Friday, 16 August 2013

WebSphere MB NODES

WebSphere MQ  :

MQInput node :

- MQInput node is used to receive messages from clients that connect to the broker by using the WebSphere® MQ Enterprise Transport, and that use the MQI and AMI application programming interfaces.


The MQInput node handles messages in the following message domains:
  • XMLNSC
  • DataObject
  • JSON
  • BLOB
  • MIME
  • MRM
  • JMSMap
  • JMSStream
  • XMLNS
.


Terminals:

Out : The MQInput node routes each message that it retrieves successfully to the Out terminal.

Failure : If the backout count is exceeded (as defined by the BackoutThreshold attribute of the input queue), the message is routed to the Failure terminal.If you have not connected the Failure terminal, the message is written to the backout queue.

Catch : If the message is caught by this Input node after an exception has been thrown further on in the message flow, the message is routed to the Catch terminal.If you have not connected the Catch terminal, the message loops continually through the node until the problem is resolved.


Note:
-You must define a backout queue or a dead-letter queue (DLQ) to prevent the message from looping continually through the node.

Transaction Mode:

Automatic : The message is received under sync point if the incoming message is marked as persistent; otherwise, it is not received under sync point. Any message that is sent later by an output node is put under sync point, as determined by the incoming persistence property, unless the output node has overridden this property explicitly.

Yes (the default) : The message is received under sync point; that is, within a WebSphere MQ unit of work. Any messages that are sent later by an output node in the same instance of the message flow are put under sync point, unless the output node has overridden this explicitly.

No : The message is not received under sync point. Any messages that are sent later by an output node in the message flow are not put under sync point, unless an individual output node has specified that the message must be put under sync point.The MQOutput node is the only output node that you can configure to override this option.



Parse timing :

On Demand : On-demand parsing, referred to as partial parsing, is used to parse an input message bit stream only as far as is necessary to satisfy the current reference(Delayed).An input message can be of any length. To improve performance of message flows, a message is parsed only when necessary to resolve the reference to a particular part of its content. If none of the message content is referenced within the message flow (for example, the entire message is stored in a database by the DataUpdate node, but no manipulation of the message content takes place), the message body is not parsed.Therefore, fields might not be parsed until late in the message flow, or never. This restriction applies to both the message body and the message headers.

Immediate and Complete : Both override partial parsing and parse the entire message, including any message headers, except when the MRM parser encounters an element with a complex type with Composition set to Choice or Message that cannot be resolved at the time; for example, the content must be resolved by the user in ESQL. If Composition is set to Choice, the data is added to the message tree as an unresolved item, and parsing continues with the next element. If Composition is set to Message, parsing terminates at that point. The only difference in behavior between Immediate and Complete occurs when MRM validation is enabled.


Order mode :

-The order in which messages are retrieved from the input queue and processed.This property has an effect only if the message flow property Additional instances on the Instances tab, is set to greater than zero; that is, if multiple threads read the input queue.

Default : Messages are retrieved in the order that is defined by the queue attributes, but this order is not guaranteed because the messages are processed by the message flow.

User ID : Messages that have the same UserIdentifier value in the MQMD are retrieved and processed in the order that is defined by the queue attributes; this order is guaranteed to be preserved when the messages are processed. A message that is associated with a particular user identifier that is being processed by one thread, is completely processed before the same thread, or another thread, can start to process another message with the same user identifier. Ensure that each message has a unique message ID in the MQMD of the incoming message. No other ordering is guaranteed to be preserved.

Queue Order : Messages are retrieved and processed by this node in the order that is defined by the queue attributes; this order is guaranteed to be preserved when the messages are processed. This behavior is identical to the behavior that is exhibited if the message flow property Additional instances is set to zero. However, if you set Order mode to By Queue Order then redeploy the message flow, additional instances that are already running are not released. Therefore, when you set Order mode to By Queue Order, either stop and restart the message flow, or run the mqsireload command for the execution group after you redeploy the flow.

User Defined : You can specify a message element using the Order field location property. An XPath or ESQL expression property to control which part of the message is used to impose ordering on incoming messages when Order mode is User Defined. If the field is missing, an exception is raised, and the message is rolled back.

Logical order :

If you select this check box, messages are received in logical order, as defined by WebSphere MQ.If you clear the check box, messages that are sent as part of a group are not received in a predetermined order. If a broker expects to receive messages in groups, and you have not selected this check box, either the order of the input messages is not significant, or you must design the message flow to process them appropriately.


All messages available :

-Select All messages available if you want message retrieval and processing to be done only when all messages in a single group are available.
Match message ID,Match correlation ID :

- A message ID,Match correlation ID that must match the message ID in the MQMD of the incoming message. Enter a message identifier if you want the input node to receive only messages that contain a matching message identifier value in the MsgId field of the MQMD.

Browse Only :

-This property controls whether a message is removed from the queue when it is read. If you select this check box, the message is not removed from the queue when it is read. If you select this option, OutputLocalEnvironment.MQ.GET.Browsed is set to true when a message is propagated to the output terminal of the MQInput node.


MQOutput node :


Use the MQOutput node to send messages to clients that connect to the broker using the WebSphere® MQ Enterprise Transport and that use the MQI and AMI application programming interfaces.


Terminals:

In : Connect the In terminal to the node from which outbound messages bound are routed.

Out/Failure : Connect the Out or Failure terminal of this node to another node in this message flow to process the message further, process errors, or send the message to an additional destination.If you use aggregation in your message flows, you must use the output terminals.


