Skip to main content

SDL Web 8 - The "Discovery" Microservice

One of the microservices I was describing in my post Content Delivery Microservices is the Discovery Service. This post describes what the service does and provide a step-by-step installation guide.

The Discovery service is a new addition to the set of functionality in Tridion. It is a REST service that provides information about the capabilities of a given content delivery environment. A capability represents a Content Delivery module that is exposed itself as a REST service (i.e. the other CD Microservices of SDL Web 8). The Discovery service knows about each capability in a given environment and exposes this information in its methods.

For example, if a content delivery environment has capabilities Deployer and Dynamic Content, the Discovery service will provide the calling client the information about their endpoints, such that other systems discover what capabilities are available in a given environment, and what are their endpoints, so that they can communicate with these modules. We will see in a subsequent post, how this works in more detail using the New Way of Publishing and the Topology Manager.
Top level XML response of Discovery service

The Environment metadata provides the actual access to the individual capabilities:
Details of the available capabilities

The Discovery service is a server role, running either as a standalone or Windows service Spring Boot package. By default, it contains an embedded Apache Tomcat instance, which makes it very easy to install and get running.

Discovery service uses a Content Delivery database to persist the information about each configured capability in its environment. Therefore, we need to configure node Storage in cd_storage_conf.xml, as well as the individual installed capabilities. These capabilities are in the form of URL endpoints, which define each capability as REST service, a client id and possibly an OAuth secret.

In order to install it as Windows service, the user should execute the .\installService.ps1 PowerShell script:
PowerShell installation script

Also it is possible to run Discovery service in secured mode, using the OAuth protocol. In order to configure it, modify file cd_ambient_conf.xml.
OAuth configuration section cd_ambient_conf.xml

It is possible to run it also as HTTPS, however, due to additional hassle with certificates, SDL recommends to use a reverse Proxy, instead in front of it and to secure the connection at the proxy level.

Lastly, we can start the SDL Delivery Discovery Services Windows Service.
Discovery Service running as Windows Service

Once all configurations are done and the Discovery service is up and running, we need to store the information about each capability in this environment into the Discovery Content Delivery database. In order to do so, we use a utility JAR, named discovery-registration.jar, using the following command line (I ran it from the /config folder of the Discovery Service installation):

    java -jar discovery-registration.jar

This utility reads the capability configurations defined earlier in cd_storage_conf.xml and performs an HTTP POST to the Discovery service, which will then store them in the Content Delivery database. The fact that it is possible to send these configurations over the wire and instruct the Discovery service to persist them in its database, represents a nice step towards modular/self-configuring services and it opens up the scenarios where this can be used in the future.
Execution of the discovery-registration.jar

For the inner geek, this is a little snapshot of how the configurations look like when stored in the Discovery database:
Capabilities persisted in Discovery Service database


Jordan said…
Interesting points here! It's important to understand this process in these microservices. Thanks for sharing!

Popular posts from this blog

Running sp_updatestats on AWS RDS database

Part of the maintenance tasks that I perform on a MSSQL Content Manager database is to run stored procedure sp_updatestats . exec sp_updatestats However, that is not supported on an AWS RDS instance. The error message below indicates that only the sa  account can perform this: Msg 15247 , Level 16 , State 1 , Procedure sp_updatestats, Line 15 [Batch Start Line 0 ] User does not have permission to perform this action. Instead there are several posts that suggest using UPDATE STATISTICS instead: I stumbled upon the following post from 2008 (!!!), , which describes a way to wrap the call to sp_updatestats and execute it under a different user: create procedure dbo.sp_updstats with execute as 'dbo' as

Debugging a Tridion 2011 Event System

OK, so you wrote your Tridion Event System. Now it's time to debug it. I know this is a hypothetical situtation -- your code never needs any kind of debugging ;) but indulge me... Recently, Alvin Reyes ( @nivlong ) blogged about being difficult to know how exactly to debug a Tridion Event System. More exactly, the question was " What process do I attach to for debugging even system code? ". Unfortunately, there is no simple or generic answer for it. Different events are fired by different Tridion CM modules. These modules run as different programs (or services) or run inside other programs (e.g. IIS). This means that you will need to monitor (or debug) different processes, based on which events your code handles. So the usual suspects are: dllhost.exe (or dllhost3g.exe ) - running as the MTSUser is the SDL Tridion Content Manager COM+ application and it fires events on generic TOM objects (e.g. events based on Tridion.ContentManager.Extensibility.Events.CrudEven

Content Delivery Monitoring in AWS with CloudWatch

This post describes a way of monitoring a Tridion 9 combined Deployer by sending the health checks into a custom metric in CloudWatch in AWS. The same approach can also be used for other Content Delivery services. Once the metric is available in CloudWatch, we can create alarms in case the service errors out or becomes unresponsive. The overall architecture is as follows: Content Delivery service sends heartbeat (or exposes HTTP endpoint) for monitoring Monitoring Agent checks heartbeat (or HTTP health check) regularly and stores health state AWS lambda function: runs regularly reads the health state from Monitoring Agent pushes custom metrics into CloudWatch I am running the Deployer ( installation docs ) and Monitoring Agent ( installation docs ) on a t2.medium EC2 instance running CentOS on which I also installed the Systems Manager Agent (SSM Agent) ( installation docs ). In my case I have a combined Deployer that I want to monitor. This consists of an Endpoint and a