Integrate AEM & CIF framework to build a rich and immersive e-commerce experience

Transcript

All right. We can start. Vinay and Kunal, please feel free to start with your presentation. All right. Thank you so much. Share my screen.

Can you see my screen? Yes, we can see it. Thank you. All right. All right. Thank you so much. Thank you so much for joining this webinar. I am Kunal Kabbah, technical architect at Adobe, and I am joined by Vinay Kumar, who is my colleague, again a technical architect. So today, we are going to talk about integrating AEM web commerce, using e-commerce integration framework and how you can build rich and immersive e-commerce experiences. So the agenda for today is to talk about commerce integration framework. What are the features of this framework? What is the value proposition? We will talk about the integration patterns, especially in the context of third party commerce solutions. We will also look at the different types of component libraries. We have the SIF core components as well as the client side components, and especially how you can extend those components in your projects. We will do a little bit of deep dive on that. Then we will do a quick demo of some of the new features which have been released in this framework. And then we will also talk about the best practices on performance, multi store, multi plan setup, and SEO. So let’s start with the commerce integration framework. So what is commerce integration framework? I see that many people have joined the webinar today, and many of you are architects or developers. And some of you might have already worked on AEM and commerce integration projects. Especially if you have worked on those projects before this commerce integration framework came into place, definitely you must have scratched your heads at that point of time because it was really a very hard problem to solve. How do you integrate AEM with commerce? Because those two are different applications. And how do you bring them together? Some of the important questions to answer in this integration is who should own the glass? Whether AEM should own the glass or commerce should own the glass. How do you get real time product data on your pages? How do you marry content with product data? And how do you access staged catalog data? So these are very important questions. And that’s the reason why commerce integration framework came into place. Because it simplifies this integration. It standardizes the integration of AEM with commerce. And it brings in lots of features for authors as well to create those rich immersive commerce experiences and create those experience-like commerce websites. So what is commerce integration framework? So it is basically an add-on for your experience manager. It extends the experience manager with commerce capabilities and standardizes the integration with commerce engines. It provides a set of authoring tools, components, reference storefront, and it also has certain reference implementations, which basically accelerates the development and lessons or basically accelerates the time to market for the brands. And it brings the two applications together, the AEM and the commerce. It brings them together and it leverages the strengths of both of these applications. The authoring, personalization, and only channel capabilities of AEM and the e-commerce operations of commerce solutions. So at a high level, let’s quickly go through some of the features, what are available and what is the value proposition of commerce integration framework, which you can use in your projects. So first is the CIFF core components, which we have already seen. These are open source production-ready components available and these components reduce the need for customization and accelerates the time to market for the brands. Product corporate, another very useful feature. So in AEM, you can see real-time catalog data of your products. You can see the basic information of the product, its images, its variants. You can also see the association of the product with other content nodes like content fragments, experience fragments, assets. And you can also see the staged catalog data within AEM. So you don’t have to leave the AEM interface to see this data and you can easily build the experiences within AEM without leaving that interface. Product catalog experiences. So your product pages and category pages. So you can build those pages using the standard AEM templates and commerce components. And these pages are rendered dynamically and you can enrich those pages with marketing data using commerce experience fragments. And also if you have a need to show different type of product pages based on categories, that also you can achieve out of the box with the capabilities of commerce integration framework. We will also show you a demo of this capability in the demo section. Commerce related assets. So with this add-on, when you install it in your experience manager, in the assets properties, you will see a new tab called as commerce tab. And in this tab, you can associate your products with the commerce data or the product data. Augment product catalog data. Again, a very good feature. Using this, you can leverage the content fragments in AEM and augment your product catalog data and associate those content fragments with the products using the standard product data fields. You can use these content fragments on your product pages using the commerce content fragment components. Again, a very good use case for marketing.

Production ready code and best practices. So this framework includes open source commerce components, which we have already seen. And also the Vinnia storefront, which is a reference storefront and the integration layer code. So all of this is readily available. You don’t have to develop things from scratch, which is what code is production ready, SEO optimized, integration with data layer. Everything is there. And it also comes with best practices, like how do you extend those components, which are available as part of the library.

