I was wondering about the following. If a process triggered from Orchestrator encounters issues, which are ‘resolved’ with proper exception handling, but does not execute the actual process, the Job Status will still be set to ‘Completed’, even though from a business Point-of-View processing failed. Also, for reporting purposes, being able to make a distinction between Jobs that are actually completed and or faulted is a great benefit.
How would/do you deal with this situation? My ideas so far:
Use Log Message at Info Level Fatal to identify processes that were not able to process any Transactions;
Re-throw the Exception at the very last step (outside of a Try/Catch) to cause another exception, which would set the status to Faulted
I would be very interested in your suggestions and ideas!
You mentioned Exception but have you used Business Rule Exception? This will differentiate your Transaction Items outcome which a business user could then review and requeue if desired.
In the REFramework they have a finally as part of a Try/Catch which looks like the below. When the Business Exception is handled a Set Transaction Status activity is called with ErrorType Business and the reason of the exception message. alonger with logging a Error message.
Rereading, you don’t mention Queues / Transactions … so I’ll rethink on just the Jobs aspect only!
In the end, I really think it will depend on the job and the outcome desired.
I’m working on a process currently, that I don’t want to fault or stop the process in anyway if one item in the process fails whether it’s system related or business rule related, I log those at the desired level, and either send off a report the business unit or in some cases as we have our logs being indexed by Splunk, we’re in the process of building dashboards and alerts to highlight this issues.
True, at Transaction level that would be a proper way to differentiate between successful and failed items. What I meant was, we cannot differentiate between no items being processed because of for instance an error during Initialization, because with proper exception handling the Job state will be set ‘Completed’ (see also the screenshot).
That’s actually one of the things I need to sort out for this process I took over. A run with business exceptions galore will still show “Completed” as you highlight.
I’m currently handling it be re-throwing or just logging depending on the severity needed. In my case, even if a run has a bunch of Business Exception. Most the time I’d call it successful, unless the functional requirements required us to represent the job as failed according to the job Orchestrator, otherwise I’m just logging it and capturing those in a report of some sort (Email, Trap, Splunk Dashboard/Alert, etc).
As mentioned in the other thread, I’m happy to try and answer any questions that you may have, but I would ask that you post a new question/thread so not to be off-topic to the original post of this one.
Replying to older posts with a new question unrelated to the original poster’s inquiry will probably have a different resolution and can become confusing for future readers and can have the side effect of on-topic discussion go unanswered. (These symptoms can already be seen on the forums with thread becoming orphaned or individuals trying to grab the attention of recently active users).