HTTP Task

Introduction

An HTTP task submits an HTTP call and stores the result.

Properties

General

Attribute	Type	Description	Category
Model Id	Text	Model Id identifies the element within the process model.	The model id, name and documentation properties can be found on any element. They are used respectively to uniquely identify the HTTP task, to give it a user-friendly name and to add a free-form description.
Name	Text	The name of the element. This is the name displayed in the diagram.
Documentation	Multiline Text	The documentation attribute additionally adds a description to the component.
Request method	Selection: GET POST PUT DELETE PATCH	Request method to be used in the HTTP call: GET, POST, PUT or DELETE.	Doing an HTTP REST call always consists of a request and a response. Here the request can be configured by configured the method and the URL. For more advanced use cases, it's also possible to configure custom headers and create a body, when using methods like POST or PUT. Typically, you'll want to use an expression to dynamically populate the body in that case.
Request headers	TextArea	Line-separated HTTP request headers.
Request URL	Text	Request URL of the HTTP call. Can contain expressions, e.g., 'http://your-system.example.com/your-endpoint/${someVariable}'.
Request body	TextArea	Request body to be sent, e.g., a JSON file. You can use expressions, e.g., {'clientId': ${clientId}, 'name': ${name}}.
Response variable name	Text	The variable name in which the HTTP response is stored.	Doing an HTTP REST call always consists of a request and a response. Here the handling of the response can be configured. Use the Response variable name to store the response as a process instance variable. As these responses tend to become large, it's often a good idea to store this variable transiently, by checking the Save response as a transient variable flag. Using the Handle status codes it is possible to throw a BPMN error in case of a matching status code in the response. Similarly, the Fail status code will force a runtime exception to be thrown, which will rollback the current database transaction.
Save response as JSON	Boolean	Determines whether the response variable is stored as a JSON variable instead of a String.
Save response as a transient variable	Boolean	Determines whether the response variables should be stored as transient.
Fail status codes	Text with suggestions	List of Http response status codes to fail the request and throw a FlowableException. Code ranges can be set with an X: Example: 400, 404, 5XX.
Handle status codes	Text with suggestions	List of status codes for which the task will throw BpmnError which can be caught by a boundary error event. Code ranges can be set with an X: Example: 400, 404, 5XX. Status codes in handleStatusCodes override those in failStatusCodes when they are set in both.

Control

Attribute	Type	Description	Category
Required	Boolean	Select this option to mark the element as required (exclamation mark decorator). Required plan items must be either in the status COMPLETED, TERMINATED, or DISABLED in order for their parent stage to complete.	Check this option to mark this http task as required, which means that it needs to be in a terminal state in order for its parent to complete. Visually, the http task will get an exclamation mark icon. Required plan items must be in a termninal state (such as completed or terminated) in order for their parent stage to complete.
Completion neutral	Boolean	Completion neutral influences the plan item's parent stage completes. Plan items in the state AVAILABLE may prevent the parent stage (or case) from automatically completing. By checking this property, the plan item will behave neutral with respect to the completion of the parent container.	Completion neutral influences the plan item's parent stage completion. Normally, plan item instances in the state available may prevent the parent stage (or case) from automatically completing. By checking this property, the plan item will behave neutral with respect to the completion of the parent container (i.e. it will not stop the completion).
Manual activation	Boolean	Select this option to mark the element to have Manual activation (right arrow 'play' decorator). Plan items with Manual activation move from state AVAILABLE to state ENABLED once they trigger. A plan item in state ENABLED exposes an action button that allows the user to manually start the plan item.	A manual activated http task is not automatically activated when its parent stage becomes active. Instead, the http task plan item instance will be in the available state, until the user manually uses the action to activate it, at which point the http call will be done.
Manual activation name	Text	Define the name to be used for the manual activation trigger.
Manual activation icon	Icon	Define the icon to be used for the manual activation trigger.
Manual activation priority	Integer	The priority for the Manual activation action
Manual activation permission groups	Group Selection	Define the groups which have access to the manual activation trigger.	Advanced configuration for manual activation. The permission groups allow to define which groups and the permissions users allow to define which users can use the action to manually activate the http task plan item instance.
Manual activation permission users	User Selection	Define the users which have access to the manual activation trigger.
Manual activation channels	Text	Define a list of channels to expose the manual activation action.
Start form	Reference	An optional form shown when the event listener is manually activated.	The form that is shown when the action to manual activate the http task is used. If there is no form, the human task will immediately be activated.
In same deployment	Boolean	Set it to true if the referenced definition should be referenced from within the same app deployment. Set it to false to always use the newest definition.	The Same deployment flag is used to indicate that the manual activation form model that is used is part of the same app deployment package as where the current CMMN model is in. If unchecked, the latest version is used which can come from an app that is deployed at a later point in time.
Validate start form fields (server-side)	Boolean	If the start form is submitted and validate form fields expression evaluates to true, form fields are validated on the BE side according to the form model restrictions.	If the form is submitted and the flag or expression on the left-hand side evaluate to true, the form fields will be validated on the server-side according to the form model restrictions.

Repetition