Standardized integration layer. Like if you have use cases for integrating your AEM with non Adobe commerce solutions, some third party commerce solutions, how do you do that? So again, instead of reinventing the wheel and building that integration layer from scratch, you get a reference implementation. And this layer is microservices architecture based. So it is easy to scale, easy to extend, and it saves a lot of time and accelerates the development effort. And finally, the AEM project archetype with Vinnia storefront. So you can easily scaffold the content and commerce project. And using this archetype, you get a Vinnia storefront, which again is a good starting point for custom storefronts, which you will build for your projects. So we have seen all of these features. We will see some of these in action in the demo as well. So let’s move on to the integration patterns. So before I start with the integration patterns, I will just quickly start with the API query language, which is the GraphQL. So GraphQL is used as the standard language or the standard API for integrating your AEM with commerce. And GraphQL is getting more popular these days because it gives more capabilities or basically it helps you to reduce the overall interactions you make between the client and the server. So the client can make an introspection call to the server to get the schema of the response. And based on that introspection, it can then just get what all information it requires. Whereas in the case of REST APIs, you have to make those multiple calls to get the data from the server. So it is basically reducing the number of calls, reducing the payload. You are just getting what you need. So that’s why this is used as a standard for integration. All the core components and the client side components use GraphQL for integration with the commerce engines.

So let’s start with the first pattern, standardized integration for Adobe Commerce. So suppose you have to integrate your AEM with Adobe Commerce or Magento Commerce solution. And how do you do that? And you don’t have to do anything because the commerce integration framework connects directly with the Adobe Commerce. So there is no integration layer in between. You can see in this diagram my AEM components, which are hosted in AEM Author or Populace, or even the client side components, they are making direct calls to the Adobe Commerce solution. And why is this possible? Because the Adobe Commerce or Magento, it provides a GraphQL based API. And the GraphQL schema, which is used in Magento, it’s the same schema what the commerce components rely on and the query for commerce objects. So that’s the reason there is no integration layer in between. And in this architecture, you can see that we have different caching layers. Like I have got Fastly CDN in front of Adobe Commerce to cache the GraphQL query response. And we have got standard AEM caching layers of dispatcher and CDN. And one key thing over here is that the client side components, they are making the GraphQL calls directly via JavaScript. But those calls are proxied via the dispatcher.

