Base64 Function Modules in SAP ABAP

[isuru_fernando24]

The base64 algorithm is an efficient way to transfer data via the Internet. In SAP, you can use Base64 when you are implementing file-based interfaces between your SAP system and third-party applications via SAP Process Orchestration or SAP Cloud Platform Integration. Instead of sending the file as an attachment in a message you can send file data as a Base64 string. For example, for outbound interfaces, you first need to encode the file in Base64 format and transmit it to the target system as a Base64 string. In the target system, you need to decode the Base64 string back to actual data.

This method comes in handy if you want to implement file-based interfaces via the Application Integration Framework (AIF) as AIF is not able to handle file attachments.

 

This article goes into detail on Function Modules (FM) in SAP that we can use to encode and decode Base64 string. Use encoding FMs for outbound interface messages and decoding FMs for inbound interface messages.

Function Modules for Base64 Encoding:

 

There are two function modules to encode a string to Base64 format. First, convert string to Xstring using 'SCMS_STRING_TO_XSTRING'. Then use 'SCMS_BASE64_ENCODE_STR' to convert Xstring to Base64.

Function Modules for Base64 Decoding:

 

Decoding is a three-step procedure. Convert Base64 string to Xstring using 'SCMS_BASE64_DECODE_STR'. Next, transform the Xstring to Binary using function module 'SCMS_XSTRING_TO_BINARY'. Finally, turn the Binary format to String via 'SCMS_BINARY_TO_STRING'.

How to Decode and Encode Base64 in SAP PI/PO and CPI

 

In most instances, you will use SAP Process Orchestration (PO) to interface between SAP and third-party applications. In these instances, we can use mapping techniques such as User Defined Functions (UDFs), Java Mappings or Adapter Modules to decode and encode Base64.

However, CPI of SAP Integration Suite has standard converter modules to encode and decode Base64.

I have also developed a sample program to decode/encode base64 in ABAP.

To summarize, you can use Base64 string to transfer data such as files, PDFs, images, etc. between SAP and external APIs. Using this method you can avoid sending files as attachments in the message payload. Use the FMs listed above to Encode and Decode Base64 in your SAP application or interface program.

Thank you for reading, hope this information will help you design interfaces.

 

Cheers!

[Tomas_Buryanek]

Hello,
i would like to add that there are also BASE64 methods in CL_HTTP_UTILITY class:

DECODE_BASE64

ENCODE_BASE64

DECODE_X_BASE64

ENCODE_X_BASE64

And I personally prefer to use this class instead of (unreleased) functions.

[larshp]

"secure and efficient", can you elaborate on this part? From a security perspective, the data is not encrypted or checksummed, for efficiency, base64 encoded data is typically larger than the original.

[Sandra_Rossi]

If you talk about SCMS_STRING_TO_XSTRING then you may complete that it encodes the string in UTF-8 by default. Idem for the decoding, you convert from a xstring text in UTF-8. Note that instead of all those old function modules, you may use CL_ABAP_CODEPAGE (ABAP 7.02 to 7.52), that's much shorter:

DATA: xstr TYPE xstring,

      str  TYPE string.

TRY.



str = cl_abap_codepage=>convert_from( source = xstr ). " default is UTF-8



xstr = cl_abap_codepage=>convert_to( source = str ). " default is UTF-8



CATCH cx_root.

  " handle conversion errors

ENDTRY.

[isuru_fernando24]

Hello Thomas,

Certainly, CL_HTTP_UTILITY class methods you have given can be used to encode and decode base64. I have included these methods in my original post.

Thank you!

[isuru_fernando24]

Thank you for sharing Sandra!

[Isaias_SAP]

Indeed…

If you want to add security, transmit the data using HTTPS or SNC 😉

[former_member607044]

Thank you for sharing Sandra!

Useful Code!!

[marco-silva]

Hello,

Thank you for this blog!

