In enterprise environments there is a high chance of having your SDL Tridion Content Delivery side being hosted on an IBM WebSphere Application Server infrustructure.  Setting up the Tridion Cache Channel Service should be done via the Java Messaging Service at places where such infrastructure exists: the client invested a lot into it probably for a good reason and failover is most likely a key requirement.  In this article we’ll take a look at how to set up the Tridion Cache Channel Service using JMS on IBM WebSphere Application Server (WAS).

IBM WAS is a very robust and complicated product, especially when you get into server clustering.  So I’m not going to try and claim to be an expert at it.  To be honest, I can barely click around that hideous interface without sounding like someone with a major case of Tourette’s 😉  So you’ll probably need to buddy up with an in-house WebSphere platform specialist to help out with the WAS/cluster configuration.

Note: this article is based on a configuration with WAS 7 and Tridion 2011 SP1 HR2.  However, the same (or very similar config) should work for Tridion 2013 and 2013 SP1.

There are several things you need to take into account when working with WebSphere’s Default Java Messaging Service which I’ll discuss here.  I do expect you, the reader, to understand how the Tridion CCS works at a high level, so first please read the Tridion documentation that’s available on SDL Live (http://sdllivecontent.sdl.com/LiveContent/content/en-US/SDL_Tridion_2011_SPONE/task_5757AEB2C06D427EA5A299FAB6165052).  Here I address items specific to WebSphere JMS configuration only.  So let’s get started.

WebSphere MQ is NOT Required

MQ is a separate product with bangs and whistles and is not required for Tridion’s CCS. SDL Tridion requires a standard JMS Provider, and every enterprise application server must have a JMS according to the JSR 914 specification.

WebSphere JMS is the default JMS provider that comes with the WebSphere Application Server. So you do not need any products beyond it.

The App Must be deployed as part of an EAR

The short story is that your web application must be part of an Enterprise Archive (EAR). You will not get away with just using a Web Archive (WAR).

The long story is that the WebSphere App Server supports Message Driven Beans only (AsyncJMS10MDB and AsyncJMS11MDB options). A Message Driven Bean is a type of Enterprise Java Bean (EJB), and EJBs must be part of the EAR in scope adjacent to the WAR. So the EJB spec must be created within the scope of the EJB Module file, not the Web Module (WAR). Here is a quick recap on all this J2EE goodness: http://docs.oracle.com/javaee/6/tutorial/doc/bnaby.html.

The conclusion is that an EAR file is required with an EJB module which specifies to use the MDB class provided by Tridion (in one of the JARs).

Tridion CCS Message Driven Bean Spec is Required

As mentioned above, you need to have an EJB module with the MDB spec that points to the Tridion MDB class.

Use Eclipse (or your favourite J2EE IDE) to create an EJB Project. This project only needs to have 1 XML file, which is the EJB spec. The Tridion jars (and the class where the spec will point to) will be part of the higher/common scope in the EAR.

The spec (inside ejbModule->META-INF->ejb.jar.xml):

<?xml version="1.0" encoding="UTF-8"?>
<!-- Copyright (c) 2003 Sun Microsystems, Inc. All rights reserved. -->
<ejb-jar version="2.1" xmlns="http://java.sun.com/xml/ns/j2ee"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd">
 <display-name>SimpleMessageJAR</display-name>
 <enterprise-beans>
 <message-driven>
 <display-name>SimpleMessageEJB</display-name>
 <ejb-name>SimpleMessageEJB</ejb-name>
 <ejb-class>com.tridion.cache.JMSBean</ejb-class>
 <messaging-type>javax.jms.MessageListener</messaging-type>
 <transaction-type>Container</transaction-type>
 <activation-config>
 <activation-config-property>
 <activation-config-property-name>
 DestinationType
 </activation-config-property-name>
 <activation-config-property-value>
 javax.jms.Topic
 </activation-config-property-value>
 </activation-config-property>
 <activation-config-property>
 <activation-config-property-name>
 Destination
 </activation-config-property-name>
 <activation-config-property-value>
 jndi/Tridion_Cache_Topic
 </activation-config-property-value>
 </activation-config-property>
 <activation-config-property>
 <activation-config-property-name>
 ConnectionFactoryName
 </activation-config-property-name>
 <activation-config-property-value>
 jndi/Tridion_Cache_Conn_Factory
 </activation-config-property-value>
 </activation-config-property>
 <activation-config-property>
 <activation-config-property-name>
 Transacted
 </activation-config-property-name>
 <activation-config-property-value>
 true
 </activation-config-property-value>
 </activation-config-property>
 <activation-config-property>
 <activation-config-property-name>
 DeliveryOption
 </activation-config-property-name>
 <activation-config-property-value>
 A
 </activation-config-property-value>
 </activation-config-property>
 </activation-config>
 </message-driven>
 </enterprise-beans>
</ejb-jar>

I’m working with the Tridion Documentation team to get this added to the official SDL Live docs, hopefully making this article obsolete once SDL Live is updated.

Configuration Tips:

• Follow the official documentation on SDL Live to configure the Object Cache in your cd_storage_config.xml file.
• In WAS, create a Topic Connection Factory and a Topic for your Tridion Cache Channel. (This is where your WebSphere specialist/admin buddy does his/her magic.)
• Make sure to enable cache logging as per this article: http://sdltridionworld.com/articles/sdltridion2011/analyzing_object_cache.aspx. You’ll be able to see if your cache config is working or not.
• Put the Tridion Content Delivery JARs in the EAR, not the WAR.
• Don’t forget to add your EJB module with the Tridion MDB spec to the EAR.
• Get a JMS Queue monitoring tool so that you can see the Tridion CCS invalidation messages get added and consumed in the queue.  HermesJMS is a really good one and it’s open source: http://www.hermesjms.com/confluence/display/HJMS/Home
  • Remember, if you’re testing the config in a Staging or new Production environment, there is a high chance that the JMS may be in a different network segment from your developer machine, so you won’t be able to use HermesJMS to inspect the queue.  Works wonders in Dev though!
• All instances of the Deployers and your web apps should have the Object Cache with RemoteSynchronization enabled.  The config should be something like the following, but do consult the official SDL Live docs for this:

<JndiContext>
 <Property Name="java.naming.factory.initial" Value="com.ibm.websphere.naming.WsnInitialContextFactory" />
 <Property Name="java.naming.provider.url" Value="corbaloc::myserver1:9814,:myserver2:9814" />
</JndiContext>

You should now be good to go and run some tests.

The Cache Channel Smoke Test

You need a baseline by which to tell whether CCS is working as expected.  Essentially, you need to ensure that when new content is published, old content gets invalidated and each web app’s object caches are updated.  Here is my simple test:

1. Publish a DCP until successfully deployed.
2. Hit a page on your site that retrieves the DCP and monitor the caching log to ensure it gets inserted into the Object Cache (see below for how to enable the cache log).
3. Update the content of your Component in Tridion and republish that Component’s DCP.
4. Hit the page where this DCP exists (i.e. refresh the page from step 2). The expected result is that the DCP should be updated with the new content.

Once you get this working, the performance of your J2EE Tridion-driven website surges.  It’s an amazing feeling to have this thing up and running.  Hopefully this article makes the process a lot smoother for the next person doing it.

References

Official SDL Documentation
http://sdllivecontent.sdl.com/LiveContent/content/en-US/SDL_Tridion_2011_SPONE/task_5757AEB2C06D427EA5A299FAB6165052

Analyzing the Object Cache
http://sdltridionworld.com/articles/sdltridion2011/analyzing_object_cache.aspx

Tridion and JMS: removing another SPOF
http://blog.trivident.com/category/architecture/

How to configure JMS for Cache Channel Service
http://tridion.stackexchange.com/questions/3387/how-to-configure-mq-for-cache-channel-service

Special Thanks

Andy Lim from SDL P.S. for helpful advice and his ability to creatively operate outside the box.

Jeff Wisor from SDL Support for his helpful and quick tips with next steps.

Ram G. for his presentation at the 2012 MVP Retreat on “Demystifying the Tridion CCS” and providing additional tips via Tridion Stackexchange.

Sumit Malvi [my amazing clients (I don’t know if I’m allowed to mention company names)]. Sumit is the WAS specialist buddy I mentioned above. Thanks for educating and refreshing my memory with all the J2EE goodness. Despite the long hours, it was a pleasure seeing this CCS thing coming to life.

Sreedhar Sundaram [also my amazing client]. Thanks for your support, ideas and direction in getting this accomplished. After that week, in my mind you are now the official Tridion CCS guru.

Happy Tridionizing!  and Happy New Year!!!