CRM One Order Model Redesign in S/4HANA for Customer Management 1.0 – Part 1
In my previous blog S/4HANA for Customer Management 1.0 introduction from technical point of view I give you an overall introduction about this new offering. As in this blog, I will share some more detail regarding One Order Model redesign in S/4HANA for Customer Management 1.0.
The redesign project is led by SAP CRM Chief Architect Scheuch Carsten, who has almost 20 years experience on SAP CRM and is well respected by all CRM developers distributed in different sites within SAP. I really learned a lot by working with him side by side for three months last year.
This blog consists of three parts:
- Why the One Order Model needs redesign in S/4HANA?
- Short review on One Order model in SAP CRM
- New Model in S/4HANA – persistence design
Why the One Order Model needs redesign in S/4HANA?
The One Order model in SAP CRM has proven a very successful, convincing and stable basis for SAP CRM transactions for many years. It is easily extensible, and developing new data sets or features can be accomplished in an add-on style, keeping the influence on existing logic at a minimum.
When the CRM transactions on top of such models moves to S/4HANA world, new requirement arises especially on analytical, reporting or search capabilities. All of these requirement must ultimately fulfill one goal: scan high volume of transactions and extract either aggregated figures or transactions with given attributes. Thanks to HANA, now it is possible to run transactional and analytical applications on the same data basis, even in the same application.
In current One Order Model transaction data is distributed over many tables, which makes multiple joins necessary and sometimes even unavoidable of the name/value style tables inclusion. This will deteriorate the performance of analytics application.
As a remedy, the index table CRMD_ORDER_INDEX was introduced from the very beginning of CRM, into which the most important attributes from transaction data storage tables are replicated as a FLAT table. The analytics processing gets accelerated at the cost of some additionally duplicated storage.
Now with the move to S/4HANA world, it is the best timing to redefine One Order persistence model in such a way that the primary database tables behave well for analytical applications, and that the use of CRMD_ORDER_INDEX is no longer necessary.
Short review on One Order model in SAP CRM
One Order model consists of “segments” with different types highlighted with different colors below.
1. ORDERADM_H and ORDERADM_I: as the name ADM indicates, these two nodes contain ADMinistrative data for Header and Item level.
2. SERVICE_H, PRODUCT_I( orange color below ): Extensions are data segments which EXCLUSIVELY belong to a header or to an item, distinguished by post-fix H or I. Cardinality to header or item is 1:n.
3. SHIPPING, PARTNER( blue color below ): A set is a collection of data which can be linked EITHER to a header OR to an item at the same time. Taking SHIPPING for example, it makes sense for an order to maintain different shipping data on both header and item level.
How CRMD_LINK works in SAP CRM
Each segment introduced above is usually represented by one database table (naming convention: CRMD_<segment>). Some segments might have more than one.
For extensions, the table design is pretty easy: just use the guid of ORDERADM_H( ORDERADM_I ) as primary key of header( item ) extension persistence table.
For set, since it might be used for either header or item, so the persistence table design for set is a little bit tricky compared with extension.
Taking SHIPPING set for example, the connection between ORDERADM_H and SHIPPING is established by CRMD_LINK, the primary key of CRMD_ORDERADM_H and CRMD_SHIPPING are stored in field of GUID_HI and GUID_SET separately.
New Model in S/4HANA – persistence design
Instead of having business data spread in different dedicated table, we now have two flattened tables, one for header and one for item.
Both contains include structures which consists of fields from original set like ORGMAN, PARTNER etc, and header flat table CRMS4D_SERV_H contains fields from original header extension, and item flat table CRMS4D_SERV_I contains fields from original item extension accordingly.
The original table for each segment for example CRMD_ORDERADM_H, CRMD_OPPORT_H etc will remain there but will NOT be used by any application AT ALL. Neither are any data stored there.
Have a look at new package which contains some important table for new model control.
In version 1.0 only a subset of Sales & Service transactions are supported, for example service order, service request and service confirmation. The header level business data of these three transactions are stored in above mentioned table CRMS4D_SERV_H. In later release more transactions will be introduced.
How about the table name for these new transactions? It’s determined by API CL_CRMS4_ACRONYM_CB=>GET_TABLE_NAME.
In new model design the database table has naming convention CRMS4D_<acronym>_H[I] where acronym has 1:1 relationship with object type, maintained in table CRMS4C_ACRONYM.
Shadow table CRMS4D_BTX_H
In SAP CRM if we have a order ID and would like to know its guid, we simply select guid from CRMD_ORDERADM_H using order id and order process type, as orders with different order type might have the same ID.
In S/4HANA for Customer Management this is NOT possible, since CRMD_ORDERADM_H becomes obsolete. And only order ID is available, it is not known whether it is a service document or an activity or whatever else, so we don’t know which table should be used for query, CRMS4D_SERV_H, CRMS4D_ACTV_H or CRMDS4D_<acronym>_H.
The shadow table CRMS4D_BTX_H comes on the stage: it stores order guid, object ID and object type. With object type, the corresponding database table is then available by calling API CL_CRMS4_ACRONYM_CB=>GET_TABLE_NAME mentioned before.
You may consider it as “reduced version” of CRMD_ORDERADM_H, representing a bridge between the old GUID based world and the new database design.
How Order read works under new model
The processing logic of One Order framework is divided into three layers. Each component is equipped with corresponding function groups CRM_<component>_xx, where xx is the layer acronym: OB, OW or DB.
- OW = Object Workarea: treats the current record that is processed by the API.
- OB = Object Buffer: holds the most recent state of the document in the current transaction.
- DB = Database Buffer: holds the current database image of the transaction.
Take OPPORT_H for example:
It’s better that you have some understanding about how these three layers orchestrate for Order read & write scenario as prerequisite knowledge before you deep into One order in S/4HANA world. You might refer to my blog Buffer logic in One Order header extension Read for some illustration. In the end of that blog I provide some links which also contains my blogs regarding One order change, create and save scenario.
The basic idea is: with the goal that all three layers( including event handler and callback functions invoked) shall work as before, it is only necessary to INJECT some new code which acts as a bridge to connect the new model in S/4 world with the old function modules in three layers.
Let’s use a real case for illustration. Suppose I would like to read the item and partner data of this service order.
The implementation is almost exactly the same as you would code in CRM, except the necessity to use shadow table CRMS4D_BTX_H instead of CRMD_ORDERADM_H.
REPORT zcrms4_order_read.
DATA: lt_guid TYPE crmt_object_guid_tab,
lt_product_i TYPE crmt_product_i_wrkt,
lt_partner TYPE crmt_partner_external_wrkt.
SELECT SINGLE guid INTO @DATA(lv_guid) FROM crms4d_btx_h WHERE object_id = '8000494705'.
CHECK sy-subrc = 0.
APPEND lv_guid TO lt_guid.
CALL FUNCTION 'CRM_ORDER_READ'
EXPORTING
it_header_guid = lt_guid
IMPORTING
et_product_i = lt_product_i
et_partner = lt_partner.Let’s first have a look at what exactly the “injected” code is. We create a new function group for segment BTX_H in DB layer, that is CRMS4_BTX_H_DB. Have a look at CRMS4_BTX_H_READ_DB.
This function module will read header data from corresponding header flat table CRMS4D_<acronym>_H and then call function module CRMS4_BTX_H_PUT_TO_DB_BUFFER, which does the trick.
The importing parameter is_header_db has a generic type ANY because it is filled with data read from corresponding table CRMS4D_<acronym>_H in the runtime.
Within this function module, the following logic has been implemented:
1. get all allowed segments belonging to current process type via function module CRMS4_ORDER_OBJECTS_ALLOWED_CB
2. loop all these allowed segments, call the corresponding PUT_DB function module of each to insert the dedicated data into database layer.
In order to avoid the lengthy code as below:
We introduce the concept of converter class – each segment has its own converter class by implementing the defined interface IF_CRMS4_BTX_DATA_MODEL where the dedicated PUT_DB function module is called.
The method name CONVERT_S4_TO_1O gives you a hint that it is responsible to put the data fetched from S/4HANA new persistence table CRMS4D_<acronym>_H to the classical One order DB buffer.
Relationship between segment name and its mapping class name is maintained in table CRMS4C_BTX_CONV.
When and where these new logic will be injected?
Debug the simple report zcrms4_order_read to unveil the mystery. Just set a breakpoint on CRMS4_BTX_H_PUT_TO_DB_BUFFER and observe when and where it is called.
I highlight some important callstacks as below.
CRM_ORDER_READ calls CRM_ORDERADM_H_READ_DB, this is exactly the same as in SAP CRM. The injection of new logic is done in callstack 11: now we read data from CRMS4D_<acronym>_H, and then call CRMS4_BTX_H_PUT_TO_DB_BUFFER to split the data with flat structure into each segment’s database buffer by calling CONVERT_S4_TO_1O method of their converter class.
Since now database buffer for each segment is filled, the subsequent call for database buffer READ will hit the buffer.
See the comparison between S/4HANA for Customer Management and SAP CRM. The injection is clearly displayed in the highlighted area in the left area.
All the left handling for read scenario remains unchanged compared with the logic in SAP CRM.
How about it you would like to direct access the object buffer of a segment by calling its read function module instead of CRM_ORDER_READ?
Here below is the diagram for CRM_OPPORT_H_READ_OB in SAP CRM:
Here below is counterpart in S/4HANA for Customer Management:
Hope this blog can help you understand the adaptation of One Order Model in S/4HANA. In my next blog we will explore how One Order write scenario works under this new model. Stay Tuned!
Jerry’s other blogs on S/4HANA for Customer Management
- S/4HANA for Customer Management 1.0 introduction from technical point of view
- CRM One Order Model Redesign in S/4HANA for Customer Management 1.0 – Part 1
- CRM One Order Model Redesign in S/4HANA for Customer Management 1.0 – Part 2
- Create Mass Products by code in S/4HANA for Customer Management
- Create Mass Service document in S/4HANA for Customer Management
- One order extensibility in S4HANA for Customer Management
Excellent information Jerry, thank you.
Hello Jerry,
Excellent Blog!
Could you please let me know if the current "CRM Sales" scenario like Sales Order would also be part of S/4 HANA Customer Engagement?
Thansk and regards, Krish
Hello Krish,
The original Sales Order ( tcode VA01 ) will still be used in S/4HANA. The Lead & Opportunity in SAP CRM will be part of Sales core in S/4HANA for Customer Management, as defined in the official roadmap.
Best regards,
Jerry
Hi Jerry,
Very informative blog.
is there any changes in the WEBUI BSP components framework, is TX: bsp_wd_cmpwb works as in on premise?
Thanks
Sushant
Hi Sushant,
From application developer point of view, the workbench BSP_WD_CMPWB works exactly the same as before 🙂 My WebClient UI framework colleagues did some excellent job so now the style of WebUI looks like as a Fiori application, which then has a consistent look-and-feel with other S/4HANA Fiori applications.
Best regards,
Jerry
Very good question!
I am very interested in that, too, as I was a little bit baffled to see WebClient Framework being reused on S4.
My assumption are:
I am eager to see how Transaction Launcher and Document Templates (Word and PDF) are included in future releases of S4CM. Bigger adjustments might be necessary.
cheers Carsten
Hi Carsten,
In S/4HANA for Customer Management, the WebClient UI just uses a new theme called Belize delivered by SAP, whose detail could be found from this url in SAP help.
The navigation from CRM WebUI to S/4HANA Fiori UI itself is done by transaction launcher in CRM.
For example, once the hyperlink of product ID in Service Order line item is clicked, the Fiori application of product master management in S/4HANA will be launched:
Best regards,
Jerry
Hi Jerry,
Do you have any posts related to transaction launcher configuration? I made the same steps like in CRM but is not working.
I'm trying to link an ERP transaction.
Best regards
Hi Jerry!
Wow! Excellent contribution! I really appreciate the effort you put into the details of the blog. Especially the images are very good to comprehend what is actually going on. Well done!
For OneOrder, or however it is called from now on, I got a good and clear picture. In my opinion the apporach feels quite sound. From an application point of view there really will not be changing much (only for OneOrder).
So much for the positive and encouraging part. Now again for some questions that I would be glad if you would answer on.
OneOrder via CRM_ORDER_xxx is quite straight forward. The BT GenIL works completely on both function modules. For single transaction handling that is very good. Now we do have other scenarios in CRM that invoke the CRM_ORDER_xxx modules.
In current on premise there is, nearly always, an CRM_ORDER_READ invoked for every result returned. To read additional data or do authorization checks. Is this still in place with S4CM?
On most of the projects I have been there was an issue with performance in OneOrder queries. In 90% of the time the problem was not searching for the correct entries, but retrieving the information for the result set. Do you know if this is optimized with S4CM?
As put above I am very considered about the performance we can expect from that. Doing a SELECT SINGLE on a CDS view to put the information in CRM_ORDER_xxx buffer does not seem very clever for mass data. How does the CRM_ORDER_READ work if I put like 100 GUIDs into it at once? Maybe you could do a test with an SQL trace.
Is it still necessary to call CRM_ORDER_INITIALIZE very frequently when working with a large number of transactions? With > 100.000 entries in the buffer I experienced the biggest performance impacts from ABAP not database.
I saw your blog on CRM_ORDER_MAINTAIN, suppose I put my question on performance for update scenarios there 😉
Keep on the good work. You keep writing those blogs faster then I can comprehend and comment on the information 🙂
cheers Carsten
Hello Carsten,
First of all thanks a lot for your time and reading! You questions here will definitely help other customers & partners who will choose to S4CRM soon, I firmly believe.
Most of your questions you point out above belong to the analytics topic, and currently there are a dedicated team in SAP who are working on it. I am not very clear about the details, I would share them out once I build up my knowledge gap first 🙂
Best regards,
Jerry
Hi Jerry!
Yes, you are correct. I am working as a SAP CRM consultant and of course I am interested in the benefits the new S4CRM brings for my customers and what challenges are to be expected. To be honest: Currently I see many challenges and very few benefits for existing SAP CRM customers. Of course for businesses not running SAP CRM this is a different story.
Most customers are quite consent with what SAP CRM delivers from an application perspective. What nearly all of them have in common is performance issues and browser incompatibility.
Judging from your blogs and your history I am very positive you can find out the answers to all questions that I have. However, it is too much to ask! Your sharing in such an early phase is more than I had hoped for!
I hope that some of your colleagues from the other teams read my questions and would like to jump in. So please do not feel pressured by me 🙂
cheers Carsten
Hi Jerry,
I have recently done upgradation project to EHP1 to EHP4, SAP has introduced BBPCRM and CRM_PLUS components. Some of the function modules/data dictionary objects have been deleted and changed. I read it is done keeping in mind of future enhancements.
In S4 CRM , has this changes have accommodated as in EHP4? or future EHP release will follow seperate path?
Thanks
Sushant
Hi Sushant,
Regarding your question In S4 CRM , has this changes have accommodated as in EHP4? or future EHP release will follow seperate path?
I have checked with responsible colleague today and the answer is: yes, the changes from EhP4 are also there in S4CRM.
the background is: With EhP4, we have done the resolution of the object clashes with ERP, i.e., we have isolated technically identical objects in CRM_PLUS and renamed objects which had different versions in CRM and ERP, so that the object list of ERP and CRM were completely disjoint in the end. Without these changes, S4CRM would not have been possible! 🙂
Best regards,
Jerry
Hi Jeery,
Quick query here,does the CRM_ORDER_MAINTAIN & CRM_ORDER_READ are extended with S4CM Tables CRMS4D_SERV_H etc..
Thanks,
Syam
Hi Jerry,
Thank you so much for this series of blogs on Cm 1.0!
Could you please clarify on IBase in CM 1.0? Do we have same old structure or is it replaced with something new?
Many Thanks,
Sagar Patel
Hi Jerry,
It is known that a new release will be launched on September with some functionality related to Sales. So, now I ´m working with the first release but still have some doubts about the fusion of S4 and CRM world as following:
Thank you a lot for your help
Hi
If TREX is out of the scope what replaced it in S4CRM?, currently I ´m working with Knowledge article creating the in S4CRM but how can I index the in order for searching ?
Thank you
Great read!
Here are my current conclusions :
What I don't understand is how configuration and extensions work together with table flattening. e.g. I can see one field for every main standard partner function in the table. If I introduce different partner functions or create new custom partner functions for some transaction/item type - where will they be stored. All real world customer implementations I have seen use tons of custom partner functions. If they will be stored in different table, that basically nullifies effect of flattening as you would still have to take this into account in reporting. If they will be stored in the same table by creating additional fields in the table through some framework, then that makes the design dangerous in terms that for some customers it might introduce very wide tables, that could break limits of HANA db in some cases.
Excellent Blog Jerry - just like all your Blogs! 🙂
Thanks a lot!
I am about to create Fiori Apps for Service Handling in the Public Transport Area on top of S4CRM Data Model (Custom made Application) - very helpful infos!