Publishing XML and Other Data With the WAS Liberty Profile


Since CLM now ships the WebSphere Application Server Liberty Profile as default, you might want to be able to publish XML and other data similar to the easy way that was available in Tomcat, by just using the application server that is available. This avoids having to set up an additional Web or application server.

Problem

Sometimes it is necessary to provide access to some files using the HTTP/HTTPS protocol.

This is interesting for the Process Enactment Workshop, or if you want to publish your own XML data to be used with HTTP Filtered Value Sets, host custom Doors Next Extensions, or if you want to publish Build results.

It is convenient if there is already an application server available to host these files there and make them accessible, instead of having to set up a web server. This especially holds if it is necessary to provide the data using HTTPS, and not HTTP, because browsers these days reject to process content that is mixed from HTTP and HTTPS sources. The latter is important for Doors Next Generation extensions. Not having to set up a new server also avoids having to create a trusted certificate for it. It reduces the additional failure point, backup and maintenance and provides URI stability as well, since you don’t want to change the URI for the CLM applications hosted anyway.

Tomcat

With Tomcat, it was relatively easy to do that, by just adding a folder under \tomcat\webapps and placing your files there. Assuming the folder name is myfiles, Tomcat then provides the files with the public URI root https://serverpath:port/myfiles/fileName.

Another way was to simply drop the file into the tomcat/webapps/ROOT/ or a sub folder, which has the same effect.

Is there a similar way to achieve this with the WAS Liberty Profile shipped with CLM?

Example Scenario

Lets assume, like in the scenario explained in Publish and Host XML Data Using Tomcat – The Easy Way, we want to publish a file makers.xml to be accessible with a context root PEWEnactmentData on the server with the public URI root https://clm.example.com:9443/.

The expected outcome is to be able to access the XML file content using the URL https://clm.example.com:9443/PEWEnactmentData/makers.xml.

Solutions

There are two relative simple solutions for WAS Liberty. The solutions below are based on information from Lars, one of our WebSphere experts and the IBM WebSphere Application Server Liberty Profile Guide for Developers.

For WAS Liberty Profile, all solutions require to deploy an application. There are several ways to create and deploy an application in WAS Liberty Profile.

  1. Deploy an application in some folder and declare the context root and location of the application in the server.xml or specific location XML file
  2. Deploy an application in the dropins folder; for this to work, it is necessary to make sure the application server has the dropins monitoring enabled for this to work

Deploying an application in this context means

  1. Create a folder with some contend in a location (or copy the folder into the location)
  2. Deploy a compressed folder with some content

Please note: Any changes to any of the server configuration XML files are automatically picked up be WAS Liberty Profile. There is no need to reboot the server for the steps below to work.

1. Deploying an Application – Standard

The trick in this solution, is to pretend to deploy an uncompressed Web Application such as a WAR file. It is obviously possible to create a real WAR file or the structure that is contained in it, but that is not really necessary. See the last section here if you are interested in deploying the application as compressed WAR file.

1.1 Deploying the Application

The only thing necessary to trick the WAS Liberty Profile into making the data available with a correct context root is to create a folder with the context root as name and an extension .war, and to make the application location known in an XML file.

In the default setup of WAS Liberty Profile with CLM, after the first launch, all installed CLM applications end up in the folder <Install Folder>\server\liberty\servers\clm\apps. The screen shot below shows this structure.

FolderStructure

The applications are deployed as compressed WAR file and have been extracted to a folder with the name of the application. As an example the CCM application (RTC) came shipped as ccm.war.zip and was extracted to a folder ccm.war. The context root of the CCM application is ccm, which is basically the name without the extension war. The same pattern holds for all the other applications.

It is possible to create a folder to host the files to be published. The folder should be named <context root>.war to result in an application with the desired context root.

Files within this folder will be available with their file name.

A file in that folder with the name <filename> will be accessible as <public URI root>/<context root>/<filename>.

If the files are within sub folders, the folder path within the root folder and the file name compose the file name part of the URL. For example, the root folder has a sub folder names myfiles and a file test.xml in it, the file is accessible as <public URI root>/<context root>/myfiles/test.xml.

In our example with the given public URI root being https://clm.example.com:9443/, the folder name <context root> being PEWEnactmentData and <filename> being makers.xml the URL would be https://clm.example.com:9443/PEWEnactmentData/makers.xml.

1.1 Declaring the Application Location

The WAS Liberty Profile needs to know which application has to be published and where to find its resources. WAS Liberty Profile defines an XML element to declare which application is located where. The element is <appliction…./>. It supports various attributes and can come in many different forms. The most important attributes are

  • id: Must be unique and is used internally by the serve
  • location: The path to the application resource
  • context-root: The context root of the application
  • name: The name of the application
  • type: Specifies the type of application (war or ear)

