| Author |
Message
|
| lehare |
 Posted: Mon Apr 03, 2006 2:43 am Post subject: xml attribute in compute node |
 |
|
Apprentice
Joined: 25 Jul 2005
Posts: 48
|
Hi guys,
i'm failing to recreate a message to include xml attributes ...
i have the below message coming into the compute node
<?xml version="1.0" encoding="UTF-8"?>
<Q1:sassaCust xmlns:Q1="http://www.ibm.com/websphere/crossworlds/2002/BOSchema/sassaCust" version="3.0.0" verb="Create" locale="en_US" delta="false">
<Q1:CustId>100007</Q1:CustId>
<Q1:CustName>Motheo</Q1:CustName>
<Q1:custAge>04</Q1:custAge> <Q1:ObjectEventId>sassaJdbcConnector_100001xworlds_events20060324131304.743</Q1:ObjectEventId>
</Q1:sassaCust>
i'm able to reference the above Local Attributes same way i reference 'normal' Elements. - but now i'm not able to put back the recieved Local Attributes to their rightfull place - the broker Outputs them along with Elements ..
eg.
<?xml version="1.0"?>
<NS1:sassaCust_Out xmlns:NS1="http://www.ibm.com/websphere/crossworlds/2002/BOSchema/sassaCust" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<NS1:CustId>188888</NS1:CustId>
<NS1:CustName>Ayanda Mkhize </NS1:CustName>
<NS1:CustAge>20</NS1:CustAge>
<NS1:ObjectEventId>JUKLUV</NS1:ObjectEventId>
<verb>Create</verb>
<version>3.0.0</version> <--- i don't want them to be here - but to be at the top along with the namespace definition!
</NS1:sassaCust_Out>
thank you.
lehare. |
|
| Back to top |
|
 |
