Efficient Sites Structure - Improved Performance

Transcript

Hello everyone and welcome to the session of efficient site structure. Here with me are Abhinav and Vive. We are part of AM site team. In this session we are going to talk about MSM best practices, live copy overview, MSM in the background jobs and the three differences between language copy and live copy which basically increases the authoring experience. So since AM is moving towards cloud services, these best practices help author creating websites early in a better performing way and in a better performing way of synchronizing the content across multiple sites. So the main agenda of this session is to talk about MSM rollout configs and their priority order, MSM rollout as a background job and the key differences between language copy and live copy. So to start with let’s talk about MSM best practices. So if you know MSM is a part of AM, so MSM is used to use same content across multiple locations. So MSM uses the concept of live copies to reuse the content across multiple sites. With the help of MSM basically anything that changed at a source level can be synchronized across multiple live copies. Possible use cases of MSM are global to local sites or national offices to regional branches. At present in the AM, MSM is supported in sites, assets and assets folder and experience segments. The next thing we are going to talk about are MSM rollout config. So MSM rollout configs are the key component to decide how the synchronization will work between source and the live copy. If you talk about rollout config, rollout config consists of two major things rollout triggers and live action. So rollout trigger are the deciding factor which decide when the synchronization will take place and live actions are the actions which decide how the synchronization will be performed from a source to live copy. In AM it’s possible that customer can create their own custom rollout config and their custom live actions. A customer should be a little bit conscious when they create their custom rollout config. It should be done as little as possible. Customization should be done as little as possible. Moving on, we’ll discuss about the default rollout config that is present in AM. So first of all I would like to point out here that this is the CRXD view in AM as a cloud service. This is not available in AM in the cloud service. So basically this is a part of dev instances now. So customer can actually create these rollout config custom rollout config using the CRXD in their dev instances and those custom rollout config should be part of their custom code which should be deployed how the usual custom code is deployed. So moving on, see how the default rollout config look like. So default rollout config have a trigger rollout which means that this rollout config will trigger the rollout on manual rollout only and this default rollout config consists of content update multiple live actions like content update, content copy, content delay, so on. The major thing here to discuss is the priority order of the rollout conflict. So we have seen that the customer does not consider the priority order of the rollout config sometimes and that creates an unexpected behavior. So priority order of the rollout config decide which if there are multiple rollout config involved in a rollout which rollout config will be run first and how after that what will run. So priority order is defined in libs order list here something like this. So if you see launches on top followed by push on modify shell look followed by default. So this is defined in the libs model list and this remains same across all the sites in the aim. It cannot be changed for any individual site it will remain the same across aim. If customer is creating their own custom rollout config they should rewrite the order list as per their convenience and customer can rewrite your priority order in apps MSM order list. One thing to note here is that as soon as customer writes their own custom priority order in apps MSM order list that will be remain the fact now that will be the source of truth for priority order and libs MSM order list will be discarded. Always remember that the priority order of the rollout config changes the outcome of the rollout. We’ll see that with an example here. So here I have created a custom rollout config page move in apps MSM with page move action. So page move action is provided out of the box and most of the customer create custom rollout config out of this action. So I have created one here page move okay with page move action and if you see I have rewrite the order list node in the fashion that the page move is on the top of the default. Okay so basically the page move has a higher priority than default. This is the XML representation of this order list node. This is how it looks like it has a it it’s a slim order folder okay so basically these children are in the order and if you see that the page move is on the top of the default. So what happens with this order so I have created a live copy from language master en using page move rollout config and standard rollout config. And if you see this is the source page language master en and I have moved the child page about us to about us move here and after that I perform the rollout. So basically this is the source page rollout and you see in the test live copy the page has been moved as per the changes in the source. So this if you see the complete flow is here basically I moved the source page child and I performed the rollout and the same has been depicted with the live copy as well. So this was the expected behavior. Now what I’ll do I’ll change the priority order of page move and I put default on the top of page moves that means the default has a higher priority now if you look at the code of this this will look like something like that the default is on the top of page move. Now I’ll do the same thing I’ll create a test live copy of language master en with both the rollout configs I perform the same operation of move at the source level I have moved about us page to about us move and I perform the rollout from source to test live copy. If you see that I moved the page about us move in the source and after the rollout the new page about us move has been created but the about us which was in the original position has not been deleted. So the if you see the again the flow basically I moved the child page about us to about us move and then I perform the rollout and the original page has not been deleted and a new page about us move has been created. So you see this is an unexpected behavior this original expectation was to that the original page should be moved in the live copy as well. So this is an example of showing that the priority order does matter in the outcome of the rollout. Next thing we should talk about is potion modifier rollout config. Potion modifier rollout config is provided out of the box it comes it’s similar to default rollout config it has every action that is part of default rollout config but it has a trigger modification. What that means is with every change at the source rollout will be triggered automatically for all the live copy of that source. So if the changes at the source level are frequent the rollout will trigger very frequently and that sometimes create performance issue because rollout itself a heavy operation. It’s always better to perform rollout when there are sufficient changes at the source level instead of rolling out every minor change at the source level. So customer should be a little bit conscious about using potion modifier. If customer has a requirement to automate the rollout we do have an option now in the background job in async framework to basically schedule a rollout at their preferred time. We’ll talk about that how to do that in the later section of this session. Another thing to note here is nested live copies. So nested live copies are the live copy which are created inside a live copy. Nested live copies are also creates performance issues sometimes. So customer should always be a little bit cautious when they create custom nested live copies. We have seen in the past that some customers create live copy for each page instead of creating a live copy at the root of the site. Basically most of the use cases can be fulfilled while creating the live copy at the root level and they don’t require creating live copy at each page level. So that is also something that should be a little bit cautious about too while creating a live copy. Another thing to notice when you move at the source level a nested live copy is created that can be avoided while using page move action which will keep the structure same in the source and the live copy and avoid creating unnecessary a nested live copy in the site structure. Moving ahead we’ll talk about live copy overview. Vivek over to you. Thank you Ankith. Yeah hello everyone. In this section we’ll be looking at the live copy overview console of AEM in context of Amazon. The live copy overview enables us to manage and view inheritance across site and perform operations like roll out, synchronization, suspend and reset easily. Next slide please. So the features available on group and console center of the classic UI is now available on the touch enabled UI which is known as the live copy overview and next slide please. Now where to find live copy overview console on site’s admin page select a source page and open references tab under live copy section live copy overview button can be seen in the lower section of the references tab. Next slide please. So some of the features that can be seen on the live copy overview console are on selecting a source page authors can edit or roll out the page on selecting a live copy authors can edit check relationship status synchronized by pulling source changes reset to the source page temporary suspend inheritance or permanently detach it from the live relationship. Along with these options authors can also see the current inheritance status of live copies like inheritance cancel live copies up to date or blueprint modified in case of new changes in source page. Next slide please. Relationship status option will list on the details of the selected live copies and its corresponding blueprint page some of the details like blueprint path last modification date last rolled out date authors that triggered the rollout and other details related to rollout configuration can be seen under this console. Next slide. So in this section we will be looking at the background jobs to reduce the negative impact of performance adobe experience manager processes certain long running and resource intensive operations asynchronously in context of sites time consuming and bulky operations like rollout and page mover now using async framework as background jobs. This framework is based on Apache sling jobs and eventing mechanism providing guarantee of processing. Next slide please. So what are the some of the benefits that we can see by moving to background jobs authors can check the status of operation while still executing on operation failure the jobs can be retried manually or automatically send notification on operation failure or completion there is surety to run even on pod restarts in context of cloud deployments details like parameters passed errors reported can be checked on job details page authors can resume processing from the last failed state and detailed execution history and scheduling option is also available. Next slide please. Now how to schedule a job or how to start a background job with the introduction of this framework am sites by default have such rollout and page move operation to always run as background jobs while performing move or rollout operation this new dialogue will allow authors to start background operation immediately or schedule it for near feature on completion of background operation the authors will be notified with the pop-up notifications and inbox notification. Next slide please. The list of background jobs currently running finished or scheduled can be seen on the jobs listing page authors can navigate to tools general jobs to open the jobs listing page this page will list on the details like operation name description job start and or schedule date along with the current progress state. Next slide please. The notification layer of the background jobs will notify authors at various points on job submission this green toast message will be shown to authors when processing is finished inbox notification is sent along with status of the operation for example in this screenshot we can see background rollout operation completed successfully on successful completion authors will also be notified with pop-up status message of the job can be seen and there will be a link to the job details page. Next slide please. So there are other places as well where the status of this background jobs can be checked by selecting a page on sites admin console the details of background operation can be checked in this screenshot we can see the details of a rollout operation that was running on this page and by selecting that page we can see the details like the start date and the the current status of the job and the author that started this job similarly on sites card view the pages are tagged with the stickers with some background operation is executed for example the blue sticker is notifying about the rollout operation that is recently got completed on the tag page on sites list view an operation column is added that will list on the jobs that is scheduled running or completed on the corresponding page. Next slide please. Authors can get the detailed overview of the selected background operation by opening the details page from the jobs listing console the job details page of rollout operation will list on the details of the source page rolled out the author that started the operation date and time of of start and finish of the job and any errors reported during the rollout operation. Next slide please. The job details page of move operation will list the job processing details along with parameters that were passed like source path destination path references that got adjusted references that were published and type of move operation. Next slide please. There are some other features that are available under jobs framework job background jobs framework the selected failed jobs can be retried manually and the details of references that could not be adjusted can also be seen under the page move details page. Next slide please. So there are certain configurations that can be helpful while using background jobs by navigating to tools general job configuration we can enable or disable this the pop-up notification that is sent on job completion and the operation specific configuration can also be tuned depending on the use cases for example move operation can be configured to send inbox notification pop-up notification or email notification and job completion. That’s all from my side thank you. Handing over to Abhinav to cover language copies. Thanks Vivek. So next we will discuss the difference between language copy and live copies and which one should be used when. A language copy is a copy of an existing site that is needs to be translated to another language. As you can see in the image the en is the source and rest d es fr it are its language copies. It is highly recommended to create language copies if you intend to translate the content. To perform the synchronization between the source and language copies en provides out of the box update and translate workflows. It is advisable to have all the language roots at the same level. As you can see in the image all the language roots are at the same level. A live copy is a copy of a specific site content which inherits the content from its source through live relationship. When we perform the synchronization the actual transfer of content happen from source to live copy. The one prime use case is to reuse the content from multiple sub-sites. As you can see in the above image the language master en is the source and in the below image you can see that the us en is the live copy of the language master en. If you use the live copy for translation purpose whenever we perform the translation whenever we perform the rollout or synchronization the translated content get overwritten. Due to this very reason it is advisable to always use language copies whenever you want to translate so that that particular content is not overwritten. So in this session we have covered rollout configs and their priority orders and how background job affects the performance of rollout and the key differences between the language copy and live copy. And now I would like to thank everyone for attending this session. Questions are welcome and the forum link is already been pasted by Ankit in the chat box. You can share your questions on the forum as well. We will try to answer as many questions as possible over there. Thanks again.