Just for Christmas holidays we successfully implemented at customer premisse their first custom-developed App utilizing the SAP Mobile Platform. The App is a so-called productivy application, and enables managers to execute routine approval tasks at arbitrair moments and locations [inside and outside office buildings + network] that suite the manager best. The approval tasks originate from SAP workflows, e.g. HCM expense handling business process.
The road to this achievement was rather bumpy, not in the least because this was the first project in which multiple recent SAP technology developments where utilized and validated. SAP NetWeaver Gateway OData services, Sybase Unwired Platform 2.1.x, Sybase Afaria.
Conclusions / Important lessons learned
- Standard Gateway WFService can be used to expose SAP workflow tasks with user involvement, to non-SAP front-end
- The different components of SAP Mobile Platform are all still new, with minimal to no references, incomplete and often outdated/incorrect documentation, no best practices yet, referential architectures and so on
- Mobility platforms and technologies are evolving fast; in general and in particular this also holds for SAP Mobile Platform
- We actually needed the latest versions of Gateway 2.0 (SP4 or later) and SUP (2.1.5) to successfully complete the Manager Task-Productivity App
- The current state of the platforms and technologies is sufficient, but does require us to apply some workarounds and accept some sub-optimal execution.
- Pull architecure is recommended for Gateway OData based App
- User-centric Design is key to deliver an App that the end-users are actually willing to use
- Workflow Extension Points (BAdI) enable to plug-in into the Gateway Workflow Service behaviour to augment with specific required behavior. E.g. retrieve workflow-specific additional data, complete ActivityTask iso the standard support UserDecision task.
- The manual user tasks (human interactions points) of SAP Business Suite workflows can be exposed outside boundaries of SAP without any modification in the SAP workflow.
Architecture decision: Pull or Push?
Expose SAP data to outside consumers can be achieved either by:
- Pull: Consumer requests the data from SAP
- Push: SAP Business Suite activily propagates the SAP data to any interested consumer.
Both architectures have their value. But in general the recommendation is to apply the Pull architecture, and only consider the Push architecture when Pull cannot deliver. Most important reason is that Push architecture is a lot more complex for consumer to handle correctly. The consumer must be able to ad-hoc handle the received notifications from the publishing SAP business suite, optional per received notification still invoke the backend to retrieve additional data, and maintain plus synchronize a local repository on the device. SUP Mobile Business Objects (MBO) is designed to support this and includes data-synchronization support. But SUP OData does not [yet] include support for this, and is by default better suited for pull-scenarios.
Note: In a next blogpost I will go into more detail on the Pull versus Push architectural decision.
