Add Profile SAS 9.4 (SASPy)

[ShuguangSun]

Summary
Add profile SAS 9.4 (SASPy) which uses Python and SASPy for those users who have python/saspy but not ITC in the target machine.

In order to use this connection type, you'll need to have Python and SASPy installed locally (the machine VS Code is installed on) or remotely (if you are using VScode remote development). SASPy fully supports connection methods of STDIO (Unix only), SSH, IOM (Remote and Local) and HTTP, and partially supports connection method of COM. You can visit the following link to find out how to install SASPy and how to configure it.

This work is mainly based on the ITC profile or mimic it.

Testing

Tested under

• SASPy and local SAS 9.4 in Windows
• Remote SASPy and SAS 9.4 in Windows server vis VScode remote SSH development
• SASpy and remote SAS 9.4 (windows server) via IOM

[smorrisj]

@ShuguangSun thank you for this contribution! The maintainers team discussed this morning, and some questions come to mind. Overall, what is the motivation behind contributing this PR? Are there missing connection methods that you would like to see in what we currently offer in the extension?

Overall, it seems like the main benefit of this contribution, would be that python offers an operating system agnostic way to use the connection providers that saspy supports (except for COM), but wanted to see if there were additional motivations? We already support many of the connection methods that saspy does, the main difference is that our IOM and COM (COM is really IOM without java) implementation has a current requirement on ITC, which binds us to windows support only.

In this approach, this would require users to install python, configure it, and then install saspy, and setup a configuration profile for it, in addition to setting up the extension's saspy connection profile. Saspy is mainly targeted at programmers that want an api level of direct access to execute SAS code. I'm concerned that requiring end users to successfully configure saspy as an additional setup would introduce un-necessary friction, that could otherwise be mitigated, if we were to directly add support for additional connection providers directly to the extension, versus going through an additional python adapter.

For the initial IOM research, we created a prototype that uses java and grpc to broker requests between the IOM jars and the extension itself, where the extension had a compact grpc client that could call the "remote" functions on the local server. While it offered an operating system agnostic way to interact with SAS on the client side, it introduced an external requirement on java, in addition to having a technical requirement that the IOM jars are present on a classpath when the tiny grpc server spins up.

Apologies for the long-winded comment. User feedback is important to us. We'd like to iterate on this discussion to hone in on details before deciding to accept or reject it.

[takikadiri]

Hi, thank you for the amazing works provided in the sas-extension and saspy ! I'm adding our feedback here regarding SAS 9.4 profiles.

We've a python-first linux dev environment based on a remote vscode that we access through a web url. We use saspy to query SAS Data through IOM, but we want to go further by using vscode as a SAS IDE.

Currently no connection type works for us, maybe this saspy based connection or the prototype that you mentioned would solve this problem as they are operating system agnostic.

Looking forward for it !

[ShuguangSun]

I have a situation that not have the priviliege to install ITC on my machine, but I can use python/saspy which is similar to @takikadiri . This is the trigger of my idea of SASPy Profile.

SASPy is more mature than the sas extensition and have more functions. Fore example, it provides a run script mode (batch mode), and like SAS EG ans studio, if we want to extend the extenstion a background run function, it can be easyly implemented in SASPy profile.

Python and SASpy provide easier way to handle log and output as they have done the dirty work. For example, to fetch the results, IOM/COM profile needs to identify local or remote directiory and the , howeer, saspy can just need to return the ll['LOG'] and writhe ll['LST'] to file. It might work for download data (as csv) as well.

Python and SASPy provide some modeling functions which looks like those task and applicable procedure in SAS EG and Studio. It might be not in our extension's cope. However if someone else want to provide some 3rd party exentension, the modeling things in SASPy can be used.

By the way, it should be a litte faster than IOM/COM in windows box especially when there a large chunck of flush or coding convert things.

[snlwih]

Hi @ShuguangSun , @takikadiri , trying to better understand your use case. A lot of functionality in the extension has been added, but not all that functionality is supported for all connection types. Being able to maintain all configuration and connection definition information in a single location is very important, as was already mentioned earlier in this comment thread.

Instead of adding even more connection types, we'd rather enhance capabilities for existing connection types. This to keep development effort and maintenance to a minimum when more capabilities are added in the future .

I saw mention of not having privileges to install SAS Integration Technologies Client (ITC) software on the local machine. Could you elaborate on why that is? SAS Integration Technologies Client is officially supported software from SAS Institute that is installed on (almost) every Windows machine that has SAS software on it. And we have large amounts of users using this software.

I also saw mention of remote development. Am I correct in assuming that this is a setup as described in https://code.visualstudio.com/docs/remote/remote-overview? If so, then I have a number of follow up question:

• Are you saying connection type SSH in the SAS Extension does not work in this setup?
• Or are you perhaps asking for enhancing the list of capabilities supported by the SSH connection type, so it includes more of the capabilities that are already supported for connection type "iom" (remote-IOM) and/or connection type "rest" (SAS Viya)? If so, which specific capabilities? We can then create issues of type feature request for those specific capabilities.
• On which OS does the VS Code client run in your setup?

[takikadiri]

Hi @snlwih , our SAS setup doesn't allow SSH, we don't have user management at OS level. Moreover, we're using code-server as a web editor in a Linux environment. Currently i see no SAS 9.4 connection type that let us connect to a remote SAS server from a Linux environment.

The @ShuguangSun contribution seems to bring an OS agnostic connection type to SAS 9.4 (with a saspy dependency)

[ShuguangSun]

I also saw mention of remote development. Am I correct in assuming that this is a setup as described in https://code.visualstudio.com/docs/remote/remote-overview? If so, then I have a number of follow up question:

Yes.

* Are you saying connection type SSH  in the SAS Extension does not work in this setup?

I'm working with a SAS server on Windows which doesn't support -nodms. In other words, the current SSH profile only works for linux/unix kind server. For SAS server on Windows, it seems requiring meta server. As our IT can't setup the meta server well, I tried the local (COM) and IOM in vscode remote-ssh enviroment and failed.

* Or are you perhaps asking for enhancing the list of capabilities supported by the SSH connection type, so it includes more of the capabilities that are already supported for connection type "iom" (remote-IOM) and/or connection type "rest" (SAS Viya)? If so, which specific capabilities? We can then create issues of type feature request for those specific capabilities.

* On which OS does the VS Code client run in your setup?

Local Window to remote Windows.