Design and implementation of SAP Cloud for Customer Extensibility

Today's article from Jerry's colleague, C4C development team Developer Xu Huan (Xu Boris), the SAP Chengdu Research Institute. Xu Huan sitting on my left-hand side of the position, so I work in any encounter C4C technical problems, a turn can ask him, very convenient. It's the desktop of his office.

Jerry previous Article field extensibility of SAP products take SAP CRM and SAP S/4hana as an example, this paper introduces the design principle and implementation of SAP product field Extensibility. Now Xu Huan continues to extensibility this topic and introduces you to the extensibility design and implementation of SAP Cloud for customer.

SAP C4C and SAP S/4hana Extensibility have deep roots, the latter being based on the former and innovative. From the timeline, many of my German colleagues I know have been involved in the framework development of C4C and S/4hana extensibility. Many of the key roles of the two framework development teams, such as architects and product managers, are even the same group of people.

Below is the text of his.

Hello everyone, I am Boris, Chinese name Xu Huan. 2015 New Year's Day has been engaged in ERP customer project development and consulting, about 6 years. Prior to this, we also worked on a few years of development unrelated to SAP products. As a result of participating in ERP implementation project before joining SAP, I have spent a lot of time researching the basic business process of ERP core module, and have been involved in many projects from project to customer on-line implementation. In 2015, with the vision of the SAP development team, we joined the SAP BYD/C4C Application development project, participated in the development of multiple application modules and industry solutions, and handled more than 1000 customer failures in the field of the C4C HTML5 UI framework over a period of 2 years with a technical support role.

Currently as a member of SAP C4C in the China standard development team, I am delighted to share my thoughts on c4c extensibility here.

Jerry previous Article field extensibility of SAP products has introduced the differences between the two concepts of enhancement and modification. C4C users enhance the C4C standard UI and custom developed UI through the key user tool, a CRM-like application enhancement tool,aet. The enhanced types are divided into personalization and adaptation, which are effective for individual users within the same tenant and for all users within the same tenant.

The Key user tool is very easy to use. If you want to enhance the UI by adaptation, sign in to C4C, select Adapt, Edit Master Layout in the top menu bar (corresponding, if you choose personalization Way, Start with the Personalize menu item next to adapt).

Now hover the cursor anywhere on the page, if the page is C4C background set to "can enhance", then you can see a popup toolbar, click on the plus icon inside, you can choose "Add fields" from the drop-down menu to enhance the field.

Fill in the field description, type and other information after saving.

Is it very similar to the C4C Extension field creation page and the S/4hana Extension field creation page that appears in the previous story of Jerry?

For the customer, the whole process is straightforward, and it takes only a few minutes to complete the operation. The support behind is the extensibility framework provided by SAP C4C, which I want to introduce to you. First, we start with the basic concept.

Personalization

User-made adjustments to the UI in this way are only valid for users who are currently personalization and are not visible to other users.

C4C backstage there is a storage system called Xrep, design ideas and concepts with Jerry introduced S/4hana extensibility mentioned lrep consistent, but in C4C changed a name, here X for cross. Although C4C customers and partner cannot log in to the background to see the full contents of xrep like S/4hana, it is still possible to view parts of the Xrep through the configuration Explorer in the UI designer. As shown in the right-hand area, xrep is essentially a layered file system implemented with ABAP.

Technically, each personalization imposes a UI modification that generates a file that is C4C officially called the Change Transaction, hereinafter referred to as Ct. The CT personalization produced is stored in a layer called $pers in the C4C backstage xrep. At runtime, when the UI page containing personanization is ready to render, the C4C front-end framework temporarily merges the CT in $pers into the corresponding C4C standard UI.

Adaptation

Technically, the CT file produced by adaptation is stored in the layer that the user belongs to. For example, a UI modification made by a customer is stored in a layer called $cust. and partner made the changes, stored in the partner corresponding to the solution unique layer below. Partner solution is a unique concept of C4C, such as an example in Cloud Application studio. The partner solution can be likened to an ABAP package, and a partner solution can store all the resources that cloud application studio supports, such as the Ui,bo,web Service, OData development, and so on. Each partner solution has a corresponding layer in the xrep.

My colleague Yang Joey used to c4c Bright left in his article SAP Chengdu Research Institute: SAP Cloud for Customer uses the unique features of SAP UI5, the source code of the C4C UI interface is stored in an XML format in the ABAP NetWeaver backstage in the Xrep. Xrep provides many APIs to access these XML files, such as read, parse, activate, and so on. Like S/4hana Lrep, c4c Xrep has different layers that store the UI created by the SAP standard Ui,partner, as well as the resources created by the user. Separation of resources is realized through layer, which makes the UI changes of the user not need to modify the UI files of the lowest level SAP standard. At run time, the upper layer changes the performance of the corresponding underlying file. For more details on merging between tiers (merge), refer to the S/4hana section of the Jerry article SAP product extensibility in the Lrep.

