SAS Viya 3.5: SAS Studio and SAS Compute Server non-functional improvements
Last November SAS launched SAS Viya 3.5. It provides our customers with new features to enhance and streamline the software's analytical capabilities. It also includes non-functional changes that are particularly interesting for architects and implementers.
This article focuses on the improvements specific for SAS Studio and its back-end server:
- Two releases of SAS Studio 5.2: (Basic) and (Enterprise)
- SAS Studio (Basic) replaces SAS Studio 4.4 in programming-only deployments.
- Both provide access to the file system and additional new capabilities.
- New capabilities for Compute servers
- New /files REST API
- XCMD support
- Servers can run under a service account
- Server processes can be reused.
SAS Studio
With the release of SAS Viya 3.5, SAS Studio has been upgraded to version 5.2. There are actually two flavors: SAS Studio (Basic) and SAS Studio (Enterprise). SAS Studio (Basic) is used in a programming-only environment, while SAS Studio (Enterprise) is used in a full environment.
Select any image to see a larger version.
Mobile users: To view the images, select the "Full" version at the bottom of the page.
SAS Studio (Basic)
SAS Studio (Basic) replaces SAS Studio 4.4 in programming-only deployments. Just as the previous SAS Studio 4.4, it is deployed as an embedded web application that does not rely on external services. It still uses the traditional SAS IOM protocol to communicate with Object Spawners and leverages SAS Workspace Servers.
This ends the similarities with the older version. In fact, the new release displays the same interface of, and is functionally equivalent to SAS Studio 5.2 (Enterprise). The obvious exceptions are all features that require interaction with other components of SAS Viya, such as microservices. Example of capabilities not available with SAS Studio (Basic) are:
- Common authentication with other SAS Viya applications
- Access to files from SAS content (SAS folders)
- Administration through SAS Environment Manager
Although SAS Studio (Basic) is intended for programming-only deployments, it is installed, configured and started also in full deployments. To avoid end users confusion on what version to use, we suggest to disable it so that only the full SAS Studio (Enterprise) remains available. For example, on RHEL 7, it is possible to stop and disable SAS Studio (Basic) with the following commands:
systemctl stop sas-viya-sasstudio-default
systemctl disable sas-viya-sasstudio-default
Then, add sas-viya-sasstudio-default to /opt/sas/viya/config/etc/viya-svc-mgr/svc-ignore so that the sas-viya-all-services command will ignore it.
SAS Studio (Enterprise)
SAS Studio (Enterprise), used within full deployments, fully integrates with other SAS Viya components (microservices, SAS Drive, SAS Launcher, SAS Compute, etc.). Starting with SAS Viya 3.5, it can leverage new back-end capabilities to access files from both SAS content (SAS folders) and the host file system.
For safety reasons, by default, each user can only navigate its own home directory. An administrator can choose to point the system to a different shared root, for example, a common project directory, or to the server root. It is also possible to completely disable the file navigation functionality:
SAS Studio (Enterprise) configuration is performed from the Configuration page of SAS Environment Manager, as explained in SAS Viya 3.5 Administration: Configuration Properties.
You can find a complete list of SAS Studio new features in the official documentation in What’s New in SAS 9.4 and SAS Viya 3.5.
Architectural diagrams of the different SAS Studio editions are available at the bottom of last year's article (based on SAS Viya 3.4) One, Two, Three SAS Studio! Enter SAS Studio 5.
Compute Server and Service
The SAS Compute Server is the back-end engine that allows clients such as SAS Studio (Enterprise) to submit SAS programs for processing using the SAS language. Clients talk to a compute server through REST calls to the Compute Service.
New files REST API
The compute service REST API now provides a new /files endpoint so that clients can access the underlying OS file system to list, create, delete, rename, copy, download, upload files and directories. This is the capability that empowers the new SAS Studio (Enterprise) file system access outlined in the previous section. Documentation of the compute REST API, including the new /files endpoint, is available on the developer.sas.com site at https://developer.sas.com/apis/rest/Compute/#computeapi.
XCMD Support
SAS Viya 3.5 introduces the possibility to enable the XCMD property, that is disabled by default. This property controls the call of OS executables from SAS code, in the form of:
- the PIPE device type in the FILENAME statement
- the CALL SYSTEM routine
- the %SYSEXEC macro
- any facility that SAS uses to execute a shell-level command
An administrator can choose to enable these XCMDs for each Compute Context using the allowXCMD property. By setting its value to true, the administrator can permit any allowed user of that context to use XCMDs. If the administrator sets the value equal to the id of a custom user group, such as powerUsers, then only the users that are members of that identity group will be allowed to use XCMDs.
The allowXCMD property can be set by editing the desired Compute context from the Contexts page of SAS Environment Manager.
Servers can Run Under a Shared Account
By default, a Compute server runs under the credentials of the user that requests the session from the client application. Starting with SAS Viya 3.5, it is possible to start a Compute server process with a service account, while still having each Compute session created with the end-user identity. This permits scenarios where end-users do not have an account on the back-end host and is similar to running SAS 9 workspace servers under a shared account after configuring token authentication.
Additional details on this configuration will be provided in another specific post.
Reusable Servers
The default SAS Compute Server life-cycle is similar in behavior to SAS 9 workspace servers. When a client requests a Compute session to submit any code, the Compute service starts a new server process, instances a new session in that process, then runs the code in the session in the form of a job. When the client has finished and decides to close its session, the server process is automatically terminated.
SAS Viya 3.5 introduces a new capability to reuse server processes, which changes this behavior.
An administrator can configure specific Compute contexts so that servers launched for that context can be reused by subsequent sessions. In practice, when a client terminates its session, the back-end server process keeps running and is immediately available for any new incoming session request. This can save same some time by avoiding the startup/shutdown of back-end processes.
To configure server reuse, an administrator sets the reuseServerProcesses property to true. This can be set by editing the desired Compute context from the Contexts page of SAS Environment Manager, just as we have seen above with the allowXCMD property.
This new setting is only valid when servers are also configured to be started under a shared service account, as explained in the previous section.
While this new life-cycle is similar to how SAS 9 pooled workspace servers or stored process servers are started and re-used, with SAS Viya Compute servers there are no pooled sessions nor concurrent sessions in the same server instance.
You can find the complete documentation about these new Compute server capabilities in the SAS Viya 3.5 Administration: Server Contexts guide.
