LSMW Project File

Quick Start Guides ›› Publish ››
Parent Previous Next

Overview


MDA Workbench creates a Legacy System Migration Workbench (LSMW) project file during Publish. This project file can be imported into an SAP System using standard functionality.


The first 8 process steps of an LSMW project define the project; subsequent steps are for executing the project.


MDA Workbench creates an LSMW Project file that includes all but Step 6.


Step

Step Description

Comments

1

Maintain Object Attributes

Uses mapping project properties.

2

Maintain Source Structures

Uses active Segment and Fields, and considers Merged Segments

3

Maintain Source Fields

Uses active Segment and Fields.

4

Maintain Structure Relations

Uses active Segment and Fields, and considers Merged Segments

5

Maintain Field Mapping and Conversion Rules

Uses active Segment and Fields, and considers LSMW-specific Field properties.

6

Maintain Fixed Values, Translations, User-Defined Functions

This step is not commonly needed.

7

Specify Files


8

Assign Files




Limitations




Process Step Details, Dependencies, and Logic


Because MDA Workbench enables merging segments (and thus creating fewer Load-Ready files), it's not necessarily a one-to-one mapping from Load-Ready files to IDoc Segments. Like every step of the data migration process, managing one-to-many relationships is the root of complexity.


1. Maintain Object Attributes



These attributes may be maintained in the Left work area of the Mapping Document window, on the Map tab.


2. Maintain Source Structures


The number of Active and Merged Segments in a mapping project, and their sequence, defines the number of Source Structures (i.e. defines the number of Staging Tables, i.e. defines the number of Load-Ready files). That's the easy part.


The relatively more tricky part is defining the hierarchical relationships between multiple Source Structures, when multiple Source Structures are defined. Source Structures and their relationships are defined explicitly in an LSMW project, but not so in an MDA Workbench mapping project. In fact, a key concept and functionality of MDA Workbench is the ability to "merge" IDoc segments into fewer Load-Ready files, including the ability to quickly change the definition of these one-to-many relationships.


If a mapping project contains only the standard list of Segments that are defined for a standard IDoc message, then what follows in this section may be largely ignored. But if you've added segments to an IDoc, or if you're working with an Enhanced IDoc, then this section is relevant for understanding how Source Structures and their relationships are created in the LSMW Project file.



The hierarchical relationships between multiple Source Structures considers Segments that merged.



3. Maintain Source Fields


The list of source fields is the list of Active fields in the mapping project. But, here again, managing one-to-many relationships is the root of complexity.


Primary Keys are those fields that uniquely identify a row of data in a Source Structure (and in a Staging Table, and in a Load-Ready file). Primary Key fields are explicitly maintained in MDA Workbench, and subsequently are explicitly defined in Staging Tables and Load-Ready files.


When multiple source structures are used (i.e. multiple Load-Ready files), LSMW assumes the list of primary key fields for each Load-Ready file based on common field names. While this is often the case, it's not always the case, and thus LSMW makes a poor assumption that must be considered.


The solution provided by MDA Workbench is straightforward: field names that appear in multiple  Source Structures that are not explicitly maintained in MDA Workbench as primary key fields are renamed. This ensures that non-primary-key field names are unique across  Source Structures. For example, if the field FUNCTION appears in  Source Structure # 1 and in  Source Structure # 2, and if the field FUNCTION is not maintained as a primary key field, then  Source Structure # 1 will include a field named FUNCTION and  Source Structure # 2 will include a field named FUNCTION_Z2. Note that the field FUNCTION in  Source Structure # 2 has been renamed to FUNCTION_Z2.


In Staging Tables and in Load-Ready files the fields are not renamed. LSMW ignores the field names in the first row of the Load-Ready file, but assumes the field names in the Load-Ready file, based on the ordered list of fields for the Source Structure.


4. Maintain Structure Relations


The number of Active and Merged Segments in a mapping project, and their sequence, defines the number of Source Structures (i.e. defines the number of Staging Tables, i.e. defines the number of Load-Ready files).


If no Segments are Merged in the mapping project then the Structure Relations are one-to-one; each Source Structure is related to one IDoc Segment.  If Segments  are merged in the mapping project then a Source Structure may be related to multiple IDoc segments and will be mapped accordingly as the Structure Relations are created.  


5. Maintain Field Mapping and Conversion Rules


All of the commonly used LSMW options are considered, with the exception of ABAP Code.





Controlling LSMW Field Mapping and Conversion Rules via Mapping Project


There is one Application Option and four Mapping project Field properties that work to control Field Mapping and Conversion Rules. Let's list them and then describe n example use cases.







Use Case # 1: A field must be provided to LSMW as a Constant value.


A typical example of this use case is the MSGFN (Function) field found in almost every IDoc and almost every IDoc segment. A constant value, such as 009, must be supplied in the IDoc.  To accomplish this prior to MDA Workbench 2.0 there were two options:  


Neither option was attractive. In the first case Load-Ready files are required with extra values that make little sense to the transformation team. It's added work and confusion without any value added.  In the second case, a transformation of sorts has been manually added to the LSMW project, but it's not really documented anywhere; it's not plainly visible.


To cover this use case, maintain the field this way:


Field Property

Value and Comments

Active

Checked = False.  Do not mark the field as Active for the Field-Level Mapping Document and SQL Scripts.

LSMW Rule

Constant

LSMW Value

009

LSMW Active

Checked = True.  Mark the field as Active for LSMW only.

LSMW Not Initial

This property is not relevant for LSMW Rule: Constant



Use Case # 2: A mapped field should only be transferred if legacy data is supplied.  


