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

Jerry officially launched the memorable day of SAP Customer Management for S/4HANA 1.0 on February 28th this year, and released a blog introduction in both Chinese and English.

The English version is posted on the SAP community and has been read by more than 16000 people so far:

The Chinese version, which is posted on the official account of Wechat, has more than 2, 000 views:

More than half a year has passed in the twinkling of an eye. Now how is the standard development of SAP S4CRM going? In the English blog I wrote in the SAP community, many foreign partners left messages asking all kinds of questions. Since Jerry left the S4CRM development team in April this year, I couldn't answer many questions, so I invited Frick Oliver, chief product manager of SAP S4CRM, to answer questions in the community:

This is a video of Oliver introducing S4CRM, excerpted from an article on the official recruitment account of SAP. You can see the elegant demeanor of this handsome German guy.

In today's article, I invited Song Hao, a developer of the S4CRM team of SAP Chengdu Research Institute, to introduce the creation and update of the S4CRM Service order (Service Order) designed and developed by his team. For the background introduction of Song Hao, you can refer to his previous article: a SAP consultant in the United States these years.

In Song Hao's article, Jerry also implanted some content about SAP CRM middleware and SAP Cloud for Customer, which are related to the topic of SAP Netweaver-based system integration. I hope it will be helpful to you.

Why did SAP set up a special team to do API development? The simplest four-word answer: system integration.

Another article by Jerry: SAP S4CRM vs C4C, Zhuge Liang and Zhou Yu? Have compared all aspects of these two products, the following figure "system integration" this line, is the content of this article to elaborate.

As highlighted in my picture above, SAP C4C is integrated with other systems. SAP recommends using Netweaver-based PI or HCI as middleware, while Song Hao will introduce the integration of S4CRM with other systems in detail.

The following is the text of Song Hao.

Hello, everyone. I'm Song Hao. I just joined the SAP family in June this year. I like to travel, watch horror movies and play stand-alone horror games, from biochemical crisis, zero red butterfly to evil spirit possession. Horror has always been the embellishment of my leisure time. Welcome to learn from each other.

S4CRM API is my first project at SAP, so let's start with the original intention of developing this API. The CRM market has been changing rapidly these years, and a hundred schools of thought contend. Troubled times will produce heroes, our new generation of products S4CRM can be said to be born in troubled times, shoulder the heavy responsibility.

In order to achieve the good operation of an enterprise, an efficient and stable system is essential. And CRM is an important member of this system. If a customer who has already adopted SAP S4CRM has other third-party systems, how do you ensure that S4CRM runs and interacts efficiently with these external systems? Our S4CRM API arises at the historic moment.

With the help of the S4CRM API related to the service order field developed by us, the external system can carry out a series of service process operations with S4CRM. A typical scenario is to call S4CRM API in the external system to create and modify service orders or service confirmation (Service Confirmation) and other requirements.

How can I find these API documents that we just released in November?

The browser visits help.sap.com, sees the beautiful woman, and enters the keyword S/4HANA cloud to search:

Go to the S/4HANA cloud product page and type service order-Create, Change to open our API help documentation.

You don't have to be confused about the keyword S/4HANA cloud I typed, because these API,S/4HANA On-Premise and Cloud share the same set of ABAP code implementations.

The help document details the technical name, length, and business meaning of each field in the API request and response structure. For the veteran driver of SAP, get this document and get to work.

In addition, there are more detailed documentation on the use of these API on the SAP Best Practices Explorer website.

You can browse these documents directly through the links below.

Https://rapid.sap.com/bp/scopeitems/3D2

The three most useful parts of the document:

Process flow: display the flow chart of Service Order Management and Monitoring directly in the browser:

(the picture is too big to display completely on one screen.)

* * Process flow (BPMN2): * * A file with the suffix npmn has the same content as Process flow, but is stored in BPMN format (business process modeling and markup, a modeling language standard for building business flowcharts).

Test script: a user manual in word format.

Because Test script contains detailed steps for using API, I'm not going to repeat it here, let's talk about the implementation details of S4CRM API.

Before introducing S4CRM API, let's review the message flow design of SAP CRM middleware that SAP CRM consultants are familiar with.

To illustrate with the example mentioned earlier, suppose that the external system triggers the creation of service orders on the CRM side through CRM middleware. Then from the external system sends the message to the CRM middleware, to we can see a corresponding service order header record in the CRM database table CRMD_ORDERADM_H, it mainly goes through the three steps marked in the following figure.

