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

This article will explain in detail how to analyze the Field Extensibility of SAP products. The content of the article is of high quality, so the editor shares it for you as a reference. I hope you will have a certain understanding of the relevant knowledge after reading this article.

The job responsibilities of SAP developers, in addition to implementing the functional requirements of the software, will also spend considerable effort on implementing some non-functional requirements to meet the so-called SAP Product Standard (product standards). These product standards, including Extensibility, which plays an important role in the implementation of SAP projects, and Security, which protects the safe operation of customer business processes, are also inconspicuous, but actually reflect the social role of SAP as a great enterprise, as well as Internationalization, and so on.

Today we are going to talk about Extensibility of SAP products. Although SAP products do a certain degree of abstraction to real-world business processes, some customers will still find that some special business processes in their enterprises can not be supported by the standard functions of SAP products. At this point, the Extensibility of SAP products has the opportunity to show their talents: the so-called Extensibility, that is, the underlying framework of SAP products provides enough flexibility to ensure that customers and implementation partners can Enhancement SAP products with the help of the standard tools provided by SAP to meet their special business needs. The difference between this enhancement and direct modification of SAP products (Modification) is that the former is recommended by SAP, and the enhanced implementation itself and the enhanced SAP standard resources are different entities, stored in different packages. With each version upgrade, the enhanced implementation itself is not affected in any way; while the changes are made to the standard code or model of the SAP product, and all these changes are lost each time the version is upgraded. And in Netweaver-based Cloud products, such as S/4HANA Cloud and SAP Cloud for Customer, customers and implementation partners have no way to modify Netweaver background resources directly.

The Extensibility of SAP products is divided into Field Extensibility and Process Extensibility. Field Extensibility, that is, the user can create a new field in the desired area of the UI directly in the browser through simple steps, which we call the Extension Field. Sometimes we prefix the term with the Simple prefix, which emphasizes that when creating new fields, customers do not need to have any technical knowledge or know the design details of the underlying data model of the product, but through simple steps like our wizard to install software on Windows systems. Process Extensibility emphasizes process enhancement, that is, it enhances the standard process of SAP products to some extent through the enhancement tools provided by SAP, such as Business Add-In (BAdI), Post-Exit, etc. Friends who have not come into contact with BAdI and Post-Exit, if you have done Java Spring development, you can compare BAdI to various hook in Spring and Post-Exit to Spring AOP (aspect-oriented programming).

The Field Extensibility for SAP CRM and S/4HANA is described below.

SAP CRM Field Extensibility

The creation of extension fields for SAP CRM is done through the tool Application Enhancement Tool (AET). Before creating an extended field, the user first enters the configuration mode (Configuration mode), and then the UI that can be created by the extended field is automatically highlighted.

After clicking the highlighted area, you can see the button to create the field. Click Create Field to enter the creation wizard of the extended field:

Here you need to maintain the details of the extension fields to be created, such as field label, field type, length, BO model where the field is located (ORDERADM_H in the figure below), and so on.

In the image above, I created an extension field labeled city name. After saving and activating it, it will be displayed on UI as follows.

All these steps can be done in just a few minutes, but what is going on behind it is far from that simple. In order to implement Simple Field Extensibility,SAP developers need to do a series of development, we call it Extensibility registration and enablement. This kind of development requires the participation of both SAP Extensibility framework developers and SAP application developers. Because although the effect from the customer's eyes is only a new extension field in UI, this is only the tip of the iceberg-the database tables in the background, the BO model and the interface data structures associated with each interaction layer should also be automatically enhanced by this extension field.

Here are some examples. The extension field I created in UI labeled city name automatically appears in the background database table:

This extension field is also automatically included in the interface structure of CRM Order-related functions:

The BTAdminH node of One Order's BO model is also automatically enhanced by this extension field.

So how does the Extensibility framework know that these resources that belong to an application also need to be enhanced when extension fields are created? It turns out that SAP Extensibility framework developers and SAP application developers have reached a contract: Extensibility framework developers define a registry. If application developers want their responsible UI to support Simple Field Extensibility, they need to fill in this registry with all kinds of model information and database table information that need to be automatically enhanced by the framework, so that when users use AET tools to enhance it. The Extensibility framework knows exactly which application layer-related models also need to be enhanced.

The appearance of this registry is shown in the following figure:

Application developers have a lot of other things to do besides registration, so there is an Application Extensibility Guideline programming specification within SAP, and we follow this document when we develop.

If the implementing partner develops a UI themselves and wants it to support Simple Field Extensibility, then it also needs to be developed according to this Guideline.

I have made an example for your reference before:

Fill in the registration form:

Https://blogs.sap.com/2013/10/25/step-by-step-to-enable-your-genil-component-with-aet

Follow Application Extensibility Guideline to make your application support Simple Field Extensibility

Https://blogs.sap.com/2013/10/25/step-by-step-to-enable-your-genil-component-with-aet-part-two/

Some CRM consultants ask me from time to time, "Why can't my AET UI see the Create Field button, or is it grayed out?" In fact, there are no more than three reasons:

