Topic
  • 7 replies
  • Latest Post - ‏2014-10-31T18:32:26Z by Ukumar_I
svolkers
svolkers
47 Posts

Pinned topic Multi Protocol Gateway correlation of messages to the backend request reply

‏2007-11-28T17:49:24Z |
I had presumed the correlation id is unquely assigned to each request and matched on the reply. Is this not correct? The backend service is claiming my correltion id is null. If I am to assign, what is the preferred method to assign it?
Updated on 2007-11-29T03:38:54Z at 2007-11-29T03:38:54Z by svolkers
  • SystemAdmin
    SystemAdmin
    6772 Posts

    Re: Multi Protocol Gateway correlation of messages to the backend request reply

    ‏2007-11-28T18:02:34Z  
    Hello, svolkers. A request message will not usually have a correlation ID. The receipient of a request will usually set the correlation ID of their respone to the message ID of the request. On the front side of a DataPower service, our MQ front side handler will do that that. On the back side of a DataPower server, we'll forward the processed request to the server without a correlation ID, and we expect the server to return a response to that request with the correlation ID equal to the message ID of the request we forwarded. That's how DataPower keeps track of MQ request/response pairs on the back side.
  • svolkers
    svolkers
    47 Posts

    Re: Multi Protocol Gateway correlation of messages to the backend request reply

    ‏2007-11-28T21:08:03Z  
    Hello, svolkers. A request message will not usually have a correlation ID. The receipient of a request will usually set the correlation ID of their respone to the message ID of the request. On the front side of a DataPower service, our MQ front side handler will do that that. On the back side of a DataPower server, we'll forward the processed request to the server without a correlation ID, and we expect the server to return a response to that request with the correlation ID equal to the message ID of the request we forwarded. That's how DataPower keeps track of MQ request/response pairs on the back side.
    Thanks Ben great explanation. The service I am interfacing with echoes back the correlation ID, any work around suggestions? Is there anyway to innject the msg id into the correlation id on the backend MQ handler? I need to preserve the web service front end session for the response.
  • SystemAdmin
    SystemAdmin
    6772 Posts

    Re: Multi Protocol Gateway correlation of messages to the backend request reply

    ‏2007-11-28T21:37:39Z  
    • svolkers
    • ‏2007-11-28T21:08:03Z
    Thanks Ben great explanation. The service I am interfacing with echoes back the correlation ID, any work around suggestions? Is there anyway to innject the msg id into the correlation id on the backend MQ handler? I need to preserve the web service front end session for the response.
    Hello, svolker. If I understand your situation correctly, it's the following:

    Request: service consumer (-> SOAP/HTTP ->) DataPower (-> MQ ->) service provider
    Response: service provider (-> MQ ->) DataPower (-> SOAP/HTTP ->) service consumer

    And, you're saying that the service provider is not setting the correlation ID of it's MQ response message to the message ID of DataPower's MQ request message (in which case, DataPower should not be able to correctly retrieve the response from you service provider). First, before trying to set the correlation ID of the request to the message using DataPower, you'll want to make sure that your service provider is actually copying the correlation ID from the request to the response (which would be unusual). If instead it is simply creating a new response message without copying the correlation ID from the request, then of course, setting the correlation ID on DataPower won't help your situation.

    You may find the following documentation excerpt useful for using a XSL stylesheet to set the MQMD header correlation ID value to the message ID value of the request before sending it from DataPower to the service provider. I haven't tried this yet myself.

    "Version 3.6.0.0 of the DataPower firmware introduces the ability to determine the full set of MQMD header values. This is done by setting the DataPower extension variable var://context/contextname/_extension/header/MQMD to a nodeset containing the desired values.

    Here is an example MQMD request header nodeset:

    <MQMD>
    <StrucId>MD </StrucId>
    <Version>1</Version>
    <Report>0</Report>
    <MsgType>8</MsgType>
    <Expiry>-1</Expiry>
    <Feedback>0</Feedback>
    <Encoding>546</Encoding>
    <CodedCharSetId>437</CodedCharSetId>
    <Format>MQSTR </Format>
    <Priority>0</Priority>
    <Persistence>0</Persistence>
    <MsgId>414d51205741535f6970315f7365727667b65c450a920020</MsgId>
    <CorrelId>000000000000000000000000000000000000000000000000</CorrelId>
    <BackoutCount>0</BackoutCount>
    <ReplyToQ>QUEUE5</ReplyToQ>
    <ReplyToQMgr>WAS_ip1_server1 </ReplyToQMgr>
    <UserIdentifier>mqm </UserIdentifier>
    <AccountingToken>1601000000000000000000b</AccountingToken>
    <ApplIdentityData> </ApplIdentityData>
    <PutApplType>11</PutApplType>
    <PutApplName>les\IBM\MQ-test\rfhutilc.exe</PutApplName>
    <PutDate>20061121</PutDate>
    <PutTime>21452170</PutTime>
    <ApplOriginData> </ApplOriginData>
    <GroupId>000000000000000000000000000000000000000000000000</GroupId>
    <MsgSeqNumber>1</MsgSeqNumber>
    <Offset>0</Offset>
    <MsgFlags>0</MsgFlags>
    <OriginalLength>-1</OriginalLength>
    </MQMD>

    By manipulating these header values, you can alter the behavior of the communications with the remote queue manager. For complete details regarding the effect and consequences of these values, see the relevant MQ documentation.

    It is important to note that you must create an MQMD header containing all desired elements whenever you want to change or add just one. So, for example, if you wanted to change the UserIdentifier header value sent to the back end queue, you would first need to save the entire MQMD header nodeset, change the desired value and then rewrite the MQMD header using the saved values."

    I've attached a XSL stylesheet written by Steve Loscialpo, an IBM DataPower Regional Architect, they may help get you started.
  • svolkers
    svolkers
    47 Posts

    Re: Multi Protocol Gateway correlation of messages to the backend request reply

    ‏2007-11-29T03:38:54Z  
    Hello, svolker. If I understand your situation correctly, it's the following:

    Request: service consumer (-> SOAP/HTTP ->) DataPower (-> MQ ->) service provider
    Response: service provider (-> MQ ->) DataPower (-> SOAP/HTTP ->) service consumer

    And, you're saying that the service provider is not setting the correlation ID of it's MQ response message to the message ID of DataPower's MQ request message (in which case, DataPower should not be able to correctly retrieve the response from you service provider). First, before trying to set the correlation ID of the request to the message using DataPower, you'll want to make sure that your service provider is actually copying the correlation ID from the request to the response (which would be unusual). If instead it is simply creating a new response message without copying the correlation ID from the request, then of course, setting the correlation ID on DataPower won't help your situation.

    You may find the following documentation excerpt useful for using a XSL stylesheet to set the MQMD header correlation ID value to the message ID value of the request before sending it from DataPower to the service provider. I haven't tried this yet myself.

    "Version 3.6.0.0 of the DataPower firmware introduces the ability to determine the full set of MQMD header values. This is done by setting the DataPower extension variable var://context/contextname/_extension/header/MQMD to a nodeset containing the desired values.

    Here is an example MQMD request header nodeset:

    <MQMD>
    <StrucId>MD </StrucId>
    <Version>1</Version>
    <Report>0</Report>
    <MsgType>8</MsgType>
    <Expiry>-1</Expiry>
    <Feedback>0</Feedback>
    <Encoding>546</Encoding>
    <CodedCharSetId>437</CodedCharSetId>
    <Format>MQSTR </Format>
    <Priority>0</Priority>
    <Persistence>0</Persistence>
    <MsgId>414d51205741535f6970315f7365727667b65c450a920020</MsgId>
    <CorrelId>000000000000000000000000000000000000000000000000</CorrelId>
    <BackoutCount>0</BackoutCount>
    <ReplyToQ>QUEUE5</ReplyToQ>
    <ReplyToQMgr>WAS_ip1_server1 </ReplyToQMgr>
    <UserIdentifier>mqm </UserIdentifier>
    <AccountingToken>1601000000000000000000b</AccountingToken>
    <ApplIdentityData> </ApplIdentityData>
    <PutApplType>11</PutApplType>
    <PutApplName>les\IBM\MQ-test\rfhutilc.exe</PutApplName>
    <PutDate>20061121</PutDate>
    <PutTime>21452170</PutTime>
    <ApplOriginData> </ApplOriginData>
    <GroupId>000000000000000000000000000000000000000000000000</GroupId>
    <MsgSeqNumber>1</MsgSeqNumber>
    <Offset>0</Offset>
    <MsgFlags>0</MsgFlags>
    <OriginalLength>-1</OriginalLength>
    </MQMD>

    By manipulating these header values, you can alter the behavior of the communications with the remote queue manager. For complete details regarding the effect and consequences of these values, see the relevant MQ documentation.

    It is important to note that you must create an MQMD header containing all desired elements whenever you want to change or add just one. So, for example, if you wanted to change the UserIdentifier header value sent to the back end queue, you would first need to save the entire MQMD header nodeset, change the desired value and then rewrite the MQMD header using the saved values."

    I've attached a XSL stylesheet written by Steve Loscialpo, an IBM DataPower Regional Architect, they may help get you started.
    Great, this should work. I have verified the service provider does copy the correlation ID provided. It is perhaps not the standard approach, but I have learned, it was the negotiated correlation matching mechanism. Thank you for the detailed explanation. One last point of interest..... I understand what you have provided, but I am curious when the msgid is available during the policy processing? I presume from your explanation it must be assigned and available from the start of the policy processing.
  • chandraX-
    chandraX-
    7 Posts

    Re: Multi Protocol Gateway correlation of messages to the backend request reply

    ‏2013-05-21T20:13:29Z  
    • svolkers
    • ‏2007-11-29T03:38:54Z
    Great, this should work. I have verified the service provider does copy the correlation ID provided. It is perhaps not the standard approach, but I have learned, it was the negotiated correlation matching mechanism. Thank you for the detailed explanation. One last point of interest..... I understand what you have provided, but I am curious when the msgid is available during the policy processing? I presume from your explanation it must be assigned and available from the start of the policy processing.

    MsgID shd be available from the point were you introduce the MQ header action. (or if the incoming reuqest is MQ, it already have it).

     

    This shd help, if you need to modify MQMD,

    http://publib.boulder.ibm.com/infocenter/wsdatap/4mt/index.jsp?topic=%2Fcom.ibm.dp.xi.doc%2Fintegratingwithmq38.htm

    Updated on 2013-05-21T20:15:02Z at 2013-05-21T20:15:02Z by chandraX-
  • Sudarshan Bandaru
    Sudarshan Bandaru
    61 Posts

    Re: Multi Protocol Gateway correlation of messages to the backend request reply

    ‏2014-10-31T17:34:33Z  
    • chandraX-
    • ‏2013-05-21T20:13:29Z

    MsgID shd be available from the point were you introduce the MQ header action. (or if the incoming reuqest is MQ, it already have it).

     

    This shd help, if you need to modify MQMD,

    http://publib.boulder.ibm.com/infocenter/wsdatap/4mt/index.jsp?topic=%2Fcom.ibm.dp.xi.doc%2Fintegratingwithmq38.htm

    Hi Chandra,

    How to get the generated MsgId in DataPower?

  • Ukumar_I
    Ukumar_I
    8 Posts

    Re: Multi Protocol Gateway correlation of messages to the backend request reply

    ‏2014-10-31T18:32:26Z  

    Hi Chandra,

    How to get the generated MsgId in DataPower?

       following is sample code to get it..
        <!-- get the MQMD header from the request message -->
        <xsl:variable name="entries" select="dp:request-header('MQMD')"/>
         <!-- parse into a usable nodeset -->
        <xsl:variable name="header" select="dp:parse($entries)"/>
         <!-- store the desired values in a variable available for later -->
        <xsl:variable name="MsgId" select="$header//MsgId"/>

     

    regards

    ud