| Author |
Message
|
| rabee_nawash |
 Posted: Fri Feb 05, 2016 11:20 pm Post subject: Parse Xml in CDATA |
 |
|
Apprentice
Joined: 01 Dec 2014
Posts: 27
|
| I have an xml text passed through SOAP message using CDATA , I want to validate it against xsd file and if succeeded fill the data in the XSD object, is there any way to do that in IBM integration bus, and is their a visual way of doing it? |
|
| Back to top |
|
 |
| smdavies99 |
| Posted: Fri Feb 05, 2016 11:43 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
There are a number of Threads in the Message Broker Forum here that discuss CDATA and parsing there of. The comments by Timber/Kimbert are expecially relevant to your question.
Please take some time to look at these threads. The Google search box on the upper right on this page will help you.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| rabee_nawash |
| Posted: Sat Feb 06, 2016 9:09 am Post subject: |
|
|
Apprentice
Joined: 01 Dec 2014
Posts: 27
|
| smdavies99 wrote: |
There are a number of Threads in the Message Broker Forum here that discuss CDATA and parsing there of. The comments by Timber/Kimbert are expecially relevant to your question.
Please take some time to look at these threads. The Google search box on the upper right on this page will help you. |
Thank you Timber, but none of them helped me. My issue not with parsing alone its parsing with validation. I was able to parse the xml message but regardless of if its valid against its schema. Meaning I changed submit a message with tags which its not exists in the XSD file but again it pass the parsing and it parse the validate node. My issue is that I need to check if the data passed in the CDATA is correct before rout it to another web service. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Sat Feb 06, 2016 10:33 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
how are you doing the parsing?
How are you validating it?
The product can certainly validate a message tree against an XSD schema and if it fails, it will throw an error.
This is SOP for many of us. So, what are you doing exactly? Examples/sample code will help us here.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| rabee_nawash |
| Posted: Sat Feb 06, 2016 10:55 am Post subject: |
|
|
Apprentice
Joined: 01 Dec 2014
Posts: 27
|
Request SOAP Message : Note the XML is inside transactionData CDATA
| Code: |
<?xml version="1.0" encoding="UTF-8"?><tns0:Envelope xmlns:tns0="http://schemas.xmlsoap.org/soap/envelope/" xmlns:tns1="http://www.xyzhealth.com/b2b/health/po/schema/v1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<tns0:Header/>
<tns0:Body>
<tns1:ProcessTransaction>
<transactionId>transactionId</transactionId>
<transactionType>transactionType</transactionType>
<transactionData>
<data<![CDATA[<?xml version="1.0" encoding="utf-8"?>
<Prior.Request
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="https://www.health.com/DataDictionary/CommonTypes/PriorRequest.xsd">
<Header>
<SenderID>MF23</SenderID>
<ReceiverID>A001</ReceiverID>
<TransactionDate>11/05/2014 10:57</TransactionDate>
<RecordCount>1</RecordCount>
<DispositionFlag>PTE_VALIDATE_ONLY</DispositionFlag>
</Header>
<Authorization>
<Type>Authorization</Type>
<ID>SIL_Aug6_2014</ID>
<IDPayer>10992273</IDPayer>
<MemberID>695076</MemberID>
<PayerID>A001</PayerID>
<EmiratesIDNumber>784-1984-3761860-0</EmiratesIDNumber>
<DateOrdered>11/05/2014</DateOrdered>
<Encounter>
<FacilityID>MF23</FacilityID>
<Type>1</Type>
</Encounter>
<Diagnosis>
<Type>Principal</Type>
<Code>540.0</Code>
</Diagnosis>
</Authorization>
</Prior.Request>]]></data>
</transactionData>
<transactionAttachments/>
<callExtensions>
<extension/>
</callExtensions>
</tns1:ProcessTransaction>
</tns0:Body>
</tns0:Envelope>
|
| smdavies99 wrote: |
how are you doing the parsing?
How are you validating it?
I parse the XML like this
| Code: |
SET OutputLocalEnvironment.Variables.data = FIELDVALUE(InputRoot.XMLNSC.ns:ProcessTransaction.transactionData.(XMLNSC.CDataField));
SET OutputRoot = InputRoot;
CREATE LASTCHILD OF OutputLocalEnvironment.Variables.XMLMessage DOMAIN ('XMLNSC') PARSE (OutputLocalEnvironment.Variables.data CCSID 1208); |
The product can certainly validate a message tree against an XSD schema and if it fails, it will throw an error.
I use the validate node to validate, but I don't know how to assign the XSD schema to it? there is no option for that, please note the XSD is available to the application thruough its library
This is SOP for many of us. So, what are you doing exactly? Examples/sample code will help us here. |
|
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Feb 06, 2016 7:55 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
I doubt very much that the validate node was built to validate what is in the Environment or local environment tree.
You have essentially 2 possibilities.
- Change the code to make validation happen on your CREATE PARSE command and deal with the error handling...
- use a FLOW ORDER node to split the flow. On the first branch move the parsed XML to OutputRoot.XMLNSC and put it to the VALIDATE node. On the error terminal of the VALIDATE node attach a THROW node.
This will prevent the second branch to be executed if the CData does not validate...
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| rabee_nawash |
| Posted: Sun Feb 07, 2016 4:06 am Post subject: |
|
|
Apprentice
Joined: 01 Dec 2014
Posts: 27
|
Thank you fjb_saper,
I used the second approach (Flow Order), but still I the xml pass the validation however it shouldn't .. My question how IIB will know to which XSD schema the validation should run..
Currently this is my situation
The message tree after using the Flow Order and moved the new parsed xml into the XMLNSC
| Code: |
Message
XMLNSC
Prior.Request
xsi:CHARACTER:http://www.w3.org/2001/XMLSchema-instancenoNamespaceSchemaLocation:CHARACTER:https://www.health.com/DataDictionary/CommonTypes/PriorRequest.xsd
Header
SenderID:CHARACTER:MF23
ReceiverID:CHARACTER:A001
TransactionDate:CHARACTER:11/05/2014 10:57
RecordCount:CHARACTER:1
DispositionFlag:CHARACTER:PTE_VALIDATE_ONLY
:CHARACTER:Authorization1
ID1:CHARACTER:SIL_Aug6_2014
IDPayer:CHARACTER:10992273
MemberID2:CHARACTER:695076
PayerID:CHARACTER:A001
EmiratesIDNumber:CHARACTER:784-1984-3761860-0
DateOrdered:CHARACTER:11/05/2014
Encounter
FacilityID:CHARACTER:MF23
Type:CHARACTER:1Authorization
Type
Diagnosis
Type:CHARACTER:Principal
Code:CHARACTER:540.0
Activity
ID:CHARACTER:1
Start:CHARACTER:10/04/2012 11:00
Type:CHARACTER:5
Code:CHARACTER:1288-1472-001
Quantity:CHARACTER:1.0
Net:CHARACTER:500.0
Clinician:CHARACTER:GN6489
Observation
Type:CHARACTER:Text
Code:CHARACTER:Dose
Value:CHARACTER:25
ValueType:CHARACTER:Mg
|
and the XSD schema in a file called PriorRequest.xsd
| Code: |
<?xml version="1.0" encoding="UTF-8"?><!-- Created with Liquid XML Studio 1.0.8.0 (http://www.liquid-technologies.com) --><xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" id="PriorRequest" version="2.0" xmlns:tns="http://www.health.com/DataDictionary/CommonTypes" xmlns:xsd="undefined">
<xs:import namespace="http://www.health.com/DataDictionary/CommonTypes" schemaLocation="CommonTypes.xsd"/>
<xs:element name="Prior.Request">
<xs:complexType>
<xs:sequence>
<xs:element name="Header">
<xs:complexType>
<xs:sequence>
<xs:element name="SenderID" type="tns:HeaderSenderID"/>
<xs:element name="ReceiverID" type="tns:HeaderReceiverID"/>
<xs:element name="TransactionDate" type="tns:HeaderTransactionDate"/>
<xs:element name="RecordCount" type="tns:HeaderRecordCount"/>
<xs:element name="DispositionFlag" type="tns:HeaderDispositionFlag"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="Authorization">
<xs:complexType>
<xs:sequence>
<xs:element name="Type" type="tns:AuthorizationType"/>
<xs:element name="ID" type="tns:AuthorizationID"/>
<xs:element minOccurs="0" name="IDPayer" type="tns:AuthorizationIDPayer"/>
<xs:element name="MemberID" type="tns:AuthorizationMemberID"/>
<xs:element name="PayerID" type="tns:AuthorizationPayerID"/>
<xs:element minOccurs="0" name="EmiratesIDNumber" type="tns:AuthorizationEmiratesIDNumber"/>
<xs:element minOccurs="0" name="DateOrdered" type="tns:AuthorizationDateOrdered"/>
<xs:element minOccurs="0" name="Encounter">
<xs:complexType>
<xs:sequence>
<xs:element name="FacilityID" type="tns:EncounterFacilityID"/>
<xs:element minOccurs="0" name="Type" type="tns:EncounterType"/>
<xs:element minOccurs="0" name="Start" type="tns:EncounterStart"/>
<xs:element minOccurs="0" name="End" type="tns:EncounterEnd"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element maxOccurs="unbounded" minOccurs="0" name="Diagnosis">
<xs:complexType>
<xs:sequence>
<xs:element name="Type" type="tns:DiagnosisType"/>
<xs:element name="Code" type="tns:DiagnosisCode"/>
<xs:element maxOccurs="unbounded" minOccurs="0" name="DxInfo">
<xs:complexType>
<xs:sequence>
<xs:element name="Type" type="tns:DxInfoType"/>
<xs:element name="Code" type="tns:DxInfoCode"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element maxOccurs="unbounded" minOccurs="0" name="Activity">
<xs:complexType>
<xs:sequence>
<xs:element name="ID" type="tns:ActivityID"/>
<xs:element minOccurs="0" name="Start" type="tns:ActivityStart"/>
<xs:element name="Type" type="tns:ActivityType"/>
<xs:element name="Code" type="tns:ActivityCode"/>
<xs:element minOccurs="0" name="Quantity" type="tns:ActivityQuantity"/>
<xs:element name="Net" type="tns:ActivityNet"/>
<xs:element minOccurs="0" name="OrderingClinician" type="tns:ActivityOrderingClinician"/>
<xs:element minOccurs="0" name="Clinician" type="tns:ActivityClinician"/>
<xs:element maxOccurs="unbounded" minOccurs="0" name="Observation">
<xs:complexType>
<xs:sequence>
<xs:element name="Type" type="tns:ObservationType"/>
<xs:element name="Code" type="tns:ObservationCode"/>
<xs:element minOccurs="0" name="Value" type="tns:ObservationValue"/>
<xs:element minOccurs="0" name="ValueType" type="tns:ObservationValueType"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element minOccurs="0" name="Resubmission">
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="0" name="Type" type="tns:ResubmissionType"/>
<xs:element name="Comment" type="tns:ResubmissionComment"/>
<xs:element minOccurs="0" name="Attachment" type="tns:ResubmissionAttachments"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema> |
See here authorization1 is not valid authorization type as per the schema , how the mapping will happen or there is something wrong with the name spaces |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sun Feb 07, 2016 8:33 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
You did deploy the xsd as a message model right?
Look at your schema, and then look at your message: where are the namespaces shown in the schema? Looks like the message is missing them....
You also might want to show what your xsd looks like after import into the toolkit and validation...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| timber |
| Posted: Sun Feb 07, 2016 1:38 pm Post subject: |
|
|
Grand Master
Joined: 25 Aug 2015
Posts: 1280
|
|
| Back to top |
|
|
| rabee_nawash |
| Posted: Sun Feb 07, 2016 3:44 pm Post subject: |
|
|
Apprentice
Joined: 01 Dec 2014
Posts: 27
|
On the first branch move the parsed XML to OutputRoot.XMLNSC and put it to the VALIDATE node. On the error terminal of the VALIDATE node attach a THROW node.
This will prevent the second branch to be executed if the CData does not validate...[/list]
The issue I think that the parse removed the xmlnd and nsi attributes that's why when it reach the parse node the node can't locate the xsd file. Any idea how I can return back the xmlns and nsi to the nonamespaceschemalocation
Have fun [/quote] |
|
| Back to top |
|
|
| timber |
| Posted: Mon Feb 08, 2016 1:50 am Post subject: |
|
|
Grand Master
Joined: 25 Aug 2015
Posts: 1280
|
| Quote: |
| The issue I think that the parse removed the xmlnd and nsi attributes |
I don't understand; XMLNSC does not throw away information when it parses an XML document. Please check your spelling, and explain more clearly what you mean.
| Quote: |
| ...that's why when it reach the parse node the node can't locate the xsd file. |
IIB does not need to 'locate the xsd'. It uses the model that was deployed with the application. I assume that you have deployed your xsd(s)?
Have you tried using the OPTIONS clause in the CREATE...PARSE statement yet? |
|
| Back to top |
|
|
| rabee_nawash |
| Posted: Mon Feb 08, 2016 1:09 pm Post subject: |
|
|
Apprentice
Joined: 01 Dec 2014
Posts: 27
|
| timber wrote: |
| Quote: |
| The issue I think that the parse removed the xmlnd and nsi attributes |
I don't understand; XMLNSC does not throw away information when it parses an XML document. Please check your spelling, and explain more clearly what you mean.
| Quote: |
| ...that's why when it reach the parse node the node can't locate the xsd file. |
IIB does not need to 'locate the xsd'. It uses the model that was deployed with the application. I assume that you have deployed your xsd(s)?
Have you tried using the OPTIONS clause in the CREATE...PARSE statement yet? |
This is the XML String before parsing
| Code: |
data:CHARACTER:<?xml version="1.0" encoding="utf-8"?>
<Prior.Request
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="PriorRequest.xsd"]>
<Header>
<SenderID>MF23</SenderID>
<ReceiverID>A001</ReceiverID>
<TransactionDate>11/05/2014 10:57</TransactionDate>
<RecordCount>1</RecordCount>
<DispositionFlag>PTE_VALIDATE_ONLY</DispositionFlag>
</Header>
<Authorization>
<Type>Authorization</Type>
<ID>SIL_Aug6_2014</ID>
<IDPayer>10992273</IDPayer>
<MemberID>695076</MemberID>
<PayerID>A001</PayerID>
........... |
and this is after parsing
| Code: |
XMLMessage
XMLNSC
XmlDeclaration
Version:CHARACTER:1.0
Encoding:CHARACTER:utf-8
Prior.Request
xsi:CHARACTER:http://www.w3.org/2001/XMLSchema-instance
noNamespaceSchemaLocation:CHARACTER:PriorRequest.xsd
Header
SenderID:CHARACTER:MF23
ReceiverID:CHARACTER:A001
TransactionDate:CHARACTER:11/05/2014 10:57
RecordCount:CHARACTER:1
DispositionFlag:CHARACTER:PTE_VALIDATE_ONLY
Authorization
Type:CHARACTER:Authorization
ID:CHARACTER:SIL_Aug6_2014
IDPayer:CHARACTER:10992273
MemberID:CHARACTER:695076
PayerID:CHARACTER:A001 |
Yes thanks its working with options, but I still prefer to use the validate node, any idea why the parse change the attributes prefix
| Code: |
Prior.Request
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="PriorRequest.xsd"]> |
Thanks any way my problem is resolved |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Feb 08, 2016 1:22 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
| rabee_nawash wrote: |
Yes thanks its working with options, but I still prefer to use the validate node, any idea why the parse change the attributes prefix
|
Can you please be more specific?
My guess is because in the environment tree you don't have a default parser and you have to explicitely set it for attributes to behave correctly...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Feb 08, 2016 1:23 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| rabee_nawash wrote: |
| any idea why the parse change the attributes prefix |
The prefix of any namespace is irrelevant. The only question is which namespace a given XML element is in, either through specific allocation or one of the defaulting mechanisms. The only thing the prefix (the left hand side of the colon) does is save you typing.
I don't see where the parsed version differs from the original on that basis.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Feb 08, 2016 1:52 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Vitor wrote: |
| I don't see where the parsed version differs from the original |
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
|
|