Transaction Mode:

When you define an MQOutput node, the option that you select for the Transaction Mode property defines whether the message is written under sync point:
  • If you select Yes, the message is written under sync point (that is, within a WebSphere MQ unit of work).the message is put transactionally.
  • If you select Automatic (the default), the message is written under sync point if the incoming input message is marked as persistent.
  • If you select No, the message is not written under sync point.
Persistence Mode :

Persistence Mode, defines whether the output message is marked as persistent when it is put to the output queue:
  • If you select Yes, the message is marked as persistent.the message is put persistently.
  • If you select Automatic (the default), the message persistence is determined from the properties of the incoming message, as set in the MQMD.
  • If you select No, the message is not marked as persistent.
  • If you select As Defined for Queue, the message persistence is set as defined in the WebSphere MQ queue by the MQOutput node specifying the MQPER_PERSISTENCE_AS_Q_DEF option in the MQMD.

Destination Mode :

-The queues to which the output message is sent.

Queue Name(the default) : If you select Queue Name (the default), the message is sent to the queue that is named in the Queue Name property. If you select this option, you must set the Queue Manager Name and Queue Name properties.

Reply To Queue : If you select Reply To Queue, the message is sent to the queue that is named in the ReplyToQ field in the MQMD.When you select this value, the MQOutput node constructs a WebSphere MQ reply message.

Destination List : The message is sent to the list of queues that are named in the local environment that is associated with the message.

New Message ID/New Correlation ID :
- If you select this check box, WebSphere MQ generates a new message identifier/new correlation identifier to replace the contents of the MsgId field in the MQMD.

Segmentation Allowed : If you select this check box, WebSphere MQ breaks the message into segments in the queue manager. Clear the check box if you do not want segmentation to occur.

Message Context : When a security profile is associated with the node and is configured to perform identity propagation, the chosen context can be overridden to ensure that the outgoing identity is set.

Request :If you select the check box, each output message in the MQMD is generated as a request message and the message identifier field is cleared so that WebSphere MQ generates a new identifier.
Reply-to Queue : The name of the WebSphere MQ queue to which to put a reply to this request. This name is inserted into the MQMD of each output message as the reply-to queue.

MQReply node :


The MQReply node is a specialized form of the MQOutput node that puts the output message to the WebSphere® MQ queue that is identified by the ReplyToQ field of the input message header.

-Use the MQReply node to send a response to the originator of the input message. The MQReply node is a specialized form of the MQOutput node that puts the output message to the WebSphere® MQ queue that is identified by the ReplyToQ field of the input message header.

- Terminals(In,Failure & Out) , Segmentation ,  Persistence mode , Transaction mode ,Validation properties are same as defined for MQOutput node.

Saturday, 10 August 2013

WebSphere MQSI commands for MB

Broker Commands

FOR ADMINISTRATOR COMMANDS             -           RUNMQSICOMMANDCONSOLE

Create a broker and its associated resources -                           MQSICREATEBROKER (brokerName)  -i   (serviceUserId)  -a  (servicePassword)  -q  (queueManagerName)  -n  
                                                                                                          (dataSourceName)

Change one or more of the configuration parameters of the broker  -
                                                                                                MQSICHANGEBROKER
                                                                                                                  (brokerName)  

Delete a broker                                                                   -         MQSIDELETEBROKER   
                                                                                                                 (BrokerName)

Request the broker to stop and restart execution groups -    MQSIRELOAD(BrokerName)

Create deployable broker archive files containing message flows and dictionaries   
                                                                               -    MQSICREATEBAR -data  
                                            (WorkSpace) -o (FilePathOfMsgFlow)  -b (BarName)

Deployment request to the Configuration Manager           - MQSIDEPLOY -b
                   (brokerName) -e  (executionGroupName) -a  (BARFileName)



ConfigManager Commands


Create a Configuration Manager and its associated resources -   MQSICREATECONFIGMGR (ConfigmgrName)  -i  (ServiceUserID)  -a  (ServicePassword)  
                                                                                   -q  (QueueManagerName)
                                                                                           
Changes one or more of the properties of the Configuration Manager -   
MQSICHANGECONFIGMGR (ConfigmgrName)


Delete a named Configuration Manager     - MQSIDELETECONFIGMGR (ConfigmgrName)


Properties commands


Modify broker properties and properties of broker resources -          
MQSICHANGEPROPERTIES (BrokerName) -o  (ObjectName)  -n  (PropertyName) -v                                                                                                                
                                                                                            (PropertyValue)


Display properties that relate to a broker, an execution group, or a configurable service
MQSIREPORTPROPERTIES -o  (ObjectName)


Trace Commands


Display the trace options currently in effect   -      MQSIREPORTTRACE (Broker Name)
                               –u –e (ExecutionGroupName) –f (FlowName) –o (OutFileName)


Set the tracing characteristics for a component -    MQSICHANGETRACE  (Broker Name)
                                         -u – e (ExecutionGroupName) –f (FlowName) –r –l (Level)


Retrieve the trace log for the specified component -    MQSIREADLOG (Broker Name)  
                               –u –e (ExecutionGroupName) –f (FlowName) –o (OutFileName)


Process the XML log created by mqsireadlog  -      MQSIFORMATLOG –i (InputFileName)
                                                                                                –o (OutFileName)

Note : In the above trace commands Broker Name can be replaced by any component you wish to generate and read logs