Rapid mobile app development

Blog: Capgemini CTO Blog

The background to RMAD

Mobile development for enterprise has gone through a lot of evolution, back in 2007 the mobile enterprise application platforms (MEAP’s) hit the market enabling development of mobile app’s that supported 3 or more multiple device OS’s as well as multiple backend’s. The MEAP was marketed as the one stop package solution that addressed everything in the mobile lifecycle from app design, to final deployment and maintenance. An example of a MEAP is the Sybase (Later SAP) SUP mobile platform.

However these one-size-fits-all solutions were high on promise but short on actual delivery. Typical problems being vendor lock in, limitations on the App’s created, complex maintenance and difficulties in moving the solutions between MEAP platforms.

The solution was for the market to move to mobile application development platforms (MADP’s) which used mobile SDK’s, open platforms and open protocols. Again SAP followed this movement with the SMP mobile platform.

Within the MADP’s providers there have been various attempts of creating a Rapid mobile app development (RMAD’s) which creates an environment where Enterprise App’s can be created quickly. Within SAP the Agentry metadata driven App’s, on SMP and its SAP cloud platform mobile service (SCPms) equivalent, follow this model.

SAP in addition to its Agentry capabilities has recently introduced a new RMAD environment called the Mobile Development Kit. This environment was previously called SEAM (SAP enterprise application modeller) which is a more accurate name for its capabilities. Again like Agentry this new RMAD tool is a metadata-driven environment which allows both for the customising of the new standard native SAP applications, like SAP Asset Manager, as well as creating new native mobile apps. Both of these types of Apps built using the Mobile development Kit can be developed with offline capabilities and clever synchronisation of Business logic. As a native mobile app it can use all the standard on device features such as the camera, face-id, accelerometer, VR etc etc

Do I like RMAD technology – yes I do, in the old days it was call 4GL (4^th generation language) the golden rule being to define the data first. Also when I ran my own Mobile development company we quickly realised it was very slow to write all our mobile app in C++ across multiple hardware platforms, so we quickly came up with our own inhouse RMAD running an interpreted metadata language and exchanging compressed XML.

So how do I get started?

Firstly the entire environment is based on SAP Cloud platform mobile services (SCPms) on top of that you will need the SAP Cloud Platform SDK for iOS because at the moment only iOS devices are supported. I can see from the SAP Asset Manager roadmap that a App will be created for Android in 2019, but roadmap’s can change and indeed this roadmap last year said 2018 for Android. Currently the SMP on-premise version of mobile services, does not support this environment. I believe it is unlikely that any new features will be added to SMP with SAP’s current Cloud focus.

The mobile Development Kit (MDK) has a web based editor that is loaded as a plug-in to the SAP Web IDE. This plugin adds all the building blocks you need to create mobile app’s using wizards, drag and drop standard UI elements and mobile templates. Beware of thinking that because we are using the tool Web IDE that this development has anything to do with UI5 or Fiori, it does not.

On the architectural diagram below you can see that the app designer develops the Metadata app using the Web IDE plugin. This App then sits within the MDK extension to the Cloud mobile services, and is pushed out to Client devices when the user of the device is authorised to run that App and use that data. The OData synchronisation part of the App, uses standard Cloud mobile services plus the iOS extensions for mass synchronisation of large amounts of lookup tables.

So how do a develop an App using Mobile Development Kit ?

Data First – When defining a meta-data driven application, the normal rule is to define and understand your data first. I am a firm believer in data first, you need to know the data needs of your app first, what is available and what is missing. For this we use the Object Browser, in the WebIDE MDK plugin, this helps you to search and locate the already exposed OData objects you will need within your application. From this Object browser you can also examine and embellish the meta-data with associated actions, UI elements, globals and rules. This tool would be challenging if used by a Functional Consultant, but they typically know the backend data well, so if they can cope with the interface I would say go for it.

Business rules – I prefer to do these second after defining the data. Using the Visual rules editor of the WebIDE MDK plugin you can visually create business logic for execution and managing data. The editor makes use of the Google Blockly visual code editor, which is easy to understand to create the native script code. For complex rule logic, it is possible for the developer to write rules directly in native script. The idea behind this editor is to allow the Functional consultants to create the business rules rather than the App developers. This separation of Functional behaviour from Application user experience is a great idea, using the skills of these two disciplines to their best. This frees the Functional consultant from having to write specification which are then incorrectly interpreted by the developer.

App Page – Once you have defined your data that will be used by the App you can then use the WYSIWYG Page editor, of the WebIDE MDK plugin, to layout the pages of the application using very easy drag and drop and drop down property sheets. Attached to the controls on the page you can then add event handlers and bind controls to the object data already defined. You can also attach business logic rules to the controls. This is the heart of the application, as the App developer builds page by page, keeping an eye on the UX of the page.

Actions (Workflows) – The Action editor, in the WebIDE MDK plugin is used to define the workflow. The action editor interacts with the Object Browser to allow the workflows to interact with the previously defined objects, properties and rules. The Success or Failure execution rules are also defined here. Again like the Business rules these actions are easy to create and the tool is aimed at the Functional Consultant inputting these workflows rather than the App developer.

Custom Plugin’s – It is also possible to develop additional custom native controls, using iOS Native code developed in Swift, which can then be used as a new control within this Meta data driven environment. A special mapping control is a good example that was used with Asset Manager. Because these custom addon’s require Swift expertise, we are talking about a costly senior iOS developer being used, which will slow down how rapid RMAD development will be.

Summing up:

Advantages:

The Mobile Development Kit utilises a metadata-driven development model. This gives the developers a much higher level of abstraction when building App. There is no need to worry about the low level system detail such as onboarding, data synchronisation or networking.
The use of open industry standard technologies such as NativeScript, Javascript, JSON and OData within the underlining architecture.
Deployment and Lifecycle management are built in to the Mobile Development Kit as part of the Cloud mobile services. Updated App’s are sent to the field with a few clicks, the application checks for updates every time it communicates.

Disadvantages:

Like using Syclo, this seems a very strange way at first to write mobile App’s.
You need to deploy these App’s using SCPms Cloud, which can be very expensive when compared to Amazon, Google or Microsoft cloud services.
The Mobile Development Kit currently only works with iOS device. So if you have a deployed mobile landscape of other OS’s then this is not the RMAD for you.
There is no integrated way of defining tests to test your application.
More difficult to diagnose and debug the App if runtime problems are encountered.

Given that from my list above the disadvantages outweigh the advantages, is there any reason for using SAP’s RMAD Mobile Development Kit?

We at Capgemini have implemented these complex Field Service / Asset Management type app’s at many customers, sometimes it makes sense to use an Off-the-shelf functionality such as you receive with Work Order Manager using the SMP Agentry platform. Sometimes the customer wants a cheaper option, because the cost of Agentry / SMP / SCPms can be prohibitively expensive, and we implement a Hybrid UI5 mobile app using ODATA via Gateway with offline capability.

So when would Capgemini recommend using this new Mobile Development Kit? If you are happy to only use iOS hardware (Remembering that Apple, in my opinion, is the best mobile hardware in the world) as your Field Service / Asset Management device of choice. And you can implement the SAP Cloud Platform with its mobile services into your architecture … then this RMAD should be first choice.