Configuration Parameters:
These are the configuration parameters specified by the Command Element in the Deployment document. NOTE: Like all other OpenEAI configuration objects, there is a "container" level associated to Command objects. Many Elements and attributes are required at that level and may be optionally overridden at this level. This is to avoid having to enter redundant information in the Deployment document if all (or most) Command objects being configured should use the same configuration information. Therefore, many of the Command configuration parameters are optional at this level but required at the "container" level. Where this is the case, it will be indicated by an "*".
| Name | Required | Description |
|---|---|---|
| CommandName | yes | Name of the Command. The consumer will look at the COMMAND_NAME JMS Property associated to each message it consumes and execute the command with that name. |
| CommandClass | yes | Fully qualified class name of the Command implementation for the consumer to instantiate. The consumer will then execute this instance each time it consumes a message that has a COMMAND_NAME JMS Property with this CommandName. |
| Configuration | no | The configuration Element that specifies what components this Command will have at its disposal. This is the Command's AppConfig object. |
| MessagingComponents | no | Other messaging components that this command might need to interact with. Typically, this is only needed for infrastructure type gateways, like Routers and Proxies that will forward messages to other components in an enterprise. This will end up being an AppConfig object for each one of those components so this Command may have Producers, Properties, MessageObjects etc. set up according to that components needs. It is mostly just a convienient way to accomplish this goal re-using existing foundation to configure and organize those objects. |
| type | yes | The type of command being initialized (Request, Sync or Scheduled) |
| isDefault (true | false) | no (defaults to false) | Signifies that the command being initialized is the "default" command to be executed if the message consumed by the consumer does not have the COMMAND_NAME JMS Property set on it. |
| isAbsolute (true | false) | no (defaults to false) | If true, indicates that the command being initialized is the ONLY command that will ever be executed by the consumer no matter what the COMMAND_NAME JMS Property set to. It is only appropriate to set this to true if the Consumer only executes one command. |
| inboundXmlValidation (true | false) | no* | Indicates whether or not this Command should perform XML validation on the messages passed to it. This is automatically checked and performed when the command uses the initializeInput method to build the Document out of the JMS Message passed to it by the Consumer. |
| outboundXmlValidation (true | false) | no* | Indicates whether or not this Command should perform XML validation on the messages it returns or forwards after it's finished performing the business logic associated to the command. This is NOT currently automatically performed by any foundation code. It is up to the Command itself to check this flag and validate the document itself. This may eventually be put in the buildReplyDocument method as a convenience. |
| writeToFile (true | false) | no* | Indicates whether or not this Command should serialize the contents of the Message passed to it when it builds the XML Document from the message. |
| messageDumpDirectory | no | Indicates the directory where the message should be serialized to (if writeToFile is true). If no directory is specified, it will default to the current directory of the running application (the gateway). |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |