Script Job Redeployments?

[ardobbins]

Is there a way to script job redeployments in SAS without having data integration studio? 

[JuanS_OCS]

Hello @ardobbins,

just checking where is your question focused in:

1. having DI on your development environment, then promote those scripts to other environments?
2. Or having DI, but not wanting to use DI for the interactive re-deployment functionality but on batch mode?

For the first one, there are ways, the main challenge is to get everyhing in variables that can be changed by autoexec or parsing the sas files.

For the second one, I believe you will need at least DI 4.7:

https://support.sas.com/documentation/cdl/en/etlug/65920/HTML/default/viewer.htm#p1jxhqhaz10gj2n1pyr...

http://support.sas.com/documentation/cdl/en/etlug/68225/HTML/default/viewer.htm#p1jxhqhaz10gj2n1pyr0...

[ardobbins]

Right now we have a production folder with all of our programs that are scheduled through SMC. We also have a working GIT repository. When programs are updated by our developers, they push their changes up to that working folder. We then have a script that moves the updated program over to the prodcution folder. 

Where I'm looking to automate is in this next step. Once the new program is moved over to the production folder, we have to go into SMC and find the program in the scheduler, right click, and redeploy. 

Is there anyways we can avoid having to manually go in and redeploy the job each time it is updated? 

Thanks! 

[SASKiwi · Accepted solution]

As I understand it when you redeploy a SAS batch job in SMC, SAS simply copies the job from its source folder to the batch job deployment folder as defined in SMC. You can avoid having to do this by getting your Production deployment script to copy the job into the batch job deployment folder instead.

[ardobbins]

So there is no metadata to be updated with the new program? If what you are saying is true, and I hope so! 🙂 you are correct, this seems pretty straight forward. Thank You! 

[SASKiwi]

Correct - I don't think metadata is involved here. We update our deployed batch jobs outside of SMC all the time and nothing breaks...

[JuanS_OCS]

In that case I guess both of my answers will help you 🙂

Well, not necesarity manually. If you are able to fill in a simple document or text file with the details of your branch to be promoted/deployed, you will able to script and even schedule the re-deployment/promotion of this branch.

[JuanS_OCS]

@ardobbins, @SASKiwi,

please let me interfere here. Be mindful, because otherwise you can easily corrupt your environments, and datamarts:

• DI jobs generate code and it can be copied to other environments: yes, indeed.
• But, the magic of DI jobs is that, when you deploy them, it dynamically generates in the code all your environment variables: metadata server, users, passwords, libraries, etc, etc etc, all information from the metadata of that environment.

This means that you cannot copy most of the jobs "as is". As on my earlier post, there are 2 options:

1. you copy the job, but you need to parse those variables to change the values into the actual values on the new environment (or you just call to variables on your autoexec, as alternative)
2. Or you just execute the batch jobs to automatically re-deploy the jobs you need.

Both options are, still, quite straight forward, but a bit less than just copy the .sas files.

If you have doubts, still, you can open your .sas files generated by your deployed SAS jobs and check all the connections details inside, which are dependent on each environment, and they come from the metadata.

@SASKiwi, happy to speak about this topic. If I miss something, I will be happy to learn 🙂

[SASKiwi]

@JuanS_OCS, thinking about this some more, all of our batch jobs are very simple and consist of one SAS program which uses %INCLUDE to run all other programs. I suspect that is why we can get away with copying outside of SMC. There are no LSF job designs and we don't have SAS DI Studio.