B2B Integration

 View Only
  • 1.  SI 5.2.6 - Help with Extended Hex Characters

    Posted Thu June 10, 2021 08:21 AM
    Hello,

    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



    ------------------------------
    Karen Gallello
    Karen
    ------------------------------

    #B2BIntegration
    #SupplyChain


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

    Posted Tue June 15, 2021 12:12 PM
    Karen,
    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
    ------------------------------



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

    Posted Wed June 16, 2021 08:20 AM
    Hi Mark,

    I would like to try the Encoding Conversion service.  Our ERP system uses CCSID 13488 (Unicode) and the customer wants the file in US English.  

    So for the input_encoding would I enter '13488' or 'Unicode' and what would I enter for the output_encoding to reflect US English?

    Regards,

    Karen

    ------------------------------
    Karen Gallello
    Karen
    ------------------------------



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

    Posted Wed June 16, 2021 08:38 AM
    Karen,
    Here is a sample of using the encoder service:
    <operation name="Encoding Conversion">
    <participant name="EncodingConversion"/>
    <output message="EncodingConversionTypeInputMessage">
    <assign to="." from="*"></assign>
    <assign to="output_encoding">Cp1252</assign>
    <assign to="input_encoding">Cp1252</assign>
    <assign to="." from="*"></assign>
    </output>
    <input message="inmsg">
    <assign to="." from="*"></assign>
    </input>
    </operation>

    It might take a few tries to get the right encoder name for the Java version you are running, but looking those up are key to matching them to your needs. Can check and the 13488 might be correct. There is no English, but UTF-8 is a common encoding for America and the default for B2Bi.

    ------------------------------
    Mark Murnighan
    Solution Architect
    ------------------------------