Preparation
Before you move the EEW extension data, the following things must beconsidered:

• Generation of the extensions must be finished and have no errors. You
might check this either by displaying status in EEWB (correctlygenerated) or more deeply with report OXT_METADATA_CHECK. Extensionswhich are checked successfully can be transported, other extensions not.

• Generated objects must have been transported to the target system and
not been changed afterwards. This is realized with the normal EEWWorkbench Transport (called TGEN,WB in this document) and optionally anEEW Customizing Transport (called TGEN,CUST in this document) - bothassigned to the EEW project of the extension. Please be sure that youhave one transport TGEN,WB containing one or more extensions completely,same for TGEN,CUST.

• The original system (by means of TADIR object catalog) of the generated
objects must be adjusted in the target system by setting the targetsystem as the original system. Either do this by transporting aRelocation transport from source to target system (best solution) or byrunning report RDDTADI7 or RDDIT200 in target system providing thetransport request TGEN,WB. Alternatively you can use the toolbox oftransaction SE03 to move objects.
If these steps are not performed, the transport of EEW metadata mightnot fail, but generating or changing of extensions in the target systemwill not work.
Make sure that the package (development class) and the namespace of theextension is available in the target system and identical as in thesource system.
Maintain EEW system settings (transaction EEWC) in the target system inthe same way as in the source system - especially name spaces. Logicalsystem and RFC destinations can be adapted to the target systemlandscape. See not 649336 for further information.

Transport Process
To move the extensions, you need a new workbench transport (called TMETA
,WB here) and a new customizing transport request(called TMETA,CUSThere). Do not use TGEN,WB or TGEN,CUST for this purpose. Also you musttake care that system settings allow the transport (in table T000CCNOCLIIND must be initial and CCCORACTIV must be '1').
Run report OXT_TRANSPORT in the source system and provide the twotransports T(META,WB) and T(META,CUST) and the extension name.
Perform this step for all extensions you want to transport. T(META,WB)and T(META,CUST) can be used for several extensions. Afterwards releasethe transports T(META,WB) and T(META,CUST) and import them in the targetsystem.
If this is done, run report OXT_AFTER_IMPORT in the target system foreach transported extension to adjust it.
To check whether the extensions have been transported and adjustedcorrectly use report OXT_METADATA_CHECK. This report checks theextension status and consistency.
Afterwards the extensions can be generated or changed again with thefollowing restrictions:


• New transport requests must be assigned to the project of the extensions
(in EEWB transaction mark the project and select "Transport Requests" inthe context menu).

• Documentation of extensions and projects is deleted.


• Error log entries for tasks and extensions are refreshed.

Usage in 2 system landscape
A 2 system landscape is a specific system landscape making EEW meta datatransports necessary. The normal development process of 2 systemlandscapes is:


• Develop in DEV system and test


• Transport to PROD system


• Destroy the DEV system


• Build a new DEV system if necessary by copying the PROD system.

According to this process, the handling of EEW should be:

• Create and change extensions in DEV system and test them


• Transport all generated objects and all EEW meta data to PROD system
like described in this document and adjust it. Test whether thetransport was successful with report OXT_METADATA_CHECK.

• Destroy the DEV system like planned by your IT management.


• Build a new DEV system if necessary by copying the PROD system. The new
DEV system will contain the generated objects and the EEW metadata, soyou do not need transports from PROD to DEV.

• Set the original system of all generated EEW objects to the new DEV
system. Set EEWC data correctly like described above. Run ReportOXT_AFTER_IMPORT for each extension (although you did not transport inthis case). Also run report OXT_METADATA_CHECK for each extension tocheck whether it's correct.

Riscs and problems
The transport process described above is intended for complete moves ofa system landscape, e.g. due to upgrade or changing to support mode.Distributed development will very probably lead to problems.
To avoid this, you should consider the following things:


• Do not have a particular extension (or develop it) in several systems or
clients.

• If extensions are transported "by accident" (e.g. by client copy), you
might remove all EEW metadata of a client by a report provided by SAPsupport.

• In general do not develop extensions with EEW in several systems/clients
transporting to the same target system. Reason: extensions might existusing the same technical names for generated objects leading to clashesin the target system.
So if all extensions of a source system are correctly moved, and thesource system remains an active development system, all EEW metadatashould be removed from it. Ask SAP support for further information. Thisavoids errors by working in two systems in parallel. Take care that thisstep is not reversible and affects all extensions, transported or not.
In any case, do not continue to work with EEW extensions in the sourcesystem after a transport.