Automation: running EG projects in headless mode via SSH

[js5]

Hello,

I am trying to automate our already developed SAS EG projects by starting them remotely via VBS. I have the following script developed:

' ------------------------------------------------
' ExtractCodeAndLog.vbs
' Uses SAS Enterprise Guide automation to read an EGP file
' and export all SAS programs and logs to subfolders
' There is a new subfolder created for each process flow
' within the project
'
' This script uses the Code.Text method, which will NOT include
' other "wrapper" code around each program that 
' SAS Enterprise Guide might have inserted
'
' USAGE:
'   cscript.exe ExtractCodeAndLog.vbs <path-to-EGP-file>
' EXAMPLE:
'   cscript.exe ExtractCodeAndLog.vbs c:\projects\DonorsChoose.egp
'
' NOTE: use proper version of CSCRIPT.exe for your SAS Enterprise Guide
' version.  For 32-bit EG on 64-bit Windows, use 
'      c:\Windows\SysWOW64\cscript.exe 
' ------------------------------------------------
' force declaration of variables in VB Script
Option Explicit
Dim Application
Dim Project

' Change if running a different version of EG
Dim egVersion 
egVersion = "SASEGObjectModel.Application.8.1"

' Simple error check - looking for a project file 
If WScript.Arguments.Count = 0 Then
  WScript.Echo "ERROR: Expecting the full path name of a project file"
  WScript.Quit -1
End If

' Create a new SAS Enterprise Guide automation session
'On Error Resume Next
Set Application = WScript.CreateObject(egVersion)
WScript.Echo "Opening project: " & WScript.Arguments.Item(0)

' Open the EGP file with the Application
Set Project = Application.Open(WScript.Arguments.Item(0),"")
If Err.Number <> 0 Then
  WScript.Echo "ERROR: Unable to open " _
    & WScript.Arguments.Item(0) & " as a project file"
  WScript.Quit -1
End If

WScript.Echo "  " & Project.Name & ", Project Flow"  
WScript.Echo "  " & Project.Path & ", Project Flow"  
Project.ProjectLog.Clear()
Project.ProjectLog.Enabled = True
Project.Run
Project.ProjectLog.SaveAs "\\foo\projectLog.txt"

Dim item

' Navigate the process flows in the Project object

'For Each item In Project.ProjectItems
  ' ProcessFlow is ContainerType of 0
'  If flow.ContainerType = 0 and flow.name = "autoexec" Then
'    WScript.Echo "  " & item.Name & item.Type & ", Item"  
'    flow.Run
'  End If
'Next

'Dim flow

' Navigate the process flows in the Project object

'For Each flow In Project.ContainerCollection
  ' ProcessFlow is ContainerType of 0
'  If flow.ContainerType = 0 and flow.name = "autoexec" Then
'    WScript.Echo "  " & flow.Name & ", Process Flow"  
'    flow.Run
'  End If
'Next

'For Each flow In Project.ContainerCollection
  ' ProcessFlow is ContainerType of 0
'  If flow.ContainerType = 0 and flow.name <> "autoexec" Then
'    WScript.Echo "  " & flow.Name & ", Process Flow"  
'    flow.Run
'  End If
'Next


' Close the project
Project.Close
' Quit/close the Application object
Application.Quit

It does what I want it to do when started from a Citrix session on a machine SAS EG is installed, but if I ssh into the machine and try to run it, I get the error:

Could not create object named "SASEGObjectModel.Application.8.1"

Is it because ssh is running in headless mode? Would switching to powershell help in this regard?

[ballardw]

Might want to explain what you mean by "headless mode" in this context.

I did quick search as I am not familiar with the term and the first XXX results all referred to operating drones. So I though I would ask.

[js5]

Headless means command-line only in this context, as I am logging in to the VM running SAS EG via SSH as opposed to RDP/Citrix. My suspicion is that this might be the reason for the VB Script not working, as VBS cannot create a MS Excel object via SSH either but both work when executed locally on the VM.

[Kurt_Bremser]

Why so complicated? It is much easier to run programs (.sas files) from the commandline.

[SASKiwi]

While what you are attempting is absolutely doable, I'm with @Kurt_Bremser on this one, that exporting your EG project to SAS programs and scheduling them in SAS Management Console using the Scheduling Server is far easier and requires no additional scripting at all. Another benefit is that server-based scheduling is more reliable than client-based scheduling.

[js5]

Well we already use Apache Airflow to orchestrate our other Data Engineering tasks. Running sas programs directly is a path we also consider, but the issue is how to keep the execution order in sync with the .egp files as they are being continuously developed. Running the projects via EG would achieve that for free. 

If all we have to do is Share -> Export all code in project, we could probably live with this being a necessary step for deployment. Can it be guaranteed that it produces exactly the same results as running the code from within EG?

[Patrick]

To be verified but I'm pretty sure if you export all code from an EG project then the generated .sas file will contain the code in the sequence how EG would execute it.

As an opinion:

EG scheduling is client side and certainly can help end-users to automate their "personal" tasks but I don't consider this "production level scheduling" and I wouldn't try and use EG projects for this. 

Viya's SAS Studio flow "merges" many of the advantages and "ease of use" SAS EG provides to end-users with the capabilities of development tools like DI Studio and allows for fully production worthy version control and scheduling.

It might be worth for you to plan for the future, investigate how things can work under Viya and then go for an approach under SAS9.4 that is "future proof" and will allow for as painless a migration as possible.

[Sajid01]

Hello @js5 
"It does what I want it to do when started from a Citrix session on a machine SAS EG is installed, but if I ssh into the machine and try to run it, I get the error:"
Is the same user account used in both instances?
Please make sure that the PATH variable has the same value in both cases.

[js5]

It is the same user. We tried powershell in the meantime and got pretty much the same error. It appears that the issue indeed is that graphical application like SAS EG cannot be started from a command-line-only SSH session

[SASKiwi]

If you haven't checked this out it may be well worth doing: https://communities.sas.com/t5/SAS-Communities-Library/Doing-More-with-SAS-Enterprise-Guide-Automati...

I'd still suggest pursuing server-side automation with programs exported from EG is a more robust solution. Apache Air Flow could be used in this scenario since it's already one of your tools of choice.

[Frank09]

Does the VBscript files has to be executed using Admin privilege?  If that's true, SSH connection is not possible using non-admin account to login on Windows. I have not seen SAS company any official comment on this. 

[js5]

psexec needs to be executed with admin privilege.

[Frank09]

If use public key authed login on, through SSH, VBscript can be executed directly which calls EG automation dll. Why it is necessary to use psexec? The problem is: non-admin account can't be used to run VBscript which calls EG automation dll. I think the reason maybe as you said, EG requires the admin privilege.

[js5]

It's been a while since I tried this so I do not remember exactly. The problem is not the privileges EG needs. The problem is that if you just log in via SSH, there is no GUI session active and Windows programs, such as EG, require it. If you google around, you will find that people are facing the same issues trying to run MS Excel for example.
There are two solutions I found:
- generating a scheduled task and running it
- running the script via psexec
Both of these approaches require elevated privileges as far as I recall.

[Frank09]

Thanks! It seems there is no hope to run VBscript through SSH especially when things like Excel involved.