| Author |
Message
|
| IIB_newbie |
 Posted: Tue Sep 02, 2014 11:30 pm Post subject: Extracting metadata from XSDs in java compute node |
 |
|
Newbie
Joined: 02 Sep 2014
Posts: 2
|
I want to extract the user-defined metadata (annotations) associated with the input XSD in a java compute node.
1) Are annotations available in the MbMessage?
2) Is there a plugin similar to com.ibm.j2ca.base.TypeFactory as in Websphere ESB (extracts the metadata from DataObject) to extract annotations from message within IIB?
3) Is there a way to retrieve annotations using ESQL?
Thanks |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Wed Sep 03, 2014 1:41 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
I don't quite understand... unless you consider the annotations as processing instructions?
There are checkboxes on the XMLNSC parser to retain mixed values, comments and processing instructions. Does checking any of those change what you see? It may just be considered noise as those (annotations) are typically between tags and get suppressed....
You can also see if using the XMLNS parser gives you a different result...
Anyway can you tell us why you think you need that data from the xsds?
What are you trying to do?
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Sep 03, 2014 4:34 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| fjb_saper wrote: |
| There are checkboxes on the XMLNSC parser to retain mixed values, comments and processing instructions. Does checking any of those change what you see? |
It's worth a try but I'd be surprised if it helped. The IIB message tree is build from the input message stream not from the object the input is built from as it is in WESB. Remember that the message tree being passed to a Java Compute Node may not have originated from an XML message and, even if it did, it may not have been parsed against an XSD.
| fjb_saper wrote: |
Anyway can you tell us why you think you need that data from the xsds?
What are you trying to do? |
Annotations in an XSD are, in my world, human readable comments for humans not some kind of meta-processing instruction (where a processing instruction is a specific kind of tag included with the XML document itself). So why do you need them?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Sep 03, 2014 5:24 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| You can of course generate jaxb classes from the xsds/models you are using. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Sep 03, 2014 6:17 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
| You can of course generate jaxb classes from the xsds/models you are using. |
Urgh - Java..... 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| IIB_newbie |
| Posted: Thu Sep 04, 2014 1:54 am Post subject: |
|
|
Newbie
Joined: 02 Sep 2014
Posts: 2
|
Thanks for the reply.
The annotations contains data needed for the transformed output which is for a legacy application.
Currently we use WESB for integration. Legacy back end system has a special xml format. For ease of mapping we have an intermediate XSD generated from this xml (using java) which stores some of the information needed for conversion as annotations. After mapping in the mediation we have custom data handler written in java that converts the mapped output into the legacy format by reading the annotations from XSD. In WESB this is done using com.ibm.j2ca.base.TypeFactory. Now we are trying to migrate all our mediations from WESB to IIB and we are searching for options to implement this in IIB.
The below are the options considered
1. Build a user defined parser to convert the intermediate XML to legacy format
2. Use java compute node (preferred by the architects in the organisation)
3. Use xslt
4. Use ESQL
If metadata can not be obtained in any of the above mechanism, I'm thinking of parsing the XSD in one of the above mechanism. Please let me know your suggestions.
Note: Checking the box is not providing the annotations from the XSD. Only the input XML is available in the message. |
|
| Back to top |
|
|
| kimbert |
| Posted: Thu Sep 04, 2014 4:47 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
Thanks - that was useful. We are now able to advise you properly.
This sentence got my attention:
| Quote: |
| For ease of mapping we have an intermediate XSD generated from this xml (using java) which stores some of the information needed for conversion as annotations. |
That sounds like a non-standardized version of a DFDL xsd. Probably not exactly, but how close am I to the truth?
also this:
| Quote: |
| After mapping in the mediation we have custom data handler written in java that converts the mapped output into the legacy format by reading the annotations from XSD. |
Once again, sounds rather like DFDL, except that DFDL doesn't require you to write and maintain a custom data handler.
So my comments on your options are:
1. Build a user defined parser to convert the intermediate XML to legacy format.
Sounds like a bad idea. Write some Java that generates DFDL xsds that do the same trick.
2. Use java compute node (preferred by the architects in the organisation)
How does this differ from 1. ? Using WMB as a Java container is often the wrong choice - although it can be a fast route to an initial solution
3. Use xslt
It's portable, and I can see why the architects might like that, given the situation with WESB. Other than that, I don't see it as a good technical solution.
4. Use ESQL
ESQL is only a transformation language. You should never perform parsing and formatting in ESQL. So ESQL is only ever a part of the solution. Java-generated DFDL models + a small amount of ESQL ( or Java ) may be a good solution, though.
| Quote: |
| If metadata can not be obtained in any of the above mechanism, I'm thinking of parsing the XSD in one of the above mechanism. Please let me know your suggestions. |
I think you would be mad to parse the XSD in the message flow. You will end up doing the same work repeatedly ( or else you will end up having to write a thread-safe cache ). I would use the existing Java code ( from the WESB mediations ) as a basis for a migration tool. Then use the migration tool to generate a IIB meta-data ( DFDL schemas ).
_________________
Before you criticize someone, walk a mile in their shoes. That way you're a mile away, and you have their shoes too. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Sep 04, 2014 4:49 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
If nothing else works, you can read the message as a BLOB, and pass it to a JavaCompute node that then does all the same (horrible horrible horrible) things that your WESB flow is doing.
You can then map the objects created to objects that were built using JAXB, and thus output a sensible MbMessage tree. |
|
| Back to top |
|
|
|
|
