Name: Introducing Fundamentals of Backoffice Framework in SAP Commerce Cloud
Uploaded: 2021-1-12
Duration: 303 s
Description: In this video, you can learn about the fundamentals of Backoffice Framework concept in SAP Commerce Cloud.

Share feedback

<p>We are aware of intermittent issues in accessing the learning content</p>

We are aware of intermittent issues in accessing the learning content

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?

Please try again later

Sorry, we encountered an error

Try again or reset results to continue browsing

We didn’t find what you’re looking for

To continue, please log in

Your session has timed out

Explore {title} at SAP Learning. Find out more!

Enhance your learning experience for free

<div><div><div><div><div><div><div>In this video, you can learn about the fundamentals of Backoffice Framework concept in SAP Commerce Cloud.</div></div></div></div></div></div></div>

Introducing Fundamentals of Backoffice Framework in SAP Commerce  Cloud

In this video we will cover back office framework fundamentals. The core concept in the back office framework is a widget. It is the smallest building block of every back office framework application. The widget concept was introduced to provide high modularity by means of a clear separation of responsibility. This means that each single widget should have one single responsibility. That widget should be usable in isolation from any other widgets. Bigger or more complex widgets should be composed of simple widgets. We call the bigger widgets grouped or composed widgets. Modularity is made possible through a clear separation of data. This means that each widget has its own private model that is not shared with other widgets. Message driven widget communication also enables high modularity. Widgets communicate via sockets that can be interpreted as signals. Think of a void method in Java. In order to be reusable, widgets should provide a high level of configurability, both in behavior and in terms of how the user interface is structured. This is where dependency injection is used, along with the strategy pattern. It allows for the capability to plug in custom behaviors to achieve this level of configurability, along with the well known mechanism of aliasing in spring. We allow context dependent configurations and instance dependent settings, reusing configurable widgets that have clear and simple responsibilities to build bigger or more complex blocks of the application is quite straightforward. Therefore, a good understanding of a widget's features and a deep knowledge of the standard widgets library is crucial for effective development. With a back office framework. Two more important basic concepts of the framework are actions and editors. Actions and editors share most of the previously mentioned design rules for widgets. The differences are mainly related to action and editor communication restrictions. Actions are dedicated to executing some operation that is usually related to selected or visible data. Think of a delete action. The ZK library extended by SAP Commerce allows for the easy embedding of actions in the view. Many widgets from the standard widgets library also allow configuration capabilities for using the actions. Editors are used for displaying and editing data. Think of a date picker similar to actions. SAP Commerce provides extensions to the ZK library that allow editors to be easily embedded, along with their configuration capabilities. In addition, we offer a smart mechanism for inferring the right editor type to be used for a data type that allows almost seamless usage even in more complex scenarios. Adapters are utility widgets that don't have a view, but are necessary to perform various operations on the objects sent through the sockets between widgets. One reason that you would potentially use an adapter widget is if you need two widgets to communicate, but their socket types don't quite match up. You can use an adapter widget to extract or transform the output from one widget into the required input for the receiving widget. An example of an adapter widget is a property extractor widget. This widget is used between the exploratory widget and the advanced search widget in back office. The exploratory widget has an output socket called Selected node that sends out a navigation node object for the selected node. However, the advanced Search Widgets input socket, called type only accepts a string object. So what it wants is just the name of the data type on which to execute the search. To get these two widgets to communicate, we need something in between them that will extract the type name from the navigation node object and forward it on to the advanced search. This is where the property extractor widget is necessary to accomplish the type name extraction. The property extractor widget is configured with a spell or spring expression language expression that will be evaluated on the input object. The spell expression in this case uses the key name. This key extracts the string value for the name property out of the navigation node object, and passes it to the advanced search widget. The back office framework provides a large set of useful adapters in addition to property extractor. One that we would like to mention is condition Evaluator. This adapter allows the redirection of an input object to one of two output sockets, based on the evaluation of a predicate on the input object. Other adapters include context poppy, later cast, event producer, event acceptor, and many more. All adapters are listed on the available widgets document page. Available widgets.