The MSMQSender component is used to send messages to MSMQ. The component supports different formatters that can format the incoming messages in a form that is recognizable by various client applications to receive. The name of the queue to which a message needs to be sent can be specified using the CPS.

Points to note

• If a queue specified in the CPS does not exist in a local or remote MSMQ server, it is not automatically created.
• This component runs only on Windows Platform.
• This component requires Microsoft .NET Framework 2.0 or above installed on the machine where peer server is running.
• The component sends a message of string type when object Type property is set to false, When the message is to be sent in a particular object type, that object type must confirm to the XMLSerializer. Hence the component supports sending messages of types that can be serialized/deserialized using XMLSerializer. For more information on XMLSerializer, refer to http://msdn.microsoft.com/en-us/library/system.xml.serialization.xmlserializer.aspx

Configuration

The MSMQ server, queue and formatters can be configured in the CPS.

Figure 1: Sample MSMQ server configuration

Error Configuration

Error Handling Configuration

Please refer Error Handling section Common Configurations page for details.

Connection Configuration

Server Name

Name of the server to be used for communicating with the Queue Manager.

Provide MachineName in case of OS protocol, IP Address in case of TCP protocol and NetworkNumber; HostNumber in case of SPX. IP address or full DNS name of the host computer (or the computer name within an enterprise) in case of HTTP/HTTPS

Queue Name

Name of the Queue to which a component needs to be connected to.

Queue Type

Name of the Queue to which a component needs to be connected to; choose form the following options available:

• private
• public

Protocol

Protocol to be used to retrieve/send messages from/to MSMQ server. Use 'OS' to access with Machine Name and 'TCP' to access with IP Address. To use HTTP/HTTPS MSMQ HTTP Support should have been installed during MSMQ installation.

Options available are:

• OS
• HTTP
• HTTPS
• TCP
• SPX

Transaction

Specifies whether the queue is transacted or not. If this property is enabled, it represents a transacted operation; each message will be wrapped in a transaction while sending.

Message Configuration

Message Formatter

Type of formatter to be used. MSMQSender supports three type of formatters.

The three types of formatters available are explained below.

• ActiveXMessageFormatter
  This formatter has to be used to send messages whose body is formatted in a way that is compatible with the MSMQ ActiveX Component. The ActiveXMessageFormatter is compatible with messages of Message Queuing COM components, allowing interoperability with applications that use the MSMQ COM control. MSMQSender component supports only primitive data types for ActiveXMessageFormatter
• BinaryMessageFormatter
  This formatter has to be used to send messages whose body are to be serialised using a binary format. The BinaryMessageFormatter is very efficient and can be used to serialize most objects. The objects which are marked as serializible can be used with this formatter. With MSMQSender component to send messages of non primitive data types, Assembly(dll) containing the particular class type should be explicitly added as a resource to the component.
  
• XMLMessageFormatter
  This formatter has to be used to send messages whose body are to be serialised using a XML format. The XmlMessageFormatter is the default formatter that an instance of MessageQueue uses to serialize messages written to the queue. With MSMQSender component to send messages of non primitive data types, Assembly(dll) containing the particular class type whose schema matches to the sender type should be explicitly added as a resource to the component.

ObjectType

If enabled, message body of an object type can be sent. By default, the component sends message of string type. The name of the assembly and fully namespace qualified class names (for example, System.Messaging.Message) or primitive type names(int etc) should be provided in Assembly Name and Class Name properties respectively in the CPS of the component.

Assembly Name

Name of the assembly (along with extension i.e Test.dll) containing class types that will be available on queue. This field is not required if messages of primitive data types are to be received

Class Name

Namespace qualified class name of message type (e.g System.Messaging.Message). In case of primitive data types provide keywords of corresponding type (like int)

XSD of message body

XML schema definition of input message. In case of object types, input message should confirm to schema of the class type provided.

Recoverable

If set to 'yes', the delivery of a message is guaranteed even if a computer crashes while the message is en route to the destination queue.

Use Acknowledgement