Consider the case of an IDoc that is updating an existing record. If a value is not supplied by the Load-Ready file for then field then what is the end-state requirement for that field in the existing record?



Using only the LSMW Rule of Transfer accomplishes the first option: the existing field value is if the input is blank. Like this:


Field Property

Value and Comments

Active

Checked = True.  Mark the field as Active for the Field-Level Mapping Document and SQL Scripts.

LSMW Rule

Transfer

LSMW Value

Leave this property empty.

LSMW Active

Checked = False.  Do not mark the field as Active for LSMW only.

LSMW Not Initial

Use Application Default



The exception is when Options > Publish: LSMW Project > LSMW Rule: Not Initial is set to True. If set to TRUE then fields with an LSMW Not Initial value of Use Application Default will be considered as: Only If Source Field Not Initial.


Using the LSMW Rule of Transfer along with LSMW Not Initial accomplishes the second option: the existing field value is changed only if a new value is supplied. Like this:


Field Property

Value and Comments

Active

Checked = True.  Mark the field as Active for the Field-Level Mapping Document and SQL Scripts.

LSMW Rule

Transfer

LSMW Value

Leave this property empty.

LSMW Active

Checked = False.  Do not mark the field as Active for LSMW only.

LSMW Not Initial

Only If Source Field Not Initial




Use Case # 3: A mapped field should be transferred with Leading Zeros.


Let's say you need to map a G/L Account Number (SAKNR), which is required to be 10 characters with leading zeros in the IDoc. Instead of asking the legacy data transformation team to pad the number with leading zeros it is possible to use this standard LSMW option.  Like this:


Field Property

Value and Comments

Active

Checked = True.  Mark the field as Active for the Field-Level Mapping Document and SQL Scripts.

LSMW Rule

Move With Leading Zeros

LSMW Value

This property is not relevant for LSMW Rule: Move With Leading Zeros

LSMW Active

Checked = False.  Do not mark the field as Active for LSMW only.

LSMW Not Initial

This property may be set to either option, per your business requirement. It does work with LSMW Rule: Transfer. It also works with LSMW Rule: Move With Leading Zeros.  



Use Case # 4: An IDoc Segment-Field should be populated with the same value as another Segment-Field.


Let's say you need to populate a value in one Segment-Field and need the same value from the Load-Ready file populated in another Segment-Field.  It's easy to accomplish this using a Key Word: @FIELD.


Consider a complex mapping project for Customer Master that includes two IDocs: ADRMAS (Address Master) and DEBMAS (Customer Master).  The customer number, populated in the Customer Master header segment (E1KNA1M) must also be populated in the Address Master header segment (E1ADRMAS).


Thus there are two related segments involved in this scenario:



Each segment includes a field that must be populated with Customer Master from the same Load-Ready file.



The first field is mapped to accept data from the Load-Ready file ... [[E1KNA1M-KUNNR]]


Field Property

Value and Comments

Active

Checked = True.  Mark the field as Active for the Field-Level Mapping Document and SQL Scripts.

LSMW Rule

Transfer

LSMW Value

Leave this property empty.

LSMW Active

Checked = False.  Do not mark the field as Active for LSMW only.

LSMW Not Initial

This property may be set to either option, per your business requirement. It does work with LSMW Rule: Transfer. It also works with LSMW Rule: Move With Leading Zeros.  


The second field [[E1ADRMAS-OBJ_ID]] is mapped by referring to the first field:


Field Property

Value and Comments

Active

Checked = False.  Do not mark the field as Active for the Field-Level Mapping Document and SQL Scripts.

LSMW Rule

ABAP Code

LSMW Value

@FIELD = [[E1KNA1M-KUNNR]]

LSMW Active

Checked = False.  Do not mark the field as Active for LSMW only.

LSMW Not Initial

This property may be set to either option, per your business requirement. It does work with LSMW Rule: Transfer. It also works with It does work with LSMW Rule: Move With Leading Zeros.  


For the second field, during LSMW Project creation, the source structure of E1KNA1M-KUNNR is dynamically determined and mapped.


The LSMW Value for the second field says ... For ADRMAS - E1ADRMAS - OBJ_ID, dynamically determine the source structure of E1KNA1M and fill ADRMAS - E1ADRMAS - OBJ_ID from that source structure and field name KUNNR.



Use Case # 5: ABAP Code for an Active field.


There are times when fully manual intervention is required for a field, but you want that field to be included in a Staging Table so that the value is available for ABAP processing.


Field Property

Value and Comments

Active

Checked = True.  Mark the field as Active for the Field-Level Mapping Document and SQL Scripts.

LSMW Rule

Transfer

LSMW Value

Enter the ABAP Code for this field.

LSMW Active

Checked = False.  Do not mark the field as Active for LSMW only.

LSMW Not Initial

This property may be set to either option, per your business requirement. It does work with LSMW Rule: Transfer. It also works with LSMW Rule: Move With Leading Zeros.  




6. Maintain Fixed Values, Translations, User-Defined Functions



7. Specify Files


Front End (PC) Files




SAP Application Server Files


For each LSMW object, LSMW creates two files on the SAP application server during execution steps. LSMW uses the DIR_HOME path by default if a path is not supplied, and by default a path is not supplied.


Basis team generally does not want the DIR_HOME path to be filled with data migration files. Specifying a long file path in LSMW may be problematic because of the length limitation, and a common standard is better for maintainability than using a different path for different servers and different customers.

For standardization of Starter Pack content, it is preferable to use an alias, such as DM. The option File Path SAP is then set to /DM/ (the default) or \DM\ depending on the SAP application server file system.



Basis Task - Unix File System



Basis Task - Windows File System




8. Assign Files