1. Your user does not have permission to use AET

two。 The AET on your system is not setup correctly.

3. The UI you selected cannot be enhanced by AET (that is, the UI corresponding to UI is not registered as "extensible")

Before mentioning incident to SAP, you can follow the steps of my blog to debug and find out the reason:

Https://blogs.sap.com/2013/09/29/inside-aet-why-create-field-button-is-visible-in-some-ui-while-invisible-in-others/

How are these extension fields created with AET drawn on UI at run time?

In a nutshell, CRM WebClient UI's view configuration information (that is, the details of the fields that need to be displayed on the view, the relative positions between fields, field labels, and so on) are maintained in an entity called Configuration Context, identified by a 16-bit GUID.

The Context content is stored in the database table BSP_DL_XMLSTRX2 in XML format.

At run time, the UI framework first reads the XML data from the above database table and parses it into DOM, and then instantiates different UI controls according to the different types of UI controls corresponding to each node in DOM. For example, if a field type defined in XML is inputfield, create an instance of the CL_THTMLB_INPUTFIELD class. Jerry introduced in the previous official account article about the development of SAP UI and Salesforce UI that each control supported by WebClient UI will have a Render class similar to that in SAP UI5, which is responsible for generating the corresponding native HTML code for the control. From the point of view of UI view configuration, adding the extension field created by AET to the UI simply adds a node corresponding to the extension field in the XML source code, as shown in the following figure:

For more information on how extension fields are rendered at runtime, please refer to my blog:

Https://blogs.sap.com/2016/12/22/how-extension-field-created-by-aet-is-rendered-in-web-client-ui/

SAP S/4HANA Extensibility

Unlike SAP CRM, which creates extension fields directly on a specific application UI, S/4HANA uses a unified Tile (Custom Fields and Logic) as a portal to create extension fields:

The detailed maintenance interface for extended fields is more or less the same as SAP CRM's AET tool. The Business Context in the figure below means that the user wants this field to appear in the General area of the details interface of the S/4HANA Fiori application and Product Master.

After the extension field is created, the customer goes to the Product Master details page, right-click and select the extension field just created from the Available Fields list, and the extension field can be displayed on the Fiori UI.

What S/4HANA application developers need to do is similar to the SAP CRM described in the previous chapter, and they also need to register.

The following picture shows the registry of S/4HANA Extensibility. The highlighted line represents the "Product Master General" I selected from the Business Context drop-down menu in the extension field creation dialog box:

The above registry maintains two ABAP DDIC include structures for Product Master General, meaning that once this extension field is created and saved, it will automatically appear on these two DDIC include structures.

From the highlighted tab at the top of the registry, you can also see that these extended fields created by browsers in S/4HANA can not only be displayed directly in Fiori UI, but also can be placed in CDS view,OData models and Web Service,IDoc models. The options that appear in the registry simply indicate that they can support the addition of extension fields using the Extensibility extension framework, and it is up to the customer to decide whether to actually put the extension fields in. You can add the extension field to the corresponding model by clicking Enable Usage.

So how are the S/4HANA extension fields displayed on Fiori UI rendered at run time? To answer this question, let's first analyze what information is contained in the HTTP request that Fiori UI sends to the S/4HANA background when we add the extension field to Fiori UI.

Use the previous Jerry official account article Jerry to talk to you about the old tricks of the Chrome developer tool, and use the Chrome developer tool to find the details of this HTTP request. The requested payload is a JSON string saved to the local detailed study, in which there are seven important fields.

1. Jstype: sap.ui.comp.smartfield.SmartField

Indicates that the implementation type of the extension field in the Fiori UI view is Smart Field. What is Smart Field? It is also one of the controls provided by UI5, but unlike UI controls with specific types such as sap.m.Button and sap.m.Input, Smart Field is not bound to any definite UI display type during the XML view development stage, but is actually just a placeholder. The following figure is an example of Smart Field. Just with this fragment of XML view, we have no idea what kind of UI5 control id will be rendered as a Smart Field of idPrice at runtime. Instead, the type of the control can only be determined at run time, depending on what kind of annotation its bound field Price has in the metadata of the OData model.

In my example, the field Price is annotated as a Decimal field with units in the metadata, and its substitute field is another field in the OData model: CurrencyCode.

So at run time, the Smart Field is rendered by the UI5 framework as two UI5 controls, one that displays the price number, which is bound to the field Price on the OData model, and the other that displays the price unit, which is bound to the field CurrencyCode of the OData model.

For more explanation of Smart Field and rendering logic, please refer to my blog:

Https://blogs.sap.com/2016/03/14/currency-example-how-smart-field-works/

2. Id:mdm.cmd.product.maintain::sap.suite.ui.generic.template.ObjectPage.view.Detail::C_Product...

Indicates which Fiori application and which specific UI area the extension field is added to. The mdm.cmd.product.maintain in the first half of ID represents the Fiori application S/4HANA Product Master, and sap.suite.ui.generic.template.ObjectPage.view.Detail represents that the Fiori application is built based on the SAP Smart Template framework, and the UI where the extension fields are located is based on the Detail page of Smart Template's ObjectPage.

