The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
There are many ways to invoke the RESTful services available from Enterprise Scheduler. In the examples below, the services are called by a simple Java client using the HttpURLConnection class. In addition to this method, you can also use a wide variety of third party frameworks such as the Spring Framework RestTemplate or the Apache CXF Framework.
Before writing code to invoke the REST API, one could first browse the services available via a browser. In a live Enterprise Scheduler environment, the URL where the API can be reached is as follows:
Figure C-1 REST API browser view
Clicking on the links issues a "GET" request to the API. A "POST" request to the API can also be issued from the browser by using the "Manual Commands (Post)" link.
Figure C-2 REST API Post Screen
The calls to the REST API are subjected to the same security restrictions as the same user accessing Scheduler UI. In Code Example 1 below, a call is issued to get all of the available jobs. The list of available jobs returned is determined by the username used in the API call.
The following Java client issues a GET request to the REST API. This is the equivalent of clicking on the ApiObject link as described in the REST API From Browser section. This example retrieves all of the jobs currently defined in the Scheduler environment. The username and password pair is Base64 encoded and passed to the server as the "Authorization" property.
An XML document containing a list of jobs is returned from this call.
Code Example 2 shows a POST request issued to the TES REST API. The URL for issuing a POST request is always the same: http://<hostname>:<port>/api/<DSP Name>/ post.
In the post request, the command to be executed is sent in an URL encoded string. In this particular example, a POST request is sent to insert a job into the schedule. The <id> is the id of the job. Other parameters include <startdate> - the requested runtime for the job; <vars> - local job variable overrides; <params> - local job parameter overrides; and <deps> - the Y/N value for whether or not to override the job's dependencies.
In both previous code examples, the calls establish new sessions on the server. For typical applications that make repeated calls to the REST API, the best practice is to reuse the established sessions so that the server does not create excessive number of active sessions, which eventually could cause it to run out of memory.
Code Example 3 is an extension of Code Example 1 showing the usages of a cookie for session management.
In Code Example 1, a GET request was issued to get a list of all jobs. The GET request can accept additional parameters such that the list of jobs returned can be filtered further.
If one needs to get a list of jobs that match a specific name pattern, the GET request URL can be constructed as follows:
URL url = new URL("http://www.mycompanyscheduler.com:8080/api/tes6.2/Job.getList?query=(Job.name LIKE '%name%')")
In this case a where clause ( Job.name LIKE '%name%' ) is sent. The where clause must be URL encoded. Similarly, other queries using other field names in the Job object can be constructed.
The same also be achieved using a POST request. The POST payload is below. In addition to the queryCondition , using the POST one could also specify columns needed.