IBM Support

JMS Messaging - High availability, scalability and Maximo Integration Framework using a single Service Integration Bus

Technical Blog Post


Abstract

JMS Messaging - High availability, scalability and Maximo Integration Framework using a single Service Integration Bus

Body

In the past, the documentation that was created for Maximo clustering with JMS resources typically contained separate buses – one per cluster – to avoid affecting performance while loading data to Maximo, but this is often complicated and has drawbacks when it comes to high availability and scalability as well as ease of configuration.  I admit I'm probably responsible for most of that documentation and generally there are always workarounds available to cope with the separate buses when more than one cluster needs access to the same JMS resource, but these are always confusing and difficult to troubleshoot when things don’t go quite the way we want them to.  Often, the integration or cron clusters need to be able to access the sequential outbound queues, or users need to access the inbound continuous or sequential queues from the user cluster.

 

I decided it was time to simplify the configuration and at the same time, make the JMS resources more accessible to avoid the complication of creating duplicate JMS queues at different scopes for use by different clusters.  This is simpler to do now than in previous versions of WebSphere Application Server Network Deployment.

 

The idea of this post is to help you to configure the JMS resources in WebSphere version 7.0.0.x to 8.5.5.x for use by the Maximo Integration Framework version 7.5 and 7.6, in such a way that all servers that need to access them can, regardless of the cluster a server is a member of if any, as long as the servers are all in the same WebSphere cell.  This will also reduce the number of steps required to configure the resources because it requires only a single bus.  Additionally, the continuous inbound queue will be configured for load distribution, containing a dedicated messaging engine for each server instance in the cluster.

 

 

There are two things this document can help you accomplish.  The first is configuring the JMS resources for scalability and the second is configuring the messaging engines for highly availability.

 

For this configuration, we are assuming the following already exists:

UI cluster (uicluster) containing two members

IF cluster (ifcluster) containing two members

CRON cluster (croncluster) containing two members

 

 

Below are links to the diagrams and concepts associated with the messaging engine configuration I am using here.   Additional information about how the policy maintenance in WebSphere works is included:

 

https://www.ibm.com/support/knowledgecenter/SSEQTJ_8.5.5/com.ibm.websphere.nd.doc/ae/cjt1004_.html

https://www.ibm.com/support/knowledgecenter/SSEQTJ_8.5.5/com.ibm.websphere.nd.doc/ae/cjt0011_.html

 

Below is a simple diagram depicting the solution outlined here:

image

 

Below is the list of steps used to configure WebSphere

 

  1.  To accomplish load distribution and visibility of the JNDI objects throughout the WebSphere cell, we will need several messaging Engines.  We will also need a database for each messaging engine.  In this configuration, we will have two messaging engines for the IF continuous inbound queue (one per cluster member for load distribution) and one for each cluster for accessing the sequential queues.  This means we will have a total of four messaging engines, so we will need four empty databases or schemas for this configuration prior to proceeding.  These databases will be used only by the messaging engines and will not be used by the Maximo application.  The owner of the database must have permissions to create tables.

Remember that no two messaging engines can share the same schema for their persistent storage, so each messaging engine must have its own persistent storage location.

Once you have four empty databases or schemas, proceed to the next step.

 

  1. Create JDBC Provider for your database which we will use for your messaging engines’ persistent storage.

 

The example below is for Oracle:

  1. Launch a browser and open the WebSphere Administrative Console by typing the following: https://<dmgr_host_name>:9043/ibm/console
  2. Click Resources > JDBC > JDBC Providers
  3. From the Scope drop-down list select Cell=ctgCell01
  4. Click New.
  5. Enter/select the following information
    • Database Type Select Oracle
    • Provider type Select Oracle JDBC Driver
    • Implementation type Select XA data source
    • Name Enter oraclexa
  6. Click Next
  7. Leave Directory location blank
  8. Click Next
  9. Click Finish
  10. Click Save
  11. Click OK
  12. Click oraclexa to open the dialog box.
  13. Change the Class Path to a local path containing a copy of the jar file from the Maximo installation folder/lib/ojdbc6.jar

Note that this file must be placed in the same location on each node.This can be a mount point or UNC path as well as a local location that the WebSphere JVM user has access to.

