Hello everyone. My name is Varun Mitra and welcome to the video. In this particular lesson, we are going to talk about managing dispatcher configuration in Cloud Manager for AEM as a cloud service. After completing this training, you will be able to manage the dispatcher. So now let’s just quickly go ahead and see how you can set up the dispatcher configuration for AEM as a cloud service instance. So right over here, I have got some sample dispatcher configuration. This particular dispatcher configuration, if you observe, looks different from a normal dispatcher configuration. Configuration here is spread across two different folders, conf dot d, and conf dot dispatcher dot d. Conf dot d folder contains your Apache server configuration, and conf dot dispatcher dot d contains your dispatcher configuration. If I were to go inside conf dot d, it further contains different other folders. You have got available VHost and enabled VHost folder, which I use for maintaining your virtual host configuration. Rewrite rules are defined within the rewrite folder, and variables contains some global and custom variables that you can use. Dispatcher underscore VHost dot any file is a sample file, which allows you to verify the VHost configuration. Now, if I were to go to the enable VHost folder, I would see that there is a default dot VHost file. This particular file basically points to the available VHost folder. So, let’s go to the available VHost folder and verify. So, within available Vhost, I’ve got the default dot Vhost file. If I want to define any more virtual hosts, I should create a copy of this file and include the new file within the default VHost that is available to me in the enable Vhost folder. Because default Vhost file should not be changed, as changes done within this default VHost file will have no effect. I should basically create a new copy or define a new VHost file and include it within the enabled VHost.

Similarly, if I were to go to the rewrites rule, I would see that there is a file that is default rewrite rules. They are loaded up when Apache server is loaded for the very first time. I should not do any changes in here. If I have any changes that need to be done in the rewrite rule that they should be done within this rewrite dot rules file. This particular file can be modified by the end user.

Similarly, I have got different variables. I have got global variables and custom variables within global variables. I can set the log level. For example, I can change the dispatcher log level from here. Or I can also define some custom variables which I can then later on use, within different files. So, this is how the different files can be defined within your conf dot d folder. Now I can also go to the conf dot dispatcher dot d folder. It has a very similar structure. I have got an available farm wherein I can define different farms, cache folder which defines my cache definition client headers. We defined client headers, enabled farm, which is very much similar to enabled Vhost. Which just contains the same link to the available farms folder.

Filters, renders, and virtual host, which allow me to define filter definition, renders, and what virtual host for my dispatcher. If I were to go to the available farm I have the default dot farm file over here. Again, this is an immutable file. It should not be changed. If I want to do any changes, I should add a new file in here. And I should add a sibling within the enabled farms file. That is the enabled farms folder. Here I can add a sibling within the default dot farm folder. Now let’s look at the other folders as well. I have the cache folder. If I want to define any new custom cache rules, I can put them in rules dot any. Default underscore rules dot any, and default underscore invalidate dot any are default files that should not be changed. They are deemed immutable.

Similarly, for client headers my changes should be done in client headers dot any. I should not do any changes in default underscore client headers dot any file, as this is an immutable file. Similarly, within my filter definition or my filter section I can do my changes in filters dot any, and I can define, or I need to include default underscore renders dot any file. Now renders will point to my available published servers, or my available office server. As such, this particular file should not be changed by the end user. This is supposed to be changed by the Cloud Manager itself or by the managed services team. So do not make any changes in default underscore renders dot any. This is specific to the environment and internal IP address are always kept private.

Similarly, we have virtual hosts. I can do my changes in virtual host dot any file.

So, these are my dispatcher configurations, and they look a bit different from your traditional dispatcher configuration. Just keep in mind that certain files are deemed immutable and should not be changed by the end user. If you were to do any changes, they will have no effect. And certain files are mutable. For example, you have got your rules dot any file, which is a mutable file, which you can change it your way. So do your changes in the mutable file, avoid doing any changes in the immutable. Now, in order to make it easy for an end user to use or define dispatcher configuration, our engineering has created a simple dispatcher SDK. You can download the dispatcher SDK. It comes along with the sample dispatcher configuration. It also comes along with a dispatcher validator. This validator, when run, will allow you to validate your dispatcher configuration. Not only you can validate your dispatcher configuration, you can also generate the specific dispatcher configuration which you can then later on use within your environment or for your testing purposes. It also comes with a docker image, which will start up the Apache server with the generated dispatcher configuration for testing purposes. By default, it can point to your local published server, or a published server that is running in cloud. And then you can test out these dispatcher configurations using the published environment. Then you can quickly execute this dispatcher SDK. So, this is my dispatcher SDK. What I’m going to quickly do is I’m going to launch the command prompt right over here. In order to execute my dispatcher validator, I can quickly invoke it with the help of a very simple command. So, I’m going to quickly put in my command over here. What this command will do is it will invoke the exe file, and it will run my dispatcher validator. It is taking into account my src folder, which contains my dispatcher configuration, and it is going to generate some output in my output folder. Let me quickly run this. You can see that it provided me with some output that is, no issues found, dump folder already exists and non-empty. Let me delete the out folder from here, and restart.

It will generate a new out folder with a file that contains my dispatcher configuration. Now, in order to show you where the dispatcher validator will throw errors, in case of incorrect configuration, let me quickly pick up another dispatcher configuration and provide that as an input. So instead of the src folder, I provide another folder which contains my dispatcher configuration And once that it run, it will throw some errors. So, let me quickly provide the folder name over here.

As you can see, my dispatcher validator threw a bunch of errors, as these particular configurations were not compliant with the guidelines provided for AEM as a cloud service. I would have to make these changes if I want these configurations to be deployed.

So, this is how you can use dispatcher validator to test out you dispatcher configurations. If you want, you can also deploy the docker image, and test out these configurations directly on your local instance. You will need to deploy docker on your machine in order to run the docker validator.

So, this is how you can manage dispatcher configuration for AEM as a cloud service.

So now, you should be able to manage the dispatcher configuration. Thank you very much for watching this video and have a great day. -