Implementing Messaging and the Web Event Service

Implementing the Info*Engine Web Event Service (WES) and/or point-to-point messaging provides the following capabilities:

• Users or applications that interact with Info*Engine can send and retrieve messages to and from a JMS message queue. If the Web Event Service is being used, users or applications can also emit events.

Message and event emission can be from anywhere in the MOM network. Therefore, using WES can connect a separate Info*Engine environment with other JMS-compatible environments, and messaging can send information between those environments.

• By default, events emitted through Info*Engine do not expire. However, WES event authors can specify a time after which the event expires.

• When a WES is used, Info*Engine subscribers to a JMS topic can execute defined tasks when a specified event has occurred.

When interacting with a MOM, Info*Engine needs to translate local Info*Engine data into JMS messages, and then from JMS messages back into Info*Engine data.

In order to perform this two-way translation Info*Engine uses different message processors which are referred to here as “types.” In most cases the type listed corresponds directly to an actual JMS message type, but for types like InfoEngine and Unknown, these simply refer to the name of a message processor that maps onto a JMS message object that can suit the data being transferred. Info*Engine can send and receive JMS messages that are of the following types:

If the message type is InfoEngine, then a message sent from Info*Engine can include Info*Engine groups. This provides a way to pass Info*Engine groups between separate Info*Engine environments.

Used for building and receiving a message that may be specific to a third-party recipient that supports this type of message.

Used to create messages from values that are in the form of name=data. The name portion of the value is the key used to place data in this type of message.

Used to create or receive messages specific to a third-party recipient that also supports this type of message.

Used to turn BLOB data into a format that can be processed by a third-party recipient that supports BytesMessage.

Info*Engine uses this type for incoming messages that do not have a message type defined. It creates an empty IeRequest and appends the contents of the message as BLOB data.

In addition, if you supply a user-defined message processor, Info*Engine can send and receive JMS messages of the user-defined type.

The size of the messages that you can send and receive may be dependent on the MOM you are using. For example, persistent messages in WebSphere MQ must be less than 4 MB, by default.

The following Info*Engine webjects provide point-to-point messaging capabilities:

The following Info*Engine webjects support WES capabilities:

For webject examples, see Message Webjects and Web Event Service Webjects.

To implement WES or point-to-point messaging in your Info*Engine environment, complete the following tasks:

• For point-to-point messaging, configure the JMS queues in the MOM that you want to use, and configure a queue connection factory that is used in conjunction with the queues. The connection factory used for point-to-point messaging is the same connection factory used for task queuing.

For the WES, configure the required JMS topics and a topic connection factory in the MOM. Each topic represents an event.

• Use a MOM-supplied utility or administrative UI to create the necessary administered objects (connection factories, queues, topics) in the JNDI repository. Depending on your MOM, these objects may or may not be independent from those discussed previously.

• Using the Info*Engine Property Administration utility, create a new JMS service property set for your MOM. The name of the property set you create can be passed as input to the SERVICE parameter for any JMS-related webjects. If you do not wish to use the SERVICE parameter on the JMS webjects, then edit the applicable Info*Engine servers or servlets that are used for JMS operations and specify the name of your property set in the Default JMS Service property (.jms.defaultService).

When creating your new JMS service property set, the most commonly set properties can be found under the Core JMS Properties section of the property set form. Other properties can be found in the Additional JMS Properties section.

The properties that must be set depends upon the MOM to which you are connecting. At a very minimum the .jms.baseUri property and the connection factory properties must be set.

The following properties are useful when implementing point-to-point messaging and the WES:

The .jms.CtxFactory property can be used to specify a JNDI context provider factory if your MOM’s administered objects are not stored in the LDAP. This is typically a Java class name provided with the JARs used to connect Info*Engine to your MOM.

The .jms.baseUri.principal and .jms.baseUri.password properties specify any necessary JNDI credentials associated with access to the URI specified by the .jms.baseUri property. Whether or not these properties need to be set is based upon the security requirements of your MOM’s JNDI repository.

The .jms.username and .jms.password properties can be used to specify default credentials to use when connecting to your MOM. If your MOM requires credentials for connections then you must either specify these properties or use the DBUSER and PASSWD parameters when using JMS webjects.

For point-to-point messaging, the .msg.queueConnectionFactory property specifies the JNDI name of the QueueConnectionFactory object used to connect to your MOM.

For WES, the .wes.topicConnectionFactory property specifies the JNDI name of the TopicConnectionFactory object used to connect to your MOM.

The .jms.lib property specifies a directory where the JARs required to connect to your MOM are stored. If you do not specify this property, then the JARs are found within the JVM CLASSPATH (such as JARs stored in <Windchill>/codebase/WEB-INF/lib).

If you are configuring more than one third-party MOM into your system, then you should use the .jms.lib property for each MOM to isolate third-party classes from each other.

For WES, the .wes.subscriptionIdentifier property specifies a hard-coded subscription identifier your system should use. Subscribing to an event automatically generates a subscription identifier. These identifiers must be unique. By default, the identifier generated is based on the host name and event name.

If you have multiple Info*Engine environments running on the same host and you want to generate multiple subscriptions to the same MOM for the same event, then the automatically-generated subscription identifiers are the same. To make them unique, you must set a unique subscription identifier in all, or all but one, of the environments.

You must create one or more Info*Engine tasks that subscribe to the JMS topics that are used for emitting events. A startup task can be used to generate subscriptions when your system starts. The wt.federation.task.startup property controls the single startup task, or add the task in the Startup Task 1 field on the LDAP entry form for the Info*Engine server or servlet that you want to execute tasks when events occur. By executing the tasks at server startup, the server is always subscribed to the topics.

For examples of emitting events and setting up tasks to execute when an event occurs, see Info*Engine Tasks.