Migrate the Dispatcher configuration from AMS

Transcript

Hello everyone, my name is Varun Mitra and welcome to the video. In this particular lesson, we will talk about converting the dispatcher configuration from Adobe Managed Services.

After completing this training, you will be able to explain the process of migrating the dispatcher configuration from AMS. Now, let’s just quickly go ahead and see how you can migrate dispatcher configuration from Adobe Managed Services to make them work with AEM as a Cloud Service. So, this is the GitHub document that I will be referring to for this particular video. Now, this particular document depicts or lists out the steps that you need to follow in order to convert or make sure that your dispatcher configurations are valid for AEM as a Cloud Service. This is a fairly lengthy process and I would suggest you to give yourself enough time to follow each and every of these steps before you try running the dispatcher validator. Since there are quite a few steps in this particular tutorial, as such I’m going to just help you guys start off and then you can follow the documentation and you can arrive at the same results. So, the first step, as I mentioned in this particular documentation is to extract our archive and download the dispatcher configuration for AMS. If you are an Adobe Managed Service as customer, you should have access to your dispatcher configuration. You should be able to request your AMS password to provide you with these dispatcher configuration if you don’t have that. If you want to just try this for training purposes, you can also generate these dispatcher configuration at your end using one of our archetypes.

Now, this is the dispatcher configuration that I have got on my end. As you can just see it contains four different folders. Going back to the documentation again, it lists out removing the unused sub folders and files. This means that I need to remove conf and conf.modules.d folder. Once these folders are removed I then have to go ahead and clean up conf.d folder and remove any configuration files represented in here. Let me go ahead and remove these two folders first and foremost.

And I’ll also remove modules.d. Now I’ll go inside conf.d folder and remove all of these extra configurations files that are presented here. I’ll multi-select, and I will remove all of these configuration files. By doing this I’m fulfilling step number two. Now, I also need to remove any non-published virtual host within the enabled vhost file. That is, I need to remove author, unhealthy, health, lc, or flush.

So, I can simply go to enable vhost and I can remove author and flush leaving behind only the publish vhost file. Once again, I will multi-select and delete these from here. Now, since these files represent an enabled vhost, there is a chance that they will also be present in available vhost. As the files with an enabled vhost simply provide assembling to the files within available vhost. So, I will once again remove the non-published vhost files from available vhost and that’s what is depicted over here as well.

So, we’ll once again remove these three files leaving behind the publish vhost. Now, going back to step number four I need to comment out the virtual hosts sections that do not refer to port number 80. So once again, I can open up the publish vhost file and over here, I can see that the virtual host points to port number 80. If there were other virtual host sections I would have to remove them. Now, going back to the document I can check the rewrites that is I need to go to the rewrites directory and remove any of these files that are present in here. So once again, I will go to the rewrites directory, I see that there is a base rewrites rule an x forwarded forcessL rewrite rule that I need to remove So I can go ahead and multi-select and remove these two from here as well. Now, since these two files are now removed I need to remove the reference from my vhost file as well. So, I can simply go in here, scroll to the very bottom and I can remove the x forwarded vhost file, that is the include statement for it. I’m going to leave the If as is, that as the if statement access. And I will also remove the base rewrite rules file and save my changes. Now, similarly, I’m going to also look at the other rules that is checked for the variables in conf.d variables directory. And remove any file that is called as AMS_ default.vars and that remove its reference from the vhost file as well.

So, you go to the variables’ directory and remove the default vars file from here. Let me quickly look up the vhosts to verify if there is a reference present over here.

So, I can see that the files with the variables are being used in multiple locations. So, I will have to go ahead and filter of my file from all of these different discrepancies. So, this is something which I would have to do. So, if you want to define your custom variables you should create a file call it custom.vars and you need to include that within your virtual hosts file as well. Now, another thing which I might want to do is remove the whitelisting. Again, I can simply go to conf.d whitelist and remove the base white list rules from here.

Or I could just go ahead and remove the entire folder that is not needed and I can remove the whitelisting from my virtual host file once again. I will do a quick search and look for whitelists.

I do see the file being included over here, so I can simply go ahead and remove it. So, this is yet another change that I have done. Now, let’s look into another step.

Now we need to remove or replace any variables that are no longer needed. So, first of all, first and foremost we need to rename, publish_ docroot to simply to docroot. Let’s find out where we have defined publish_ docroot So docroot is defined over here. I just need to rename it to docroot. And similarly, I need to also look for disp_ID. I will quickly go ahead and look for it over here.

It is defined over here, I can see and then I simply need to remove that entire section. We are in these remove function. Similarly, next thing is published force SSL. I will once again, do a Control + F to find this out in this file, and I can remove these section which I only escape. The last I can also remove publish whitelist enabled.

Right from here I will also remove the commented-out part so that this particular portion is completely, I’ll save my changes.

Now as an intermediate test, I can simply run dispatcher validator to find out any errors that might have predicted while I was working on this particular file. So, this is how you can modify a dispatcher configurations to fit the dispatcher configuration for AEM as a Cloud Service. Our work is not yet done, there is still a lot of things that you need to do. You still need to remove the non-publish farms. Rename the farm file, check the cache and all of the steps that we have skipped over. I would suggest you to give yourself enough time and go over all of these steps, if you intend on converting your AMS configuration by yourself to fit AEM as a Cloud Service. The link to this particular documentation will be provided right after this video via the lecture. So, we have given, or I have given you guys a small overview of how to migrate dispatcher configuration from AMS to AEM as a Cloud Service.

So now you should be able to explain the process of migrating the dispatcher configuration from AMS. Thank you very much for watching this video and have a nice day -