SAP offers RISE with SAP to enable customers in becoming Intelligent and Sustainable Enterprises (IES). RISE with SAP offers customers a flexible solution combining Cloud ERP, Industry best practices, Analytics and more, under a single contract.
Behind the scenes, SAP’s powering technology is responsible for making this happen. In this blog, I would like to share about the technology responsible for gluing together the different SAP solutions into a whole being greater than the sum of its parts.
You might have heard about Desired state repository, it is a method of using API calls in a unified and centric way, it simplifies the activation of Micro-Services which are designed to serve different requests from different users. One of the important principles of this concept is a declarative programming paradigm, in which the user declares what the desired state is for him and the various services work to achieve it. This concept is well known in Kubernetes and other cloud providers.
Why is using a desired state repository worthwhile? Traditionally app developers need access to every API to make changes and consume services. Using APIs requires time to learn, understand, and plan since every API is different and might behave differently. For instance, input from a user can be processed instantly or be save for later. If services require a similar input, the user will have to provide it again and separately for every service provider. In addition, if a service would like to access data of a different service it would require integration to extract the data and copy it to a different location.
The current approach requires to deal with the working with different APIs- connecting, securing and saving data, transferring data between APIs and more. This is the reason a different approach is required, offering a simple integration process between two services. Providing a holistic solution for integrating solutions can significantly improve the ability to interact with new solutions, expand existing solutions and thus save valuable development time and resources.
How can it be done differently? First of all, by centralizing and unifying the APIs. This means all requests can be received in a centralized and common way (uniform API contract) and not in the way that each Service defines its API.
The second step is a paradigm shift - moving from consuming services to working with a declarative programming paradigm. The declarative paradigm is very important because it can simplify the development process. With this method, the developer is not required to know and program all the actions that need to be performed to reach a certain desired state (in the past this required familiarization and usage of many APIs), but he/she is only required to describe the desired state and hence the system works to provide it in the best possible way.
For example, a developer wants to develop a service that would be able to make the following steps:
1. Create a new account.
2. Create a primary user for the account.
3. Provide service ‘A’ to the account.
4. Provide service ‘B’ to the account.
5. Update the account with the services provided.
Imperative paradigm example:
Declarative paradigm example:
We built a desired state repository using declarative programming tailored for our needs to centralize and unify the APIs. The goal was to build a control plane that can address common challenges: large scale of operation, lifecycle and version management and robust privilege management. The solution was inspired by Kubernetes API server and we implemented on top a hierarchical structure of folders and additional capabilities that were required.
To conclude, the solution we built simplifies and reduces the time it takes developers to implement internal integrations and to extend existing services. The advantages provided by this solution can enable us in the future to extend the use of this solution for others.
Behind the scenes, SAP’s powering technology is responsible for making this happen. In this blog, I would like to share about the technology responsible for gluing together the different SAP solutions into a whole being greater than the sum of its parts.
You might have heard about Desired state repository, it is a method of using API calls in a unified and centric way, it simplifies the activation of Micro-Services which are designed to serve different requests from different users. One of the important principles of this concept is a declarative programming paradigm, in which the user declares what the desired state is for him and the various services work to achieve it. This concept is well known in Kubernetes and other cloud providers.
Why is using a desired state repository worthwhile? Traditionally app developers need access to every API to make changes and consume services. Using APIs requires time to learn, understand, and plan since every API is different and might behave differently. For instance, input from a user can be processed instantly or be save for later. If services require a similar input, the user will have to provide it again and separately for every service provider. In addition, if a service would like to access data of a different service it would require integration to extract the data and copy it to a different location.
The current approach requires to deal with the working with different APIs- connecting, securing and saving data, transferring data between APIs and more. This is the reason a different approach is required, offering a simple integration process between two services. Providing a holistic solution for integrating solutions can significantly improve the ability to interact with new solutions, expand existing solutions and thus save valuable development time and resources.
How can it be done differently? First of all, by centralizing and unifying the APIs. This means all requests can be received in a centralized and common way (uniform API contract) and not in the way that each Service defines its API.
The second step is a paradigm shift - moving from consuming services to working with a declarative programming paradigm. The declarative paradigm is very important because it can simplify the development process. With this method, the developer is not required to know and program all the actions that need to be performed to reach a certain desired state (in the past this required familiarization and usage of many APIs), but he/she is only required to describe the desired state and hence the system works to provide it in the best possible way.
For example, a developer wants to develop a service that would be able to make the following steps:
1. Create a new account.
2. Create a primary user for the account.
3. Provide service ‘A’ to the account.
4. Provide service ‘B’ to the account.
5. Update the account with the services provided.
Imperative paradigm example:
Imperative paradigm
Declarative paradigm example:
Declarative paradigm
We built a desired state repository using declarative programming tailored for our needs to centralize and unify the APIs. The goal was to build a control plane that can address common challenges: large scale of operation, lifecycle and version management and robust privilege management. The solution was inspired by Kubernetes API server and we implemented on top a hierarchical structure of folders and additional capabilities that were required.
To conclude, the solution we built simplifies and reduces the time it takes developers to implement internal integrations and to extend existing services. The advantages provided by this solution can enable us in the future to extend the use of this solution for others.
- SAP Managed Tags:
