Name: Working with Advanced Widget Features in Backoffice Framework in SAP Commerce Cloud
Uploaded: 2021-5-5
Duration: 449 s

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><div><div>In addition to some of the core features we looked at earlier, the Backoffice Framework provides you with a number of more advanced capabilities. These features allow for additional reusability, modularity, and dynamic configurability in your application. In this video, you will learn about some of the advanced widget features in the Backoffice framework, namely stubs, template widgets, virtual sockets, and role-based permissions. </div></div></div></div>

Working with Advanced Widget Features in Backoffice Framework in SAP Commerce Cloud

Hi, my name is Phil from the SAP Training and Adoption Team. And in this presentation, we're going to be showing you some of the advanced widget features in the back office framework, in addition to some of the core features we looked at earlier. The back office framework provides you with a number of more advanced capabilities. These features allow for additional reusability, modularity, and dynamic configurability in your application. In this module, we're going to discuss the following topics. First of all, stubs which provide widget, socket, and messaging architecture to actions and editors. Then template widgets that provide for the dynamic creation of a widget instance in different contexts. Virtual sockets which enable runtime socket configuration, and finally role based permissions that allow us to manage the visibility of widgets for different users and groups. In a previous module, we learned that back office framework widgets communicate by sending and receiving messages via the use of sockets, actions, and editors. On the other hand, do not have sockets, but nevertheless, in some cases you may need your action or editor to have the ability to communicate with other widgets. For example, imagine that you have an editor that should automatically trigger a search in the editor area component. When a user enters data in one of its fields. Because both actions and editors are rendered on the basis of contextual information that's not available at the time of the application's orchestration. They cannot have the same in-built socket capability as standard widgets. In order to overcome this limitation. We can tell our actions and widgets to become socket aware. This is done by extending the abstract component widget adapter aware class by extending the abstract component widget adapter aware class. Your action and editor can utilize the following methods to work with sockets send output. This is used to send data on an output socket event add socket input event listener. This adds an event listener for the input socket, denoted by socket ID. In addition, you'll need to add your socket definitions to the definition XML file for your action or editor. Extending abstract component widget adapter aware is what allows the definition XML for actions and entities to include socket information. Connecting your socket aware action or editor is also slightly different from the way it's done with normal widgets, as mentioned previously. Due to rendering based on runtime contextual information, we can't anticipate the number of coexisting instances of a particular action or editor in the view. Therefore, the back of his framework creates a visual representation of one instance of the action or editor, known as a stub. This stub represents one socket aware component, but it may represent multiple concurrent instances of that component. The stub can then be used to connect the action or editor with other widgets. The stub will have a unique ID generated by concatenating the stub underscore prefix with the original idea of the action or editor. Here you can see that we've specified a connection between the output of an action stub and the input to a widget. Note the stub underscore prefix on the action ID in addition to the XML configuration. We can also configure connections between stubs and widgets within the application orchestrator. In the symbolic widgets, speed. As you can see, there's an additional area on the far left hand side of the screen, and when we expand it, we see it's labeled as the component holder. This area lists all of the stubs that exist within the framework, i.e. any component that extends abstract component widget aware. You can then connect these stubs to widgets using the link connector icon. And this is identical to the way that we've previously connected widgets within the application orchestrator. All features that are available for widget connections are also available for stubs, except for a few limitations. Only one instance of a stub exists, regardless of the number of instances of that socket aware component. This means that if you have two instances of a socket aware editor in your application, and configure the stub to connect to a widget, both editor instances will be connected to that widget. Stubs may only be connected to widgets. For example, a stub to stub connection would not be supported. Virtual sockets are also not supported for stubs. For examples of using stubs, you can take a look at the back office administration cockpit mash up. Here, stubs have been used in multiple instances. For example, the reference editor lists reference entities, but it also allows the user to edit each item in the list without stubs. All of the editing capabilities would have needed to be rebuilt into the reference editor with stubs. On the other hand, we're able to reuse existing components and connect them with sockets to achieve the same functionality. So in this video, we've learned how to use stubs to allow actions and entities to communicate with widgets via sockets. In the next two videos, we're going to take a look first at template widgets and virtual sockets. Template widgets allow the application to dynamically create tabs and popups in your application, based on the template socket interactions and virtual sockets allow for the runtime creation of sockets on a widget, and can be used to trigger actions on template widgets. In the third video, we'll take a look at how to configure authority based restrictions on widgets, depending on the authority based role of the current user. All of these advanced features of the back office framework are covered in more detail in the help documentation. Thank you for listening.