This post was kindly contributed by Business Intelligence Notes for SAS® BI Users - go there to comment and to read the full post.

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.