Architecture

From a bird's eye view, the different pieces that make up a KuFlow deployment and their data flow are an important part of understanding the implemented architecture. Not all parts are of required use, their necessity will be determined by customer requirements. Basically, KuFlow exposes in an authenticated way, two services that external systems can interact with. A REST endpoint and a Temporal GRPC endpoint. It also has configurable WebHooks that are responsible for delivering asynchronous events to its systems. Client systems, Workers or other applications, are responsible for interacting with this part. Finally, the KuFlow web application is responsible for providing a secure environment with two distinct parts. One is oriented to administrators who are in charge of configuring all the processes that are implemented in the organisation, and the other is oriented to end users, who are in charge of instantiating processes and completing tasks.

REST API

The Rest API contains a set of operations that facilitate integration with other systems and expose the logic necessary for an automated system to operate on KuFlow. The available operations group different actions that can be carried out on the Processes and Tasks instances. The definition of these elements is carried out in the KuFlow web application.

An idempotent design of the operations has been carried out so that the robustness of the API is guaranteed in possible retries of actions on the same entity. In the API reference, you can find more information about the details of each operation. Furthermore, the API is conveniently versioned so that your systems can use it safely.

GRPC Temporal API

Integration with Temporal is achieved through the implementation of an external Worker that must be implemented. At this point it is important to note that there is never any communication between the temporal and the worker servers, only in the opposite direction. It is always the workers that consult the status of the Temporal server.

This approach of Workers allows you to locate these deployments on your internal network so that you can access your corporate services without being exposed to the Internet. In the same way, your data remains on your network and only the data that you want to be available in our web application will be uploaded to our KuFlow systems.

Temporal exposes a GRPC API that workers will use to open a communications channel with the server. To facilitate this integration in KuFlow we have developed a series of SDKs in various programming languages that facilitate the integration task for the developer. These SDKs, in turn, use the client libraries provided by Temporal. In our GitHub you can find examples of integration with KuFlow using the different SDKs available.

Likewise, communications between Workers and the KuFlow cloud are made with secure connections that are fully authenticated. The authentication section details the mechanisms required to authenticate to our systems.

Webhooks

In KuFlow there are different forms of asynchrony with which a external system might want to interact. For example, given the nature of human actions, it can be useful for a system to react to different actions that are triggered by a KuFlow user, such as changes in task states. Thus a external system might want to know, for example, when a task is claimed by a user.

For this, a Webhooks mechanism has been implemented that issue notifications through HTTP POST requests to an external system. KuFlow webhooks implement a mechanism that guarantees the delivery of notifications. Furthermore, each notification is delivered in order to its system so that an event Y produced in time "t + 1" is never delivered before an event X produced in time "t", so that when the delivery of the event is confirmed "X", will proceed to the delivery of the event "Y".

Web Application

The KuFlow web application offers a graphical interface where different types of users can perform and query different types of actions. It is intended for end users, administrators, organisation owners, developers and process analysts.

In a very schematic and summarised way, depending on the type of user, some of the operations that can be carried out are as follows:

• Management operations related to the organisation. Such as billing management, user configuration at all levels or other tasks such as deleting data from the organisation.
• Operations such as user management, process definition, credentials for workers, webhooks, etc. Normally in organisations, this profile is usually given to developers, business managers or process managers.
• Management of the organisation's process instances. Typically, business analysts are in charge.
• Instantiate the processes defined by the organisation and interact with tasks when and by completing the information defined through the process wizards.