| Author |
Message
|
| Cogito-Ergo-Sum |
 Posted: Thu Dec 16, 2010 12:21 am Post subject: Detect exception when input file is empty. |
 |
|
Master
Joined: 07 Feb 2006
Posts: 293
Location: Bengaluru, India
|
Environment : WMB 6.1 on Linux (Ubuntu 10.04) and WMB 6.1 Toolkit on Linux (Ubuntu 10.04)
Once a message flow has started, how would I know if the message flow has terminated with or without an exception ? I am trying to co-relate the message flow with a mainframe batch job that would complete with a zero or non-zero return code. Based on the return code, the job is marked or not marked in error.
Details :
The requirement is to throw an exception if the file name as mentioned in the FileInput node is found to be empty. With the exception thrown, manual intervention/investigation is done before a non-empty file is provided. BTW, the file name in FileInput node will be a symbolic link. To do this, I am connecting the 'End of Data' terminal of a FileInput node to a Compute node where an exception is thrown. I am able to see the exception message in syslog and the input file (that is, the symbolic link) has been moved to mqsibackout folder too.
All this I understand. But, in a production environment, how can the message flow alert the support staff of this error ? Does this come under 'Monitoring' ? If so, then I don't follow at all because, the input nodes are not having the 'Monitoring' tab as seen in WMB Toolkit.
_________________
ALL opinions are welcome.
-----------------------------
Debugging tip:When you have eliminated all which is impossible, then whatever remains, however improbable, must be the truth.
---Sherlock Holmes |
|
| Back to top |
|
 |