AVOID TROUBLE:Do not place database driver files in the WebSphere Installation/lib folder.

  1. Click Ok
  2. Click Save

 

 

  1. Now we need to create data sources for each messaging engine.  Since there are four messaging engines required for this configuration (two for the partitioned continuous queue and one each for the remaining clusters), we will need to create four data sources (one for each database used by each messaging engine for persistent storage).  If you create four schemas in a single database, you can create only one data source and four authentication aliases (one for each schema user).  The number of data sources you create will depend on which database vendor you are using and your database configuration.  In the example below, I created a single data source and four authentication aliases (one per schema user):

 

Click Resources > JDBC > Data sources

  1. From the Scope drop-down list select Cell= ctgCell01
  2. Click New.
  3. Enter the following information
    1. Data source Name Enter oraclexads
    2. JNDI Name Enter jdbc/oraclexads
    3. Component-managed authentication alias Select (none)
  4. Click Next
  5. Select an existing JDBC provider oraclexa
  6. Click Next
  7. Enter the JDBC URL information using the format shown below:
  • URL Enter jdbc:oracle:thin:@<hostname.domain.com>:1521:<yourdbname>
  • Data store helper class name Select Oracle11g data store helper
  • data source in container managed persistence (CMP) <Checked>

 

  1. Click Next
  2. Click Finish
  3. Click Save
  4. Click oraclexads to open the dialog box
  5. Click on JAAS - J2C authentication data
  6. Click New.
  7. Enter the user information for the first schema
    • Alias Enter me1
    • User ID Enter me1
    • Password Enter <PASSWORD>
  8. Click OK
  9. Click Save
  10. Click Resources > JDBC > Data sources > oraclexads
  11. Select ctgCellManager01/me1 for Component-managed authentication alias
  12. Click OK
  13. Click Save
  14. Using the steps from 12 to 17, create four remaining schemas and save the changes.

The end result will be a total of four authentication aliases created using the following aliases:

 

me1

me2

me3

me4

 

  1.  Test your data source connection.  Once successful, proceed to the next step.

 

 

  1. Creating the JMS Bus

 

  1. Click Service Integration > Buses to open the Buses dialog
  2. Click New to create a new bus
  3. Enter mifjmsbus as the name of the new bus
  4. Deselect the Bus security check box
  5. Click Next
  6. Click Finish
  7. Click Save

 

 

  1. Adding Clusters to the service integration bus

 

Add the UI Cluster to the bus

 

  1. From the WebSphere Administrative Console, click Service Integration > Buses
  2. Click mifjmsbus
  3. Under Topology on the right, click Bus members.
  4. In the Buses > mifjmsbus > Bus members dialog box, click Add
  5. Click the Cluster drop-down arrow, and select the cluster uicluster to add to the bus, and then click Next
  6. Check that the Data Store radio button is selected, and then click Next
  7. Check that the Use existing data store radio button is selected
  8. Enter the following information
    • Data source JNDI name Enter jdbc/oraclexads
    • Schema name Enter me1
    • Authentication alias Select ctgCellManager01/me1
    • Create tables <checked>
  9. Click Next
  10. Click Finish
  11. Click Save

 

Add the Cron Cluster to the bus

 

  1. From the WebSphere Administrative Console, click Service Integration > Buses
  2. Click mifjmsbus
  3. Under Topology, click Bus members
  4. In the Buses > mifjmsbus > Bus members dialog box, click Add
  5. Click the Cluster drop-down arrow, and select the cluster croncluster and then click Next
  6. Check that the Data Store radio button is selected, and then click Next
  7. Check that the Use existing data store radio button is selected
  8. Enter the following information
    • Data source JNDI name Enter jdbc/oraclexads
    • Schema name Enter me2
    • Authentication alias Select ctgCellManager01/me2
    • Create tables <checked>
  9. Click Finish
  10. Click Save
  11. Click OK

 

 

 

 

Add the IF Cluster to the bus

 

  1. From the WebSphere Administrative Console, click Service Integration > Buses
  2. Click mifjmsbus
  3. Under Topology, click Bus members.
  4. In the Buses > mifjmsbus > Bus members dialog box, click Add
  5. Click the Cluster drop-down arrow, and select the cluster ifcluster to add to the bus, and then click Next
  6. Check that the Data Store radio button is selected, and then click Next
  7. Check that the Use existing data store radio button is selected
  8. Enter the following information
    • Data source JNDI name Enter jdbc/oraclexads
    • Schema name Enter me3
    • Authentication alias Select ctgCellManager01/me3
    • Create tables <checked>
  9. Click Finish
  10. Click Save

 

