An execution is the path of an initial message through a flow. As the message
gets into the flow (generated by a scheduler, received by a webhook, etc.), the platform
execution ID to it. This
ID follows the message through the entire flow,
forming an execution. Also, the same
ID will be assigned to any messages caused
by this initial message in the flow. The following diagram demonstrates executions
using a webhook flow:
A client sent two messages to a webhook URL simultaneously. The message
passed by the webhook trigger to the next action without change. While processing the
message the action produced 10 more messages which passed to the following
action. In summary we can say that an external stimulus produced an execution
with 11 messages in the platform. Similarly another external stimulus
produced the execution
B with 11 messages. These two executions are separated
logically but not necessarily physically.
As for a polling flow, everything works as shown on the diagram:
The platform internal scheduling triggers a polling flow execution. The message emitted by the trigger creates a large number of messages that all belong to the same execution. In the example above 101 messages belong to the same execution as they were caused by the same trigger message. A new execution is created in the next scheduling interval.
The action receiving the data processes it in parallel or serially, and emits 10 messages for each piece of data. The last action of the flow receives 100 messages totally. All the 110 messages belong to the same execution. In the following sections, we will describe how to manage executions on the platform.
Navigate to the new executions page from the left-side menu, under the Analyze selection. Select the new Executions menu item to navigate to this new page.
The platform adds all filters to the URL code, so you can send a link to the filtered executions list to your colleague.
If new executions happened while you are browsing the list of executions, the platform
will show a notification at the top of the list, and a prompt to load them. You can dismiss
it by clicking
X. The idea is to not let new executions interfere with
your current selection. The screenshot below shows a typical view with a notification:
When you dismiss the notification above the new executions are not lost, you will get the same notification with an updated number of new executions again when new executions happen.
A Technical Note - to benefit from this page, all your custom components must use the latest Nodejs Sailor (above 2.5.4). Restart all the real-time flows after updating your components.
This filter allows you to concentrate on executions of one or more flows by selecting the check-boxes in front of their names in the drop-down menu.
You can select more than one flow if you need to debug related flows. Here you can search for the flow names to find the relevant flows faster.
Note, by deselecting all (or pressing Clear) you will return to the default view of all executions from all the active flows.
This filter allows you to list executions based on their statuses: Successful or Erroneous. By default the platform shows all executions.
This filter allows you to list executions based on their time. A drop-down menu offers a calendar view where you can customise and concentrate on the time interval when the executions have started.
Picture above shows the default view of the time interval with today’s executions.
You can select any of the predefined options like
last 15 minutes,
today, etc. Or you can customise it further using the calendar view by selecting
the starting date and end date. You can also select the starting and ending hour
of the interval.
Please Note: you must press Apply for it to take effect. You will know it worked when the check-mark shows the Custom Range and the name interval menu shows the selected interval instead of Today.
Since most of the errors inside components are related to the processed data, executions are beneficial for debugging integration flows. On the executions page you can select a single execution:
Then, for example, you can check the errors that occurred:
You can use the retry feature to re-submit or retry.
A container serves as a standardized software unit that encapsulates code and all its dependencies, ensuring consistent and efficient execution across various computing environments. Specifically, Docker container images represent lightweight, self-contained packages of software that encompass everything essential for running an application: code, runtime, system tools, system libraries, and configuration settings.
In the flows, individual containers are created for each step, allowing components to perform their designated tasks. However, it’s crucial to note that if an error occurs during the container initialization process, the affected component will be unable to fulfill its functions, consequently impacting the entire flow. To address such issues, we provide a dedicated containers page where you can access comprehensive information about the status of each container associated with a particular component in your flow.
For example, consider a scenario where your flow begins with a simple webhook component, but the execution doesn’t proceed as expected. In such cases, if you’re unsure about the root cause of the problem, your initial course of action should involve visiting the containers page and examining the status of the container responsible for the webhook component within your workflow.
Please note that numerous factors can lead to flow errors. Among the most frequently encountered issues are “Component Failed to Start” and “Component Ran Out of Memory” errors. For a more detailed insight into these errors and how to address them, we recommend referring to the dedicated articles that provide comprehensive information and solutions for these issues.
On the Containers page, you’ll encounter the following states:
To access specific information for a container, simply click on the ‘Step Name.’ On the individual container page, you will find the following details: