| Author |
Message
|
| petervh1 |
 Posted: Wed Sep 21, 2016 11:37 pm Post subject: Best practice for error handling and monitoring |
 |
|
Centurion
Joined: 19 Apr 2010
Posts: 123
|
Hi
I am looking at streamlining the current error handling process together with the monitoring/logging process as follows:
Take a basic flow of MQInput -> Compute -> MQOutput. Wire the Catch and Failure terminals to an error-handling SF. This SF writes the ExceptionList to a queue and the original payload to another queue.
This causes these queues to fill up over time, and generally produces a requirement for maintenance.
I would appreciate feedback on this scenario:
Take the same basic flow of MQInput -> Compute -> MQOutput. Remove the connection to the error-handling SF. Create a monitoring profile for this flow that generates an event message when the payload passes through any of these eventSourceAddresses:
MQ Input.transaction.Rollback
MQ Input.terminal.failure
MQ Input.terminal.catch
If an event is generated, write this event message to another queue (this event message is configured to contain the original payload and the ExceptionList). A separate flow reads these event messages and writes them to a database, where they can be examined and dealt with if necessary. If an error occurs in this second flow, invoke an error-handling SF that writes the ExceptionList to a queue and the original payload to another queue.
This way, I only get messages written to a queue/s if the database-writing flow has a failure. I still have access to the original payload and the ExceptionList from the database row.
Comments please? |
|
| Back to top |
|
 |
| timber |
| Posted: Thu Sep 22, 2016 3:42 am Post subject: |
|
|
Grand Master
Joined: 25 Aug 2015
Posts: 1280
|
| What value is monitoring adding? Can't you simply write a message flow that reads the queue(s) and writes to a database? |
|
| Back to top |
|
|
| petervh1 |
| Posted: Thu Sep 22, 2016 3:49 am Post subject: |
|
|
Centurion
Joined: 19 Apr 2010
Posts: 123
|
| I'm using monitoring to record the progress of payloads through the flow. Need this so that Production Support can trace different payloads. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Sep 22, 2016 4:00 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
There are several products that will capture and handle this kind of monitoring data for you.
Is the value of the information greater than the cost of such a product?
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| petervh1 |
| Posted: Thu Sep 22, 2016 11:11 pm Post subject: |
|
|
Centurion
Joined: 19 Apr 2010
Posts: 123
|
| My question was aimed more at "is this a sound approach to reducing maintenance on queues by means of combining IIB-supplied monitoring capabilities with a flow", rather than "is this a good way to read and process the raw XML event messages emitted by IIB". |
|
| Back to top |
|
|
| timber |
| Posted: Fri Sep 23, 2016 12:51 am Post subject: |
|
|
Grand Master
Joined: 25 Aug 2015
Posts: 1280
|
In your first post, you said:
| Quote: |
| This SF writes the ExceptionList to a queue and the original payload to another queue. |
...so the existing subflow is logging the payload to a queue.
Then you proposed the monitoring-based solution:
| Quote: |
| If an event is generated, write this event message to another queue (this event message is configured to contain the original payload and the ExceptionList). A separate flow reads these event messages and writes them to a database |
I don't understand why you cannot use the existing payload/exception queues to populate the database.
| Quote: |
| is this a sound approach to reducing maintenance on queues by means of combining IIB-supplied monitoring capabilities with a flow |
It's a sound approach to monitoring message flows. But I don't see how it will reduce maintenance of the queues any better than my proposal would. Either way, the queues will be regularly drained by the message flow that populates the database so the queue-filling-up problem is resolved. |
|
| Back to top |
|
|
|
|
