New improvements in our SDKs for workers based on KuFlow Engine!

Published 27-09-2023 by KuFlow Team

Credits: Created by lexica.art - Edited by KuFlow

At KuFlow we continue working to make the experience of developing workers for our platform as comfortable as possible. For them we have recently introduced changes in our SDKs that greatly facilitate the tasks of configuration and orchestration of asynchronous tasks.

This time the improvements introduced cover the development of Workers with KuFlow Engine (Temporal.io based).

Improvements in the authentication and authorization mechanisms of Workers

As you know, in the workers for KuFlow that use the Temporal-based engine, the authentication mechanisms against our Temporal solution consist of a certificate and private key system, plus a signed token. Up to now, with our SDKs the implementation of this mechanism was quite easy since a ready-to-use mechanism is provided. However, the worker developer had to provide the credentials, certificates and private key to configure his worker.

Now, it is at this point that a fully transparent mechanism has been implemented for the SDK to automatically manage the provisioning of the certificates and their private key. Because, of course, authentication and authorization mechanisms are still in place.

This makes it completely unnecessary to create certificates (both public and private part) in the KuFlow user interface. Therefore, from now on, you will not have to configure any certificates in your workers. However, your certificates issued until now will be perfectly valid and will continue to work if you do not decide to upgrade to the latest versions of our SDKs for now. However, if you access the KuFlow user GUI you will notice that the certificate management section is marked as disabled.

Therefore, you should no longer specify the Mutual TLS section in your workers' settings. In the same way, we have taken the opportunity to make the configuration of the namespace of the worker unnecessary, from now on this configuration is managed dynamically by the SDK. In the following image you can see the difference in the changes in the configuration of a worker with respect to the previous version of the SDKs.

kuflow's "workflow.run" method for Python

As always, these changes are available in all our SDKs; Java, Javascript and Python.

For more information:

Authentication mechanism in KuFlow: https://docs.kuflow.com/developers/authentication
Working with Temporal based Workers using KuFLow SDKs: https://docs.kuflow.com/developers/client-integration-temporal

New asynchronous task handling

At KuFlow we differentiate between two types of tasks. Synchronous and asynchronous tasks. Synchronous tasks are performed by computer systems since there is no need to wait for inputs and outputs to perform them. However, an asynchronous task depends on different time instants for its completion. Normally this type of task is performed by a human, but it can also be performed by a computer system.

To handle this asynchrony in Temporal-based workers, until now we used to use a Temporal activity that did not finish until it was completed by an external event, usually as a consequence of the action performed by a human in the KuFlow GUI. This involved developers setting up two activity facades in workers, one for synchronous KuFlow activities and one for asynchronous ones. This meant that when orchestrating the creation of the task in the workflow, it had to call one activity or another depending on the nature of the task.

From now on, there will only be a single activity facade for KuFlow, and a single method for creating tasks, whether synchronous or asynchronous.

So how do we handle the suspension of Workflow to orchestrate asynchrony?

The solution is simple, and is a more natural way of use in the Temporal world. In these cases, when we need to wait for the task to complete in order to continue with our workflow, what we need to do is add the following line of code after invoking the task creation.

Example in Typescript

await condition(() => kuFlowCompletedTaskIds.includes(taskId));

Example in Java

Workflow.await(() -> this.kuFlowCompletedTaskIds.contains(task.getId()));

Example in Python

await workflow.wait_condition(lambda: task.id in self._kuflow_completed_task_ids)

What happens here is that we are pausing the workflow until we receive a Temporal signal that indicates that the task has been completed externally. When this happens, the worker will continue the execution of the workflow right where it was going.

As always, you can find examples of how to use this new implementation in the existing tutorials in the KuFlow documentation, in the example repositories on GitHub, and by generating example code or templates from within the KuFlow application.

For more information: