From articles I read on the web, it is clear that data is the gold of the twenty first century. Loading, enriching, manipulating and analyzing data is something that SAS is good at. From colleagues and customers questions, it is clear that end-users are willing to display data handled by SAS outside of the user interfaces that are bundled with the SAS software.
In this series, I will shed some lights on different techniques that are available to feed web applications with SAS data stored in SAS Viya environment.
If you are new to SAS Viya world, it is important to understand the flexibility and versatility: SAS Viya is what you make of it.
This might sound like a marketing message but I can tell from experience that SAS Viya offers a variety of options when it comes to providing data to the outside world. Here are some examples:
From these examples, when talking about a web application, I'm thinking about an application that consumes information from SAS Viya and not load data or administer the SAS Viya environment.
In this first article, I will explain when to use SAS Micro Analytic Service, SAS Viya Jobs, SAS Cloud Analytic Service and SAS Compute Server. I will not cover the SAS In-Database technologies as accessing data from the supported databases is covered by tutorials on the web.
In the other articles in the series, I will demonstrate how SAS data can be consumed using simple web applications.
Let's start with covering the available options.
For those who are new to SAS Viya, the SAS Viya Jobs provide functionalities similar to the SAS Stored Processes in the SAS 9 world. A SAS Viya Job is designed to be called from the web through the SAS Job Execution web application or called directly through HTTP requests.
A SAS Viya Job has multiple components: a job definition, job prompt(s) and parameters. The job prompts are optional and can be written or automatically generated in HTML format. The prompts can also be written in the Common Task Model language but this option is not suitable for web developments. Prompts are one way to provide input to the SAS Viya Jobs. Other ways to pass data to the jobs are:
If you want more information and examples about the SAS Viya Jobs, you can have a look at the documentation.
As a SAS Viya Job can include an HTML form when you create it, it is a natural choice when it comes to building web applications. The benefit of using the SAS Viya Jobs is when you separate the development tasks for the SAS code and the user interface. SAS developers can focus on the SAS code while web developers can work on the web side.
The SAS code can be used to access all the data source types that can be accessed from SAS. These data sources include RDBMS, files located on the file system or on the web and CAS tables. This is most probably the best solution in terms of flexibility.
SAS Viya Jobs are executing SAS code on the SAS Compute Server. This is important to know because it might impact the performance of your web application. Each request to a SAS Viya Job will launch a SAS Compute Server instance. When the execution time of the SAS code is long, the startup of the SAS Compute Server might have less impact. If the SAS code needs to return results quickly like when populating a dropdown list in a form, this launch time for the SAS Compute Server might quickly become the bottle neck of your web application. Knowing this, I would recommend using the SAS Viya Jobs when the startup time is less important than the processing time.
The SAS Compute Server is the successor of the SAS Workspace Server in the SAS 9 world. It is used for example by SAS Studio to execute SAS code. Behind the scene, SAS Studio web interface uses REST APIs to interact with the SAS Compute Server. The interesting part is that these REST APIs endpoints are public. It means that a web application can call the SAS Compute Server and execute SAS code a bit like SAS Studio does. The REST APIs for the SAS Compute Server are documented.
Launching a SAS Compute Server means that a process is running for you on the server side. This process is waiting for SAS code to be executed. After a defined amount of time without activity, the process will be stopped. As a result, a web application can launch a SAS Compute Server when desired and handle the sessions depending on the web application. As a web application developer, you can decide whether a SAS Compute Server should be running for each connected user or if it should be running at the application level. You can also decide how long the SAS Compute Server session should be running and how many requests it can execute. Knowing this, using SAS Compute Server REST APIs gives a lot of flexibility and also a lot of responsibility to the web developer.
In terms of execution, the SAS Compute Server can execute any SAS code as the SAS Viya Job can do. The biggest difference between the SAS Viya Jobs and the SAS Compute Server is the way the sessions are handled. While the SAS Viya Job starts a session, executes the code and closes the session, the SAS Compute Server gives more flexibility in the session management but that means more code to handle the session lifecycle.
The SAS Micro Analytic Service is a memory-resident, high-performance program execution service. It is used to score models and decisions that are published from SAS Model Studio, SAS Model Manager or SAS Intelligent Decisioning to name a few of the solutions using MAS. The Micro Analytic Service is designed to execute many micro requests and to return responses in an efficient way.
For more information about SAS Micro Analytics Services, please refer to the documentation.
Using MAS implies that you have the correct license.
MAS is designed to execute micro requests. It can be used in any web application which needs real-time or close to real-time processing. As soon as a model or decision is published to MAS, you can send data using REST APIs and retrieve the scoring data. If you compare the usage of MAS with the SAS Viya Jobs or the SAS Compute Server, it is really business oriented in the sense that a model/decision containing the business logic should have been developed and published upfront.
In terms of web developments, calling MAS REST APIs requires the same level of web management as the SAS Viya Jobs. You can easily compare the two options as they both require some preparation work on the SAS side: creating a SAS Viya Job or building and publishing a model. As soon as the preparation work is done, getting data is a three steps approach:
The SAS Cloud Analytic Service (CAS) is an analytic engine which is designed to perform data management and statistical computation on large datasets stored in-memory. CAS data can be accessed using SAS code, natively using third-party languages like Python, Lua, Java and R and also through REST APIs.
CAS actions are used to interact with the CAS server. Each action requires specific parameters to perform the tasks. For more information about the CAS actions and their specific parameters, please refer to the CAS Action sets documentation.
Using the CAS server is the best option when your web application needs to perform statistical analyses on large amount of data. Your application will benefit from the CAS processing power especially when the tables are already loaded. Even though it is possible to load data into the CAS server on demand using the REST APIs. I would not recommend this use unless necessary for your application as the SAS UIs such as SAS Visual Analytics are optimally designed to handle this interaction. Depending on the data location and the amount of data, the load process might take time which does not provide the best experience for the end-user.
For more information about the REST APIs related to the CAS server, refer to this documentation.
The CAS server also gives the opportunity to score models and decisions that are published to it. It provides the same functionalities as MAS but it is not optimized for micro requests. If you want to score a large amount of data, I would recommend to score the data upfront and to access the resulting data. This will give a better user experience as the response time will be decreased.
SAS provides different options to provide data to a web application. In this article, I've tried to explain when to use which option. It is your choice, as a developer, to opt for one or the other depending on your web and SAS/CAS programming knowledge. There are always multiple approaches to hydrate your web application with SAS data. In the next articles of this series, I will:
Find more articles from SAS Global Enablement and Learning here.
Thanks for taking the time to put together such a comprehensive series @XavierBizoux
Hey!
Thanks for sharing, great article.
One question,
you use /SASLogon/oauth/token endpoint for generating bearer token.
How you enable user to use that endpoint?
Usually when using clients for API you need CLIENT_ID which I don't see here passed.
Or behind the scenes client is already created and defined, and LOGIN function use it in that part of code
const headers = { 'Authorization':"Basic " + btoa('gel_app:gel_secret'), 'Content-Type':'application/x-www-form-urlencoded' };
?
However, I don't see connection between gel_app and gel_secret anywhere or where are they defined on react app site.
I used last time great article:
Authentication to SAS Viya: a couple of approaches - SAS Users
To get client, and it worked.
Thanks for clarification!
Join us for SAS Innovate 2025, our biggest and most exciting global event of the year, in Orlando, FL, from May 6-9. Sign up by March 14 for just $795.
Data Literacy is for all, even absolute beginners. Jump on board with this free e-learning and boost your career prospects.