06-02-2014 03:06 PM
My company is fairly new to SAS and we're trying to use Enterprise Guide egps to replace our old automated reporting framework. So far it has gone well, but there is one component of automation that I can't seem to figure out how to implement.
I'm sure there is a way to do this, but my searching has come up empty thus far. Is there a way to halt process flow execution at any given step if that step fails(has an execution error)? Ideally, I'd want to detect that a step in a running process flow has failed and have it send an email to our team letting us know that it has. We've had much success with creating and automating process flows, but currently when execution fails they just "keep on truckin" and still send out report files that have incomplete and sometimes incoherent information. obviously this needs to be rectified.
I thank you in advance if you know of a solution.
06-02-2014 03:17 PM
Have you looked at Conditions in the process flow? Search "conditions" in the EG online help.
Conditions allow you to check something: a value in a data set, a macro variable, a prompt value -- and then take an action/branch the flow based on the outcome.
06-02-2014 03:23 PM
Thanks for the info. I have looked at these previously. In this case would I be able to check &syserr and route execution from there? It seems as though there would be a lot of extra process flow steps added using this (branching every step in case of error). Is there a way to make conditions jump to a specific Program for instance, which would send an email and then terminate execution?
06-02-2014 03:46 PM
You mention that your company is fairly new to the SAS environment. I'm delighted that you're using it...I think you'll find it's a huge productivity boost. Be sure to use these discussion groups to solicit opinions about issues, the way you did with this one.
Chris's note definitely presents the easiest option for adding error-handling.
Enterprise Guide is a marvelous development tool for SAS code, and an absolutely superb option for exploratory analytics. However, for running repeated, production systems the SAS environment has some other options you could explore.
You could turn your EG project flows into Stored Processes, and then the addition of a little bit of SAS code could implement your error-handling. This would have the advantage of making the code easily available to other users, from a variety of user interfaces.
Or, you could continue to use EG as the development environment, but then export the SAS code to a program (.sas) file, add error-handling as needed, and upload the code to a server and use automated job-submission software to run it on the server.
Both of these would remove the need to have the Enterprise Guide PC attached to the network when the code runs.
06-02-2014 04:00 PM
Thanks for the reply. Yes, I love using SAS and Enterprise Guide. I'd never even seen it until April of 2013 but having previous experience with other programming languages and reporting tools, it wasn't as much of a headache as I thought it would be. The biggest selling point is the community. Soooooo much info is available.
The alternate options you reference are intriguing, but unfortunately not possible for us at this time. It's pretty ridiculous, in my opinion, but we do not have a SAS server. We've been using the local server for everything and mapping a folder on a file server to maintain a persistent dataset library. I keep trying to explain the performance benefits of getting a dedicated server, but so far, no dice.
I will continue investigating using conditionals as Chris suggested.
06-02-2014 04:13 PM
In response to your question about SYSERR -- that's a good start. But I find that SYSERR isn't always the most reliable indicator that there is an error. For example, SYSERR could be set during a step that caused an error, but then "cleared" by a subsequent step that runs successfully. See what I mean by running this program:
proc options option=ls; run;
It's better to think about what constitutes an "error state", and then test for that. For example, are you expecting a certain data set to exist? Or to have a certain number of records? You can have a code node that tests for this condition, places the result in a macro variable, and then base the condition off of that macro value.
06-03-2014 02:30 AM
Chris, There is whole basic concept on error-handling. SAS(R) 9.4 Language Reference: Concepts, Second Edition
It is extending to checkpoint restart functionality that should give reliable processing.
Are you saying the investment SAS did in that is humbug because the error-detecting/handling is not reliable? It is a downgrade of quality.
Would it not make more sense, when this kind of issues would be noticed, to make that process of error-detecting/handling more reliable?
06-03-2014 10:31 AM
Hey, at least you guys are heading in the right direction! No harm in starting small, and then extending the environment as you become more experienced.
You're right, this community is a fantastic resource!