There are two kinds of Processes available in Frends:
A regular Process is used to create the integration flow functionality and active visual documentation of what that integration flow does and a Subprocess can be used to wrap smaller parts of Processes to create reusable microservices across other Processes.
This enables a Process hierarchy where you can create a Frends Process which executes a Subprocess, which executes a Subprocess and so on which can be used to create an orchestration layer and where you can isolate for example access to a specific system inside a Subprocess.
A Subprocess can be executed on any other Agent group in the same Environment as the parent Process. This functionality can for example be used to call a Subprocess on an on-premise Agent from a cloud Agent in a secure and simple way.
Note: You should only use remote Subprocesses when necessary to access remote resources. They add overhead and an additional point of failure (Service Bus is used to request and reply remote Subprocess executions) when used. See more at here.
When designing a Subprocess call you define in which Agent group the Subprocess should be executed when it is run in that Environment. This is done from under the Advanced settings on the Call subprocess shape properties:
Subprocess as an error handler
You can configure a Subprocess to be called if an error is thrown in the Process and left unhandled. See Subprocess to call on unhandled error.
Subprocess as a Trigger
Subprocess can act as a conditional trigger.
A Process always has a starting point, some functionality and an ending point. The flow of the execution is then dictated by arrows connecting different elements
These three parts of a process combined create a functional integration process which executes a desired integration flow.
The Process instances are stored in the Frends Logstore database and can be viewed through the UI.
A Process instance is the single execution of an integration process created in Frends. The Process instance is used for monitoring and auditing purposes since the Process instance stores all the information relating to the execution of that specific Process in that specific instance.
As an example when a Process is being built the view looks like this:
And when it's finished the Process instance shows the data and the execution path the process took during that execution:
Finding Process Instances
When you have built your integration process and need to find a specific Process instance tied to that Process, you can use the Process page in the UI to search and filter your Process executions to find the instance you were looking for.
A good example of this would be to for example search for specific data in the Process execution such as name of the city being processed:
Information about Process execution
Dynamic information about the execution of the Process can be obtained in the process with #process reference.
#process.agentThe name of Agent that runs the Process.
#process.agentGroupThe name of Agent Group where the Process was run.
#process.environmentThe name of Environment where the Process was run.
#process.executionidThe execution ID (GUID) of the Process instance. You can again query for a specific process execution instance by the execution GUID, to e.g., generate links to the Process in error emails. The link would be in the format
#process.idThe ID (GUID) of the Process.
#process.nameThe name of the Process.
#process.uriThe URI of the Process.
#process.versionThe version number of the Process.