When you create a profile and the Machine is set to be Remote (and "Use Integrated Windows Authentication" is NOT selected), what network protocol does EG use to connect to the server? Thanks.
EG uses the SAS IOM FileService API (part of SAS Integration Technologies Client) to access the files on the remote SAS server.
If the desired result is to use Git version control on your SAS program files, we suggest storing your SAS program files in a Git repository (central origin). End-users clone that repository to their client machines, access and work on the program files in their local (cloned) Git repository, commit changes to their local Git repository, then push them back to origin. (Rather than accessing your program files directly through the SAS server, which doesn't fit the Git model.)
Register today and join us virtually on June 16!
sasglobalforum.com | #SASGF
View now: on-demand content for SAS users
The paper under below link should answer some of your questions.
http://support.sas.com/resources/papers/proceedings13/420-2013.pdf
Ok, thanks. According to the paper it uses a combination of the "SAS Integrated Object Model (IOM) and the Microsoft Component Object Model (COM)".
So my followup question is: Is there a way to mount the remote filesystem using the same protocols so that it shows up as a network drive?
I'm trying to do Git version control on the remote files and am not allowed to install any software on the remote server. I tried using SSHFS to mount the remote drive and run version control locally, but it's way to slow. Consequently, I'm trying to find a more efficient way to access the files so was wondering how EG does it.
TCP/IP is the network protocol used regardless of what authentication method you use - IWA or an explicit user account.
Sorry, maybe I misspoke. I didn't mean network protocol exactly. How is the EG client accessing the remote files? Is it something like NFS or some other protocol tunneled through SSH?
EG uses the SAS IOM FileService API (part of SAS Integration Technologies Client) to access the files on the remote SAS server.
If the desired result is to use Git version control on your SAS program files, we suggest storing your SAS program files in a Git repository (central origin). End-users clone that repository to their client machines, access and work on the program files in their local (cloned) Git repository, commit changes to their local Git repository, then push them back to origin. (Rather than accessing your program files directly through the SAS server, which doesn't fit the Git model.)
Register today and join us virtually on June 16!
sasglobalforum.com | #SASGF
View now: on-demand content for SAS users
Yes, I agree that storing the SAS program files locally matches better w/ the Git model. The issue I'm facing is an IT policy which doesn't allow users to save SAS program files locally to the client machines because they are not backed up there, so everyone exclusively develops using remote files. However, if the files are under version control and are pushed to a central repo, maybe I can get an exception to that policy.
Anyway, thank you for your answer!
It is best practice to store your EG SAS program files in a location that is both backed up and can be used with version control. A central file share can provide this. The file share could be part of your SAS application server setup or it could be elsewhere depending on how your SAS environment has been architected.
SAS Innovate 2025 is scheduled for May 6-9 in Orlando, FL. Sign up to be first to learn about the agenda and registration!
What’s the difference between SAS Enterprise Guide and SAS Studio? How are they similar? Just ask SAS’ Danny Modlin.
Find more tutorials on the SAS Users YouTube channel.
Ready to level-up your skills? Choose your own adventure.