A Java Message Service (JMS) message for a business process
consists of:
- A message header for message identification and routing information.
- Properties for JMS-specific data, application-specific data, and provider-specific
data (optional).
- The body (payload) of the message that holds the content (optional).
Business Process Choreographer supports text, object, and bytes-message
formats.
Message header
A Business Process Choreographer client application can set the following
fields:
- JMSReplyTo
The destination to send a reply to the request. If this
field is not set, a reply is not returned.
- JMSMessageID
Uniquely identifies a message. This value is set by Business
Process Choreographer when the message sent returns. This identifier is used
as the JMSCorrelationID in the reply message.
- JMSCorrelationID
Links messages. Do not set this field. A Business
Process Choreographer reply message contains the JMSMessageID of the request
message.
Data properties
This data is passed as name-value pairs. The name-value pairs can occur
in the following combinations:
- wf$verb and parameters, for example, wf$verb, wf$processInstanceName
- wf$porttype, wf$operation, wf$processTemplateName
Business Process Choreographer acknowledges the following properties:
- wf$verb
The function to call. Possible values are: call, forceTerminate,
and initiate.
If the wf$verb property is not set and the JMSReplyTo
field is set, then call is issued. If neither the wf$verb property nor the
JMSReplyTo field are set, then initiate is issued. If the port type and operation
are set, the verb is ignored.
- wf$piid
The object ID of the process instance. You can use this ID
with the forceTerminate function to identify the process instance. The value
is set as the result of the initiate function if the JMSReplyTo filed is set.
If both the wf$piid and the wf$processInstanceName values are set, the value
for wf$processInstanceName is used.
- wf$processTemplateName
The name of the process template to instantiate
or the process template that specifies the operation to be called. This template
name must be set for call and initiate, and when the port type and operation
are specified. If the template name is not set, Dispatch is
assumed.
- wf$processInstanceName
The name of the process instance. You can use
this name with the forceTerminate function to identify the process instance
to process. It can be used with call and initiate to specify the
process instance name of the process instance to create. If the port type
and operation are specified, the process instance name is ignored.
- wf$processState
The state of the process instance. This value is set
in reply messages.
- wf$exceptionText
Specifies the message text of the exception that ended
the process.
- wf$porttype
Identifies the port type of a process operation that is
to be invoked. The port type must be qualified, that is, it must contain the
name and namespace in the form: {Namespace}Name. The following is an example
of a port type:
wf$porttype = "{http://www.example.com}whileLoop"
You
can create the format of the port type by constructing a javax.xml.QName object
and calling the toString method of the object. If you specify a port type,
you must also specify a property for wf$operation.
- wf$operation
Identifies the process operation that is to be invoked.
Message payload
Use to specify input, output, and fault messages. If the port type
and operation are specified, only messages of the ObjectMessage type are supported
for both request and reply messages.
- Request messages
- TextMessage must contain an object of the type String. This object contains
the input message to pass. The defined input message must also be of type
String.
- ObjectMessage must contain an object of the type ClientObjectWrapper.
This object contains the input message to pass.
- BytesMessage must contain a byte array that represents the streamed version
of the input message to pass.
- Reply messages
- If possible, the reply message is the same format as the request message.
That is, if the request message has a TextMessage format, then the reply message
also has a TextMessage format. If a TextMessage format cannot be used, for
example, because the type of the process instance output message is not a
String, then a message with ObjectMessage format is returned.
- If an ObjectMessage message is returned, it contains an object of the
type ClientObjectWrapper. This object contains the output message, the message
of the fault terminal, or an exception.
If the reply message contains an
exception as the result of a port type/operation call, the exception is:
- A ProcessException if the operation cannot be invoked.
- A FaultReplyException if the operation sends an application-defined fault.
- An EngineMissingReceiveException if there is no activity waiting for the
request and the process ends before an outstanding receive or pick activity
processes this request.
- An EngineMissingReplyException if the operation corresponds to a receive
or pick activity that implements a two-way operation and the process ends
without sending a reply.
- If a BytesMessage message is returned, it contains the streamed output
message or the streamed message of the fault terminal.
- If a process can be navigated until its output is reached or a fault occurs,
the wf$processInstanceName and the wf$processState properties are set.
- If an exception occurs during the processing of a request or if an exception
occurs during the execution of a process instance and the fault is not connected
to a fault terminal of the process, the reply message does not contain a payload.
The wf$processInstanceName, the wf$processState, and the wf$exceptionText
properties are set. The wf$exceptionText property contains the message text
of the exception that ended the process. Nested exceptions follow the message
text. These exceptions are separated by new-line characters.