Skip to content

Step Types

Every step in an orchestration performs a single action. DIBOP supports four step types, each designed for a specific purpose.

API Call

An API Call step makes an HTTP request to a connected external system. This is the most common step type -- it is how orchestrations interact with the outside world.

Configuration

Field Description
Connection Which connected system to call
Operation Which API operation to invoke (from the connector's registered operations)
Parameters Input values for the API call (can reference outputs from previous steps)
Headers Additional HTTP headers to include (optional)
Timeout Override the connection's default timeout for this step (optional)

What Happens at Runtime

  1. DIBOP retrieves the connection's credentials from Key Vault
  2. Authenticates with the external system (API key, OAuth2 token, etc.)
  3. Sends the HTTP request with the configured parameters
  4. Waits for the response (up to the timeout)
  5. Stores the response in the execution context under the step's name
  6. Logs the API call in the API Call Log

Output Structure

The output of an API Call step is available to subsequent steps:

{
  "status_code": 200,
  "headers": {
    "content-type": "application/json",
    "x-request-id": "abc123"
  },
  "response": {
    // The parsed JSON response body
  },
  "duration_ms": 245
}

Reference the response in later steps using parameter mapping:

${step_name.response.field_name}
${step_name.status_code}

Error Behaviour

If the API call fails (network error, timeout, or HTTP 4xx/5xx), the step is marked as failed. The orchestration's error handling configuration determines what happens next.

Data Transform

A Data Transform step manipulates data without calling any external system. Use it to reshape, filter, enrich, or aggregate data between API calls.

Configuration

Field Description
Transform Type The kind of transformation (Map, Filter, Merge, Extract)
Input The data to transform (references to previous step outputs)
Mapping A JSON object defining the transformation

Common Transform Operations

Field Mapping (Rename / Reshape)

Create a new object by mapping fields from a previous step's output:

{
  "vehicle_make": "${decode_vin.response.Make}",
  "vehicle_model": "${decode_vin.response.Model}",
  "vehicle_year": "${decode_vin.response.ModelYear}",
  "decoded_at": "${_context.timestamp}"
}

Filtering

Filter an array of records based on a condition:

{
  "type": "filter",
  "input": "${fetch_vehicles.response.vehicles}",
  "condition": "item.status == 'active'"
}

Merging

Combine data from two different steps:

{
  "type": "merge",
  "sources": [
    "${decode_vin.response}",
    "${fetch_inventory.response}"
  ],
  "strategy": "deep_merge"
}

Aggregation

Compute summary statistics over an array:

{
  "type": "aggregate",
  "input": "${fetch_sales.response.transactions}",
  "operations": {
    "total_revenue": "sum(item.amount)",
    "transaction_count": "count()",
    "average_sale": "avg(item.amount)"
  }
}

Output

The transformed data is stored in the execution context under the step's name, just like any other step.

Chain Transforms

You can chain multiple transform steps in sequence. Each one builds on the output of the previous, allowing complex data reshaping without any code.

Conditional

A Conditional step branches the orchestration based on a condition. It evaluates an expression and executes different subsequent steps depending on the result.

Configuration

Field Description
Condition A boolean expression to evaluate
Then Steps Steps to execute if the condition is true
Else Steps Steps to execute if the condition is false (optional)

Condition Syntax

Conditions use a simple expression language:

Expression Meaning
${step.status_code} == 200 HTTP status equals 200
${step.response.count} > 0 Count is greater than zero
${step.response.status} == "active" String equality
${step.response.items} != null Value is not null
${step.response.score} >= 0.8 AND ${step.response.verified} == true Combined conditions

Example: Check Before Write

Conditional: "Is the vehicle new?"
  Condition: ${decode_vin.response.ModelYear} >= 2024
  Then:
    → write_to_new_inventory
  Else:
    → write_to_used_inventory

Nested Conditionals

Conditionals can be nested, allowing for complex decision trees. However, keep your orchestrations readable -- if you find yourself nesting more than two levels deep, consider splitting into multiple orchestrations.

Error Handler

An Error Handler step defines what happens when a preceding step fails. It provides fine-grained control over error recovery.

Configuration

Field Description
Applies To Which step(s) this handler covers
On Error The action to take: Retry, Skip, Abort, or Custom
Retry Count Number of retry attempts (if Retry is selected)
Retry Delay Seconds between retry attempts
Fallback A step to execute if all retries fail (optional)

Error Actions

Retry

Re-execute the failed step up to N times with a configurable delay:

Setting Default Description
Max Retries 3 Maximum number of retry attempts
Retry Delay 1 second Time to wait between retries
Backoff Exponential Delay multiplier (1s, 2s, 4s, ...)

Idempotent Operations

Only use Retry for operations that are safe to repeat (idempotent). A GET request is always safe to retry. A POST that creates a record may not be -- you could end up with duplicate records.

Skip (Continue on Error)

Mark the step as failed but continue executing subsequent steps. Useful when the failed step is not critical to the overall workflow.

The skip status is available in the context:

${step_name._status} == "skipped"

Abort

Stop the orchestration immediately. The execution is marked as failed and no further steps are executed. This is the default behaviour.

Custom Fallback

Execute an alternative step when the primary step fails. For example:

  • If the primary API is down, call a backup API
  • If a write fails, log the data to a dead letter queue
  • If a transform fails, use a default value

Built-In Context Variables

Every step has access to built-in context variables:

Variable Description
${parameters.*} The orchestration's input parameters
${step_name.*} Output from a previous step
${_context.timestamp} Current UTC timestamp
${_context.execution_id} The unique ID of this execution
${_context.orchestration_id} The orchestration's ID
${_context.enterprise_id} Your enterprise ID

Choosing the Right Step Type

You Want To... Use
Call an external API API Call
Reshape or filter data Data Transform
Make a decision based on data Conditional
Handle failures gracefully Error Handler

Next Steps