The location and ID is required and either the name equal to the context root, or the context-root can be provided. The type can be omitted. I did not provide the ID and it worked for me, but since the server requires it, it should be provided. Use the same value as the name or context root for the ID.

It is necessary to add the application declaration to the server configuration for example by adding it to the server.xml file. In a CLM deployment a file appliction.xml is included in the server.xml, declaring all the applications and it makes sense to use that file instead.

Save the xml files after any change to activate the new setting. The server will pick up the change.

2. Deploying an Application – dropins

The WAS Liberty Profile has the capability to monitor a special dropins folder on a regular basis. If new content is detected, it is automatically made available by the server. The automatic monitoring needs to be enabled for this to work. A standard CLM deployment disables the monitoring to reduce server load.

2.1 Deploying the Application – dropins

In a default CLM install the dropins folder is located here:

<Install Folder>\server\liberty\servers\clm\dropins

Create a folder named <context root>.war in the dropins folder and add the files to publish. After detecting the addition, the files will be accessible like explained in 1.1.

The folder <Install Folder>\server\liberty\servers\clm\dropins should now look like below.

Published application with file

2.1 Enable Automatic Monitoring for Dropins

The automatic monitoring of the dropins folder is disabled for a standard CLM setup with WAS Liberty Profile. This saves processor cycles and I/O for the server operation. It has to be enabled once in the server.xml file for this solution to work. Find the XML element <applictionMonitor> and change the attribute dropinsEnabled from “false” to “true” and save the file. The image below shows the changed configuration file.

Enable Dropins Monitoring

The attribute pollingRate determines how often the server checks the location for changes. Adjust the value to your needs.

Save the server.xml file after any change to activate the new setting. The server will pick up the change.

The XML file content should now be accessible.

Example 1 – Standard

In the example we want to publish a document with the URI https://clm.example.com:9443/<context root>/makers.xml, where <context root>=PEWEnactmentData. The public URI root is already given by the server set up.

1.1 Create the “Application”

As first step create the application. Create a new folder named PEWEnactmentData.war in the folder <Install Folder>\server\liberty\servers\clm\apps. The folder could be created anywhere, but it makes sense to put it where the other applications are. If it is necessary to use a different folder, for example to allow other users to modify the content, place the folder in a different location and note the path. The path to the location will become important in the next step.

Put the files to be published underneath this folder. In the given example, put the file makers.xml into the folder.

The folder structure should look like the image below:

New Application folder

1.2 Publish the “Application”

The WAS Liberty Profile needs to know which application has to be published and where to find its resources. WAS Liberty Profile defines an XML element to declare which application is located where. The element is <appliction…./>. It supports various attributes and can come in many different forms. The most important attributes are

  • id: Must be unique and is used internally by the serve
  • location: The path to the application resource
  • context-root: The context root of the application
  • name: The name of the application
  • type: Specifies the type of application (war or ear)

The location and ID is required and either the name equal to the context root, or the context-root can be provided. The type can be omitted. I did not provide the ID and it worked for me, but since the server requires it, it should be provided. Use the same value as the name or context root for the ID.

The element can be put into several places. In a CLM installation, by default, the applications are declared in the file

<Install Folder>\server\liberty\servers\clm\conf\application.xml

The file is included in the file <Install Folder>\server\liberty\servers\clm\server.xml. It would be possible to place the application declaration in the file server.xml, but it seems to make more sense to put it into the file application.xml instead.

Add lines

<!–  My Application –>
<application id=”PEWEnactmentData” name=”PEWEnactmentData” location=”${server.config.dir}/apps/PEWEnactmentData.war”/>

to the file application.xml and save the file.

The file should look like below:

Declare new Application

In this case the location is relative to the server configuration folder which n our case is <Install Folder>\server\liberty\servers\clm\. The location could really be anywhere. If it is necessary to include a folder that, as an example, can be accessed by regular users, you could change the location to somewhere with less read and modification restrictions.

After the save of the application.xml, the published XML file should be accessible using the URL https://clm.example.com:9443/PEWEnactmentData/makers.xml.

The image below shows the browser access.

Browser Access To XML File

2. Deploying an Application – dropins

In the example we want to publish a document with the URI https://clm.example.com:9443/<context root>/makers.xml, where <context root>=PEWEnactmentData. The public URI root is already given by the server set up.

2.1 Create the “Application”

As first step create the application. Create a new folder named PEWEnactmentData.war in the folder <Install Folder>\server\liberty\servers\clm\dropins.

Put the files to be published underneath this folder. In the given example, put the file makers.xml into the folder.

