| Author |
Message
|
| CuriousNJ |
 Posted: Tue Jul 05, 2011 1:05 pm Post subject: generating xml stucture from message set(XML1) |
 |
|
Newbie
Joined: 05 Jul 2011
Posts: 8
|
Hi,
i have worked earlier on transforming FLM to XML message but each xml tag was created in the code.
is it possible to create the xml structure ,the xml tag itself(without writing the code for each tag) from the message set(XML1).
and also the mapping with the FLM. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Wed Jul 06, 2011 4:12 am Post subject: Re: generating xml stucture from message set(XML1) |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| CuriousNJ wrote: |
| is it possible to create the xml structure ,the xml tag itself(without writing the code for each tag) from the message set(XML1). |
Yes.
| CuriousNJ wrote: |
| and also the mapping with the FLM. |
No. Unless the mapping is direct and by name, 1-for-1, broker can't know which field maps to which tag unless you direct it by some means. Doesn't have to be code if the mapping is simplistic.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| kimbert |
| Posted: Wed Jul 06, 2011 4:18 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| i have worked earlier on transforming FLM to XML message |
What is 'FLM'. Does it stand for 'Fixed Length Message' perhaps?
| Quote: |
s it possible to create the xml structure ,the xml tag itself(without writing the code for each tag) from the message set(XML1).
and also the mapping with the FLM. |
Yes, but you will have to accept that the output XML will have *exactly* the same logical structure as your input. You do it like this:
1. Model your fixed-length message using the MRM parser with a TDS or CWF physical format. I assume that you have already done this, but you have not said so.
2. In your message flow, put a Compute node immediately after the input node. Only one line of ESQL is required:
| Code: |
| SET OutputRoot.XMLNSC.rootTagName = InputRoot.MRM; |
...where rootTagName is the name of your input message ( which you could get from InputRoot.Properties.MessageType if you wanted to )
Note that I did not use the MRM physical format for output. I used XMLNSC. XMLNSC does not use MRM physical formats, so you can delete the XML1 physical format from your message set. |
|
| Back to top |
|
|
| CuriousNJ |
| Posted: Fri Sep 02, 2011 12:09 pm Post subject: |
|
|
Newbie
Joined: 05 Jul 2011
Posts: 8
|
Hey Thanks Jedi..It helped..Actlly i had to do it in java..so did the same in java...
i have one more querry, can you please help me on this...
1) I created the fixed length msg in to an xml stucture in java by creating first MRM structure and then simply copying it to the output xmlnsc.
2) Requirement is that output xml should have namespaces and prefix.
3) So for that i created msg set Or msg definition file using mqsicreatedefs..and gave one target shema namespace.
4) But that name space came for only the root tag(the element at 01 level in copybook).so the xml generated has the namespace declaration only after root tag..no prefix were there in rest of the xml tags.
5) Then in messageset for each child there were two option "No_Target_NameSpace" and other the namespace that i added to root tag.
6) So after creating msgset manually i had to set the namespace for each child.then i recieved the required xml.
7) Now my querry is if there is any way of creating msgset from cobol using mqsicretedefs so that each child will have that namespace declaration to reduce that manual work. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Sat Sep 03, 2011 4:28 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
DO NOT USE THE MRM-XML format to handle XML documents.
DO NOT.
It is bad. It is obsolete. It is deprecated. It will cause you problems.
Create an XML document that looks like what you want to produce, and use Toolkit to create an XSD from that and then create a new Message Definition in the XMLNSC domain to model that.
This is the *best* way to handle your situation. |
|
| Back to top |
|
|
| kimbert |
| Posted: Mon Sep 05, 2011 12:35 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
Not sure whether there is a setting on the importer, but I think there's an XML Schema property that will do what you need - well, two properties actually.
Their names are 'elementFormDefault ' and 'attributeFormDefault'. They are attributes of the xs:schema element, and they control whether or not the local declarations are namespace-qualified.
If the COBOL importer does not allow you to set these attributes, it should be easy enough to add them into the imported mxsd files ( remember that an mxsd is just an xsd with some annotations ).
Let me know if you need more info on this.
mqjeff : You're right, but I think CuriousNJ is using XMLNSC already. |
|
| Back to top |
|
|
| CuriousNJ |
| Posted: Mon Sep 05, 2011 2:49 am Post subject: |
|
|
Newbie
Joined: 05 Jul 2011
Posts: 8
|
yeah..that is there.i had tried with it also. i simply edited the mxsd file and added this property attributeFormDefault="unqualified" elementFormDefault="qualified"
it worked..but is this the only way..doing it manually...actually i am working on automating this creation of message set n ol..
also mqjeff, i did not get what did it mean when you said USING THE MRM-XML format to handle XML documents. and why is it bad?
Please explain, I am new to all this. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Mon Sep 05, 2011 4:46 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
The mrm-xml parser currently in use is based upon the original XML parser that goes back years. Certainly when I started coding everything was done using MRM.
As has been stated, it is deprecated. It could very well be removed in the next Major version of Broker. It is not really being maintained.
ergo,
don't use it.
There is nothing to stop you from using it. It is there in the set of tools you can call up. But one of these days, IBM will remove stuff that has been marked a deprecated.
If you then wail 'but my business depends on this thing which has been removed' your complaint may very well fall upon deaf ears.
I'm sure the semi official word from IBM will be along soon.
_________________
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 |
|
|
| kimbert |
| Posted: Mon Sep 05, 2011 8:06 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
The word 'deprecated' sometimes generates panic, so I feel the need to set the record straight:
The old XML domain is deprecated, but will probably never be removed from the product. Don't ever use it in a new message flow.
XMLNS is not deprecated, but XMLNSC is almost always a better choice
MRM-XML has issues, but it is not deprecated, and will probably never be removed from the product. The main reason for using it was to validate the XML document against the xsds in the message set. XMLNSC does a much better ( and faster ) job of that. Please don't use MRM-XML in a new message flow - it's just not strategic.
XMLNSC is the recommended XML parser for reading and writing of XML. Please use it unless you have a very good reason not to. |
|
| Back to top |
|
|
|
|
