| Author |
Message
|
| rglack10 |
 Posted: Mon Jul 25, 2011 2:57 am Post subject: Defining WMB Business Service ID's |
 |
|
Apprentice
Joined: 06 Jul 2011
Posts: 34
|
Hi,
We are using WMB to integrate legacy landscape with modern apps based on WAS for example. We want to use the broker for content based routing to route from flow to flow and flow to adapter flow etc - all ususal scenarios. The issue we have is the legacy apps send fixed length string data that does not readily identify the app without intricate lookups and additianl analysis per app. The issue is we want a standard method if identifying an interface/flow and a unique way to perform content based routing, auditing, error identification etc.
The plan is to define a business service ID naming standard that we use to generate a unique business service ID for each flow and embed it in the flow using an externally declared variable so that the business service ID is unique to the flow and discoverabel at runtime.
The reason we want to do this is:
1) It gives each flow a unique textual business service ID for external lookups etc and prevents duplication
2) It reduces complexity of a bespoke method of identifying each legacy app from a value in its payload which is not at all obvious
3) It is a one size fits all solution
4) The naming standard we create is defined by us and is therefore intuitive, fit for purpose and is only really relevant to the broker developers and designers etc (it will never be used by / sent to external apps).
5) It is a global method of identifying an interface and flows within an interface
6) It will have improved benefits for our error handling, auditing etc as it will identify flows with an understandeable textual based business service ID.
The plan is to create this business service ID naming standard then record each entry in an environment data pool for easy viewing and access.
We have considered other options than the one above. For example we though about using the interface type to identify the interface and flows such as an MQ queue name or FTP file location etc but as the interface types are varied we did not see this as fit for purpose nor was it intuitive. In fact it is a disjointed method with bespoke work per interface/flow.
Based on the above description does anyone agree this is a solution that will work in practice? Has anyone had any similar experience of this?
I will be happy to explain further if anyone has any constructive feedback. |
|
| Back to top |
|
 |
| WGerstma |
| Posted: Mon Jul 25, 2011 3:45 am Post subject: |
|
|
Acolyte
Joined: 18 Jul 2011
Posts: 55
|
I am not sure, if I understood your text properly. But yes, surely you can add a UDP to be filled in development or deployment time to uniquely identify your flows. But you could also just use the messageFlowLabel to accomplish the same.
And yes, we have DB tables where we lookup data to populate MQ Detination Lists, with the lookup done by messageFlowLabel and some identifiers within the message payload. You can build dynamic routing like this.
If I did not match the core of your question, please clarify. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Mon Jul 25, 2011 4:48 am Post subject: Re: Defining WMB Business Service ID's |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| rglack10 wrote: |
| The issue we have is the legacy apps send fixed length string data that does not readily identify the app without intricate lookups and additianl analysis per app. The issue is we want a standard method if identifying an interface/flow and a unique way to perform content based routing, auditing, error identification etc. |
You could set the ApplicationId in the MQMD.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| rglack10 |
| Posted: Mon Jul 25, 2011 7:13 am Post subject: |
|
|
Apprentice
Joined: 06 Jul 2011
Posts: 34
|
| WGerstma wrote: |
I am not sure, if I understood your text properly. But yes, surely you can add a UDP to be filled in development or deployment time to uniquely identify your flows. But you could also just use the messageFlowLabel to accomplish the same.
And yes, we have DB tables where we lookup data to populate MQ Detination Lists, with the lookup done by messageFlowLabel and some identifiers within the message payload. You can build dynamic routing like this.
If I did not match the core of your question, please clarify. |
Hi, the question is simply is it a good idea to create this unique business service ID or is there a better way of identifying and promoting interface /flow properties for content based routing and the other tasks discussed above.
I have seen quite a few implementations of WMB and the concept of content based routing. Some apps comply to a set XML wrapper, some add the wrapper as data enters the ESB etc.. In this case we are doing no such thing we want to take the data "as-is" without adding anything to the message payload like an XML wrapper with app info etc...
Whilst I agree you can simply use the flow name this does have restrictions in that a flow name can be specific to a flow at a low level and not be as decoupled or descriptive of the wider interface as your own BSID could if you follow me and I suppose this now widens the discussion to what are your flow naming standards etc.. In any case I like the BSID idea as it gives you wider scope to provide a BSID that means more to testers, business people perhaps than a message broker flow name would or could.. This could be argued as good and bad I suppose as well I think it really depends what kind of hat you have on...
Thanks for the reply.. |
|
| Back to top |
|
|
| rglack10 |
| Posted: Mon Jul 25, 2011 7:16 am Post subject: Re: Defining WMB Business Service ID's |
|
|
Apprentice
Joined: 06 Jul 2011
Posts: 34
|
| lancelotlinc wrote: |
| rglack10 wrote: |
| The issue we have is the legacy apps send fixed length string data that does not readily identify the app without intricate lookups and additianl analysis per app. The issue is we want a standard method if identifying an interface/flow and a unique way to perform content based routing, auditing, error identification etc. |
You could set the ApplicationId in the MQMD. |
Another idea we considered but it may not all be MQ interfacing and even then when entering the broker an MQMD will be created and the app ID could be populated with a BS ID as it entered the broker but I'm not sure what benefit this gives over simply promoting the property and storing it in rfh2 for example... Also, any changes to legacy apps is defintie no no so we have to work with what we have and even a change as little as populating the appID is excluded.. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Jul 25, 2011 7:34 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
If you need to keep your legacy apps unchanged, then you need to define fixed endpoints for those legacy apps - "adapters" if you will - that modify the messages they produce to add the relevant information to identify the messages for common routing and transformation.
There's no magic wand here. Something needs to create new data and add it to the message. |
|
| Back to top |
|
|
| WGerstma |
| Posted: Mon Jul 25, 2011 9:51 am Post subject: |
|
|
Acolyte
Joined: 18 Jul 2011
Posts: 55
|
There are unlimited possibilites. You can go with your UDP, you can pass it around in usr folder, you can even keep a history of the flows passed in usr and/or in a databse. Technically spoken, everything works.
About your idea of providing such data to testers and business people: I often have seen these people requesting such data, I have never seen them put such data to any use. I suppose, 99% of the time, WMB developers have to cope with the traces. Build something you are comfortable with, do not satisfy each and every demand from everybody. |
|
| Back to top |
|
|
| rglack10 |
| Posted: Mon Jul 25, 2011 10:43 pm Post subject: |
|
|
Apprentice
Joined: 06 Jul 2011
Posts: 34
|
| mqjeff wrote: |
If you need to keep your legacy apps unchanged, then you need to define fixed endpoints for those legacy apps - "adapters" if you will - that modify the messages they produce to add the relevant information to identify the messages for common routing and transformation.
There's no magic wand here. Something needs to create new data and add it to the message. |
I agree with this statement entirely... This is exactly our aim. |
|
| Back to top |
|
|
|
|
