| Author |
Message
|
| prem.rengasamy |
 Posted: Thu Sep 29, 2011 1:19 pm Post subject: WMB MonitoringFlow Issue |
 |
|
Newbie
Joined: 29 Sep 2011
Posts: 4
|
Hi
We have a requirement as shown below.
Environment
1. WMB version = V7
2. MQ version = V7
3. OS = Windows[for test]/AIX for other regions
Current scenario
1 WMB flow - does a soap request/reply - lets say this part is ok
2. this WMB flow has 2 nodes - after SOAP Reply is done
3. Node 1 or Node2 is called based on a value lets say EmpType='A'
4. We have terminal In wmb monitoring event setup for Node1 to emit when EmpType='A' and terminal In WMB moinitoring event setup for Node2 to emit when EmpType='B'
5. We were ok until emptype='A' was used a filter from within wmb code. We had a subscription created for $SYS/Broker/BRK1/Monitoring/<<EGNAME>>/<<FLOWNAME>> in MQ V7 and there 1 MQ subscriber Q which also worked fine
Issue
We are trying to create a queue called lets say 'QA' to subscribe messages when EmpType='A' and queue 'QB' to subscribe message when EmpType='B'
Constraints
1 Topic - predefined by WMB
1 Flow - per requirement
Content based filtering not allowed inside MQ to keep it per IBM recommendation inside WMB
question
how do u emit a topic with Filter from within WMB flow monitoring setup to emit Topic 1 or Topic 2 or Topic 1 with Filter A and Topic 1 with Filter B
I hope i did not leave any backdrop to understand the requirement. Any feedback appreciated !!! |
|
| Back to top |
|
 |
| prem.rengasamy |
| Posted: Thu Sep 29, 2011 1:21 pm Post subject: |
|
|
Newbie
Joined: 29 Sep 2011
Posts: 4
|
| We are considering publish node based on EmpTypes to different topics as 1 option though we prefer using the wmb monitoring profile and its default $SYS/Broker/BRK1/Monitoring/<<EGNAME>>/<<FLOWNAME>> topic |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Sep 30, 2011 4:39 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| prem.rengasamy wrote: |
| we prefer using the wmb monitoring profile |
Why? Why use system monitoring for business data events?
Also a queue called "QA" is not going to subscribe to anything. A subscription might use QA as a target, but the queue itself isn't doing anything.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| prem.rengasamy |
| Posted: Fri Sep 30, 2011 6:23 am Post subject: |
|
|
Newbie
Joined: 29 Sep 2011
Posts: 4
|
| Vitor wrote: |
| prem.rengasamy wrote: |
| we prefer using the wmb monitoring profile |
Why? Why use system monitoring for business data events?
Also a queue called "QA" is not going to subscribe to anything. A subscription might use QA as a target, but the queue itself isn't doing anything. |
1. Even though its business data we use for our internal log process/portals
2. QA or QB is planned to be a target and consumed by separate process. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Sep 30, 2011 6:57 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| prem.rengasamy wrote: |
| 1. Even though its business data we use for our internal log process/portals |
Ok. but IMHO the event message is a very cumbersome way to trap this, especially if you're trying to make the event conditional on a given business data item.
| prem.rengasamy wrote: |
2. QA or QB is planned to be a target and consumed by separate process. |
Using a separate topic(s) would allow these processes a lot more freedom to act.
I know the issues with content based filtering, but I'm interested to hear IBM has explicitly recommended against it's use. Is this a publicly available document you can post a link to?
Bottom line - the topic an event message is published with is fixed. The conditions under which it's published as fixed. The content can be varied only as documented.
If it was me (and obviously it's not), I'd build a generic sub-flow that publishes your business data with whatever topics, subscription points, etc you like and build that into the front of all your flows. It's no more intrusive than editing the monitoring parameters.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| prem.rengasamy |
| Posted: Fri Sep 30, 2011 12:32 pm Post subject: |
|
|
Newbie
Joined: 29 Sep 2011
Posts: 4
|
| Vitor wrote: |
| prem.rengasamy wrote: |
| 1. Even though its business data we use for our internal log process/portals |
Ok. but IMHO the event message is a very cumbersome way to trap this, especially if you're trying to make the event conditional on a given business data item.
| prem.rengasamy wrote: |
2. QA or QB is planned to be a target and consumed by separate process. |
Using a separate topic(s) would allow these processes a lot more freedom to act.
I know the issues with content based filtering, but I'm interested to hear IBM has explicitly recommended against it's use. Is this a publicly available document you can post a link to?
Bottom line - the topic an event message is published with is fixed. The conditions under which it's published as fixed. The content can be varied only as documented.
If it was me (and obviously it's not), I'd build a generic sub-flow that publishes your business data with whatever topics, subscription points, etc you like and build that into the front of all your flows. It's no more intrusive than editing the monitoring parameters. |
Thanks for the thoughts. We planned to go via IBM recommended approach keeping content based filtering out of Mq and into WMB via another subscriber flow so it gets the wmb:event message which we do want to be retained for our log process/future ibm product to consume it - this flow routes to separate qs - problem solved.
Thanks anyways ! |
|
| Back to top |
|
|
|
|
