topic Re: Picking sas programs dynamically in SAS Programming

Picking sas programs dynamically

Ramesh_165 — Mon, 25 Jun 2018 19:50:44 GMT

Hi,

I'm trying to setup /Dev, /Test, /Prod folders (regions) in one single server to differentiate Dev, Test and Prod regions in our shop.

Is there a way to pick the .SAS program from these three different regions dynamically based on availability from a main program in an egp?

For example, below is how the programs live in the three regions.

/Dev

A.sas (calls B.sas)

main.sas (Calls A.sas)

/Test

A.sas (Calls B.sas)

B.sas (Calls C.sas)

main.sas (Calls A.sas)

/Prod

A.sas (Calls B.sas)

B.sas (Calls C.sas)

C.sas

main.sas (Calls A.sas)

If i run main.sas from /Dev folder, it should pick A.sas from /Dev, B.sas from /Test and C.sas from /Prod folder.

Any help would be greatly appreciated.

Thank you!

Re: Picking sas programs dynamically

Urban_Science — Mon, 25 Jun 2018 21:31:08 GMT

What I think you are looking for is a "Relative Path" option for EG. It can be found in EG under File>Project Properties>File References. Using this option, EG looks for the SAS programs within the folder where EG is saved and up to one folder level deeper. I use this for my projects because I use Git for source control. This way, anyone on their team can pull the project and run it without worrying about which drive letter they saved the pulled project.

The biggest challenge with using Dev/Test/Prod environments is not the SAS program file references, instead it is library references for where SAS data sets are saved to. When using Dev/Test/Prod environments, the last thing you want to do is overwrite a file in production when you are currently trying to develop something. My solution to this is to add a config file/process settings file to the beginning of the EG flow and then to update that file with the path to save/reference data sets.

I love talking about how production analytics projects should not only be source controlled, but also they should be developed with Dev/Test/Prod environments in mind. Let me know if you have any questions.

Re: Picking sas programs dynamically

andreas_lds — Tue, 26 Jun 2018 09:47:54 GMT

@Urban_Science wrote:

...

The biggest challenge with using Dev/Test/Prod environments is not the SAS program file references, instead it is library references for where SAS data sets are saved to. When using Dev/Test/Prod environments, the last thing you want to do is overwrite a file in production when you are currently trying to develop something. My solution to this is to add a config file/process settings file to the beginning of the EG flow and then to update that file with the path to save/reference data sets.

...

This problem can be partially solved by using different levels / configurations for each environment. Additionally developers should not have any access rights to production environments, preventing unwanted changes of data or code. Unfortunately all steps i can think of, aren't capable of solving all issues, e.g. if you are using libraries defined in metadata and multiple developers are working on the same project, i can see no way to prevent conflicts without using different library names and having to rename (edit code) before the project is moved to test/prod.