Name: Working with Configuration Files in Backoffice Framework in SAP Commerce Cloud
Uploaded: 2021-4-14
Duration: 400 s
Description: In this video, you will learn about the following configuration files in Backoffice Framework in SAP Commerce Cloud:Widgets.xmlOverriding widgets.xmlCockpit-config.xmlOverriding cockpit-config.xml

Share feedback

<p><u><strong>Planned maintenance of Practice Systems</strong></u></p>

Planned maintenance of Practice Systems

Why create an SAP account?

Enhance your learning experience

SAP Learning

Choose your subscription

Manage your subscription

Live Sessions

Hands-on Practice

Certification

My Learning

Ready to start learning?

<div><div>In this video, you will learn about the following configuration files in Backoffice Framework in SAP Commerce Cloud:<br><ul><li>Widgets.xml</li><li>Overriding widgets.xml</li><li>Cockpit-config.xml</li><li>Overriding cockpit-config.xml </li></ul></div></div>

Working with Configuration Files in Backoffice Framework in SAP Commerce Cloud

Hi, my name is Lily. In this video, we'll discuss the following configuration files. Widgets XML overwriting widgets XML cockpit config XML and overriding cockpit config XML. The back office application structure contains two XML files that you need to know about. As a developer back office widgets, XML and back office config and SAML back office widgets. SML contains the application mashup for any perspective within the application. The local file back office config XML contains the contextual UI behavior for components depending on the current user and on the data type being displayed. These files in your back office extension are merged into an in-memory global matcher for the entire application, which can be viewed within the application orchestrator. We'll discuss these files in more detail in a moment. For now, just note that the configuration that developers will edit primarily resides in these two files. The application mash up refers to the layout and structure of the back office application. It includes all of the individual mash ups for the different perspectives within the application. The application mash up describes which widgets are used within each perspective, the layout of the widgets in each perspective, how widgets are wired together through socket connections or widget viewing restrictions, and the current values of a widget instance settings. We previously saw that a widgets settings are defined and optionally given default values in its definition XML file. The runtime values of settings for a widget instance, though, are pulled from the application mash up configuration. The global application mashup is stored in the database as a media item. It can be viewed from application orchestrator, but should not be edited directly. This is because the content is dynamically generated and is a merged configuration of multiple XML files within the application. Updates to this file will happen at runtime through the Application Orchestrators user interface. Whenever a user performs actions, such as adding a widget to the user interface or creating a widget connection. Each back office extension contains a back Office Widgets XML file, which contains a partial definition of the global mashup. It can be edited directly and upon performing a refresh, will be incorporated into the global UI definition. You can find more information about this topic in the Back Office Technical Guide in the SAP Commerce Cloud documentation. You can also provide an application level widgets XML file to provide a default mashup for your standalone back office application. Back office comes out of the box with its own application level widgets. XML definition that specifies the default configurations for the back office. Any changes to the application mashup at runtime can be reverted through the use of the Reset to default option for the corresponding config file in the application orchestrator. This will cause the application to reload the XML files from the file system, which means that your extension's default mashup configuration will get reloaded and merged into the global Widget's XML definition at runtime. Often, developers use the orchestrator to create and edit the application mashup. They can copy the relevant XML code from the Widget's Xaml file in orchestrator and paste it into their application or back office extension level widgets XML file. This results in a more permanent application mashup that cannot be lost on invoking reset to default in the application orchestrator. Runtime updates in the Application Orchestrator will override application level and extension level widget XML configurations. The component contexts UI configuration describes the content and behavior of widgets and other components in different contexts. Component contexts UI configuration updates are more advanced than application mashup configuration updates, as the XML file is required to be edited manually. This is the part on which we will primarily focus the component context. UI configuration exists in a file called back office Config. XML. This is also a merged file that is dynamically created for multiple XML files on the file system. You can view and edit the XML from this merged file within the application orchestrator. Once you edit this file through the user interface, you can tell the application orchestrator to save the entire merged XML to the database as a media item. Back office developers can provide default UI configurations for their custom and extended widgets. This configuration is located in an XML file within the individual widgets folder. Structure. At runtime, this XML file will be loaded into the merged cockpit config XML definition. Any runtime changes to the merged cockpit config XML will override this default configurations. Within back office, the merged cockpit config and SAML is stored as a commerce cloud media item. Runtime updates to the XML made using the application orchestrator can be written back to the persisted data. Similarly, with standalone back office applications, you can store the runtime version of the merged file back onto the file system. If reset to default is invoked on config XML within the application orchestrator, the application will purge the merged XML file and recreate it from the default cockpit config XML files on the file system. This means that any runtime updates to the standalone merged application, XML or media item will be reverted. As a back office developer, you have the option of providing extension level, context configuration for your custom and extended widgets. Extension level configurations will override widget level configurations at runtime. Configuration changes made in the application orchestrator will in turn override extension level configurations. In this video, we discuss the following configuration files widget XML overwriting widgets, XML cockpit config XML and overriding cockpit config XML. Thanks for watching.