What is MDG Mobile Helper? Why do we need it?
SWhat can it do?
MDG Mobile Helper contains many great features of SAP MDG. Users can create, change, search and delete materials and business partners, check up their change request inboxes, see the details of change requests, and implement the necessary actions according to the business scenarios. These features are implemented with a most simplistic and most stylistic approach. The app also includes a chatbot, which can understand the user’s directives and acts accordingly. Chatbot can be used for all the features, with wide understanding and replying capabilities with a simple usage. The user can ask for any of the features, and their requests will be completed by the chatbot. Using this application, SAP MDG users can get their work done in no time, without needing a computer around them, and with a simple and stylish use.
Used technologies
For development of this application, state-of-the-art technologies has been used. These technologies are React Native, Django, RASA, and oData. React Native is a JavaScript-based framework which is used for mobile front-end to implement the user interface with a simplistic and stylish approach. Django is a Python-based framework which is used for back-end functionalities and communication between oData and front-end. RASA
is an open source chatbot framework which is mainly used for implementing the AI of the application’s chatbot feature. oData (Open Data Protocol) is an open protocol to create REST APIs to make the main communication between SAP MDG and the application in the least time-consuming way.
Project Backend Structure
Project Backend Structure

Why use another APIs instead of directly connect with oData?
The main starting point of the project is a research and development idea. Continuously, new studies and developments will be made on the project. For this reason, if new trials do not work, it is necessary to establish a structure that allows for an easy step back. It is necessary to apply the research easily and give up from them with the same ease. That’s why setting up a service-oriented architecture-like structure makes things much easier here.
In this context, Python is a programming language that can respond very well to the demands of this project. RESTful APIs can be easily created for the desired structures with Python. At the same time, applications can be developed in many areas with Python, which is a very flexible language. Although the existing Core API and Chatbot API are related to two different areas, they have been implemented easily. Of course, new services can be added apart from these. For example, it is a very suitable language for developing deep learning or machine learning prediction algorithms that are planned to be added to the project. In order for the project to be sustainable and because React Native is a frontend framework, some logic processes must be done at the backend level. The implementation of these processes is much easier with a flexible language such as Python compared to the ODATA protocol and ABAP.
Why React Native instead of SAP Fiori?
React Native is one of the most common framework amongst JavaScript frameworks. It is a state-of-the-art technology, and it is widely used for developing mobile applications. SAP Fiori is a user interface solution by SAP, which uses SAPUI5, which is also a JavaScript framework. But why SAP Fiori has not been used?
• React Native is very flexible, meaning that the application can be implemented in the most user-friendly way. But SAPUI5 has limited customization, its design and functionality are pre-defined and cannot be easily customized, this creates an issue for building a user-friendly application.
• React Native can show very decent and strong performance, it can easily support massive datasets without slowing down. Also, complex user interface controls can be built without any performance issues in React Native. However, SAPUI5 can lead to some performance issues with large datasets or complex user interface controls and can slow the application down.
• React Native is an open-source framework and maintained by a large community of developers. It also follows a more agile development approach, so it gets frequently updated. This makes React Native to keep up with the contemporary approaches. However, SAPUI5 gets less updates because it is not an open-source framework, this leads the framework to be more old-fashioned in terms of both style and functionality.
• In React Native, external libraries can be (and commonly) used, and these libraries are mostly solid, since they are also open-source libraries. They can be used to create wide range of different components, and because of they are created for React Native, these components are compatible with mobile devices. But using external libraries can be very hard in SAPUI5, and generally there can be compatibility issues using different devices.
• React Native allows developer to use a single codebase to develop onto both iOS and Android devices, whereas in SAPUI5, the developer needs to write separate code for specific platform’s native languages and SDK’s.
How can the application connect to the SAP system?
Before connecting to the SAP system, the application is supposed to send data regarding both the material and change request to the Django server. In conjunction to this, the URL, regarding filtering to fetch convenient data, adding or updating the data, is parsed. In addition, since the structure has names of oData service names, the system is able to send a request to SAP system.
Literally, OData services are in charge of sending data to both Frontend and Backend sides of programs. As reported on, oData services benefit from MDG APIs for sending a convenient response to users.
How the application takes advantage of traits of SAP?
To take advantage of the mobile application, the users should be able to see data. In the backend hence APIs play a determinant role for it. So, what should be done for benefiting from them? For using APIs of an SAP system, entity sets regarding to a module should be implemented. Hence, for developing an MDG mobile application, MDG APIs had been taken into consideration. For making a comprehensive backend mechanism, not only APIs are used, but also the communication between OData and APIs must have been done through ABAP and SQL.
As mentioned in the above section, OData services use various SAP MDG APIs for handling processes as a user can do on an SAP Web Dynpro screen. With the help of those tools, users will manage to simultaneously create a material and a change request. Not only creating, but also, they will be able to process a change request and decide if the change request should be activated.
Chatbot feature
Chatbot has been designed and implemented to help the user to use the application’s features with simple requests from only one screen. This chatbot is an AI chatbot which has been built with RASA. It has many capabilities with Natural Language Processing, All the features are supported by the chatbot, some of them has been shown in the examples below.
In this case, user asks the chatbot to create change request for creating a material. The chatbot asks if the user wants to be redirected to the material creation screen inside the application or continue the creation from the chatbot. User wants to continue, so the creation process begins. Chatbot asks the needed inputs from the user, when all the inputs have been given, the chatbot asks if the user wants to finalize the creation process. The user approves, and within a few seconds, the material has been created. Finally, the chatbot gives the information about the change request, that has been created.

In this second case, user asks the chatbot to reject a change request. After that, the chatbot asks the change request number. The chatbot checks if the change request with that change request number exists, and if it does not exist, gives an error message and asks the change request number again. When an existing change request is given, the chatbot asks the user to write a reject note. After the reject note is given, chatbot asks to finalize the reject process, and when it is approved, the chatbot rejects the change request within a few seconds.
MDG Mobile Helper has got many features, such as creating, modifying, deleting and searching materials and business partners, access and display the user’s inbox, use the user-defined filter for the inbox, show the details of change requests, apply the actions for the change requests according to the user’s role, and many more to come.
This is the main menu of MDG Mobile Helper. It contains Inbox, Material, and Business Partner buttons. It also has buttons for notifications, settings, and the chatbot.


This is the Inbox screen. The users can see their change requests in their inbox. CR Number, Change Date and Time, Creator Name, and Status of the change requests can be seen. These change requests can be sorted by those fields. There is also a filter button to use the user-defined filter. The user can press on a specific change request to see the details of that change request.


This is the change request details screen. We can see the header data, notes, basic data and the material description in this screen as seen above. We can also edit the editable fields.


After the user writes the reject note, the reject process will be finalized within a few seconds. And it can now be seen that the change request is now in the “To Revise: Perform Changes” status.
|