| Author |
Message
|
| elenzo |
 Posted: Tue May 15, 2012 5:30 am Post subject: Handling two different version of the same code |
 |
|
Acolyte
Joined: 22 Aug 2006
Posts: 53
|
Hi, we have a problem with version of a service, as a request of a client we have to be able to deploy two (or more) version of the same flow at the same time.
Consider this example:
I have a Message Flow like this: MqInput - Compute - MqOutput, in the compute node we make a transformation, now, that transformation needs a new field, and we have to deploy the old code and the new code (with the new field) , so... the only idea we have is do something like this... Have two different esql, which are gonna be pretty much the same, and try to access them dinamically, exactly as we can do with an XSLT. In the compute Node is the ESQL Module property, which we should complete dinamically, may be setting a param in the localEnvironmnet, is this posible ?? If not (as I expect) do you have any other ideas to solve this ?
Thank you very much! |
|
| Back to top |
|
 |
| lancelotlinc |
| Posted: Tue May 15, 2012 5:37 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
We do this with a Boolean UDP. When we want the new code, we flip the UDP to TRUE. When we want the old code, we flip the Boolean UDP to FALSE.
If you want real-time access to same, use a Singleton.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue May 15, 2012 5:38 am Post subject: Re: Handling two different version of the same code |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| elenzo wrote: |
| is this posible ?? |
It's not.
| elenzo wrote: |
| If not (as I expect) do you have any other ideas to solve this ? |
Well call me crazy but why not have ESQL which can handle both forms of input message? Or if you want a means of implementing you much worse suggestion, put the 2 near identical ESQL in the flow & route between them based on the existence (or not) of this field. Then ensure everyone knows any future changes need to be made to both versions in both places.
I'd imagine that if these are 2 different versions of the same input there might even be a version indicator you could reference, which would be more reliable than a potentially optional field.
I wouldn't handle this kind of scenario with 2 near-identical XSLT even though you can for exactly that reason. Dual maintenance is a pain.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue May 15, 2012 5:41 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lancelotlinc wrote: |
We do this with a Boolean UDP. When we want the new code, we flip the UDP to TRUE. When we want the old code, we flip the Boolean UDP to FALSE.
If you want real-time access to same, use a Singleton. |
I think the @OP wants to run multiple versions of the "same" code perminently rather than just upgrading.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue May 15, 2012 5:46 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| In general, you need to have two copies of the flow with two unique names. |
|
| Back to top |
|
|
| elenzo |
| Posted: Tue May 15, 2012 6:03 am Post subject: |
|
|
Acolyte
Joined: 22 Aug 2006
Posts: 53
|
Yes, having 2 flows with different names is the only solution we have so far, but considering that we have more than 200 flows and we can have 2, 3 or more versions at the same time, this solution seems to be very unpleasant
I think we are gonna have to migrate all esql to XSLT and that way access the transformation using the localEnvironmnet |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue May 15, 2012 6:09 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| elenzo wrote: |
| I think we are gonna have to migrate all esql to XSLT and that way access the transformation using the localEnvironmnet |
I think you're making a rod for your own back but go in peace with your solution & may fortune smile on you.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| missing_link |
| Posted: Wed May 16, 2012 5:07 am Post subject: |
|
|
Acolyte
Joined: 08 Jan 2004
Posts: 60
|
Is the new field on the input, output or both?
If you need to host multiple versions of the same service but at the same end point or queue, then you should have something in the incoming payload/header/namespace to identify which version of the response the client wants. That way you can still have one flow and just within the flow to the required transformation routine.
Done this before and used the namespace to version the payload and had 5 versions of a service all quite happily running in one flow, each with slightly different input/output formats. Once the latest code went live, no changes allowed save for bug fixes.
If you need to host multiple versions of a service, its easier to make that allowance in the design upfront. |
|
| Back to top |
|
|
| deepnair |
| Posted: Wed May 16, 2012 9:44 am Post subject: |
|
|
Apprentice
Joined: 07 Feb 2012
Posts: 35
|
I think you should externalize such logic into java and invoke java from esql based on conditions, for e.g.
ESQL Code
call Core java translation
Java Code
Identify input type (take it as key)
Read Key value pair xml and get another java class name for key
Execute the java class that you got from XML
So this way you have a very dynamic way of handling transformations.
Thanks,
Deep Nair |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed May 16, 2012 10:13 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| deepnair wrote: |
| I think you should externalize such logic into java and invoke java from esql based on conditions, for e.g. |
You can do the same kind of thing from ESQL without needing to go into Java.
But in the general case, when you need to support more than one version of a given interface, you need to plan for the management of having two entirely separate flows.
Whether or not you deploy those flows to the same EG or do something smart to route traffic to different EGs is yet again a separate question. |
|
| Back to top |
|
|
| deepnair |
| Posted: Wed May 16, 2012 10:16 am Post subject: |
|
|
Apprentice
Joined: 07 Feb 2012
Posts: 35
|
| Quote: |
| You can do the same kind of thing from ESQL without needing to go into Java. |
The advantage I see here of java is that we need not deploy the flow with the business logic again (thus needing regression) but use java and an xml key value pair combination to make changes dynamically and easily deployable. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed May 16, 2012 10:18 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| deepnair wrote: |
| Quote: |
| You can do the same kind of thing from ESQL without needing to go into Java. |
The advantage I see here of java is that we need not deploy the flow with the business logic again (thus needing regression) but use java and an xml key value pair combination to make changes dynamically and easily deployable. |
V8 has ESQL files that are independently deployable.
   |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed May 16, 2012 9:27 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
From V6 to V7 you can keep the flow name but just switch it having the version number in the broker schema... They can then coexist in the same execution group... but you'd need some kind of router flow to route messages to either one...
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| naio |
| Posted: Tue Nov 27, 2012 2:17 pm Post subject: |
|
|
Voyager
Joined: 08 Nov 2012
Posts: 82
|
I am facing the same problem, of potential several version coexisting at the same Time.
And like in other ESBs or with XSL in WMB I would like to select the ESQL module before arriving in the COMPUTE.
As far as I have read, this is not posible, or any of you have reach this?
Having a ESQL that select among others, or General ESQL for all the cases are not the best practice, especially if the diferences among the versions are big and there are a lot of versions.
I just would like to select among diferent ESQL files and Just One Compute.
_________________
"God is in his heaven all's right with the world" |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Nov 27, 2012 2:24 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| naio wrote: |
| As far as I have read, this is not posible, or any of you have reach this? |
It's not. Any of the suggestion in this thread will give you a functionally equivalent solution.
You need to ask why are these different versions? If the differences between them are large enough they're separate code, are they not separate modules? Why does the independently deployable ESQL of v8 and message routing not meet your needs? Do you want to select a given piece of ESQL because the familiar architecture is to select and load a Java class?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
