Aspects and challenges encountered mobilizing a SAP business process
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).
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.
…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
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
2. Identity Management / IAM
Authentication (SSO across diverse authentication administrations)
Data loss ( through Device loss)
Data integrity (inspection, to prevent via encryption)
Unmanaged devices / BYOD
User and Device onboarding
Network throughput + latency
5. Auditing / Audit Trails
- Deliver the App as a web-app; and rely on platform browsers to make sure the App runs on the multiple devices
- Deploy as PhoneGap hybrid App that can directly be started from the device (relieving the user of need to retype the url in browser)
- Expose the required functionality to outside as an API, with endpoints that are invoced via integration and data standards.
- Use Gateway as middleware to deliver the service API: develop + runtime
- 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.
- 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.
- We did NOT utilize SAP Mobile Platform, but hook into mobile platform that is already in use. Providing device onboarding, reverse proxy, transfer security.
- 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).
- 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.
- 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
- 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:
- Single Sign On to SAP NetWeaver Enterprise Search 7.2 Using Integrated Windows Authentication
- SAP Fiori – Overview of SSL and SAML 2.0 Configuration
- Building SAP Fiori-like UIs with SAPUI5 in 10 Exercises
- How-to Avoid Caching of Confidential Data
- Gateway Protection against Cross-Site Request Forgery attacks