The next pattern is for third party commerce solutions. So if you have third party commerce, then how do you integrate it with your AEM? So here comes the integration layer. So you can clearly see we have the integration layer posted on Adobe App Builder, which is based on Adobe IOT runtime. And this App Builder hosts these IOT actions or the runtime actions. And these actions, basically what they do is they translate the response from the third party commerce. It could be like REST APIs or any other APIs. It is translating the response of those APIs and converting them to GraphQL. So this integration layer simplifies the integration between your commerce components. So commerce components, they don’t have to directly connect to the third party commerce. So that is done via the integration layer. And you don’t have to make any changes in your commerce components because the integration is done by a standard GraphQL schema and queries which they are already built on. So that’s how you do the Adobe App Builder integration. We will talk about this integration layer in more detail in the coming slides. The next pattern is third party commerce solution integration without the App Builder. So suppose you cannot use the App Builder, you don’t have the license or you cannot use it. So what are the options? So the options here are that you can use a third party integration layer, you can host your integration layer on MuleSoft or any other external API gateway. And essentially do the same thing what you were doing on the App Builder. Translating the responses and converting it back to GraphQL and returning it back to the components. The option B is that instead of using those external third party layers, you can directly customize your third party commerce solution and host those GraphQL APIs within the commerce solution if it allows. So that’s another option. And finally, this slide talks about a popular commerce solution like SAP Commerce Cloud or Hybris. So there is a reference, I will not say reference, an integration layer which is an open source implementation which has been done by a partner called as Deconium. So that’s already available because SAP Commerce Cloud is quite popular and used across multiple companies. And that’s why instead of building it from scratch in every project, reference implementation has been developed and contributed. So you can use this as a starting point and extend whenever required. So this slide talks about the integration layer reference architecture. So I was talking about the Adobe App Builder and the actions. But this slide at a high level talks about how it is architected or designed in the backend. So basically this integration layer is divided into multiple actions or I would say a set of resolutions. So these functions run in your Adobe I O platform. So there are two set of functions or actions which are called as local action or remote actions. So why this local and remote actions are designed or segregated in this way is that if you look at how GraphQL works. So in this diagram, you can see that the client is making an introspection query, like it is trying to understand what are the different objects available in the schema, like how it can query those objects. So it’s making an introspection query. So that query goes to the dispatcher action, which is a local action running in its own node process in the Adobe App Builder. Now this action only knows about the catalog data. It knows about the products and the category. And what it is doing is it is forwarding the incoming introspection query to the cart resolver action. And cart resolver action is those about the cart objects. So there are two sets of sub schemas that are called as local actions. So there are two sets of sub schemas here. One is the catalog sub schema and one is your cart sub schema. So your cart resolver action is only responsible for your cart objects. So essentially, what is happening is once this delegation happens to the cart resolver action, it gets back the response of the introspection query. And then the dispatcher action then sends back a consolidated response to the client. And for the client, the client gets a consolidated response. So the client is not aware that internally it is making calls to different sub schemas. So there is a single schema for the client. So this design helps you. The advantage you get with this design is that it is easy to extend and customize. Because if there are changes required in cart resolver or cart sub schema, you can easily do that in the cart resolver action instead of doing everything in a single piece of code. So that’s the reason how this is designed. And this is basically if you search in Google, this is like a GraphQL, I think, delegation or sub delegation pattern, if I’m not wrong. So this slide, again, the same continuing with the same slide. Now, with the introspection query, you just get to know what are the scheme, what is the schema. In this schema, you know, like what are the different types of queries you can make and how you can make those queries and what you get as part of those queries. Now, the next part is you fire a query. So the client is now making a query for products. It is asking for certain categories. It is asking for the cart items. Now, the same thing is happening. The query goes to the dispatcher action. Since the dispatcher action has to get it from a third party commerce, the data from the third party commerce, it is making a REST call and that REST call is getting converted back to the GraphQL response. And that translation is happening in the dispatcher action. And then it is forwarding the query to get the cart object to the cart resolver action. So that forwarding happens, the delegation happens, the cart resolver action makes a REST call to the commerce platform to get the cart object data. And then it gets translated to the GraphQL response and then how it is combined and a consolidated, combined federated response is sent back to the client. So that’s how this integration works. Now, let’s talk about the delivery options. So in commerce projects, there is always this question of who should own the glass, whether AEM should own the glass or commerce should own the glass. So this slide talks about the different architecture options we have. Your commerce storefront can be hosted completely on AEM, which is like Vennia storefront. So in that case, all your content is managed in AEM. You are building those content using your standard components and templates and your specific editing, you are leveraging those features and you are delivering everything, the entire HTML to the browser. Whereas in the case where you have a headless implementation like a Magento PWS studio storefront, so everything is built on React. Now, how do you leverage content in that React application? Then the option for you is that you can use the content services, the GraphQL based content services to surface that content from AEM in the JSON format to your headless or to the single page application. So here AEM does not own the glass, but your single page application owns the glass. Now, in this slide, I’m just taking an example of the PWS studio, which is a Magento storefront, which is completely built on React. A Vennia storefront built on React. Now, how do you go about and extend that and start using content from AEM? So all the React components in PWS studio, we are using Apollo client, which is a standard client used for finding the GraphQL queries and getting that commerce data from the commerce engine and showing that data in the React component. So this Apollo client is responsible for all your GraphQL queries. Now, if you want to get the data from AEM, you will have to make another call to AEM and that call again will be a GraphQL call, right? Because you will be using the content services of AEM and calling those GraphQL APIs of AEM to get the content. Now, you will have to extend the Apollo client over here and then this Apollo client will be able to make two calls and consolidate the responses and then you can use that response in your components. So there is a detailed documentation available for that. I have shared the link on the slide. You can go through that. This is just for reference how that is achieved. All right. I will now stop sharing and Vinnie, who is my colleague, he will start the rest of the talk. Thank you so much. Vinnie, over to you. Hey, thanks Kunal. Thank you for covering the CIF architecture along with different integration pattern options and its important building blocks. Now I will talk about the CIF core components and how these components can be extended for a specific business requirement. I think as Kunal, you covered the overall goal is to reduce the need of a custom code and help us create time to market. That’s why these core components exist. In the core components, we have support for both server-side AEM STL components and the client-side React components. Today, I will cover about both server-side and client-side component and of course how these can be extended. As Kunal has already mentioned, these are production ready. You can use this as is or you can extend them as well. I’m sure many people in this session might be aware, but for those who are not aware, besides these components, Adobe also provides an AEM version of the Vigna reference storefront by Magento. It is an example of how a typical B2C experience will be built using the CIF core components and AEM project archetype. How does it look, right? Like the component, it’s an open source and available on the GitHub. Apart from the code, there is a package available. If you want to pick up that package and install it on AEM version, you can also do that. As I said, there are two versions of the components. One is a server-side component, another is a client-side component. We can customize both. Let’s talk about the server-side component first. We understand every project has a different business requirement, hence the framework should support the component customizations. Similar to WCM core components, the CIF components also follow the proxy component pattern. That means when you want to extend these components, you can create a proxy component which will extend the CIF core components. Which eventually makes a GraphQL call, gets the data and then renders it back. The customization of GraphQL query can also be done. There are hooks available which are provided by the CIF core components. There is a commerce GraphQL models and the client is also part of these OSDI bundles. It is also embedded as part of CIF core components. Now, let’s take an example. We’ve been talking about GraphQL. For CIF, we use the Magento GraphQL schema as an API for communicating between AEM and commerce provider. To make the life easy of developers, CIF uses a generator to generate Java classes from Magento GraphQL schema and use those classes in the component. To make this work, we leverage the GraphQL introspection feature as Kunal said in the beginning. It gives you a schema, it gives you all the information about the objects which is available and which is already exposed. So when you’re writing GraphQL query in your favorite ID, you can get everything in auto-completion. You don’t need to go back to the schema and refer back because the object is generated from the classes. You can actually get this in auto-completion. The generated classes also contain data models for parsing and deserializing the GraphQL JSON response. We release data model for each Magento version on GitHub. So it’s not just a resident product team. Always whenever there is a new release of the schema happens, it is also available on the GitHub. Now let’s take an example if we want to extend one of the CIF component. What will be and how will we do it? In the sequence diagram, I’ve taken an example of a product user component. We are extending a product user component. The requirement is to show additional description which does not come as part of the out-of-the-box CIF component. So what we have done here is we have created a proxy component. As I said, it follows a proxy pattern and it actually points to our TV product user component. In order to now extend that, there is a need to create a sling model which is product user which will extend out of the box product user and the implementation wherein we will get the additional attribute which will come from a GraphQL which is description and then we will render it. I will cover this in more detail in the demo but this is how the overall flow will look like. In a high level, again I’m reiterating there is a proxy CIF component which we will create which will point to AM core components. Eventually, in order to get or make a data from the commerce system, it makes a call to commerce GraphQL system. Again, it depends on whether you are integrating with AM commerce directly or you have a middle layer in between for non-magento. That’s why you see Adobe ION between. Now, that’s how the server-side components work. When I say server-side, the components are purely written in HTML, typical AM components. In an e-commerce world, it’s a very dynamic nature. Not everything can be server-side. There is a requirement to get something dynamically, something on a real-time. This is what we refer to as a client-side component. In the previous releases, we supported the client-side components for quite some time but these were the React components. We recently made a change on the CIF core components. We have deprecated the existing version of the React component. Now, there is a new PWA Studio library, a paradigm framework which will be used. If you are planning to use starting a new project, I would strongly recommend that you look at using the PWA Studio component, the new React components. Rather than using the existing components. These are also available in the CIF. Now, the CIF client-side components follow the PWA Studio approach, as I said. It provides modern React components based on the paradigm framework. Those who are not familiar with the paradigm alone, basically most React components contain two distinct sections. A section for logic and a section for presentation. The logic section contains code for generating new values, maintaining local state and a life cycle of the method. This section, you can consider this as a brain of the component. The content section of the React component contains code that defines the component DOM structure. It often uses values from logic part of the component and passed into another component or display using HTML elements. The PWA Studio separates those two sections into distinct components with a specific concern. A Vigna UI component, you can think of that way, and a paradigm Talon, which has the business logic. Now, in case you need to customize the client-side component, what is the best way to do that? Here is an example that you can extend and bootstrap your client-side component development. Client-side components are stored under UI frontend modules. These are compiled and deployed as a client library in AM. You can copy component from Vigna-UI in PWA Studio project. You can also reuse the UI if required or reuse the Talon if there is no change in the business logic. This is an example of mini-card. If there is no change in the mini-card, you can still use the mini-card component here. You can copy paste in your UI frontend module and reuse it. The reference is also mentioned here. You can go to this and I will also cover how the mini-card is designed in it. Now, quickly jump into the demo. Just give me one second, I’ll share my screen. To start the demo, I would like to first cover some of the new and enhanced features of SIP. I will show you a demo where we have extended the product user component and how we have customized together more information and how we can reuse and extend the client-side component. Let me just start with the new features. If you are not familiar and if you are doing it first time, what I have done is all the documentations are available. You can set up your local. Everything is pretty much available on the web. What I have done is I have installed the Vigna store. You can go to the site and you will see the Vigna demo store. I have already installed it. It is actually pointing to one of the commerce stores. What I will do is I will go to the commerce and this is where you will see the Vigna store. This is one store which I have configured. If I click on the Vigna, you will see all the categories and all the products. If I want to see the detail of any of the categories, I can pretty much click on that. It will give me all the details. What is the category ID? How many products and child categories we have? Similarly, if we want to see the product details, I can click on that. I will get all the products. I can see the description, the price, if there are variants attached to this. That’s what Kunal was talking about. It’s a product cockpit. As a marketer or an author, I don’t need to go to the commerce system now. Everything is available here. That’s one store. Usually, there is a need to support more than one store. It is pretty much available out of the box. As you can see, I have configured another store which is Weaken. This has the other data. If you want to reuse that, if you want to configure multiple stores, it is very much possible. All you need to do is go there in the cloud services. There is a section called CIF configuration. You can go and create one more configuration. As you can see, I have configured one configuration for Weaken. The other one for Weaken site. I can click on that and show you the properties. This is how my store configuration looks like. It points to which GraphQL client, which is an OLEI configuration, which store you want to point to, what is the category root ID. Now you can have multiple stores. These multiple stores also correspond to the different sites. I want to use these multiple stores in a different website. What I’m going to do is I’ll go to the site. This is my cloud instance as well. This is where I have created the latest code from Maven Architect 35 and deployed here. I have two sites. One is a demo and another is a Weaken. One is pointing to Vinya, other is pointing to Weaken. If I go to the US and open the category page here, I’ll click here and I’ll open the category page here. I will click on the viewer category. It will show me by default all the categories which are in my Vinya store because I have attached my Vinya store. I click on the, let’s say I want to see this, I click on top. It will list all the products which fall under the category Vinya top. If I do the same thing on the different content hierarchy, wherein I have tagged a different store, which is a Weaken store, I will go there. It’s the same page. Even if it’s a copy, you can think of it as a live copy or a language copy, whatever you want to create. I clicked on this page. I’ll open this in edit mode. If I go there, view with category, it is showing me a Weaken store. I’m getting all the products, all the categories which are part of the Weaken store. Let’s say if I want to select the equipment, I select the equipment and I click on edit. It will now show me all the products which fall under the equipment under the different store. As an enterprise customer, you might need to support different products, different stores in a different geography, different local. It is completely possible out of the box. Additionally, if you want to have a different URL pattern, let’s say when you click on that, there is a pattern which we follow. Let’s say there’s a pattern that you are following a product page. You have a category ID and then a SKU name, a product name. But maybe for a different geography or a different country, you do not want to follow the same. That is pretty much out of the box possible. All you need to go to the same configuration. I quickly take you back to where I had the configurations. I will go to my configurations. Cloud services. I will go to SIFT configurations. This is where I have two. Now, I can go and change that particular URL pattern on the store configuration itself. If you want to select a different URL pattern, you can now select from here. If you want to select a URL path or a variant SKU for a weekend, you can pretty well do that. Not only for product, you can also change that for category. That is pretty much possible now. These are some of the new features. I would also like to talk about one new feature which is a very good feature for marketers. What happens usually is in SIFT, people think that it is only one page which supports the experience. What if I want to have a different experience for my products which fall under a particular category? Let’s take an example of this. Wherein I had equipments. I will open it again. No problem. We go to categories. This is my one page which will serve all the categories. What if the requirement is I want to have a different product page for one of the categories? That’s not a problem. What I can do is let me open first a category for you. I will go view with category. I will select equipment. In equipment, you want to have a… I clicked on this. This is still using the same product page. My marketer wants to use a different product page. What they can do is… What we can do is we can create another experience which I have created here. I just need to tag this with the category I want to do that. I will go here in my properties section and I can actually go to commerce tab and I can tag it. I want all the products which fall under cycling so I can tag it. I don’t know if there’s something wrong happening here but you will see a list of it here. You can tag it with that particular… That is pretty much possible. In fact, if you want to have a different category, you can also do that. Let’s say you do not want to use this one common page for all your categories. You can also do that. You can create another category page. Let’s say the way I have created it for trip and I can tag this page for a trip category. Whenever somebody clicks on the trip category, it will use this experience, not this experience. These are some of the new features which will definitely help a lot of things which marketers usually want. They want to control the more experience on their hands. All of these things are pretty much possible. Now, let’s look at the use case which I was talking about how we can extend the product user component. What I’ve done is… I’ll show you quickly. First thing which we need to do is if you want to extend the product user component, we need to see the existing GraphQL. That’s the beauty of GraphQL as Kunal was mentioning. You don’t need to change your endpoint. You don’t need to do much. All you need to do is, is the attribute coming or not? If it is coming, you need to see in the schema, validate that and get the output. As you can see, this is my out of the box. I do not see a description coming here. This is what gets fired when I use out of the box product user component. First thing what I’ll do is I will put… I want to show the description. I’m sorry to interrupt you. Could you please increase or zoom into the browser because now with code it’s a little bit too small to see. Okay, let me try.

