Building a Custom Servlet for SDL WorldServer

12 Jun 2017

SDL WorldServer allows customers to expand WorldServer capabilities through pluggable components. There are several exit points in WorldServer through which custom code can be invoked to perform customer-specific operations.

Here are the types of pluggable components currently supported:

AIS Triggers: AIS stands for Asset Interface System and is the framework WorldServer uses to access content whether that content is in a content management system, a file system, a database, etc. Through a customized AIS trigger, it is possible to execute customer-specific actions in response to specific AIS-related events.
Automatic Actions: customized automatic actions to be executed within a WorldServer workflow.
Authentication: can be used to override the default password validation strategy.
Filters: allow the support of new types of assets within WorldServer.
Notification Service: allow email messages to be customized.
Servlets: customized WorldServer-aware servlets.
TM Services: TM stands for Translation Memory. It is possible to provide alternative services to be used in place of the exposed TM services.

Developers use the SDL WorldServer Software Development Kit (SDK) to write these pluggable components. The implementation begins by extending an abstract class corresponding to the type of component you want to create. For example, the com.idiominc.wssdk.component.servlet.WSHttpServlet abstract class needs to be extended in order to implement a customized servlet.

The abstract classes provide us with a handle to the WSContext object, which provides us with access to the service managers.

I've implemented a very simple servlet for demonstration purposes. I'm using Maven in my project, so I first installed the wssdk-server jar file in my local repository using the following.

mvn install:install-file -Dfile=wssdk-server.jar -DgroupId=com.idiominc -DartifactId=wssdk-server -Dversion=11.1.0.3909 -Dpackaging=jar

There are only two dependencies in the pom.xml file.

<dependencies>
    <dependency>
        <groupId>com.idiominc</groupId>
        <artifactId>wssdk-server</artifactId>
        <version>11.1.0.3909</version>
    </dependency>
    <dependency>
        <groupId>javax.servlet</groupId>
        <artifactId>javax.servlet-api</artifactId>
        <version>3.1.0</version>
        <scope>provided</scope>
    </dependency>
</dependencies>

The ProjectInfo servlet outputs project information from all projects available in the system (active and inactive). It demonstrates the use of the user and workflow managers for gathering information.

ProjectInfo.java

Deploying the custom servlet

The steps for installing the custom servlet include:

Creating a WorldServer component deployment descriptor
Creating a component archive (zip file) containing the component classes and, if required, including all of the non-WorldServer library dependencies.
Using the WorldServer UI to deploy the component.

The component descriptor is an XML file that provides WorldServer with the information needed to identify and register the uploaded component. Only one descriptor file, named as desc.xml, is provided per deployment. If your project contains multiple implementations (i.e. servlets, filters), all references are included within a unique descriptor file.

The contents of my project's desc.xml is shown below.

<components>
    <servlet class="com.worldservertraining.ProjectInfo"/>
</components>

Create a zip file containing the XML descriptor file and your classes. Note that the desc.xml file must be at the base of the zip file. In addition, your Java classes must be placed in the zip file under the appropriate Java package structure. There cannot be any jar or zip files inside your deployment zip file. In order to use supporting libraries in your projects, you can either expand these supporting libraries in your zip package or have them added to WorldServer's classpath.

Once the zip package is ready, you can use WorldServer's UI to deploy your customizations. Your WorldServer user will need to have the right privilege to perform the following steps.

Login to WorldServer and click the Management option.

Click the Administration option.

Click the Customization option.

Select the appropriate component type and click the Add button to upload your zip package. If your deployment includes components of different types, select any option from the drop-down. WorldServer will workout the components from the descriptor file anyway.

Once uploaded, providing no errors are displayed, you should see your customizations listed as shown below.

The Name, Description and Version properties are taken from the respective properties in the bespoke component object.

Testing the custom servlet

Of course testing depends on the type of component you have deployed. For instance, an automatic action (auto_action) component will require an association with a workflow step for testing to work.

Invoking a servlet involves requesting the following URL.

http://localhost:8080/ws-legacy/ws_ext?servlet=<servlet_name>

Therefore, our ProjectInfo servlet would be requested using:

http://localhost:8080/ws-legacy/ws_ext?servlet=project_info