| Author |
Message
|
| dg_sl_uk |
 Posted: Tue Jan 13, 2004 6:41 am Post subject: Runtime data container mapping query |
 |
|
Newbie
Joined: 09 Jan 2004
Posts: 5
Location: United Kingdom
|
Hi
I've got a question regarding a problem with my data container.
The problem is basically that information present in the input data container for a UPES activity in my flow, is not present in the output data container.
Curiously, this only happens I'm writitng data to the data container from the UPES. I have verified this by temporarily removing the esql in the UPES concerned with setting stuff in the data container.
When the UPES is not accessing the data container, the information gets passed happily between input and output data containers.
However, as mentioned above, when the UPES does write to the data container it looks like the existing information is overwritten.
I have also verified that I have default data connectors in the right places and that I have set the inputs and outputs to the correct (identical) data structure.
As a newcomer to MQSW (see earlier posts !  ) I'm at a bit of a loss as to what's going on.....
Thanks in advance for any advice
Dave  |
|
| Back to top |
|
 |
| vennela |
| Posted: Tue Jan 13, 2004 9:38 am Post subject: |
|
|
Jedi Knight
Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India
|
| Quote: |
However, as mentioned above, when the UPES does write to the data container it looks like the existing information is overwritten.
|
I don't see anything wrong with this kind of behaviour.
If you send workflow a response from the UPES, the values that you give in the response will be used. Otherwise, the mapped values from input container to output container will be used. |
|
| Back to top |
|
|
| MaheshPN |
| Posted: Tue Jan 13, 2004 10:44 am Post subject: |
|
|
Master
Joined: 21 May 2003
Posts: 245
Location: Charlotte, NC
|
Hi Dave,
If you know what data elements come from UPES response and you want to retain the rest of the data from input container, map field to field.
-In the data connector map only the field which come from UPES.
-In the Default connector map the fields, that want to transfer from input to the output container.
Hope this will help !!!
-Mahesh
IBM Certified Solution Expert - MQWorkflow |
|
| Back to top |
|
|
| jmac |
| Posted: Tue Jan 13, 2004 11:52 am Post subject: |
|
|
Jedi Knight
Joined: 27 Jun 2001
Posts: 3081
Location: EmeriCon, LLC
|
Dave:
When you get your initial message the ProgramOutputDefaults should contain all of the data that you mapped via the data default connector. When you send back your Reply you should make sure it contains these members.
_________________
John McDonald
RETIRED |
|
| Back to top |
|
|
| dg_sl_uk |
| Posted: Wed Jan 14, 2004 3:51 am Post subject: |
|
|
Newbie
Joined: 09 Jan 2004
Posts: 5
Location: United Kingdom
|
Hi
Thanks for the advice everyone.
There was some confusion over how default data connectors interact with UPES data. I had thought the only the information modifed by the UPES would be written back into the data container, and that the info passed by default would be retained.
"D'oh!"
I'll try implementing your suggestions 
Dave |
|
| Back to top |
|
|
| anuppc |
| Posted: Mon Feb 09, 2004 8:29 am Post subject: How does the default data connector Mapping work with UPES? |
|
|
Voyager
Joined: 22 Oct 2002
Posts: 93
Location: Montreal
|
Hi All,
I'm using MQWF 3.4 with sp4. I have an FDL with an synchronous UPES activity. Some of the data elements are updated by another application in the response message. In the model i have a default connector mapping the input container with the output container. I expected the response message to update only those elements which have been updated. To my surprise i see that all the elements are overwritten (making the default data connector ineffective). Thus i loose some original data.
Please let me know if this is normal.
Yes i did notice "jmac's comment"
"When you get your initial message the ProgramOutputDefaults should contain all of the data that you mapped via the data default connector. When you send back your Reply you should make sure it contains these members."
Does that mean that the connector or message handler will have to store these defaults and remember to add these defaults in the response msg?
It would have been cool if workflow would automatically update elements from <ProgramOutputData> of the response and map the unchanged elements via the default data connector.
_________________
BlowFish |
|
| Back to top |
|
|
| john_sharp |
| Posted: Fri Mar 26, 2004 10:10 am Post subject: Pity that the UPES has to do the default mappings |
|
|
Newbie
Joined: 17 Mar 2004
Posts: 2
Location: Edinburgh, Scotland
|
I agree with the sentiments of the previous post that "it would have been cool" if MQSW would execute the default mappings. I'd find fault with the MQSW documentation (help screens and manuals) here, since they would lead you to understand that MQSW is going to execute some helpful copying from UPES input to output container of elements with defined default mappings, where there is no explicit occurrence of these XML elements in the UPES reply.
But all that MQSW is really going to do is give the UPES the information needed - in the shape of the static mappings and runtime input values in <ProgramOutputDate> and chuck the responsibility onto the UPES to do it. I didn't understand this from MQSW help/manuals until I came across some supplementary paper from Kurt Fleckenstein (Boeblingen).
Rather than have processes build a large number of MQSW Sata Structures, each customised to a UPES input and output, with lots of complex data flow mappings, I'd rather keep to a limited number of structures in the process (maybe just one in a small process), and allow the UPES to use a subset of the elements in its input and ouput container. To keep faith with this approach, each of our UPES activities will be burdened with maintaining the state of a set of elements in which it has no functional interest and merging the application reply with these when it responds to MQSW.
What this will probably force us to do is implement, in a top layer of our UPES, some physical caching of the <ProgramOutputData> together with process-dependent code to merge default map data with the reply data coming back from the invocation of a lower layer of application function - somewhat messy and laborious, since I can't see a generic way to compose the merged reply.
To me the natural place to tackle this would have been inside MQSW, when it gets the UPES reply - since it has all the mappings needed. I guess that this is too much to hope for - but I think that
- executing default data mappings for synchronous UPES invocations is a common requirement
- the product documentation is poor, and I think that from my contacts the way it works is not well-understood by IBM support people.
Maybe this would be a good candidate for a SupportPac.
_________________
John S Sharp |
|
| Back to top |
|
|
|
|