Add a second messaging engine for the ifcluster for partitioning the continuous inbound queue

 

  1. Under Buses/mifjmsbus>bus members, select ifcluster
  2. Then select Scalability with high availability
  3. Then click on Messaging Engines
  4. Then click Add messaging engine button
  5. Choose Data Store and click next
  6. Enter the following information
  7. Data source JNDI name Enter jdbc/oraclexads
  8. Schema name Enter me4
  9. Authentication alias Select ctgCellManager01/me4
  10. Create tables <checked>
  11. Click Next
  12. Click Finish
  13. Click Save

 

 

  1. Modify the messaging engine policies

 

  1. Navigate to Service Integration > Buses and select mifjmsbus
  2. On the right, select Bus Members
  3. Click on ifcluster
  4. Select the radio button for Scalability and High Availability
  5. Save
  6. Next, Navigate back to the mifjmsbus and on the right side of the screen, select Messaging Engine Policy Maintenance
  7. Click on the first of the two messaging engines in the list
  8. Ensure that Fallback and Preferred Servers Only check boxes are checked
  9. On the right side of the screen, click Preferred Servers
  10. Add both ifcluster server instances to the list of preferred servers in the order they appear
  11. Navigate back to your mifjmsbus and on the right side of the screen, select Messaging Engine Policy Maintenance
  12. Click on the second of the two messaging engines
  13. Ensure that Fallback and Preferred Servers Only check boxes are checked
  14. On the right side of the screen, click Preferred Servers
  15. Add both ifcluster server instances in the opposite order as done in step 10
  16. Save

 

 

  1. Creating the partitioned destination for the continuous inbound (CQINBD) queue

 

  1. From the WebSphere Administrative Console, click Service Integration > Buses
  2. Click mifjmsbus
  3. Click Destinations under Destination resources on the right
  4. Click New
  5. Leave Queue radio button checked as the destination type, and click Next
  6. Type CQINBD in the Identifier field then click Next
  7. Select the Bus Member pull-down and choose cluster ifcluster as the bus member
  8. Click Next to open the confirm queue creation dialog box
  9. Review your selections, then click Finish
  10. Navigate again to Buses > intjmsbus > Destinations, then click CQINBD
    • Click Specify as the Exception destination value
    • Enter CQINERRBD as the Exception destination value
    • Change the Maximum failed deliveries value to 5
  11. Click Apply
  12. Click Save

 

 

  1. Creating the destination for the sequential inbound (SQINBD)

 

  1. From the WebSphere Administrative Console, click Service Integration > Buses
  2. Click mifjmsbus
  3. Click Destinations under Destination on the right side of the screen
  4. Click New
  5. Leave Queue checked as the destination type, and click Next
  6. Enter SQINBD in the Identifier, then click Next
  7. Select the Bus Member pull-down and choose cluster croncluster
  8. Click Next
  9. Review your selections, then click Finish
    • Navigate the path Buses > mifjmsbus > Destinations, then click SQINBD
    • Click None as the Exception destination value.
  10. Click Apply
  11. Click Save

 

