Discover millions of ebooks, audiobooks, and so much more with a free trial

Only $11.99/month after trial. Cancel anytime.

SAS Stored Processes: A Practical Guide to Developing Web Applications
SAS Stored Processes: A Practical Guide to Developing Web Applications
SAS Stored Processes: A Practical Guide to Developing Web Applications
Ebook479 pages3 hours

SAS Stored Processes: A Practical Guide to Developing Web Applications

Rating: 0 out of 5 stars

()

Read preview

About this ebook

Customize the SAS Stored Process web application to create amazing tools for end users. This book shows you how to use stored processes—SAS programs stored on a server and executed as required by requesting applications.

Never before have there been so many ways to turn data into information and build applications with SAS. This book teaches you how to use the web technologies that you frequently see used on impressive websites. By using SAS Stored Processes, you will be able to build applications that exploit CSS, JavaScript, and HTML libraries and enable you to build powerful and impressive web applications using SAS as the backend.

While this approach is not common with SAS users, some have had amazing results. People who have SAS skills usually do not have web development skills, and those with web development skills usually do not have SAS skills. Some people have both skills but are unaware of how to connect them with the SAS Stored Process web application. This book shows you how to leverage your skills for success.


What You Will Learn

  • Know the benefits of stored processes
  • Write your own tools in SAS
  • Make a stored process generate its own HTML menu
  • Pass data between stored processes
  • Use stored processes to generate pure JavaScript
  • Utilize data generated by SAS
  • Convert a SAS program into a stored process


Who This Book Is For

SAS programmers looking to improve their existing programming skills to develop web applications, and programming managers who want to make better use of the SAS software they already license

LanguageEnglish
PublisherApress
Release dateJun 6, 2020
ISBN9781484259252
SAS Stored Processes: A Practical Guide to Developing Web Applications

Related to SAS Stored Processes

Related ebooks

Enterprise Applications For You

View More

Related articles

Reviews for SAS Stored Processes

Rating: 0 out of 5 stars
0 ratings

0 ratings0 reviews

What did you think?

Tap to rate