Is it better? Yes, thank you. Okay. Yeah. So we don’t need to change anything because as the schema description is also exposed. It’s just that we have not used it. So now I’ve entered the description here. I click on the send request. I will validate if I’m getting the description. Yes, I’m getting the description. So all I need to do is I need to now in my proxy components. Give me one second.

Okay, one second. My screen is frozen.

Okay. Okay. Okay. Okay. Okay. Yeah. So what I’ve done is I’ve created a my teaser Java component which extends the product teaser. Since I want to show a custom description, I’ve added a field there and then I’ve written a IMPL for this. In this, all I need to do is existing product teaser dot get product retriever that it follows a delegate retriever pattern. This is where we just need to mention that extend the query with a custom object which is description. That’s all we need to do. And once this is done, we definitely need to come back on our component, which is product teaser, and write the STL to handle the description, which is this. So we are getting the response as a sling model in a custom description that we are rendering. So that’s all we need to do it. This is how easy the customization of server-side component is. Now, with the interest of time, I’ll quickly jump to the best practices. Now, based on our experience, there are certain learnings, best practice, and recommendations for integrating AM and commerce system using SIPs. Let me cover those in the next few slides. Right? Let’s first talk about the performance. As performance is a very key, important part for any e-commerce website, there are some best practices around to how to get a better one. The first and foremost is render commerce data server-side via SIP core component for cacheable. So wherever we can cache, for example, PDP component, not everything needs a real-time call. Right? Product images, description. So make this as a back, it’s a server-side component so that we can cache it. Render the commerce data, which is real-time dynamic in nature using the React component like price, inventory, all of these. Make a call directly from a client-side, get the data and render it. Leverage the Sling model and GraphQL client caching. You can also cache the GraphQL response. So feel free to do that to enhance the performance. You can also fine-tune the dispatcher and CDN for caching the pages and the static contents. Right? Let’s see in more detail. Right? So usually, right, let’s see how we can improve the caching effectively. The request, the user request comes from business stakeholders. Maybe always present real-time product data to customer, but this is not optimal user system resources. Right? It can impact the end user site performance and would greatly outweighs the benefit of constantly showing the real-time information. Right? I would say that the initial step is to close on the caching strategy to define, sit with all the stakeholders, come up with a metrics. Right? This is just an example. Right? In a commerce website, there are different type of content. For an example, there might be home pages and something, which is not very frequently changes. Right? Even if you’re serving the state content, it might not be. So you can cache them with certain TTL. But if you take an example, price inventory, it is highly recommended you do not cache them. Right? So because that those might change very frequently against the checkout shopping cart payment pages. It is. You probably do not want to cash them because the experience is very unique for every user. Right? So the first step is you actually agree with your business that this is how we will do and what is the caching and TTL time. We will keep it. Now, the other best practice around is considering the reusability and maintainability of the code. Right? So as much as possible, use the or extend the CIF core component using the delegation pattern, as I showed. Right? Leverage the Vigna UI, PWA components. You can reuse them as much as possible. You don’t need to create a new framework there and follow the same framework. Even if there you have a multiple brand use case, try to reuse the platform front end codes as much as possible instead of creating a different front end code for every brand. For enrichment use cases, try to use out of the box experience and content fragment because you can tag them with the product SKU and automatically when you are on a particular SKU, it will show that content fragment and experience. So there are enrichment possible. So try to use them rather than creating one page for every enrichment requirement. Now, the other important thing is multi-store. As I said, it is pretty much possible out of the box. You don’t need to do the customization. So try to use out of the box feature for multi-brand and multi-store setup. You can also align this with it pretty much support the context of their configuration. Try to use your AM-MSM best practices so that you can align your configuration accordingly. Also try wherever the labels are required. Manage I18 as part of code as if you are on a cloud so that it can be. Now, I think there were a few questions around SEO, but there are there are some best practices around SEO as well. Because searching and optimization has become a key concern for many marketers. As a result, SEO concern needs to be addressed and supports SEO fully. There are some best practices around it. Like you can define based on the patterns which are available. So you discuss with your business owner if you are migrating from existing site, just see which URL pattern suits you best. You can also generate the side map of these. There is out of the box support available which follows based on the Apache Sink site map. You can also add the relevant JSON-LD markup to your components. Now, there are some general best practices, but I think I kind of covered that. And just one more thing I want to call it out that this is not just for B2C, but this framework completely supports the B2B as well. For an example, if there is a use case, you want to show a price only after the customer is logged in. So that pretty much is possible. You can go and customize out of the box libraries. It is already loading pricing information client side. It is configurable, so you can extend that. So it is not just limited to B2C. You can definitely extend this architecture and support your B2B. Many of our customers are also using this for B2B. Now, I will open it for Q&A now.