What is Smart Template's ObjectPage? Please refer to my blog:

Https://blogs.sap.com/2016/05/03/my-understanding-about-how-object-page-in-smart-template-is-rendered/

3. YY1_JDKminimumversionJ_PRD

The field name of the OData model to which the Fiori UI extension field is bound. We can do an experiment: maintain any value, such as "1.7", in the extension field on Fiori UI, and then save it. Turn off UI and reopen it, and it's easy to observe in the Chrome developer tool that a field called "YY1_JDKminimumversionJ_PRD" contains the value "1.7" in the OData response structure returned from the background. Fiori UI's extension field is bound to this model field, so it can display "1.7".

4. FileName

5. Layer:CUSTOMER,packageName:$tmp

These fields need to be explained together. As described in the previous CRM section, the configuration information for the SAP CRM WebClient UI view is maintained in the background database table in XML format. However, because S/4HANA Fiori applications are developed based on UI5, there is no corresponding storage database table for this kind of configuration information, but the corresponding relationship between extended fields and Fiori UI is stored in a special warehouse in the way of files. The content of the file is basically the JSON string I'm looking at from the Chrome developer tool, and the area where the file is stored is called LREP (Layered Repository). LREP is actually a file system implemented by ABAP, and its contents can be browsed using report / UIF/GET_CHANGES_4_TARGET.

To execute report, the most eye-catching are these layer, which is the origin of the name LREP, a hierarchical file system.

Vendor layer: SAP layer, which contains standard content published by SAP.

Partner layer:Partner can be enhanced based on the content of SAP layer. For example, like CRM AET, Partner enhancements can be configured into a transportable ABAP package, so the extension fields created by Partner on Fiori UI are stored in this ABAP package, from the development system to the test and production system.

Customer layer: customer enhancements made through S/4HANA 's extension tools are generally configured to be stored in the $tmp package, not transferable, and visible to all other users of the same system.

Draft layer: independent of the topic of this article, Draft concept processing for S/4HANA, refer to SAP help: https://help.sap.com/viewer/468a97775123488ab3345a0c48cadd8f/1709%20002/en-US/ed9aa41c563a44b18701529c8327db4d.html

User layer: stores personalization information and is visible only to the user who created the resource.

Why introduce this layering mechanism? Or to achieve the central idea mentioned at the beginning of the article: to ensure that enhancements made by partners and customers are not lost as a result of SAP product upgrades. Through the hierarchical storage of content, the content done by SAP, partners and customers is isolated from each other and does not affect each other. At run time, assuming that SAP, partners and customers all have their own resources for the same UI model, then the UI seen by the end user is a union of these resources, and the process of generating the union is called Merge. If there is a conflict during the Merge process, such as the label of a UI field, SAP, partner and customer have their own definitions, the Merge result will be based on the content contained in the highest priority layer. Different layer priorities are from low to high, that is, the layer of report from top to bottom in the figure above is as follows:

SAP- > Partner- > Customer- > User.

Let's go back to our ongoing payload analysis. Execute report, and the result is as follows. Click the button to display the full contents of this file in LREP:

You can find that the content of this file is the payload of the HTTP request sent from Fiori UI to the S/4HANA backend server that we observed in the Chrome developer tool:

Therefore, when we select the extension field from the Available Fields in the right-click menu in Fiori UI to put on the Fiori UI, Fiori UI requests the details of the extension field, that is, the JSON string containing the fields we have analyzed so far, is sent to the S/4HANA background and stored in the LREP.

The interaction between Fiori UI and S/4HANA LREP is done through sap.ui.fl.LrepConnector.js, which calls the service exposed by LREP to store the contents of the file.

6. Reference: mdm.cmd.product.maintain.Component

Product Master, the Component ID of the Fiori application, can be found in the Component.js of the BSP application MD_PROD_MAS_S1. As mentioned earlier, the Fiori application Product Master is built on Smart Template and does not have its own front-end implementation, so Component.js is just a wrapper with less than six lines of code.

When the Fiori UI containing the extension fields is about to render, there is first a HTTP request to read all the extension field information contained in the UI to be rendered from the LREP. Notice the / sap/bc/lrep/flex/data in the blue highlighted area below, which is the storage service that the S/4HANA background LREP exposes to Fiori UI.

After reading the JSON returned by LREP, Fiori UI parses the changeType as addFields, then calls the processing logic of the Fiori UI framework to render it according to the details of the extended fields contained in the JSON. This is actually the Merge action of SAP layer's Fiori standard UI and Customer layer's extension fields as mentioned earlier.

The entry for the extension field Merge to Fiori UI is at AddFields.applyChange:

AddElementIntoGroupElement adds the extension field to the area corresponding to the Fiori UI:

AddElementIntoGroupElement then calls createControl to convert the definition of the extended field into the corresponding UI5 control instance, whose Render is responsible for rendering the control instance into native HTML code. At this point, the rendering of the S/4HANA extension field is complete.

Field Extensibility on how to analyze SAP products is shared here, I hope the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

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.