I'm getting a corrupted PDF with this code:

  DATA: lv_base64_pdf        TYPE string,

        lv_decodedx          TYPE xstring,

        lv_fullpath          TYPE string,

        lv_bin_filesize      TYPE i,

        lt_data              TYPE solix_tab.



    CLEAR: lv_decodedx.



    CALL METHOD cl_http_utility=>if_http_utility~decode_x_base64

      EXPORTING

        encoded = lv_base64_pdf

      RECEIVING

        decoded = lv_decodedx.



    CALL METHOD cl_bcs_convert=>xstring_to_solix

      EXPORTING

        iv_xstring = lv_decodedx

      RECEIVING

        et_solix   = lt_data.



    lv_bin_filesize = xstrlen( lv_decodedx ).

	

    CALL METHOD cl_gui_frontend_services=>gui_download

      EXPORTING

        bin_filesize            = lv_bin_filesize

        filename                = lv_fullpath

        filetype                = 'BIN'

        show_transfer_status    = ' '

      CHANGING

        data_tab                = lt_data.

Any clue about what can be wrong?

Thank you!

 

Best regards,

Marco Silva

[Sandra_Rossi]

Your code looks completely correct. Are you sure the PDF base64 is correct at the beginning?

[marco-silva]

Hello,

Yes, I'm sure! If I perform this I get my base64 file.

    DATA: lt_soli TYPE soli_tab.



    CALL FUNCTION 'CONVERT_STRING_TO_TABLE'

      EXPORTING

        i_string         = lv_base64_pdf

        i_tabline_length = 255

      TABLES

        et_table         = lt_soli.



    CALL METHOD cl_gui_frontend_services=>gui_download

      EXPORTING

        filename             = lv_fullpath

        filetype             = 'ASC'

        show_transfer_status = ' '

      CHANGING

        data_tab             = lt_soli

      EXCEPTIONS

        OTHERS               = 1.

Using an online base64 decoder like https://www.freeformatter.com/base64-encoder.html I'm able to get a working PDF...

I don't know if it can be an issue of my SAP server... Something about encoding... I'm on a ECC6 EHP8 SP8 (BASIS 750 SP9).

Regards,

Marco

[marco-silva]

I guess I have a good hint. If I perform this:

    CALL METHOD cl_http_utility=>if_http_utility~decode_x_base64

      EXPORTING

        encoded = lv_base64_pdf

      RECEIVING

        decoded = lv_decodedx.



    CALL METHOD cl_http_utility=>if_http_utility~encode_x_base64

      EXPORTING

        unencoded = lv_decodedx

      RECEIVING

        encoded   = lv_base64_pdf.

My base64 PDF gets corrupted.



The good one is the one that has ">>". I get more differences with this "ÿ" strange character in the files...

I've tried all the base64 decode function modules and class methods that I could find in my system and I always get the same result...

Any clue?

Regards,

Marco

[Sandra_Rossi]

As I said, no issue at my side with your code, the base64 decoding works and I can open the downloaded file correctly:

PARAMETERS fullpath TYPE string LOWER CASE DEFAULT 'C:\Users\yourname\Downloads\test.pdf'.



DATA(lv_base64_pdf) = VALUE string( ).

PERFORM get_very_small_pdf_base64 CHANGING lv_base64_pdf.

DATA(pdf_reloaded) = VALUE xstring( ).

PERFORM download_pdf USING lv_base64_pdf fullpath CHANGING pdf_reloaded.



FORM download_pdf

    USING

        lv_base64_pdf TYPE string

        lv_fullpath   TYPE string

    CHANGING

        lv_decodedx   TYPE xstring.



  DATA: lv_bin_filesize TYPE i,

        lt_data         TYPE solix_tab.



  CLEAR: lv_decodedx.



  CALL METHOD cl_http_utility=>if_http_utility~decode_x_base64

    EXPORTING

      encoded = lv_base64_pdf

    RECEIVING

      decoded = lv_decodedx.



  CALL METHOD cl_bcs_convert=>xstring_to_solix

    EXPORTING

      iv_xstring = lv_decodedx

    RECEIVING

      et_solix   = lt_data.



  lv_bin_filesize = xstrlen( lv_decodedx ).



  CALL METHOD cl_gui_frontend_services=>gui_download

    EXPORTING

      bin_filesize         = lv_bin_filesize

      filename             = lv_fullpath

      filetype             = 'BIN'

      show_transfer_status = ' '

    CHANGING

      data_tab             = lt_data.



ENDFORM.



