| Author |
Message
|
| EricCox |
 Posted: Wed Sep 12, 2012 8:29 am Post subject: Cannot Retrieve HTTPRequestIdentifier |
 |
|
Master
Joined: 08 Apr 2011
Posts: 292
|
To all,
I have an HTTPInput Node receiving SOAP but cannot access the Destination.HTTP.RequestIdentifier.
I believe I can see it in the trace log but cannot access it in a following compute node.
I have this:
SOAPtoCWF
HTTPInput>>>TraceNode>>>ComputeNode>>>MQOutput>>>
${LocalEnvironment}
CWFtoSOAP
HTTPReply<<<<<<<<<ComputeNode>>>MQInput<<<<Host Mainframe
Here is the result of the TraceNode:
( ['MQROOT' : 0x179464464]
(0x01000000):Destination = (
(0x01000000):HTTP = (
(0x03000000):RequestIdentifier = X'414d5120514d424b5244303120202020402d4450202a601a' (BLOB)
)
)
)
But when I try to access InputLocalEnvironment.Destination.HTTP.RequestIdentifier I get this in the UserTrace:
Executing statement ''DECLARE requestId CHARACTER;'' at ('.RQ_ALS.Main', '36.3').
Executing statement ''SET requestId = InputLocalEnvironment.Destination.HTTP.RequestIdentifier;'' at ('.RQ_ALS.Main', '37.3').
('.RQ_ALS.Main', '37.19') : Failed to navigate to path element number '2' because it does not exist.
Evaluating expression ''InputLocalEnvironment.Destination.HTTP.RequestIdentifier'' at ('.RQ_ALS.Main', '37.19'). This resolved to ''InputLocalEnvironment.Destination.HTTP.RequestIdentifier''. The result was ''NULL''.
I'm just trying to access the value, assign it to a variable and see the value that is assigned.
Can someone point me to what I'm doing wrong to capture the HTTPRequestIdentifier? Or can you point me to what to look for that might be interfering with my ability to retrieve that value? |
|
| Back to top |
|
 |
