As the world’s second-largest electronics components manufacturer, Molex is a truly global business. The company runs more than 60 factories in 21 countries from a single global instance of SAP sited at company headquarters in Lisle, IL.

Molex had implemented multiple code pages using Multi-Display Multi-Processing (MDMP) technology to support its 8,000 users from 10 different languages. But SAP’s withdrawal of support for MDMP (with the release of mySAP ERP 2005) meant Molex would have to convert to Unicode, the universal standard for encoding and representing text in multiple languages, before upgrading from R/3 to SAP ERP 6.0.

The company was also determined to avoid future issues with unreadable characters, as illustrated in Figure 1. These issues can arise when users develop work-arounds for language limitations on a system, such as logging on in English and pasting foreign characters into a transaction.

Figure 1

On the right, an example of unreadable characters in an MDMP system

While some companies choose to convert to Unicode during an upgrade, Molex decided to tackle the Unicode project separately to minimize system downtime. It would prove a wise decision.

“I am very glad we didn’t try to do two things at once,” says Dave Hubert, manager of Global Information Systems at Molex. “Unicode is the most complex technical challenge we have undertaken. In the last 12 years, we’ve done six upgrades and numerous maintenance patches. Those we understood, but with Unicode you find completely different challenges that require a creative solution.”

Molex had to overcome significant technical challenges to complete its Unicode conversion. Here is a closer look at five of the key lessons Molex learned during its Unicode project:

1. Stock up on hardware

Unicode’s ability to process double-byte languages will add considerably to the CPU and database requirements of your system. SAP recommends increasing CPU by 30% and RAM by at least 50% in preparation for the conversion. Depending on which Unicode standard you choose, the size of the database should be increased anywhere from 10% (UTF-8) to 60% (UTF-16). The exact requirement depends on the encoding scheme used and languages supported.

Hubert says ignoring the hardware requirements can stall your project dramatically. The company first tried to import and export on a scaled-down quality assurance (QA) hardware environment, but that process took a full month and left the test system with an out-of-sync data set that was impossible to reconcile easily.

“The export/import of the database takes such an incredibly long time that you have to have parallel processing of multiple threads to achieve throughput to turn over a test-converted system to a user community in a reasonable amount of time,” says Hubert. “In a normal upgrade process — say from 4.6 to ERP 6.0 — you’d typically use the common QA-type hardware that usually doesn’t have the entire landscape of multiple app servers. You do that with Unicode, and you delay the completion of the process by weeks. Not hours, but weeks.”

To ensure that it had the hardware capacity necessary to test and convert its entire system, Hubert’s team upgraded to an array of 4-way and 12-way HP Itanium servers. The system now processes transactions at an acceptable rate of about one transaction per .75 seconds for 2.5 million transactions per day, despite an average monthly database growth of 60 to 70 GB.

2. Prepare for the unknown with SAP applications and third-party technologies

Hubert describes the delay caused by the hardware requirements as a secret blessing, as it gave his team time to discover a major issue with the conversion of the SAP BW system to Unicode that took a full month to resolve.

The problem arose because the data extractors used to move data from the core ERP system to SAP BW would substitute single-byte pound signs for unknown characters. If those unknown characters were double-byte characters from the original Korean or Japanese, however, the resulting loss of bytes would cause data from neighboring columns to shift positions. The result was a jumble of numeric data placed into the wrong fields.

“We had to ensure that the numeric data going to BW was clean. So we took all the text fields in the BW extractors and moved them to the far right of the file so that if they were corrupted or damaged, they wouldn’t affect any numeric values,” says Hubert.

Reorganizing the data fields took the SAP BW team a full month of non-stop work, according to Hubert.

Unicode compliance issues extend outside of SAP as well, the Molex team discovered. They had trouble discerning whether some of their third-party applications were Unicode-compliant, and some vendors demanded development money to ensure compliance. In one case, Molex had to suspend its use of an outside application for months until the vendor could update the technology.

3. Check and check again

SAP provides tools that allow your team to check your entire system for Unicode compliance. Hubert’s team found that using the transactions UCCHECK and SLIN in combination were effective.

UCCHECK runs a scan on a program or system to find Unicode syntax errors. The transaction identifies compliance issues on specific objects, allowing the project team to correct the syntax before the conversion to Unicode. An example of a UCCHECK screen is shown in Figure 2.

Figure 2

Running the transaction UCCHECK

While UCCHECK will flag non- compliant objects, it is not as precise as the extended system check transaction SLIN. Where UCCHECK simply scans each object for syntax errors, SLIN performs a run-time analysis on those objects.

“You can’t be 100% comfortable with UCCHECK. You have to run the extended program check to be sure,” says Hubert.

4. Balance Unicode and non-Unicode environments with SM59

The transaction SM59 defines the internal and external HTTP connections for the SAP system. SM59 allows you to define the source and target systems as Unicode or non-Unicode to allow those systems to work together in a mixed environment.

Hubert discovered that proper setup of those connections was key to maintaining uptime in a multi- application SAP ERP environment. Molex converted its ERP and SAP CRM systems first, then later converted the SAP BW system.

“It was a critical lesson learned to make sure that was correctly established for data going from Unicode to non-Unicode,” says Hubert.

5. Speak the language

Testing a complex Unicode conversion like Hubert’s is unlike any other project because it relies on native speakers to check for accuracy. Molex supports multiple double-byte Asian languages, so Hubert was forced to assemble a team of language specialists to review the conversion before the project went live. In some cases, he simply needed to know whether certain characters were rendering Japanese, Korean, or Chinese words.

“There is a tremendous amount of visual scanning of data involved,” says Hubert. “You can’t do it with automated tools. You have to have people to look at the core table entries and read the text and sign on in multiple languages.”

Conclusion

Molex implemented the conversion during Easter weekend in 2007. The system required a total of 52 hours of downtime beginning on a Friday (a U.S. holiday and post-work hours in Asia), but was up and running — and fully tested — by Sunday afternoon.

Since the Unicode conversion, Molex has upgraded to SAP ERP 6.0 and has suffered no issues with language conversion. Hubert says he is glad the company decided to tackle the Unicode conversion before the upgrade, since the first project consumed about 175% of the man-hours typically required for an upgrade.

“That’s really because of the number of custom programs we had. There were thousands of objects that needed to be touched, and while they only took about 15 minutes each, they each needed to be resent to the custom system. We ended up moving almost 8,000 custom objects into the system,” says Hubert.

Of course, user management is key when changing the language landscape of a system. Hubert’s team relied on a direct approach to managing ongoing user-created problems — such as users signing on in one language, typically English, and pasting text from documents in another language.

“We had to explain to them that that was not going to work going forward and that it was damaging to the data, and if they wanted to use their local languages, they had to sign on in them,” says Hubert.

Then there’s the problem of user expec­tations. Hubert says it’s important to remember that the Unicode conversion affects their daily routines with little or no tangible benefit at the end of the project.

“From a user’s perspective, they don’t really gain anything from Unicode, and they are inconvenienced for a while afterward with potentially corrupted or unreadable text. You have to present it to them that in the long term we’ll be able to display all those characters on your screen cleanly,” he says.

Davin Wilfrid

Davin Wilfrid was a writer and editor for SAPinsider and SAP Experts. He contributed case studies and research projects aimed at helping the SAP ecosystem get the most out of their existing technology investments.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.