Experiences from building a first SAP Gateway + SUP Mobile App

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

1. Standard Gateway WFService can be used to expose SAP workflow tasks with user involvement, to non-SAP front-end
2. 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
3. Mobility platforms and technologies are evolving fast; in general and in particular this also holds for SAP Mobile Platform
1. 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
2. The current state of the platforms and technologies is sufficient, but does require us to apply some workarounds and accept some sub-optimal execution.
4. Pull architecure is recommended for Gateway OData based App
5. User-centric Design is key to deliver an App that the end-users are actually willing to use
6. 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.
7. 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.

Preserve X-CSRF-Token requires SUP 2.1.3

At customer we are conducting an innovation project to experience and validate the applicability of SAP NetWeaver Gateway and Sybase Unwired Platform (SUP) for exposing SAP workflow tasks management to mobile devices. The App has 2 integration dataflows with SAP backend:

1. Retrieve the list of open tasks for logged-on user
2. And per task, propagate task decision to complete the SAP workflow

The integration App - SAP Backend is achieved via REST and OData; which is stateless. To protect against Cross-Site Request Forgery attacks, SAP Gateway requires that data modifying requests include a valid X-CSRF-Token in the header. The token value must first be retrieved through HTTP Fetch via a non-modifying request, and can then in this session be used for subsequent modifying requests.

This approach worked correct when initially SUP excluded, and with requests direct invoked against SAP NetWeaver Gateway. Upon including SUP in the system landscape, we received error '403:Forbidden/Location'. Through HTTP sniffing I detected that the SAP session was not maintained over multiple http requests originating from SUP context. SAP Support analysis on the submitted OSS Ticket identified the inability to preserve the complete session cookie as a problem in the SUP 2.1.1 OData layer, and advised us to upgrade to SUP 2.1.3. This indeed resolved the issue.