hi there,
for the jobs that i have scheduled, is it a way to show what was the code inside ? does it have any job code for refer back?
thanks
thank you @gwootton , i will explore on it . but i didn't use job definition ,i checked it is more like a stored process .
below are my use case which hope you can provide me some ideas how to refresh the latest changes into the "deployed" jobs
1. job created in jsf and pointing to a code (abc.sas) in one of project folder under sas content tree
2. added the job into a flow
3. if i change the code (abc.sas) , how do i reflect the change to the "deployed" job which i have embedded in the job flow itself?
4. if i can trace the job path/file.sas on those jobs that i seen from flows ?
Thanks
When you create a new job from a saved program, the code of the program is copied into the job request. You can see that code by pulling /jobExecution/jobRequests/<id> (the ID is found in the "general" tab of the job properties) in the "code" attribute. This means any changes to the source code (abc.sas) would not carry over to the job, so you would need to delete the existing job and create a new one with the updated code. If you have jq installed, these commands would fairly quickly show you the stored code, just need to update the user, job id and baseurl with what is correct for your environment.
baseurl=https://viya.demo.sas.com user=<user_id> read -s -p "Enter password: " pass id=<job_id> token=$(curl -s -L -X POST "$baseurl/SASLogon/oauth/token" -H 'Accept: application/json' -H 'Content-Type: application/x-www-form-urlencoded' -H 'Authorization: Basic c2FzLmNsaTo=' -d 'grant_type=password' -d "username=$user" -d "password=$pass" | sed "s/{.*\"access_token\":\"\([^\"]*\).*}/\1/g") curl -s -L $baseurl/jobExecution/jobRequests/$id -H "Authorization: Bearer $token" | jq -r '.jobDefinition.code'
Just curious, is there no option to "redeploy" an existing job? With SAS 9.4 / DI studio there is a "redeploy."
Another option, which I use in 9.4 / DI studio is to have your deployed job just be a singe %INCLUDE statement which includes the real program. So the deployed job foo is just %include foo.sas. Then you can update foo.sas any time you want, and the deployed job doesn't need to change.
I haven't tried Viya yet, but it works well on 9.4 BI server. Typically I try to write my SAS code (foo.sas) in a way that it will run when called from DI studio or EG or as a batch submission or whatever. I only create a "job" when I want to schedule something. The job is just a wrapper object that points to existing code. In fact, most of my jobs are exactly the same, because they just %include /&project/Code/&jobname..sas /source2. The value for &project and &jobname come from the name of the job and metadata path.
Gotcha, thanks. I would think redeploy would be a handy feature for the backlog.
In 9.4, looks like there were macro variables &ETLS_JOBNAME and &JOBID but for the path I had to use the &JOBID to crawl the metadata.
Are you ready for the spotlight? We're accepting content ideas for SAS Innovate 2025 to be held May 6-9 in Orlando, FL. The call is open until September 16. Read more here about why you should contribute and what is in it for you!