Shulou(Shulou.com)06/01 Report--

How to design and implement the order model of SAP CRM system, I believe that many inexperienced people are at a loss about it. Therefore, this paper summarizes the causes and solutions of the problem. Through this article, I hope you can solve this problem.

Compared with the traditional addition, deletion, modification and query, in the field of order scheduling, for example, the "increase" of the SAP order model also needs to consider various types of pre-and post-order orders in the actual business process, that is, the term document flow (Document Flow) used by SAP.

In addition to the migration of the status of the order itself, "change" also includes a variety of executable logic provided by the order model. This logic includes not only the changes to the fields of the order model itself, but also the interaction between the order and the third-party system. In many contexts, we call this logic Action.

The following figure is shown in the lower right corner:

Since the complexity of the order model is so high, it is very important to introduce an excellent high-quality modeling method that can support enterprise-level order scheduling applications.

Looking at some random examples, how many standard order types does SAP CRM support? In the picture below, BUS2000 starts with different order types, which I haven't counted, but there are always dozens of them.

And SAP Cloud for Customer, although there are fewer Business Object under the CRM namespace than SAP CRM, the basic order model for automating the sales process is still in place.

Let's first take a look at SAP CRM's order model. Is it possible to use a set of models to describe dozens of order types supported by SAP CRM? Yes, that is the SAP CRM One Order model, and its self-describing name reflects the characteristics of the model.

Jerry has tried to figure out whether the term "One Order" comes from the official SAP or is only used internally by SAP developers.

Use the search engine to search according to the keyword One Order, and the results are almost all blogs written by Jerry. However, according to the keyword ONE ORDER, the system can still search out a lot of code.

My article Jerry's collection of 42 original articles from WebClient UI has this architectural diagram:

In terms of architecture, the One Order framework is located in the red area of the image above, including database tables, ABAP structures and the API code that operates them.

How successful is the SAP One Order framework? The search engine typed in the keyword "SAP CRM ONE ORDER" and the first search result was a blog written by Jerry. The first paragraph gives you a detailed explanation:

Despite its success, when Jerry first came into contact with One Order, he was surprised to find that there was not a more intuitive graphical interface that could show the full picture of the model. However, the shortcomings do not outweigh the shortcomings, for a framework born 20 years ago, we should not use the standards of 20 years later to demand it.

Let's imagine what different types of orders have in common. There is nothing more than that every order has a title structure and line items. Some structures, in terms of business, can appear in both the order header and line items, such as the business partner details (Involved parties), organizational structure (Organization Unit), and so on. Some fields can appear only for line items, such as product information sold (Product, Scheduled Line).

The principle of SAP One Order modeling is similar to the building blocks we played with when we were kids.

The units that make up the smallest granularity of the One Order model are structures that act as building blocks, which are viewed in the transaction code CRMC_OBJECTS.

The following figure is a list of these structures. if the SAP standard structure does not meet the needs, the customer can still create a new structure.

Then, by building blocks, we combine several structures with business relationships and jointly assign them to a certain order type, such as the order type BUS2000116 that describes the service process, which consists of the following structures:

With the models, all that is left is to implement the add, delete, modify and query operations based on these models, that is, ABAP programming.

The code implementation principle of One Order API is actually a combination of the Template pattern and the observation-publisher pattern in the design pattern.

When we learn the template model, there is a classic example that God dominates the birth, aging, sickness and death of all living beings through the template pattern.

After each of us is instantiated by our parents, we can only passively implement the four methods defined by God in the template: birth, old age, illness, and death, but we cannot change the template itself, such as changing the order of the four methods. Even Jobs had no way to add an "immortal" method to himself. It sounds cruel, but it's true.

So, what template methods are defined in the One Order framework as the God of One Order applications?

Transaction code CRMV_EVENT, specify BUS2000116, execute:

Get the following list. The first column in red is the building blocks that make up the One Order model mentioned earlier. The second blue column is a list of events that these building blocks are interested in happening to them. You can see from the figure that these event names are self-describing, such as AFTER_CREATE, BEFORE_CHANGE, BEFORE_DELETE, and so on.

The third column, the black ABAP function, is the listening function for these events.

The suffix EC of these listening functions stands for Event Callback.

With the above framework, the development work of One Order application developers becomes extremely easy:

1. Through the way of building blocks, define the One Order model needed by your own application.

two。 Implement the listening function corresponding to the events that need to be paid attention to in the model.

When will these listening functions be called? Application developers don't have to worry about it.

From this we can find that the implementation of the One Order framework transfers the programming complexity from the application developer to the framework implementation.

The implementation within the One Order framework is so complex that the length of an article cannot be explained clearly. And usually, users of the One Order framework only need to know the use of API such as CRM_ORDER_READ, CRM_ORDER_MAINTAIN and so on.

For more details, please refer to my SAP community blog:

1. Buffer logic in One Order header extension Read

Https://blogs.sap.com/2017/03/22/buffer-logic-in-one-order-header-extension-read/

2. Logic of FILL_OW function module in One Order

Https://blogs.sap.com/2017/03/22/logic-of-fill_ow-function-module-in-one-order/

3. Logic of CHANGE_OW function module in One Order

Https://blogs.sap.com/2017/03/23/logic-of-change_ow-function-module-in-one-order/

4. Logic of CREATE_OW function module in One Order

Https://blogs.sap.com/2017/03/24/logic-of-create_ow-function-module-in-one-order/

5. Logic of SAVE_EC function module in One Order

