MQ Series BC - how to use is a request/reply scenario with access to MQ headers?

[Michael Czapski]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Hello,

I am in need of demonstrating an OpenESB solution in which a BPEL process is triggered by a MQ Series BC, receives the MQ message and MQ correlationId and MQ messageId headers, gets the address of the replyTo queue form the MQ headers, populates a message with the MQ correlationId the same as the inbound message correlationId and finally sends the response message to the replyTo queue form the original request message.

I have MQ connectivity sorted out in that I am able to receive MQ messages and access message body.

I am unable to retrieve message header values. The videocast which shows the use of MQ Series BC does MQ Put.

Can someone, please, let advise me on how to configure the MQ BC WSDL so I have access to headers and advise on how I can implement this kind of request/reply scenario with OpenESB and MQ BC?

Thanks in advance

Regards

Michael

[Noel Ang]

Michael Czapski wrote:

Hello,

I am in need of demonstrating an OpenESB solution in which a BPEL process is triggered by a MQ Series BC, receives the MQ message and MQ correlationId and MQ messageId headers, gets the address of the replyTo queue form the MQ headers, populates a message with the MQ correlationId the same as the inbound message correlationId and finally sends the response message to the replyTo queue form the original request message.

I have MQ connectivity sorted out in that I am able to receive MQ messages and access message body.

I am unable to retrieve message header values. The videocast which shows the use of MQ Series BC does MQ Put.

Can someone, please, let advise me on how to configure the MQ BC WSDL so I have access to headers and advise on how I can implement this kind of request/reply scenario with OpenESB and MQ BC?

Thanks in advance

Regards

Michael

Hello Michael,

The MQ BC conveys only the messageId and correlationId MQ header fields.  There is not a way to obtain the replyToQueue value in the current implementation.

To make available the messageId and correlationId data in a BPEL process, the mq:header extensibility element needs to be utilized in the service WSDL (the service that the BPEL process represents) to indicate to which message input part(s) to map these header fields.

For example, with the following definition fragment, the MQBC would assign the the correlationId and messageId field values of a message dequeued from MQ, into parts part2 and part3 of the input defined for the operation:

    <binding ...>
        <mq:binding/>
        <operation name="startEvent">
            <mq:operation queueName="QNAME" queueOpenOptions="1" transaction="NoTransaction"/>
            <input name="input1">
                <mq:body use="literal" SyncPoint="false" MessageType="ByteMessage" MessageBody="dd"/>
                <mq:header>
                      <correlationId parts="part2"/>
                      <messageId parts="part3"/>
                </mq:header>
            </input>
        </operation>
    </binding>

Noel
--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@...

[Michael Czapski]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Thanks, Noel.

Is there a plan to support replyToQueue property and, if yes, what is the expected timeframe? If not, what workaround would you suggest to facilitate implementation of a request/reply pattern with the response queue not known ahead of time and possibly different for each request?

What xsd data type are part2 and part3? Are then xsd:hexBinary? If yes, how can I dump their content into a log in BPEL 2.0?

Thanks for responding.

Regards

Michael


Noel Ang wrote:

Michael Czapski wrote:

Hello,

I am in need of demonstrating an OpenESB solution in which a BPEL process is triggered by a MQ Series BC, receives the MQ message and MQ correlationId and MQ messageId headers, gets the address of the replyTo queue form the MQ headers, populates a message with the MQ correlationId the same as the inbound message correlationId and finally sends the response message to the replyTo queue form the original request message.

I have MQ connectivity sorted out in that I am able to receive MQ messages and access message body.

I am unable to retrieve message header values. The videocast which shows the use of MQ Series BC does MQ Put.

Can someone, please, let advise me on how to configure the MQ BC WSDL so I have access to headers and advise on how I can implement this kind of request/reply scenario with OpenESB and MQ BC?

Thanks in advance

Regards

Michael

Hello Michael,

The MQ BC conveys only the messageId and correlationId MQ header fields.  There is not a way to obtain the replyToQueue value in the current implementation.

To make available the messageId and correlationId data in a BPEL process, the mq:header extensibility element needs to be utilized in the service WSDL (the service that the BPEL process represents) to indicate to which message input part(s) to map these header fields.

For example, with the following definition fragment, the MQBC would assign the the correlationId and messageId field values of a message dequeued from MQ, into parts part2 and part3 of the input defined for the operation:

    <binding ...>
        <mq:binding/>
        <operation name="startEvent">
            <mq:operation queueName="QNAME" queueOpenOptions="1" transaction="NoTransaction"/>
            <input name="input1">
                <mq:body use="literal" SyncPoint="false" MessageType="ByteMessage" MessageBody="dd"/>
                <mq:header>
                      <correlationId parts="part2"/>
                      <messageId parts="part3"/>
                </mq:header>
            </input>
        </operation>
    </binding>

Noel
--------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@...

[Michael Czapski]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Hello, Noel.

I configured the MQ BC as you suggested, with the exception of openOptions, which is 0 in my case and 1 in your case. What does openOptions of 1 do? When I add headers they are added with the tag names as in your example - mq:header. The wsdl becomes invalid until I change mq:header to mq:mqheader. Is this an issue? My part2 and part3 are xsd:hexBinary. I am getting nothing in them. I am using MQ sample amqsputc to put message to the queue so I can receive them. I don't know if amqsputc adds headers like messgeId. It is unlikely to be adding correlation id. I expect to see at least messageid populated.

