Overview

We must simultaneously reduce complexity and increase the speed of achieving repeatable results while recognizing and managing data models that are fundamentally different across the data migration landscape.

The shape of data -- the technical definition of data -- changes with each step.

One source of complexity is identifying and accommodating one-to-many relationships that are the nature of some business objects. For example, a customer may have multiple telephone numbers, multiple shipping addresses, multiple associated contact persons, and more.

Beyond the complexity represented by the business object itself, it's important to recognize that components of the data migration landscape represent one-to-many relationships in fundamentally different ways. For example, one-to-many relationships may be expressed differently by relational database tables (i.e. Staging Tables) versus the same data in a structured document (i.e. an IDoc). What's more, there's a third consideration, which is the data model assumed by conversion programs (i.e. Legacy System Migration Workbench, LSMW). What are the key differences demanding our attention?

• Staging Database:  Primary key fields are explicitly required for each table to define one-to-many relationships.

• LSMW:  Assumes (incorrectly!) that primary key fields for multiple Load-Ready Files are based on field names.

• IDoc:  Primary key fields may be inferred from parent-child relationships (e.g. Customer Master IDoc does not include Customer # in the Company Code segment).

• SAP ECC:  The shape of the data changes during IDoc processing, which is a consideration for Reconciliation.

Deftly managing the above complexity, simplifying the process for every functional resource, and increasing the speed of achieving predictable results is the comprehensive challenge.

Mapping Project

Here are the high-level steps for creating a mapping project for one data migration object object:

1. Open an existing project or create a new project.

There are several ways to create a new mapping project or to open an existing mapping project file.

• A new mapping project can be created by choosing File and then Map from SAP from the menu.
• Choose an SAP system and client and specify an IDoc Basic Type, such as ARTMAS05 or DEBMAS07. The application will connect to the SAP system and import the segment and field details of that IDoc Basic Type.
• An existing mapping project (file extension .mdawb) can be opened from a file by several methods:
• Choose File and then Open to choose a .mdawb file.
• Double click a file with file extension .mdawb in Windows Explorer and it will start MDA Workbench and then load the mapping project file.
• Drag a mapping project file (file extension .mdawb) from Windows Explorer and drop it into the MDA Workbench application window.
• Recently used mapping projects are listed in the File | Recent list and may be quickly opened from that list, rather than browsing for a file.

Once the mapping project file is open, take note of (and maintain, if needed) the Project ID, which is found in the Left Work Area on the Map tab. This Project ID is used for file naming when producing deliverables.

2. Select IDoc segments, and indicate which segments are to be merged.

In this step you're indicating which segments of the IDoc are relevant, and you do this by marking the segment as Active. You're also identifying one-to-many relationships. Completing both of these activities will define the number of Staging Tables that will be created to supply data (as Load-Ready data files) to the LSMW Project.

The IDoc segments are displayed in the Main Work Area, including two indicators for each segment: Active and Merged.

Merging of segments is a key concept. Each segment represents the possibility of a one-to-many relationship. One-to-many relationships can be reduced by using the Merge functionality. When two or more segments are merged, that means that there will always be – without exception – a one-to-one relationship between these segments.  

Each segment in an IDoc usually represents the possibility of a one-to-many relationship, and this possibility remains if you choose not merge segments. When a segment is not merged, then a separate staging table is created for that segment. If the data transformation team puts one record in the staging table, then one segment is created in the IDoc. If the data transformation team puts two (or more) records in the staging table, then two (or more) of the segment is created in the IDoc.  

One "gotcha" that you need to be aware of -- and that you must to attend to -- is that primary key fields must be available in both the parent and child (not-merged) segments. In some IDocs, the primary key fields(s) exist in both the parent and child segments. In some IDocs, the primary key field(s) exist only in the parent segment. If the primary key field(s) do not exist in both the parent and child segments, then you must copy primary key fields from the parent segment to the child segment so that they will be available when defining primary key fields for each Staging Table. In some extreme cases, you may have to add primary key fields in both the parent segment and child segments.

An IDoc is a structured document, like an XML document, and parent-child relationships (one-to-many relationships) between IDoc segments are defined by the IDoc structure and definition. Staging Stables are defined by the IDoc segments and fields that will be used (i.e. Segments and Fields are flagged as Active). Our goal is to reduce the number of database Staging Tables when possible, which is accomplished by reducing the number of one-to-many relationships when possible (i.e. merging segments).

For example, consider Customer Master and the possible one-to-many relationship between Customer and Company Codes. The relevant segments in this example are:

• E1KNA1M - Master customer master basic data (KNA1)
• E1KNB1M - Master Customer Master Company Code (KNB1)

If our requirement is for only one company code, then there isn't a need for a separate Staging Table to represent a one-to-many relationship between Customer and Company Codes. Any Active fields from E1KNB1M (Master Customer Master Company Code KNB1) could be merged with Active fields from E1KNA1M (Master customer master basic data KNA1) into a single Staging Table. And that is the purpose of the Merge indicator.

• Active
• If a segment is flagged as Active then Active fields in that segment will be included in Staging Table(s).

• Merge
• If a segment is flagged as Active and flagged as Merge then Active fields in that segment will be included in the same Staging Table as the previous Active segment.

3. Select IDoc fields.

Field Properties: Active and LSMW Active

Mark the relevant fields as either Active or LSMW Active.  The difference is straightforward:

• If a field is flagged as Active then that field will be included in a Staging Table, and thus in the Load-Ready file.
• A value for this IDoc field is accepted from the Load-Ready file.
• The value of the field in the Load-Ready file will be transferred to the IDoc field (i.e. LSMW Rule: Transfer)

• If a field is flagged as LSMW Active then that field will be not included in a Staging Table, but the IDoc segment-field will be filled with a constant value or the result of ABAP Code.
• A value for this IDoc field must be specified in the mapping project, using a different LSMW Rule that you must specify.

• Active and LSMW Active are mutually exclusive. If one is checked then the other becomes unchecked.

• When using LSMW Active there are other field properties to consider:
• LSMW Rule
• LSMW Value

Using LSMW Active

Lets take a closer look at using LSMW Active and the options for LSMW Rule.

• LSMW Rule:  Constant
• For example, nearly every IDoc segment includes a field MSGFN (Function) that needs to be populated with a constant value, such as 004 (Change: Message contains changes). Using this example ...
• Choose the LSMW Rule of Constant.
• Make an entry for LSMW Value: 004.
• LSMW Rule:  ABAP Code
• For example, it is often desirable to populate an IDoc field with the the same value that was supplied to a previous Segment-Field.
• This example is a bit more complex to explain, but actually simple to use. Let's use the example of the Characteristics IDoc (Message CHRMAS) to list the steps.
• Scenario Details:
• Segment E1CABTM contains a field named SPRAS (Language Key)
• A lower segment, E1CAWNM, also contains a field named SPRAS (Language Key).
• Implementation Steps
• Mark the first field (E1CABTM-SPRAS) as Active so that it will be included in a Staging Table. A legacy value will be accepted for this field.
• Mark the second field (E1CAWNM-SPRAS) as LSMW Active.
• Choose the LSMW Rule of ABAP Code.
• Make an entry for LSMW Value:
• Enter the key work @FIELD, followed by a space, followed by an equals sign and another space: (@FIELD = )
• Click the row selector for the first field (E1CABTM-SPRAS) and press Control + C.
• Return to the LSMW Value for the second field, put the cursor after "@FIELD = " and press Control + V.  The result is:  @FIELD = [[E1CABTM-SPRAS]]
• The syntax translates to:  For @FIELD (i.e. this field) equals the same source as that used for E1CABTM-SPRAS.
• In summary, the value supplied to a previous IDoc field will also be transferred to this IDoc field.

Field Property: LSMW Not Initial

This field property is only relevant when an LSMW Rule of Transfer is used.

When the option for Only If Source Field Not Initial is used then a value will be transferred from Load-Ready file to the IDoc field only if a non-blank value is supplied in the Load-Ready file.

For most IDoc messages, this has implications, both when a record is created and also when a record is changed.

Create Record:

• If Only If Source Field Not Initial is used then when an entry is not supplied in a Load-Ready file (zero length string) the a default value may be supplied by the system during IDoc processing.
• This is usually the case, but the behavior depends on IDoc message type.
• The use of Only If Source Field Not Initial is generally preferred when creating new records.

Change Record:

• If Only If Source Field Not Initial is used then when an entry is not supplied in a Load-Ready file (zero length string) then existing data for that field may not be overwritten during IDoc processing.
• This is usually the case, but the behavior depends on IDoc message type.
• A decision to use Only If Source Field Not Initial depends entirely on your functional understanding of the business requirements and desired behavior during IDoc processing.

Consider that there is an application option that can be set to True:  Options > Publish: LSMW Project > LSMW Rule: Not Initial

For the IDoc field, there is a property named LSMW Not Initial, and there are two options for this IDoc field property:

• Use Application Default
• Only If Source Field Not Initial

If the application option LSMW Rule: Not Initial is set to True, or if the IDoc field property LSMW Not Initial is maintained as Only If Source Field Not Initial, then the field will be treated as Only If Source Field Not Initial when creating the LSMW Project.

4. Maintain Primary Key(s).

An IDoc is a structured document, like an XML document, and parent-child relationships (one-to-many relationships) between IDoc segments are defined by the IDoc structure and definition. In contrast, database Staging Tables require explicit definition of primary key fields. Every staging table must have Primary Key field(s) defined. The fields flagged as Primary Key indicate the one or more fields that uniquely identify a row in the database.

Because IDoc structure defines relationships, you'll find that some IDoc segments don't even include primary key fields. For example, E1KNB1M (Master Customer Master Company Code KNB1) does not include the field KUNNR (Customer Number). If our requirement is to support multiple company codes then E1KNB1M (Master Customer Master Company Code KNB1) would not be flagged as merged, thus permitting data for multiple company codes in a separate database Staging Table.

If E1KNB1M (Master Customer Master Company Code KNB1) is not merged and will create a separate Staging Table, then that staging table must include both KUNNR (Customer Number) and BUKRS (Company Code). To accomplish this, copy KUNNR (Customer Number) from segment E1KNA1M (Master customer master basic data KNA1) to segment E1KNB1M (Master Customer Master Company Code KNB1), inserting it just above BUKRS (Company Code).

Clicking the Primary Key button on the Toolbar opens a form that displays a tab for each Staging Table that will be created. You should visit each tab and designate the Primary Key field(s) for each Staging Table.

In the case of an IDoc, the structure of parent – child relationships can define a one-to-many relationship without including primary keys. In the case of relational database tables, primary keys are an absolute requirement.  Some IDocs include primary key fields in both the parent and child segments, and this is the simple case. But some IDocs do not include primary key fields in child segments (in a structured document, the key fields are implied by the structure) and in this case further attention is required.  

If the key field(s) do not exist in both the parent and the child segments, then you must copy key fields from the parent to the child segment so they will be available when defining Primary Key fields for each Staging Table.

5. Create a Local System Database with Key Values.

This step is optional, but will help with accurately maintaining sample data for a specific system and target, if one is available.

• Create a new Local System Database.
• Create a Value Table Map by clicking the Value Tables Map button.
• Transfer Data from SAP using the Value Tables Map.  

6. Create validation tests.

It's optional to Create Validation Tests at this point, but it will help with the validation of Load-Ready files when they become available.

Validation tests are also helpful for Working With Sample Data, which is the very next step.  With the Validation Engine running in real-time while maintaining Sample Data, especially performing validation based on Value Tables, you can be confident that you're creating sample data that aligns with the master data and configuration of the target SAP system and client.

7. Maintain sample data.

Sample data should be provided to the conversion program developer so that the conversion program can be unit tested.

Clicking the Maintain button on the Toolbar opens a form that displays a tab for each Staging Table that will be created. You should visit each tab and enter rows of sample data.

8. Publish deliverables.

Clicking the individual buttons on the Toolbar group named Execute enables discrete creation of deliverables:

• Create SQL creates a SQL Server script that can be used to create the database Staging Tables for this project.
• Create LSMW creates an LSMW Project and creates LSMW Field Definition files that match the definition of Staging Tables.
• LSMW Project files can be imported into an SAP system using standard LSMW functionality (from the menu, choose Extras and then Import Projects).
• LSMW Field Definition files are compatible with and meant to be used by LSMW, saving time when manually creating an LSMW project.
• Create MAP creates a Field-Mapping Workbook (an Excel document) that contains field-level mapping and transformation rules.

Clicking the Export button on the Toolbar group named Sample Data enables creation of sample data files:

• Export creates tab-delimited text files to be used when unit testing conversion projects.

Clicking the Publish button creates all of the above deliverables with the click of one button. The deliverables are created in a new folder below the location of the project file (.mdawb project file), and the folder name includes the creation time and date. For example, for a project named FI_GL, a folder named FI_GL_20150109-165204 would be created with the following files: