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

How to carry out the design and implementation of SAP Cloud for Customer Extensibility, many novices are not very clear about this, in order to help you solve this problem, the following editor will explain for you in detail, people with this need can come to learn, I hope you can gain something.

C4C users enhance the C4C standard UI and custom-developed UI through the tool Key User Tool (Application Enhancement Tool,AET similar to CRM). Enhancements are divided into Personalization and Adaptation, which take effect for a single user in the same tenant and for all users in the same tenant respectively.

Key User Tool is very easy to use. If you want to enhance UI through Adaptation, log in to C4C and select Adapt-> Edit Master Layout in the top menu bar (accordingly, if you choose Personalization, start with the Personalize menu item next to Adapt below).

Now hover the cursor anywhere on the page, if the page is set to "can be enhanced" by the C4C background, then you can see a pop-up toolbar, click the plus icon inside, and you can select "Add Fields" from the drop-down menu to enhance the field.

Fill in the field description, type and other information and then save it.

We compare the C4C extension field creation page in the above figure with the S/4HANA extension field creation page in the previous Jerry article. Is it very similar?

For customers, the whole process is simple and easy to understand, and all operations are completed in just a few minutes. Behind it is the Extensibility framework provided by SAP C4C, which is exactly what I would like to introduce to you. Let's start with the basic concepts.

Personalization

The adjustment made by the user to the UI in this way takes effect only for the user who is currently Personalization, and is not visible to other users.

There is a storage system called XREP in the background of C4C. The design idea and concept are the same as the LREP mentioned when Jerry introduced S/4HANA Extensibility, but changed its name in C4C, where X stands for Cross. Although C4C customers and Partner cannot log in to the background to view all the contents of XREP as S/4HANA does, they can still view some of the contents of XREP through the Configuration Explorer in UI Designer. As shown in the right area of the figure below, XREP is essentially a hierarchical file system implemented in ABAP.

Technically, each UI modification imposed by Personalization generates a file, which is officially called Change Transaction for C4C, hereinafter referred to as CT. The CT generated by Personalization is stored in the C4C background XREP. The CT in the formula input error PERS is merged into the corresponding C4C standard UI.

Adaptation

Technically, the CT files generated by Adaptation will be stored in the Layer to which the user belongs. For example, UI changes made by customers are stored in a Layer named $Cust. The changes made by Partner are stored under the unique Layer of Solution corresponding to Partner. Partner Solution is a unique concept of C4C, as shown in figure Cloud Application Studio below. You can compare Partner Solution to an encapsulation of ABAP Package. A Partner Solution can store all kinds of resources supported by Cloud Application Studio, such as UI,BO,Web Service,OData development, and so on. Each Partner Solution has a corresponding Layer in the XREP.

My colleague Yang Joey once mentioned in his article SAP Chengdu Research Institute C4C Guangzuo: the uniqueness of SAP Cloud for Customer's use of SAP UI5 that the source code of C4C's UI interface is stored in XML format in XREP behind ABAP Netweaver. XREP provides many API to access these XML files, such as reading, parsing, activating, and so on. Like S/4HANA LREP, C4C XREP has different Layer, which stores the UI created by the SAP standard UI,Partner and the resources created by the user. The distinction and isolation of resources is realized through Layer, so that the operator's changes to UI do not need to modify the UI file of the lowest SAP standard. At run time, the upper layer changes overwrite the performance of the corresponding underlying files. For more details on merging between different layers (Merge), please refer to the introduction to LREP in the S/4HANA section of the SAP product Field Extensibility in the Jerry article.

At run time, the C4C framework incorrectly typed Load from the XREP Layer formula contains the SAP standard UI, as well as the CT resulting from Partner and customer UI changes. The CT generated in Adaptation mode is immediately merged into the corresponding UI, and the UI file in $Load after the CT merge is regenerated so that the foreground framework is always rendered based on the latest merged UI source code on the next load.

We now modify the properties of a standard field in the way of Adaptation, and then observe what the automatically generated CT looks like with this modification. We tick the Mandatory property of the standard field Manager on Employee UI, meaning that if the field is not maintained, the changes made to Employee cannot be saved successfully.

Since users and Partner cannot log in to the C4C background, we need to view the generated CT details in another way. Add the debugMode=true parameter to the url in the address bar to enter debug mode.

Then reload the page, hold down the Ctrl + left mouse button and click the "Manager" field, and a pop-up window appears. The red underline below shows the storage path of this CT in XREP. There is a segment "AddCondition" in the path that indicates the type of CT. Click the hyperlink "Get CTs" to view the CT details.

The XML content of this CT is as follows:

It contains some important information:

UsedAnchor: this attribute is one of the most important signs that distinguishes C4C Extensibility designs from SAP CRM and S/4HANA, which will be described in more detail right away. The UsedAnchor type in the figure above is SectionGroupAnchor,xrepPath, which is the path of the Anchor in XREP.

TargetFile: indicate which C4C UI this CT will be merged into. The value in the example above is COD_Employee.TI, which refers to the UI Adaptation operation that occurs on the details page of Employee, that is, the Employee details page.

AddCondition: describe the specific type of UI modification. The example above shows that the name of the modified property is "Mandatory" and the default value is true.

Now let's talk more about UsedAnchor. Jerry's article Field Extensibility of SAP products once mentioned that there is a unified Extensibility registry behind both SAP CRM and S/4HANA. The developer of each application needs to register the information needed by the framework if he or she wants the UI of his application to support Extensibility. Similarly, C4C Extensibility also needs this kind of registry logic, implemented by Anchor mentioned in the example above.

Anchor means "anchor point" in Chinese, and this word is very appropriate in the context of C4C Extensibility registration. Each Anchor points to an UI area that can be enhanced through C4C Key User Tool. We use UI Designer to open the Employee detail page that just modified the Mandatory property of the Manager field, and found that the Manager field is in a Section Group. Select the Group and you can see that there is an Anchor in the Extensibility attribute on the right side of the page. This Anchor is the value of the UsedAnchor field in the XML content of the CT we studied earlier.

If an Anchor is maintained at the Extensibility attribute of a Section Group, it means that SAP C4C declares that the Section Group can be enhanced by Key User Tool. On the contrary, it cannot be enhanced. Hovering your mouse over these non-enhanced UI in Adaptation mode will only be highlighted, but no toolbars will be displayed.

In addition to Key User Tool, there is another way for C4C's Partner to enhance UI, even with Cloud Application Studio's Extensibility Explorer. Select a UI Section Group, and if the Extensibility field of the Group maintains Anchor, you can see the operation options highlighted in red below, and follow the wizard to enhance the UI.

Finally, when, where and by whom did these automatically created CT be created?

CT * create

The trigger for CT creation is done in the JavaScript code on the UI side, and then delivered to the C4C background. The corresponding processors (Handler) for different types of UI modifications are stored in the directory sap/client/flex/changes folder of JavaScript on C4C UI. For example, the AddConditionHandler.js file is responsible for responding to events in which the user modifies the properties of the UI field in the Key User Tool.

ChangeRegistry.js, as an entry in response to user operations in Key User Tool, distributes different types of UI modifications to the corresponding processors for processing.

The following figure shows that when a UI modification of the type "PropertyChange" occurs, the change is delivered by ChangeRegistry.js to the processor PropertyChange.js.

PropertyChange.js parses based on the passed event parameters and determines that the Property of the field that has changed is mandatory, so it goes to _ mandatoryChanged for processing and creates a CT to record the modification.

Is it helpful for you to read the above content? If you want to know more about the relevant knowledge or read more related articles, please follow the industry information channel, thank you for your support.

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.