| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Difference in 6.0.2 and 6.1 |
« View previous topic :: View next topic » |
| Author |
Message
|
| francoisvdm |
 Posted: Tue Oct 28, 2008 3:51 am Post subject: Difference in 6.0.2 and 6.1 |
 |
|
Partisan
Joined: 09 Aug 2001
Posts: 332
|
windows platform:
I deploy the same message flow and message set in V6.0.2 and V6.1 and I see the following difference:
Writing XMLNS data to a queue, in V6.0.2 it looks like:
<NS4:PURCHAS_ORDER_NUMBER></NS4:PURCHAS_ORDER_NUMBER>
and in V6.1 it looks like:
<NS4:PURCHAS_ORDER_NUMBER/>
Where can I control this behavior?
Thank you
_________________
If you do not know the answer or you get the urge to answer with "RTFM" or "Search better in this forum", please refrain from doing so, just move on to the next question. Much appreciated.
Francois van der Merwe |
|
| Back to top |
|
 |
| mdmader |
| Posted: Tue Oct 28, 2008 11:49 am Post subject: Re: Difference in 6.0.2 and 6.1 |
|
|
Newbie
Joined: 17 Apr 2008
Posts: 7
|
| francoisvdm wrote: |
windows platform:
I deploy the same message flow and message set in V6.0.2 and V6.1 and I see the following difference:
Writing XMLNS data to a queue, in V6.0.2 it looks like:
<NS4:PURCHAS_ORDER_NUMBER></NS4:PURCHAS_ORDER_NUMBER>
and in V6.1 it looks like:
<NS4:PURCHAS_ORDER_NUMBER/>
Where can I control this behavior?
Thank you |
Should be something like this:
SET OutputRoot.XMLNS.NS4.PURCHAS_ORDER_NUMBER.(XML.Content) = NULL;
Should generate <NS4:PURCHAS_ORDER_NUMBER></NS4:PURCHAS_ORDER_NUMBER> rather than the <NS4:PURCHAS_ORDER_NUMBER/>. |
|
| Back to top |
|
|
| francoisvdm |
| Posted: Tue Oct 28, 2008 8:07 pm Post subject: |
|
|
Partisan
Joined: 09 Aug 2001
Posts: 332
|
hmmm, that will be difficult for bigger structures. Also, this structure is filled with a mapping node and I'm sure I'm not going to test every field for empty etc. Any other plans?
Thank you
_________________
If you do not know the answer or you get the urge to answer with "RTFM" or "Search better in this forum", please refrain from doing so, just move on to the next question. Much appreciated.
Francois van der Merwe |
|
| Back to top |
|
|
| mdmader |
| Posted: Wed Oct 29, 2008 12:17 pm Post subject: |
|
|
Newbie
Joined: 17 Apr 2008
Posts: 7
|
| francoisvdm wrote: |
hmmm, that will be difficult for bigger structures. Also, this structure is filled with a mapping node and I'm sure I'm not going to test every field for empty etc. Any other plans?
Thank you |
First, we don't use a lot of mapping nodes, we primarily use Compute nodes. I ran into the same issue and found that solution in the MB ESQL document. ftp://ftp.software.ibm.com/software/integration/wbibrokers/docs/V6.1/messagebroker_ESQL.pdf
Probably not the most effective way but, if I were to take stab at fixing the elements after a Mapping node, I'd probably try a Compute node with something like this (not tested):
CREATE COMPUTE MODULE myModuleName
CREATE FUNCTION Main() RETURNS BOOLEAN
BEGIN
DECLARE myRef REFERENCE TO OutputRoot.XMLNSC.myXMLRoot;
-- fix nulls
CALL fixNullElements(myRef);
RETURN TRUE;
END;
CREATE PROCEDURE fixNullElements(IN startPtr REFERENCE)
BEGIN
DECLARE fieldPtr REFERENCE TO startPtr;
MOVE fieldPtr FIRSTCHILD;
IF LASTMOVE(fieldPtr) THEN
IF FIELDTYPE(fieldPtr) = 0x03000000 THEN
IF fieldPtr IS NULL THEN
SET fieldPtr.(XML.Content) = NULL;
END IF;
END IF;
END IF;
WHILE LASTMOVE(fieldPtr) DO
call fixNullElements(fieldPtr);
IF FIELDTYPE(fieldPtr) = 0x03000000 THEN
IF fieldPtr IS NULL THEN
SET fieldPtr.(XML.Content) = NULL;
END IF;
END IF;
MOVE filedPtr NEXTSIBLING;
END WHILE;
END
END MODULE;
If you do come upon solution, we all would like to know how you did it. Best of luck. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