Attribute	Type	Description	Category
Repetition	Boolean	Select this option to mark the element as repeatable (fencemark decorator). Repeatable plan items may exist more than once at run-time, each having their own life-cycle.	An http task can be repeatable, in which case multiple plan item instances will be created for the same http task plan item, resulting in multiple http calls. The repetition can be an expression, and new instances are created as long as the expression resolves to true. This can be limited using the Max instance count. The Repetition counter variable is a local variable with a value incremented by one for each new plan item instance created. Alternatively, a Collection variable can be passed which leads to a plan item instance per element in the collection. The element can be captured in a variable using the Element variable and its index in the collection in the Element index variable.
Repetition counter variable	Text	Name of the repetition counter variable.
Don't create repetition counter variable	Boolean	Enable this flag to prevent the creation of the repetition counter variable. When a variable aggregation is defined, this flag will be ignored and a repetition counter variable will be created.
Max instance count	Selection: unlimited one	Defines the maximum number of instances for repetition. Note that this does not mean there can be only one instance ever in the lifetime of a case instance, this will limit the instances each time when the repetition is evaluated (for example when an entry sentry evaluates to true to re-enter a stage or plan item).
Collection variable	Text	Variable to be used as the collection for the repetition.
Element variable	Text	Variable that will be used to store the current item value for the repetition.
Element index variable	Text	Variable that will be used to store the current index value for the repetition.
Variable Aggregations	List		When having multiple instances of this http task, there is often a need to create an aggregation of the variables created and/or updated in each instance. With variable aggregation, a JSON variable can be created that after all instances have been completed contains the summary of all the used variables. This is needed because typically variables are persisted locally, to avoid clashes on the process instance level. Alternatively, an 'overview' variable can be created while the instances are still unfinished. Each aggregation consists of one or multiple definitions that map instance variables of one instance to the single aggregation variable.

Details

Attribute	Type	Description	Category
Request body encoding	TextArea	Encoding of the request body.	Configures the encoding if the body of the request, if set.
Request timeout	Integer	Request timeout in milliseconds.	The amount of time in milliseconds that the runtime execution engine will wait for the HTTP call to receive a response. Defaults can be configured on the Flowable server configuration level.
Disallow redirects	Boolean	Determines whether HTTP redirects can be redirected.	By default, redirects issued by the receiving side of this HTTP task will be followed. Check this flag if this should not be allowed.
Save request variables	Boolean	Determines whether all request variables are stored. By default, only response related variables are stored as variables.	The Save request variables flag stores all request-related runtime fields such as url, body, headers, encoding, etc. as variables. Note that this could potentially lead to many and large process instance variables. The Save response details does the same, but for all response related fields that are not the actual response in the body, such as status code, headers, etc. Finally, the Variable prefix is a prefix that is put in front of these variables for easier grouping, which is useful when there are different HTTP tasks.
Save response details	Boolean	Determines whether response variables including HTTP status, headers etc. are stored. By default, only the response body is stored as a variable.
Result variable prefix	Text	A prefix that is put in front of the variable name of the result variables for easier grouping. The following variables are affected: responseProtocol, responseReason, responseStatusCode, responseHeaders, responseBody, errorMessage.
Ignore exception	Boolean	Determines whether exceptions are ignored and stored in the variable indicated in the response variable.	Determines whether exceptions are ignored and stored in the variable indicated in the response variable.

Advanced

Execution

Attribute	Type	Description	Category
Impact on parent completion	Selection: default ignore ignore if available ignore if available or enabled ignore after first completion ignore after first completion if available or enabled	Defines how the plan item is used when the parent completion evaluation is executed.	Normally, a parent stage completes when it has no active child plan item instances and all such instances are in a terminal state. Using auto complete, this can be changed to only look at the plan items marked as required. Using the Parent completion here, this behavior can be further specified: default will be as described above while ignore means that this http task isn't taking into account when checking if the parent stage completes. The other options allow for even finer-grained control to determine when to ignore this http task with regards to parent stage completion.
Asynchronous	Boolean	When enabled, the behavior of the plan item will be executed as an asynchronous job. This will happen when the plan item transitions to the ACTIVE state. During the execution of the behavior, the plan item will be set to an intermediate ASYNC_ACTIVE state. Please refer to the documentation for more details.	When making an HTTP task asynchronous, the HTTP REST call will be executed asynchronously in the background. This is useful for example to not block the UI of a user, in case of a slow service that is being called. Choose exclusive to avoid other asynchronous steps of this process instance to run at the same time. When Leave asynchronously is enabled, the activity will be left as an asynchronous job. This means that the activity is ended asynchronously.
Exclusive	Boolean	Determines whether the plan item is run as an exclusive job. An exclusive job makes sure that no other asynchronous exclusive plan items within the same case instance are performed at the same time. This helps to prevent failing jobs in concurrent scenarios.
Leave asynchronously	Boolean	When enabled, the leaving of the plan item will be executed as an asynchronous job. This will happen when the plan item transitions moved out of the ACTIVE state. During the execution of the behavior, the plan item will be set to an intermediate ASYNC_ACTIVE_LEAVE state. Please refer to the documentation for more details.
Leave exclusive	Boolean	Determines whether the activity should leave as an exclusive job. An exclusive job makes sure that no other asynchronous exclusive activities within the same process are performed at the same time. This helps to prevent failing jobs in concurrent scenarios.
Job Category	Text	When set, the underlying generated job will have a Job Category, which will be executed only by Application Servers, where the Case Engine has enabledJobCategories set to this category.
Include in history	Boolean	When the history level is set to "instance" or "task" level with this property it can be configured if this plan item instance should be included in the historic plan item instance data.	The Include in history flag can be used to store the historical entry of this http task when running with a history level that normally would not store the execution of the plan item. Note that this flag has no effect when running with history level 'none'.
Execute parallel in same transaction	Boolean	Flag indicating that the Http call should be done parallel in the same transaction. This means that when using parallel gateways multiple http tasks are executed in the same time in the same transaction and thus the entire execution of the process / case is faster.	Checking this flag means that the HTTP calls will be done in a separate threadpool. In case of parallel http calls, for example when there are multip HTTP tasks after a parallel gateway, this speeds up throughput as the calls will be done in a truly asynchronous way. The difference with using the asynchronous is that in that case there will be an asynchronous job for each asynchronous HTTP task, while with this flag the current execution is paused until all HTTP tasks with this flag checked are completed in a separate threadpool. It also means that the work isn't spread across different Flowable async executor instances, but rather all on the same machine, which typically is faster.

