Running a SAS Enterprise Guide Program from VB.NET

[Louis_Gallo_CIGNA_com]

I am trying to find a way to run an existing SAS EG program from within VB.NET. If this is possible? If it is, is there any way to pass SAS variables in before running the program? (Currently, I use Prompt Manager)

There are tons of articles on calling VB.NET tasks from within a SAS EG project, but I want to go the other way and call SAS EG passing params in from a VB.NET front end.

Any help is appreciated.

Thanks,

Lou Gallo

[FriedEgg]

http://support.sas.com/documentation/onlinedoc/guide/examples/SASGF2012/Hemedinger_298-2012.pdf

[ChrisHemedinger]

See also -- many examples posted here (associated with the paper cited by

Not Just for Scheduling: Doing More with SAS Enterprise Guide Automation - sasCommunity

And if you're interested in doing more with Microsoft .NET and SAS directly:

http://blogs.sas.com/content/sasdummy/2013/06/09/sas-client-with-microsoft-dot-net/

Chris

[Louis_Gallo_CIGNA_com]

Hi Chris,

I want to sure that I am setting my expectations right that what I am trying to do is possible.

I am trying to open an existing .EGP SAS EG project and run that from VB.NET or C#.NET. I need to set SAS variables before the actual run in SAS EG from .NET.

Most of the articles that I have seen do not reference running an existing SAS EG project, more actual SAS code.

Am I trying to do something that is not supported? If not, can you point me to any references for running an existing EGP file.

Thanks to all that responded.

(My SAS EG program works wonderfully and fast, but I trying to dress it up for any non-SAS folks that may want to use it.)

Thanks,

Lou

[TomKari]

A colleague covered a similar area at SGF 2012. Her paper is "SAS® IOM and Your .Net Application Made Easy"

Tom

[Louis_Gallo_CIGNA_com]

I am almost there. I can run my SAS project in a C# barebones program (not dressed up yet).

SAS.EG.Scripting.Aplication EGApp = new SAS.EG.Scripting.Application();

EGApp.Open("my filename","");

EGApp.Project.Run;

EGApp.Quit();

Now I am figuring out how to insert in my SAS macro variables before running it. (Augh!! So close!)

If anyone has any suggestions, it would be appreciated.

Thanks,

Lou

[ChrisHemedinger]

Lou,

I suggest something like this:

SAS.EG.Scripting.Code c =  EGApp.Project.CodeCollection.Add();

c.Server = "SASApp" /* or your sever */

c.Text = "%let macro=myval;";

c.Run();  /* or just run the project. */

Chris

[shoin]

Hi Chris this may be a dumb question, but do you need any options turned on for running VB script ?  I am not win expert and i have been asked many times.

Thank you in advance,

R

[ChrisHemedinger]

R,

Not sure what you mean by "options" - do you mean privileges?  Typically anyone can run a VB script on the local machine without additional permissions.  Trying an example script from here is probably the best proof that you're able to do what you need.

Chris

[shoin]

Thank you for the quick reply, I meant no SAS options are needed to enabled for example, xcmd? (It may be needed for other reasons but not specifically run VB scripts.)

[ChrisHemedinger]

No, no special options are needed to use VB script to drive SAS Enterprise Guide actions.  XCMD is needed only if your SAS code calls out to the operating system shell (so, using SAS to drive the Windows operating system).

Chris

[shoin]

Thank you senor!

[Peter_C]

Lou

as a "batch process with no user inputs", your EG project can retrieve values from the calling environment by reading environment variables (rather than a user selecting those values from from the prompts).

This assumes you have a way to introduce code like:

%let parameter1 = %sysget(ENV_VAR1) ;

One way (not the only way) would be to add something to the autoexec used when SAS starts. Obviously this would be "after" the EG project starts.

Rather than pick up parameters from the environment, an EG project could "proc import" the parameters from a file of name-value pairs.

I would not expect setting environment variables to be any more "sticky" than SAS macro variables.

If you need to manage re-running, that should be done within the SAS code of the project recognizing the situation.

Many of the EG projects that I use have more than one route through the project. I have to choose the start point.

How would your package achieve this?

Peter

[Louis_Gallo_CIGNA_com]

Thanks so for responding Peter. It is very strange. I use the exact convention in my SAS code to read the environmental variables I set in VB.NET code.

In VB.NET code:

System.Environment.SetEnvironmentVariable("SASSTARTINGDATE"; strStartingDate, EnvironmentVariableTarget.Process)

In SAS EG code:

%LET STARTINGDATE = %SYSGET(SASSTARTTIME);

If I try running the SAS report again within the same .NET executable session (It is a user front end for executing the SAS EG code), it still holds onto the first iteration environnmental variables and ignores the new ones. If I kill the SAS.EXE in the background, it will work fine on the second iteration. It almost seems like the first environmental variables settings got stuck to that SAS.EXE or SYSWOW64 in the background. Am I doing something not disposing of an object properly after each loop.Note that I am executing my SAS EG EGP in VB.NET in a thread, but I terminate and dispose of the thread object.

It is getting frustrating, so I may just fall back to PROC IMPORT. That will probably be less frustrating.

Any advice is appreciated.

Thanks,

Lou Gallo

[TomKari]

It sounds like you're only getting the values that the environment values have when SAS starts; I'm not enough of a Windows expert to know if this is usual behaviour, but I wouldn't be surprised. If you're good in VB.Net, you could probably code up a quick test to see if it exhibits the same behaviour. If it does, it would rule out this mechanism for inter-process communication.

Tom