Hierarchy

⤷

⤷

Basic Data
Data Element | PXNGENAPPL |
Short Description | Generation Source |
Data Type
Category of Dictionary Type | D | Domain |
Type of Object Referenced | No Information | |
Domain / Name of Reference Type | PXNGENAPPL | |
Data Type | CHAR | Character String |
Length | 30 | |
Decimal Places | 0 | |
Output Length | 30 | |
Value Table |
Further Characteristics
Search Help: Name | ||
Search Help: Parameters | ||
Parameter ID | ||
Default Component name | ||
Change document | ||
No Input History | ||
Basic direction is set to LTR | ||
No BIDI Filtering |
Field Label
Length | Field Label | |
Short | 10 | Gen. Src. |
Medium | 15 | Gen. Source |
Long | 20 | Generation Source |
Heading | 30 | Generation Source |
Documentation
Definition
Proxy Migration to MDR
Background
Each proxy is assigned to a so called generating application. This attribute is persisted with the proxy ( table field SPROXHDR-GEN_APPL ) and not changeable during lifecycle of a proxy.
Until now the only relevant generating application for Scope 1 was "Enterprise Service Repository" (key: SPACE). With introduction of Backend Metadata Repository (MDR) a new generating application (key: "BACKENDMDR") was introduced for all proxies modeled in backend.
MDR and ESR proxies share the same namespace (type/name/namespace), hence it is important that proxies generated via SPROXY do not overwrite proxies generated via MDR and vice versa. To control this a target generating application was introduced.
Target Generating Application
The assignment of a proxy to it's generating application is controlled by a target generating application that is by default "Enterprise Service Repository" for Business Suite systems, and "BACKENDMDR" for BusinessByDesign systems.
Via table view SPXNMIGRATION the target generating application can be specified per namespace (wildcards allowed) to overwrite the default generating application.
The target generating application is checked each time an object for a concrete namespace has to be generated via SPROXY or created via MDR. If the context (MDR/SPROXY) does not match the system settings, the creation via MDR / generation via SPROXY is not performed.
Migration of ESR proxies to MDR
For already existing ESR proxies a migration to MDR can be done via report SPXNMIG
Via selection screen a namespace range can be specified. Based on the namespace range a list of all proxies that can be migrated is displayed. Here the user can start the migration for the complete list or a subset. The selection considers the target generating application for the current development system, so the list only contains entries if the target generating application is MDR and ESR proxies for the namespace range exist.
For migrated proxies the generating application was changed to BACKENDMDR and the VERSION_ID for the proxy was set to SPACE.
Restrictions:
- Inline types can NOT be migrated automatically to MDR.
They should be changed to global types in ESR and regenerated to become global types in backend also.
Alternatively they can be converted by migration tool in a semi-automatic way. Semi-automatic way means that inline types can be converted into global types by specifing a global name for each inline type for which the tool needs to generates a global type.
Note: If the second option is used a migration back to ESR is not possible. - Migration of ESR interfaces based on external definitions is not supported.
They can be replaced by an external consumer/provider generated from WSDL directly in backend.
Migration MDR proxies back to ESR
To migrate MDR proxies back to ESR the target generating application has to be set to ESR via system default/view maintenance SPNXGENAPPL for the concrete namespace. After that the relevant proxies have to be regenerated via SPROXY.
Additional Notes:
Regeneration can only take place in the ESR proxy editor. To get the ESR Editor for a MDR proxy you have to invoke the proxy editor via transaction SPROXY.
If completely new objects are created in the MDR, they are not directly published back to the ESR, so if both repositories need to be in sync, this has to be done manually via modeling in the ESR.
Use
Dependencies
Example
History
Last changed by/on | SAP | 20130604 |
SAP Release Created in | 72L |