Hi John,
Thank you for the detailed description of your scenario. I work on the AEM adapter for SAP Integration Suite, so I can speak to exactly what’s happening here.
The short answer: the adapter can do what you need, but the property needs to be set in a different place than where you currently have it.
The AEM Receiver adapter has two separate property configuration areas that are easy to confuse:
- JCSMP Properties (on the Connection tab) – These are session/connection-level properties (e.g., GENERATE_SENDER_ID, CLIENT_CHANNEL_PROPERTIES.ReconnectRetries). They configure the underlying JCSMP
session to the broker. Properties set here never end up on the published message – they only affect how the connection itself behaves.
- User Properties (on the Message Properties tab, under Additional Properties) – These are per-message key-value pairs that get carried inside the message’s SMF User Properties (SDTMap). This is exactly where the Solace broker’s distributed tracing feature looks for the W3C Trace Context.
Based on your description – “This adapter has the JCSMP property ‘traceparent’ set” – it sounds like you are setting traceparent in the JCSMP Properties on the Connection tab. If so, that value is being applied to the JCSMP session configuration and is never written onto the outgoing message. The broker therefore sees no trace context on the message and creates a new root span with its own trace-id, which is exactly the behavior you’re observing.
What to do instead:
Set the traceparent (and optionally tracestate) in the User Properties section under the Message Properties tab of the Receiver adapter:
┌─────────────┬───────────────────────────────────────────────────────────────┐
│ Key │ Value │
├─────────────┼───────────────────────────────────────────────────────────────┤
│ traceparent │ 00-<32-hex-char-trace-id>-<16-hex-char-span-id>-<trace-flags> │
├─────────────┼───────────────────────────────────────────────────────────────┤
│ tracestate │ (optional) vendor-specific key-value pairs │
└─────────────┴───────────────────────────────────────────────────────────────┘
The value must follow the Trace Context format exactly:
traceparent = 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01
Where:
- 00 = version
- 32 lowercase hex chars = trace-id
- 16 lowercase hex chars = parent span-id
- 01 = sampled (00 = not sampled)
When set in User Properties, the adapter writes these into the message’s SDTMap via XMLMessage.setProperties(). The Solace broker’s distributed tracing feature reads from this same location (this is the same mechanism used by the official solace-opentelemetry-jcsmp-integration library’s SolaceJCSMPTextMapSetter/SolaceJCSMPTextMapGetter). The broker should then use your provided trace-id when generating its OTEL spans for Dynatrace, linking them to your upstream trace.
Dynamic trace context propagation
If your iFlow receives an inbound HTTP request that already carries a traceparent header (e.g., from an upstream system with its own tracing), you can propagate it dynamically rather than hardcoding a value:
- Add traceparent to the iFlow’s Runtime Configuration > Allowed Header(s) allowlist
- In the Receiver adapter’s User Properties, set:
- Key: traceparent
- Value: ${header.traceparent}
This uses the adapter’s Camel expression support to dynamically resolve the value from the exchange header at runtime, so each message carries the correct trace context from its originating request.
To directly answer your three questions
- Is the AEM adapter capable of setting a property that the Solace broker would recognise for distributed tracing? – Yes, but it must be set via User Properties (Message Properties tab), not JCSMP Properties (Connection tab).
- Is the property name “traceparent” correct? – Yes, traceparent is the correct key name per the W3C Trace Context specification. The broker recognises this key when it appears in the message’s User Properties (SDTMap).
- Why does the broker generate its own trace-id? – Because the traceparent set in JCSMP Properties (Connection tab) is a session-level configuration and does not get placed onto the published message. The broker sees no trace context on the incoming message and therefore creates a new root span.
Important note
The AEM adapter does not natively generate or instrument traces itself – it has no built-in OpenTelemetry integration. However, it can pass through an existing trace context to the broker via User Properties, which is sufficient for your use case of continuing an existing trace through the broker to Dynatrace.
I hope that helps – please let us know if you run into any issues after moving the property to User Properties.
Regards,
Sunil
