This is the hands-on companion to my Boomi Functional Integration Tracing demo. Where the original post and its short demo show what Boomi integration tracing looks like, this tutorial goes deep on how every part is built inside Boomi, Elastic and Azure. If you want the high-level overview first, start with the original demo post — then come back here to build your own Boomi integration tracing setup step by step.
I recorded a full deep-dive video that walks through every component of this Boomi integration tracing pattern step by step. This written tutorial follows that video closely, so you can read along, pause, and rebuild the pattern in your own environment. If you are new to the platform, the official Boomi site is a good starting point.
Watch the Boomi integration tracing deep-dive video
If you have questions after watching, leave a comment or reach out — I am always happy to talk through a technical challenge. All of the supporting material for this tutorial, including a Markdown write-up and every data model as a JSON schema, lives in the accompanying GitHub repository linked from the video.
The business case for Boomi integration tracing
A business colleague wants to know where order XYZ from customer ABC is right now. That is the whole point of the design. Everything we build below exists so that anyone can search a single order or customer back through the Boomi environment and immediately see what happened to it. Good Boomi integration tracing turns that vague question into a precise, searchable answer.
The Boomi integration tracing architecture at a glance
The delivery path is deliberately simple. An order flows from System A, through Boomi, through Azure API Management, into System B:
- System A sends a business order into Boomi.
- Boomi processes the message, stores searchable business values as track fields, and emits a functional and technical trace.
- Azure API Management validates the target contract (schema validation) before the message reaches System B.
- Elastic and Application Insights provide an independent functional and technical record of what happened.
Two building blocks make Boomi integration tracing searchable. First, track fields, which let you search Boomi executions by business identifiers such as order ID and customer ID. Second, an Elastic dashboard that receives structured trace messages. Elastic is just my choice here because it is easy to set up — you can swap it for any store you like. On top of Azure API Management I also enable Application Insights for an end-to-end technical view.
How the Boomi environment is organised
The environment is split into two areas: order processing and tracing. Order processing itself is split across two processes:
- Imitate Send Order — a demo helper that lets me play the role of System A and fire either a successful or an unsuccessful order.
- Main Order — the process that does the real work and is deployed separately. It is triggered by the imitation process.
Splitting the trigger from the logic keeps the demo honest: the main process behaves exactly as it would in production, and the imitation process only exists to send test orders.
Step 1: Set your Boomi integration tracing properties
The first thing the process does is set trace properties. These come in two flavours — dynamic document properties (DDPs) and dynamic process properties (DPPs) — and the choice between them is deliberate, not arbitrary. Think about what belongs to an individual document versus what belongs to the whole process run.
In the trigger process I set the initial values:
- Correlation ID and Activity ID — a unique value that ties everything together.
- Interface code (for example,
1) — always use a unique interface code per Boomi integration. It makes traceability effortless and keeps everything aligned with your documentation. - Interface name and system names — I use standardised, short (roughly five-character) system names such as
sysAandsysB, which are also part of my documentation. - Domain — here it is
order. - Parent status — the functional state of the process: progressing, succeeded or errored.
- Action — a functional description such as “started processing this order” or “order created successfully”.
- Severity (info or error) and status, plus all of the standard Boomi execution information.
- Schema version (for example,
1.0) — used to keep tracing backwards compatible.
DDP (Dynamic Document Property) values:
DDP_CorrelationId
DDP_ActivityId
DDP_RegistrationTsp
DDP_ParentStatus
DDP_EndTsp
DDP_Action
DDP_Severity
DDP_Status
DPP (Dynamic Process Property) values:
DPP_InterfaceCode
DPP_InterfaceName
DPP_SourceSystemCode
DPP_TargetSystemCode
DPP_DomainCode
DPP_StartTsp
DPP_BoomiAccountId
DPP_BoomiRuntimeId
DPP_BoomiRuntimeName
DPP_BoomiExecutionId
DPP_BoomiNodeId
DPP_BoomiProcessId
DPP_BoomiProcessName
All of these properties map onto a single JSON schema I call the trace log message, and they form the backbone of the whole Boomi integration tracing framework. The full schema and an example message are in the GitHub repo, so you can see exactly how the correlation ID, activity ID and integration metadata come together in the final payload.
trac-message-schema-v1.json
{
"$schema": "http://json-schema.org/draft-04/schema#",
"title": "traceLogMessage",
"type": "object",
"properties": {
"id": {
"type": "string",
"description": "Unique identifier for this log entry (random GUID)"
},
"correlationId": {
"type": "string",
"description": "Correlation identifier (GUID). Within Boomi: DPP_CorrelationId"
},
"activityId": {
"type": "string",
"description": "Unique identifier for the parent session. Within Boomi: DDP_ActivityId"
},
"registrationTsp": {
"type": "string",
"format": "date-time",
"description": "Timestamp when this log entry was created (UTC). Within Boomi: DDP_RegistrationTsp"
},
"interfaceCode": {
"type": "string",
"description": "Interface code (e.g. IF0001). Within Boomi: DPP_InterfaceCode"
},
"interfaceName": {
"type": "string",
"description": "Optional interface name. Within Boomi: DPP_InterfaceName"
},
"parentStatus": {
"type": "string",
"enum": [
"RUNNING",
"SUCCESS",
"WARNING",
"FAILED",
"FATAL"
],
"description": "Overall session status. Within Boomi: DDP_ParentStatus"
},
"startTsp": {
"type": "string",
"format": "date-time",
"description": "Start time for this session. Within Boomi: DDP_StartTsp"
},
"endTsp": {
"type": "string",
"format": "date-time",
"description": "End time if session is completed. Within Boomi: DDP_EndTsp"
},
"sourceSystemCode": {
"type": "string",
"description": "Source system code (2–3 characters). Within Boomi: DPP_SourceSystemCode"
},
"targetSystemCode": {
"type": "string",
"description": "Target system code (2–5 characters). Within Boomi: DPP_TargetSystemCode"
},
"domainCode": {
"type": "string",
"description": "Domain code (2–5 characters) for example PART for participation. Within Boomi: DPP_DomainCode"
},
"action": {
"type": "string",
"description": "Action description. Within Boomi: DDP_Action"
},
"severity": {
"type": "string",
"enum": [
"INFO",
"WARNING",
"ERROR",
"DEBUG",
"TRACE"
],
"description": "Log severity level. Within Boomi: DDP_Severity"
},
"status": {
"type": "string",
"enum": [
"SUCCESS",
"WARNING",
"FAILED",
"FATAL"
],
"description": "Status of this log entry. Within Boomi: DDP_Status"
},
"boomiAccountId": {
"type": "string",
"description": "Run identifier (optional). Within Boomi: DPP_BoomiAccountId"
},
"boomiRuntimeId": {
"type": "string",
"description": "Run identifier (optional). Within Boomi: DPP_BoomiRuntimeId"
},
"boomiRuntimeName": {
"type": "string",
"description": "Deployment environment. Within Boomi: DPP_BoomiRuntimeName"
},
"boomiExecutionId": {
"type": "string",
"description": "Run identifier (optional). Within Boomi: DPP_BoomiExecutionId"
},
"boomiNodeId": {
"type": "string",
"description": "Run identifier (optional). Within Boomi: DPP_BoomiNodeId"
},
"boomiProcessId": {
"type": "string",
"description": "Run identifier (optional). Within Boomi: DPP_BoomiProcessId"
},
"boomiProcessName": {
"type": "string",
"description": "Run identifier (optional). Within Boomi: DPP_BoomiProcessName"
},
"schemaVersion": {
"type": "string",
"description": "Version of this schema, e.g. '1.0'. Within Boomi DPP_SchemaVersion"
},
"traceTimestamp": {
"type": "string",
"format": "date-time",
"description": "Timestamp when the trace is created"
},
"metadata": {
"type": "array",
"description": "Optional metadata key/value pairs.",
"items": {
"type": "object",
"properties": {
"key": {
"type": "string",
"description": "Metadata key (can be empty)."
},
"value": {
"type": "string",
"description": "Metadata value (can be empty)."
}
},
"required": [
"key",
"value"
]
}
}
},
"required": [
"id",
"correlationId",
"activityId",
"registrationTsp",
"interfaceCode",
"parentStatus",
"sourceSystemCode",
"targetSystemCode",
"domainCode",
"severity",
"status",
"schemaVersion",
"traceTimestamp"
],
"examples": [
{
"id": "7ac41e92-1f1f-4a2b-8a2f-56a7c222ab33",
"correlationId": "c3b2f1d1-3b1a-4e2d-812a-456789abc111",
"activityId": "c3b2f1d1-3b1a-4e2d-812a-456789abcdef",
"registrationTsp": "2026-08-03T20:45:00Z",
"interfaceCode": "IF0001",
"interfaceName": "MAIN IF0001 SFEV > CDM Order",
"parentStatus": "RUNNING",
"startTsp": "2026-08-03T20:45:00Z",
"endTsp": "2026-08-03T20:47:00Z",
"sourceSystemCode": "SFEV",
"targetSystemCode": "CDM",
"domainCode": "ORDER",
"action": "Started processing order",
"severity": "INFO",
"status": "SUCCESS",
"boomiAccountId": "1234",
"boomiRuntimeId": "1234",
"boomiRuntimeName": "test-boomi-runtime",
"boomiExecutionId": "0dd93fd5-9ece-44a0-9330-e4fb4f69ef5b",
"boomiNodeId": "node-01",
"boomiProcessId": "proc-abc123",
"boomiProcessName": "MAIN IF0001 SFEV > CDM Order",
"schemaVersion": "1.0",
"traceTimestamp":"2025-08-03T20:45:00Z",
"metadata": [
{
"key": "orderId",
"value": "123"
},
{
"key": "customerId",
"value": "789"
}
]
}
]
}Step 2: Push the order onto a queue
For this demo I push the order onto a Boomi queue. Full disclosure: I am not a big fan of the Boomi queue for production. I am an Azure person and I would reach for an Azure Service Bus every time, because you get far more control over the delivery count, the peek-lock mechanism, the dead-letter queue and resubmitting. The Boomi queue is used here purely because it ships with the sandbox and keeps the demo self-contained.
Once the order is on the queue, the trigger process is done and the main process takes over.
Step 3: Configure track fields for Boomi integration tracing
The main process listens to the same queue and has track fields enabled. Track fields are the search backbone of Boomi integration tracing. If you open the process and the track fields list is empty, that is because they have not been defined yet. You add them at the account level: go to your Boomi account settings and, near the bottom, you will find the track fields configuration.
For this integration I added order ID and customer ID. A few things to keep in mind:
- You can define a maximum of 20 track fields, so choose them carefully.
- Favour commonly used, cross-integration values — a search field, a record ID, or similar — so the same fields are useful across many processes.
With those defined, you can later search Boomi executions directly on order ID or customer ID.
Step 4: Reuse the correlation across chained processes
At the start of the main process we set the trace properties again — but this time we do not generate a new unique ID. Instead we read the correlation ID and activity ID from the dynamic document properties set by the previous process. When you chain processes like this, carrying the same correlation and activity ID forward is what lets Boomi integration tracing follow a single order across every hop. Everything else stays the same.
The main process wraps its logic in a try/catch — nothing unusual there — and then moves into the first sub-process, which is where the interesting part begins.
Step 5: Attach metadata using a cache
Before we emit any trace, we set the metadata. I always use the activity ID as the unique key to attach information to the trace. From the input document I pull the customer ID and order ID, then store them in a Boomi cache keyed on that activity ID.
The cache uses one JSON profile — the same trace log message profile — and relates the activity ID to a set of metadata key/value pairs. Later, when we build the trace message, we join the metadata back onto it using that key. The payoff is that Boomi integration tracing can always be searched on business metadata such as order ID or customer ID, even when the raw payload no longer carries it.
Step 6: Emit the first functional trace
Now for the functional trace itself. We let the trace know that Boomi has received the order from System A. From the business point of view this is the moment the order reaches the “received, now processing” phase. Severity is info.
Behind this step sits a process route. Whenever logic is shared across multiple processes, use a process route — it keeps the design maintainable for whoever picks it up after you. The route contains the following:
- Branch on schema version. Based on the DPP schema version (here
1.0) we select the right “create trace message” logic. Versioning the schema is what makes Boomi integration tracing backwards compatible: when a field or breaking change arrives, add a new version and let both run side by side. - Set the activity ID. A small JSON step sets the activity ID so the trace matches the correct activity. This matters enormously if you debatch documents and the activity ID changes — it ensures the right metadata is attached.
- Map properties to trace fields. A map connects every document and process property we set earlier to the fields of the trace message. It looks busy, but you only build this once. This is your Boomi integration tracing framework.
- Push to the trace queue. The resulting trace message is placed on the trace queue.
Step 7: Handle the unhappy flow
When the process hits the catch shape, we build a failure trace: set parent status to failed, capture the try/catch action, set severity to error, and stamp the end time. It uses a separate process route that is almost identical to the happy-path one — the only difference is an extra branch that throws a generic exception on the current data, so the error surfaces clearly in the trace output.
Step 8: Map System A to System B and trace the transformation
Back in the sub-process we have a simple map from the System A format to the System B format. After the map returns the transformed document, we emit another trace — the “transformed from System A into System B” step.
How much you trace here is a functional decision. Ask the business what they actually want to see: the full journey, or only failures? Add per-context traces to match that answer rather than tracing everything by reflex.
system-a-order-schema.json
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"$id": "https://intersky.nl/schemas/system-a-order.schema.json",
"title": "System A Order",
"description": "Order message created by System A. The orderId is the business key and correlationId is propagated for functional tracing.",
"type": "object",
"additionalProperties": false,
"required": [
"orderId",
"correlationId",
"orderDate",
"orderStatus",
"customer",
"currency",
"orderLines",
"shippingAddress",
"sourceSystem"
],
"properties": {
"orderId": {
"type": "string",
"pattern": "^SO-[0-9]+$",
"description": "Business key used for functional tracing.",
"examples": [
"SO-1042"
]
},
"correlationId": {
"type": "string",
"format": "uuid",
"description": "End-to-end technical trace identifier.",
"examples": [
"7db2f7c8-ef5b-4afc-8c56-1a4df2e5042c"
]
},
"orderDate": {
"type": "string",
"format": "date-time",
"examples": [
"2026-08-15T09:41:03Z"
]
},
"orderStatus": {
"type": "string",
"enum": [
"CONFIRMED",
"CANCELLED"
],
"examples": [
"CONFIRMED"
]
},
"customer": {
"type": "object",
"additionalProperties": false,
"required": [
"customerId",
"name"
],
"properties": {
"customerId": {
"type": "string",
"examples": [
"CUST-2048"
]
},
"name": {
"type": "string",
"examples": [
"Northwind Retail"
]
}
}
},
"currency": {
"type": "string",
"enum": [
"EUR"
],
"examples": [
"EUR"
]
},
"orderLines": {
"type": "array",
"minItems": 1,
"items": {
"type": "object",
"additionalProperties": false,
"required": [
"lineNumber",
"itemCode",
"description",
"quantity",
"unitPrice"
],
"properties": {
"lineNumber": {
"type": "integer",
"minimum": 1,
"examples": [
1
]
},
"itemCode": {
"type": "string",
"examples": [
"WIDGET-BLUE-01"
]
},
"description": {
"type": "string",
"examples": [
"Blue Widget"
]
},
"quantity": {
"type": "integer",
"minimum": 1,
"examples": [
2
]
},
"unitPrice": {
"type": "number",
"minimum": 0,
"examples": [
49.95
]
}
}
}
},
"shippingAddress": {
"type": "object",
"additionalProperties": false,
"required": [
"countryCode",
"city"
],
"properties": {
"countryCode": {
"type": "string",
"pattern": "^[A-Z]{2}$",
"examples": [
"NL"
]
},
"city": {
"type": "string",
"examples": [
"Amsterdam"
]
}
}
}
},
"examples": [
{
"orderId": "SO-1042",
"correlationId": "7db2f7c8-ef5b-4afc-8c56-1a4df2e5042c",
"orderDate": "2026-08-15T09:41:03Z",
"orderStatus": "CONFIRMED",
"customer": {
"customerId": "CUST-2048",
"name": "Northwind Retail"
},
"currency": "EUR",
"orderLines": [
{
"lineNumber": 1,
"itemCode": "WIDGET-BLUE-01",
"description": "Blue Widget",
"quantity": 2,
"unitPrice": 49.95
},
{
"lineNumber": 2,
"itemCode": "CABLE-USB-C-02",
"description": "USB-C Cable",
"quantity": 1,
"unitPrice": 19.95
}
],
"shippingAddress": {
"countryCode": "NL",
"city": "Amsterdam"
}
}
]
}system-b-order-schema.json
{
"$schema": "http://json-schema.org/draft-04/schema#",
"id": "https://intersky.nl/schemas/system-b-order.schema.json",
"title": "System B Order",
"description": "Order message accepted by System B. The core schema mirrors System A so Boomi can map it directly while retaining functional-tracing identifiers.",
"type": "object",
"additionalProperties": false,
"required": [
"orderId",
"orderDate",
"receivedAt",
"orderStatus",
"customer",
"currency",
"orderLines",
"shippingAddress"
],
"properties": {
"orderId": {
"type": "string",
"pattern": "^SO-[0-9]+$",
"description": "Same business key received from System A.",
"examples": [
"SO-1042"
]
},
"orderDate": {
"type": "string",
"format": "date-time",
"examples": [
"2026-08-15T09:41:03Z"
]
},
"receivedAt": {
"type": "string",
"format": "date-time",
"description": "Timestamp added by System B when the mapped order is received.",
"examples": [
"2026-08-15T09:41:05Z"
]
},
"orderStatus": {
"type": "string",
"enum": [
"PENDING_FULFILLMENT",
"REJECTED"
],
"examples": [
"PENDING_FULFILLMENT"
]
},
"customer": {
"type": "object",
"additionalProperties": false,
"required": [
"customerId",
"name"
],
"properties": {
"customerId": {
"type": "string",
"examples": [
"CUST-2048"
]
},
"name": {
"type": "string",
"examples": [
"Northwind Retail"
]
}
}
},
"currency": {
"type": "string",
"enum": [
"EUR"
],
"examples": [
"EUR"
]
},
"orderLines": {
"type": "array",
"minItems": 1,
"items": {
"type": "object",
"additionalProperties": false,
"required": [
"lineNumber",
"itemCode",
"description",
"quantity",
"unitPrice"
],
"properties": {
"lineNumber": {
"type": "integer",
"minimum": 1,
"examples": [
1
]
},
"itemCode": {
"type": "string",
"examples": [
"WIDGET-BLUE-01"
]
},
"description": {
"type": "string",
"examples": [
"Blue Widget"
]
},
"quantity": {
"type": "integer",
"minimum": 1,
"examples": [
2
]
},
"unitPrice": {
"type": "number",
"minimum": 0,
"examples": [
49.95
]
}
}
}
},
"shippingAddress": {
"type": "object",
"additionalProperties": false,
"required": [
"countryCode",
"city"
],
"properties": {
"countryCode": {
"type": "string",
"pattern": "^[A-Z]{2}$",
"examples": [
"NL"
]
},
"city": {
"type": "string",
"examples": [
"Amsterdam"
]
}
}
}
},
"examples": [
{
"orderId": "SO-1042",
"orderDate": "2026-08-15T09:41:03Z",
"receivedAt": "2026-08-15T09:41:05Z",
"orderStatus": "PENDING_FULFILLMENT",
"customer": {
"customerId": "CUST-2048",
"name": "Northwind Retail"
},
"currency": "EUR",
"orderLines": [
{
"lineNumber": 1,
"itemCode": "WIDGET-BLUE-01",
"description": "Blue Widget",
"quantity": 2,
"unitPrice": 49.95
},
{
"lineNumber": 2,
"itemCode": "CABLE-USB-C-02",
"description": "USB-C Cable",
"quantity": 1,
"unitPrice": 19.95
}
],
"shippingAddress": {
"countryCode": "NL",
"city": "Amsterdam"
}
}
]
}The full schemas, JSON profiles, and Azure API Management policies for this tutorial are available in the GitHub repository: https://github.com/interskyintegrations/Blog/tree/main/eps04_Boomi_Tracing_Setup
Step 9: Deliver to System B and emit the final trace
The last step of the main process pushes the message to System B through a REST endpoint. Then we set the finishing trace: parent status success, action order created, severity info, status success, and a final timestamp. Every trace — started, transformed and finished, plus any errors — goes onto the same trace queue.
Step 10: Ship Boomi integration tracing messages to Elastic
A single, dedicated process drains the trace queue and pushes each message to Elastic. Because this is effectively a new integration, it gets its own trace properties, including a new interface code (for example, 2) — we are, after all, integrating from Boomi into Elastic, which deserves its own identity. It is a bit of an inception, but it keeps the Boomi integration tracing consistent.
The process posts each trace into the Elastic table, then runs a simple application status check: if we get a 201 back, all is well; otherwise we throw an exception. That exception flows through the same try/catch pattern and shows up as an error case — tracing the tracer.
Step 11: Run the happy path
Time to test the Boomi integration tracing end to end. I create a new order — say order SO1600 from customer 2050 — save it and push it onto the queue. The separately deployed main process picks it up, posts it to System B, and emits the three trace messages: started, transformed and finished.
Now the core question: can we find this order later? In Boomi, choose search on user-defined track fields, pick order ID, and paste the value. It comes straight back, even if the run happened a week ago — as long as the documents are still stored on the runtime. From there you can load the execution and see the process, and the same track fields make customer ID equally searchable. (Tip: switch the process to low latency during testing so trace delivery to Elastic is quicker to observe.)
Over in Elastic, searching for customer 2050 shows the complete journey: order received from System A, transformed into System B, and order created. All of the trace fields are available to filter on — severity, status, and everything else you pushed — and if you are comfortable in Elastic you can build alerts on top of those tables.
Step 12: Run the unhappy path
On the Azure side there are two APIs. The Order API includes a policy (also in the GitHub repo) that mocks a 201 when everything is valid, plus a validate-content step. This is the part people often forget: Azure API Management can validate an incoming payload against an uploaded schema and reject anything that does not conform. A good order returns 201; a request missing the order ID is rejected.
To demonstrate, I send an order for customer 2075 but omit the order ID, using the imitation process’s unhappy flow. Because there is no order ID, we cannot search on it — but we still have the customer ID. In this exact business scenario you would ask the customer for their number and search on customer ID instead. The execution comes back flagged as an error.
Loading the execution shows the trace message set in the exception shape. The order ID is missing, and the API response tells us the order ID is of an invalid type — the same response you would see in Postman. In Elastic the journey now reads: received the order, transformed it into the System B format, then failed — order ID of invalid type, a string expected but null received.
Ideally you validate the contract before the message ever enters the integration, so System A learns about its own mistake. But this shows how Boomi integration tracing keeps you in control when it does slip through — and how a good dashboard turns “something broke” into “the integration never received the order ID.”
Step 13: Add the technical view with Application Insights
The functional trace answers the business question. For deep technical investigation I connect Application Insights to Azure API Management and log the request and response bodies. When a question comes in, instead of relying only on Boomi or Elastic, you can do an end-to-end investigation in App Insights: search for the customer, find the API call, and inspect exactly what was sent and what came back. It is more technical by nature, but invaluable for root-cause analysis.
One architectural bonus: from Boomi’s perspective, Azure API Management is a single connection, while behind it you can fan out to any number of downstream systems. That can meaningfully reduce connector licensing costs on the Boomi side.
Wrapping up your Boomi integration tracing framework
That is the whole Boomi integration tracing pattern, end to end: correlation and activity IDs, deliberate document versus process properties, track fields for business search, a metadata cache keyed on the activity ID, versioned trace messages built through process routes, a functional record in Elastic, and a technical record in Application Insights. Build the framework once and every future integration inherits searchable, business-readable tracing.
The step-by-step Markdown notes and all of the JSON schemas — the trace log message, the System A order and the System B order — are in the GitHub repo linked from the video description. If you get stuck, leave a comment or reach out. Have a good one.
0 Comments