Addressing BIP6062 in IBM ESB (IIB / IBM ACE) following the OneAgent injection

anton_konikov · ‎12 May 2026

Summary

After OneAgent injection, you might occasionally see the BIP6062: Invalid parser sequence error. According to IBM diagnostics, this occurs because:

The integration node has encountered a message body of type <insert_2> followed by a message header of type <insert_1>. It is not valid to have message headers following message bodies.

Background

The header in IBM ESB can be manipulated in a different ways and one of the possibility to build an outgoing message in the Compute node. Below is the simple message flow that receives HTTP request and then prepare a JSON for reply:

The message structure after PrepareReplyMessage Compute node:

As we can see the JSON folder is placed between HTTPReplyHeader and HTTPRequestHeader:

Message
├── Properties
├── HTTPReplyHeader
│   ├── Content-Type: CHARACTER:application/json
│   ├── X-Global-Transaction-ID: CHARACTER:9ad8a9f5-0a3c-4d3e-99c0-b746a1e03c85
│   ├── X-Correlation-ID: CHARACTER:0eb4c033-8028-467d-862b-56257558b753
│   ├── timestamp: CHARACTER:2026-04-16T00:56:28.306-8
│   └── messageId: CHARACTER:20260416005628306
├── JSON
│   └── Data
│       ├── firstName: CHARACTER:John
│       ├── lastName: CHARACTER:Doe
│       ├── age: INTEGER:34
│       ├── sex: CHARACTER:male
│       ├── height: INTEGER:181
│       ├── weight: INTEGER:78
│       ├── email: CHARACTER:john.doe@example.com
│       ├── phone: CHARACTER:+1-555-234-5678
│       ├── dateOfBirth: CHARACTER:1991-07-12
│       └── address
│           ├── street: CHARACTER:742 Evergreen Terrace
│           ├── city: CHARACTER:Springfield
│           ├── state: CHARACTER:IL
│           ├── postalCode: CHARACTER:62704
│           └── country: CHARACTER:US
└── HTTPRequestHeader    <--- [ERROR: header follows the Message Body]
    ├── Accept: CHARACTER:application/json
    └── Content-Type: CHARACTER:application/json

In this case, if the message propagates to the HTTPReply node, the client will receive the response and the transaction is being finished after the reply:

