Comparing the SAS Job Execution Web Application, SAS Studio and jobExecution REST API endpoint
- Article History
- RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
In SAS Viya, users have multiple options for executing SAS jobs, each catering to different needs and technical proficiencies. The primary methods include the SAS Job Execution Web Application, SAS Studio, and the jobExecution REST API. Understanding the distinctions among these tools can help users select the most appropriate one for their specific use cases.
SAS Job Execution Web Application
- Access URL: https://<host>:<port>/SASJobExecution
- Purpose: Provides a web-based interface for users to create, manage, and execute SAS jobs without requiring extensive programming knowledge.
- Features:
- Supports HTML input forms and the SAS prompting interface for user inputs.
- Jobs are stored in the SAS Content Server and can be organized within folders.
- Execution results, including logs and outputs, are accessible directly through the web interface.
- Offers scheduling capabilities for jobs.
- Ideal For: Users who prefer a graphical interface to manage and run SAS jobs, especially those with limited programming experience.
Select any image to see a larger version.
Mobile users: To view the images, select the "Full" version at the bottom of the page.
SAS Studio
- Access URL: https://<host>:<port>/SASStudio
- Purpose: Offers a web-based development environment for writing, editing, and executing SAS code.
- Features:
- Provides code editors with syntax highlighting and debugging tools.
- Allows users to create and manage job definitions.
- Integrates with version control systems for collaborative development.
- Ideal For: Data scientists and developers who require a robust environment for developing and testing SAS programs.
jobExecution REST API
- Endpoint: /jobExecution/jobs
- Purpose: Enables developers to programmatically submit and manage SAS jobs using RESTful API calls.
- Features:
- Supports both synchronous and asynchronous job execution.
- Integrates seamlessly with other applications and automation tools.
- Provides detailed job monitoring, including status checks and log retrieval.
- Facilitates advanced workflows, such as job chaining and conditional execution.
- Ideal For: Developers and system integrators looking to incorporate SAS job execution into automated processes or external applications.
Practical Examples Using jobExecution REST API
The jobExecution REST API allows for programmatic control over SAS job execution. Below are examples demonstrating how to use this API.
Example 1: Submitting a Job Asynchronously
To submit a job asynchronously, you can use the following curl command:
curl -X POST "http://<host>:<port>/jobExecution/jobs" \
-H "Authorization: Bearer <access_token>" \
-H "Content-Type: application/json" \
-d '{
"jobDefinitionUri": "/jobDefinitions/definitions/yourJobDefinition",
"arguments": {
"param1": "value1",
"param2": "value2"
}
}'
This command submits a job based on a predefined job definition, passing in necessary parameters.
Example 2: Checking Job Status
After submitting a job, you can check its status using the job ID returned from the submission:
curl -X GET "http://<host>:<port>/jobExecution/jobs/<job_id>" \
-H "Authorization: Bearer <access_token>"
This will return the current status of the job, including whether it's running, completed, or failed.
Example 3: Retrieving Job Logs
To retrieve the logs of a completed job:
curl -X GET "http://<host>:<port>/jobExecution/jobs/<job_id>/log" \
-H "Authorization: Bearer <access_token>"
This command fetches the execution log, which can be useful for debugging or auditing purposes.
Key Differences
Feature |
SAS Job Execution Web Application |
SAS Studio | jobExecution REST API |
Interface | Web-based GUI | Web-based code editor | RESTful API |
User Input | HTML forms or prompting interface | Code editor with prompts | JSON payloads |
Job Storage | SAS Content Server | SAS Content Server | SAS Content Server |
Execution Mode | Primarily synchronous | Synchronous and asynchronous | Synchronous and asynchronous |
Scheduling | Built-in scheduling UI | Integration with scheduling tools | Requires integration with schedulers |
Monitoring | Web interface | Integrated monitoring tools | API endpoints for status and logs |
Use Case | Manual job execution | Development and testing | Automated and integrated workflows |
Conclusion
SAS Viya offers versatile tools for job execution, catering to a broad spectrum of users:
- SAS Job Execution Web Application: Ideal for users seeking a straightforward, form-based interface.
- SAS Studio: Suited for developers and data scientists requiring a comprehensive coding environment.
- jobExecution REST API: Best for integrating SAS job execution into automated workflows and external applications.
By understanding the capabilities and ideal use cases of each method, users can effectively leverage SAS Viya's job execution features to meet their specific needs. Even if some functionalities are pretty similar, it is better to call the REST API when integrating a job in the web interface as it provides a more flexible approach. If you want to insert the result in an iFrame, it might be easier to use the SAS Job Execution Web Application as you would technically embed the web page.
For more detailed information and additional examples, refer to the official documentation:
Find more articles from SAS Global Enablement and Learning here.
Blog to Communities: Comparing the SAS Job Execution Web Application, SAS Studio and jobExecution REST API endpoint
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Very clear, concise and practical, thanks @XavierBizoux . Maybe the Viya CLI job plugin could also be added to the scope of your comparison, or furthermore explained alongside its batch plugins counterpart to clarify which purpose they serve ?
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
@Ronan_Lincoln , thank you for the feedback and suggestion. The original scope was mainly around the user interfaces. The CLI is is another kind of beast which also uses the REST APIs behind the scenes. I will see how we can bring this comparison to the community as it deserves, I believe, an article on its own. Stay tuned!