| dipankar |
| Posted: Mon Apr 03, 2006 2:59 am Post subject: |
|
|
Disciple
Joined: 03 Feb 2005
Posts: 171
|
Post your ESQL please.
_________________
Regards |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Apr 03, 2006 3:13 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
You need something along the lines of:
SET OutputRoot.XML."NS1:sassaCust_Out".(XML.Attribute).version = '3.0.0'
My emphasis, code snippet is offered for illustration only and without favour or prejudice. Note that it assumes your XML is not in a message set, which may well not be your situation.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| lehare |
| Posted: Mon Apr 03, 2006 4:53 am Post subject: |
|
|
Apprentice
Joined: 25 Jul 2005
Posts: 48
|
BROKER SCHEMA com.ibm.jtext.util
DECLARE ns12 NAMESPACE 'http://www.ibm.com/websphere/crossworlds/2002/BOSchema/sassaCust';
CREATE COMPUTE MODULE JTextInput_Compute
CREATE FUNCTION Main() RETURNS BOOLEAN
BEGIN
CALL CopyMessageHeaders();
DECLARE tempData BLOB;
-- CALL CopyEntireMessage();
-- convert hex to binary
set OutputRoot.MQRFH2 = null;
--set tempData = cast(InputRoot.MRM.ns1:BLOB as blob);
set OutputRoot.BLOB.BLOB = cast(InputRoot.MRM.ns1:BLOB as blob);
--set environment variables
set Environment.JText.version = InputRoot.MRM.version;
set Environment.JText.verb = InputRoot.MRM.verb;
set Environment.Jtext.locale = InputRoot.MRM.locale;
set Environment.Jtext.delta = InputRoot.MRM.delta;
set Environment.Jtext.ObjectEventId = InputRoot.MRM.ns12:ObjectEventId;
RETURN TRUE;
END;
CREATE PROCEDURE CopyMessageHeaders() BEGIN
DECLARE I INTEGER;
DECLARE J INTEGER;
SET I = 1;
SET J = CARDINALITY(InputRoot.*[]);
WHILE I < J DO
SET OutputRoot.*[I] = InputRoot.*[I];
SET I = I + 1;
END WHILE;
END;
CREATE PROCEDURE CopyEntireMessage() BEGIN
SET OutputRoot = InputRoot;
END;
END MODULE;
CREATE COMPUTE MODULE JTextInput_EnrichMessage
CREATE FUNCTION Main() RETURNS BOOLEAN
BEGIN
CALL CopyMessageHeaders();
--CALL CopyEntireMessage();
SET OutputRoot.Properties.MessageSet = 'fridayTest';
SET OutputRoot.Properties.MessageType = 'sassaCust_Out';
SET OutputRoot.Properties.MessageFormat = 'XML1';
SET OutputRoot.MRM.ns12:CustId = InputRoot.MRM.ns12:CustId;
SET OutputRoot.MRM.ns12:CustName = InputRoot.MRM.ns12:CustName;
SET OutputRoot.MRM.ns12:CustAge = InputRoot.MRM.ns12:CustAge;
SET OutputRoot.MRM.ns12:ObjectEventId = 'JUKLUV'; --InputRoot.MRM.ObjectEventId;
SET OutputRoot.MRM.verb = Environment.JText.verb;
SET OutputRoot.MRM.version = Environment.JText.version;
SET OutputRoot.MRM.locale = Environment.JText.locale;
SET OutputRoot.MRM.delta = Environment.JText.delta;
RETURN TRUE;
END;
CREATE PROCEDURE CopyMessageHeaders() BEGIN
DECLARE I INTEGER;
DECLARE J INTEGER;
SET I = 1;
SET J = CARDINALITY(InputRoot.*[]);
WHILE I < J DO
SET OutputRoot.*[I] = InputRoot.*[I];
SET I = I + 1;
END WHILE;
END;
CREATE PROCEDURE CopyEntireMessage() BEGIN
SET OutputRoot = InputRoot;
END;
END MODULE; |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Apr 03, 2006 5:05 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Did you have a question associated with that code, or is it still the same one? Sorry if I'm confused.
Normally, if you copy stuff from InputRoot to Environment, you end up losing the parser information that goes with that stuff. Like
| Code: |
| Set Environment.Variables.XML = InputRoot.XML |
would remove all of the XML nature of the data.
But you're copying back to an MRM message, and presumably the model properly indicates that verb and locale and etc. are actually XML Attributes on the data element in question.
but I'd think you still need to say
| Code: |
| SET OutputRoot.MRM."NS1:sassCust_Out".delta = Environment.JText.delta; |
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| alexey |
| Posted: Mon Apr 03, 2006 5:22 am Post subject: |
|
|
Acolyte
Joined: 18 Dec 2003
Posts: 62
Location: Israel
|
AFAIK, you just can't fill attributes AFTER elements. Put the attributes before.
Alexey. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Apr 03, 2006 5:31 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I'm not aware of any restrictions on whether attributes are added before or after elements - and even then it wouldn't matter for MRM, as MRM doesn't determine that a logical message element is an XML Element or XML Attribute until the tree is turned into a bitstream.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| alexey |
| Posted: Mon Apr 03, 2006 5:42 am Post subject: |
|
|
Acolyte
Joined: 18 Dec 2003
Posts: 62
Location: Israel
|
I did not find any documented restrictions too, but that is what I've experienced, at least in version 5. May be I'm wrong about the cause of the problem, and the order of the tree creation is the real reason for this behaiviour:
I mean what happens is that MRM parser does not have any record of field called "verb" after a field called "ObjectEventId" in the tree, so it can not determine the _attribute_ nature of the field and creates it as element for default.
Alexey. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Apr 03, 2006 5:49 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Field creation order has always been important in how a message tree is parsed.
So yes, that would explain your situation, and possibly the original poster's problem.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| lehare |
| Posted: Mon Apr 03, 2006 6:06 am Post subject: |
|
|
Apprentice
Joined: 25 Jul 2005
Posts: 48
|
I get the following output:
<?xml version="1.0"?>
<NS1:sassaCust_Out xmlns:NS1="http://www.ibm.com/websphere/crossworlds/2002/BOSchema/sassaCust" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<NS1:CustId>188888</NS1:CustId>
<NS1:CustName>Ayanda Mkhize </NS1:CustName>
<NS1:CustAge>20</NS1:CustAge>
<NS1:ObjectEventId>JUKLUV</NS1:ObjectEventId>
<NS1:sassCust_Out>
<verb>Create</verb>
<version>3.0.0</version>
</NS1:sassCust_Out>
</NS1:sassaCust_Out>
after entering
| Code: |
SET OutputRoot.MRM."NS1:sassCust_Out".verb = Environment.JText.verb;
SET OutputRoot.MRM."NS1:sassCust_Out".version = Environment.JText.version;
SET OutputRoot.MRM."NS1:sassCust_Out".locale = Environment.JText.locale;
SET OutputRoot.MRM."NS1:sassCust_Out".delta = Environment.JText.delta; |
|
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Apr 03, 2006 6:11 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
And you're certain these are defined as attributes in the message set?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| lehare |
| Posted: Mon Apr 03, 2006 6:47 am Post subject: |
|
|
Apprentice
Joined: 25 Jul 2005
Posts: 48
|
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Apr 03, 2006 6:58 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Just checking.... 
That's a good place - the last line of the MRM section on accessing attributes shows an example.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| lehare |
| Posted: Mon Apr 03, 2006 7:08 am Post subject: |
|
|
Apprentice
Joined: 25 Jul 2005
Posts: 48
|
for Example ... if one has the InputRoot message
| Code: |
| <Title Category="Computer" Form="Paperback" Edition="2">The XML Companion</Title> |
what will be the resulting Esql statement to change Local Attribut "Edition" to have value "7"?
and have the Output of
| Code: |
| <Title Category="Computer" Form="Paperback" Edition="7">The XML Companion</Title> |
|
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Apr 03, 2006 7:28 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
There's no difference between accessing XML Attributes on the Input Root and accessing them on the Output Root.
For the MRM, again, you do not need to worry in your code about whether an element is modeled as an Attribute or an Element, or even if it's being output as XML at all.
You said that the model did specify that these fields are Attributes, so the only issue that remains is to ensure that you are setting the right thing at the right time.
http://publib.boulder.ibm.com/infocenter/wmbhelp/v6r0m0/index.jsp?topic=/com.ibm.etools.mft.doc/ac17380_.htm
The manual does specify that you need to set all attributes on an element BEFORE you set any child fields. That includes the value of the main element itself. (So, alexey - there's your documentation).
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
