| Author |
Message
|
| Esa |
 Posted: Fri Nov 22, 2013 4:26 am Post subject: HttpRequest node clears InputLocalEnvironment |
 |
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
Does anybody have an idea why HttpRequest node clears InputLocalEnvironment?
If I set OutputLocalEnvironment.Destination.HTTP.RequestURL, it's no longer in place after the PROPAGATE call has returned. Not to talk about the other stuff I would like to have in OutputLocalEnvironment, it's just plain empty.
Message Broker 8.0.0.2 |
|
| Back to top |
|
 |
| dogorsy |
| Posted: Fri Nov 22, 2013 4:41 am Post subject: Re: HttpRequest node clears InputLocalEnvironment |
|
|
Knight
Joined: 13 Mar 2013
Posts: 553
Location: Home Office
|
| Esa wrote: |
If I set OutputLocalEnvironment.Destination.HTTP.RequestURL |
If you set the OutputLocalEnvironment, why you expect the InputlocalEnvironment to be set on return from the PROPAGATE ? |
|
| Back to top |
|
|
| Esa |
| Posted: Fri Nov 22, 2013 4:46 am Post subject: Re: HttpRequest node clears InputLocalEnvironment |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
| dogorsy wrote: |
| Esa wrote: |
If I set OutputLocalEnvironment.Destination.HTTP.RequestURL |
If you set the OutputLocalEnvironment, why you expect the InputlocalEnvironment to be set on return from the PROPAGATE ? |
Well, the OutputLocalEnvironment of the preceding compute node becomes the InputLocalEnvironment of the following HttpRequest node, naturally.
And if the stuff I put in OutputLocalEnvironment is not there any more after the node has propagated to a HttpRequest node, it must be because the HttpRequest cleared it's whole InputLocalEnvironment. Not only the area that it possibly used for its temporary stuff, but also the stuff that belonged to me.
Not to talk about the stuff that should have belonged to both of us... |
|
| Back to top |
|
|
| dogorsy |
| Posted: Fri Nov 22, 2013 4:52 am Post subject: |
|
|
Knight
Joined: 13 Mar 2013
Posts: 553
Location: Home Office
|
Can you please explain ?
In your compute node, before the httprequest, you have inputLE and outputLE. you set the outputLE with some values. On return from the httprequest, you WILL NOT HAVE the values you set in the outputLE in the inputLE.
In the inputLE you should have the ones you received from the preceeding node ( and the httprequest IS NOT a preceeding node ).
Last edited by dogorsy on Fri Nov 22, 2013 4:57 am; edited 2 times in total |
|
| Back to top |
|
|
| mgk |
| Posted: Fri Nov 22, 2013 4:55 am Post subject: |
|
|
Padawan
Joined: 31 Jul 2003
Posts: 1642
|
| Quote: |
| OutputLocalEnvironment is not there any more after the node has propagated to a HttpRequest node, it must be because the HttpRequest cleared it's whole InputLocalEnvironment |
Wrong. It's actually the PROPAGATE statement that clears the OutputLocalEnvironment when it returns (along with OutputRoot and OutputExceptionList), unless you use the DELETE NONE clause on the PROPAGATE statement...
Kind regards,
_________________
MGK
The postings I make on this site are my own and don't necessarily represent IBM's positions, strategies or opinions. |
|
| Back to top |
|
|
| Esa |
| Posted: Fri Nov 22, 2013 5:05 am Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Nov 22, 2013 7:42 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
This is one reason why it's very odd that the GDM does not let you access Environment, but only lets you access LocalEnvironment.
Most of the techniques for using Environment tree in a multi-node propagate loop structure aren't possible using GDM, so one either has to make extra effort to ensure that local environment is preserved, or put in extra effort to map between Environment and LocalEnvironment outside the GDM.
It's a very very very odd design choice. |
|
| Back to top |
|
|
| Esa |
| Posted: Sun Nov 24, 2013 2:17 am Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
This hasn't much to do with my original problem of forgetting to define DELETE NONE with PROPAGATE every now and then, but I do have some comments.
| mqjeff wrote: |
| This is one reason why it's very odd that the GDM does not let you access Environment, but only lets you access LocalEnvironment. |
In fact GDM doesn't let you access LocalEnvironment either, just individual scalar values in it. You cannot modify InputLocalEnvironment event with custom ESQL, because you are not allowed to pass references.
| mqjeff wrote: |
Most of the techniques for using Environment tree in a multi-node propagate loop structure aren't possible using GDM, so one either has to make extra effort to ensure that local environment is preserved, or put in extra effort to map between Environment and LocalEnvironment outside the GDM.
It's a very very very odd design choice. |
Mapping routines are for building completely new output trees, not for modifying existing trees. Like InputRoot, InputLocalEnvironment and Environment.
This must be because modifying an existing tree with a mapping tool is a far more complex task than it seems.
It's relatively easy to map against a database table, because there is a standard way to define a key or a compound key that the mapping routine can compare to determine if it must update an existing record or create a new one. This is not the case when you modify message structures in situ. For example, if you used an enriching map task to map input OrderLine.ProductCode to output OrderLine.Productcode, the routine must determine if it should modify the existing Orderline element or create a new one. Should it modify the existing element if sequenceNumber attribute is same in both source and target? Or should customerNumber be the same, too? You would have to somehow inject these rules in the mapping task.
The fact that you cannot propagate a modified Environment or InputLocalEnvironment tree from a mapping node makes it not the best choice to be used in propagate loops. Or any propagate yo-yo's regardless if they are called within a loop or not.
Fortunately there are good alternatives. I don't think there is any need to enhance the graphical mapper, it should remain a simple tool for simple tasks. |
|
| Back to top |
|
|
|
|
