Is it possible to create a shell script to deploy/redeploy a SAS job. General syntax or example are welcome. Also, is it possible to creating the job's respective SPK via the script itself ? Thanks
You can schedule both export and import of spk - it's documented fairly extensive.
Not sure that you by standard tool can schedule/script job deployment. Question is, why do you want to do that?
In my mind, you need to do some test/checks that the imported jobs are ok, and all necessary post-import task is performed before you put the job to production (deploy).
Instead of manually deploying/re-deploying a job, a shell script can deploy the job. In case the job is already deployed, then the script will rename the existing .SAS file i.e job_name.sas -> job_name_old_count.sas and redeploy the job to job_name.sas. Similarly for the .SPK file.
Basically i want to automate the process.
Still find it a bit "dangerous". How can you be sure that the imported met data is actually working in the new environment?
And quite often a new version is accompanied by change scripts and other manual tasks (parameter files etc). How do you automate that?
And as I mentioned, I'm not aware of any ready made function for this.
Kind of new to SAS, so i don't understand what the problem could be. When i usually run a job, i run via another script, which invokes the .SAS in the specified location. This is done via using 'SYSIN' function in the script.
Generally when we deploy/redeploy the job in DIS manually and then import it in a new environment, it works fine. Can you please explain why doing this process manually will not work ? Just wanted to know if it is possible to deploy via a script.
Again, I don't know any such functionality. and since no one else has answered, chances are that there is none. To confirm, contact your SAS representative.
Reason (which really doesn't matter if you can't automate this): during maintenance of a DW, some changes means that you need to change target table structures (adding/renaming/removing columns, indexes, keys) - manual scripts to change often needs to be developed and executed in the production environment before the updated ETL flow can be scheduled.
Also, there could be new input data, new logins etc. So there's lot of dependences that needs to checked before scheduling new/uodated jobs.
the deploy redeploy job is a DI feature and SAS(R) Data Integration Studio 4.9: User's Guide.
See: "Note: Under change management, only administrators can deploy jobs"
Change management is a process to assure you are only doing validated changes.
SAS(R) Data Integration Studio 4.9: User's Guide (Using a Command Line to Deploy Jobs) is there for doing that process automated mostly under control of a release management tool.
Yes you could implement all kind of those thing on a trial-error approach. No you should not do that for a professional approach. A higher maturity level is requiring being in control.
As there could be unintended changes in the SAS metadata your deployment will possible fail. But why would you deploy when the code is ok.
More likely you are on some SIEM approach, than go for a SIEM design and solution.
Newer versions of DI Studio (4.901+) allow this. It is documented here: http://support.sas.com/documentation/cdl/en/etlug/69395/HTML/default/viewer.htm#p1jxhqhaz10gj2n1pyr0.... Older versions had a similar but much more restrictive tool using ant.
Also see Paper 1067-2017 An Introduction to the Improved SAS® Data Integration Studio Batch Deployment Utilit...by Jeff Dyson, The Financial Risk Group, which gives a run through on how to use it.
If you are controlling the metadata import into an environment then, IMHO, there is not an increased risk in also scripting the deployment of jobs. In fact it can save human error by incorrectly selecting which jobs to redeploy.
If DI Studio is not involved, it is still possible to automatically deploy SAS jobs, defined in SMC Schedule Manager, by script as long as they are deployed to the correct job deployment folder. We actually use the build process within our Version Control tool to do this and it works well.
The SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment.
Learn how to install the SAS Viya CLI and a few commands you may find useful in this video by SAS’ Darrell Barton.
Find more tutorials on the SAS Users YouTube channel.