SAP One Domain Model – powering microservices architectures

The 1^st challenge comes with the name ….microservices.

How ‘micro’ should be the service to implement?

I don’t plan to answer this or neither start discussions around nano, micro or macro services, or what exactly should be consider a microservice, I leave this discussions to other forums, I want look how application architecture patterns are being discussed and adopted by customers, microservices and agile development go hand in hand, and customers are demanding to SAP to provide ways for them to do this when extend SAP solutions.

Microservices architectures are not new, but they have received a very important push with cloud adoption, PaaS and SaaS solutions. Typically cloud native solutions are being developed using microservices architecture patterns, applications are decomposed by business capabilities or decomposed by domains or sometimes just being decomposed due to technical decisions (not the best choice).

Customers are looking to adopt microservices architectures for developing and extend their solutions as a way to gain flexibility and agility to develop new applications to attend business needs or support new business models.

What customers are looking for …

Be able to develop microservices to be exposed as API’s or develop just simple point to point API’s to be consumed as need, and be able to scale when need. This is mostly what customers are looking for. The microservices need to be as simple as possible and reusable. Some customers are already making available API catalogs and “forcing” the internal and external development teams to adopt and consume the API’s published in their projects.

Customers and partners are building applications that use APIs as major building blocks. The IT industry is rapidly converging towards an API economy.

With this approach they are also able to implement a governance model in the integrations, deal also with the security associated with the exposition of their business data. With an API layer they are able to implement access policies and control the applications that consume the data. It will be the first step for api monetization – (internally or externally).

The challenges are …

How to implement and abstract the complexity of their backend ecosystem.
How to implement and ensure the stability of the API’s model exposed.
How to implement without having to deal with hundreds’ of integrations with the different applications.
How to implement dealign with a huge “backward compatible” (legacy).
How implement this with a aceptable TCO.

Having integration middleware solutions and API management tools, help and are needed to implement an API architecture, but it does not remove the complexity of dealing with a high number of point to point integrations with several SAP backend systems. Being able to handle request routing, API composition, authentication, protocol translation, rate limit, caching, metrics collection or request logging are just a part of the story.

When is comes to SAP solutions, we all know that the data models and the number of different solutions, to support end-to-end business processes, are also a challenge to support customers vision of implementing a more agile approach for their development strategy.

Regardless of where the data resides …

Talking about SAP ecosystems and end-2-end business processes supported by SAP Industry or LoB solutions, SAP One Domain Model is key and has a lead role, because it enables since the begin a way of accessing to SAP data from different systems, supported by SAP Graph.

SAP One Domain Model, is the aligned domain model across all domains and industries.
SAP Graph, is the simple and intuitive service API, using open standards like OData and oAuth.

SAP Graph uses routing and translation to provide app developers with seamless navigation and access to SAP-managed data, regardless of where this data resides.

When implementing an agile development strategy is important to provide simple intuitive, single APIs, single domain model, single authentication gateway, to significantly reduced the learning curve and boost the Productivity.

Access data regardless where it resides, immune from future landscape changes, same app works for different customers, on dev, staging and prod landscapes, without change and easy portability is obtained by having a Landscape abstraction.

SAP One Domain Model powers microservices architectures by enabling easy extensibility and making possible to navigate across SAP systems with powerful APIs, where a single query may cross multiple systems.

Most endorsed aspect is the expected reduction in expertise required to develop SAP extension apps, this can be seen as a productivity breakthrough.

Lets have a quick view under the hood …

SAP One Domain Model API’s are exposed using SAP Graph, based on open standards (OData v4) and in one consistent and intuitive domain model. Supports modern security solutions like Single-Sign-On authentication, oAuth, propagation of identity, support of existing roles and authorization.

OData is a standard RESTful API between clients and “services”. It provides SQL-like access to a data model: read, write, update, delete, call, filter, select, sort, page, etc., and the metadata queries support auto-discovery.

