- 6 minutes to read

XML to XML Transformation

Transform Log Event XML into cleansed, business-friendly formats for end-user viewing in Log Views.

Why Transform XML to XML?

Most stylesheets transform XML to HTML for visual presentation in Log Views. But there are compelling business reasons to keep the output as XML:

Security & Compliance

  • Remove sensitive data - Strip PII (Personally Identifiable Information), credentials, or confidential business data before displaying to end users in Log Views
  • Meet compliance requirements - GDPR, HIPAA, PCI-DSS often prohibit showing certain fields to operations teams or auditors
  • Audit trail safety - Log Views are accessible to multiple users; cleansed XML reduces exposure risk

Business User Friendliness

  • Strip technical noise - Remove verbose SOAP envelopes, namespaces, or wrapper elements to show only the business payload
  • Simplify structure - Transform complex nested XML into flat, readable format for operations teams who aren't XML experts
  • Focus on business data - End users see just the order details, customer information, or transaction data—not SOAP protocol overhead

Technical Integration

  • Enable copy-paste - Users can copy the cleansed XML from Log Views and paste into other tools, testing systems, or support tickets
  • Support downstream analysis - Analysts can export and parse clean XML for reporting or data investigation
  • Standardize formats - Convert various message formats into a consistent structure for easier troubleshooting

Common Use Cases

  1. Strip SOAP envelope - Remove web service wrappers to expose just the business message in Log Views
  2. Mask customer data - Replace credit card numbers, SSNs, or emails with *** before displaying in Log Views
  3. Remove credentials - Strip username/password fields from authentication messages visible to support staff
  4. Simplify structure - Transform complex nested XML into flat format for operations teams viewing Log Events

Tip

This stylesheet applies to Log Events in Log Views, not alarm emails. If you're looking for alarm email customization, see Alarm Plugin Object for XSLT examples that transform alarm data to HTML.

Example: Strip SOAP Envelope

This example demonstrates the most common XML-to-XML transformation: extracting the business payload from a SOAP web service envelope for display in Log Views.

Understanding the Transformation

What it does

  • Removes the outer SOAP <Envelope> wrapper
  • Extracts content from <Body> element
  • Strips all namespace prefixes (soap:, soapenv:)
  • Preserves the business message structure and data

When to use it

  • Operations teams viewing Log Events need to see just the business data, not SOAP protocol overhead
  • End users aren't familiar with SOAP structure and find envelopes confusing
  • You want cleaner, more readable Log Views focused on business content

XSLT Code

The stylesheet uses XSLT templates to navigate the SOAP structure and extract only the business content:

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" exclude-result-prefixes="soap">
  <xsl:output method="xml" omit-xml-declaration="yes" version="1.0" encoding="UTF-8" indent ="yes"/>
  <xsl:template match="/">
    <xsl:apply-templates select="soapenv:Envelope/soapenv:Body/*"/>
  </xsl:template>
  <xsl:template match="*">
    <xsl:element name="{local-name()}">
      <xsl:apply-templates select="@*|node()"/>
    </xsl:element>
  </xsl:template>

  <xsl:template match="@*">
    <xsl:attribute name="{local-name()}">
      <xsl:value-of select="."/>
    </xsl:attribute>
  </xsl:template>
</xsl:stylesheet>

How it works

  1. Root template (match="/") - Selects only the content inside <Body>, ignoring the <Envelope> wrapper
  2. Element template (match="*") - Recreates each element using local-name() to strip namespace prefixes
  3. Attribute template (match="@*") - Preserves all attributes while removing namespace prefixes
  4. Output formatting - Indents the result for readability with indent="yes"

Input XML

A typical SOAP message with envelope wrapper and business payload:

<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" soap:encodingStyle="http://www.w3.org/2003/05/soap-encoding">
  <soap:Body>
    <Orders>
      <Order state="OK">
        <Id>1337</Id>
      </Order>      
    </Orders> 
  </soap:Body>
</soap:Envelope>

Notice

  • <soap:Envelope> wrapper - Protocol overhead, not business data
  • <soap:Body> container - Holds the actual business message
  • <Orders> element - The business payload operations teams care about

Output XML

After applying the XSLT transformation, only the clean business payload remains:

<Orders>
  <Order state="OK">
    <Id>1337</Id>
  </Order>
</Orders>

Result

  • SOAP envelope completely removed
  • Namespace prefixes stripped
  • Business message preserved exactly
  • Clean, readable XML for operations teams viewing Log Events

Advanced: Remove Sensitive Data

Beyond stripping envelopes, you can mask or remove sensitive fields for compliance and security before displaying in Log Views.

Example: Mask Credit Card Numbers 

<!-- Add to your stylesheet templates -->
<xsl:template match="CreditCardNumber">
  <CreditCardNumber>****-****-****-****</CreditCardNumber>
</xsl:template>

<xsl:template match="SSN">
  <SSN>***-**-****</SSN>
</xsl:template>

Example: Remove Elements Entirely 

<!-- Completely remove password fields -->
<xsl:template match="Password"/>
<xsl:template match="ApiKey"/>

Business value

  • Compliance - Meet GDPR, HIPAA, PCI-DSS requirements by not displaying sensitive data in Log Views accessible to multiple users
  • Security - Log Views may be viewed by support staff, auditors, or operations teams who shouldn't see customer PII
  • Access control - Operations teams can troubleshoot messages without seeing customer confidential data

Configuration Steps

  1. Create a new Stylesheet in Nodinite
  2. Paste the XSLT code and customize for your XML structure
  3. Test the transformation using sample Log Events
  4. Associate the stylesheet with your Log Views
  5. Click Save

Important Considerations

Browser rendering

  • XML will display in Log Views as plain text or formatted XML depending on browser capabilities
  • Most modern browsers provide collapsible XML tree views for better readability
  • Users can copy-paste the XML output for use in other tools

Performance

  • XSLT transformations run when users view Log Events in Log Views
  • For Log Views with thousands of events, keep transformations simple and efficient
  • Complex XPath expressions or recursive templates may slow down Log View rendering

Validation

  • Test your transformation with various message samples to ensure proper handling of edge cases
  • Verify that masked/removed fields don't break XML structure
  • Ensure output is well-formed XML that browsers can display correctly

Next Step

  • Stylesheets - Learn about other stylesheet types and use cases

Alarm Plugin Object - Transform alarm object XML with XSLT for emails
XML Passthrough - Debug stylesheet for raw XML output in emails
Stylesheets - Understanding stylesheet types and capabilities
Base64Decode XML from JSON - Another XML transformation example