Listeners

Attribute	Type	Description	Category
Lifecycle listeners	List	Allows you to define lifecycle listeners for a plan item. Lifecycle listeners allow you to execute an expression, a delegate expression or a class when a plan item transitions from one state to another.	With lifecycle listeners it is possible to react to state changes of the http task. Lifecycle listeners allow you to execute an expression, a delegate expression or a class when the plan model transitions from one state to another.

Reactivation

Attribute	Type	Description	Category
Direct activation condition	Boolean	Condition that expresses if the plan item should be directly activated when a case instance is reactivated.	Case reactivation is the the ability to reopen a finished case instance and continue with its execution. Case reactivation needs to be modeled using a reactivation listener and specific behavior can be configured for each plan item in the case model. The Direct Activation Condition is the first condition to be evaluated during case reactivation. If checked or if there is an expression evaluating to true, the http task immediately gets activated, regardless of any entry sentry or condition which might be necessary to restart at a certain state of the case (e.g. a stage). The Ignore Condition, if checked or if there is an expression evaluating to true, means that the http task is ignored on reactivation. The Default Condition only gets evaluated, if the previous ones are either not checked or evaluated to false. If so, the http task behaves like a regular one as if the case instance was started from scratch. This means that any necessary entry sentry is considered and evaluated and the engine proceeds as normal. Please check the Flowable documentation for more details.
Ignore condition	Boolean	Condition that expresses if the plan item should be ignored when a case instance is reactivated.
Default condition	Boolean	Condition that expresses if the plan item should trigger when a case instance is reactivated.

Visual

Attribute	Type	Description	Category
Font size	Selection: 8 9 10 11 12 14 18 20 24 36 48 72	The font size of the element in the diagram.	Visual properties that determine how the HTTP task is shown in the diagram. This has no impact on the runtime execution.
Font weight	Selection: Normal Bold	The font weight of the element in the diagram.
Font style	Selection: Normal Italic	The font style of the element in the diagram.
Font color	Color	The font color of the element in the diagram.
Background color	Color	The background color of the element in the diagram.
Border color	Color	The border color of the element in the diagram.

List Attribute Details

Variable Aggregations

Attribute	Type	Description
Target (Variable / Expression)	Text	The name of the target variable or an expression that gives the variable name
Type	Selection: Default Custom
Delegate Expression	Text	Delegate Expression to be executed when the task is activated. A delegate expression must resolve to a Java object, for instance a Spring bean. The object's class must implement either PlanItemJavaDelegate or CmmnActivityBehavior.
Class	String	Fully qualified classname of a class to be invoked when executing the task. The class must implement either PlanItemJavaDelegate or CmmnActivityBehavior.
Target variable creation	Selection: Default Create overview variable Store as transient variable
Variable Definitions	BasicFormList

Variable Definitions

Attribute	Type	Description
Source (Variable / Expression)	Text	The name of the source variable or an expression that provides the value
Target (Variable / Expression)	Text	The name of the target variable or an expression that gives the variable name

Lifecycle listeners

Attribute	Type	Description
Source state	Selection: Any Available Active Enabled Disabled Completed Failed Suspended Closed Terminated Waiting for repetition Async active Async active leave
Target state	Selection: Any Available Active Enabled Disabled Completed Failed Suspended Closed Terminated Waiting for repetition Async active Async active leave
Class	Text	Fully qualified classname of a class to be invoked when executing the task. The class must implement either PlanItemJavaDelegate or CmmnActivityBehavior.
Expression	Text	JUEL Expression to be executed when the task is started. Expressions allow you to interact with the backend by calling services, making calculations etc. You can find more information about expressions in the documentation.
Delegate expression	Text