Edge Delta Parse XML Processor

The Edge Delta Parse XML Processor parses XML strings into structured data, maintaining the full structure of the XML document.

6 minute read

Overview

The parse XML processor parses an XML string into structured data. Unlike ParseSimplifiedXML it maintains the entire structure of the XML document, including attributes, content within tags, and the hierarchy of elements.

Configuration

Consider the following log:

<log type="access">
  <!-- Log entry for a web request -->
  <details>
    <host>172.17.15.39</host>
    <userIdentifier>68b148de-7ce3-423c-b72d-64a4f21ecfc0</userIdentifier>
    <timeLocal>2024-12-15T22:40:53.723160Z</timeLocal>
  </details>
  <requestInfo>
    <method>POST</method>
    <request>/styles/main.css</request>
    <protocol>HTTP/2</protocol>
  </requestInfo>
  <response>
    <status>403</status>
    <bytesSent>1043</bytesSent>
  </response>
  <message>This is a sample log entry</message>
</log>

It can be parsed into attributes with the following processor configuration:

YAML version:

- name: Multi Processor_fa8d
  type: sequence
  processors:
  - type: ottl_transform
    metadata: '{"id":"XwnTywTL9ZQHiMlUzyb2e","type":"parse-xml","name":"Parse XML"}'
    statements: |-
      merge_maps(attributes, ParseXML(body), "upsert") where IsMap(attributes)
      set(attributes, ParseXML(body)) where not IsMap(attributes)

Output:

{
  "_type": "log",
  "timestamp": 1745310134812,
  "body": "<log type=\"access\"><!-- Log entry for a web request --><details><host>172.17.15.39</host><userIdentifier>68b148de-7ce3-423c-b72d-64a4f21ecfc0</userIdentifier><timeLocal>2024-12-15T22:40:53.723160Z</timeLocal></details><requestInfo><method>POST</method><request>/styles/main.css</request><protocol>HTTP/2</protocol></requestInfo><response><status>403</status><bytesSent>1043</bytesSent></response><message>This is a sample log entry</message></log>",
  "resource": {
...
  },
  "attributes": {
    "attributes": {
      "type": "access"
    },
    "children": [
      {
        "children": [
          {
            "content": "172.17.15.39",
            "tag": "host"
          },
          {
            "content": "68b148de-7ce3-423c-b72d-64a4f21ecfc0",
            "tag": "userIdentifier"
          },
          {
            "content": "2024-12-15T22:40:53.723160Z",
            "tag": "timeLocal"
          }
        ],
        "tag": "details"
      },
      {
        "children": [
          {
            "content": "POST",
            "tag": "method"
          },
          {
            "content": "/styles/main.css",
            "tag": "request"
          },
          {
            "content": "HTTP/2",
            "tag": "protocol"
          }
        ],
        "tag": "requestInfo"
      },
      {
        "children": [
          {
            "content": "403",
            "tag": "status"
          },
          {
            "content": "1043",
            "tag": "bytesSent"
          }
        ],
        "tag": "response"
      },
      {
        "content": "This is a sample log entry",
        "tag": "message"
      }
    ],
    "tag": "log"
  }
}

Note: It could be less nested, without the tag, children, and content tags if you use a custom processor with the ParseSimplifiedXML OTTL function.

Options

Select a telemetry type

You can specify, log, metric, trace or all. It is specified using the interface, which generates a YAML list item for you under the data_types parameter. This defines the data item types against which the processor must operate. If data_types is not specified, the default value is all. It is optional.

It is defined in YAML as follows:

- name: multiprocessor
  type: sequence
  processors:
  - type: <processor type>
    data_types:
    - log

condition

The condition parameter contains a conditional phrase of an OTTL statement. It restricts operation of the processor to only data items where the condition is met. Those data items that do not match the condition are passed without processing. You configure it in the interface and an OTTL condition is generated. It is optional.

Important: All conditions must be written on a single line in YAML. Multi-line conditions are not supported.

Comparison Operators

Operator	Name	Description	Example
`==`	Equal to	Returns `true` if both values are exactly the same	`attributes["status"] == "OK"`
`!=`	Not equal to	Returns `true` if the values are not the same	`attributes["level"] != "debug"`
`>`	Greater than	Returns `true` if the left value is greater than the right	`attributes["duration_ms"] > 1000`
`>=`	Greater than or equal	Returns `true` if the left value is greater than or equal to the right	`attributes["score"] >= 90`
`<`	Less than	Returns `true` if the left value is less than the right	`attributes["load"] < 0.75`
`<=`	Less than or equal	Returns `true` if the left value is less than or equal to the right	`attributes["retries"] <= 3`
`matches`	Regex match	Returns `true` if the string matches a regular expression (generates `IsMatch` function)	`IsMatch(attributes["name"], ".*\\.log$")`