| kimbert |
| Posted: Thu Dec 16, 2010 12:45 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Please quote the exact version of toolkit and runtime. Monitoring was added first in 6.1.0.2 and was significantly enhanced in 6.1.0.3. |
|
| Back to top |
|
|
| Cogito-Ergo-Sum |
| Posted: Thu Dec 16, 2010 1:36 am Post subject: |
|
|
Master
Joined: 07 Feb 2006
Posts: 293
Location: Bengaluru, India
|
Toolkit (as seen in Help -> About WebSphere Message Brokers Toolkit - Message Broker) : Version: 6.1.0
Runtime (as seen from . mqsiprofile) : 6.1.0.2
Are you implying that the alerting part can be done only by 'Monitoring' option ?
_________________
ALL opinions are welcome.
-----------------------------
Debugging tip:When you have eliminated all which is impossible, then whatever remains, however improbable, must be the truth.
---Sherlock Holmes |
|
| Back to top |
|
|
| kimbert |
| Posted: Thu Dec 16, 2010 2:13 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| Are you implying that the alerting part can be done only by 'Monitoring' option ? |
No. I was just supplying some relevant facts. Now we know why the Monitoring tab does not appear in your toolkit. |
|
| Back to top |
|
|
| Cogito-Ergo-Sum |
| Posted: Thu Dec 16, 2010 3:57 am Post subject: |
|
|
Master
Joined: 07 Feb 2006
Posts: 293
Location: Bengaluru, India
|
| Quote: |
| No. I was just supplying some relevant facts. Now we know why the Monitoring tab does not appear in your toolkit. |
ok, the missing tab part is cleared. Thanks !
But, I am still not sure how to do the alerting part. As I mentioned, I have come to the point where I can write a message to syslog.
In the message flow, the file (sym-link) in FileInput node would be set to different files over the time. So, it is important that, a given file is handled 'correctly' - for example, take action when file is empty - before the flow can be allowed to process other files.
_________________
ALL opinions are welcome.
-----------------------------
Debugging tip:When you have eliminated all which is impossible, then whatever remains, however improbable, must be the truth.
---Sherlock Holmes |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Dec 16, 2010 4:06 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
I'm a bit confused about what you want to detect.
It should not be possible to deploy a flow with a FileInput node that has an entirely empty value for the file name.
It should not be possible on any given file system to write a file without a file name.
So I don't know what you mean by a file name that is entirely empty.
If you want to find out if the contents of the file are empty, you can look at the Properties that are set in the message tree after you have read the file. One of them should be the length that was read. If it's not, then you can read the contents as BLOB and then just ask for the length of InputRoot.BLOB.BLOB. |
|
| Back to top |
|
|
| Cogito-Ergo-Sum |
| Posted: Thu Dec 16, 2010 4:44 am Post subject: |
|
|
Master
Joined: 07 Feb 2006
Posts: 293
Location: Bengaluru, India
|
I am sorry, I was not clear.
My question was about the file being empty; not file name being empty. Something like this :
| Code: |
lrwxrwxrwx 1 mqm mqm 8 2010-12-16 18:10 FI01 -> tempFile
-rw-r--r-- 1 mqm mqm 0 2010-12-16 11:55 tempFile
|
The FileInput node reads FI01.
In the Compute node - connected from 'End of Data' terminal of FileInput node - I am able to test InputLocalEnvironment.File.IsEmpty and InputLocalEnvironment.File.Record = 0 to know it is an empty file. And, in such a scenario, I am throwing an exception which can be seen in syslog.
But, I want to know, in a production environment, how can the message flow alert the support staff of this error ?
_________________
ALL opinions are welcome.
-----------------------------
Debugging tip:When you have eliminated all which is impossible, then whatever remains, however improbable, must be the truth.
---Sherlock Holmes |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Dec 16, 2010 5:12 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Cogito-Ergo-Sum wrote: |
| But, I want to know, in a production environment, how can the message flow alert the support staff of this error ? |
How, in a production environment, would the support staff detect any problem with broker? For instance, if a flow which referred to a database for business reasons throws a SQL error (either because the database is down or the data being supplied is flawed) how will support be notified?
The same mechanism can be used here.
Or instead of throwing an error, the flow could send an email / WMQ message / write to a triggered database table. The possibilities are endless.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Cogito-Ergo-Sum |
| Posted: Thu Dec 16, 2010 5:47 am Post subject: |
|
|
Master
Joined: 07 Feb 2006
Posts: 293
Location: Bengaluru, India
|
| Quote: |
| How, in a production environment, would the support staff detect any problem with broker? |
I thought, this question might come. 
We are exploring features to suit our transition to WMB. It would have been nice to see what message flows are currently running or stopped, what message flows reported an exception, etc. For now, it seems a cron job to poll the syslog for certain message IDs might inform us of an exception. Of course, taking an action (email, trigger, raise ticket etc.) on an exception would be out of scope of WMB.
_________________
ALL opinions are welcome.
-----------------------------
Debugging tip:When you have eliminated all which is impossible, then whatever remains, however improbable, must be the truth.
---Sherlock Holmes |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Dec 16, 2010 5:52 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Cogito-Ergo-Sum wrote: |
| I thought, this question might come. |
It is a fairly obvious one, given you're using the same WMB exception mechanism to report an empty file.
| Cogito-Ergo-Sum wrote: |
| For now, it seems a cron job to poll the syslog for certain message IDs might inform us of an exception. |
Or a app using the CMP to obtain the information. At least the running / stopped / health questions.
| Cogito-Ergo-Sum wrote: |
| Of course, taking an action (email, trigger, raise ticket etc.) on an exception would be out of scope of WMB. |
Why "of course"?
The next obvious question is how do you notify support about problems in your current production environment and (if this isn't a separate question) why are you not just using the same method to notify them of problems in WMB?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Cogito-Ergo-Sum |
| Posted: Thu Dec 16, 2010 6:28 am Post subject: |
|
|
Master
Joined: 07 Feb 2006
Posts: 293
Location: Bengaluru, India
|
| Quote: |
| Or a app using the CMP to obtain the information. At least the running / stopped / health questions. |
I will have a look into CMP. Thanks !
Because I think, a product should only report an error through a return code, stack trace, etc. Exactly how it is consumed - email, pager, ticket, phone call - is not in scope of the product. My question really was to know how does WMB report an error. The syslog (reporting) and cron job (consumption) is one way. CMP, the other, I guess.
The Monitoring part is another important way, I guess.
| Quote: |
| The next obvious question is how do you notify support about problems in your current production environment and (if this isn't a separate question) why are you not just using the same method to notify them of problems in WMB? |
Ours' is a mainframe batch job environment. I think, there is an exit that detects a non-zero return code and routes it to a ticketing application (CA-SOLVE). I would really have to ask our sysprogs to know the details.
In case of batch jobs, we have a return code which is (probably) polled by CA-SOLVE to raise a ticket. I was looking for something similar in case of WMB that can be polled/detected by CA-SOLVE or etc.
_________________
ALL opinions are welcome.
-----------------------------
Debugging tip:When you have eliminated all which is impossible, then whatever remains, however improbable, must be the truth.
---Sherlock Holmes |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Dec 16, 2010 6:39 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Cogito-Ergo-Sum wrote: |
| Because I think, a product should only report an error through a return code, stack trace, etc. Exactly how it is consumed - email, pager, ticket, phone call - is not in scope of the product. |
I'm forced to disagree with you there. Especially in this instance where there's no actual error with broker; the problem is that the data is missing or invalid. I don't see any problem with a product using something other than return codes to communicate with the outside world. That's a very JCL-centric view (and I say that as a z/OS person of many years standing).
| Cogito-Ergo-Sum wrote: |
| In case of batch jobs, we have a return code which is (probably) polled by CA-SOLVE to raise a ticket. |
I suspect that the exit you refer to raises a ticket in CA-SOLVE rather than it polling anything. It's a far more typical way to run that system.
| Cogito-Ergo-Sum wrote: |
| I was looking for something similar in case of WMB that can be polled/detected by CA-SOLVE or etc. |
Like an email arriving in a monitored mail box, or a triggered batch job firing this exit perhaps? 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Dec 16, 2010 7:45 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
There are a bunch of different approaches to this problem.
The right approach for your shop usually starts, as Vitor is trying to lead you towards, with the mechanisms that are already in use.
Most major vendors of monitoring/alerting software end up having extensions or plugins or optional products that are smart about Message Broker. Certainly of course you can buy the right Omegamon tool from IBM's Tivoli line and it will know how to monitor your Broker.... Probably CA has something as well. |
|
| Back to top |
|
|
| Cogito-Ergo-Sum |
| Posted: Thu Dec 16, 2010 8:06 am Post subject: |
|
|
Master
Joined: 07 Feb 2006
Posts: 293
Location: Bengaluru, India
|
| Quote: |
| Certainly of course you can buy the right Omegamon tool from IBM's Tivoli line and it will know how to monitor your Broker.... Probably CA has something as well. |
hmm...thanks !
_________________
ALL opinions are welcome.
-----------------------------
Debugging tip:When you have eliminated all which is impossible, then whatever remains, however improbable, must be the truth.
---Sherlock Holmes |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Dec 16, 2010 8:10 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
| Certainly of course you can buy the right Omegamon tool from IBM's Tivoli line and it will know how to monitor your Broker.... |
...as well as all your batch jobs & other tasks and platforms correctly configured.
| mqjeff wrote: |
| Probably CA has something as well. |
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