The folder structure should look like the image below.

Published application with file

Assuming the automatic application monitoring is enabled, the file should be accessible after the next polling cycle, (at least after waiting the full pollingRate). If automatic application monitoring is not enabled, enable it as described in 2.2 and save the configuration file.

The XML file content should now be accessible using the URL https://clm.example.com:9443/PEWEnactmentData/makers.xml.

Deploying Compressed Folder Structures

It is also possible to publish real WAR, EAR similar to the way described above. For example create a WAR file as described in Publish XML Data Using Tomcat – Hotfix for The Process Enactment Workshop and attached to that post. Deploy the compressed WAR file, for example PEWEnactmentData.war in the dropins folder or declare it as an application and put it onto another location like explained below. This automatically deploys the application and makes the contained files accessible.

Just zipping the folder structure we created above into a zip file, name it PEWEnactmentData.war and trying to deploy does not seem to be working however. The WAR file needs to provide required supporting structures in this case.

Related Posts

The RM Extensions Hosting Guide for CLM 6.0.1 and later versions explain the dropins example as well.

Summary

This post shows how easy it is to publish supporting files on the WAS Liberty Profile. This is important if you want to host custom Doors Next Extensions, or if you want to publish your own XML data to be used with HTTP Filtered Value Sets, for the Process Enactment Workshop and it can possibly also used with Build result publishing. In the latter case, you would likely publish a root folder that contains all the build results.

As always I hope this post has some value to users out there, or is at least interesting to read.

Advertisements

Publish and Host XML Data Using Tomcat – The Easy Way


Why I missed this easy solution beats me, however, as my team mate Freddy points out in his (e-mail) answer to my comment on his blog about HTTP Filtered Value Sets it is even easier to publish XML data – or any other data – on Tomcat than by creating a web application as described in my last post.

* Update *: See Publishing XML and Other Data With the WAS Liberty Profile for how to do this with the WAS Liberty Profile.

Solution

Basically what you have to do is to publish it in the folder $CATALINA_HOME/webapps/ROOT/. In the context of a Jazz Team Server that is the folder /server/tomcat/webapps/ROOT/. If you have a file test.xml you want to publish on your Tomcat server you can copy it directly into that folder or into a sub folder structure.

Example

To publish the given file makers.xml from the last post as  https://localhost:9443/PEWEnactmentData/makers.xml, assuming a standard Jazz Tomcat deployment.

  • Create a folder PEWEnactmentData in the folder <InstallDir>/server/tomcat/webapps/ROOT/
  • Copy the file makers.xml into the newly created folder

The File is now accessible as https://localhost:9443/PEWEnactmentData/makers.xml as intended. Replace localhost with your fully qualified hostname in your deployment.

Note: Please make sure that your Folder Name does not conflict with the context root of any web application you have deployed on Tomcat.

Summary

Given this approach it is as easy to use Tomcat to maintain your data for HTTP Filtered value providers as using Apache.

This is also a good example how hard it can be to find information in the Internet. I tried to search for publishing XML on Tomcat with what I learned from Freddy, and I did not find an answer to the question really. All the discussions are around deploying applications.

Publish XML Data Using Tomcat – Hotfix for The Process Enactment Workshop


Can you publish XML files for the HTTP Filtered Value Set on Tomcat? This was a question I asked myself when working on Lab 4 of the Process Enactment Workshop. My first answer, and also response to this forum question was: No.

Dead Wrong. It is of course possible to do so. I just did not know how to do that. This post shows how you can indeed do this.

You can download a WAR File that contains the data for the Process Enactment Workshop here.

* Update *: See this post for an even easier way to publish your data on Tomcat.

* Update *: See Publishing XML and Other Data With the WAS Liberty Profile for how to do this with the WAS Liberty Profile.

Background

I needed to provide an example for the HTTP Filtered Value Set in the workshop. Since this Value Set requires the XML published by a HTTP server, I basically saw two options: download and install Apache as described here, and place the XML document into the htdocs sub-directory for publishing. I could also use an existing example like http://cars.flashmx.us/makes. I did not want to add the effort and time to install Apache, even if it is quite straight forward. I thought about publishing on Tomcat but digging the internet did not show an easy way to do it. So I chose to use http://cars.flashmx.us/makes. Some days ago the inevitable happened. That web site does not provide the information I need any longer.

Available Options

Now I was again down to the two choices:

  1. Install Apache
  2. Find a solution with Tomcat.

I still did not like the Apache solution, at least for the workshop, as it adds a lot of waiting time due to the install, although I will describe it shortly below. So I decided to take a deeper look at Tomcat. I found a relatively easy solution to make it possible with Tomcat too.

