| Author |
Message
|
| dkeister |
 Posted: Tue Jan 08, 2008 11:41 am Post subject: Bad XML in message to UPES |
 |
|
Disciple
Joined: 25 Mar 2002
Posts: 184
Location: Purchase, New York
|
We migrated from Workflow 3.5 to Workflow 3.6. FP 6 on MQ 6.0.2.2
I have a data container with XML data being sent to the queue for a UPES. The XML data is contained in a CDATA section:
<Action>
<Notification><![CDATA[<?xml version='1.0' encoding='UTF-8'?><NotificationCollection structure='Base'>
</NotificationCollection>]]>
</Notification>
<Comment>This is a test of workflow 3.6</Comment>
</Action>
The information within the CDATA is what I expect.
Now a second message is sent and the data looks like:
<Action>
<Notification><![CDATA[<?xml version='1.0' encoding='UTF-8'?><NotificationCollection structure='Base'>
</NotificationCollection>]]><?xml version='1.0' encoding='UTF-8'?><NotificationCollection structure='Base'></NotificationCollection>]]>
</Notification>
<Comment>This is a test of workflow 3.6</Comment>
</Action>
this message in the UPES queue is bad because it contains the extra:
<?xml version='1.0' encoding='UTF-8'?><NotificationCollection structure='Base'></NotificationCollection>]]>
in the Notification tag. Subsequent messages keep getting larger because each contains an additional ...
<?xml version='1.0' encoding='UTF-8'?><NotificationCollection structure='Base'></NotificationCollection>]]>
It appears to me that Workflow is not handling CDATA properly when building the message for the UPES (not clearing out an internal buffer or something...).
Has anyone seen this? Used XML as part of the data container data?
_________________
Dean Keister |
|
| Back to top |
|
 |
| dkeister |
| Posted: Tue Jan 08, 2008 1:29 pm Post subject: |
|
|
Disciple
Joined: 25 Mar 2002
Posts: 184
Location: Purchase, New York
|
Just an update to the prior post.
The container element contains:
<?xml version='1.0' encoding='UTF-8'?><NotificationCollection structure='Base'></NotificationCollection>
And that this was working under 3.4 and 3.5
_________________
Dean Keister |
|
| Back to top |
|
|
| jmac |
| Posted: Wed Jan 09, 2008 6:33 am Post subject: |
|
|
Jedi Knight
Joined: 27 Jun 2001
Posts: 3081
Location: EmeriCon, LLC
|
Dean:
If you haven't already done so, I would open a PMR. This looks strange.
_________________
John McDonald
RETIRED |
|
| Back to top |
|
|
| dkeister |
| Posted: Wed Jan 09, 2008 6:34 am Post subject: |
|
|
Disciple
Joined: 25 Mar 2002
Posts: 184
Location: Purchase, New York
|
Doing that as we speak!
_________________
Dean Keister |
|
| Back to top |
|
|
| hos |
| Posted: Thu Feb 28, 2008 11:50 pm Post subject: |
|
|
Chevalier
Joined: 03 Feb 2002
Posts: 470
|
Dean,
did you get a solution in the meantime?
Can you tell us the PMR # ?
This indeed seems to be a problem in 3.6.6.
Thanks. |
|
| Back to top |
|
|
| dkeister |
| Posted: Fri Feb 29, 2008 6:15 am Post subject: |
|
|
Disciple
Joined: 25 Mar 2002
Posts: 184
Location: Purchase, New York
|
Here is the PMR - PMR 35842,756,000 - message contains extra data from previous request
I closed it yesterday (having just returned from a fishing trip to Chile)...
Our original design placed XML data in a data container and with the first UPES request everything was OK but when the second request arrived it appeared that the data from the original request was partially included.
My guess is that they are not clearing a buffer some where.
However, we didn't use the data so removed our code to populate it as a workaround. THEN I got a request to recreate with trace but since we had a running workaround, and things are very busy here, we didn't have time to recreate ... so I told them to close the issue.
I know the problem is there ... I think someone in development could easily recreate without our 'assistance'.
Hope this helps.
Dean
_________________
Dean Keister |
|
| Back to top |
|
|
| hos |
| Posted: Mon Mar 03, 2008 7:06 am Post subject: |
|
|
Chevalier
Joined: 03 Feb 2002
Posts: 470
|
| There is an APAR IZ16766 for this problem. |
|
| Back to top |
|
|
|
|
