| Author |
Message
|
| EricCox |
 Posted: Tue Feb 28, 2012 10:24 am Post subject: Main Flow Executes even if PUT to Log Q Fails |
 |
|
Master
Joined: 08 Apr 2011
Posts: 292
|
To all,
I have the following requirements.
This is in one Flow - Let's call it the MainFlow
1.) Main Message Flow Processing must Execute even if Logging Fails
2.) PUT a the original Request Message to LOGGING_QUEUE
In the MainFlow I have the inbound InputNode.Out wired to a MQOutPut Node to PUT the message to the LOGGING_QUEUE. The InputNode.Out is also wired to the main processing part of the Flow.
I have two Message Flows:
1.) MainFlow sends a copy of the Request Message to a LOGGING_QUEUE
2.) Another LoggingMessageFlow picks up the Message and Persists it to a Database
What is happening is that if the MainFlow cannot PUT the message to the LOGGING_QUEUE, for instance if it has reached Max Queue Depth, the MainFlow is reporting an error back to the service consumer.
I need the MainFlow to make a 'best effort' to PUT the message to the LOGGING_QUEUE but it cannot fail and send back an Error response if it cannot PUT the message. The MainFlow must continue to execute even if it can't PUT the message to the LOGGING_QUEUE.
How can I achieve this behavior?
All help is greatly appreciated.
Eric |
|
| Back to top |
|
 |
