| Author |
Message
|
| petervh1 |
 Posted: Sun Apr 10, 2016 10:36 pm Post subject: Disadvantages of user-written event monitoring |
 |
|
Centurion
Joined: 19 Apr 2010
Posts: 135
|
Hi All
Does anyone have some documentation or references to discussions on why it is better practice to user the IBM-supplied event monitoring function rather than a user-written option?
The user-written option in this case consists of a number of subflows that are inserted at various points in the main flow. These subflows write out XML messages that are put to a queue and then added to a DB by a separate flow.
Thanks |
|
| Back to top |
|
 |
| ruimadaleno |
| Posted: Mon Apr 11, 2016 12:39 am Post subject: |
|
|
Master
Joined: 08 May 2014
Posts: 274
|
Maybe you can start by telling us why the ibm-supplied event monitoring does not meet your requirements.
Developing an event monitoring set of subflows sound to me like "re-inventing the wheel" or "i don't know if ibm-supplied event monitoring can give me xxxxx or zzzz"
_________________
Best regards
Rui Madaleno |
|
| Back to top |
|
|
| petervh1 |
| Posted: Mon Apr 11, 2016 1:05 am Post subject: |
|
|
Centurion
Joined: 19 Apr 2010
Posts: 135
|
I am convinced that IBM-supplied monitoring is the right way to go. I am in a customer-facing situation where I am trying to convince them that they should replace their monitoring functionality with the IBM-supplied one.
More specifically, they use subflows that are called at various points. These subflows write codes that confirm the progress of a message through a flow. The codes are written to an XML message that is then used to update a DB table. I have suggested using literal names in the eventName element in the monitoring profile to provide this "event code" functionality.
Any thoughts? |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Mon Apr 11, 2016 1:12 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
There is naturally the
if it ain't broke don't fix it
School of thought.
It sound like the current one works and meets their requirments.
So... how to get them to change?????
What will the change cost? (in terms of manpower and possibly software/hardware)
What will changing it get them that they don't already have?
What will changing it lose them in functionality?
What is it that they want that their current solution can't give them?
What is the performance impact?
Can you answer the above?
Do the answers make sense?
just for starters.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| petervh1 |
| Posted: Mon Apr 11, 2016 1:26 am Post subject: |
|
|
Centurion
Joined: 19 Apr 2010
Posts: 135
|
Thanks for the feedback smdavies99.
I'm happy to provide them with answers to the questions you posed.
What I'd also like, though, is to justify the replacement on grounds such as:
1 The IBM-supplied solution provides much detail - such as timestamping, terminal and node info etc.
2 The IBM-supplied solution allows you to avoid the practice of having functional and non-functional code in the same flow - a situation whereby failure in the non-functional code (ie monitoring subflow code) could cause a failure in the functional code (ie business logic code). |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Mon Apr 11, 2016 2:12 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
It is all very well to provide them with all this extra lovely data but will they use it? Will it have an effect on their business operations? etc etc etc
The existing code (subflows) are obviously well proven so what are the real risks of them failing? Come on now be honest...
Change for changes sake may not always work in the way you expect.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Apr 11, 2016 4:40 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
I echo the comments of my associate.
One point which I think hasn't been covered is that the IBM supplied solution is part of the product so using that moves the support & maintenance into IBM's budget rather than the customer's. If these sub flows are fairly stable & not subject to much change that's going to be a marginal saving.
Likewise with your point 2 - if the sub flows are stable what is the risk that it will fail and cause a business logic problem? Does removing that risk justify the cost?
Like my associate, I think you're batting on a very sticky wicket here. If you're building a new monitoring framework it's a no-brainer to leverage the IBM supplied events. If you've got a functional system (and I'm assuming here the customer's system is functional and working well or you wouldn't be struggling to convince them) then it's a much harder case to justify.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| inMo |
| Posted: Mon Apr 11, 2016 11:03 am Post subject: |
|
|
Master
Joined: 27 Jun 2009
Posts: 216
Location: NY
|
| I cannot find the driver for change - did I miss it? For a production system, I have to imagine something must be broken to even bring up a fundamental change impacting ALL flows - is something broken and needs repair? How many flows need this repair - 5, 50, 500? |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Mon Apr 11, 2016 9:58 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| inMo wrote: |
| For a production system, I have to imagine something must be broken to even bring up a fundamental change impacting ALL flows - is something broken and needs repair? How many flows need this repair - 5, 50, 500? |
That is a risk with ANY software syolutino that uses common code.
Find a bug in that code and you are faced with (eventually) having to change evey application that uses that code. How long (eventually) is does depend upon the bug itself.
For a critical bug then it might be tomorrow. For one with a very rare use case then it might not be that important and 'fixed in next version is fine'.
Notice how I have not mentioned anything to do with Broker/IIB in that last paragraph?
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
|
|