curl -kv -X POST "http://localhost:7800/BIP6062" -H "Content-Type: application/json" -d "{\"query\":{\"firstName\":\"John\",\"lastName\":\"Doe\",\"dateOfBirth\":\"1991-07-12\"}}"
Note: Unnecessary use of -X or --request, POST is already inferred.
* Host localhost:7800 was resolved.
* IPv6: ::1
* IPv4: 127.0.0.1
*   Trying [::1]:7800...
*   Trying 127.0.0.1:7800...
* Connected to localhost (127.0.0.1) port 7800
* using HTTP/1.x
> POST /BIP6062 HTTP/1.1
> Host: localhost:7800
> User-Agent: curl/8.13.0
> Accept: */*
> Content-Type: application/json
> Content-Length: 74
>
* upload completely sent off: 74 bytes
< HTTP/1.1 200 OK
< Content-Type: application/json
< X-Global-Transaction-ID: c648a831-c8a7-422a-a5f9-0321c77f1c72
< X-Correlation-ID: 4715187b-df87-4ac2-a69c-1f9da4717327
< timestamp: 2026-04-16T00:59:52.287-8
< messageId: 20260416005952287
< X-Original-HTTP-Status-Code: 200
< Server: IBM App Connect Enterprise
< Date: Thu, 16 Apr 2026 08:59:53 GMT
< Content-Length: 283
<
{"firstName":"John","lastName":"Doe","age":34,"sex":"male","height":181,"weight":78,"email":"john.doe@example.com","phone":"+1-555-234-5678","dateOfBirth":"1991-07-12","address":{"street":"742 Evergreen Terrace","city":"Springfield","state":"IL","postalCode":"62704","country":"US"}}* Connection #0 to host localhost left intact

Problem

After OneAgent injection, one can see that the behavior has changed and that the IBM ESB now throws the next exception and the transaction is rolling back:

Why IBM parser exceptions are not caused by OneAgent, but can be exposed by it

When you install a monitoring agent like Dynatrace OneAgent, it registers a C-level User Exit within the integration node. This User Exit hooks into specific lifecycle events, such as when a message leaves a node (Propagate event).
So when there is a User Exit, the IBM ESB invokes parsers and this base parser is strictly bound by the rules of the Web Services/HTTP domain. It traverses the tree strictly from top to bottom. If the message structure is incorrect, an error is thrown.

The IBM documentation is explicit about how a message tree should be structured. Specifically, it states:

Any additional headers that are included in the message appear in the tree in the same order as in the message. The last element beneath the root of the message tree is always the message body.

This rule is foundational. It ensures that parsers and other components in the message flow can reliably locate and process the message's content.

When this structural integrity is not maintained, an invalid parser sequence can be thrown. This error indicates that the parser was unable to interpret the message tree, which can happen if it expects to find the message body as the final element but encounters something else instead.

It is important to note that this is not an issue specific to any single monitoring tool, such as OneAgent. Rather, it is a direct consequence of altering the message flow in a way that violates the core principle of the message tree's structure.

Reproducing IBM Parser Exceptions Independent of OneAgent

The same issue can be reliably reproduced with adding extra nodes to continue the transaction and for example trace the output after HTTPReply node by Trace nodes.

Resolution

To resolve the BIP6062: Invalid parser sequence error, the structure of the message tree must be amended to ensure that it strictly adheres to IBM's structural requirements. The message body (such as JSON, XMLNSC, or BLOB) must always be instantiated as the last element in the OutputRoot.

In the example provided above, the HTTPRequestHeader was incorrectly placed after the JSON domain.

Enforcing the correct order (Properties -> Headers -> Body) ensures that the integration node's parsers, and subsequently the Dynatrace OneAgent code module for IBM ESB, successfully traverse the message tree without throwing an invalid sequence exception.

Below is the corrected message structure, updated to comply with IBM's structural requirements:

Message
├── Properties
├── HTTPReplyHeader
│   ├── Content-Type: CHARACTER:application/json
│   ├── X-Global-Transaction-ID: CHARACTER:9ad8a9f5-0a3c-4d3e-99c0-b746a1e03c85
│   ├── X-Correlation-ID: CHARACTER:0eb4c033-8028-467d-862b-56257558b753
│   ├── timestamp: CHARACTER:2026-04-16T00:56:28.306-8
│   └── messageId: CHARACTER:20260416005628306
├── HTTPRequestHeader    <--- [The header is placed before the Message Body]
│   ├── Accept: CHARACTER:application/json
│   └── Content-Type: CHARACTER:application/json
└── JSON                 <--- [Moving the message body as the last element]
    └── Data
        ├── firstName: CHARACTER:John
        ├── lastName: CHARACTER:Doe
        ├── age: INTEGER:34
        ├── sex: CHARACTER:male
        ├── height: INTEGER:181
        ├── weight: INTEGER:78
        ├── email: CHARACTER:john.doe@example.com
        ├── phone: CHARACTER:+1-555-234-5678
        ├── dateOfBirth: CHARACTER:1991-07-12
        └── address
            ├── street: CHARACTER:742 Evergreen Terrace
            ├── city: CHARACTER:Springfield
            ├── state: CHARACTER:IL
            ├── postalCode: CHARACTER:62704
            └── country: CHARACTER:US

Note: The specific message structure shown in this example is provided solely for demonstration purposes to illustrate the root cause of the problem. Your actual message tree, the domains used (e.g., XMLNSC, BLOB instead of JSON), and the specific headers involved might be completely different in your particular environment. Regardless of your exact configuration, you must always pay close attention to your message structure and ensure it adheres to the strict rule that the message body is always the final element in the tree.

What’s next

If this article does not fully resolve the issue:

Open a Dynatrace support ticket.