Marshall Service (com.ibi.agents.XDMarshallAgent)

Syntax:

com.ibi.agents.XDMarshallAgent

iIT Service Object:

exit preemit: Marshall Agent

misc: Marshall Agent

Description:

This service collects and serializes the content of a current document and its channel context as a single message. The marshaled message can then be sent to another listener, where it will automatically be unmarshaled to reconstruct the original channel.

For example, you can marshal a message and then use an MQ or File emit service to send the message to another listener on that protocol. The next listener picks up the message, and the processing of the message resumes. The second channel can exist on another configuration or even another host.

Sending a marshaled message insures that the continuation of execution is on the same transaction ID (TID) as that of the originating channel.

You must not use this service when sending messages through server facilities that are managed internally. These include the internal emit service, the internal emitter, the RVI gateway relay facilities, and messages to be placed on pending queues. These services automatically marshal their own messages, and marshaling a marshaled message would create an unpredictable error.

Note: This service is packaged with the iwgateway.jar extension.

Parameters:

Parameter

Description

Compress Message

During marshaling, the message body will be compressed. Compression works best with messages restricted to a small set of octets (such as an XML message), but works poorly when the message consists of randomly distributed octets, such as a binary message.

Marshall User Special Registers

Determines if marshaling should include the user-level special registers. By default, DOC and HDR registers are included in the marshaled message, along with some specific registers needed for Business Activity Monitor (BAM) and transaction tracking.

Namespace

If a namespace is specified, only special registers in the designated namespace are included in the marshaled message, along with the specific registers needed for BAM and tracking. This can be helpful when preparing multiple marshals for different targets, each of which needs different header registers. Other services are available to manipulate special register namespaces as required.

Use Encryption

Determines if marshaled messages should be encrypted. A secure AES cipher is used, and must be deciphered by the receiver (using the Unmarshal service). Automatic unmarshaling cannot be performed on an encrypted message.

AES Key

A cipher key shared between the marshal and unmarshal services. Usually, this is specified as a special register or from a properties file.

The edges that are returned by this service are listed in the following table:

Edge

Description

success

The message has been marshaled and is ready for sending.

fail_operation

The message could not be compressed, encrypted, or marshaled.

For more information, see Unmarshal Service (com.ibi.agents.XDUnmarshallAgent).