| Author |
Message
|
| RB |
 Posted: Mon Jun 04, 2012 4:20 am Post subject: Parser options in java |
 |
|
Acolyte
Joined: 23 May 2006
Posts: 56
|
All,
We are using MB6.1 in our project. We have a custom java class which is used to implement the transformation logic. The class receives the XML message, builds the message tree using the method MBElement.createElementAsLastChildFromBitstream (with one message set having both XML and TDS formats). After this, we are using the MBElement.toBitstream to build the TDS output.
Is there any way we can specify the validation options in either createElementAsLastChildFromBitstream or toBitstream methods? Currently the code is able to create the output, but it fails to do any validation like minOccurs/maxOccurs/lengh validation etc. We want to specify ValidateContentAndValue but these methods are not providing any option for specifying this! Any idea how we can mention the parse option in these Java methods?
Regards,
RB |
|
| Back to top |
|
 |
| lancelotlinc |
| Posted: Mon Jun 04, 2012 5:15 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
|
| Back to top |
|
|
| RB |
| Posted: Mon Jun 04, 2012 5:49 am Post subject: |
|
|
Acolyte
Joined: 23 May 2006
Posts: 56
|
The current architecture doesnt allow me to do it this way. As per the current implementation, the entire message translation happens in Java classes. The implementation is very generic outside the classs, so the message flow currently use only the wrapper structure and the actual data is modified only in these java classes. So I need some option in Java to do this!
Regards,
RB |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Mon Jun 04, 2012 5:52 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
You could propagate the tree on the alternate path to an RCD. If the validation is successful, propagate on the normal path. If the RCD throws an exception, handle in your JCN.
Your argument against using an RCD doesn't make sense. Thats why there is an RCD in the first place. If you choose not to use an RCD, you will have to manually validate each individual field with custom Java code.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Jun 04, 2012 7:07 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
You say, on the one hand, "I have to do this in Java".
You say, on the other hand, "I can't do this in Java".
You're right about the second hand, you can't do this in Java. The options field is not accepted by the Java API.
If your architecture says "You have to do everything in Java even if you can't do it in Java", then it's not an architecture. |
|
| Back to top |
|
|
| RB |
| Posted: Mon Jun 04, 2012 8:26 am Post subject: |
|
|
Acolyte
Joined: 23 May 2006
Posts: 56
|
Yep.. that is exactly the situation.. Got to do that in Java, but not finding an option..  I am wondering why we are still not having the parser options in Java.. the options field has been provided for future enhancements (as a place holder) for quite some time in createElementAsLastChildFromBitstream... not sure when this is going to come!!..
Regards,
RB |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Mon Jun 04, 2012 8:34 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| RB wrote: |
Yep.. that is exactly the situation.. Got to do that in Java, but not finding an option.. I am wondering why we are still not having the parser options in Java.. the options field has been provided for future enhancements (as a place holder) for quite some time in createElementAsLastChildFromBitstream... not sure when this is going to come!!..
Regards,
RB |
I just gave you an option to do it in your JCN by using the ALTERNATE path. If the RCD throws an exception, the exception can be caught in your JCN. What more do you want?
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| RB |
| Posted: Mon Jun 04, 2012 8:53 am Post subject: |
|
|
Acolyte
Joined: 23 May 2006
Posts: 56
|
My architecture is slightly complex, I cannot change the flows - it is being used by lot of other flows/interfaces. We have a generic wrapper and depending upon the values in the message, flow dynamically invokes the specific class which has the transformation logic. So within these limits, my only option is to implement the transformation and the validations in Java.
My other option is to push all the validations upstream.. but I wanted to check whether there is any option in Java which would help in implementing the parser options before that! |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Mon Jun 04, 2012 8:55 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| RB wrote: |
My architecture is slightly complex, I cannot change the flows - it is being used by lot of other flows/interfaces. We have a generic wrapper and depending upon the values in the message, flow dynamically invokes the specific class which has the transformation logic. So within these limits, my only option is to implement the transformation and the validations in Java.
My other option is to push all the validations upstream.. but I wanted to check whether there is any option in Java which would help in implementing the parser options before that! |
I wasn't suggesting you to change the flows. I was suggesting you to add one node. You cannot add one node?
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jun 04, 2012 8:56 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| RB wrote: |
| We have a generic wrapper and depending upon the values in the message, flow dynamically invokes the specific class which has the transformation logic. |
Effectively the oft-used model where WMB is deployed as a WAS server that does tricks?
That's not complex, that's simplistic.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Mon Jun 04, 2012 8:59 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| Vitor wrote: |
| Effectively the oft-used model where WMB is deployed as a WAS server that does tricks? That's not complex, that's simplistic. |
Yucky - ewww. 
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jun 04, 2012 9:06 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lancelotlinc wrote: |
| Yucky - ewww. |
It's one step removed from the model where you have a JCN tthat reads a queue, transforms a message and writes it to a target queue, with the queue names in a properties file.
If I'm interpreting the OP's scenario correctly, there's a single flow bracketed with input and output nodes with a JCN in the middle. This JCN contains the logic to identify a required class and call out to it (I apologies for any poor use of Java terminology) for the work.
The "benefits" of such a model (which I've seen a few of) is that you don't need to deploy a new flow to implement a new message type, but simply provide a new jar. This fits well with the deployment model of a Java shop, but does mean (as the OP correctly points out) that the flow itself rapidly becomes fossilized.
The disadvantages of this style include but are not limited to the problem the OP has encountered, the need to write Java code to perform other non-parsing functions WMB can do (and for which a license fee is being paid), increased requirements for control and administration, etc, etc.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Mon Jun 04, 2012 9:09 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
I think his boss chose the wrong product. If all they wanted was to write stuff in Java, they should have chosen WebSphere ESB product rather than WebSphere Message Broker.
It also sounds like whomever designed the architecture has no practical knowledge of the WMB product. Either he / she did not attend the training class where they teach you the basic information on how to use the product or he /she has no coach or mentor to pass along the information.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Jun 04, 2012 9:12 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jun 04, 2012 9:20 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lancelotlinc wrote: |
| I think his boss chose the wrong product. If all they wanted was to write stuff in Java, they should have chosen WebSphere ESB product rather than WebSphere Message Broker. |
I'd be inclined to agree, assuming that a product choice was made & WMB was not selected because it was already on site (WMB is older & has a larger installed base than WESB).
| lancelotlinc wrote: |
| It also sounds like whomever designed the architecture has no practical knowledge of the WMB product. Either he / she did not attend the training class where they teach you the basic information on how to use the product or he /she has no coach or mentor to pass along the information. |
Welcome to the world the rest of us live in.
Aside from
| Code: |
| import my.usual.comments.on.getting.training.budget |
I've had architects tell me that "architecture is at a higher level than the technology & shouldn't be constrained by technological limitations or practices". Yes, I said that under my breath as well.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
