| Author |
Message
|
| Vitor |
 Posted: Mon Jun 04, 2012 9:21 am Post subject: |
 |
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
 
Votes mean changes! 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Mon Jun 04, 2012 9:27 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Vitor wrote: |
| 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. |
It also makes it very very difficult to do reasonable change management. |
|
| Back to top |
|
|
| RB |
| Posted: Mon Jun 04, 2012 8:43 pm Post subject: |
|
|
Acolyte
Joined: 23 May 2006
Posts: 56
|
lancelotlinc,
I cannot modify the flows to even add a node. There are hundreds of different messages handled by the flow and we cannot create an alternate path just for this scenario! That's why I wanted to check if there is any way we can specify the options in java parsing, just like the way we can do in message flows and ESQL!
Regards,
RB |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Jun 05, 2012 2:47 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| RB wrote: |
| I cannot modify the flows to even add a node. There are hundreds of different messages handled by the flow and we cannot create an alternate path just for this scenario! |
Again.
You CANNOT DO THIS.
And on top of that, you CANNOT SPECIFY OPTIONS USING JAVA.
So you have Two things that You CANNOT do, and yet you still must do SOMETHING.
So you therefore must do SOMETHING ELSE.
I.e. create a new flow.
You have NO OTHER OPTION. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Tue Jun 05, 2012 4:26 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| RB wrote: |
lancelotlinc,
I cannot modify the flows to even add a node. There are hundreds of different messages handled by the flow and we cannot create an alternate path just for this scenario! That's why I wanted to check if there is any way we can specify the options in java parsing, just like the way we can do in message flows and ESQL!
Regards,
RB |
Your System Architect is daft. You guys really painted yourselves into a corner. A skilled architect would design flexibility into the architecture. I cannot think of any scenario worse than this since, even with mainframe Cobol, you can send MQ messages anywhere you want.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| Esa |
| Posted: Tue Jun 05, 2012 4:37 am Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
@RB
A framework flow like the one you are using should be configurable. It should use UDPs and/or promoted properties to make it possible to adapt it to different situations. You shoud ask your architects if they could make it possible to configure validation on the MQOutput node or whichever output node you are using... |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Jun 05, 2012 4:43 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
RB - you need to discuss this situation with your architect and make sure they understand the tradeoffs they have made and how it impacts your situation. It seems that they have taken a lot of effort to ensure that their broker environment is 'easy to deploy', without understanding what 'easy to deploy' really means.
This architecture clearly didn't consider the notion of validation of data very well, and that should have been part and parcel of any integration solution.
Once you have had that discussion, your architect may provide you with some remediation.
If not, you can run some experiments to see if you can use ASBITSTREAM from within an MbSQLStatement object. If it works, you need to make clear to the architect that this still represents a fatal flaw in their design and something needs to be changed. |
|
| Back to top |
|
|
| RB |
| Posted: Tue Jun 12, 2012 9:21 pm Post subject: |
|
|
Acolyte
Joined: 23 May 2006
Posts: 56
|
Thanks for all your suggestions! (and sorry for the delay in the response)
Our integration layer has two products - Data Power and MB. Most of the time, messages will be coming to DP first and gets routed to MB only in case of specific transformation requirements which cannot be addressed in DP with the current framework. Though the generic architecture in MB is to carry the message in the payload section of a generic wrapper and do the transformations in java, it does have the flexibility of sending to a dedicated message flow and do the transformations (though this is not recommended much by the architects here!)
So in our case, I wanted to see if I could implement the parsing logic in Java itself which would have been much easier than pushing these validations to the DP components or adding a separate message flow just for this purpose! I think we don't have any other option than to go for one of these!
Regards,
Rijesh |
|
| Back to top |
|
|
|
|