Https://blogs.sap.com/2017/03/23/logic-of-save_ec-function-module-in-one-order/

6. CHANGED_AT, HEAD_CHANGED_AT and CRM_CHANGED_AT in order header table

Https://blogs.sap.com/2017/04/27/changed_at-head_changed_at-and-crm_changed_at-in-order-header-table/

One of the API of One Order, which provides CRM_ORDER_MAINTAIN for consumers to modify operations. All the structures supported by the SAP standard appear in the parameter list as one of the input parameters:

Although this design method makes the parameter list seem a bit lengthy, on the other hand, it also has the effect of self-description, ensuring that even if API users do not read the document, just by browsing the parameters themselves, they can get a general idea of which data modifications the API supports in One Order.

This is also in line with one of the conditions mentioned in the famous API design best practices document from Google that a good API should meet: easy to learn and use, self-describing, and not easy to misunderstand.

In my other article, Hello World, S/4HANA for Customer Management 1.0, I mentioned that after some of the functions of SAP CRM were migrated to SAP S/4HANA, some of the implementations were modified, including the transformation of One Order.

Jerry is one of the three people in charge of One Order transformation design. I have shared the detailed transformation principles and implementation with the SAP community. I will only outline some core concepts here.

Https://blogs.sap.com/2018/03/02/crm-one-order-model-redesign-in-s4hana-for-customer-management-1.0-part-1/

Https://blogs.sap.com/2018/03/05/crm-one-order-model-redesign-in-s4hana-for-customer-management-1.0-part-2/

Why do you want to transform it? Because SAP CRM has moved to S/4HANA, and one of the strengths of S/4HANA is also mentioned in my colleague Zhang Sean's article on the order to collection of S/4HANA business role overview, that is, for the first time in the history of SAP, S/4HANA has realized the perfect combination of OLTP and OLAP, that is, the only data source of a system, which can meet the needs of both Transaction transactional applications and Analytics analysis phenotypic applications.

However, the previous model of SAP CRM One Order cannot match the above characteristics of S/4HANA without modification.

Before the transformation, each structure that makes up the smallest granularity of the One Order model has its own independent database table, and the naming convention is generally CRMD_ plus the structure name.

If this underlying storage model is moved to S/4HANA intact, there will be performance problems when running applications such as report statistics. In order to extract the report results, the background needs to do internal and external join operations of various database tables in storage tables with many structures. When the size of the database table involved in the join operation increases to a certain order of magnitude, the performance of the whole application is not good. Jerry also participated in the performance evaluation, and finally we decided to modify the underlying data model of One Order.

Because we have only eight months to go from research to prototype development to formal development, we chose a way with the least cost and minimal changes to the One Order framework.

First of all, we abandoned the previous practice of having one dedicated database table for each structure. in S/4HANA, there are only two tables for each order type, one for header data and the other for line item data. Fields that were previously scattered in different structural tables are now maintained in these two tables. Since all the fields are tiled in these two tables, we internally call them Flattened Table.

After the storage model is greatly simplified, we create a CDS view based on these two tables, which can be consumed by the upper report application. The simplified model after modification can meet the needs of OLAP applications in S/4HANA.

For the transformation of S/4HANA OLTP applications, in one sentence, we adopt the adapter pattern (Adapter) in the design pattern and introduce a miniature middleware between API and the simplified database table to play the role of Adapter.

When consumers read through One Order API, the middleware is responsible for restoring the data stored in the simplified data table and filling it into the cache of the upper layer of One Order API. For the latter, it is unaware of the changes in the underlying storage model, because Adapter encapsulates the logic of underlying data reading and converts the format, so the upper layer of One Order API does not need to make any changes and can function as normally as it does in SAP CRM.

When consumers call One Order API for write operation, before the data stored in the cache corresponding to each structure is persisted to the database, Adapter is also responsible for merging the data scattered in different cache structures, and then writing the merged structure to the flat table.

After talking about the design of the CRM One Order order model, let's take a brief look at the order model design of SAP Cloud for Customer.

Although the background of SAP Cloud for Customer is not visible to customers and Partners, we can still get some design information about its order model from legitimate sources.

Https://archive.sap.com/discussions/thread/3602400

From the reply from this SAP employee in the SAP community, we know that ESF2 and BOPF have many similarities and similar design concepts, but ESF2 is mainly used for products deployed in the cloud, such as the development of Business Object on SAP Cloud for Customer, while the latter mainly serves On Premises solutions such as S/4HANA.

Because Jerry can't show you the interface of C4C background ESF2, I chose BOPF, the Business Object development framework that shows S/4HANA, because as mentioned earlier, the two are very similar in many ways.

Like the SAP CRM One Order framework introduced earlier, the order model implemented through BOPF is also composed of several structures by building blocks, as shown in the red highlighted area above, and each structure has its own exclusive storage database table. On the other hand, the event listening function of each structure in SAP CRM One Order adopts the traditional process-oriented function implementation of ABAP, while BOPF adopts the ABAP class that implements the specified interface. The two principles are the same, but the implementation details are different.

Although the order model of SAP C4C is the same as the traditional One Order model of SAP CRM, each structure has its own database table, but there are no performance problems when running the report program. how do you do this?

The answer is to use TREX, a repository optimized for read-only reporting applications. In other words, SAP C4C uses two different storage systems for transaction and report processing, unlike S/4HANA.

SAP Cloud for Customer's order model is visible to customers and Partners in Cloud Application Studio, and people who are interested can check it out on their own.

After reading the above, have you mastered how to design and implement the order model of SAP CRM system? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.