Using SAP Graph each request follows a simple but powerful syntax:

Using SAP One Domain Model API, it will be something like:

You can use the available parameters like $filter, $skip, $search, $count, $orderby, $select and $expand.

In this example for a similar GET request you can see the domains and entities, provided by SAP Graph and being part of the SAP One Domain Model.

https://sandbox.graph.sap/api/beta/sap.odm.sales/CustomerOrder

With SAP Graph is possible to define routing policy and “leading system” tenant for each entity-type in SAP One Domain Model.

SAP Graph exposes the SAP One Domain Model.

SAP Graph exposes the SAP One Domain Model and relations… which map to a diversity of native APIs, objects and models of the underlying business systems.

Each system may have its own “unique key range”… which may not match across the landscape… requiring a dedicated “key mapping” solution.

What SAP Graph has to do for the below query:

GET https://sandbox.graph.sap/api/beta/sap.odm.sales/CustomerQuote?$orderby=id & $top=1 & $filter=customer/name eq ‘Bestrun’ & $expand=items($select=product/name)

– Parse the request, determine the execution plan, and evaluate where to get the data

Find the customer-id that matches the customer name “Bestrun”
Extract the customer quotes based on the unique customer ID, and fetch the first quote
Fetch, for each of the products in the quote, the appropriate “item name” from the Product entity.

What happens at back-end systems level:

Get “id” from Sales Cloud (the leading system for “customer”)
Send the “id” to Commerce Cloud to get the first quote
Get al ll the item ids from Commerce Cloud
Commerce cloud ids don’t match S/4, if retrieves a key mapping.
Get the product names from S/4H.

If you want to know how to extend SAP One Domain Model model using the SAP CDS Graphical Modeler and SAP Business Application Studio, please read a very interesting blog post from Xiao-fei Song “Extending SAP ODM model using SAP CDS Graphical Modeler”.

Resources to visit …

For those interested in look how to explore SAP One Domain Model, check the below resources to visit:

SAP API Business Hub

Check the documentation of model and browse model structure.
Check documentation of according APIs provided by SAP Graph and SAP CP Master Data Integration.

SAP CP Master Data Integration (SAP Business Technology Platform Discovery Center)

Central synchronization for master data objects along end-to-end business processes
Consumption (CRUD) of master data objects of 3rd party / partner applications by using SAP Cloud Platform Integration adapters.

To access to SAP Master Data Integration you need to go to Business Technology Platform cockpit and activate the service to start using it.

After selecting SAP Master Data Integration service from the service Marketplace, choose create …

then you just need to select the runtime environment …

SAP Graph

Explore the consumption (CRUD) of master data objects and transactional entities of 3rd party / partner applications with direct integration with SAP Graph APIs on SAP Graph runtime (acting as a proxy).
Test the available APIs via the sandbox.

Accessing to https://explore.graph.sap/ you can test the available APIs from SAP One Domain Model via the Sandbox API Explorer.

If you want you can also test the API via an external tool like SoapUI or Postman. Below an example using Postman.

Copy the query that you want to test
Select the authentication method supported: OAuth 2.0
Copy the Token (you can get the token from here , browse the page until you find the Bearer Token in the Public Access section).

After you can test and start exploring the API and check the JSON payload.

You can also test the different query parameters. In the below example we are setting a filter to the amount.

Be sure that …

If you are an enterprise architect be sure that microservices and aligned domain data models topics will not go way from your conversations, just remember that the 4 different domains (or subsets) of TOGAF architecture principles, are Business Principles, Application Principles, Technology Principles and Data Principles. Some of the Data Principles are: Data is an Asset, Data is Shared, Data is Accessible and Common Vocabulary and Data Definitions (data is defined consistently throughout the enterprise, and the definitions are understandable and available to all users).

Maybe for this blog topic the most relevant principle is the 21st TOGAF principle: Interoperability!