HANA and Gateway for Retail POS?

[Former Member]

Coffee lovers...

I hope you don't mind me bouncing an architecture question off you? I can't find a more suitable forum for this kind of question!

A retail customer is blueprinting for a new POS implementation - they have 1100 stores and will run IS Retail.

Would it make sense to run HANA appliances with Gateway services and find a way to ensure the stores are always online (backup comms etc)?

The ECC developers would focus on exposing relevant IS Retail etc services through Gateway - golden rule to keep business logic inside SAP. I would aim for stateless services too to keep it simple.

The UI team could freely build all manner of in-store solutions on mobile devices, registers, scanners etc. It would be easy to create something like an Apple store experience in the higher value stores (they sell furniture under one brand).

Ideally they would work on a cross-platform development environment so the team could easily select the best hardware for any particular requirements. For example, wxWidgets looks like a way to keep UI development consistent regardless of device.

I would really value your thoughts on this kind of approach.

Thanks

Peter

[Former Member]

I would first clarify whether a stateful application would be a show-stopper and whether all business processes can be supported by stateless applications - at least without dictating too much to the intended process.

A bar-scanner might not be a problem. An interactive shopping cart or screens with tabs in them might well be though.

Cheers,

Julius

[Former Member]

Hi Julius.

That is a good point. Hopefully shopping carts and tabs can be handled by persisting data locally. Where it gets messy is orchestrating the back end processing. Recovering from errors part way through a multi-transaction process is the pain point. But I don't think exposing that complexity to the user should be the solution. Handling stateful calls also puts more business logic into the front end.

If only ROLLBACK worked at a transactional level!

Peter

[Former Member]

Hopefully shopping carts and tabs can be handled by persisting data locally.

Any easy-to-make error is also to cast your system sizing in stone based on some assumptions, like this one.

For example, that you do not encrypt data and therefore loadbalance at logon and keep session IDs to send requests to the same server. Most likely you will do this. However you will at the latest need to encrypt for the shopping cart scenario as you will want to avoid having your last pair of socks sued off your feet... If you want to use end-to-end SSL to keep the connection to the server open, you will need to re-think your loadbalancing and system sizing.

Cheers,

Julius

[Former Member]

Hi Julius,

I was actually thinking to persist the contents of the shopping cart or tabbed pages locally as the user builds the full transaction, and then pass the whole lot to the server in a stateless call.

Regards

Peter

Edited by: Pete Chapman on Jan 31, 2011 9:21 PM

[Former Member]

Okay, but you also said:

Handling stateful calls also puts more business logic into the front end.

If your stateless applications are processing screen-flows and shopping cart type navigation on the frontend until each imaginable LUW is complete, then you might end up with more than the SAPGui installed over there anyway. Actually, you might need the database on the frontend as well for some business processes...

Please accept my apologies. I am a sceptic and specialize in breaking things

Cheers,

Julius

[Former Member]

Thanks Julius - no problem. If we use simple solutions to solve simple problems then they are harder to break.