NOTE:the sequential inbound queue is being assigned to the croncluster because this queue is sequential and therefore must not be partitioned.If we were to assign it to the ifcluster where we have two messaging engines created, the queue would become partitioned and would no longer be considered a sequential queue.This is important when message order is required and is the reason we assigned the sequential queue to the cron cluster.

 

  1. Creating the destination for the sequential outbound (SQOUTBD) queue

 

  1. From the WebSphere Administrative Console, click Service Integration > Buses
  2. Click mifjmsbus
  3. Click Destinations under Destination resources on the right side of the screen
  4. Click New
  5. Leave Queue checked as the destination type, and click Next
  1. Enter SQOUTBD in the Identifier field, then click Next
  2. Select the Bus Member pull-down and choose cluster uicluster as the bus member
  3. Click Next
  4. Click Finish
    • Navigate to Buses > mifjmsbus > Destinations, then click SQOUTBD
    • Click None as the Exception destination value
  5. Click Apply
  1. Click Save

 

 

  1. Creating the destination for the inbound error queue (CQINERRBD) queue

 

  1. From the WebSphere Administrative Console, click Service Integration > Buses
  2. Click mifjmsbus
  3. Click Destinations under Destination resources on the right side of the screen
  4. Click New
  5. Leave Queue checked as the destination type, and click Next
  6. Enter CQINERRBD in the Identifier field, then click Next
  7. Select the Bus Member pull-down and choose Cluster ifcluster
  8. Click Next
  9. Click Finish
  10. Navigate to Buses > mifjmsbus > Destinations, then click CQINERRBD
    • Click Specify as the Exception destination value
    • Enter CQINBD as the Exception destination value
    • Change the Maximum failed deliveries value to 5
  11. Click Apply
  12. Click Save

 

 

  1. Creating the JMS connection factory

 

  1. From the WebSphere Administrative Console, click Resources → JMS → Connection factories.
  2. From the Scope drop-down list select Cell=ctgCell01
  3. Click New
  4. Verify that the Default Messaging Provider is selected and click OK
  5. Enter the following information, and then click OK
    • Name Enter intjmsconfact
    • JNDI name Enter jms/maximo/int/cf/intcf
    • Bus name Select mifjmsbus
  6. Click Save

 

  1. Creating the continuous inbound (CQIN) JMS queue

 

  1. From the WebSphere Administrative Console, click Resources > JMS > Queues
  2. From the Scope drop-down list, select Cell=ctgCell01
  3. Click New
  4. Verify that the Default Messaging Provider is selected and click OK
  5. Enter the following information, and click OK
    • Name Enter CQIN
    • JNDI name Enter jms/maximo/int/queues/cqin
    • Bus name Select mifjmsbus
    • Queue name Select CQINBD
    • Uncheck the check box “Restrict messages to the local queue point if a queue point is configured on the connected messaging engine”
    • Select the radio button “Do not prefer a local queue point over other queue points”
    • Select the radio button “Messages may be sent to different queue points”
    • Select the radio button “Message on all queue points are visible”
  6. Click OK
  7. Click Save

 

 

  1. Creating the sequential inbound (SQIN) JMS queue

 

  1. From the WebSphere Administrative Console, click Resources > JMS > Queues
  2. From the Scope drop-down list, select Cell=ctgCell01
  3. Click New
  4. Verify that the Default Messaging Provider is selected and click OK
  5. Enter the following information, and click OK
  • Name Enter SQIN
  • JNDI name Enter jms/maximo/int/queues/sqin
  • Bus name Select mifjmsbus
  • Queue name Select SQINBD
  1. Click OK
  2. Click Save

 

  1. Creating the sequential outbound (SQOUT) JMS queue

 

  1. From the WebSphere Administrative Console, click Resources > JMS > Queues
  2. From the Scope drop-down list, select Cell=ctgCell01
  3. Click New
  4. Verify that the Default Messaging Provider is selected and click OK
  5. Enter the following information, and click OK
    • Name Enter SQOUT
    • JNDI name Enter jms/maximo/int/queues/sqout
    • Bus name Select mifjmsbus
    • Queue name Select SQOUTBD
  6. Click OK
  7. Click Save

 

  1. Creating the error (CQINERR) JMS queue

 

  1. From the WebSphere Administrative Console, click Resources > JMS > Queues
  2. From the Scope drop-down list, select Cell=ctgCell01
  3. Click New
  4. Verify that the Default Messaging Provider is selected and click OK
  5. Enter the following information, and click OK
    • Name Enter CQINERR
    • JNDI name Enter jms/maximo/int/queues/cqinerr
    • Bus name Select intjmsbus
    • Queue name Select CQINERRBD
    • Uncheck the check box “Restrict messages to the local queue point if a queue point is configured on the connected messaging engine”
    • Select the radio button “Do not prefer a local queue point over other queue points”
    • Select the radio button “Messages may be sent to different queue points”
    • Select the radio button “Message on all queue points are visible”
  6. Click OK
  7. Click Save

 

  1. Creating JMS activation specification for the continuous inbound queue (CQIN)

 

  1. From the WebSphere Administrative Console, click Resources → JMS → Activation Specifications
  2. From the Scope drop-down list, select Cell=ctgCell01
  3. Click New
  4. Click OK
  5. Enter the following information, and then click OK
    • Name intjmsact
    • JNDI name intjmsact
    • Destination type Queue
    • Destination JNDI name jms/maximo/int/queues/cqin
    • Bus name mifjmsbus
    • Maximum concurrent endpoints 5
    • Maximum batch size 10
    • Check the checkbox “Always activate MDB in all servers”
  6. Click OK
  7. Click Save

 

  1. Creating JMS activation specification for the inbound error queue (CQINERR)

 

  1. From the WebSphere Administrative Console, click Resources > JMS > Activation Specifications.
  2. From the Scope drop-down list, select Cell=ctgCell01
  3. Click New. to complete the General Properties section for the new JMS activation specification.
  4. Click OK
  5. Enter the following information, and click OK.
  • Name Enter intjmsacterr.
  •  JNDI name Enter intjmsacterr
  • Destination type Enter Queue
  • Destination JNDI name jms/maximo/int/queues/cqinerr
  • Bus name mifjmsbus
  • Maximum batch size 10
  • Maximum concurrent endpoints 5
  • Check the checkbox “Always activate MDB in all servers”

 

  1. Click OK
  2. Click Save

 

  1. Modify the ejb-jar.xml and ibm-ejb-jar-bnd.xmi to enable the Message Driven Beans for the Integration Framework maximo.ear file.

 

