The background to RMAD
Mobile development for enterprises has gone through a lot of evolution. Back in 2007, mobile enterprise application platforms (MEAPs) hit the market, enabling the development of mobile app’s that supported three or more multiple-device OSs as well as multiple backends. 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 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 (MADPs) that used mobile SDKs, open platforms, and open protocols. Again, SAP followed this movement with the SMP mobile platform.
Among MADP providers, there have been various attempts at creating a rapid mobile app development (RMAD) that creates an environment in which 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, 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 that allows both for the customizing of the new standard native SAP applications such as SAP Asset Manager, as well as for creating new native mobile app’s. Both of these types of app’s built using the mobile development kit can be developed with offline capabilities and clever synchronization of business logic. As a native mobile app, it can use all the standard on-device features such as the camera, facial ID, accelerometer, VR, etc.
Do I like RMAD technology? Yes I do. In the old days, it was called 4GL (fourth generation language)—the golden rule being to define the data first. Also, when I ran my own mobile development company, we quickly realized that it was very slow to write all our mobile app’s in C++ across multiple hardware platforms, so we came up with our own in-house RMAD running an interpreted metadata language and exchanging compressed XML.
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 an app will be created for Android in 2019. But roadmaps 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 plug-in adds all the building blocks needed 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 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 plug-in. 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 authorized 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 synchronization of large amounts of lookup tables.
How do I develop an app using a mobile development kit?
When defining a metadata-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 plug-in. This helps search for and locate the already-exposed ODATA objects you will need within your application. From this object browser, you can also examine and embellish the metadata 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.”
I prefer to do these after defining the data. Using the visual rules editor of the WebIDE MDK plug-in, 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 when creating 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 functional consultants rather than app developers to create the business rules. This separation of functional behavior from application user experience is a great idea, using the skills of these two disciplines to their best. It frees the functional consultant from having to write specifications that are then incorrectly interpreted by the developer.
Once you have defined the data that will be used by the app, you can use the WYSIWYG page editor of the WebIDE MDK plug-in to lay out 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 already-defined object data. 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.
The action editor in the WebIDE MDK plug-in 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.
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 metadata-driven environment. A special mapping control is a good example that was used with Asset Manager. Because these custom add-ons require Swift expertise, we are talking about a costly senior iOS developer being used, which will slow down RMAD development.
- The mobile development kit utilizes a metadata-driven development model. This gives developers a much higher level of abstraction when building the app. There is no need to worry about low-level system detail such as on-boarding, data synchronization, or networking
- 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 and the application checks for updates every time it communicates.
- 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 devices. So if you have a deployed mobile landscape of other OSs, 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?
At Capgemini, we have implemented these complex field service/asset management-type app’s for 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, this RMAD should be your first choice.