Using Play When You Have Connectors in Your Process

Wouldn’t it be great if you could confirm your process flow without cluttering your Zeebe cluster?

Camunda’s Play feature provides the ability to test your processes and see them in action using a temporary cluster just for the purpose of Play.

You can test both the flow as well as the validity and functionality of each activity in your process diagram. This is very important when it comes to confirming your outbound connectors.

In this article, we’ll show you how Camunda’s Play feature functions and how to test processes without disrupting your Zeebe cluster. You’ll learn how Play mode in Web Modeler creates a safe testing environment, how to handle variables and forms during execution, manage secrets, resolve incidents, and ultimately leverage this tool to test processes swiftly and efficiently.

Let’s get started.

What is Play and why should I use it?

Using Play mode in Camunda Web Modeler gives developers access to a Zeebe-powered playground environment. When you are testing your process, this provides an option to try out your process with no effect on your existing Zeebe cluster. It sets up a temporary cluster just for the purpose of Play.

Taking advantage of this feature can have significant value if your process has several outbound connectors. You can verify that your cluster secrets are properly configured as well as test the connector as part of the overall process.

Play can only receive information from Web Modeler and communicates with Connectors using user-defined secrets in the secret store for the Play environment.

How to use Play

While within the Implement tab in Web Modeler, you simply click on the Play button to begin the process. You will see a dialog box appear that gives you the status of creating your play environment while it is configured for you.

 

Once ready, Play is initiated by simply clicking on the “Play process” button. You will be presented with your process showing green arrows to represent the path taken by the process and blue action buttons at each step in the process to indicate that an action is required for the process to continue.

Working with process variables

If your process starts with an incoming form or depends on incoming variables, you must set those using JSON at the beginning of the process using “Set Variables.” An example of this can be seen below.

     

You will see the variables in the display along with information about when they were set and by what action. They are editable here as well so that if a mistake is made, you can make modifications to those variables during Play.

Once the variables are set, you can continue the process instance. Variables can be updated during the Play execution through forms and tasks or by editing in the Play interface.

Human tasks and forms

When the Play process encounters a human task, you will see an option to fill in the form.

This action will present the form configured for the human task allowing you to fill in the appropriate form fields.

Depending on the configuration, filling in the form may change process variable values and the course the process will take. The updated variables will appear in the lower frame of the screen.

Working with connectors and secrets

One of the most important features of Camunda Play is the ability to fully test your Connectors and verify they are working correctly. In this example, we have Connectors within a subprocess which can be displayed in Play by clicking on the magnifying glass.

The subprocess shows two Connectors – both using the UIPath RPA Connector. The blue button shows that we can invoke the connector. However, there is a note at the lower left of the screen indicating that we need to update the Connector secrets first.

Since Play uses its own temporary Zeebe cluster, any cluster secrets must be populated in this cluster for execution. By selecting “Add missing secrets” from the gray dialog box, the secrets panel is displayed for your play cluster. These secrets can be edited and saved so that they are available to the Play Zeebe cluster.

Access your process instance again using the Monitoring pane. Remember in this example, our Connectors are within the “Generate Claim Number” subprocess.  

The blue action button reflects that the Connector needs to be invoked.

In this example, the UIPath RPA Connector is launched which accesses a mainframe-like application passing information from the process to return a generated claim number – shown below as 93292.

We have a timer wait in this process before the UIPath Connector is invoked again to retrieve the generated claim number from the system.

The display will inform you if the invocation was successful or an incident occurred.

To complete this subprocess, the final UIPath RPA Connector must be invoked. Similar information is displayed about the successful completion or any incidents.

There is another Connector in this process that sends an email using SendGrid to notify the customer of a status. Once invoked, the display provides details of that invocation’s success or failure. With the success of this Connector, the email is properly generated and emailed to the appropriate recipient.

In this case, you can see that information from the process instance has been properly used to propagate the email message with required information.

What about incidents?

Up to this point, the discussion has been around a successful Play process. Let’s talk a moment to look at the Play process instance when there is an incident with your Connector.

In the process below, an incident has occurred in our SendGrid connector which can be seen by the red action information in the Play process display.

In the outlined row, it is clear that something could not be executed and this is likely because the variable policyholderEmail is not defined (highlighted in yellow). Using the “Resolve” option, you can make modifications to this task to remedy the situation.

In this example, the policyholderEmail is properly set using JSON to resolve the incident.

After making this change, you can see that the process can continue (indicated by green and no incidents) to the next stage in the process.

Play helps developers test processes quickly and efficiently

By using the Play feature provided in Web Modeler, developers can easily test processes with no effect on your existing Zeebe cluster.

This provides a mechanism for quickly going through various paths and verifying Connectors effectively.

Haven’t dived into Camunda’s Play functionality yet? Find out more over on our forum or try for yourself today!