B2B Integration

Expand all | Collapse all

SI 5.2.6 - Help with Extended Hex Characters

  • 1.  SI 5.2.6 - Help with Extended Hex Characters

    Posted 5 days ago

    We are having an issue with SI translating extended hex characters and are currently using keyword replace to handle.  However, I'd like to find a more permanent solution.

    Data coming from our ERP system sometimes has extended hex characters that Sterling does not translate properly.  I've tried adding the extended hex characters to the map which works fine until the process hits the Enveloping service.  Here is an example:

    Data before Envelope Service: León (This is how it looks in source ERP system)

    Data during Envelope Service: Le�n (This is how it looks once it hits the Envelope service)

    Data translated as: Le�n (This is how it translated to EDI)

    For this particular customer, we need to send the EDI data using US English only - 'León' should translate as 'Leon'.

    Does anyone have any suggestions?

    Thank you,


    Karen Gallello

  • 2.  RE: SI 5.2.6 - Help with Extended Hex Characters

    Posted 5 hours ago
    It sounds like you are experiencing a character encoding issue. Many systems support localization by using specific character encodings such as ASCII, UTF-8 or GBK.
    Rather than trying to convert a specific character in the data it would be easier to change the whole file all at once using the "Encoding Conversion Service", documentation is here: https://www.ibm.com/docs/en/b2b-integrator/6.1.0?topic=l-encoding-conversion-service

    This makes use of the standard Java supported character sets. So you just need to identify what code set the ERP system is using and convert to what your partner wants (and something the translator likes). There are many references on how to handle this; here is one from IBM to get you started: https://www.ibm.com/docs/en/i/7.4?topic=encodings-fileencoding-values-i-ccsid and this will also provide you a list of the available code set for this version of Java.

    I have found this to be a common issue that deployments encounter as they mature into a global ecosystem.

    Mark Murnighan
    Solution Architect