start portlet menu bar

HCLSoftware: Fueling the Digital+ Economy

Display portlet menu
end portlet menu bar
Close
Select Page

HCL Universal Orchestrator (UnO) is the new Cloud Native Orchestration Tool, fueling Hyperautomation. Hyperautomation is the technology trend to automate everything that can be automated.

The combination of HWA (HCL Workload Automation) and HCL UnO, available with the new bundle “HCL Automation Orchestrator Suite”, was currently recognized as a Leader inside Radar™ Report for Workload Automation and Orchestration 2023 published by EMA (Enterprise Management Associates).

Within this article we focus on the capabilities, advantages of HCL UnO and demonstrate them in an example.

The key differentiators of HCL UnO:

  • APIs & other connectors: REST APIs, Orchestration CLI
  • Orchestration Choreography: Task dependencies, Time dependencies, Calendar, Event driven and on-demand task execution, Policy driven planning, Human-in-the-loop
  • Decision Automation: Conditional dependencies, Automatic Recovery, SLA Management
  • Discovery, Modelling & Analytics: Observability, AI Data Advisor
  • UI Creation: Self-Service Catalog, No-code Job integrations
  • Conversational Capabilities: Clara (Self Service Automation)

The major main benefits of HCL UnO:

Using HCL UnO one benefits from an easy set up, scriptless and restful Jobs (“calls”), quick arranging of Jobs to Job Streams (“flows”), very fast execution of Job Streams (“flows”), with thousands of Jobs able to been triggered in a matter of milliseconds- thanks to HCL UnO’s microservices and agentless architecture.

HCL UnO also comes with a CLOUD agent where you can schedule all the remote job types. Additionally you can change the Job Stream execution time inside the the policy-driven plan which reflects instantaneously on the plan with active-active configuration!

To highlight these benefits practically, we demonstrate its properties using a specific example inside a cloud native environment. Follow this example process which was mapped and automated in HCL UnO:

The automation process begins with setting up the single Jobs, arranging them in the right order, setting up branches, exchanging data between Jobs and transforming their output to leverage them in other Jobs.

The last Job (PROCESS_ORDER) receives the result from the predecessor’s Jobs and processes the order based on inventory.

The result and successful execution inside HCL UnO resembles the following:

So, how do we get there?

It is crucial to understand that in a cloud native environment HCL UnO works completely agentless, with restful Jobs (“restful calls”) and scriptless.

One can easily exchange data between Jobs and transform their output to use in other Jobs. Job output data is combined into a single JSON file, holding the Job context. HCL UnO can query and transform information in the Job context using JSONata4Java, the Java version of JSONata, a lightweight query and transformation language for JSON data.

JSONata is used to extract relevant data that is hidden in potentially large JSON files using sophisticated queries with compact and intuitive notation. It can be applied to virtually any problem that involves querying and transforming JSON data, and is able to perform the following actions:

  1. Manipulate strings
  2. Combine and aggregate numeric data
  3. Query and extract values
  4. Create complex JSON output structures that enable complex data transformation tasks

For a greater understanding, we display three Jobs in detail to clarify how data is requested and transformed.

Let’s examine the definition of the first Job GET_NEW_ORDER:

By using the method GET we request data from the endpoint: http://${var.HOST}:3030/v1/orders/last

(Description of method GET: Get a resource from a server. The server looks for the data you requested and sends it back to you. `GET` request performs a `READ` operation.)

The result while executing the Job during the Job Stream (“Flow”) is:

Here you can see how easy it is to retrieve data from the defined endpoint.

The next Job we want to explain is GET_INVENTORY:

In this case we use method POST on endpoint: http://${var.HOST}:3030/v1/inventory

(Description of method POST: New resource on a server. The server creates a new entry in the database and tells you whether the creation is successful. `POST` request performs an `CREATE` operation.)

With ‘Body’ defined inside this Job (result of prior executed Job GET_NEW_ORDER):

(Description of JSONata: Transformation language used to transform and query JSON data.

Provides a simple but flexible syntax for filtering and transforming data in JSON format.

Here: GET_NEW_ORDER.JSONResult.items.{})

We receive the following result:

In this case, we verified that the order can be performed based on the inventory. The result shows that enough articles are “in stock”.

The last Job which is executed is PROCESS_ORDER:

With “Body” defined inside this Job (of prior executed Job GET_NEW_ORDER and GET_INVENTORY):

We obtain the following result:

Additionally, a success message is shown inside the Job log:

Job running: Restful

{

"msg": "new process completed"

}

This example shows how easy it is to define restful Jobs while using script less/low code combined with JSONata to filter and transform data. We can apply JSONata functions on any part of the Job (variables, body, host). For creating the Job Stream, the Jobs have only to be ordered in a meaningful way and linked to each other with branches – all done via “Drag n’ Drop”.

The Operator’s perspective on HCL UnO

After setting up the Jobs and Job Streams, it is not solely important that an operator is able to easily schedule them to react to business needs, but also to immediately being capable of increasing (or decreasing) the frequency of execution. HCL UnO inherits a “policy-driven plan”, which allows a scheduler to change the Job Stream execution time which reflects instantaneously on the plan.

The following picture shows the actual plan:

The ORDER_PROCESS Job Stream recently created has 4 instances on the plan for the next 24 hours.

The new policy-driven plan is designed to run autonomously with minimal user interaction while still guaranteeing full user control over the whole workload.

On the example below we have the ORDER_PROCESS Job Stream with a 6-hour frequency. Which is why we see 4 instances on the plan above.

Now let’s change the INTERVAL from 6 to 3.

Now we instantaneously have 8 instances on the plan. This optimization could be achieved through the new HCL UnO architecture and its adaptative plan. This re-evaluation process automatically runs every time a new Job Stream instance is activated or when a new Job is submitted.

Next to changing the frequency right away, there are many other parameters to schedule Job Streams as there are “Rule for non-working days”, “run cycles” (inclusive or exclusive), “calendar driven” and many more.

As you have seen in the example above, we’ll recap the main benefits of HCL UnO:

  • Easy set up
  • Scriptless & restful Jobs (“calls”)
  • Quick arranging of Jobs to Job Streams (“flows”)
  • Fast execution of Job Streams (“flows”) because of agent less architecure
  • “Policy-driven plan” (change the Job Stream execution time which reflects instantaneously on the plan).

Moreover HCL UnO is based on Active/Active architecture. That means that it scales indefinitely to dynamically adjust to the current workload. This means that HCL UnO is always available, easy to scale, fast in running workloads and with very low maintenance.

We no longer need to failover and failback components, either. Every microservice can have multiple instances running at the same time to guarantee no single point of failure exists.

If you have any questions or would like to see a live demonstration of HCL UnO, please don’t hesitate to contact us!

Comment wrap