SAP S OF TWARE L OGISTICS
Step 9. Generate – During this phase all ABAP programs or function modules are generated or compiled from ABAP source code into ABAP byte code. This
4.15 ENHANCEMENT PACKS
As of SAP ERP 2005, a new type of software deployment package is available, called an Enhancement Package. An Enhancement Package extends SAP ERP 2005 with new functionality that is normally released through SAP upgrades. To reduce the number of ERP releases, SAP has decided to keep the 2005 release as a core release up to at least 2010 and only add new functionality to the system through Enhancement Packs. So if a customer would like to leverage new functionality, it’s
no longer required to go through an entire upgrade process, but rather implement one or more Enhancement Packs instead.
Figure 4.50: mySAP ERP 2005 Enhancement Package strategy. ©Copyright SAP AG.
Enhancement Packages do not replace Support Packages. Support Packages are released to fix bugs and contain performance improvements. Enhancement Packages contain new functionality that is added to the ERP applications and can be licensed seperately. The functionality that has been added to the system through Enhancement Packages will become part of the next major SAP release.
Implementing Enhancement Package is optional to the customer and need to be considered on a case-by-case basis.
Enhancement Packages are incremental, which means that if you do not have any installed in your system and you would like to install Number 2, it automatically installs Number 1. Due to the fact that Enhancement Packages are new functionality, which means new programs, screens, and DDIC objects, you have to implement Support Packages for these Enhancement Packages as well. This results in a much more complex Support Package strategy. To support customers with this, SAP has released tools like SLM (SAP Life-Cycle Manager) and the MOP (SAP Maintenance Optimizer). Tools like these should help to reduce the complexity and effort of applying Support Packages.
SAP will also release Enhancement Packages for other Business Suite components like CRM, SRM, PLM and SCM.
4.16 LANGUAGES
SAP applications based on the ABAP engine are multilanguage, which means that multiple languages can be used by end users. Depending on the release status, the SAP system supports up to 30 different languages. The language in which a dialog user works is specified during logon by making a selection on the logon screen.
Alternatively, it can be specified by a system parameter or by a default setting in the user master record.
After a “fresh” install of an SAP system only German (DE) and English (EN) are available as languages. Additional languages need to be imported into the system using the Language management tool accessible through transaction SMLT.
The different languages are implemented as text elements, which are identified by a language key. All SAP support languages have their own unique language key that is specified in table T002:
Field Type (dimension) Description
SPRAS LANG (1) Language key
LASPEZ CHAR (1) Language specification
LAHQ CHAR (1) Degree of translation
LAISO CHAR (2) ISO 639 Language code
When an additional language needs to be installed in the system the language key needs to be available in this table. Through transaction SMLT, you will be able to select the appropriate language and add it to the list. For every language in the system, whether it’s imported or not, there is a line item in the overview screen of SMLT. By selecting this line, you can see all import details of this particular language. If the language has not been imported into the SAP system, this line will provide the ability to start loading the language.
Languages are imported by using R3load, up to SAP R/3 release 4.6C or by using R3trans as of SAP R/3 4.6C. The language import files are delivered as R3load or Transport files (co- and datafiles) on a CD-ROM. During the import phase in SMLT, you can specify the location of these installation files.
Figure 4.51: Initial screen of SMLT Language Management (SAP R/3 4.6C). ©Copyright SAP AG.
As already stated, languages are implemented as text elements. All text elements are stored in tables, with at least two fields: language key and text. So when a text is put on the screen it points to a row in a table, identified by a language key.
As mentioned before, table DD02L contains all table definitions in SAP. The table DD02T points back to DD02L, lists all relevant language fields, and contains all texts in different languages for all table names. Table DD02L points to DD02T, which contains (most important fields are shown here):
Field Type (dimension) Description
TABNAME CHAR (40) Name of table (as in DD02L)
DDLANGUAGE CHAR (2) Language key (as in T002)
DDTEXT CHAR (120) Text it self
For example, DD02T.TABNAME = ‘USR02,’ DD02T.DDLANGUAGE=’D’ and DD02T.DDTEXT=’Anmeldedaten.’
Text elements are available for all kinds of SAP tables: Master, Transaction, System, and Customizing tables. For example, the customizing table TVKO that contains all Sales Organizations is accompanied with table TVKOT for the text elements.
Although a table or ABAP program can have multiple text elements, one for each installed language, there is only one Master Language. The master language is the language where the objects are created and maintained in. The master language, which on most occasions is English or German, of each object is specified in table TADIR field MASTERLANG.
TIP Text elements, and therefore languages and translations, are stored in tables with (TVKOT) and without (DD02T) the client-specification field MANDT. Therefore, assume that languages are client independent.
The customer can decide whether it translates certain text elements using the Translation Workbench, which can be accessed using transaction SE63. The translation workbench is a tool for translating language-dependent texts. The tool can be used to translate additional texts in incompletely translated languages. For example, if you want to use the Danish language, but the language is not (yet) available from SAP, the option is to install the Danish language in SMLT, but without importing the language. The Danish language is completely supplemented with either English or German. The dialog user, who logs-on in Danish will only see English or German texts. This provides the ability to translate certain text elements into Danish yourself, for example, to cope with legal requirements. This could be done for “Dangerous Goods Movement” documents.
As of release 4.6C, SAP switched from R3load to R3trans for language imports.
The reason for this is related to Support Packages. In SAP releases older than 4.6C,
you could not install “new” additional foreign languages to your system if there were already Support Packages applied.
Figure 4.52: Language import problem of SAP R/3 up to release 4.6B.
If you did so, the “new” language is only added in the “core” of the SAP system, all objects that were modified due to Support Packages will not have a proper translation. The solution to this problem is to include, in all Support Packages, the text element of all supported languages. During the normal implementation of Support Packages, SAP will only import those languages that are installed in the system. When an additional language is added to the system at a later stage, the SMLT tool will import missing text elements belonging to that “new” language and from the already applied Support Packages. In order to do this, the co- and datafiles of these Support Packages need to be available for accessing. A negative consequence of this “new” method is the increased size of each Support Package.
Figure 4.53: Language import option as of SAP R/3 4.6C.
TIP You do not have to keep all co- and datafiles online in order to add additional languages to your system. SMLT is able to disassemble all required files from the EPS package. Just store all required EPS packages in “/usr/sap/transEPS/in.”