Offline Apps Series: Blog 3 Infrastructure
Blog 3: Infrastructure
In this blog, we address the more technical aspects of a mobile app development project. There are several technical questions to address. Although they are subordinate to the business need – they enable the business and the actual app – do not underestimate them. My experience is that mobile app projects get delayed due to unresolved technical issues, not because the business wants a complex app!
When building your first mobile app we also have the lay the land for the mobile infrastructure we plan to use and should be included, but bearing in mind that the this of course overstates the cost of the first app which is recaptured later once further apps are developed. Approaches are mentioned below; understand that they are just two of many options and not a comprehensive list:
Outside-in where we put into place an additional infrastructure around our business system (SAP ECC or any other SAP Netweaver products). This has the advantage that we can use the platform also for non-SAP products and give the user a seamless process if the business data is store in more than one system or database.
SAP took this approach with their SAP Mobile Platform (SMP) product which mainly relies on the integration via the widely adopted oData protocol to communicate with the system databases.
Inside-Out focuses on one business system and the mobile platform is added to the existing infrastructure, limiting potentially the usefulness of the mobile platform from the outset. Be sure what the end-game is when adopting this approach.
Neptune Software took this approach with their SAP add-on which can be deployed on any SAP Netweaver application server, including SAP Gateway.
My personal recommendation is to use Neptune Software for several reasons:
- I am a SAP centric consultant and my approach is usually to imbed to best practice process in SAP ECC and expose it via a simple mobile app to the end-user.
- Having done multiple implementations for web and mobile apps using SAP’s WebIDE and the Neptune IDE, I find that Neptune has a considerably quicker time-to-value than SAP’s Fiori approach – with the apps looking and feeling the same since both use SAPUI5 libraries.
- Neptune is much easier to learn for an established ABAP developer.
- Neptune uses the existing SAP transportation management system (STMS) tying the app lifecycle management to existing processes in SAP Basis support teams.
- Neptune provides better tools for device integration and mobile app deployment. SAP’s and Neptune’s approach are both based in the open-source Cordova libraries. However, Neptune provides a much easier approach (via Adobe Phonegap) to bind them into the hybrid mobile apps and sign them with corporation’s enterprise certificates and provisioning profiles.
- With Neptune, I have a much smaller IT landscape footprint than using SAP’s mobile platform. And the downside of the inside-out approach can be mitigated if we have multiple Netweaver products by deploying Neptune on the SAP Gateway. With the newest support pack, we can even integrate any oData enabled third party system in the future!
- In Neptune, everything is one place in SAP GUI and I do not have to subscribe to their professional WebIDE services and install and use their and Hybrid Application Toolkit (HAT)
- Neptune allows to write the app code once and use it anywhere (office, on the move), any device (iOS, Android, WinMobile), any browser (Chrome, IE11, Firefox, Safari), any time (online, offline) – all in one offering!
I may sound biased here, but my experience is that it at least takes at least a week for a focussed developer and technical consultant to put hardware and infrastructure in place and install all developer’s tools – whereas in Neptune it takes me ½ an hour and I can spend the first week building the first app and already collect first feedback from the business. Your mobile app project should be user focused first!
Knowing the type of device the user will use is quite important for many reasons.
Real estate. An app which was designed for a tablet may technically work on a phone, but be awkward to use. The size of the screen is crucial and this should be clarified right at the start when naming the use cases to avoid surprises later.
The developer can make sure to develop the mobile app to be ‘responsive’ to the screen size, thus we can develop the app once and run it everywhere. The pop-in features in SAPUI5 are a saviour when displaying tables and spreadsheets and look good on all devices.
Be clear on which operating system is used. Market leading in enterprise settings are Android and Apple devices. Neptune also supports WindowsMobile if that is required.
Be clear on the environment and which situations devices are used. As you describe the use case describe the environment in which devices are used. Managers like to use iPads and iPhones before, after and during their busy meeting or travel schedule. When considering other use cases, you may require ruggedization or even explosion-proof devices. In this case, almost always you turn to Android tablets or phones for technicians and operators, since they are open systems and can be bought ruggedized or even explosion-proof from the manufacturer.
We have worked with e.com, for example, who provide Samsung Android devices from consumer grade to Atex zone 1/21 certified.
Think about device integration features which enhance the way the app is going to work and make the task for the end user easier. For example:
- Camera integration – a picture says it all
- Photo or file library requirements – do we have data collected by other apps on the device?
- Document display capabilities – display design document, certificates etc.
- GPS location and map integration – show me directions to next job location
- Compass – in which direction from my location do I have to look to find the issue?
- Barcode, RFID or NFC reader capabilities – reduce typing errors, speed up data entry
- And I am sure there are many more
With that out of the way, the take-away message is though:
Know the end-game. Focus on one deployment option first!
Having a view on how SAP experience should look like in the future is important, but keep in mind that for the first mobile app you should aspire to keep the use case as simple as possible, restrict to a single device type and allow for future improvements and new apps in a larger SAP mobile app roadmap.
Experience shows for the first app the effort of putting the mobile infrastructure into place has its own challenge and provides high learning curve for the business and SAP in-house teams alike.
After the project allow for lessons to be learned and take them into the next app development cycle. It is a journey after all!
Using Neptune as my go-to-solution for SAP mobile apps, it is worthwhile to outline some security aspects which need to be addressed as well in the first mobile app project. There are many more options than the ones outlined below. I am focussing on the two typical examples:
The typical 2-tier landscape would simply involve deploying the Neptune Runtime as an add-on software component version into your SAP Netweaver application server by importing their transport and activating the license and the SICF nodes and you are ready to go developing.
This deployment should only be considered if we do not require to expose the SAP application as a mobile app outside the corporate network or if the users are tunnelled into the corporate network via a VPN setup and if we only require that single SAP system as the backend system.
A 3-tier landscape needs to be considered otherwise which allows added layers of security. Here, we deploy Neptune on the SAP Gateway and on the back end as required.
The gateway acts as hosts for the app, the backend has the ABAP code for data integration and the two systems connect via trusted RFC.
Register a domain which is mapped via a proxy/reverse proxy server to the internal IP addresses of the SAP gateway if you intend to use the mobile app outside the corporate network.
Signing the app with a developer certificate and including the provisioning profile is a must for deployment on iOS devices and good practice for Android devices. The developer should ask for those to be provided from the enterprise’s security team and require also the key phrases which need to be entered when wrapping the app in Adobe Phonegap. Consider that you must sign up to subscriptions for:
- The Apple Enterprise Developer Program when using iOS devices to countersign certificates and create provisioning profiles. Apple will require evidence that you are a valid and registered company.
- Adobe Phonegap for wrapping up the app build in Neptune and creating the native installation files for the target devices (iOS, Android or WindowsMobile)
Deployment of the .ipa and .apk app installation files should happen via an MDM system, but can happen via Neptune’s own app catalogue as well.
It is important to note, that Neptune mobile apps automatically hydrate and update themselves if changes to the app are deployed to your SAP production system. This makes it easy from a change management perspective for the app developers to quickly amend and improve the app on user feedback!
From an SAP point of view, you still need named users for licensing of SAP as well as Neptune Runtime and therefore – especially if devices are shared – we need to simplest possible way to authenticate the user who is using the mobile app.
Decide on user authentication. Investigate and consider if the mobile devices are personal or shared across the work force.
A simple authentication method for the user is crucial and is a key aspect in user acceptance!
- SAP user + password is of course always possible, but is cumbersome on a small virtual keyboard on a phone and can be a real hurdle if someone just wants to approve some purchase requisitions, but spends most time on the phone with your user support resetting passwords.
SAP user + password works for professional users, who are already versed in SAP.
- Neptune allows to set a PIN code or finger prints after the first login, but password expiration policies may still require the user to remember SAP user and resetting passwords accordingly.
- Alternatives could be a swipe-in authentication, e.g., by using employee badges in combination with SAP user + password above.
PIN code, finger prints, swipe cards or key fobs are a good approach when devices are shared, like on a shop floor scenario.
- Most user-friendly option is a Single-sign-on option empowered by an Active Directory solution. Thus, the user would typically just enter the network user and password they use daily for accessing the company computers anyway.
Ideally, providing an identity certificate is deployed on the mobile device which is accepted by SAP by matching it against the root certificate which issued the identity. But, ensure your existing MDM and identity provider solution deploys the identity certificate in the keychain of the mobile app you are creating!
Single Sign On is the most user-friendly option, but may not be appropriate when sharing devices!
Lastly, if the application is to run offline, be sure that all locally stored data is encrypted. In Neptune that is easily achieved and comes as part of the Neptune package, the app developer just activates that feature in the app during development.
In the next and last blog of the series, we are looking at the implications of mobile and offline app development from the developer’s point of view.