Open the file /opt/IBM/SMP/maximo/applications/maximo/mboejb/ejbmodule/META-INF/ejb-jar.xml

The file contains two sections that have Message Driven Beans (MDBs) commented out and will look like the contents below:

 

<!-- MEA MDB  

    <message-driven id="MessageDriven_JMSContQueueProcessor_1">

      <ejb-name>JMSContQueueProcessor-1</ejb-name>

      <ejb-class>psdi.iface.jms.JMSContQueueProcessor</ejb-class>

      <transaction-type>Container</transaction-type>

      <message-destination-type>javax.jms.Queue</message-destination-type>

      <env-entry>

        <env-entry-name>MESSAGEPROCESSOR</env-entry-name>

        <env-entry-type>java.lang.String </env-entry-type>

        <env-entry-value>psdi.iface.jms.QueueToMaximoProcessor</env-entry-value>

      </env-entry>

    </message-driven>

-->

 

<!-- MEA MDB for error queue

    <message-driven id="MessageDriven_JMSContQueueProcessor_2">

      <ejb-name>JMSContQueueProcessor-2</ejb-name>

      <ejb-class>psdi.iface.jms.JMSContQueueProcessor</ejb-class>

      <transaction-type>Container</transaction-type>

      <message-destination-type>javax.jms.Queue</message-destination-type>

      <env-entry>

        <env-entry-name>MESSAGEPROCESSOR</env-entry-name>

        <env-entry-type>java.lang.String </env-entry-type>

        <env-entry-value>psdi.iface.jms.QueueToMaximoProcessor</env-entry-value>

      </env-entry>

      <env-entry>

        <env-entry-name>MDBDELAY</env-entry-name>

        <env-entry-type>java.lang.Long </env-entry-type>

        <env-entry-value>30000</env-entry-value>

      </env-entry>     

      <env-entry>

        <env-entry-name>ERRORQUEUE</env-entry-name>

        <env-entry-type>java.lang.String </env-entry-type>

        <env-entry-value>1</env-entry-value>

      </env-entry>     

    </message-driven>

-->

 

<!-- MEA MDB

    <container-transaction>

        <method>

           <ejb-name>JMSContQueueProcessor-1</ejb-name>

           <method-name>*</method-name>

        </method>

        <trans-attribute>Required</trans-attribute>

    </container-transaction>

-->

<!-- MEA MDB for error queue

    <container-transaction>

        <method>

           <ejb-name>JMSContQueueProcessor-2</ejb-name>

           <method-name>*</method-name>

        </method>

        <trans-attribute>Required</trans-attribute>

    </container-transaction>

-->

 

Uncomment the MDBs.  Uncommented, the MDBs will look like the following:

 

