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

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
    ACCEPTED ANSWER

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

    ‏2007-11-28T18:02:34Z  in response to svolkers
    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
      ACCEPTED ANSWER

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

      ‏2007-11-28T21:08:03Z  in response to SystemAdmin
      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
        ACCEPTED ANSWER

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

        ‏2007-11-28T21:37:39Z  in response to svolkers
        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
          ACCEPTED ANSWER

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

          ‏2007-11-29T03:38:54Z  in response to SystemAdmin
          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
            ACCEPTED ANSWER

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

            ‏2013-05-21T20:13:29Z  in response to svolkers

            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
              34 Posts
              ACCEPTED ANSWER

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

              ‏2014-10-31T17:34:33Z  in response to chandrax

              Hi Chandra,

              How to get the generated MsgId in DataPower?

              • Ukumar_I
                Ukumar_I
                8 Posts
                ACCEPTED ANSWER

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

                ‏2014-10-31T18:32:26Z  in response to Sudarshan Bandaru
                   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