Review must be at least 10 words

    Book preview

    SAS Stored Processes - Philip Mason

    © Philip Mason 2020

    P. MasonSAS Stored Processeshttps://doi.org/10.1007/978-1-4842-5925-2_1

    1. Introduction

    Philip Mason¹ 

    (1)

    Wallingford, UK

    SAS has been utilized by programmers for more than four decades. To keep up with the ability to retrieve, edit, modify, and report on nearly any type of data from anywhere, SAS has built SAS Stored Processes. Although you can find information about Stored Processes in the SAS documentation on the SAS site, this book focuses on helping programmers utilize the SAS Stored Process Web Application to create amazing tools for your end users.

    Background

    When I started using SAS in 1985 on IBM mainframes, I was using SAS 82.5 – in the days before SAS started renumbering its products into the series we know today. We used terminals connected to the mainframe and could write a program that was either run interactively or saved and run in batch. The output produced was basic by today’s standards and was effectively static output that was printed out and handed to users. If changes were needed, we would edit the programs and re-run them.

    Obviously, SAS has evolved over the decades, adding more and more features that are useful in processing data into information and delivering it to users. Now you can access data anywhere, process it, and display it in almost any way. The following are just a few of the innovations in SAS over the years that have occurred since I started using SAS:

    SAS/AF lets us produce applications which run in the SAS environment and are very flexible. There are now many people porting their old AF applications to Stored Processes running in a web browser.

    SAS/IntrNet enables a web browser to prompt users for information before using that to customize results of programs. Changing these old programs to Stored Processes is very easy.

    ODS lets us easily provide output in a wide range of formats using the same program. For instance, we could produce HTML, RTF, and PDF from one report. This is all very helpful when using Stored Processes.

    SAS/ACCESS, together with Filename and Libname engines, lets us read and write lots of different data formats whether Oracle database, EXCEL spreadsheets, XML files, or many others. This enables Stored Processes to read and write to almost any supported system or file format.

    SAS Visual Analytics provides a complete platform for analytics visualization, enabling you to identify patterns and relationships in data that weren’t initially evident. Interactive, self-service BI and reporting capabilities are combined with out-of-the-box advanced analytics so everyone can discover insights from any size and type of data, including text. Stored Processes can be used directly from VA or included in reports. You can also link to a URL, which can be running a Stored Process.

    Since SAS 8.2 came out in 2001, web applications could be used through SAS. Originally, HTML was generated from a data step, which could then be used through a web browser. Then SAS/IntrNet came along which enabled the creation of more flexible web apps. But now SAS has the SAS Stored Process Web Application – a powerful way to deliver content to a web browser. The Stored Process Web Application runs a Stored Process on behalf of a user and can deliver the output to the web browser. Stored Processes can be used in this way to build web applications. They can produce all the HTML and JavaScript needed to make a web application or just be used to produce some data needed for a table displayed.

    Some of these technologies have lasted many years and are still just as useful today as they were 20 years ago. Some of the technologies are hardly used any more (such as SAS/AF), but SAS has provided new and improved technologies in their place. Never before have there been so many ways to turn data into information and build applications with SAS.

    This book will show you how to use the web technologies that you frequently see used in impressive websites. By using Stored Processes, you will be able to build applications that exploit CSS, JavaScript, and HTML libraries, which will enable you to build powerful and impressive web applications using SAS as the back end. In the last few years, some SAS users around the world have started to do this with amazing results. This kind of approach is still very uncommon with SAS users around the world. People who have SAS skills usually don’t have web development skills and vice versa. Occasionally, people have both skills but are unaware of how to connect them with the SAS Stored Process Web Application. This book lays out the skills needed to connect all of this together.

    What’s a Stored Process?

    A Stored Process lets you write SAS that is stored on a server and use it from many places expanding on the utility of the SAS Software. A Stored Process can be executed as required by requesting applications.

    Stored Processes were introduced in SAS 9 in 2002 and are essentially just a SAS program with some metadata associated with it. Metadata is generally defined as data about data. Stored Processes are similar to the concept of a SAS macro, in that a Stored Process can also have a range of parameters associated with it; however, there is much more to a Stored Process in SAS.

    Virtually, any SAS program can be a Stored Process. Just add metadata and you can turn your SAS program into a Stored Process! As long as you define at least a few key things, such as where it will run and where the code is stored, most other things will default nicely for you. And Stored Processes can always be changed later if you want to alter any defaults, add parameters, and so on.

    There are two parts to a Stored Process:

    1.

    The SAS code, which is run when the Stored Process is executed. This might be stored within the metadata or stored elsewhere on a disk as shown in Figures 1-1 and 1-2.

    ../images/495218_1_En_1_Chapter/495218_1_En_1_Fig1_HTML.jpg

    Figure 1-1

    Stored Process with code stored in metadata

    ../images/495218_1_En_1_Chapter/495218_1_En_1_Fig2_HTML.jpg

    Figure 1-2

    Stored Process with SAS code stored on disk

    2.

    The metadata for the Stored Process which holds information about these:

    1.

    Which server it will run on, which can be either a Stored Process server or Workspace server

    2.

    Which users are allowed to run it, as well as which users can change the metadata for the Stored Process

    3.

    What parameters can be used, including any ranges, required parameters, and default values

    Web applications are a great way to provide information and functionality to users. Since they run in a web browser, it means that there is no software to be installed, which makes it easy for anyone to use them. Running from a web browser means that any devices which are able to browse the Web can initiate something to run on the web application. So, whether you want to use your web app on a mainframe, PC, Mac, or tablet, you will be able to. Remember the web app runs on a server, but you interact with it through your client. See Table 1-1 for a comparison between stored processes and workspace servers.

    Table 1-1

    Feature comparison for Stored Process vs. Workspace servers

    Stored Processes can produce output which can be sent directly to the web browser. This is called streamed output. There is a special fileref (_webout) where the Stored Process execution context can use to steam output directly to the client. In a web browser, the execution context would be the Stored Process Web Application, and it would take anything written to it and send it to the client. This is enormously flexible and powerful. It means that anything you can produce from SAS using ODS, or even a data step, can be written to a web browser.

    Stored Processes can run on SAS Stored Process servers or SAS Workspace servers; however, many customers find it helpful to use Stored Process servers since they will typically get started faster since they are shared. A Stored Process server will run under the sassrv user account (by default); however, if running on a Workspace server, it will run under the user’s account. Some customers find it useful to run on a Workspace server for security reasons. It is useful to be aware of how the servers are configured and how many multibridge connections are available of each of the defined servers. This can help in choosing the best one to use.

    Benefits of Stored Processes

    A Stored Process basically gives your SAS program the ability to run in many more places than before – not only within a SAS environment but also in other applications and all kinds of other places. The following are some reasons for using a Stored Process:

    Centralized code on server providing one version of the truth.

    The user can be prompted to enter various parameters.

    Parameters can be passed to the Stored Process so that it can be written in a very generic way.

    Code can be run on a server or grid to provide the best available environment to run the code.

    Code can be run in many places:

    Web browser

    Microsoft Office: Excel, Word, and PowerPoint

    Many SAS clients

    Windows programs using .Net connection provided

    Many programs using Java connection provided

    Web services

    Accept user input from browser or via parameters on URL

    Produce output in web browser

    Easy to use – You can use a wizard in Enterprise Guide to create a SAS program and then use a wizard to create a Stored Process from it.

    Logically separates the SAS code (what it does) from the metadata (who can run it, where it runs, etc.).

    Use the power of ODS destinations.

    Create files such as PDF, Excel, PowerPoint, and Word.

    Render files produced using various applications such as MS Word, MS Excel, PDF Viewer, and so on.

    Integrate output produced into other applications written in a range of technologies such as HTML, Java, C++, and so on.

    Produce JSON or XML files to represent data in the form required by other objects or applications.

    Use Proc HTTP or Proc STP to run a Stored Process with the Stored Process Web Application, allowing you to run a Stored Process within a Stored Process.

    Embed URL calls in emails, Word documents, or PowerPoints, so user can click a link to run Stored Process and produce some content.

    Output produced by a call can be modified in various ways by passing parameters to it, such as _odsdest or _xpixels.

    Can schedule URLs to run in windows scheduler, which could produce a package and email it to someone, for example.

    Can run from Excel, Word, PowerPoint, and many other applications, even without the Microsoft Office Add-in. It just has to be an application capable of using a URL as input.

    Integrates with many other SAS clients such as the BI Dashboard, Portal, Web Report Studio, Enterprise Miner, Visual Analytics, Visual Statistics, and even JMP.

    Integrates with many other applications such as Tableau by producing an output like a CSV and then automatically downloading it to client and into application.¹

    Other Key Features of Stored Processes

    The key thing that makes a SAS program a Stored Process is some metadata, which is defined and points to (or includes) the SAS code. If you compare a Stored Process and some SAS code that effectively are doing the same thing, you will find that the Stored Process can be run from many more places and be used in a far more flexible way. For instance, running the Stored Process via the Office Add-in could bring results into Excel, or running it with BI Dashboard could populate part of a screen.

    If your Stored Process is producing ODS output, then you need to use ODS statements. SAS has provided some great autocall macros you can use to take care of this. You simply put %stpbegin at the start of your Stored Process and %stpend at the end. There are lots of optional macro variables which can be set to alter the behavior of ODS if you use these standard macros. Or you could just code your own custom ODS statements if you want; however, if you don’t use the standard stpbegin and stpend macros provided by SAS, you might find that the Stored Process doesn’t run as you expect.

    Your Stored Process doesn’t have to produce any output. It might just produce a table in a database, copy a file, or carry out some other operation in the background. Of course, generally you will want to provide some kind of output so that you know whether the process worked or not. Your Stored Process might produce a report of some sort in HTML for display in a browser, or a PDF file, or some CSV data to be loaded by a Python program. The possibilities are endless.

    The most important fileref to know for the Stored Process programmer is _webout. It is automatically available when running a Stored Process through the Stored Process Web Application. Writing to this allows you to write directly to the web browser, which provides you with a very powerful technique that we will explore later.

    You can run Stored Processes from lots of different places within SAS, but also outside of SAS which can provide a great way to call SAS code from other applications.

    Skills Needed

    The Stored Process Web Application and/or the Stored Process service API can be used to implement web apps. An advantage of using the Stored Process Web Application is that you only need HTML and SAS skills in order to build a web application. However, if you use the Stored Process service API, then you will need Java skills in order to build your web application in Java which then calls Stored Processes via the Stored Process service API.

    SAS Products Required

    To use Stored Processes in SAS, you will need the following products as a minimum:

    SAS Core

    SAS Integration Technologies

    SAS runs across many kinds of hardware and is supported by many operating systems. For example, you could be running PC SAS on a Windows laptop or using SAS Studio from a web browser on your iPhone. However, if you want to run Stored Processes, you will need a server somewhere that you can connect to and run those Stored Processes, returning the output to you. That server needs to have the appropriate parts of SAS installed on it to enable Stored Processes to run.

    The standard way to develop Stored Processes provided by SAS is Enterprise Guide which requires Windows, as it doesn’t run on other platforms. JMP is a powerful tool that runs on Windows or Mac and can access SAS in a number of ways, including the running of Stored Processes.

    If using the Stored Process Web Application, all you need is a browser, which could be run on PC, Mac, Linux, mobile phone, or tablet.

    Summary

    We have been introduced to SAS Stored Processes in this chapter and learned some things about them:

    A stored process is basically a SAS program with some metadata that says who can run it, where it runs, and what parameters are used.

    You can use stored processes to build web applications and leverage your SAS infrastructure.

    Stored processes run either on a Stored Process server or a Workspace server.

    Stored processes work with Microsoft products, Java applications, and .Net applications and even act as web services too.

    The _webout fileref can be used to write directly back to the client using the stored process.

    Most SAS programmers can use stored processes quite easily without much extra learning involved.

    Most big SAS installations have the required software available without needing to purchase anything extra.

    Footnotes

    1

    Using HTTP headers and Open With.

    © Philip Mason 2020

    P. MasonSAS Stored Processeshttps://doi.org/10.1007/978-1-4842-5925-2_2

    2. Developing Applications

    Philip Mason¹ 

    (1)

    Wallingford, UK

    When developing applications with SAS, it is wise to keep in mind some principles and best practices to follow. If you follow these principles, then they will help to avoid many of the common problems and pitfalls that developers are confronted with. These things are much easier to implement at the start of a project rather than part way through and will provide a lot of benefits for the investment of time and effort.

    This chapter is aimed at the project manager or architect of a project, as they tend to be the person who thinks about the project as a whole. Sometimes this will be the programmer, especially for small projects. There are advantages to following these principles even with small projects, but the benefits grow as the size of the project grows in size.

    Development Models

    There are many ways to carry out development. I will briefly outline some of these now.

    Freestyle Approach

    The freestyle approach is how many untrained people develop things. It basically involves just diving in and starting to code with no planning at all. Of course, you need some idea of what you are trying to build, but that can be a sketch on the back of an envelope or a vague idea in your

    Enjoying the preview?
    Page 1 of 1