<!-- MEA MDB  -->

    <message-driven id="MessageDriven_JMSContQueueProcessor_1">

      <ejb-name>JMSContQueueProcessor-1</ejb-name>

      <ejb-class>psdi.iface.jms.JMSContQueueProcessor</ejb-class>

      <transaction-type>Container</transaction-type>

      <message-destination-type>javax.jms.Queue</message-destination-type>

      <env-entry>

        <env-entry-name>MESSAGEPROCESSOR</env-entry-name>

        <env-entry-type>java.lang.String </env-entry-type>

        <env-entry-value>psdi.iface.jms.QueueToMaximoProcessor</env-entry-value>

      </env-entry>

    </message-driven>

 

<!-- MEA MDB for error queue -->

    <message-driven id="MessageDriven_JMSContQueueProcessor_2">

      <ejb-name>JMSContQueueProcessor-2</ejb-name>

      <ejb-class>psdi.iface.jms.JMSContQueueProcessor</ejb-class>

      <transaction-type>Container</transaction-type>

      <message-destination-type>javax.jms.Queue</message-destination-type>

      <env-entry>

        <env-entry-name>MESSAGEPROCESSOR</env-entry-name>

        <env-entry-type>java.lang.String </env-entry-type>

        <env-entry-value>psdi.iface.jms.QueueToMaximoProcessor</env-entry-value>

      </env-entry>

      <env-entry>

        <env-entry-name>MDBDELAY</env-entry-name>

        <env-entry-type>java.lang.Long </env-entry-type>

        <env-entry-value>30000</env-entry-value>

      </env-entry>     

      <env-entry>

        <env-entry-name>ERRORQUEUE</env-entry-name>

        <env-entry-type>java.lang.String </env-entry-type>

        <env-entry-value>1</env-entry-value>

      </env-entry>     

    </message-driven>

 

<!-- MEA MDB -->

    <container-transaction>

        <method>

           <ejb-name>JMSContQueueProcessor-1</ejb-name>

           <method-name>*</method-name>

        </method>

        <trans-attribute>Required</trans-attribute>

    </container-transaction>

 

<!-- MEA MDB for error queue -->

    <container-transaction>

        <method>

           <ejb-name>JMSContQueueProcessor-2</ejb-name>

           <method-name>*</method-name>

        </method>

        <trans-attribute>Required</trans-attribute>

    </container-transaction>

 

Open the file /opt/IBM/SMP/maximo/applications/maximo/mboejb/ejbmodule/META-INF/ibm-ejb-jar-bnd.xmi

The file contains a section that has Message Driven Beans (MDBs) commented out and will look like the contents below:

<!-- MEA MDB
  <ejbBindings xmi:type="ejbbnd:MessageDrivenBeanBinding" xmi:id="MessageDrivenBeanBinding_1" activationSpecJndiName="intjmsact">
    <enterpriseBean xmi:type="ejb:MessageDriven" href="META-INF/ejb-jar.xml#MessageDriven_JMSContQueueProcessor_1"/>
  </ejbBindings>

-->

<!-- MEA MDB for error queue
  <ejbBindings xmi:type="ejbbnd:MessageDrivenBeanBinding" xmi:id="MessageDrivenBeanBinding_1" activationSpecJndiName="intjmsacterr">
    <enterpriseBean xmi:type="ejb:MessageDriven" href="META-INF/ejb-jar.xml#MessageDriven_JMSContQueueProcessor_2"/>
  </ejbBindings>
-->

 

Uncomment the MDBs so they look like the following:

<!-- MEA MDB -->
  <ejbBindings xmi:type="ejbbnd:MessageDrivenBeanBinding" xmi:id="MessageDrivenBeanBinding_1" activationSpecJndiName="intjmsact">
    <enterpriseBean xmi:type="ejb:MessageDriven" href="META-INF/ejb-jar.xml#MessageDriven_JMSContQueueProcessor_1"/>
  </ejbBindings>

<!-- MEA MDB for error queue -->
  <ejbBindings xmi:type="ejbbnd:MessageDrivenBeanBinding" xmi:id="MessageDrivenBeanBinding_1" activationSpecJndiName="intjmsacterr">
    <enterpriseBean xmi:type="ejb:MessageDriven" href="META-INF/ejb-jar.xml#MessageDriven_JMSContQueueProcessor_2"/>
  </ejbBindings>

 

