| Author |
Message
|
| Rexx |
 Posted: Fri Feb 24, 2006 4:52 am Post subject: XML validation with schema |
 |
|
Newbie
Joined: 24 Feb 2006
Posts: 4
Location: Gothenburg
|
Hi!
Anyone having a good solution of how to read an XML from an MQ input node and validate it by using an XML schema (through a MRM), maybe modify the XML, and then send it to an output node without having the XML modified? (sounds like the most common task ever...). This is for WBIMB 5.x. I know that this is a know problem but do anyone have a good solution for it?
I get many unpleasant side effects, like the XML header is getting modified, the root element disappears and attributes become elements all in different combination depending how I handle the XML in the message flow.
I know there is a support pack IA9A that solves this but this is not an option in the nearest future. I have been informed that it is possible to BLOB from inputnode, store in Environment, activate a parse and validate through ESQL and then pass the BLOB to a reset content descriptor that sets domain XML. The question is
How do I force parse and validate through ESQL?
Thx in advance |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Fri Feb 24, 2006 5:13 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| Rexx wrote: |
| maybe modify the XML, and then send it to an output node without having the XML modified? |
huh?
The basic way to validate messages is to create a model of the message, and then set the validation properties on a node that supports it.
So the simplest flow that would validate a message would consist of an MQInput node with the validation properties set directly connected to an MQOutput node.
In order to validate data against an XML Schema, you need to import the XML Schema into your message model. Now, there are some restrictions on what aspects of XML Schemas can be supported in the MRM.
So one could write a plugin node that would parse or reparse the XML data and use something that fully supported all the features of XML Schemas. But it would be just as easy to do this in a standalone program without going through Broker at all.
You may also be able to use the XMLTransformation node, with an appropriate XSLT that will validate your data against the schema.
As for
| Quote: |
| How do I force parse and validate through ESQL? |
http://publib.boulder.ibm.com/infocenter/wbihelp/v6rxmx/index.jsp?topic=/com.ibm.etools.mft.doc/ak04950_.htm
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Rexx |
| Posted: Fri Feb 24, 2006 7:00 am Post subject: XML validation with schema |
|
|
Newbie
Joined: 24 Feb 2006
Posts: 4
Location: Gothenburg
|
| Quote: |
So the simplest flow that would validate a message would consist of an MQInput node with the validation properties set directly connected to an MQOutput node.
In order to validate data against an XML Schema, you need to import the XML Schema into your message model. |
This is actually the way I am doing it. The validation works fine but the data is beeing modified.
| Quote: |
| Now, there are some restrictions on what aspects of XML Schemas can be supported in the MRM. |
This is probebly the problem. I originally have a DTD that is transformed to an xsd (with XMLSpy) and used as an import when creating a messageset using new "Message Definition File" and later refered to in the MQInputNode. So, I guess there is a list of these "restrictions"...? Feels odd to modify a fully valid generated XSD just to meet the limitiation of the MRM parser...
| Quote: |
| You may also be able to use the XMLTransformation node, with an appropriate XSLT that will validate your data against the schema. |
Hmmm...
Thx for this one. I'll try and go for that! |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Feb 24, 2006 7:13 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Can you clarify how the data is being modified?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Rexx |
| Posted: Fri Feb 24, 2006 7:30 am Post subject: XML validation with schema |
|
|
Newbie
Joined: 24 Feb 2006
Posts: 4
Location: Gothenburg
|
Sure! Here is a sample:
Original XML:
<?xml version="1.0" encoding="UTF-8"?>
<?Siebel-Property-Set EscapeNames="false"?>
<myroot>
...
After parsing/validation:
<?xml version="1.0"?>
<!DOCTYPE MRM PUBLIC "G65T63S002001" "www.mrmnames.net/G65T63S002001">
<MRM xmlns="www.mrmnames.net/G65T63S002001">
<myroot>
...
As you can see:
- encoding removed,
- IDOCTYPE added (can probebly be supressed in messageset definition),
- extra MRM root added. Could also probebly be filtered in a compute node...
- Siebel-Property removed
- Also, later in XML, attributes converted to elements. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Feb 24, 2006 8:00 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Most of this can be controlled in the message set.
I'm not sure about the <?Siebel-Property-Set>, but it should be retained if you ensure that the message has an Open composition.
What's going on is that the MQInput node is parsing the entire message from the bitstream into a logical message tree based on the model, and then validating each element.
Then the MQOutput node is reconstructing the bitstream from the logical tree - again using the model.
So this is working as designed and pretty much doing what you tell it to. It's just that your model is less precise than you maybe thought it was.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| kimbert |
| Posted: Mon Feb 27, 2006 1:54 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| IDOCTYPE added (can probebly be supressed in messageset definition) |
Yes, it can be suppressed.
| Quote: |
| extra MRM root added. Could also probebly be filtered in a compute node |
No - it's easier than that. Just set the messageset property 'Root Tag Name' to the empty string.
| Quote: |
| Also, later in XML, attributes converted to elements. |
Very strange. Your message set must be wrong somewhere. See later comments...
| Quote: |
- Siebel-Property removed
- encoding removed |
I'm afraid this is a restriction of the MRM XML parser.
A couple of clarifications:
- You may get more accurate message model if you use the built-in DTD importer, instead of using XMLSpy to do the DTD->XSD conversion. Was there a reason why you did not take this route in the first place?
- Your best bet is to save the input bitstream in the environment, as you suggest - that should solve all the data modification problems at a stroke. However, you should still address the element->attribute problem. This is definitely pointing to a problem in your model, and if you don't get the model right, your validation will go wrong at some point. |
|
| Back to top |
|
|
| Rexx |
| Posted: Tue Feb 28, 2006 5:31 am Post subject: |
|
|
Newbie
Joined: 24 Feb 2006
Posts: 4
Location: Gothenburg
|
| Quote: |
- You may get more accurate message model if you use the built-in DTD importer, instead of using XMLSpy to do the DTD->XSD conversion. Was there a reason why you did not take this route in the first place?
|
Good question! Not very used to generate MRM from xsd or dtdt. Did not really notice the feature.
| Quote: |
| - Your best bet is to save the input bitstream in the environment, as you suggest - that should solve all the data modification problems at a stroke. However, you should still address the element->attribute problem. This is definitely pointing to a problem in your model, and if you don't get the model right, your validation will go wrong at some point. |
All the problems described above did not occure at the same time and this attribute problem came up under some circumstances i do not remember...!
I did go for the 'save input bitstream'. However, I do not really save the message in flow. I get the data from MQInputNode as a BLOB and then I use a floworder node and in the 'first' terminal i do the validate ESQL code and in the ''Second' i do a 'Reset content descriptor' to 'XML' (the tree guaranteed untouched) and proceed with normal mapping. If the 'First' terminal fails, I handle this as any other exception. Happy!  |
|
| Back to top |
|
|
|
|
