MDG Mobile Assistant

What is MDG Mobile Helper? Why do we need it?

AP Master Data Governance (SAP MDG) is an integrated solution offered by SAP, where companies can easily manage their master data across businesses. It helps companies to minimize the risk of business disruption caused by inaccurate or missing data. It is very useful to prevent loss of revenue by these risks. Although this is very functional, it can be troublesome to use SAP MDG in various situations. There can be accessibility and availability issues. In some cases, businesses may be in need to take urgent actions and users may need to use its features when they are away from their computers, which can lead to major problems for the company. Also, SAP MDG can be confusing to its users with the solution’s wide range of features, so some users may need more simplified solutions. In addition, the common need to perform the same operations over and over shows the necessity of simplifying the usage of SAP MDG.

As a solution to these problems, we are pleased to introduce MDG Mobile Helper. In our contemporary world, people are getting more and more used to getting their works done by using mobile devices. Thus, using a mobile application would be a perfect solution for the stated problems. MDG Mobile Helper is a mobile application, which will be published to iOS and Android devices. This application is being developed for using many features offered by SAP MDG, and it is designed to use these features with simpler and more accessible ways.

What 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

On the backend, where the frontend communicates, there is a service-oriented architecture structure. In the next stages of the project, microservice structures are planned for the backend part. As it can be seen in the figure, the frontend part only communicates with the Core API which is developed with the Django Framework. Frontend requests go to Core API first, then requests to other services are made from here and responses are received. These responses are sent back to the frontend via the Core API. If the incoming requests are directly related to MDG, they go to the oData API, while the requests related to the chatbot go to the Chatbot API which are developed with the RASA Framework. For the transactions to be made in our SAP system, the system is reached via the oData API, and the requested transactions are carried out.

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.

To begin with, the aim of using Change Request API is, fetching data of a given change request number. Through read_crequest method, developers are eligible to see the details of the change request.

Moreover, the Governance API was a reasonable selection for processing change requests. Firstly, the give API brings about dynamic programming at ABAP phase. The create_data_reference method of the API is a useful tool for it. The import parameter of the method should be ‘Material’, both key and data will be returned. Secondly, the API provides tools for fetching material information, including notes which can be written for a change request. Methods for both writing a new note(write_note) and getting notes of a change request(get_notes) are included in this API. Finally, processes of a change request should be done in a specific order, otherwise programs would return error and that may lead to hinder using the application. Whereas methods both enqueue_entity and dequeue_entity help for overcoming those circumstances. The first method is used for putting the change request in a queue, the second method on the other hand dequeues from the order, when changes are done to the change request. When the change request is edited, users must save changes, otherwise users may not see changes at the change request. As a solution, the API contains a save method.

As it can be seen, the backend side does not consist of two APIs. Furthermore, Convenience API has a huge role in the system. For instance, if a material should be created in the application, the given API is used.

Apart from MDG APIs, SAP Gateway API has also the allotment in the backend side. The referred API is used in three different sections. As a beginning, the API should be used for developing a create_deep_entity method, which refers to nested structures of entities in oData. Moreover, according to the options that user might select in the app, an execute_action method should be implemented in oData. The method returns message according to the choice that user makes. Ultimately, a get_expanded_entity method was taken into consideration for fetching data of nested structured entities. To illustrate, all the methods belong to the SAP Gateway API.

For giving proper consequences to users, also classes are used. Since all change requests in an SAP system have workitems, agents and workflow steps, a class should be used regarding workflows, since change requests work according to the unique design of their workflows. For discovering what happened to the change request, workitems should be fetched. Hence a function called SAP_WAPI_GET_DEPENDENT_WIS is used for fetching work items of a change request. Additionally, for reading what a workitem includes, the SAP_WAPI_READ_CONTAINER should be called. In the second place, agents of a change request represent who is authorized to proceed with it. Therefore, the service class for workflow has “get_cr_wf_processors” method for it. Ultimately, every change request has at least two steps options for completing the process positively or negatively. For example, activation or rejection of a change request. For that reason, the class has a method get_crequest_step for reaching to steps of a change request.

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.