When MSMQ is used in an offline (disconnected) mode or message is sent to non existent remote queues or non transactional message sent to transactional queues, messages will be sent to outgoing queues and will be sent or discarded later to their respective destination. Component will immediately give output sending message as successful, but it is not guaranteed delivered to the destination. In such cases, if this property is enabled, component will request acknowledgement messages and only after reception of positive acknowledgement of delivery, component will output sending as successful else an exception will be thrown. In this case, component will create a local queue by the name "fioranoadminqueuefioranotempackqueue" where acknowledgement messages will be received and processed by the component.

Use Timeout

When this option is enabled, component will wait for acknowledgement of delivery till configured time out interval after which exception will be thrown. Message will not be delivered after this time interval. If disabled component will wait infinitely for acknowledgement.

Timeout

Maximum time interval in milliseconds after which exception will be thrown if message is not delivered.

Scheduling Configuration

Enable Scheduling

When this option is set to yes, the component will try to send messages for configured number of times for the interval provided, else input has to be sent to the component to send message. Input port will be disabled for this case

Enable Scheduling

Select 'yes' to schedule the component. Input port will be disabled for this option.

Repeat Interval

Time interval in milliseconds between repeats.

Repeat Count

Number of times to be repeated. use '0' for infinite times.

 

Input Message

On clicking the ellipsis  button, an editor will be opened where option is available to generate sample message based on schema or you may provide a valid schema.

Message Properties

Apart from the above CPS properties, certain other properties can be set as JMS header properties on the incoming message to the component which will be set to the message being sent to the queue. All these properties should be of string type

• MSMQ_CORRELATION_ID: Sets the message identifier to reference the original message.
• MSMQ_MESSAGE_LABEL: Sets an Unicode string that describes the message
• MSMQ_PRIORITY: Sets the message priority, which determines where in the queue the message is placed. It can take the values from 0 to 7.
• MSMQ_TTL: Sets the maximum amount of time for the message to reach the queue. The message is discarded without input into queue, if that time interval is exhausted. Time interval must be in milliseconds
• MSMQ_USE_JOURNAL_QUEUE: Sets a value that indicates whether a copy of the message should be kept in a machine journal on the originating computer.
• MSMQ_USE_DEADLETTER_QUEUE: Sets a value that indicates whether a copy of the message that could not be delivered should be sent to a dead-letter queue.

Input Schema

Scenario 1

When Use Connection from input is set to No and there is no schema set XSD of message body

In this case, There is no schema that the Input port requires. The input message can simply be any plain text

Scenario 2

When Use Connection from input is set to No and there is a schema set XSD of message body

In this case, The Input port requires the message to be in XML format and it must confirm to the XSD set inside the CPS


Figure 2: Input Schema When Use Connection from input is set to No and there is a schema set XSD of message body

Scenario 3

When Use Connection from input is set to Yes and there is no schema set XSD of message body

In this case, The Input port requires the message to be in XML format and it should contain all the Connection-configuration values. The XSD for the message is generated automatically and it has an element defined for each property of the CPS. For any value not specified in the input message, the values set inside the CPS will be taken by default


Figure 3: Input Schema When Use Connection from input is set to Yes and there is no schema set XSD of message body

Scenario 4

When Use Connection from input is set to Yes and there is a schema set XSD of message body

In this case, The Input port requires the message to be in XML format and it should contain all the Connection-configuration values along with the XSD required for the message body. The XSD for the message is generated automatically and it has an element defined for each property of the CPS along with an element "Body" which contains the XSD of the message body. For any value not specified in the input message, the values set inside the CPS will be taken by default.


Figure 4: Input Schema When Use Connection from input is set to Yes and there is a schema set XSD of message body

Functional Demonstration

Scenario 1

Send messages to a local MSMQ Server.

Configure the MSMQ Sender in scheduling mode and provide required assemblies for XMLMessageFormatter and use Display component to check the response.

Figure 5: Demonstrating Scenario 1 with sample output

Figure 6: Sample Output