Skip to Content

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.

SAP Backend - Gateway - SUP.png

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.

To report this post you need to login first.

7 Comments

You must be Logged on to comment or reply to a post.

  1. Jarret Pazahanick

    Thanks for detailing out your experiences and curious as to why the customer did not use the standard delivered SAP HR Approval Mobile App and chose to build their own.

    (0) 
    1. William van Strien Post author

      Very valid point. There are actually 2 reasons for why we did not utilize the standard SAP HR Approval App:

      1. The standard App requires a standard SAP HCM configuration; in our case the customer HR department has made several organization-specific customizations in SAP HCM, and the standard App does no longer fit
      2. At this customer we also intentionally aimed to gain experience with custom developing up to implementing a Mobile App. In fact, we also developed the same App as a mobile site variant; utilizing SharePoint as website framework, and Duet Enterprise with its workflow capability to expose the SAP workflow tasks to the SharePoint context.
      (0) 
  2. Dhananjay Kumar

    Hi, I have a very basic question and I would really appreciate if you can share your thoughts on this . When your are using SUP to develop mobile application , what was the need to add another middleware in the form of SAP Netweaver Gateway ? If its Odata, then can’t we expose data from Application Server in JSON or XML format to SUP and hence can build our mobile application without even introducing to another layer of server. If its security, then there is an option of using  reverse proxy servers n hence without exposing the actual server location we can consume date within SUP from application server. I am trying to understand what actually SAP Netweaver Gateways buys me, what unique feature do I get when by introducing SAP Netweaver Gateway to my landscape.   Thanks

    (0) 
    1. William van Strien Post author

      Hi Dhananjay,

      Role of NetWeaver Gateway is as central exposition layer of the underlying SAP business suites; via nowadays standards interoperability standards.

      NW Gateway out-of-the-box contains Workflow OData service (WFService); that exposes user decision tasks from SAP workflow backend to any consumer that can consume OData; and allows to handle the tasks from these consumers.

      Role of SUP in our project is ‘limited’ to secure infrastructure; it is not applied as integration / interoperability layer. That role is for Gateway.

      Regards, William.

      (0) 

Leave a Reply