SAS Stored Processes: Excerpt from STP Book
We excerpted this post from The 50 Keys to Learning SAS Stored Processes.
Chapter 2: Creating Simple Stored Processes
BASE SAS gives programmers the exponential ability to query and report about data from their desktops; however, this limitation means that a user can access the data from their desktops only. As an organization’s reporting needs grow, more individuals need to quickly retrieve and analyze similar information. As a result, a small group with access to the data unintentionally becomes report gatekeepers. Other members of the organization have to talk to these gatekeepers for even the simplest piece of data.
Before you convert a SAS program to a stored process, you must consider whether the program is a good candidate for conversion. Although any SAS program can be a stored process, this does not mean that all programs should be a stored process. Programs that require user input, run on user demand, and generate output are typically better candidates than those programs scheduled to run overnight, take a long time to run or require no user modifications.
In Chapter 1, “Getting Started with Stored Processes” you learned how to register a stored process. In this chapter, you will convert an existing SAS program into a stored process and apply different prompt types to increase the scope and flexibility of a program.
Sample Scenario for Stored Process Conversion
As an example of a report gatekeeper and how a stored process solved the issue, let’s consider the following business scenario. There is a SAS program that exports returned hardware parts from an enterprise database to a spreadsheet. Each time a reliability analyst reviews a part with a high return rate, a SAS programmer adds the part number to the where statement, reruns the program, and sends the spreadsheet to the analyst. The analyst retrieves the data and begins the analysis process.
After the program was converted to a stored process, the reliability analyst could access the stored process using the web interface or even the SAS Add-In for Microsoft Office application. Within moments of selecting the desired product from a drop-down list, the analyst is able to start reviewing the results; thus, adding automation to the business process. In addition, the stored process allows the analyst to access the report faster, and the SAS programmer can continue to work on other tasks; thus, increasing the business efficiency.
SAS programs that require user input, run on demand, or require up to date output immediately are all great candidates for converting to stored processes
The program in this scenario was an excellent candidate for converting into a stored process. By using a single prompt, the stored process essentially asked the reliability analyst which product to retrieve. Because the stored process prompts the user, other reliability analysts can also use this same report, except they would have data specific to their specific needs.Download Chapter Excerpt
Learn More about SAS Stored Processes and Prompts
You can learn more tips and tricks for creating, debugging, and using SAS stored processes in the 50 Keys to Learning SAS Stored Processes book. It's a complete guide to SAS stored processes. Check Amazon for best pricing and quick shipping!
Latest posts by Tricia Aanderud (see all)
- Working with Large Prompt Population Lists - April 21, 2014
- Which population method should I use for my SAS prompt? - April 13, 2014
- SAS Office Analytics: Working with Your Inner SAS Programmer - March 12, 2014
- SAS Add-In for MS Office: Abe Lincoln Sends Glee in a Snowstorm - February 18, 2014
- #SASGF14: You’re Invited to a TweetUp! - February 10, 2014