Implementing Task Queuing
By implementing task queuing in your Info*Engine environment, you can provide the following capabilities:
• Users can submit a long-running task to a message queue for execution by a subscriber to the queue. The subscriber can guarantee the execution of the task and submit the result to a response queue. At a later time, the user can check for the completion of the task and retrieve the resulting data.
• Users can submit a task to a message queue for execution and wait for a response. The response is returned to the user as soon as a response is received. If the user disconnects before the response is received, the task results are queued for later retrieval.
• Users can submit a task to any queue in the message queue network, thus providing interconnection between Info*Engine servers.
• Users can submit a current Info*Engine group to a message queue. This makes the group available to multiple instances of Info*Engine users.
The following Info*Engine webjects provide the capabilities to queue and manage tasks:
Browse-Queue
Delete-Results
Query-Results
Queue-Task
Subscribe-Queue
Unsubscribe-Queue
For webject examples, see the Info*Engine User's Guide.
To implement task queuing in your Info*Engine environment, complete the following tasks:
• Install a Message-Oriented Middleware (MOM) software product, such as WebSphere MQ.
• In the MOM, configure the required execution and results queues and also configure a queue connection factory that is used in conjunction with the queues. The connection factory used for task queuing is the same connection factory used for point-to-point messaging.
• Use a MOM supplied utility or administrative UI to create the necessary administered objects (connection factories, queues, topics) in the MOM’s JNDI repository. Depending on your MOM these objects may or may not be independent from those discussed in step above.
• Using the Info*Engine Property Administration utility, create a new “JMS Service” property set for your MOM. For information on how to configure your JMS Service property set to use JMS queues, see the properties configuration step in
Implementing Messaging and the Web Event Service.
• Optionally, set the following JMS service property set values, found in the Additional JMS Properties section:
|
Property
|
LDAP Entry Field
|
|
.msg.defaultTaskQueue
|
Default Submit Queue
|
|
.msg.defaultExecutionQueue
|
Default Subscribe Queue
|
|
.msg.defaultResultsQueue
|
Default Results Queue
|
If you do not set defaults for the submit, subscribe, and results queues, the queues must be named in the webjects used for queuing tasks.
You must also 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 comes up. The wt.federation.task.startup property controls the 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.
|
|
In Windchill, the startup task is specified using the wt.federation.task.startup property in wt.properties.
|
For examples of queuing tasks, executing queued tasks, and retrieving the results of queued tasks, see
Info*Engine Tasks.
