Blog 4:Â Build
Having tackled all the discovery, design and infrastructure it is all about building the app now. We will consider build, test and deployment in this blog and hopefully provide some more and final input into your mobile app journey.
In the following I describe the typical stations I cross as I go through the build phase. The app designer and functional consultant must work with the developers shoulder-to-shoulder for best communication and the quickest way to get to an app which works for the end-user.
Get everyone into one room.
Technical specification
Together with a developer, break the design specification down into their technical details.
Design the data flow
It is advisable to map out the data and usage as it happens on the device or in SAP. I have always treated this like designing and interface between a SAP and third-party product. Create two swimming lanes which show the end-to-end process in terms of if the process step happens traditionally in the SAP backend or in the mobile app. This helps identify all the data objects correctly, when and how data is exchanged between SAP and the mobile app and ensures data integrity throughout the offline solution. An example below for a maintenance app which allows to create notifications in SAP PM:
Make sure to include:
- Any search help and drop-down data â typically SAP configuration tables,
- Any usage of master data objects in the business transaction or in search helps,
- And any transactional data within the data flow.
Identify the data objects and usage. Validate all user entries!
Provide data model for the appChristen the data objects and name all fields which are required in the app and how the data relates to each other in the app.
A by-product of this approach is that we only read and transfer data to the app which is needed. Thus, we reduce load on SAP and network for transferring the data. Result is that the end-user will be happier knowing that he doesnât have to wait for minutes for the app to respond over a 3G network.
Less data on the network makes for better user experience.
Document all data services and backend integration
Provide details on the data origin of each field in SAP, i.e., name SAP table and field name. I find Excel does mighty well for this. (Who doesnât like Excel?)
Build the web app
Using Neptune allows us to build the app as a web app first. The advantage is, that I can work on the look and feel of the app and rapidly test the behaviour, whilst the mobile app build can be done in parallel by the technical team. (see next chapter)
Implement the screens and navigation
From the design session, we have a flow chart which highlights the screens and navigations. Implement the menu and all navigation buttons.
Prototype using the target mobile device skins in your Neptune IDE or WebIDE â real estate is important form factor and should be considered right from the star
Populate all lists and search helps with data from SAP
Create appropriate test data and bring the screens to life by implementing all database read and query functions in SAP and test them with the app.
Collect feedback #1
Implementing the read-functions from SAP are always the easiest to start with and it will allow you to do a first feedback cycle with the business users and allow adjusting screen and navigation before doing any hard work.
- Do the screens have all the ârightâ information on them?
- Is the navigation intuitive and fluid?
- Collect what validations need to be put into place? What is allowed when?
- Dry-run through the business test scripts and see if we think we cover all exceptions.
Test scripts are not an after-thoughtâŚ
Implement user interaction
Build and test the business process from front-to-end. It is the easiest way to build and test in a two-pronged approach with 1 developer doing the programming and 1 functional consultant doing the testing, show and tell with the business and feeding back to the developer bugs, issues and improvements.
Build and collect feedback for popups, buttons etc. Build the posting functions into the backend and integrate them with the app. Obviously, follow the good practices of postings functions, i.e.,
- Use customer released BAPIs or IDoc functions and wrap them to provide a light-weight interface to the app which hides the complexity of the SAP data objects.
- Use well-known unreleased functions only if you must (if no proper API was provided by SAP. Does that ever happen? ?
Build light-weight interfaces for the app.
- Consider âLogical units of workâ â in SAP we may have to post multiple transactions or BAPIs in sequence, making a tremendous difference to the user by simplifying their process. Make sure to treat them as one LUW with one database commit â making it a âall or nothingâ approach when posting data into SAP. Pass the error messages back to the app.
- This ties into the error handling on the app:
Any data which couldnât be posted into SAP must be kept in the work list on the app with an appropriate error state. Include a screen for the user to review those faulty postings and the messages from SAP, i.e., all returned messages need to be associated with the work list data in question. Allow for re-posting them.
This is easiest achieved by treating the work list like an outbox with statuses like:
- ânew / not processed yetâ â awaiting actions by user on the app
- âprocessedâ â awaiting posting back to SAP
- âerrorâ â processed, but couldnât post into SAP.
The userâs work list is an outbox with processing status.
An alternative approach is a centralised error handling. For example, you can re-use the IDoc Interface which gives you a rough-and-ready error management in transaction BD87. However, my experience is that it requires a dedicated team to monitor and address any errors there on an on-going basis. That I consider counterproductive in most cases. My approach is to let the end-user get visibility of the problem (as described above) and they can either fix the underlying problem with their own means and only, if required, raise support tickets through the normal channels.
- Consider SAP is a multi-user system :All posting functions must comply with the SAP locking mechanisms (enqueue- and dequeue functions). If you use accepted postings functions like BAPIs and IDocs this doesnât require too much thought, because they will take care of it. In this case you will typically just get an error message that âObject is locked by user .â You would simply try to sync your data with SAP again and you are fine.
Collect feedback #2
Having a working version of the app now allows end-users to get hands-on with the app and validate functions and ensure completeness of the app.
Do as many cycles as you can without heavily impacting scope, time and cost.
Build the mobile app
In the meantime, the mobile app build can happen in parallel to the web app build and covers the more technical development track since for building the mobile app we must consider the security aspects covered in the 3rd blog on infrastructure.
- Developer IDEs:Â Neptune provides the simple mobile app IDE, sitting within your SAP server. The advantage is that one developer can implement the app as well as the backend integration â cutting out communication problems which you otherwise have (as, for example, if you are using SAPâs WebIDE for app development and SAP Gateway for the oData integration into SAP).
Required developer skills are:
- SAP ABAP for data integration and
- HTML5, Javascript and an understanding of the SAPUI5 libraries â which can easily be acquired by upskilling the SAP ABAP developer.
- Developer key and provisioning profile
A mobile app must be built with a countersigned developer key which matches the provisioning profiles on the target devices.
- Installation files:During building of the installation file, the app files, developer certificate and device integration libraries (Cordova libraries) are married up into a single installation file. The resulting mobile app is basically a mini web browser app which hosts the web app on the device itself and provides the integration to camera, file system, GPS etc. on the device.
- Mobile Device Management :The MDM provides the means to deploy the app, provisioning profiles and any other policies on the mobile device.
Other services to consider:
The technical track requires typical the involvement of multiple teams within the in-house IT services of the enterprise and further cloud services and systems.
- Developer IDE:Â License Neptune runtime and mobile end-users.
- Binding of mobile app:When using Neptune you need a way to create a way to turn the web app into a mobile app. Aobe PhoneGap provides the easiest way and nicely wraps up device integration via the Cordova libraries and creates the native install files (.ipa and .apk). Your first app it is even free and you can take out a subscription later on.
- MDM system:Â The MDM provides an app store for end users to download the mobile app. It also manages provisioning profiles and policies on the end-user devices. Any MDM system will do.
- Sign-up to Apple Developer Program:You must sign up for the enterprise program if you deploy to iOS devices. For Android you still create signed certificates, but the signing process can be done in-house.
- Virtual Private Network (VPN) Solution:Â If you do not want to expose SAP outside the corporate network source and procure a mobile VPN solution which supports your mobile devices.
- Single-Sign-On solution:Decide on a single-sign-on solution which provides you not just identification via SAML2.0 on an online web scenario, but via certification in an offline device scenario.
Change management
Mobile app development requires that we build a mobile app for each stage of the project
- During unit testing in the Development systems,
- During business testing in the Testing / Quality Assurance systems
- For deployment into the production system
This is because the mobile app typically is hard-wired to a specific IP address or domain name.
Transport management is a critical factor in the deployment to production and subsequent change management.
- Backend integration in SAP requires transport of your ABAP modules using SAPâs Transport Management system as usual
- The app artefacts are deployed on ECC or the Gateway and, in the latter case, require synchronised transports to production.
- Other factors may be the deployment of the provisioning profiles and mobile app in the MDM system in synch with transports in SAP.
Make sure to amend your transport procedures for change management!
Collect feedback #3
Build the app for the development systems as soon as you can and give access to them to the developers and selected key business users for assorted reasons
Test device integration
Using the prototype approach in the web app mentioned earlier provides a great facility to rapidly build all app features for the business and manage the screen design so it looks nice. But only by testing on the actual device can we make sure :
- that data management offline works by cutting network connections,
- that device integration to camera, GPS, accelerators, file system, barcode readers etc. actually work
- that user authentication online and offline is seamless.
Test the real thing.
This means that developer devices do need to be sourced and procured early in the project to support this process.
- Hand it over to the business users
Just because it worked for me (as a developer) it may not work for an end-user. Allow them to break test the app.
Acceptance Test
If you followed an involved testing approach throughout the build phase the acceptance testing should become a simple process which will confirm the final release candidate based.
- Use a widen circle of business users â users who havenât seen the app before.
- Let them validate all test existing scenarios.
- Allow them time for break testing.
- Test with good test data, close to real life in SAP production.
- Use the actual devices.
Analyse any issues and document outcome.
- Are they new improvements for a version 2?
- Where they already rejected by the project team at other times during build phase?
- Any show stoppers? Resolve them.
Document the outcome.
Deploy and go-live
We are ready to deploy!
- Onboarding:Â Prepare user guides on how to access and install the new app and get started. But that should be pretty much it. The use of the app should be intuitive.
- Prepare:Â Prepare any data ahead of go live, if required. Prepare the systems, user setup, new authorisation roles required etc.
- Change management:Â Adjust your change management procedures for future versions of the app and in preparation of the handover to mainstream support.
It should all go easy if we prepared well, but just in case:
- Provide information how to reset passwords (if required), how to reach the support team and how to raise incidents or how to feedback new ideas for the app to the developer team.
- Review incidents and feedback to learn your lessons and see problem themes evolving and manage them.
Finally:
- Seek active feedback using a survey or an online facility for feedback.
- Improve the app for serious issues, others could be tackled in the next app development.
- Plan next steps for roll-out and expand the app suite by seeking funding for the next app.
Plan your next steps.
Conclusion
Well, thank you for taking time to read some of my thoughts and I hope you can take maybe one or two useful messages from it.
Contact us to discuss your specific needs or for more information.