| Vitor |
| Posted: Tue Feb 28, 2012 10:57 am Post subject: Re: Main Flow Executes even if PUT to Log Q Fails |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| EricCox wrote: |
| How can I achieve this behavior? |
Use a Try/Catch to intercept the error from the MQOutput node.
It's an interesting requirement. What do you do with there's a problem with the business process supported by the main flow & there's no entry in the logging database? Assume there was a WMQ problem that prevented logging, or assume that the message never actually arrived and the business process is at fault?
Logging normally needs to be more reliable than that... 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| EricCox |
| Posted: Tue Feb 28, 2012 11:03 am Post subject: Logging normally needs to be more reliable than that... |
|
|
Master
Joined: 08 Apr 2011
Posts: 292
|
| What is the best practice for building a logging facility that is reliable yet allows the main flow to execute without interuption? |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Tue Feb 28, 2012 11:10 am Post subject: Re: Logging normally needs to be more reliable than that... |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| EricCox wrote: |
| What is the best practice for building a logging facility that is reliable yet allows the main flow to execute without interuption? |
Log4j is callable directly from ESQL and JCNs. Don't use the WMB log4j support pak, call log4j directly.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Feb 28, 2012 11:13 am Post subject: Re: Logging normally needs to be more reliable than that... |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lancelotlinc wrote: |
| EricCox wrote: |
| What is the best practice for building a logging facility that is reliable yet allows the main flow to execute without interuption? |
Log4j is callable directly from ESQL and JCNs. Don't use the WMB log4j support pak, call log4j directly. |
Can log4j write to a database? This sounds more like a transaction audit log than a straightforward technical log, which is how I've experienced log4j.
If it can, I may have a use for it. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| EricCox |
| Posted: Tue Feb 28, 2012 11:15 am Post subject: Re: Logging normally needs to be more reliable than that... |
|
|
Master
Joined: 08 Apr 2011
Posts: 292
|
| Vitor wrote: |
| lancelotlinc wrote: |
| EricCox wrote: |
| What is the best practice for building a logging facility that is reliable yet allows the main flow to execute without interuption? |
Log4j is callable directly from ESQL and JCNs. Don't use the WMB log4j support pak, call log4j directly. |
Can log4j write to a database? This sounds more like a transaction audit log than a straightforward technical log, which is how I've experienced log4j.
If it can, I may have a use for it. |
Yes, this is a transactional audit log. The goal is simply to send the original SOAP request message to a queue so it can be picked up and persisted to the database with a seperate Flow. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Feb 28, 2012 11:17 am Post subject: Re: Logging normally needs to be more reliable than that... |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| EricCox wrote: |
| What is the best practice for building a logging facility that is reliable yet allows the main flow to execute without interuption? |
Have the application do the logging rather than WMB? Seriously there's a lot of discussion in here about trying to run auditing out of WMB and what you're describing sounds like an audit database.
Another view is to investigate why the puts are failing. They shouldn't. WMB should enjoy the same level of uptime as any other WMQ application. In a stable production environment there's no excuse for a put failure.
You could also consider having the main flow insert into the logging database directly.
I'll defer to my associate on the ability of log4j to meet this need. I've never used it in this capacity.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Tue Feb 28, 2012 11:20 am Post subject: Re: Logging normally needs to be more reliable than that... |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| Vitor wrote: |
| lancelotlinc wrote: |
| EricCox wrote: |
| What is the best practice for building a logging facility that is reliable yet allows the main flow to execute without interuption? |
Log4j is callable directly from ESQL and JCNs. Don't use the WMB log4j support pak, call log4j directly. |
Can log4j write to a database? This sounds more like a transaction audit log than a straightforward technical log, which is how I've experienced log4j.
If it can, I may have a use for it. |
There is a JDBC Appender for use with log4j: http://www.tutorialspoint.com/log4j/log4j_logging_database.htm
However, for audit, we call the db directly, as Vitor points out, this is a better solution. We save the original payload in the db for replay.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Feb 28, 2012 11:25 am Post subject: Re: Logging normally needs to be more reliable than that... |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lancelotlinc wrote: |
| Vitor wrote: |
Can log4j write to a database? This sounds more like a transaction audit log than a straightforward technical log, which is how I've experienced log4j.
If it can, I may have a use for it. |
There is a JDBC Appender for use with log4j: http://www.tutorialspoint.com/log4j/log4j_logging_database.htm
|
Cool. Now to tell some Java people I'm not going to parse their log4j file with WMB and insert it into a database for them.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Feb 28, 2012 12:16 pm Post subject: Re: Logging normally needs to be more reliable than that... |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| EricCox wrote: |
| Yes, this is a transactional audit log. The goal is simply to send the original SOAP request message to a queue so it can be picked up and persisted to the database with a seperate Flow. |
If you have v8, you can use Record/Reply function to get this.
Even with v7, you can 'invent your own' record/reply function by enabling Monitoring on the Soap Node and capturing the full data in the event message.
Then create a flow that subscribes and writes the message into a database.
You'll then get normal MQ pub/sub behavior when the subscriber queue is full. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Feb 28, 2012 12:17 pm Post subject: Re: Logging normally needs to be more reliable than that... |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
| Even with v7, you can 'invent your own' record/reply function by enabling Monitoring on the Soap Node and capturing the full data in the event message. |
I always forget about that. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| EricCox |
| Posted: Tue Feb 28, 2012 1:28 pm Post subject: Re: Logging normally needs to be more reliable than that... |
|
|
Master
Joined: 08 Apr 2011
Posts: 292
|
| Vitor wrote: |
| mqjeff wrote: |
| Even with v7, you can 'invent your own' record/reply function by enabling Monitoring on the Soap Node and capturing the full data in the event message. |
I always forget about that. |
More justification for upgrade. Unfortunately we are on 12 year old technology v6.0. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Feb 28, 2012 1:39 pm Post subject: Re: Logging normally needs to be more reliable than that... |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| EricCox wrote: |
| Vitor wrote: |
| mqjeff wrote: |
| Even with v7, you can 'invent your own' record/reply function by enabling Monitoring on the Soap Node and capturing the full data in the event message. |
I always forget about that. |
More justification for upgrade. Unfortunately we are on 12 year old technology v6.0. |
I believe monitoring is available in v6.1 at least...
And, of course, v6.0 is officially Out of Support... |
|
| Back to top |
|
|
|
|
