| Author |
Message
|
| Heurton |
 Posted: Thu Sep 20, 2007 11:30 pm Post subject: Accessing field with attribut in XML message |
 |
|
Novice
Joined: 19 Nov 2003
Posts: 16
|
Hi,
I'm working with a XML message in MRM domain.
I have to test the value of an element with attribut in a compute node:
<OrderConfirmation OrderConfirmationStatusType="Accepted">
I don't know how to code the ESQL to check if it is "Accepted", "Canceled" or other value..!
Thanks for your help! |
|
| Back to top |
|
 |
| Vitor |
| Posted: Thu Sep 20, 2007 11:40 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Do you mean you don't know how to model it in the message model, or that the ESQL to access that part of the message model isn't working?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| kimbert |
| Posted: Fri Sep 21, 2007 12:01 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
|
| Back to top |
|
|
| Heurton |
| Posted: Fri Sep 21, 2007 5:08 am Post subject: |
|
|
Novice
Joined: 19 Nov 2003
Posts: 16
|
No, I have imported an xsd, the problem I have is how to code the SQL to acces to the value of the atribute in the MRM domain!
Thanks in advance |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Sep 21, 2007 5:37 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You don't need to do anything special to access an Attribute instead of an Element when working with MRM-XML.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Jenney |
| Posted: Tue Oct 02, 2007 6:45 am Post subject: |
|
|
Voyager
Joined: 25 Apr 2007
Posts: 83
Location: Melbourne
|
How to create XML attribut, for MRM-XML message.
I am setting,
OutputRoot.MRM.Field.(XML.Attribute)ID = '1';
when i get an XML it doesn't create the MRM instaed it creates the XML element.
How to create the XML attribute?
Thanks |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Oct 02, 2007 6:47 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You configure the model such that the physical representation of the field will be an Attribute instead of an Element.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Jenney |
| Posted: Tue Oct 02, 2007 6:51 am Post subject: |
|
|
Voyager
Joined: 25 Apr 2007
Posts: 83
Location: Melbourne
|
| That is true, i have created that value as attribute only, not as element. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Oct 02, 2007 7:00 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Then you don't need to mention "attribute" at all in your ESQL.
This is the nice thing about MRM-XML. You can pretend that you aren't doing XML at all, just ESQL.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Jenney |
| Posted: Tue Oct 02, 2007 9:08 am Post subject: |
|
|
Voyager
Joined: 25 Apr 2007
Posts: 83
Location: Melbourne
|
In my case its not creating the attribut, its creating the XML element
<MyFilld>
<Type>1</Type>
</MyFild>
instead of
<MyFild Type="1">
</MyFild>
My Code is
SET OutputRoot.MRM.MyFild.Type = '1'; |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Oct 02, 2007 9:11 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Turn on validation, and see what errors are created.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| TonyD |
| Posted: Tue Oct 02, 2007 11:55 am Post subject: |
|
|
Knight
Joined: 15 May 2001
Posts: 540
Location: New Zealand
|
I spent some time a while ago wrestling with attributes in the MRM domain, my problem being that they kept turning into elements when I wanted them to remain as attributes. I was attemtping to convert a hybrid XML/TDS message into XML.
I raised a PMR which resulted in a long 'conversation', with comprehensive advice from the C/T.
Here is one of their responses which you may find relevant:
| Quote: |
The customer has asked a how-to question and on that basis we have
provided a generic reply which we trust covers their requirement.
Customers question :
------------------------------------------------------------------------
How I can ensure that Attributes in the input message are shown as
Attributes in the output message while delimited data fields in the
input message are represented as Elements in the output message ?
Here is a quick summary and key points about the use of XML attributes :
------------------------------------------------------------------------
When parsing an XML document, attributes are recognised and can be
parsed into a message tree. How the associated message tree field is
created is completely dependent on the parser being used. Firstly let us
consider generic XML which is either one of the XML, XMLNS, and XMLNSC
domains. These XML parsers do not parse against a schema and therefore
rely on two main aspects to process the XML document :
1) XML metadata and mark-up in the document.
2) Underlying field types in the message tree such as XML.Tag,
XML.NamespaceDeclaration and XML.attr.
When interrogating the message tree in ESQL then the field-types are not
mandatory unless you have two pieces of mark-up that clash such as an
attribute and tag with the same name. However, if the parsed message
tree is to be used to write an output XML document, then these field
types are mandatory to indicate how that portion of the bitstream is to
be written. For example, for each of the following field types the
following sample portion of bitstream would be written :
i) XML.Tag : <fieldname>fieldvalue</fieldname>.
ii) XML.attr : fieldname="fieldvalue"
iii) XML.CDataSection : <fieldname><![CDATA[fieldvalue]]></fieldname>
As can be seen, since the generic XML parsers have no model to work
against, the fieldtypes determine how the bitstream is to be written.
This does not just apply to parsed message trees on output, but also
apply to newly created message trees. To create a new XML attribute for
output then ESQL similar to the following would be written :
SET OutputRoot.XML.TestCase.(XML.attr)myAttr = 'Field value';
This sets the field type to be an XML attribute and hence indicates to
the XML writer that the field is to be written as an XML attribute.
So do these principles apply to the MRM-XML parser? The answer is no.
The first common mistake is that users attempt to use the same XML field
types in the XML domain such as :
SET OutputRoot.MRM.(XML.attrr)myAttr = 'Field Value';
This is incorrect. The XML.* field types are specific to the generic XML
parsers and are not recognised by the MRM parser. The MRM parser will
not reject these since these just resolve to a numeric field type. It is
possible that some of the XML field types have some other meaning in an
MRM message tree, but in general they won't have meaning and hence the
default NameValue fieldtype will be used.
So what field type should be used in the MRM to write an XML attribute ?
The answer is none, the MRM-XML parser does not need one. The reason for
this is that the MRM domain makes use of message models that offer
structure information about how the messages are to be parsed/written
against the model. When an MRM-XML physical format is added to a
messageSet then this has a Render property for each of its elements.
This indicates whether the element is to be written as an XML tag or an
XML attribute. Ie, it is the message model that determines how it is to
be written NOT the field types in the message tree. Consider the
following message model :
myMessage [Sequence]
- myElement1 :STRING (XML Render = XML Tag)
- myElement2 : STRING (XML Render = XML Attribute)
To make use of this message model a user may construct the following
message tree :
SET OutputRoot.Properties.MessageSet = '...';
SET OutputRoot.Properties.MessageType = 'myMessage';
SET OutputRoot.Properties.MessageFormat = 'XML';
SET OutputRoot.MRM.myElement1 = 'A';
SET OutputRoot.MRM.myElement2 = 'B';
This would cause a message like the following to be written out :
<myMessage myElement2="B">
<myElement1>A</myElement1>
</myMessage>
As can be seen there was no need to create an element in the message
tree that indicate that the field was an attribute. In this case
myElement2 would have been matched to the dictionary and this would
indicate that it needed to be written as an attribute.
This can seem problematic when the message tree is NOT matched to the
dictionary. The MRM-XML physical format allows self-defining elements.
This means that if an element is not matched to the dictionary then it
will be written as the default which is an XML tag. So let us extend
the example above to the following :
myMessage [Sequence]
- myElement1 :STRING (XML Render = XML Tag)
- myElement2 : STRING (XML Render = XML Attribute)
- myElement3 : STRING (XML Render = XML Attribute)
And write the following ESQL in a message flow :
SET OutputRoot.Properties.MessageSet = '...';
SET OutputRoot.Properties.MessageType = 'myMessage';
SET OutputRoot.Properties.MessageFormat = 'XML';
SET OutputRoot.MRM.myElement1 = 'A';
SET OutputRoot.MRM.myElement3 = 'C';
SET OutputRoot.MRM.myElement2 = 'B';
This would cause the following message to be written out :
<myMessage myElement3="C">
<myElement1>A</myElement1>
<myElement2>B</myElement2>
</myMessage>
So why was myElement2 written as a tag when it is defined as an XML
attribute in the dictionary? The reason is that it did NOT match to the
dictionary. myMessage is defined as a sequence which means the fields in
the message tree MUST appear in the same order as the messageSet. In
this case myElement3 is in the wrong order in the message tree. In terms
of message tree and model synch up at writing, the following will
occur :
1) myElement1 will be matched to the dictionary from the tree.
2) myElement3 will be matched to the dictionary from the tree, but
myElement2 would have been stepped over.
3) myElement2 is found in the tree but the dictionary iterator is at the
end of the structure.
4) No match is made on myElement2 and so no dictionary details can be
found.
5) myElement2 is written as a self-defining XML.Tag and hence does not
appear as an attribute.
Self-defining MRM attributes can appear on input if the input message
does not match the model. So for example if the last sample XML output
message is parsed against the same sample message model then the
following message tree would be created :
MRM
- myElement1 = 'A'
- myElement3 = 'C'
- @myElement2 = 'B'
As can be seen the myElement2 has an @ in its named. This indicates it
is a self-defining attribute.
When parsing/writing using the MRM-XML parser then care must be taken in
that self-defining elements are not appearing unexpectedly in the
scenario. These can be detected at development time by either switching
on message validation on input/output. Alternatively in V6 a user trace
can be collected and this may contain warning messages about
self-defining elements/attributes. For example :
UserTrace BIP5493W: Message, element or attribute 'format' is
self-defining within parent 'http://www.qt.net:sdef'.
The message, element or attribute 'format' did not match
with any corresponding artifact in the message model hence
it is considered to be self-defining. If it is not intended
that this message, element or attribute be self-defining,
check that the message set is referenced in the message
properties, or modify the message model to correspond to
the instance message, or modify the instance message to
correspond to the message model.
If expected XML attributes appear as XML tags then it is definitely
worth checking that the output message model matches the message tree.
When writing using the generic XML parser, then the user needs to ensure
that the fields in the XML message tree have the fieldtype of XML.Attr
for any fields that are intended to be written as XML attributes. This
does not take place automatically if the output XML fields are created
from source MRM fields. Let us revisit the simple example above :
Message model :
myMessage [Sequence]
- myElement1 :STRING (XML Render = XML Tag)
- myElement2 : STRING (XML Render = XML Attribute)
Input XML message :
<myMessage myElement2="B">
<myElement1>A</myElement1>
</myMessage>
Which produces a parse tree of :
MRM
- myElement1 ='A'
- myElement2 = 'B'
Remember in the MRM it is the model that stores that myElement2 is an
XML attribute not the message tree. So if these fields are copied to
another domain, the message model is not involved and so the fact it is
an XML attribute is lost. For example :
SET OutputRoot.XML.TestCase = InputRoot.MRM;
Would result in an output XML message of :
|
For some reason the output XML message referred to at the end disappeared! |
|
| Back to top |
|
|
| Jenney |
| Posted: Wed Oct 03, 2007 5:26 am Post subject: |
|
|
Voyager
Joined: 25 Apr 2007
Posts: 83
Location: Melbourne
|
| jefflowrey wrote: |
| Turn on validation, and see what errors are created. |
No errors are created message go's to outout queue very smoothly.
[quote="TonyD”]
So if these fields are copied to
another domain, the message model is not involved and so the fact it is
an XML attribute is lost. For example :
SET OutputRoot.XML.TestCase = InputRoot.MRM; [/quote]
I am changing CWF to MRM-XML, so it means it will work for only incomming message not for outgoing message where new message should be created? |
|
| Back to top |
|
|
| Jenney |
| Posted: Wed Oct 03, 2007 5:28 am Post subject: |
|
|
Voyager
Joined: 25 Apr 2007
Posts: 83
Location: Melbourne
|
| jefflowrey wrote: |
| Turn on validation, and see what errors are created. |
No errors are created message go's to outout queue very smoothly.
| Quote: |
[quote="TonyD”]
So if these fields are copied to
another domain, the message model is not involved and so the fact it is
an XML attribute is lost. For example :
SET OutputRoot.XML.TestCase = InputRoot.MRM; |
[/quote]
I am changing CWF to MRM-XML, so it means it will work for only incomming message not for outgoing message where new message should be created? |
|
| Back to top |
|
|
|
|
