I have a condition in an existing application where I want to be able to detect that the database has gone away, send an email, and then exit the entire service stack without percolating back out. This is to limit the currently-topical collateral damage. I have some errors that are recoverable and some that are not.
The execSQL is wrapped in a try-catch scenario. A missing database is not actually an exception - it comes back with a value in $dbMessage. (But a missing table raises an exception…)
The message in question is detected (until a database upgrade changes it to some other text - different problem) in the TRY section, which I then terminate with an EXIT $FLOW with FAILURE. Unfortunately, it doesn’t actually exit as much as I need it to.
Sorry - that should say “… from deep WITHIN a mess of services.”
Here is how we do it.
In your case if the database is down, when you check for the message, set a variable with a value and then exit out of that flow. In the parent flow which invoked that flow, check for the returning variable value and then decide what action to take.
Hope you solve this! Good Luck!
> the TRY section, which I then terminate with an EXIT
> $FLOW with FAILURE. Unfortunately, it doesn’t actually exit
> as much as I need it to.
Just curious - what is structure of the try/catch you’re using ?
I mean, what are the three ‘exit-on’ conditions for each of the SEQUENCE steps in the try/catch block. Thanks!
VR - I tried the variable solution, but it is blown away with the rest of the pipeline before I can interrogate it.
Sonam - The wrapper sequence is Exit-on SUCCESS, the Try is Exit-on Failure, and the Catch is Exit-on DONE.
The essence of my problem it that I don’t fully understand how the failures are meant to be used. The documentation doesn’t really mention error recovery (or if it does, I haven’t found it) - it doesn’t even mention the try-catch construct, even though this is fundamental to any solution.
Clearly the Failures are meant to flow back out to the outermost service so the error handling and recovery logic can be located out in the open where it can be seen. Unfortunately, because I don’t understand it, I don’t trust it. I have done a huge number of science experiments on sequences and exits to get some idea of how they work and what they do, but I am still not fully convinced I understand how they behave under all circumstances.
The most frustrating question is - What is a flow, in the context of the Exit step? It doesn’t say. The documentation says
From: Required Specifies the step that you want to exit from.
Specify this value… To exit the…
$flow Entire flow.
Now, there is no definition that I can find in the documentation that says what a ‘flow’ is, other than that it is the name of the language. If it is the call stack of nested services that are being executed in a thread at any given moment, then Exit $flow doesn’t work, because it is being caught by my outmost sequence in the particular case I am trying to deal with. Perhaps it is a synonym for service (although the service doing the exit is about 15 calls deep, so all of the intervening services are exited too.)
Russ,
The approach I would take on this is to flow chart the logic in your code.
For each exit that you perform, I would write a message or a code in the message variable field. When you exit the child flow back to the previous calling flow, I would branch on message and take the appropriate action as needed based on the message code that you have written.
Also, when I specify message code, it can actually be a string of data that you could use in a pipe-delimited fashion:
code|message|Flow Name|action
ER-01|Something wrong happened|MyFlowName|Exit Flow To Previous
ER-02|Business Logic trapped error|MyFlowName|Exit Flow to Original Calling Flow
As far as trapping the flow names, you can do so easily using the repository.
Hope this helps.
Ray
Confirming what the other guys have written.
I was reviewing some old code – I’d come across the same problem myself earlier: For some reason, EXITs do not work within a Try block.
I fixed the problem by setting a status flag within the try block, and then checking it outside the try/catch enclosure
__Try/Catch Enclosure
|____Try
|…(EXIT does not work. Set status_flag as appropriate)
|____Catch
__Process status_flag here (EXIT works now)
Sonam wrote: “EXIT does not work.”
Do you mean it doesn’t go to the catch block?
Gee, Rob I’ve confused myself now as well. Now, I can’t find the old code I had looked up a day or so ago.
I had thought it was an EXIT from $flow and signal FAILURE that wasn’t working in the try block – but I just wrote a bit of toy code and it does work in Developer 4.6. i.e. it doesn’t go to the catch block - just thrown an exception dialog with the failure message. I could almost swear I’d seen an issue with this before – but I don’t remember it anymore.
Strange!
I too have the same experience as of Sonam…To develope an error handling architecture, I too experimented a lot with this EXIT and try-catch in wM4.6 as I was getting such inconsistent results…
But now when I see in SAP BC 4.0.1, EXIT works well as expected in try-catch. I suspect any of the patches (Fixes) applied to wM4.6 causes this inconsistency.