Can you recommend a sample MQ client I can use that allows me to explicitly populate MQ correlationid header element?

Please advise.

Thanks in advance

Michael

Noel Ang wrote:

Michael Czapski wrote:

Hello,

I am in need of demonstrating an OpenESB solution in which a BPEL process is triggered by a MQ Series BC, receives the MQ message and MQ correlationId and MQ messageId headers, gets the address of the replyTo queue form the MQ headers, populates a message with the MQ correlationId the same as the inbound message correlationId and finally sends the response message to the replyTo queue form the original request message.

I have MQ connectivity sorted out in that I am able to receive MQ messages and access message body.

I am unable to retrieve message header values. The videocast which shows the use of MQ Series BC does MQ Put.

Can someone, please, let advise me on how to configure the MQ BC WSDL so I have access to headers and advise on how I can implement this kind of request/reply scenario with OpenESB and MQ BC?

Thanks in advance

Regards

Michael

Hello Michael,

The MQ BC conveys only the messageId and correlationId MQ header fields.  There is not a way to obtain the replyToQueue value in the current implementation.

To make available the messageId and correlationId data in a BPEL process, the mq:header extensibility element needs to be utilized in the service WSDL (the service that the BPEL process represents) to indicate to which message input part(s) to map these header fields.

For example, with the following definition fragment, the MQBC would assign the the correlationId and messageId field values of a message dequeued from MQ, into parts part2 and part3 of the input defined for the operation:

    <binding ...>
        <mq:binding/>
        <operation name="startEvent">
            <mq:operation queueName="QNAME" queueOpenOptions="1" transaction="NoTransaction"/>
            <input name="input1">
                <mq:body use="literal" SyncPoint="false" MessageType="ByteMessage" MessageBody="dd"/>
                <mq:header>
                      <correlationId parts="part2"/>
                      <messageId parts="part3"/>
                </mq:header>
            </input>
        </operation>
    </binding>

Noel
--------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@...

[Mark Foster-8]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Hi Noel,

I've been trying out the MQ BC using the snippet of WSDL you sent Michael and I too am unable to get the messageId property from the MQ Header.

I know that my input message has the messageId set....

I have changed the WSDL in my CA to have....


...and I have changed my WSDLs used by my BPEL to reference those (as hexBinary, base64Binary and even String), so I now see in my mappings.....


...but I still see nothing of the input messageId/correlationId in my returned message.

Is this an issue with BPEL, the MQ BC or my implementation ?

Thanks
Mark


Michael Czapski wrote:

Hello, Noel.

I configured the MQ BC as you suggested, with the exception of openOptions, which is 0 in my case and 1 in your case. What does openOptions of 1 do? When I add headers they are added with the tag names as in your example - mq:header. The wsdl becomes invalid until I change mq:header to mq:mqheader. Is this an issue? My part2 and part3 are xsd:hexBinary. I am getting nothing in them. I am using MQ sample amqsputc to put message to the queue so I can receive them. I don't know if amqsputc adds headers like messgeId. It is unlikely to be adding correlation id. I expect to see at least messageid populated.

Can you recommend a sample MQ client I can use that allows me to explicitly populate MQ correlationid header element?

Please advise.

Thanks in advance

Michael

Noel Ang wrote:

Michael Czapski wrote:

Hello,

I am in need of demonstrating an OpenESB solution in which a BPEL process is triggered by a MQ Series BC, receives the MQ message and MQ correlationId and MQ messageId headers, gets the address of the replyTo queue form the MQ headers, populates a message with the MQ correlationId the same as the inbound message correlationId and finally sends the response message to the replyTo queue form the original request message.

I have MQ connectivity sorted out in that I am able to receive MQ messages and access message body.

I am unable to retrieve message header values. The videocast which shows the use of MQ Series BC does MQ Put.

Can someone, please, let advise me on how to configure the MQ BC WSDL so I have access to headers and advise on how I can implement this kind of request/reply scenario with OpenESB and MQ BC?

Thanks in advance

Regards

Michael

Hello Michael,

The MQ BC conveys only the messageId and correlationId MQ header fields.  There is not a way to obtain the replyToQueue value in the current implementation.

To make available the messageId and correlationId data in a BPEL process, the mq:header extensibility element needs to be utilized in the service WSDL (the service that the BPEL process represents) to indicate to which message input part(s) to map these header fields.

For example, with the following definition fragment, the MQBC would assign the the correlationId and messageId field values of a message dequeued from MQ, into parts part2 and part3 of the input defined for the operation:

    <binding ...>
        <mq:binding/>
        <operation name="startEvent">
            <mq:operation queueName="QNAME" queueOpenOptions="1" transaction="NoTransaction"/>
            <input name="input1">
                <mq:body use="literal" SyncPoint="false" MessageType="ByteMessage" MessageBody="dd"/>
                <mq:header>
                      <correlationId parts="part2"/>
                      <messageId parts="part3"/>
                </mq:header>
            </input>
        </operation>
    </binding>

Noel
--------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@...