Action Step Payload Examples

Event Orchestration – Action Step Payload Examples

Overview

In the Action step you define the payload sent with the triggered action. The payload has three parts:

• Body – Free-form JSON sent with the action. You can either tick Use the original event payload as the body, or paste custom Payload content.

• Headers – Key/value pairs delivered as Camel message headers to the target route.

• Properties – Key/value pairs delivered as Camel exchange properties to the target route.

Payload support by action type:

• Logic – Body only; its top-level JSON fields become input parameters of the logic.

• Route – Body, Headers and Properties (Headers and Properties require IntegrationManager 3.2 or newer).

• All other action types (Calculation (CFS), Calculation Flow, Data Load, PFM Workflow, Data Download, Data Upload) – the payload is not delivered; leave the Payload section empty.

In Schedulers only a subset of these action types is offered (Logic, Calculation, Data Load, Route, Workflow, Data Download). The payload behavior is the same as in Event Workflows.

Partition target — Action Type: Logic

For Logic targets, the Body is sent to the partition wrapped in the standard Pricefx API envelope {"data": <your JSON>}.

Example 1

Run a partition logic and pass it parameters. All Body fields are of your choice and become input parameters of the logic, readable in Groovy via the input binding (e.g. input.runMode). Values can be strings, numbers, booleans, arrays or nested objects. The only exception are three reserved field names – targetDate, productSKU and allResults – which the partition consumes itself instead of passing them to the logic (see the table below).

Body

{
  "runMode": "DELTA",
  "productGroups": ["BEVERAGES", "SNACKS"],
  "targetDate": "2026-07-16",
  "productSKU": "SKU-001",
  "allResults": true
}

In this example, runMode and productGroups become logic inputs (input.runMode, input.productGroups), while the remaining three fields are reserved names consumed by the partition:

Integration (IM) target — Action Type: Route

When the target is an IntegrationManager route, all three payload parts are delivered. In the target route:

• Body arrives as the Camel message body as a JSON string (not a parsed object). Parse it first — e.g. with <unmarshal><json/></unmarshal> — before accessing fields with ${body[field]}.

• Headers are read with ${header.X}.

• Properties are read with ${exchangeProperty.Y}.

Example 2

Push approved price updates to an external system.

Body

{
  "priceGridCode": "PG-2026-Q3",
  "currency": "EUR",
  "items": [
    { "sku": "SKU-001", "newPrice": 12.50, "oldPrice": 11.90 },
    { "sku": "SKU-002", "newPrice": 9.99,  "oldPrice": 9.50 }
  ]
}

Headers

Properties

How the target route reads the payload:

<route id="pushPriceUpdate">
    <from uri="direct:pushPriceUpdate"/>
    <log message="Scenario ${exchangeProperty.integrationScenario}, corr ${header.X-Correlation-Id}"/>
    <!-- the body arrives as a JSON string; parse it before accessing fields -->
    <unmarshal><json/></unmarshal>
    <log message="Grid ${body[priceGridCode]}"/>
    <split>
        <simple>${body[items]}</simple>
        <!-- per item: ${body[sku]}, ${body[newPrice]} -->
    </split>
</route>

Using the original event payload as the Body

Instead of entering custom JSON, you can tick Use the original event payload as the body. What the action receives depends on the triggering event:

Events with a job tracker (most job-completion events)

When the partition event references a background job (it contains a trackerId — e.g. CFS calculation completed, data load finished), Event Orchestration fetches the corresponding JobStatusTracker (JST) object from the partition and uses it as the payload. Example (shortened):

{
  "id": 6081,
  "typedId": "6081.JST",
  "status": "FINISHED",
  "trackerType": "PADATALOAD",
  "targetObject": "24.DMDL",
  "jobName": "Calendar (Calendar)",
  "messages": "[\"Loaded 2192 rows\"]",
  "createDate": "2026-06-11T07:39:46",
  "processingStart": "2026-06-11T07:40:15",
  "processingEnd": "2026-06-11T07:40:18",
  "parameters": "{\"dataLoad\":\"...\"}",
  "parametersObject": { "dataLoad": "..." }
}

• The JST’s parameters field is a JSON string; Event Orchestration additionally adds parametersObject with the parsed content, so the payload consumer does not have to parse it.

• Note that the payload is the JST object only — it does not contain the eventType field of the original event.

• Useful fields to branch on: status (e.g. FINISHED), trackerType, targetObject, jobName.

Events without a job tracker

When the event carries no trackerId (and as a fallback when the JST fetch fails), the raw partition event is used as the payload:

{
  "eventType": "CUSTOM_myEvent",
  "data": [
    { "typedId": "42.CFS" }
  ]
}

How the target consumes it

• Logic – the payload’s top-level fields (status, targetObject, parametersObject, …) become the logic input parameters.

• Route – the payload arrives as a JSON string body; parse it first (see above), then branch on it, e.g. with ${body[status]} or ${body[targetObject]}.