NOTE:  the MDBs are only to be uncommented for the IF ear.  For the UI and CRON maximo ear files, the MDBs are commented out in both the ejb-jar.xml and the ibm-ejb-jar-bnd.xmi.

  1. Which cron tasks should run where?

 

Now that we have three clusters, and all of our JMS resources have been created and the MDBs deployed, we will need to set properties to control where cron tasks will run.

Here are a list of cron tasks that we will need to consider:

JMSQSEQCONSUMER.SEQQOUT

JMSQSEQCONSUMER.SEQQIN

IFACETABLECONSUMER

FLATFILECONSUMER

XMLFILECONSUMER

All other cron tasks

 

The Message Driven Beans will only be deployed to ifcluster and will be activated in both server instances in this cluster, each running their own messaging engine and connecting to their respective queue points associated with the partitioned continuous queue.  Each server receives messages on their local queue points by way of the WebSphere workload manager.  Messages received from the other messaging engines will be fairly evenly distributed to both queue points.  Additional ifcluster members can be added using the same method described above to further distribute the load of incoming messages.

 

All crontasks should be configured to run in croncluster with the exception of JMSQSEQCONSUMER.SEQQOUT.  This cron task should be configured to run in the uicluster where the queue point for this queue has been assigned.  This ensures that the queue point is available when users are able to log into uicluster and that messages will be delivered to their destinations regardless of the status of any of the servers in ifcluster or croncluster.

 

The mxe.crontask.donotrun property can be specified in the maximo.properties file for each cluster to simplify the configuration.  Below is an example of what I configured:

 

Uicluster maximo.properties:

mxe.crontask.dorun=JMSQSEQCONSUMER.SEQQOUT

 

Ifcluster maximo.properties:

mxe.crontask.donotrun=all

 

Croncluster maximo.properties:

mxe.crontask.donotrun=JMSQSEQCONSUMER.SEQQOUT

 

20.  Rebuild and redeploy the maximo.ear for each cluster

 

21.  Putting it all together

 

Now that we have configured the system, how does it work?Here is a high level description of how data might be retrieved from the Maximo interface tables associated with an external system, sent to the continuous inbound queue.

 

  • Data is entered into the interface table associated with a Maximo enterprise service and external system, then the mxin_inter_trans queue table
  • The IFACETABLECONSUMER crontask runs in croncluster and picks up the messages from the interface table and routes them to ifcluster, since that is where the continuous queue point destinations are hosted
  • WebSphere’s workload management routine runs and in a round-robin fashion, distributes the messages to each queue point in ifcluster
  • The message driven beans running in each cluster member of ifcluster see their queue point messages by way of their dedicated messaging engines, and pick up the messages from the queue points
  • Each messaging engine can also pick up messages from the other’s queue point
  • Each server instance in the cluster can host both messaging engines and pick up messages from the other’s queue points if the server that originally hosted the queue point goes down

 

When messages are sent to the sequential inbound queue rather than the partitioned continuous queue, the IFACETABLECONSUMER running in croncluster will write the messages to the sequential inbound queue point assigned to croncluster.  The sequential inbound crontask JMSQSEQCONSUMER.SEQQIN which also runs on croncluster will pick up the messages and process them into Maximo.

 

When data is saved by a user in Maximo which triggers an event to write the message to the sequential outbound queue, the message is written to the sequential outbound queue point assigned to the uicluser.  The sequential outbound crontask JMSQSEQCONSUMER.SEQQOUT which also runs on uicluster will pick up the messages and deliver them to the respective external system endpoints.

 

If croncluster runs an escalation that causes and event to write a message to the sequential outbound queue, since croncluster is a member of the same bus, it can access the sequential outbound queue point assigned to uicluster, even if the uicluster is down, due to store and forward behavior.  The same is true for the ifcluster in that it will have access to the sequential outbound queue if needed without additional configuration required.  If croncluster and ifcluster a down, uicluster will continue to function independently from the others allowing users to continue working and sending data to external systems without interruption.

 

I hope you find this document useful.From this document hopefully you can discover other ways to configure Maximo with JMS in a manner that allows instance to access the JMS queues without the need for additional queue configuration.

[{"Business Unit":{"code":"BU005","label":"IoT"}, "Product":{"code":"SSLKT6","label":"Maximo Asset Management"},"Component":"","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"","Edition":""}]

UID

ibm11113987