Home » General

SAS Stored Processes: Excerpt from STP Book

Submitted by on April 14, 2012 – 4:08 pm 4 Comments

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.

Ñ

#5

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!

  

The following two tabs change content below.
Tricia Aanderud is a SAS Business Intelligence and Visual Analytics consultant based in Raleigh, NC. She has written several books about SAS, presented papers at many SAS conferences, and has over 10 years of SAS programming experience. Contact her for assistance with your next project.

Tags: ,

4 Comments »