Name: Introducing the Widget Application Context in Backoffice Framework in SAP Commerce Cloud
Uploaded: 2021-3-26
Duration: 464 s
Description: In this video, you'll learn about the basic concepts of the Widget Application Context in detail. You'll get an overview of the Spring context architecture in a Cockpit NG application, and how to register and then utilize beans. Then you'll learn how using the Widget Application Context compares to using the regular Spring web application context.

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><div><div><div><div><div>In this video, you'll learn about the basic concepts of the Widget Application Context in detail. You'll get an overview of the Spring context architecture in a Cockpit NG application, and how to register and then utilize beans. Then you'll learn how using the Widget Application Context compares to using the regular Spring web application context.</div></div></div></div></div></div></div></div></div>

Introducing the Widget Application Context in Backoffice Framework in SAP Commerce Cloud

Hi, my name is Lily. In this video, I'll go over the basic concepts of the widget application context in detail. I'll provide you with an overview of the spring context architecture in a cockpit engine application. I will also provide you with some useful examples of how to register and then utilize beans. Then I'll talk about how using the widget application context compares to using the regular spring web application context. In order to illustrate some key points about the widget application context. Let's make the following assumptions. In our system, we have two custom back office extensions called extension one and extension two. Extension one contains an order service with its corresponding bean. Our order service returns orders. Note that the order service is just one example. We can define any bean extension to is the extension where we plan to customize beans from extension one. As mentioned previously, our system can have several custom back office extensions that have a shared context which allows them to share beans. Each extension contributes to that context in a specific order, based on dependency settings that we will discuss in more detail shortly. As you can see in the diagram, the widget application context is an additional spring application context that is registered as a child of the web application context. Remember that it is registered during the deployment of an extension. In this example, we have two back office extensions that contribute to the widget application context. They contribute in specific order based on the extensions dependencies specified in extension and full XML. We want to ensure that extension one is loaded before extension two. To do this, we need to add a requires extension element. Two extension to extension info XML file. Now extension one will always be loaded before extension two. For more information on extension dependencies, you can take a look at the wiki extension dependency page. Let's continue with our example and see how the order service bean gets declared in extension one. This is the same way that you will declare any bean within an extension. First I'll navigate to our extensions widget application Context configuration file, which is automatically generated for you when you create the back office extension. The file is name according to the pattern extension name back office spring XML. It is located in the resources folder of your extension. In our example, the widget application context configuration file is called extension one. Back office spring XML. According to our assumptions, we have already declared the order Service Bean within extension one. This is how the declaration of the order Service Bean looks. That is all it takes to register a bean in the widget application context. Now the bean can be accessed by other back office extensions. I'll demonstrate this using extension two shortly. But first, let's see how we can access the beans. To access a bean inside your controller. I'll create a member variable representing the bean. Due to convention, your member variable name must be identical to the bean. Name. You need to annotate your variable with the at wire variable annotation. This tells the framework to inject the bean specified in the application context with the same name. At wire variable private order service, the ability to auto wire is supported in multiple controllers, including default widget controller selector, widget controller, and bean widget controller. Outside of controllers where auto wiring is supported, you can use back office spring util to access your beans because the widget application context is a shared context. We have the capability to replace beans defined in other extensions. In order to illustrate this. I'll use extension two to override the order service bean that is declared in extension one. To do this, I'll open the extension to back Office spring XML and declare our new order service bean. Note that the alias element name attribute is the same as for the order service bean declaration. In extension one. Previously, the order service name corresponded to the default extension one. Order service bean. Assigning a new bean to the same alias name is what tells the framework to replace this bean with our default extension to Order Service Bean. This new configuration causes every reference to order service inside extension one to. Now point to the implementation in extension two. Remember that this is possible because order service is ordered wired to the controllers directly from the widget application context. Note that for extension two orders service bean to replace the one from extension one, it also requires the extension dependencies that we specified previously. Extension two has to be loaded after extension one. As the diagram illustrates, we have one parent back office spring context. This is the main web application context. All beans from this context are visible in all back office extensions. In addition to that, we have the widget application context that is shared among all back office extensions. One important note here is that beans created in the widget application context are not visible to the parent context. Additionally, in some cases, there are requirements to adjust or register beans in the parent context from a back office extension. The registration mechanism for a bean declared in a back office extension is tightly bound to spring beans. Lifecycle. To access a bean from the widget application context within the main back office application context, you will need to access it within a custom init method. This custom init method will be annotated with at post construct. Within this method you can access the parent context. This same method is used in cockpit and GS data access strategy extender and cockpit configuration service extender classes. For more details, you can look at how these two classes are implemented in the framework. Further information on this topic will be covered in the subsequent instructor led training. In this video, we looked at the basic concept of the widget application context in detail. We looked at an overview of the spring context architecture in a cockpit engine application. We saw some useful examples of how to register and then utilize beans, and we discussed how using the widget application context compares to using the regular spring web application context. Thanks for watching.