| Author |
Message
|
| tdwells |
 Posted: Thu May 08, 2003 6:55 am Post subject: Maintaining application data within containers |
 |
|
Apprentice
Joined: 30 Oct 2002
Posts: 42
|
I have a program activity node that has 1 input data structure format and 1 output data structure format that includes the same structure as the input, but with an additional section (something like a section to hold returning data from another system).
What I want to do (using XML and EXEXMLINPUTQ) is dump data from the program activity to a UPES queue and let the other system process the data (which works ok). The other system returns information concerning the success or failure of the processing (It does not return the original input data). Then this return data which would be routed to the EXEXMLINPUTQ is moved into the output data structure where I have defined the response information. This works correctly. The key is that I also want this program activity node to just take the information that was
in the 1st portion of the input data structure and pass it along to the
portion of the output data structure that matches the input data structure
(kind of like passing the original input data along, untouched).
Is my only option to use API calls or is there some little trick to do this
within workflow. Within the data connector between the 2 program activities, I tried just dragging-n-dropping the portions of the input
data structure to the portions of the output data structure that I wanted to
keep and pass along, but that did not work. The result was that the input
portion of the next program activity was blank since that section of the
output data structure of the previous UPES program activity was not
populated with data from the returning response. Any ideas.
_________________
IBM Certified Specialist - MQSeries |
|
| Back to top |
|
 |
| jmac |
| Posted: Thu May 08, 2003 7:04 am Post subject: |
|
|
Jedi Knight
Joined: 27 Jun 2001
Posts: 3081
Location: EmeriCon, LLC
|
Troy:
The program that you have written (UPES) gets the original message. So what you should do is simply copy that portion of the message into your response.
This can be somewhat tedious if you don't have a general purpose MQWF Container parser. For me this is quite easy since our (SYSCOM Inc. )MessageHandler parses the input message and builds what appear to be MQWF Containers (in actuality just hashtables) that are accessed via getString, getLong, getFloat, etc just like the MQWF Container objects.
GOOD LUCK
_________________
John McDonald
RETIRED |
|
| Back to top |
|
|
| Ratan |
| Posted: Thu May 08, 2003 8:02 am Post subject: |
|
|
Grand Master
Joined: 18 Jul 2002
Posts: 1245
|
we had a similar requirement. we had our UPES do the task of copying the portion of input structure to the output.
-Ratan. |
|
| Back to top |
|
|
| tdwells |
| Posted: Thu May 08, 2003 8:18 am Post subject: |
|
|
Apprentice
Joined: 30 Oct 2002
Posts: 42
|
Did the UPES trigger an application to do the copying of data?
_________________
IBM Certified Specialist - MQSeries |
|
| Back to top |
|
|
| jmac |
| Posted: Thu May 08, 2003 8:26 am Post subject: |
|
|
Jedi Knight
Joined: 27 Jun 2001
Posts: 3081
Location: EmeriCon, LLC
|
I can't give the definitive answer for Ratan, but I am betting that it was the UPES itself that did the copying.
When the UPES replys it should have in the Output container all of the data you wish to pass back to MQWF
_________________
John McDonald
RETIRED |
|
| Back to top |
|
|
| Ratan |
| Posted: Thu May 08, 2003 8:28 am Post subject: |
|
|
Grand Master
Joined: 18 Jul 2002
Posts: 1245
|
I am not the guy who implemented our UPES, so I am not sure. I dont really care if an application was triggered or not. The logic is to store the attribute values in a temporary storage and while returing the program response, see if anything was stored from input and copy them over.
-Ratan. |
|
| Back to top |
|
|
|
|
