Originally posted by: SystemAdmin

What is the current best practices for implementing Unicode? I see that in 8.2.0.3 that all options in the Type Designer except Native have been "deprecated". What, if anything, has changed?

I'm working on a multinational SAP ECC 6.0 implementation and the development team wants to convert all type trees to Unicode including the EDIFACT & X12 type trees because that's the way they did it on two previous projects.

I've worked on several dozen SAP implementations in the last 15 years including several multinational implementations and Unicode came up once for some non-EDI interfaces. Those were handled by using an extra output card or two as I recall that were provided by Support to handle the conversion but that was seven years ago.

Jim Divoky
#DataExchange
#IBM-Websphere-Transformation-Extender
#IBMSterlingTransformationExtender

Originally posted by: phil2030

Isn't it a little "dangerous" to just just switch "everything" to UNICODE? (Though your company would be in an enviable position if it can dictate to all your TP's as to how they are going to send/receive EDI transmissions.)

For EDIFACT the defining character set in the UNB would have to be taken into account and agreed with each TP (or group of TP's). I haven't used X12 for a long time so cannot comment other than I would have thought a similar situation would exist.

Either way I would query IBM (if you haven't already) to see if they have UNICODE type trees in the latest EDI packs (or whatever they have nowadays) rather than converting old type trees for presumably previous EDIFACT/X12 releases.
#DataExchange
#IBM-Websphere-Transformation-Extender
#IBMSterlingTransformationExtender

Originally posted by: SystemAdmin

Yes, It would be dangerous to just just switch "everything" to UNICODE. After the development team confirmed to themselves that the current EDI type trees supported Latin-1 as opposed to ASCII as they used to, they agreed with me that the Unicode conversion is unnecessary until we find some specific requirement. I guess they didn't believe the Release Notes for 8.1? and subsequent notes that stated the new default of Latin-1 which covers most European languages.

X12 rarely has to worry about extended character sets as it is primarily used in North America.

The latest EDI Packs use Latin-1 as the character set making Unicode unnecessary for the most part.
#IBMSterlingTransformationExtender
#DataExchange
#IBM-Websphere-Transformation-Extender

Originally posted by: repanzer

Jim, I'm wondering what Trading Parnter relationship software you use, such as Trading Manager, which is what we use. We did some research into using multibyte character sets, and we would have to shut off validation in Trading Manager so we can route the data, because it didn't handle Unicode.
#DataExchange
#IBM-Websphere-Transformation-Extender
#IBMSterlingTransformationExtender

Originally posted by: SystemAdmin

That may be the reason the development team wanted to modfy all the EDI type trees. They have found it unnecessary for the moment by demonstrating that extended characters ( in Latin-1) are properly output.

In a recent release (8.1?), the default character set in the Type Designer and the shipped type trees was changed to Latin-1 from ASCII. This supports most European languages. Also, in a recent release all text is stored internally as UTF-16 (Unicode). Not certain what the effect of that is.

We're running WebSphere Partner Gateway (WPG) as the EDI manager which I believe is Unicode capable.

Jim Divoky
#DataExchange
#IBM-Websphere-Transformation-Extender
#IBMSterlingTransformationExtender