Cloud 5 AEM Dispatcher Validator

Transcript

So, hey James, how you doing? Hey, I’m great, Darren. How are you doing? Good to see you. I’m doing good. Good. You know what I’d like to cover today? How about we talk about the dispatcher valet here? Darren, you’re breaking up. I can’t quite hear you. Still here? Hello? No, I can’t hear you. Can you see me? Hello? Hello? Adobe Experience Manager’s dispatcher is an Apache HTTP web server module that provides a security and performance layer between the CDN and the AEM published here. The dispatcher is an integral part of the overall Experience Manager architecture and should be part of the local development environment set up for AEM as a cloud service. Now, a dispatcher configuration that is not valid will interrupt that cloud manager pipeline, so it’s really important to validate that code locally before checking it in. You can also run a web tier pipeline to avoid getting the dispatcher configuration mixed in with other code using some of the new functionality of cloud manager, but regardless, it’s still a really good idea to test that dispatcher configuration locally. The dispatcher SDK itself provides you a dispatcher configuration, which is just simply a vanilla file structure containing the configuration files to include in a Maven project for the dispatcher. It includes the dispatcher validator, which is the focus of this video, which is tooling for customers to validate a dispatcher configuration locally. And it also includes a dispatcher Docker image, which is a Docker image that brings up the dispatcher locally, simulating that AEM as a cloud service environment. Once you have downloaded, unzip it to a folder and navigate to the dispatcher SDK folder that is created. Let me show you exactly how that’s done. So as you see, I’m at my command line and I’m going to simply navigate to the dispatcher folder and I’m going to run this command. ./bin validator full d out is where I want it to go and source is my dispatcher configuration. You’ll see it runs with absolutely no issues found. Let’s take a look at those different directories. So here is my source directory. This is where my dispatcher configuration is. And then you will see the out directory. And what the out directory has done is it’s taken those configurations and turned this into a file set compatible with the Docker containers, HTTP Apache Web Server. So pretty cool. Hey, Darren, any questions so far about this? So how do I troubleshoot any errors that crop up when you run the validator? Good question, because you can get some wonky errors with these dispatcher configuration files for sure. So again, if you look at this link here, you’ll see some of those errors and some really great tips that the Experience League team has developed for troubleshooting these errors. So the AEM dispatcher itself is run locally using Docker against the SRC dispatcher, which I showed you in the video, and the Apache Web Server configuration files. The AEM is a cloud service SDKs published service, runs local on port 4503. But when you run it through the dispatcher, it automatically sets it to run here under 8080. So here you’ll see localhost 8080. So to run these dispatcher tools against an experience manager project dispatcher configuration, all you have to do is point your projects dispatcher to the SRC folder, just as you saw on the video. The dispatcher logs are helpful during local development to understand if and why the HTTP requests are blocked. The log level can be set by prefixing the execution of Docker underscore run with environment parameters. Now the dispatcher tool logs are admitted to the standard out directory when Docker underscore is run. So there’s some useful parameters here for actually debugging the dispatcher. First of all, you can control the log level under DSP underscore log level. And this the default is warn, but you can set it to other log levels. There’s also a rewrite log level, which sets the HTTP Web Server rewrite logging to debug. And this is again, the default here is warn. And then you also have a run mode configuration, which sets the run mode so you can simulate what happens, whether you’re using again, dev stage or prod. And in this case, it defaults to dev. All of these different things help you really simulate the AEM as a cloud service environment locally, so you can do as much debugging as possible.