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.
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 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 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.