Syntax of amqwdeployWMQService

The calling syntax for the UNIX shell is:

./amqwdeployWMQService.sh -f className [-a integrityOption] [-b bothresh] 
[-c operation] [-i passContext] [-n num] [r] [-s] [-tmp programName]
[-tmq queueName] [-u URI] [-v] [-x transactionality] [-?] 
[SSL options]

and for the Windows command file:

amqwdeployWMQService -f className [-a integrityOption] [-b bothresh] [-c operation]
[-i passContext] [-n num] [r] [-s] [-tmp programName] [-tmq queueName] [-u URI] 
[-v] [-x transactionality] [-?] [SSL options]

Where:

-f className

The name of the class to be deployed. For Java, this must be fully qualified by the package. It can be specified as a path name with directory separators or as a class name with period separators. For a .NET service, although the directory can be specified, Java proxies are always located in the package dotNetService.

If you specify a URI with the -u option and within the URI specify the targetService, the deployment utility checks that the className you have specified matches that service. If the class and service specified do not match, it displays an error message and exits.

-a integrityOption

Allows the default behavior of SOAP/WebSphere MQ listeners to be changed when it is not possible to put a failed request message on the dead-letter queue. integrityOption can take one of the following values:

DefaultMsgIntegrity

For non-persistent messages, the listener displays a warning message and continues to execute with the original message being discarded. For persistent messages, it displays an error message, backs out the request message so it remains on the request queue and exits. This default mode applies if the -a flag is omitted, or if it is specified with no option.

LowMsgIntegrity

For both persistent and non-persistent messages, the listener displays a warning and continues to execute, discarding the message.

HighMsgIntegrity

For both persistent and non-persistent messages, the listener displays an error message, backs out the request message so it remains on the request queue and exits.

The deployment utility checks for the compatibility of the -x and -a flags. If "-x none" is specified, then "-a LowMsgIntegrity" must be specified. If the flags are incompatible it exits with an error message and with no deploy steps having been undertaken.

-b bothresh

A numeric value specifying the backout threshold setting that is to be set on the request queue. The default is 3.

-c operation

Specifies which part of the deployment process to be executed. operation is one of the following options:

allAxis

Perform all compile and setup steps for an Axis/Java service.

compileJava

Compile the Java service (.java to .class).

genAxisWsdl

Generate WSDL (.class to .wsdl).

axisDeploy

Deploy the class file (.wsdl to .wsdd, apply .wsdd).

genProxiestoAxis

Generate proxies (.wsdl to .java and .class).

genAxisWMQBits

Set up WebSphere MQ queues, SOAP/WebSphere MQ listeners and triggers for an Axis service.

allAsmx

Perform all setup steps for a .NET service

genAsmxWsdl

Generate WSDL (.asmx to .wsdl).

genProxiesToDotNet

Generate proxies (.wsdl to .java, .class, .cs and .vb)

genAsmxWMQBits

Set up WebSphere MQ queues, SOAP/WebSphere MQ listeners and triggers

startWMQMonitor

Start the trigger monitor for SOAP/WebSphere MQ services. See Starting listeners by triggering.

If this option is omitted, the default is allAxis if the className given with the -f parameter has a .java extension, and allAsmx if it has an asmx extension.

-i passContext

Specifies whether the listeners should pass identity context. This parameter can take the values passContext or ownContext. If the parameter is omitted, the default is to pass context. (SeeContext).

-n num

Number of threads to be specified in the startup scripts for the SOAP/WebSphere MQ listener. The default is 10. Consider increasing this number if you have high message throughput.

-r

Specifies that any existing request queue or trigger monitor queue (if -tmq was specified) will be explicitly replaced. By specifying -r, you ensure the queues will be recreated with standard default attributes and with no messages. If the -r option is not used then any existing queue definitions will not be altered nor message entries deleted. By not specifying -r, you ensure that any customized queue attributes are preserved.

-s

Configure the listener to be executed as a WebSphere MQ service. This option is mutually exclusive to the -tmq option.

If -s and -tmq are both specified, the deployment utility displays an error message and exits.

-tmp programName

Specifies a trigger monitor program. This option might be used in a UNIX environment to circumvent limitations of the setuid trigger monitor runmqtrm.

-tmq queueName

Specifies a trigger monitor queue name. If this option is used then WebSphere MQ process definitions are made to configure automatic triggering of SOAP/WebSphere MQ listeners with the associated trigger monitor queue name. If the option is not specified then no triggering configuration is made by the deployment utility. This option is mutually exclusive to the -s option.

If -s and -tmq are both specified, the deployment utility displays an error message and exits.

-u URI

Specifies a URI. By specifying the URI in this way at deploy time, the need to supply the URI with every client invocation is removed.

If a target service is specified in this URI, it must match the class supplied in the -f option. If a request queue is not specified in this URI, the queue name is generated as follows:

1. The full path name given in the -f parameter is taken and the file extension removed.

2. Any directory separator characters are replaced with period characters.

3. Any embedded spaces are replaced with underscore characters.

4. For a .NET service on Windows, a colon after any drive prefix is replaced with a period. The drive prefix itself is left intact.

5. The name is prefixed with "SOAPJ." for Java services or with "SOAPN." for .NET services.

6. The path name is truncated to no more than 48 characters, including the "SOAPJ." or "SOAPN." prefix. On platforms other than Windows, this is done by taking the "SOAPJ." prefix and then appending up to a maximum of the rightmost 42 bytes. On Windows systems, the SOAPN. prefix is taken. Then, if the service being deployed is a .NET service, the first character and period following arel also taken if these originally denoted a drive prefix. This leaves a maximum of either 42 or 40 characters which will be taken from the right side of the string.

It is possible in some environments that a queue name generated by the supplied deployment utility might not be unique. Although there is protection against this via the validation process described in Queue and directory validation, you might choose to safeguard further against this by either restructuring the deployment directory hierarchy or by customizing the supplied deployment process.

It is only possible to nominate a single URI to the deployment utility. This URI is used in both the default client and listener configurations built by the deployment utility. One implication of this is that if a binding=client option is specified in the URI given to the deployment utility, then a configuration is built that assumes binding=client both at the sender and the listener. You might want to use the binding=auto option if you have no local queue manager on the client side and therefore require a client connection at the sender and a server connection at the listener. If you require different URIs at the client and listener we can either modify the configuration built by the deployment utility or build your own deployment utility.

-v

Sets verbose output from external commands. (Error messages are displayed whether or not -v is set.) This can be useful for creating customized deployment scripts.

-x transactionality

The form of transactional control the listener should run under. transactionality can be set to one of the following values:

onePhase

WebSphere MQ one-phase support is used. If the system fails during processing, the request message is redelivered to the application. WebSphere MQ transactions ensure that the response messages are written exactly once. If the -x flag is omitted, or is used without a qualifying option, this is the default option assumed.

twoPhase

Two-phase support is used. If other resources are coordinated resource managers and the service is written appropriately the message is delivered exactly once with a single committed execution of the service.

This option applies to server bindings connections only.

none

No transactional support. If the system fails during processing, the request message can be lost (even if persistent). The service might or might not have executed, and response, report or dead-letter messages might or might not have been written.

The deployment utility checks for the compatibility of the -x and -a flags. See the description of the -a flag for details.

-?

Print out a help text describing how the command should be used.

SSL options

Options that can be specified for use with client connections over a channel configured to run in SSL mode are specified in Using SSL with WebSphere MQ transport for SOAP.