At run time, the C4C framework reads the UI source code from the Xrep Layer $Load, where we see $load contains the SAP standard UI, and the CT that partner and the customer make UI changes from. The CT generated in adaptation mode is immediately merged into the corresponding UI, and the UI files in the $load are regenerated after the CT merge so that the foreground frame is always rendered based on the latest merged UI source code the next time the load is loaded.

We now modify the properties of a standard field in a adaptation manner, and then observe what the automatically generated CT looks like with this modification action. We tick the mandatory property of the Manager standard field on the employee UI, meaning that if the field is not maintained, changes made to the employee will not be saved successfully.

Because users and partner cannot log in to C4C backstage, we need to look at the resulting CT details in a different way. Add the Debugmode=true parameter to the debug mode in the URL of the address bar.

Then reload the page, press CTRL + LEFT mouse button to click on the "Manager" field and a pop-up window appears. The red underline is the memory path of this CT in Xrep. There is a fragment "addcondition" in the path, which indicates the type of CT. Click the HYPERLINK "Get CTs" to view the CT details.

The XML content of this CT is as follows:

Some important information is included:

• Usedanchor: This attribute is one of the most important signs C4C extensibility design distinguishes between SAP CRM and S/4hana, and is described in more detail now. The Usedanchor type is sectiongroupanchor,xreppath for the path of the anchor in Xrep.

• TargetFile: Indicates which c4c UI the CT will be merged into. The value in the example is Cod_employee.ti, which refers to the employee's Detail page, where the UI adaptation action occurs on the employee Details page.

• Addcondition: Describes the specific type of UI modification. Example refers to the modified property name "Mandatory" and the default value is true.

Now to elaborate on usedanchor. Jerry's article, Field extensibility of SAP products, once mentioned that there is a unified extensibility registry in the background of SAP CRM and S/4hana. For each app developer, if you want your app's UI to support extensibility, you need to register the information that the framework needs. Similarly, C4C extensibility also needs the logic of this registry, implemented by the anchor mentioned in the example above.

Anchor's Chinese meaning is "anchor point", the word used in C4C extensibility Register this context is very appropriate. Each anchor points to a UI area that can be enhanced by the C4C Key User tool. We opened the employee Details page with UI designer that just modified the manager field mandatory property, and found the manager fields in a section group. Select the group, and from the extensibility property on the right side of the page, you can see that maintenance has a anchor. The anchor is the value of the Usedanchor field in the XML content of the CT we studied earlier.

If the extensibility property of a section group is maintained with anchor, it means that the SAP C4C declares that the section group can be enhanced by the key User tool. Conversely, it cannot be enhanced. Placing the mouse over these non-enhanced UIs in adaptation mode is only highlighted, but no toolbars are displayed.

In addition to the key User tool, C4C's partner has another way to enhance the UI by using the extensibility Explorer of cloud Application studio. With a UI section group selected, if the Group's extensibility field maintains anchor, you can see the action options highlighted in red and the UI will be enhanced by the wizard.

Finally, where and when are these automatically created CT images created by who?

CT creation

The trigger for CT creation is done in the UI-side JavaScript code and then posted to the C4C backend. In the C4C UI-side JavaScript Directory Sap/client/flex/changes folder, there are different types of UI modifications to the corresponding processor (Handler). For example, addconditionhandler.js this file, which responds to events where the user has modified the properties of the UI field in the key user tool.

Changeregistry.js, in response to the user's entry in the key User tool, distributes different types of UI modifications to the corresponding processor for processing.

Shows that when a UI modification of type "PropertyChange" occurs, the modification is changeregistry.js delivered to the processor propertychange.js.

Propertychange.js will parse according to the event parameters passed in, judging that the property of the field that is currently changing is mandatory, so enter the _mandatorychanged to process and create a CT record of this modification.

Hope this article can let everyone to c4c extensibility design has a superficial understanding, thanks to read.

Read more

• Field Extensibility for SAP products

• SAP Chengdu Research Institute C4C Bright left: SAP Cloud for Customer uses the unique features of SAP UI5

• SAP S4crm vs C4C, Zhuge Liang and Zhou Yu?

• SAP Chengdu c4c Xiao Li Tan hua: Talking about Fiori Design guidelines

• A ramble on SAP UI and Salesforce UI development

• Hello World, S/4hana for Customer Management 1.0

To get more original Jerry's technical articles, please follow the public number "Wang Zixi" or scan the QR code below:

Design and implementation of SAP Cloud for Customer Extensibility