| marko.pitkanen |
| Posted: Wed Sep 12, 2012 9:04 am Post subject: |
|
|
Chevalier
Joined: 23 Jul 2008
Posts: 440
Location: Jamsa, Finland
|
Hi EricCox,
I wonder in which compute node you try to access RequestIdentifier? I suppose in flow SOAPtoCWF?
--
Marko |
|
| Back to top |
|
|
| NealM |
| Posted: Wed Sep 12, 2012 10:36 am Post subject: |
|
|
Master
Joined: 22 Feb 2011
Posts: 230
Location: NC or Utah (depends)
|
Try declaring requestId as a BLOB, or include a CAST (from blob to char) in your SET statement.
(Note that in your trace node output the RequestIdentifier is clearly labeled as being of type BLOB) |
|
| Back to top |
|
|
| EricCox |
| Posted: Wed Sep 12, 2012 11:22 am Post subject: BLOB and Flow |
|
|
Master
Joined: 08 Apr 2011
Posts: 292
|
Hi Marko,
I've set the variable to BLOB and tried with no success.
And yes, I'm trying to access HTTPRequestIdentifier in the SOAPtoCWF Flow.
That node switches sets the HTTP Header to Null and outputs MQMD to the MQOutputNode.
Is setting the HTTP Header to Null clobering access to the HTTPRequestIdentifier. I'm going to add a new ComputeNode before the ComputeNode that switches the SOAPtoCWF and sends out the MQOutput Node and try that. |
|
| Back to top |
|
|
| NealM |
| Posted: Wed Sep 12, 2012 11:49 am Post subject: |
|
|
Master
Joined: 22 Feb 2011
Posts: 230
Location: NC or Utah (depends)
|
I still think it has to do with your types mixup. So instead of using a local variable, try this:
SET Environment.myHTTP.RequestId = InputLocalEnvironment.Destination.HTTP.RequestIdentifier;
That would take care of any type conflict. And no, nulling out your HTTP header in Root does not wipe out your LocalEnvironment. |
|
| Back to top |
|
|
| NealM |
| Posted: Wed Sep 12, 2012 1:16 pm Post subject: |
|
|
Master
Joined: 22 Feb 2011
Posts: 230
Location: NC or Utah (depends)
|
Eric, as a "by the way", it looks like you are maybe going to store your HTTP request ID someplace and retrieve it for use by an asynchronous HTTP reply flow?
Something you can do in a simple scenario like this when your flows are retrieving data in-between via standard MQ request/reply is to use your HTTP Request ID as your MQMD.MsgID in your request flow (just make sure you don't check the New Message ID box on the MQ Output Node), and then on your response flow, retrieve the ID from the incoming MQMD.CorrelId. That way there is nothing to save and retrieve.
Actual code from one of my flows:
In your webservice request flow:
SET OutputRoot.MQMD.MsgId = InputLocalEnvironment.Destination.HTTP.RequestIdentifier;
In your response flow:
SET OutputLocalEnvironment.Destination.HTTP.RequestIdentifier = InputRoot.MQMD.CorrelId;
Note that you can do the same thing also with MQ if your services use SOAP or TCPIP nodes for input (Broker v6.1.0.4 or newer) |
|
| Back to top |
|
|
| MBMQDeveloper |
| Posted: Wed Sep 12, 2012 10:27 pm Post subject: |
|
|
Novice
Joined: 02 Jul 2012
Posts: 19
|
If you do have access to MB v7 toolkit, you have a 'facade' pattern available which would help you sort out exactly the same problem. Have a look.  |
|
| Back to top |
|
|
| EricCox |
| Posted: Thu Sep 13, 2012 3:37 am Post subject: Right On Point |
|
|
Master
Joined: 08 Apr 2011
Posts: 292
|
You are all following what I'm trying to do perfectly.
I'm going to try all our suggestions today and until it works!
Thanks |
|
| Back to top |
|
|
| EricCox |
| Posted: Thu Sep 13, 2012 4:17 am Post subject: Moving Forward |
|
|
Master
Joined: 08 Apr 2011
Posts: 292
|
Progress!
Now I am able to set the RequestIdentifier in the Response Flows CWFtoSOAP Compute Node as such:
Executing statement ''SET OutputLocalEnvironment.Destination.HTTP.RequestIdentifier = InputRoot.MQMD.CorrelId;'' at ('.Build_STOPHOLDINFO_Response.Main', '9.3').
2012-09-13 08:09:30.175575 6704 UserTrace BIP2539I: Node 'ALS_RESPONSE_GETCONSLOANSTOPHOLDINFO.BuildResponse': Evaluating expression ''InputRoot.MQMD.CorrelId'' at ('.Build_STOPHOLDINFO_Response.Main', '9.67'). This resolved to ''InputRoot.MQMD.CorrelId''. The result was ''ROW... Root Element Type=50331648 NameSpace='' Name='CorrelId' Value=X'414d5120514d424b5244303120202020402d44502114df02'''
However, I am getting this error when sending out the HTTPReply Node. Can someone help guide me to the required decorations on the message as it goes out the HTTPReply Node.
BIP3143S: Message does not contain valid HTTP context information
Thanks,
Eric |
|
| Back to top |
|
|
| marko.pitkanen |
| Posted: Thu Sep 13, 2012 4:35 am Post subject: |
|
|
Chevalier
Joined: 23 Jul 2008
Posts: 440
Location: Jamsa, Finland
|
Hi Eric,
In your integration, you have joined asynchronous communication with back end application via MQ with synchronous communication via http with requester. This means that you have two independent flow execution instances.
LocalEnvironment that contains the original RequestIdentifier does not exist when the reply comes back from the back end application. This means you have to store and fetch the original RequestIdentifier some how, so that the httpReply -node can use it to response to the original http -session (that is to the original requester).
There are several ways you can implement this. One is, as already proposed, to include original RequestIdentifier to MsgId and ask the back end system to use it as an CorrelationId or even MsgId (as you tried already).
Another way is that you have business key in you data (also in the response that comes from the back end system) and you use it together with database (or perhaps even with SHARED ROW variable) to store and fetch the original RequestIdentifier.
--
Marko |
|
| Back to top |
|
|
| NealM |
| Posted: Thu Sep 13, 2012 6:20 am Post subject: |
|
|
Master
Joined: 22 Feb 2011
Posts: 230
Location: NC or Utah (depends)
|
Eric,
Just try building only your SOAP body response and adding the SOAPEnvelope Node in front of your HTTPReply Node. Check the Create new envelope box. Ignore setting the Existing Envelope Location, because as Marko said, it doesn't exist in your async response flow.
Note that you could also simplify your request flow by using the SOAPExtract Node prior to messing around with any XML-to-Host (COBOL?) conversions. (This assume you really have a SOAP structure with an envelope and a body) |
|
| Back to top |
|
|
| NealM |
| Posted: Thu Sep 13, 2012 6:28 am Post subject: |
|
|
Master
Joined: 22 Feb 2011
Posts: 230
Location: NC or Utah (depends)
|
| Another thought: Did you remember to NULL out your MQMD (and MQCIH if you have one) on your response? |
|
| Back to top |
|
|
| EricCox |
| Posted: Thu Sep 13, 2012 6:56 am Post subject: 6.0 MB :-( |
|
|
Master
Joined: 08 Apr 2011
Posts: 292
|
I'm on 6.0  I know it's out of support. That is a long long story.
I did null MQMD and am getting a response.
However, now I have to build soap from scratch without the SOAPNodes.
Grrrrrr...Executives? They definitely aren't developers. They should try doing my job one day...one. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Sep 13, 2012 7:11 am Post subject: Re: 6.0 MB :-( |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| EricCox wrote: |
| Grrrrrr...Executives? They definitely aren't developers. They should try doing my job one day...one. |
"Upgrade? Why should we upgrade? Where's the business benefit? Where's the Return On Investment? Faster code development? Better tooling? Where does that show up on the Profit And Loss? What do you mean 'out of support'; of course it's supported. We pay you to support it. Now stop whining and get back to 'work' while we work out next year's executive compensation package. That's real work; finding bonus schemes that marry up with tax avoidence strategies isn't as easy as you peons think"
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| NealM |
| Posted: Thu Sep 13, 2012 7:30 am Post subject: |
|
|
Master
Joined: 22 Feb 2011
Posts: 230
Location: NC or Utah (depends)
|
Eric, support pac ia9o had the SOAP Envelope and SOAPExtract Nodes in it, available for WMB v6.0. We used those for the couple years prior to v6.1 where they got incorporated. Same nodes.
One more thought: Did you check the Generate Headers box on the HTTPReply Node?
Update: Ah, I see that along with ending v6.0 support, IBM has also removed several of the support pacs that are no long needed for newer versions. I could send you the zip and pdf which being a pacrat (pun intended), I still have. However since there is a runtime element and you are still on v6.0, I'm guessing getting your admin to install it would be nearly impossible. Instead I'll look around for some old v6 or v5 webservice code and post it if I find it |
|
| Back to top |
|
|
|
|
