Home > docs > getting started > Overview
A process is an execution of flows written in Concord DSL running in a project or standalone. A process can represent a single deployment, CI/CD job or any other, typically a “one-off”, type of workload.
Let’s take a look at an example:
configuration:
arguments:
todoId: "1"
flows:
default:
- task: http
in:
url: "https://jsonplaceholder.typicode.com/todos/${todoId}"
response: json
out: myTodo
- if: "${myTodo.content.completed}"
then:
- log: "All done!"
else:
- log: "You got a todo item: ${myTodo.content.title}"
When executed this flow performs a number of steps:
The example demonstrates a few concepts:
There are multiple ways how to execute a Concord process: using a Git repository, sending the necessary files in the API request, using a trigger, etc.
No matter how the process was started it goes through the same execution steps:
imports
;During its life, a process can go though various statuses:
NEW
- the process start request is received, passed the initial validation
and saved for execution;PREPARING
- the start request is being processed. During this status,
the Server prepares the initial process state;ENQUEUED
- the process is ready to be picked up by one of the Agents;STARTING
- the process was dispatched to an Agent and is being prepared to
start on the Agent’s side;RUNNING
- the process is running;SUSPENDED
- the process is waiting for an external event (e.g. a form);RESUMING
- the Server received the event the process was waiting for and
now prepares the process’ resume state;FINISHED
- final status, the process was completed successfully. Or, at
least, all process-level errors were handled in the process itself;FAILED
- the process failed with an unhandled error;CANCELLED
- the process was cancelled by a user;TIMED_OUT
- the process exceeded its
execution time limit.The runtime is what actually executes the process. It is an interpreter written in Java that executes flows written in Concord DSL. Typically this is executed in a separate JVM process.
Currently there are two versions of the runtime:
The runtime can be specified using configuration.runtime
parameter in
the concord.yml
file:
configuration:
runtime: "concord-v2"
or in the request parameters:
$ curl -F runtime=concord-v2 ... https://concord.example.com/api/v1/process
During process execution, Concord records various events: process status changes, task calls, internal plugin events, etc. The data is stored in the database and used later in the Concord Console and other components.
Events can be retrieved using the API. Currently, those event types are:
PROCESS_STATUS
- process status changes;ELEMENT
- flow element events (such as task calls).In addition, plugins can use their own specific event types. For example, the Ansible plugin uses custom events to record playbook execution details. This data is extensively used by the Concord Console to provide visibility into the playbook execution - hosts, playbook steps, etc.
Event recording can be configured in the Runner
section of the process’ configuration
object.