[solved] XSLT incomming mapping with base64 payload

lis9 · Post by **lis9** » 01 Jul 2025, 13:29

Hello,

I’m encountering an issue with my outgoing WebService integration. I’m communicating with the DHL Api2 (SOAP) using the getEpod method to retrieve a proof of delivery in PDF format.

The communication works smoothly, and I receive the response correctly. However, I have to store the payload as an article attachment using XSLT mapping, and that’s where I run into trouble.

Here’s the relevant part of my incoming XSLT mapping:

Code: Select all

<?xml version="1.0" encoding="UTF-8"?>
<xsl:transform version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:date="http://exslt.org/dates-and-times" extension-element-prefixes="date">
  <xsl:output method="xml" encoding="utf-8" indent="yes"/>
  <xsl:template match="RootElement">
    <xsl:copy>
      <OTRS_TicketArticleAdd>
        <CommunicationChannel>Internal</CommunicationChannel>
        <IsVisibleForCustomer>1</IsVisibleForCustomer>
        <SenderType>system</SenderType>
        <From>root@localhost</From>
        <Subject>Retrieve POD</Subject>
        <Body>
          The POD attachment was successfully imported from the DHL service.
        </Body>
        <ContentType>text/plain; charset=utf-8</ContentType>
        <HistoryType>AddNote</HistoryType>
        <HistoryComment>Technical note – POD attachment retrieved from DHL Api2 has been saved.</HistoryComment>
        <Attachment>
          <Filename>POD.pdf</Filename>
          <ContentType><xsl:value-of select="//getEpodResult/scanMimeType"/></ContentType>
          <Content><xsl:value-of select="//getEpodResult/scanData"/></Content>
        </Attachment>
      </OTRS_TicketArticleAdd>
      <OTRS_TicketDynamicFieldSet_PODApi>0</OTRS_TicketDynamicFieldSet_PODApi>
    </xsl:copy>
  </xsl:template>
</xsl:transform>

Everything works fine except for one thing: the attachment is not stored in the expected PDF format. Instead, its content remains base64-encoded.

Should I modify my mapping to decode the content, or is this a known issue (bug) in the system?

Kind regards,
Daniel Lisiecki

lis9 · Post by **lis9** » 02 Jul 2025, 09:47

Hello,

Following up on the issue with attachment encoding, I've identified the root cause.

When the OTRS_TicketArticleAdd operation is invoked, it calls the Kernel::System::Ticket::Article::ArticleCreate module internally. My investigation shows that this module saves the attachment file directly in binary mode, without first decoding the Base64 content that is passed to it. This explains why the attachments were being stored as raw Base64 strings instead of proper PDF files.

To resolve this, I've implemented a custom invoker. This invoker intercepts the attachment data (whether it's a HASH or an ARRAY) and performs a decode_base64 operation on the content before calling the Kernel::System::Ticket::Article::ArticleCreate module.

This approach ensures that the attachment data is correctly decoded prior to being saved by Znuny, allowing the files to be stored in their intended format (e.g., PDF).

Kind regards,

Daniel Lisiecki

Post by **root** » 02 Jul 2025, 14:39

Hello,

This seems to be a bug.

- Roy

lis9 · Post by **lis9** » 04 Jul 2025, 10:37

Thank you very much for your opinion. I've created the issue on GitHub for this.
https://github.com/znuny/Znuny/issues/694

Daniel Lisiecki

Znuny Open Source Ticketsystem

[solved] XSLT incomming mapping with base64 payload

[solved] XSLT incomming mapping with base64 payload

[solved] Re: XSLT incomming mapping with base64 payload

Re: [solved] XSLT incomming mapping with base64 payload

Re: [solved] XSLT incomming mapping with base64 payload