Logical Operators

Important: Use lowercase and, or, not - uppercase operators will cause errors!

Operator	Description	Example
`and`	Both conditions must be true	`attributes["level"] == "ERROR" and attributes["status"] >= 500`
`or`	At least one condition must be true	`attributes["log_type"] == "TRAFFIC" or attributes["log_type"] == "THREAT"`
`not`	Negates the condition	`not regex_match(attributes["path"], "^/health")`

Functions

Function	Description	Example
`regex_match`	Returns `true` if string matches the pattern	`regex_match(attributes["message"], "ERROR\\|FATAL")`
`IsMatch`	Alternative regex function (UI generates this from “matches” operator)	`IsMatch(attributes["name"], ".*\\.log$")`

Field Existence Checks

Check	Description	Example
`!= nil`	Field exists (not null)	`attributes["user_id"] != nil`
`== nil`	Field doesn’t exist	`attributes["optional_field"] == nil`
`!= ""`	Field is not empty string	`attributes["message"] != ""`

Common Examples

- name: _multiprocessor
  type: sequence
  processors:
  - type: <processor type>
    # Simple equality check
    condition: attributes["request"]["path"] == "/json/view"
    
  - type: <processor type>
    # Multiple values with OR
    condition: attributes["log_type"] == "TRAFFIC" or attributes["log_type"] == "THREAT"
    
  - type: <processor type>
    # Excluding multiple values (NOT equal to multiple values)
    condition: attributes["log_type"] != "TRAFFIC" and attributes["log_type"] != "THREAT"
    
  - type: <processor type>
    # Complex condition with AND/OR/NOT
    condition: (attributes["level"] == "ERROR" or attributes["level"] == "FATAL") and attributes["env"] != "test"
    
  - type: <processor type>
    # Field existence and value check
    condition: attributes["user_id"] != nil and attributes["user_id"] != ""
    
  - type: <processor type>
    # Regex matching using regex_match
    condition: regex_match(attributes["path"], "^/api/") and not regex_match(attributes["path"], "^/api/health")
    
  - type: <processor type>
    # Regex matching using IsMatch
    condition: IsMatch(attributes["message"], "ERROR|WARNING") and attributes["env"] == "production"

Common Mistakes to Avoid

# WRONG - Cannot use OR/AND with values directly
condition: attributes["log_type"] != "TRAFFIC" OR "THREAT"

# CORRECT - Must repeat the full comparison
condition: attributes["log_type"] != "TRAFFIC" and attributes["log_type"] != "THREAT"

# WRONG - Uppercase operators
condition: attributes["status"] == "error" AND attributes["level"] == "critical"

# CORRECT - Lowercase operators
condition: attributes["status"] == "error" and attributes["level"] == "critical"

# WRONG - Multi-line conditions
condition: |
  attributes["level"] == "ERROR" and 
  attributes["status"] >= 500  

# CORRECT - Single line (even if long)
condition: attributes["level"] == "ERROR" and attributes["status"] >= 500

Parse from

Specify the field containing the XML.

Assign to

Specify the field where you want the parsed object to be saved.

Final

Determines whether successfully processed data items should continue through the remaining processors in the same processor stack. If final is set to true, data items output by this processor are not passed to subsequent processors within the node—they are instead emitted to downstream nodes in the pipeline (e.g., a destination). Failed items are always passed to the next processor, regardless of this setting.

The UI provides a slider to configure this setting. The default is false. It is defined in YAML as follows:

- name: multiprocessor
  type: sequence
  processors:
    - type: <processor type>
    final: true

Keep original telemetry item

Controls whether the original, unmodified telemetry item is preserved after processing. If keep_item is set to true, the processor emits both:

The original telemetry item (e.g., a log), and
Any new item generated by the processor (e.g., a metric extracted from the log)

Both items are passed to the next processor in the stack unless final is also set.

Interaction with final

If final: true is enabled, any successfully processed data items, whether original, newly created, or both, exit the processor stack or node immediately. No subsequent processors within the same node are evaluated, although downstream processing elsewhere in the pipeline continues. This means:

If keep_item: true and final: true, both the original and processed items bypass the remaining processors in the current node and are forwarded to downstream nodes (such as destinations).
If keep_item: false and final: true, only the processed item continues beyond this processor, skipping subsequent processors in the stack, and the original item is discarded.

Note: If the data item fails to be processed, final has no effect, the item continues through the remaining processors in the node regardless of the keep_item setting.

The app provides a slider to configure keep_item. The default is false.

- name: ed_gateway_output_a3fa_multiprocessor
  type: sequence
  processors:
    - type: <processor_type>
      keep_item: true
      final: true