The latest version of Automation Hub is RESTful

RESTful web services operate by identifying resources through URLs, forming a crucial part of the web services landscape. At its core, REST represents an architectural paradigm that offers a multitude of benefits like scalability, performance, and adaptability to the Web services that embrace it.

When it comes to retrieving and manipulating data on the Web, CRUD operations stand out as the optimal choice. CRUD, an acronym encompassing the four most prevalent and recognized operations, simplifies the process:

• CREATE: This operation involves resource creation and corresponds to the POST method
• READ: For reading resources, the GET method is employed
• UPDATE: To modify existing resources, the PUT and PATCH methods come into play
• DELETE: As the name suggests, this operation is used to delete a resource

The RESTful plug-in has already been integrated into Automation Hub, and this blog post will showcase new and enhanced features, including:

• PATCH request
• Expanded authentication methods
• Tracking requests

To improve your Workload Automation environment, you can download the RESTful plug-in available on Automation Hub.

After downloading it, log in to the Dynamic Workload Console and go to Workload Designer. Create a new job and select “RESTful” in the database and Integrations section.

Figure 1: Job Definition page

Authentication

In the Authentication tab, you can choose between different options of authentications, if at least one of the two REST calls that the plug-in makes available needs it:

1. Basic authentication: You can choose this option if one or both REST calls need it, by manually providing the username and password.

2. Bearer token authentication: You can choose this option if one or both REST calls need it by manually providing the bearer token.

3. O-auth authentication: You can choose the options if one or both REST calls need it by manually providing the URL, the method, the refresh token if required, a client id, a client secret, and a scope.

4. Azure authentication: You can choose this option if one or both REST calls need it. You can manually provide the tenant ID, client ID, scope, and client secret.

5. AWS authentication: You can choose this option if one or both REST calls need it by manually providing the domain, the region, the refresh token, and if required, a client id and a client secret.

6. Google authentication with refresh token: You can choose this option if one or both REST calls need it by manually providing the client id, the client secret, and the refresh token.

Figure 2: Authentication page> No authentication

Figure 3: Authentication page> Basic authentication

Figure 4: Authentication page> Bearer token authentication

Figure 5: Authentication page > Oauth 2.0 authentication

Figure 6: Authentication page> Azure authentication

Figure 7: Authentication page> AWS authentication

Figure 8: Authentication page> Google authentication with refresh token

Figure 9: Authentication page> ADC Google authentication

If needed, you can provide a path to a .jks keystore with the corresponding valid password, and also verify the hostname by ticking the checkbox.

Figure 10: Authentication page> Certificate

Action

You can go to the Action tab and specify the URI associated with the service you want to call along with the method by selecting from GET, POST, PUT, DELETE, HEAD, or PATCH after providing the fields for the appropriate authentication, if necessary. Additional optional settings include:

• Query parameters: If you need to specify some query parameters, you can do that by providing, for each one, the name and the value.
• Http headers: If you need to specify some custom headers for the request, you can do that by providing, for each one, the name and the value.
• Accept: You can specify the Accept header.
• Content type: You can specify the Content-Type header. Default is application/Json.
• Body input: If you run a POST, PUT or PATCH request, you must specify a request body, and provide it inside a file for which you need to indicate the path, or directly inside a text area.

Figure 11: Action page

Advanced

After you have provided the request's information. In the Advanced tab, you can add more details.

• Output file name: If you want to save the response as a file, you can enter the path of the output in this field. Note that if you need to run a tracking request, the file will contain the response.
• JSON object result query: You can specify a JSONata query in this field if the response is a JSON and you wish to query a field from the JSON you're getting or evaluate an expression over the JSON. Notethat if you need to run a tracking request, you can only run the query against the JSON that the tracking request returned.
• Number of retries: You can specify the maximum number of retries of the first request. Default is 0.
• Retry interval: You can specify, in seconds, the retry interval for the first request. Default is 30.

Figure 12: Advanced page

Tracking

You can poll a second endpoint when the tracking is enabled till a particular condition is verified. There are three additional fields in addition to those on the Action tab that must be filled out:

• Exit condition: A boolean JSONata query representing the condition that you want to verify each time the tracking request is executed during the polling. If verified, the polling will end. This boolean query should be written with respect to a JSON context, which contains both the context of the first request (we will call it MainContext) and the context of the tracking request (we will call it TrackingRequest). Both contexts are JSON objects with the following attributes:
  • StatusCode: an integer field containing the status code of the response.
  • StatusLine: a string containing the status message associated to the status code.
  • StatusResponse: a string containing the combination of status code and status line.
  • headers: a JSON object containing response headers in the form “key”: “value.”
  • body: the response body
• Every: A field where the tracking request's retry interval must be entered. Several formats are available; they are listed in the field's label.
• Timeout: a field where the tracking request's retry interval must be entered. Several formats are available; they are listed in the field's label.
• When specifying fields for the tracking request, you have the possibility to parameterize the request, by passing values coming from the MainContext, by using JSONata queries, with the syntax %{jsonata_query}.

Figure 13: Tracking page

Submitting your job

You can submit the work at this time using the current plan. After you click Ok button then click the Submit icon. You can navigate to the Monitoring and Reporting page to view the status when a confirmation message is displayed.

Figure 14: Submitting job

Monitor page

Figure 15: Monitor page

JobLog

Figure 16: JobLog

Output properties

Figure 17: Output properties

You can download the RESTful plug-in from here.

Reconnect and Kill

In case the server goes down, the plug-in can resume the tracking activity. In particular, the plug-in recovers the exit condition which needs to be checked each time the tracking request is executed, as well as every and timeout parameters, so that it can resume the tracking without any variation.

During the reconnect, the plug-in checks it the MainContext is available: if it’s not available, then the plug-in re-executes the first REST call in order to get the MainContext, otherwise it will only restart the tracking activity.

Also, before executing the tracking request each time during polling, the plug-in checks if the agent was manually killed by the user, because if it so, then the job needs to be stopped.

Backward compatibility

The latest version of the RESTful plug-in described in this blog post is backward compatible with respect to the previous version, so if you want you have also the possibility, by using the console, to save and submit an old job definition of RESTful.