SAP One Domain Model – the lingua franca of the integrated intelligent suite
In this blog post I’ll explain to you how SAP will be using the SAP One Domain Model as the one language – the lingua franca – of the integrated intelligent suite. You’ll learn where SAP One Domain Model is already been used and get some basic understanding on the technical concept behind it.
SAP’S CLOUD INTEGRATION STRATEGY
Recently, SAP provided the SAP Cloud Integration Strategy: a comprehensive overview on how SAP will provide an integrated intelligent suite across its portfolio of solutions. SAP’s CEO Christian Klein also provided a blog post explaining SAP’s way forward around the integration in the cloud.
This suite will support end-to-end business processes like:
- Recruit to Retire (Understand, manage and optimize all aspects of your employees and external workers)
- Lead to Cash (Manage all aspects of the customer experience)
- Source to Pay (Manage all purchasing processes)
- Design to Operate (Create a digital mirror of your entire supply chain – from design to planning, manufacturing, logistics and ongoing maintenance)
You can get a more detailed look into these processes on the API Business Hub page for SAP’s reference business processes.
Figure 1 – Process flow for “Hire to Retire” subprocess on API Business Hub
COMMON SUITE QUALITIES
To facilitate a seamless integration across the suite, SAP defined a set of common suite qualities:
- Seamless user experience – harmonized look & feel and navigation patterns
- One workflow inbox – central task management
- End-to-end process blueprints – implementable reference architectures
- Consistent security & identity management – central identity provisioning & authentication
- Coordinated lifecycle management – harmonized provisioning, setup & operations
- Embedded & cross-product analytics – holistic 360° business and customer view
- Aligned domain models – aligned business objects across applications
I want to provide you now with some details on how SAP will deliver the aligned domain models.
SAP ONE DOMAIN MODEL
The SAP One Domain Model focuses on the end-to-end Intelligent Enterprise business processes mentioned above. With SAP One Domain Model the SAP applications can synchronize business objects with common attributes and use common semantics. Such objects are e.g. a workforce person (employee, contingent/external worker) or a cost center.
Figure 2 – Recruit to Retire business process: SAP solutions using aligned domain models for “Workforce Person” and “Cost Center”
These SAP applications map their representation of one or more of such domains to the corresponding entities of SAP One Domain Model.
So, by using SAP One Domain Model as the lingua franca for understanding business objects (e.g. like a cost center), customers no longer need to implement their own replication or integration solution between SAP solutions for having the same semantic understanding of a business object.
SAP takes care of that semantic harmonization with SAP One Domain Model, applying the principles of Domain Driven Design that my colleague Juergen Heymann explains more in detail in his blog post SAP’s One Domain Model and Domain Driven Design.
Definition with CDS
SAP defines each business object in the Core Data Services (CDS) format. This format is used e.g. in SAP HANA , SAP S/4HANA Cloud, the ABAP RESTful Application Programming Modell (RAP) and the SAP Cloud Application Programming Model (CAP) for describing data models as well.
Moving forward, SAP will also make SAP One Domain Model available via the SAP API Business Hub. This is specifically interesting for customers who want to extend those models with their own custom attributes. I will be writing a separate blog post that explains in more detail how this works.
Figure 3 – Data model of a “Product” in the CDS format
By introducing SAP One Domain Model as the common data model for all business objects in the Intelligent Enterprise, it becomes much easier to share business objects like a customer or an employee across the complete suite, as each solution is using the same semantic specification for those business objects. The SAP solutions automatically map the data model for a business object within an SAP solution to the corresponding SAP One Domain Model representation of that business object.
WHERE SAP ONE DOMAIN MODEL IS USED
SAP One Domain Model will become the lingua franca used by the business applications of the integrated intelligent suite to semantically understand business objects in a uniform way.
This common language is already used today for the Recruit-to-Retire business process for the business objects
- Workforce person
- Cost center
Meaning that customers with SAP S/4HANA Cloud and SAP SuccessFactors can already take advantage of a built-in integration between those two SAP solutions for the two business objects Workforce Person and Cost Center. As outlined in the SAP Cloud Integration strategy, more business objects will be delivered in 2020 and beyond via SAP One Domain Model.
Each aligned domain model translates into reduced SAP-to-SAP integration efforts for customers.
Developers will also be able to take advantage of the SAP One Domain Model via SAP Graph (currently in technology preview phase). SAP Graph exposes an API for accessing SAP-managed data, using SAP One Domain Model as the data modelling language. You can try it out already today in the API Explorer of SAP Graph. There is also a blog post available about the development of SAP Graph and the upcoming availability of the SAP Graph API sandbox preview.
Figure 4 – The API Explorer in SAP Graph
WHAT COMES NEXT?
Within the next months you will see additional business objects provided by SAP One Domain Model, which will make the business processes run more and more seamlessly across the borders of SAP solutions. This results in reduced SAP-to-SAP integration efforts.
Stay tuned for more information about how the SAP One Domain Model is and will be used across SAP solutions. This will come along also with some more technical depth for developers.
Thanks for sharing detailed information about ODM.
Thanks Syam. Stay tuned for more.
nice overview on the ODM. It would be interesting how the ODM fits into the bigger picture of the Open Data Initiative that SAP is part of.
Hi Christian, I'll find out the current status and provide an answer to you Christian as a comment in this thread.
Did you find an answer on this question?
Is this the beginning of the end of pre-packaged contents for SAP-SAP integration in Cloud Platform Integration?
Hi Murali, the short answer is "No".
I'll provide more insights into the bigger picture and the connection to SAP Cloud Platform Integration in my next blog posts around the topic of aligned domain models for the integrated intelligent suite.
But your question is very relevant and I'll address it in my next blog post(s).
Just give me a few more days :-).
Hi Murali, hope my new blog post on SAP Cloud Platform Master Data Integration provides you with some answers to your questions above.
Rui Nogueira Now that’s great news! Much looking forward to the full blog “series”!
Is there also documentation about the ODM Meta-Model? The structural aspects are quite clear, but what about behavioral entities (e. g. status & action models)?
Hi Oliver, as some other comments here you are bringing-up the right questions derived from the availability of the SAP One Domain Model.
A good starting point for specific object meta data of the SAP One Domain Model is SAP Graph and the API Sandbox (https://beta.graph.sap/explorer). You can see there all the objects that SAP is already working on today.
If you are looking more into the way how the business objects are synchronized accross the borders of an SAP solution, you can get more details from the blog post I'm preparing.
Is there an option to explicitly query the metadata via the graph-API? Appending `?$metadata` doesn't do the trick.
Looking much forward to reading your next post then!
Hi Oliver, checkout my blog post at
https://blogs.sap.com/2020/07/21/sap-cloud-platform-master-data-integration-sharing-and-synchronizing-master-data-in-the-integrated-intelligent-suite that should give you some more insights.
Hope it helps.
Thanks for sharing the explanation for this, Rui!
SAP One Domain Model is a real game-changer for effortless cross-SAP integrations. Glad to see it's moving forward.
On the other side, I concern as Master Data Integration Service for workforce, leveraging SAP One Domain Model, creates an additional cloud persistence layer for employee data. – In general case, we can have an employee with 3 different data/states in one moment of time: in SF, MDI, S4, with 2 scheduled synchronization jobs between – that not adds coherency in the global data view.
I hope, the future cross-SAP integration direction – is a Hasso Plattner’s view of single persistence of determined data entity – in source HANA base- and virtual online access to this data from other solutions and services.
Is there a chance that SAP One Domain Model will work in the future natively for Cloud or as a virtual proxy without the persistence layer?
I stumbled on your question just now and will try answer from the ODM perspective. My answer is general and not really dependent on MDI or any specific technology:
In distributed systems you need data replication for resilience and performance. With distribution / replication there is always a little delay and there can be a lot more when you take network problems into account. For an in-depth discussion check out the "CAP theorem". The alternative that all processes shared one HANA instance as shared persistence could only work for small clusters. And again, this is less resilient.
Replication is necessary and this is the same as it was before. With MDI it just gets better that we have one common replication channel with one configuration, monitoring etc. as opposed to many point-to-point connections, possibly each with mappings in between.
So the bottom line is: MDI as a replication middleware is the right direction.
Juergen (ODM lead architect)
Hi Vasily, the answers to your questions would become too long to add them as an answer to this blog post. Please give me some more time to finish my next blog post where I'll try to address all your questions properly. Will provide a link to the blog post here, once I've finished it.
The blog post will go into details how the various SAP solutions synchronize their business objects so that the solutions act as a suite.
Here you go Vasily. Hope the blog post help you to address some of your questions.
thank you for this first insight into the One Domain Model. Can you let me know if SAP By Design and SAP Business One will also be included in this approach?
Hi Gregor, SAP is supporting first the end-2-end business processes outlined in the strategy paper from Christian Klein that I've mentioned in the blog post. So the focus is not too much on the specific products. In which business scenario are you most interested?
We can also have a quick chat via phone if you want.
Hi Rui Nogueira
Thanks for the above update and progress to ODM.
Figure 1 looks like it was produced by either PowerDesigner or Enterprise Architecture Designer. Is the One Domain Model available as a PowerDesigner model?
figure 1 shows the process flow for the hire-to-retire scenario. Also describing this more in detail in my blog post around business processes in the integrated intelligent suite.
The SAP One Domain Model is providing the domain models in the Core Data Services format.
The models were produced with EA Designer and published in API Hub.
The One Domain Model does not have EA Designer model yet.
are the CDS models/types from Figure 3 public available in a git repo for usage in custom VSC projects on top of ODM models.
For example, i would like to use the Products.cds for an PoC.
Or will it later be part of @sap/odm (currently lacks Product)?
Could you please help me the reference where we can able to see details of converting existing Hybris model to "One Domain Model" OR SAP ERP i-Docs to "One Domain Model"?
It will help us more to visualized conversion from existing model to "One Domain Model".
Hi Ram, I've reached out to the colleagues from product management who are currently responsible for ODM. They'll respond in this thread.
The conversion from an internal / existing model (e.g. IDoc) to an ODM model happens within the application that reads / writes this object and it is different for each application.
What are you trying to do, what exactly do you need?
Juergen (ODM lead architect)
Thank you Rui, Juergen for quick reply,
Trying to understand the low level of conversion from existing point to point integration to ODM based architecture integration.
Basically looking for an example reference documents where i can refer the list of existing model(from point to point integration) to a ODM and how the ODM life cycle is going to be maintained in new common model approach.
let's say on example in Hybris, some of the use case we are using entity cache for specific item only(materials), in ODM approach since we have a common model(huge attributes) so how we can cache part of some of the attributes in new approach etc.
(Sorry for the late reply.)
The switch from a point-to-point to a hub-based integration, especially for master data, is quite involved. We are working on this intensely internally at SAP, at first using MDI for master data replication. To make the approaches work out-of-the-box also for customer landscapes will require some more time. A document 'how to migrate to MDI' is not ready yet.
Are you from Hybris? Then contact me internally and we can some directions we can give now. If this is a customer case, I am afraid you can only use the MDI documentation to see how to use the data available in the MDI.
Thank you Juergen,
Yes i'm from Hybris, actually for now not any real time customer use case however i'm going through documentation for one of the certification preparation and ODM look great strategy to me so trying to see possible scenario which we can handle via new Model approach.
Thank you for update.