First of all, I agree on keeping SAS code out of compiled macros and doing %includes. I can't tell you how many times I have seen this in the field (as a consultant) and the original source is lost.   There is no way to stop your source code from being discovered. You can compile it, encrypt it, etc. but ultimately it has to be executed. As soon as it goes to plain text for execution, it is discoverable. You can also back into the original (somewhat) using logs and logging mechanisms. The binary in the compiled file is also discoverable.    Your best bet to hide code is to use a form of service and keep the executing code on a different machine. However, that complicates the architecture.   Compiled macros are an archaic SAS storage mechanism: do not use them.  ... View more

Good for you. Thanks for the shout out as well. I would suggest that you post the basics of your PowerShell on github so others can find it.   If you want me to post it on my github, I am happy to do get something out there and give you credit.   SAS EG is probably static at this point so I don't expect changes that would make it easier. .  ... View more

That is DMS, not EG. No .NET harmed in DMS (DMS way predates .NET).  ... View more

Ok, you are preaching to the choir 😉 I have been working with SAS and .NET since .NET 1.0. There is way too much history to go over here so I will skip that. SAS is a legacy system started on mainframes. It has gone through lots of iterations but has loads of legacy aspects. You need to understand how to work with it.   IOM is how you work with SAS via COM. There are 3 types of ways for working with SAS, 2 of them matter in your case: local and IOM. If you have SAS local, the local provider is your way of interaction. IOM is then more of a licensing issue. See my code examples on how to easily get Local set up but you must have SAS installed locally, not EG. EG is a UI wrapper on SAS. It can talk locally or use IOM to communicate with a server.    IMO, you don't need to unwind EG for dlls. If the UI portion is a hindrance, you can use UiPath and RPA your way out of things. RPA will do the clickity-click for you.    For 20 years, I have hacked my way through the painful learning that it takes to get SAS to work with C#. When I have the time, I share it on github. Not everything is there but I try and put what I can there when time permits. Feel free to contact me for missing info. ... View more

SAS won't open source the code: not going to happen.   Github link:   savian-net (ALAN CHURCHILL) (github.com) ... View more

A lot of times, SAS processes are on demand. An API provides a way to pass parameters into the program as the parms are received. SAS EG is a series of Tasks chained together. Most of the time they are SAS steps, but they can be .NET steps as well (custom/built-in tasks).   In general, SasKiwi, I agree with you. If the process is an adhoc process, however, you can call it (even on a PC), with a REST API and execute the flow. Alternatively, you can just extract the flow out and execute it as a series of steps.    Normally, when I put REST APIs on SAS, it is not for EG but standalone SAS programs. Both adhoc and scheduled. Same principles should apply here. There are loads of reasons to front SAS with a .NET API. EG? Not sure but I can understand it. ... View more

For C#, SAS uses a COM component in Integration Technologies to run SAS. Code can be found at my github site (savian-net) or any of the code that Chris Hemendinger has written. Chris is the OG of C#/SAS. ... View more

Ok, that helps. So, let's explore the possibilities. As a side note, I will be releasing a WPF app on GitHub this week/next that unwinds the egp files for you. It is not open source: you can just use the utility. I can enhance as needed.    On to SAS/C# integration via an API. The way I have done it is to wrap it in a kestrel based app, install as a Windows Service, and let it always run in the background on a server. Front it with swagger (OpenAPI), and execute SAS behind the scenes. Stack the sas.exe instances in a queue and just pop the queue as a request comes in. Put it back in queue when completed. Seems complex but pretty easy actually (I have some code I can share). SAS has a start up time cost which you want to eliminate by holding it in memory. The SAS instances are very, very light so you can queue up several hundred w/o an issue. YMMV.   For executing EGP files specifically, look at how to execute EG code from the command line or using SAS Integration Technologies. I would leave that to the last, however, and get everything else in place. Get kestrel running, get swagger running, get a demo service that runs a command line of some sort. Integrate SAS at the end. ... View more

Use proc http but with a POST vs GET. See this: https://support.sas.com/documentation/cdl/en/proc/61895/HTML/default/viewer.htm#a003286808.htm ... View more

As a .NET developer myself, I understand some of the frustration. My repos on github (under savian-net) have some info and Chris Hemendinger's posts on sas.com will help. Chris is a .NET developer as well and often posts around C#/SAS/PowerShell.   What I am missing in your post is what you are attempting to do. Decompiling code to investigate is not the answer. The SAS egp file is merely a zip file with a different extension. Rename it and you can view the structure. There is no XSD for the XML files within it. However, I have figured out a lot of them using simple trial and error. Also, every release of SAS EG produces a different layout. The details of the XML files are not known outside of the EG engine. I do have a dll that parses that file but it is not in the public domain (we can discuss).   You can also produce an EG custom add-in. It depends on what you need, where SAS is located, etc. SAS is a very, very complex beast. A few tips will keep you on a narrow, focused path.    ... View more

First of all, SAS doesn't directly translate to SQL. They are different languages and different structures. Every step needs to be redone. Some SQL appears to be there but it is SAS SQL (semi-related to ANSI but its own animal).    SAS language conversion is hard. Take it one step boundary at a time. Translate, test, see if the results match. However, SAS will not translate all the way to SQL. SAS can translate between languages (ex. Python, C#) but it is very, very hard work. SQL does not have the capabilities to handle all of SAS' constructs. You have macros in there making it even more enjoyable. Good luck.    ... View more

Correct. The sas7bdat is a closely held secret by SAS. I asked for it to be released 20 years ago, and made some progress, but the idea was nixed. The only way to understand it is by deciphering the binary layout. The Python folks have a lot of it figured out but SAS is not going to help.   Your call as to whether you want to go down that route.   OleDB is the best option, ODBC is second, IMO. OleDB provides more metadata. Some things you can't get via ODBC but it depends on what you need.    ... View more

There is a python library that reads sas7bdat. Just use that. It parses the binary and doesnt rely on any db tech. ... View more

Saying that OleDB doesnt work does not provide enough info to help assess it. What error are you seeing? Also, you have ODBC as another option. ODBC is more stable than any of the options and is more widely supported. SAS tech support will tell you what they do out of the box. SAS can do a lot more than listed with creativity. ... View more

Looks like a missing semi-colon at the end of the proc means statement (before the var) ... View more