FORM get_very_small_pdf_base64 CHANGING e_string type string.

  " PDF from http://www.tagg.org/pdftest.pdf University of Liverpool

  CONCATENATE

        'JVBERi0xLjIgDQol4uPP0w0KIA0KOSAwIG9iag0KPDwNCi9MZW5ndGggMTAgMCBSDQovRmlsdGVyIC9GbGF0ZURlY29kZSANCj4+'

        'DQpzdHJlYW0NCkiJzZDRSsMwFIafIO/we6eyZuckTZPtbtIWBi0UjYKQGxFbJmpliuLb26QM8X6CJBfJyf99ycmFF6xJagWrrMxz'

        'wJeCEMd+gFjWBC1dLPeCJFkbl/fTKfwnTqt1CK0xIZyEwFYZ2T+fwT8KnmIxUmJinNKJyUiyW7mZVEQ6I54m2K3ZzFiupvgPaee7'

        'JHFuZqyDvxuGBbZdu8D1y+7jYf+2e//C2KOJm9dxfEqqTHMRXZlR0hRJuKwZau6EJa+MOdjpYN/gprq8xVW7aRp0ZY162ySbktoW'

        'vxpPZULGxJLSr+G4UuX+QHrcl/rz/2eqvPgGPPWhqg0KZW5kc3RyZWFtDQplbmRvYmoNCjEwIDAgb2JqDQoyNDYNCmVuZG9iag0K'

        'NCAwIG9iag0KPDwNCi9UeXBlIC9QYWdlDQovUGFyZW50IDUgMCBSDQovUmVzb3VyY2VzIDw8DQovRm9udCA8PA0KL0YwIDYgMCBS'

        'IA0KL0YxIDcgMCBSIA0KPj4NCi9Qcm9jU2V0IDIgMCBSDQo+Pg0KL0NvbnRlbnRzIDkgMCBSDQo+Pg0KZW5kb2JqDQo2IDAgb2Jq'

        'DQo8PA0KL1R5cGUgL0ZvbnQNCi9TdWJ0eXBlIC9UcnVlVHlwZQ0KL05hbWUgL0YwDQovQmFzZUZvbnQgL0FyaWFsDQovRW5jb2Rp'

        'bmcgL1dpbkFuc2lFbmNvZGluZw0KPj4NCmVuZG9iag0KNyAwIG9iag0KPDwNCi9UeXBlIC9Gb250DQovU3VidHlwZSAvVHJ1ZVR5'

        'cGUNCi9OYW1lIC9GMQ0KL0Jhc2VGb250IC9Cb29rQW50aXF1YSxCb2xkDQovRmlyc3RDaGFyIDMxDQovTGFzdENoYXIgMjU1DQov'

        'V2lkdGhzIFsgNzUwIDI1MCAyNzggNDAyIDYwNiA1MDAgODg5IDgzMyAyMjcgMzMzIDMzMyA0NDQgNjA2IDI1MCAzMzMgMjUwIA0K'

        'Mjk2IDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCAyNTAgMjUwIDYwNiA2MDYgNjA2IA0KNDQ0IDc0NyA3'

        'NzggNjY3IDcyMiA4MzMgNjExIDU1NiA4MzMgODMzIDM4OSAzODkgNzc4IDYxMSAxMDAwIDgzMyANCjgzMyA2MTEgODMzIDcyMiA2'

        'MTEgNjY3IDc3OCA3NzggMTAwMCA2NjcgNjY3IDY2NyAzMzMgNjA2IDMzMyA2MDYgDQo1MDAgMzMzIDUwMCA2MTEgNDQ0IDYxMSA1'

        'MDAgMzg5IDU1NiA2MTEgMzMzIDMzMyA2MTEgMzMzIDg4OSA2MTEgDQo1NTYgNjExIDYxMSAzODkgNDQ0IDMzMyA2MTEgNTU2IDgz'

        'MyA1MDAgNTU2IDUwMCAzMTAgNjA2IDMxMCA2MDYgDQo3NTAgNTAwIDc1MCAzMzMgNTAwIDUwMCAxMDAwIDUwMCA1MDAgMzMzIDEw'

        'MDAgNjExIDM4OSAxMDAwIDc1MCA3NTAgDQo3NTAgNzUwIDI3OCAyNzggNTAwIDUwMCA2MDYgNTAwIDEwMDAgMzMzIDk5OCA0NDQg'

        'Mzg5IDgzMyA3NTAgNzUwIA0KNjY3IDI1MCAyNzggNTAwIDUwMCA2MDYgNTAwIDYwNiA1MDAgMzMzIDc0NyA0MzggNTAwIDYwNiAz'

        'MzMgNzQ3IA0KNTAwIDQwMCA1NDkgMzYxIDM2MSAzMzMgNTc2IDY0MSAyNTAgMzMzIDM2MSA0ODggNTAwIDg4OSA4OTAgODg5IA0K'

        'NDQ0IDc3OCA3NzggNzc4IDc3OCA3NzggNzc4IDEwMDAgNzIyIDYxMSA2MTEgNjExIDYxMSAzODkgMzg5IDM4OSANCjM4OSA4MzMg'

        'ODMzIDgzMyA4MzMgODMzIDgzMyA4MzMgNjA2IDgzMyA3NzggNzc4IDc3OCA3NzggNjY3IDYxMSANCjYxMSA1MDAgNTAwIDUwMCA1'

        'MDAgNTAwIDUwMCA3NzggNDQ0IDUwMCA1MDAgNTAwIDUwMCAzMzMgMzMzIDMzMyANCjMzMyA1NTYgNjExIDU1NiA1NTYgNTU2IDU1'

        'NiA1NTYgNTQ5IDU1NiA2MTEgNjExIDYxMSA2MTEgNTU2IDYxMSANCjU1NiBdDQovRW5jb2RpbmcgL1dpbkFuc2lFbmNvZGluZw0K'

        'L0ZvbnREZXNjcmlwdG9yIDggMCBSDQo+Pg0KZW5kb2JqDQo4IDAgb2JqDQo8PA0KL1R5cGUgL0ZvbnREZXNjcmlwdG9yDQovRm9u'

        'dE5hbWUgL0Jvb2tBbnRpcXVhLEJvbGQNCi9GbGFncyAxNjQxOA0KL0ZvbnRCQm94IFsgLTI1MCAtMjYwIDEyMzYgOTMwIF0NCi9N'

        'aXNzaW5nV2lkdGggNzUwDQovU3RlbVYgMTQ2DQovU3RlbUggMTQ2DQovSXRhbGljQW5nbGUgMA0KL0NhcEhlaWdodCA5MzANCi9Y'

        'SGVpZ2h0IDY1MQ0KL0FzY2VudCA5MzANCi9EZXNjZW50IDI2MA0KL0xlYWRpbmcgMjEwDQovTWF4V2lkdGggMTAzMA0KL0F2Z1dp'

        'ZHRoIDQ2MA0KPj4NCmVuZG9iag0KMiAwIG9iag0KWyAvUERGIC9UZXh0ICBdDQplbmRvYmoNCjUgMCBvYmoNCjw8DQovS2lkcyBb'

        'NCAwIFIgXQ0KL0NvdW50IDENCi9UeXBlIC9QYWdlcw0KL01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXQ0KPj4NCmVuZG9iag0KMSAw'

        'IG9iag0KPDwNCi9DcmVhdG9yICgxNzI1LmZtKQ0KL0NyZWF0aW9uRGF0ZSAoMS1KYW4tMyAxODoxNVBNKQ0KL1RpdGxlICgxNzI1'

        'LlBERikNCi9BdXRob3IgKFVua25vd24pDQovUHJvZHVjZXIgKEFjcm9iYXQgUERGV3JpdGVyIDMuMDIgZm9yIFdpbmRvd3MpDQov'

        'S2V5d29yZHMgKCkNCi9TdWJqZWN0ICgpDQo+Pg0KZW5kb2JqDQozIDAgb2JqDQo8PA0KL1BhZ2VzIDUgMCBSDQovVHlwZSAvQ2F0'

        'YWxvZw0KL0RlZmF1bHRHcmF5IDExIDAgUg0KL0RlZmF1bHRSR0IgIDEyIDAgUg0KPj4NCmVuZG9iag0KMTEgMCBvYmoNClsvQ2Fs'

        'R3JheQ0KPDwNCi9XaGl0ZVBvaW50IFswLjk1MDUgMSAxLjA4OTEgXQ0KL0dhbW1hIDAuMjQ2OCANCj4+DQpdDQplbmRvYmoNCjEy'

        'IDAgb2JqDQpbL0NhbFJHQg0KPDwNCi9XaGl0ZVBvaW50IFswLjk1MDUgMSAxLjA4OTEgXQ0KL0dhbW1hIFswLjI0NjggMC4yNDY4'

        'IDAuMjQ2OCBdDQovTWF0cml4IFswLjQzNjEgMC4yMjI1IDAuMDEzOSAwLjM4NTEgMC43MTY5IDAuMDk3MSAwLjE0MzEgMC4wNjA2'

        'IDAuNzE0MSBdDQo+Pg0KXQ0KZW5kb2JqDQp4cmVmDQowIDEzDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDIxNzIgMDAwMDAg'

        'bg0KMDAwMDAwMjA0NiAwMDAwMCBuDQowMDAwMDAyMzYzIDAwMDAwIG4NCjAwMDAwMDAzNzUgMDAwMDAgbg0KMDAwMDAwMjA4MCAw'

        'MDAwMCBuDQowMDAwMDAwNTE4IDAwMDAwIG4NCjAwMDAwMDA2MzMgMDAwMDAgbg0KMDAwMDAwMTc2MCAwMDAwMCBuDQowMDAwMDAw'

        'MDIxIDAwMDAwIG4NCjAwMDAwMDAzNTIgMDAwMDAgbg0KMDAwMDAwMjQ2MCAwMDAwMCBuDQowMDAwMDAyNTQ4IDAwMDAwIG4NCnRy'

        'YWlsZXINCjw8DQovU2l6ZSAxMw0KL1Jvb3QgMyAwIFINCi9JbmZvIDEgMCBSDQovSUQgWzw0NzE0OTUxMDQzM2RkNDg4MmYwNWY4'

        'YzEyNDIyMzczND48NDcxNDk1MTA0MzNkZDQ4ODJmMDVmOGMxMjQyMjM3MzQ+XQ0KPj4NCnN0YXJ0eHJlZg0KMjcyNg0KJSVFT0YN'

        'CgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA'

        'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA'

        'AAAAAAAAAAAAAAAAAAAA'

        INTO e_string.