Okay, great. Thanks a lot, Vinay. And also to Kunal and also to our chat experts who have been very diligently answering questions. That’s great. So one question is, are there any use cases where this framework has been used for a commerce solution that isn’t a traditional online shopping store? Sorry, when you say non-traditional online shopping store means any other, and it is not just limited to online shopping store, it can be used for other clients as well. I’m not sure if I understood the use case especially, but is there a specific use case one is talking about? Yes, please, John. Post a follow-up question so that you can elaborate on that. Thanks. While waiting for John to post his follow-up question or to elaborate, let’s go to the next question, which is in a general e-commerce use case where we have a third-party integration with AEM. For example, AEM integration layer and third-party product, for example, Hybris. Is it a safe assumption to say that SIF is a better integration layer while still communicating with third-party products or is SIF a replacement of the third-party product altogether? Yeah, so SIF is not a replacement of the third-party product. It is an integration layer. It provides an integration layer. The framework provides an integration layer and you should be using that integration layer to integrate with third-party products, whether it is Hybris or any other solutions. Okay, thank you. I see that John wrote that he’ll pick up with Kunal offline. Okay, the next question is one that was deleted earlier. Is React paragrind Adobe framework slightly? When I do a Google search, I find packages on Magento slash Adobe. I want to make sure I’m reading the right one. This is new to me and I am interested to know more. Yeah, it’s part of the PWA Studio project, which is Magento based. It was created initially for the Magento storefronts, which are React based storefronts. Adobe has introduced this paragrind framework. Yes, it’s not equivalent to Citely, but yes, it is a framework used in React components. Basically, the business logic of the React components are called as paragrind books or React books. Those are called as Talons. Thank you. The next question is all the URL patterns we have seen were having multiple HTML. Any reason, benefits of it? Vinay, can you take that question? I’m not sure I’ve seen if there are multiple dot stmls around that. But anyways, you will you can strip that because when you are showing an end user, you will strip those stmls. The only thing which will be visible is the is the final skew dot stml. Right? So you have sling mappings, you can you can actually strip whatever you want to do that. It is just for internal mapping that whatever page you align, it maps and then based on the sling etc mapping, you can very well strip whatever you want.