Apache Solution

Download and install Apache, e.g. into the folder C:/Apache and provide a reasonable host name during the install. After the install is done, by default the sub-directory C:/Apache/htdocs is used as root for publishing. If you run C:/Apache/bin/httpd and place a document, for example makers.xml into the folder it is accessible as http://:8080/makers.xml and you are done.

Install Apache HTTP Server

Install Apache HTTP Server

You can easily maintain the documents there, update them and as long as the server is accessible use them in an HTTP Filtered Value Set.

Tomcat Solution

With Tomcat it is not quite that easy to create a solution, but if you have Tomcat already installed, once you have a solution, it is just trivial to deploy and use.

1. Install

Install The Web, XML, and Java EE Development Tools as described in the Process Enactment Workshop Lab 5, at the beginning.

Select Help>Install New Software and add an update site. I used the Helios Update Site for RTC 4.0. up to 4.0.3 vanilla zip install. Make sure to pick the right version for your Eclipse version. Select the update site. Select and install the whole package Web, XML, and Java EE Development Tools, not just JavaScript. Restart Eclipse.

I tried to use the Tomcat that comes with RTC for testing, but had issues, so I would suggest to Download a vanilla Tomcat for testing. I used the ZIP version and unpacked it into the folder C:/Apache Tomcat.

Tomcat Installed

Tomcat Installed

2. Create Dynamic Web Project

In your Eclipse RTC Client open the J2EE Perspective. Use File>New>Dynamic Web Project to create a new project.

Create Dynamic Web Project

Create Dynamic Web Project

In the wizard enter a project name. Check the default settings and create a new Target Runtime based on Tomcat v7.0 or whatever version you are using.  As Tomcat Installation Directory provide C:/Apache Tomcat or wherever you installed to. Back in the wizard should show something similar to this image.

Dynamic Web Project Wizard Step 1

Dynamic Web Project Wizard Step 1

Click Next until you reach the wizard page Web Module.

If you want to fix your context root, you can do that now. The context root is the name of the folder in which the data will later be published to the web. It is case-sensitive and you need to remember the name later. In my example my data will be published at HTTPS://:9443/PEWEnactmentData/ once I deploy on my RTC Tomcat. Make sure to choose WebContent or webcontent in the Content Directory. Check Generate web.xml deployment descriptor. See the image below as example.

Dynamic Web Project Wizard Web Module Page

Dynamic Web Project Wizard Web Module Page

Press Finish.

You have now successfully created a Dynamic Web Project, that will later be used to publish the content.  Browse the project. You are only interested in the folder WebContent.

New Web Project

New Web Project

3. Provide The Data

You now need to provide your XML data. Put the file you want to publish into the folder WebContent. To make it easier for users to locate the files I added a file index.html too. This file just has some text that points to the XML files that are hosted. The link is relative as shown in the screenshot below.

Project With Data Ready To Publish

Project With Data Ready To Publish

4. Publish And Test

Now that you are ready to publish and test, select the Project node and use the context menu to run it on your test server.

Run On Server Step 1

Run On Server

In the Wizard check that he correct runtime environment is selected and that the configuration works. Press Next and check your project is Configured to be deployed. Press Finish.

Your Server starts and after a few seconds the index page should come up like below.

Your Web Site

Your Web Site

You can click on the link in your index page to bring up your xml code. If you don’t have an Index.html, you can directly open your XML page. For example using the URL http://localhost:8080/PEWEnactmentData/makers.xml.

Now that everything works, you are ready to export the project and deploy it on your RTC Tomcat server.

5. Create A War File and Deploy

Right Click on your project again. Select Export>WAR file Enter a suitable destination folder. You can directly export into the /server/tomcat/webapps folder if you like. I chose a temporary folder. You can play around with the other options too e.g. if you want to deploy on WAS. Press Finish to run the export.

Export WAR File

Export WAR File

If you have exported to /server/tomcat/webapps you have already also deployed. If not, copy and paste your war file into /server/tomcat/webapps. If the server is running the deployment process starts right away. If not, start the server.

Once the server is up, you should be able to open your web resources using your server URL and the context root you chose. In my example https://localhost:9443/PEWEnactmentData opens the index page and https://localhost:9443/PEWEnactmentData/makers.xml opens the XML file.

Configuring the HTTP Filtered Value Set

Please be aware, that if you use HTTPS with your HTTP Filtered Value Set, you might have to check the check box to Ignore  invalid SSL certification if you did not fix your certificate.

Summary

I hope I could show that it is easily possible to store your XML files required for access from an HTTP Filtered Value Set. I have to go now and fix the Process Enactment Workshop.