ENDFORM.

[marco-silva]

Sandra,

Thank you for your time.

When I validate the base64 here I get the following message:

• The specified value is not a valid Base64 string. Try to specify a different standard.

• The following characters are not suitable for the specified standard: -_

I’m getting this base64 PDF from Google Gmail API, so I guess the format is not the one expected by SAP… Google API send a “base64url”, which is valid but maybe SAP tools aren’t compatible with that.

Regards,

Marco

[Sandra_Rossi]

"This encoding [base64url] is technically identical to the previous one [base64], except for the 62:nd and 63:rd alphabet character, as indicated in Table 2 [- instead of + and _ instead of /]." (https://tools.ietf.org/html/rfc4648#section-5)

so:

base64 = translate( val = base64url from = '-_' to = '+/' ).

or

base64url = translate( val = base64 from = '+/' to = '-_' ).

[marco-silva]

Dear Sandra,

You are totally right! It works fine now!

Thank you so much for your time!

Regards,

Marco

[rafaelchagas]

Nice work Fernando.

I used it to check my data sent using CPI.

Thanks a lot.

[Chris_Lumb]

I think there is an issue with CL_HTTP_UTILITY=>DECODE_X_BASE64 when new lines/linebreaks are present.

According to this post https://superuser.com/questions/1225134/why-does-the-base64-of-a-string-contain-n we can have new-lines in a base64 encoded string. An old IETF RFC specified a new line after every 76 characters.

From what I'm seeing the CL_HTTP_UTILITY method does not expect new lines and we get a garbled result. The SCMS FM manages to cope with new lines.

If you are using CL_HTTP_UTILITY I suggest removing new lines from your base64 string prior to decoding (perhaps removing chars in CL_ABAP_CHAR_UTILITIES=>CR_LF)

[RaviPadala]

How do we ensure Base64 file  has a valid format while processing external applications. For example uploading passport document in HR using oData service that receives Base64 files.