The integration of SAS 9 and Viya has steadily evolved over the past couple of years and has become quite robust. Several articles have been written to show the configuration required to access CAS from SAS 9.4 clients using SAS/CONNECT as well as the using SAS 9.4 as a direct CAS client. However, questions regarding SAS 9.4 clients communicating with SAS Viya and CAS services continue to surface. As a result it seemed like a good idea to briefly revisit this topic.
Many new SAS Viya customers are existing SAS 9 customers. They are familiar with the SAS 9 client interfaces and want to understand how to configure the environments to talk to each other. This can be confusing at times as some of the component names are the same and others are different. In addition the requirements change depending on the levels of software. As a result these topics raise questions.
Here are some of the questions that have been asked.
Before we dig into the questions, it is advised that you review the following articles as they will provide a partial picture of configuration required to access CAS from various clients.
Configuring Enterprise Miner to chat with CAS - As you may have guessed, this article guides the administrator through the steps to enable EM to talk to CAS
Upload Data to CAS using EG Tasks - This article explains how SAS/CONNECT may be used when using the "Upload to CAS" task when the SAS 9 environment is at 9.4M5 and the Viya environment doesn't include SAS/CONNECT.
CAS and SAS Data Integration Studio 4.903 (on SAS 9.4M5) - This article walks the user through the steps of configuring a SAS 9.4M5 environment to enable SAS DI Studio to communicate with CAS. It also references a prior post that walks the user through configuration to use SAS/CONNECT with SAS DI Studio transforms.
Some of the information in those articles is repeated here to consolidate and highlight the key points.
It may be helpful to have the major related ship events handy.
Select any image to see a larger version.
Mobile users: To view the images, select the "Full" version at the bottom of the page.
As you've probably figured out, "it depends".
If your customer's SAS 9.4 environment is at SAS 9.4M5 or later and they want to interact with a SAS Viya 3.3 or later deployment then it is not necessary to have SAS/CONNECT in either environment. The built-in CAS integration capabilities of SAS 9.4M5 enable the user to communicate directly from a CAS client.
If your customer's SAS 9.4 environment precedes SAS 9.4M5 and they want to communicate with a SAS Viya environment, then SAS/CONNECT will need to be available in each both environments if they intend to upload, download and analyze data within CAS from a SAS 9 client.
Therefore it stands to reason that for customers at SAS 9.4M4 or earlier, it would be in their best interest to update to SAS 9.4M6. Although SAS/CONNECT has stood the test of time, the built-in integration capabilities of CAS-enabled versions of SAS 9 far exceed the added complication of configuring it to communicate with Viya.
Some of the workstation clients contains tasks that require SAS/CONNECT. For example the "Upload to CAS" task in SAS Enterprise Guide uses SAS/CONNECT in the generated code to perform the upload. So if SAS/CONNECT is not available in either environment then this task has limited value.
If SAS/CONNECT is available in the SAS 9.4M5 or later environment and not available in SAS Viya, then it is possible to initiate SAS/CONNECT sessions locally which in turn use the built-in integration capabilities to communicate with CAS. This may be of value if you want to run multiple concurrent SAS 9 CONNECT sessions asynchronously where each sessions is performing different types of work or working on unique segments of data. See the "Upload Data to CAS using EG Tasks" article listed earlier.
As alluded to in the last section, if the SAS 9 environment is as SAS 9.4M5 or later then the integration capabilities are available. However, if the deployment is from the initial release of 9.4M5 at 19w38, then fewer integration capabilities are available.
The SAS 9 maintenance level can be viewed at the beginning of a SAS log. In the following example, we see the level is "9.4 (TS1M5)". But that doesn't provide any further information. Please note that the line following the level is the site name, which in this case reflects comments added for this internal order. It turns out this order added products to the deployment at 18w21.
To gain more detail on the release you can use the SYSVLONG4 automatic macro variable to view the software release and maintenance level. In the example below the software date is Sep 13, 2017. This is the week before 9.4M5 was released at 17w38. Therefore this SAS Foundation is from the 17w38 release and would not contain all of the functionality available at 17w47.
%put &sysvlong4 ;
9.04.01M5P09132017
The following is from a SAS 9.4M6 deployment. This ship event would contain all of the most current integration updates.
%put &sysvlong4 ;
9.04.01M6P11072018
If you are familiar with the deployment registry you would find that the macro date matches the "last_port_date" in the deployment registry.
This information combined with the ship event tables shown earlier should help you identify whether it is helpful to upgrade or not.
To better understand the integration capabilities at different release and maintenance levels, see the official What's New doc.
Those Viya environments that have enabled encryption in their environment, considered a best practice, require that certificates be copied and installed in the SAS 9.4Mx environment. This is to ensure that communication between the SAS 9.4Mx client and the CAS server is encrypted. The default setting in Viya 3.3 and later versions is to enable CAS encryption. Therefore it will be necessary to copy Viya/CAS certificates to the SAS 9 environment.
An example of identifying and importing certificates in a Windows deployment was covered in the Enterprise Miner article.
If the SAS 9 client environment is on Windows then the certificates are stored in the Windows trusted store as noted above. In this case the Microsoft Management Console is used to import the certificates. Once added you should be able to view them in the MMC.
If the SAS 9 client environment is on a Unix/Linux environment the certificates are stored in the SAS trusted certificate store. The SAS Deployment Manager is used on Unix/Linux environments to add certificates to the SAS store. After they are added the updates should be visible by reviewing the following directory.
See the "Configuring 9.4 Clients to Work with SAS Viya" section of the SAS Viya 3.4 Administration Guide for steps to add certificates to a trusted store.
Some of the tasks in the desktop clients require metadata configuration. Adding metadata objects in the SAS 9 environment will allow a more seamless integration. CAS servers, CAS libraries and authentication domains are some of the key metadata objects that are typically defined. The details are beyond the scope of this post and some examples can be found in the articles mentioned earlier.
In some cases it may be necessary to define a .authinfo or _authinfo file with credentials in order to authenticate to CAS. For example, if the credentials are not added to an authentication domain then an authinfo file can be used for authentication.
One question that surfaced was related to accounts, permissions and ownership when loading data from a SAS 9 environment to SAS Viya.
The deployments involved a SAS 9 environment at 9.4M4 and SAS Viya 3.3. Since the SAS 9 deployment was 9.4M4 then integrating the two environments required SAS/CONNECT in both.
The scenario required loading data from the SAS 9 environment to a path CASLIB in the SAS Viya environment. The following steps were taken in an attempt to make this happen.
One way around this, although not elegant, is to define a secondary group and place both the sastest1 and cas accounts in the group. Then change the group ownership of the directory to the new secondary group and ensure the write bit is enabled. This will allow online sessions from Environment Manager that run as the cas account, and batch sessions to run as sastest1 account.
A better solution is to use Linux file Access Control Lists. This capability allows a system administrator to override the default permissions and ownership of files or directories. The command to manage access control lists is "setfacl".
In this scenario the initial directory was /sasdata/remote and the ownership is cas:sas. Assuming sastest1 is in the sasusers group, it will be necessary to modify the Access Control List to allow the sasusers group to read from and write to /sasdata/remote. First let's look at the permissions from the ls command before changes.
[root@intcas01 sasdata]# pwd
/sasdata
[root@intcas01 sasdata]# ll
total 0
drwxr-xr-x. 2 cas sas 6 Apr 17 15:44 remote
And let's look at the sastest1 account. Note the only group it is a member of is sasusers.
[root@intcas01 sasdata]# id sastest1
uid=2003(sastest1) gid=2003(sasusers) groups=2003(sasusers)
Check the permissions of the directory using the getfacl command. This result is the same as ls command, just in a different format.
[root@intcas01 sasdata]# getfacl /sasdata/remote
getfacl: Removing leading '/' from absolute path names
# file: sasdata/remote
# owner: cas
# group: sas
user::rwx
group::r-x
other::r-x
Next let's modify the ACL to allow all sasusers read and write access using the setfacl command.
[root@intcas01 sasdata]# setfacl -m g:sasusers:rwx /sasdata/remote
Finally review the settings again with the getfacl command. Now we see that sasusers have read/write/execute to this directory, even though the sas group is assigned.
[root@intcas01 sasdata]# getfacl /sasdata/remote
getfacl: Removing leading '/' from absolute path names
# file: sasdata/remote
# owner: cas
# group: sas
user::rwx
group::r-x
group:sasusers:rwx
mask::rwx
other::r-x
With the Access Control List updated for this directory the sastest1 account can now update this CASLIB directory. However it will not be able to modify datasets loaded by other users. This method introduces much less overhead than creating a new group and placing cas and sastest1 in it.
The items mentioned in this post identify some of the questions that have come to our attention over the past several months regarding SAS 9 and SAS Viya integration. There are many resources available to answer these questions, but sometimes the answers are not so easy to find.
If you have an experience with SAS 9 and SAS Viya integration that you feel others would find useful, please share in the comments.
Are you ready for the spotlight? We're accepting content ideas for SAS Innovate 2025 to be held May 6-9 in Orlando, FL. The call is open until September 25. Read more here about why you should contribute and what is in it for you!
Data Literacy is for all, even absolute beginners. Jump on board with this free e-learning and boost your career prospects.