Step 1: field mapping of Inbound Adapter

Why do you need this field mapping? Whether it is the old CRM On-Premise or the new S4CRM, as long as it involves the creation of a service order, it is bound to call the function CRM_ORDER_MAINTAIN. And the following figure of Data Container, its data format is completely different from the number of input parameters of CRM_ORDER_MAINTAIN, so it must be done through Inbound Adapter to do a format mapping, this idea and the Adapter pattern in the design pattern is the same.

Because Inbound Adapter for format conversion in CRM middleware needs to support data synchronization of various business objects, such as service order, material master data, product master data, etc., the input parameter type used by Adapter to receive Data Container must be a general type:

Step 2: Validation Service

In general, every CRM middleware data synchronization object has a corresponding function for verification. Before calling the actual create / modify API, use this check function to perform error detection to achieve the purpose of Fail Fast,Fail Early.

Fail Fast, Fail Early is a software development implementation concept put forward by Jim Shore and Martin Fowler, which is introduced in detail with reference to the works of Martin.

For example, the COM_PRODUCT_MAT_VALIDATE in the following figure is the data verification function corresponding to the material master data synchronization object. The screenshot is from the transaction code SMW01.

Step 3: call the corresponding CRM function

If the service order is synchronized, it means the call to the function CRM_ORDER_MAINTAIN; if it is the material master data, it is COM_PRODUCT_MAINTAIN, and so on.

Consultants engaged in the secondary development of ABAP Netweaver-based SAP products can enjoy an advantage: many functional API with similar functions and similar implementation ideas in different SAP products, the similarity of this style is not easy to describe in words, simply with a "SAP flavor".

For example, I have worked as a SAP SD developer for many years. I used the function SD_SALESDOCUMENT_CREATE to create sales orders, and after joining the SAP S4CRM team, I used the function CRM_ORDER_MAINTAIN to create service orders in CRM. When I browsed the parameter definition of the latter and tried to write some test code, I couldn't help but sigh, "Oh, everything smells familiar."

Similarly, the idea of implementing S4CRM API is the same as the idea of SAP CRM middleware that has just been reviewed, which is also three major steps.

1. Validation

2. Mapping

3. Business Processing

Except that Validation and Mapping change the order, the overall idea is exactly the same as the three steps of CRM middleware:

Let's take a look at the detailed steps for developing an API in S4CRM.

1. Model

The first thing you need is modeling. Without a model, how can API start?

The first step is to build our data model in the SAP system according to the sales orders in the specific service scenario.

Use the transaction code SXMB_IFR, select Enterprise Service Builder, and the system will look for the Java runtime environment natively, which is a must, so be sure to install JRE before modeling.

The model needs to be built under the corresponding namespace. Here, I use the namespace used for SAP S4CRM standard development:

There are four elements in modeling:

Data type (data Type)

Message type (Message Type)

Error message type (Fault Message Type)

Service Interface (Service Interface)

The first thing to do is to create basic data types. You can refer to the existing basic data elements of global and introduce the global data elements that API needs to use from global namespace to our own namespace.

For example, the following figure shows the composite field SalesArea, which contains the "five golden flowers". Most Netweaver-based SAP products follow this best practice in modeling SalesArea:

In fact, we are doing an assembly work here, LEGO (Lego) you must have heard or played it.

As shown in the following figure, like assembling Lego toys, we assemble various data types into a structure for receiving external data (that is, service orders).

After the structure of the business model is created, we need to assemble an overall data type to be referenced by Message Type, which is to introduce the information of Message Header. I believe experienced consultants already know what information is maintained in this Message Header. Yes, it's just some identifying information used for transmission.

We can review the input parameters of the SAP CRM middleware Inbound Adapter, which also has this Message Header: everything is familiar.

With all the data types in place, we can assemble the final Service Interface model, which is finally open to external invocation of Webservice objects. Here we use the method of asynchronous transmission, of course, you can also choose synchronization, depending on your actual needs and business scenarios.

The name of the Service Interface above, ServiceOrderRequest_In, is the name of the API technology that appears in the SAP help documentation.

After these models are created, the Proxy object is generated in the transaction code SPROXY, which is actually the ABAP DDIC structure that can be accessed by the ABAP code.

