Skip to Content

Last year I was the integration/solution architect to expose a custom SAP business process as mobile App. In this posting I want to enumerate the major aspects and challenges we encountered. And with success, the App is in productive use, and the end-result recently won the SAP Quality Award 2015.

Aspects and challenges

SAP business system is a closed system

This actually encompasses 2 different aspects. For one, the functionality of the SAP system is locked internal in the SAP system with SAP proprietary technology and data formats, not exposed nor fit for alternative UI channels. And second, the SAP system is isolated from the evil outside in the company-internal infra.

Users demand a pleasant ‘form-factor’

Users are fed up with the arcane UI, and want a user-experience that feels good. This means it must look good, and moreover that it must have a pleasant behavior that supports the user in doing the work effective and efficient.

The mobile ‘form-factor’ must enable multiple devices and screens

Most noticable is that users expect an App to be usable from tablets and smartphones. And second is that for tablets, but in particular for smartphones, multiple different device formats and OS platforms are in use.

Unknown makes unloved

Since decades the SAP business systems are the stable base on which the organizations rely. Any change to this status quo inhibits the risk of disruption. And then also all that mobile technology and aspects introduces new knowledge. It is human response to be very careful, perhaps even scared, to all that new stuff.

The unknown outside is evil

IT security is not an easy, or even thankful job. They are held responsible in case of issues, and taken for granted otherwise.

When functionality is exposed via additional channels, also the security vulnerability increases. It is only rightful that security is very cautious, and demands proofing that the changes do not result in unacceptable security and thus business risks.

Secure and reliable authentication from App into SAP

Like all business systems, SAP internal processing is permission-based. What one is allowed to do depends on authentication (who you are) and authorization (what your allowed to do). In mobilizing the business process, the authentication part is primary delegated to the App, while the authorization part remains in the business system.

Typical the App-identity is different from the SAP identity, and a credential-mapping is required (Single Sign-On).

Performance

Although performance is also an aspect of the pleasant app-experience, the importance of this topic for user acceptance on itself warrants dedicated focus. Business-users are just as intolerant against bad-performing business-apps as they are in the personal context against non-performing consumer-apps. Also note that a major motivation for mobilizing SAP business process is to facilitate shorter time to handle, and a performant ui-experience is in that sense an absolute requirement.

What if…

…in <x> time insights or business situation has changed, and the delivered App is no longer sufficient? Such uncertainty about future developments (business and technology) is often misused as excuse to halt, and make no changes. And users are withheld from improvements in operation of the daily business actions that can be delivered to them today.

Infra aspects highlighted

1. Interoperability

Connectivity from App to the SAP business system
Expose the SAP proprietary data and functionality for outside consumption in the App
Data mapping of SAP proprietary data model in a standards-based, and optimized dataformat
Integration endpoints

2. Identity Management / IAM
Authentication (SSO across diverse authentication administrations)
Permission management

3. Security
Data loss ( through Device loss)
Data integrity (inspection, to prevent via encryption)
Unmanaged devices / BYOD
User and Device onboarding

4. Performance
Network throughput + latency
Scalability
Availability

5. Auditing / Audit Trails
Logging
Health monitoring

Architectural decisions:

  1. Deliver the App as a web-app; and rely on platform browsers to make sure the App runs on the multiple devices
  2. Deploy as PhoneGap hybrid App that can directly be started from the device (relieving the user of need to retype the url in browser)
  3. Expose the required functionality to outside as an API, with endpoints that are invoced via integration and data standards.
  4. Use Gateway as middleware to deliver the service API: develop + runtime
  5. Use SAPUI5 as html/javascript platform to deliver Responsive Design UI, and in look&feel that users are getting more familiarized with via the expanding SAP Fiori apps
  6. Architect the App as loosely-connected UI-part and Processing part. This allows to exchange the UI-part for another UI-format when the situation has changed, while the processing part can be reused.
  7. Architect the service API for an optimized integration surface. Avoid excessive call behavior of the App into the service API resulting in network latency, and design ‘chatty’ interface methods instead of data-minimized service methods.
  8. We did NOT utilize SAP Mobile Platform, but hook into mobile platform that is already in use. Providing device onboarding, reverse proxy, transfer security.
  9. Rely on proven SAP-technology of Java Authentication Server + LogonModule to convert customer-internal credential into SAP Logon Ticket (MYSAPSSO2, used in the SAP system).

Project approach

  1. UI-design the ‘mobile experience’: build mock-ups together with stakeholders to quickly arrive at an App-experience that will truly help the business users.
  2. Take the initial unknowledgable at the customer side on the tour to teach the new mobile concepts, and as such take away their uncertainties and anxiety that are due the unknown
  3. Team up with SAP as supplier, and convince IT stakeholders at the customer on the support level of standard software (Gateway, SAPUI5). Call in on well-known SAP expertise (Andre Fischer, Holger Bruchelt) for solid advice and/or crosschecking.

Some relevant references:

To report this post you need to login first.

2 Comments

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

    1. William van Strien Post author

      Thanks Holger, and as always also for your help in achieving this.

      I too miss SAP / Microsoft interop, and in particular the dedicated community under your guidance. But I’m certain that the topic will gain market attention again; and I do my own best in getting to that. Already again doing SharePoint and SAP in my current job, although for now still separate activities without integration; but a next step is defining a roadmap for the near to middle term.

      Regards, William.

      (0) 

Leave a Reply