BookmarkSubscribeRSS Feed

Revisiting SAS 9 and SAS Viya Integration

Started ‎07-23-2019 by
Modified ‎07-23-2019 by
Views 4,216

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.

Intro

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.

  • Do I need to use SAS/CONNECT to communicate with SAS Viya and CAS from SAS 9?
  • How do I know if I have built-in integration in SAS 9?
  • Depending on the platform, where do I load the certificates for encrypted communication with CAS?
  • How do I get around a permissions issue when CAS sessions started via SAS/CONNECT run under the SAS/CONNECT account but the CAS path directory is owned by the cas account?

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.

 

mdt_46_sas9int_05.png

Select any image to see a larger version.
Mobile users: To view the images, select the "Full" version at the bottom of the page.

 

mdt_46_sas9int_07.png

Do we need SAS/CONNECT?

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.

Desktop Clients and SAS/CONNECT

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.

How do I know if I have built-in integration in SAS 9?

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.

 

mdt_46_sas9int_01.png

 

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.

 

mdt_46_sas9int_02.png

 

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.

Do I need the certificates from the Viya/CAS environment?

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.

Where are the certificates stored?

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.

 

mdt_46_sas9int_03-1024x339.png

 

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.

 

mdt_46_sas9int_04.png

 

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.

Do I need to take any special action to use built-in integration in addition to adding certificates?

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.

A possible scenario to consider

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.

  • The account used in both environments was sastest1 with matching credentials
  • The directory for the CASLIB was created by the sastest1 account on the CAS controller (e.g. /sasdata/remote)
  • Logged on to Environment Manager as sastest1, an administrator, and attempted to create the CASLIB
  • This failed because the CAS session runs as the cas account and it did not have permissions to access the directory
  • Changed ownership of the directory to cas:sas and was able to create the CASLIB
  • Then from the SAS 9 environment a SAS/CONNECT session was initiated to the SAS Viya environment and this session started a CAS session
  • The CONNECT session attempted to upload data to the new CASLIB, but was unable because of permissions
  • The CAS session started by the CONNECT session was started as the user account, sastest1, and not the cas account. Therefore it did not have permission to update the directory specified for the CASLIB

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.

Final Thoughts

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.

Version history
Last update:
‎07-23-2019 11:42 AM
Updated by:
Contributors

SAS Innovate 2025: Call for Content

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!

Submit your idea!

Free course: Data Literacy Essentials

Data Literacy is for all, even absolute beginners. Jump on board with this free e-learning  and boost your career prospects.

Get Started

Article Tags