two。 Using ABAP to create and modify service orders

As mentioned earlier, the first thing we need to do is to verify the data received from the outside in order to maximize the correctness of the data before calling CRM_ORDER_MAINTAIN.

After the data validation is performed and no check errors are thrown, we need to map the externally connected data structure to the data structure in the SAP CRM_ORDER_MAINTAIN.

In fact, the relevant data fields in CRM_ORDER_MAINTAIN are scattered in the corresponding structure. For example, most of the header data is stored in ORDERADM_H, most of the line item data is stored in ORDERADM_I, and the status data is stored in STATUS.

Based on this feature, you can easily find that it is always the model that changes, while the CRM_ORDER_MAINTAIN side is relatively fixed. So we specifically designed a class to complete the data mapping. In the design of this class, we tend to give priority to the fixed side, and each structure creates a method, which is conducive to future reuse and maintenance, and the design is relatively clear and hierarchical.

The following figure is a list of methods for this data mapping class:

Let's take ORDERADM_H as an example. On the Inbound side, we map the corresponding external data to the structure ORDERADM_H corresponding to SAP CRM_ORDER_MAINTAIN.

The following figure shows how the data mapping class maps the ID, type, and description information contained in the service order header field contained in the external data to the input parameter format required by CRM_ORDER_MAINTAIN. The red highlight is the mapping processing of the order ID field.

After all the field mapping is complete, we can do business processing and call CRM_ORDER_MAINTAIN to create or update the service order.

If it is a service order creation scenario, the ID of the order is automatically generated in the S4CRM system. After the creation is completed, the generated service order data needs to be read out and sent to the external system as an API response.

The red area in the figure above represents the code that calls CRM_ORDER_MAINTAIN to create a service order, while the blue area represents the call to CRM_ORDER_READ to read the created order details out of memory and prepare for Outbound processing, that is, field mapping and mapped data are sent to the external system.

The field mapping before sending the response, mapping the data on the internal structure of SAP to the processing logic on the external structure, as shown below:

After the field is mapped, the function / AIF/SEND_WITH_PROXY is called to send out the mapped structure. The target system to be sent is specified by Logical Port, and its value is contained in the highlighted variable in line 15 below.

Jerry has described in detail the use of Logical Port in Web Service consumption scenarios in his SAP blog, so I won't repeat it here:

Https://blogs.sap.com/2014/05/20/step-by-step-to-create-consume-and-trace-web-service-in-abap-system/

We take a closer look at the acquisition of Logical Port, which is determined by several parameters.

IF_CONF_API_SRO_CONSTANTS= > COMM-SCENARIO_ID:

This field is a constant with a value of SAP_COM_0424:

The configuration steps for communication scenario represented by SAP_COM_0424 can be downloaded from the SAP Best Practices Explorer website I introduced earlier.

This communication scenario is an out-of-the-box model abstracted by SAP for the actual system integration scenario, which can be integrated with other systems through a small amount of simple configuration.

For example, the concept of communication scenario also exists in SAP Cloud for Customer, and the usage is similar:

Finally, I simulate the external system call S4CRM API to create a service order to give you a more intuitive feel.

I use SOAP UI to initiate requests. The following figure shows that we made a request to create a service order with a transaction type of SVO1:

After successfully calling Web Service in SOAP UI, go to the S4CRM system to view the details of the service order we just created:

Finally, you may be curious about the function / AIF/SEND_WITH_PROXY that actually performs the send action.

Let's first recall the scenario of SAP CRM middleware, such as CRM sending data to ERP, and finally the RFC call that is executed:

While S4CRM API uses / AIF/SEND_WITH_PROXY, the prefix AIF of this function stands for Application Interface Framework, which is an Addon on SAP Netweaver, a lightweight data integration middleware solution.

For more information about AIF, you can read the following SAP blog:

Https://blogs.sap.com/2012/04/03/sap-aif-so-what-is-it-all-about/

The API developed by our Chengdu S4CRM team is still in the process of function enhancement. Please look forward to it. Thank you for your reading.

Related reading

Can you distinguish between these three CRM solutions of SAP?

Hello World, S/4HANA for Customer Management 1.0

SAP S4CRM vs C4C, Zhuge Liang and Zhou Yu?

A SAP consultant has been in the United States all these years

For more original Jerry articles, please follow the official account "Wang Zixi":

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.