Alright, thank you. Next question is apart from React, what other front end framework goes well with CIF commerce? I mean, I would say out of the box support is for React. But if you want to have your custom framework, you are pretty well, you can pretty well go ahead and do that. Basically, you need to follow the similar architecture, your AM components will probably provide a placeholder div, let’s say product these are for just for an example. And then you will put your another front end model if it is an Angular or something and UI front end. And based on that div, you can load whatever you want to do that. So it’s completely fine. But you might lose the out of the box functionality and you might be not be able to escape your development because there is a lot of readily available. So you want to pick up from that. But yeah, it is possible if you want to customize that. Great, thank you. Next question is does the I guess is a follow up question. Does the CIF integration work when you don’t have that HTML in the path? For example, SEO best practices to remove that HTML from URLs? Yeah, I Yes, it works. It works. There are clients who are using the dot dot HTML. Yeah, it’s perfectly possible. Okay, thank you. Next question is can you comment on using the third party GraphQL integration with AM commerce and CIF on Adobe IO runtime project? Can you comment on using third party GraphQL integration with AM commerce? Why would we? Why would we? Sorry, am I reading it correctly? Okay, so you don’t want to use the AM out of the box GraphQL reference you’re saying I believe you’re saying you want to use a third party GraphQL integration.

Sorry, can you rephrase that I’m not able to understand this question correctly. Michael, please rephrase the question. Until you have that done, we will look at the next question, which is for AM and Adobe commerce integration, what is the best practice for hosting CIF? Where is it usually located? Yeah, I think you’re talking about the integration there. So that is posted on Adobe App Builder. So as I covered in these slides, the App Builder is based on Adobe IO runtime platform and its serverless functions. But if you don’t want to use that reference integration layer, you are very well free to host your custom integration layer in any other third party platform like MuleSoft. But if you want to reuse whatever is already available, then Adobe App Builder is the right platform. All right, thanks a lot. So, by now we have answered all the questions. There’s the follow up question just came in. We take this one as last one, because we’re running out of time. This is the open source project that provides a starting point for integration of third party ecommerce. Yeah, that’s true, Michael. Yeah, so you can actually connect with any of the third party. This is an open source, this is a reference implementation. So let’s say you want to connect with hybrids, which is SAP ecommerce now, right? So there is already on based on this reference implementation, there is a connector developed by Deconium, you can probably use that or you can use the SIF reference implementation if you want to connect with any other non Adobe ecommerce. All you need to do is do that mapping there, right? You might be getting data from a REST base, and then you need to configure those endpoint, get the data, do a mapping, and those will return back in a GraphQL format. Okay, great. Thanks a lot for this great session and also for answering a ton of questions. Thanks, obviously, to the audience for all your questions. And I would like to ask you for your feedback. And please help us by providing feedback through our concluding poll, which you will find in the general tab. Other than that, I just want to mention that we will post a recording on the landing page at ob.com slash go slash gems, and you will still be able to interact or post your questions on the contextual thread you will find in the general tab. And also on the landing page, it will be linked to our sessions. So thank you very much to everyone. Thanks for your attention and for joining and I wish everyone a great day or evening. Thank you and bye bye.