In our final part we will investigate how we can use Orchestrator API endpoints and Webhooks to integrate with other systems.

Once we have several robots labouring day and night in the background, as with all software, some maintenance will be required. For instance, if a job faults due to a system exception, then the developer might have to investigate the root cause, as it might indicate an underlying bug that should be rectified.

Similarly, if a queueitem in any given queue is abandoned, then it can indicate an underlying issue, either with the code itself or it can potentially indicate an infrastructure issue: if the database under the Orchestrator is filled to the brim, then some orchestrator processes will start to timeout. It could happen (and we have observed that it has happened at a few of our clients), that the job started by a ‘Set Transaction’ activity in Orchestrator runs to a timeout in the database.

It is always a good idea to maintain and archive unneeded data from the database of Orchestrator, to ensure the stability of Orchestrator.

Robots should be thoroughly tested prior to go-live, but often it is simply unfeasible to test every little corner of the process, especially all error handling, thus some issues might surface on the production environment - potentially months after go-live. Effort can be taken to avoid these maintenance tasks, but in an enterprise environment, there are always unexpected scenarios that will require the attention of either the developer or operation.

Often the business side and operation are tasked with looking out for these issues and notifying either the infrastructure team or developers through some sort of a ticketing system. Since it is manual and inefficient, this might cause delays.

This is where Webhooks can come into play. Webhooks are a bit like a newsletter sent out by Orchestrator to the given endpoint or we can think about it as a notification of some sort.

If a certain event happens in Orchestrator, an API call is sent out to the configured endpoint. If this endpoint is a ticketing system directly, then we could potentially generate a ticket automatically for the above-mentioned issues, automating ticket creation and removing the inefficient manual part from the process of ticketing altogether.

Orchestrator API endpoints can allow smooth integration with various systems (workflows or microservices).

If a process must be triggered from a workflow, then the workflow could potentially send the input to the /odata/Queues/UiPathODataSvc.AddQueueItem endpoint, creating a queueitem directly. If the job attached to the queue itself is triggered by a queuetrigger, then Orchestator will commission a robot as soon as one becomes available to handle the tasks that were created in the queue, hence we can trigger a robot run as part of any workflow if needed.

Similarly, if there is a company wide policy that would require all processes to seize for a certain timeframe (due to a Go-Live or something similar), then the job schedules can de directly modified via the Orchestrator API-s. Even schedule calendars can be updated /odata/Calendars({key}), which will determine if the job starts at the given point in the future.

We have discussed how Webhooks can be used to integrate with a ticketing system as an example of how this Orchestrator functionality can be used for integration. Then we have discussed how a process can be smoothly integrated into a workflow as another example. As we can see, all of these functionalities are in a sense just tools that we can creatively use to enhance integration with all other systems within the organisation. Often most people are unsure of how to integrate Orchestrator or their processes with other IT solutions and to them the best thing I can advise is what an enterprise architect has put perfectly: “If we have it, let’s use the tool. Shall we?”