Skip to Content
Technical Articles
Author's profile photo Himansu Sekhar Roy

SAP S/4 HANA Migration Cockpit – Direct Transfer: Creating custom API for LTMOM

INTRODUCTION:

SAP Migration Cockpit came up with Direct Transfer came in 1909. There are four ABAP based source – AFS, CRM, ERP and EWM currently supported. In 1909 version there are 208 migration objects out of which 127 belong to SAP ERP covering various Master and Transaction data which has expanded to 230 (142 for ERP) in 2020 version and is expected to grow with upcoming releases.

For various reasons there may be a requirement to create a custom migration object to do a data transfer. The custom migration object can be created using an existing SAP standard FM or a custom FM as per the requirement. In this blog I will cover the best practices and key points for creating a custom API/FM for Direct transfer in LTMOM with an example.

Purpose: Key points and high level steps to create custom API/ FM for use in Direct Transfer of Migration Cockpit.

Pre-requisite: Knowledge of SAP Migration Cockpit, LTMOM and ABAP.

 

MAIN PART:

Requirement: While transferring GL open items (classic GL) from Source (ECC) the coding block (ci_cobl) fields needs to be mapped to extension field in the API of migration object.

SAP provides the following out-of-box option to transfer classic GL opening balance:

> Migration object: S4_FI_GL_OI_CLASSIC_GL

> API/FM : BAPI_ACC_DOCUMENT_POST

 

For transferring to extension structure (1 and 2) it has the following to map value from incoming structures:

To pass or handle required value to field valuepart (1-4) currently it may not be feasible to define a source code mapping which currently is not available for customers (current limitation in LTMOM) and as you see they are defined of length CHAR 240 or CHAR 250.

To overcome the situation we can define a custom FM which will be a wrapper on BAPI_ACC_DOCUMENT_POST and subsequently pass the required parameters to Extension1 or Extension2.

While creating an custom API there are six different points to consider.  The details are available in the link (guide) available in SAP Note 2590165.

Here is a summary of the points for creating custom FM/API:

  1. COMMIT / Rollback – Shouldn’t be executed within FM
  2. Error Handling – To return messages use BAPIRET2 and no exception should be mentioned.
  3. Test mode – try to provide one
  4. Plausibility check (for the test mode)
  5. Return identifiers when data instances are created by process
  6. Consistency checks

All these are explained in detail in the mentioned note.

Coming back to the current example here is what is done: has been done to create custom FM ‘Z_BAPI_ACC_DOC_POST‘ which can be used in Migration object (target):

 

A. Importing parameter has a custom structure which is catering to all fields required to be posted (including the coding block fields).

While defining the structure ‘ZDTO_MIGCOCKPIT‘ (or any other name) you may want to consider only the required fields which you want to pass on to target system.

 

B. The exporting parameters are replica of original FM which caters to point 5 – return identifiers.

 

C. Return parameter for error handling.

 

D. Populate extension2 fields with various custom fields which are part of coding block in target system. Variable ‘IM_TESTRUN’ is for plausibility check which facilitates Simulation in Migration Cockpit and returns all applicable message for review in the tool.

FM ‘BAPI_ACC_DOCUMENT_POST‘ gets called during actual migration. In this example enhancement BADI is used in system to populate the coding block field with use of a structure.

If used in target processing the fields can be mapped by putting multiple incoming value in importing parameter of field value mapping and the output value (extension) can be split / mapped as desired. To know more on field value mapping you may refer to my other blog – SAP S/4 HANA Migration Cockpit – Direct Transfer: Creating and using custom field value mapping (LTMOM).

CONCLUSION:

SAP provides with flexibility for customers/partners to create custom API to cater to specific requirements for direct transfer in Migration Cockpit. The API comes in form of Function Module which is reusable. This API / FM should be configured during custom migration object created in a migration project and is done only in LTMOM.

The example demonstrated is one of API which I built and has been used in Productive data migration without any issue. Hope my fellow SAP enthusiasts find this information useful.

References:

SAP S/4 HANA Migration Cockpit – Direct Transfer: Creating and using custom field value mapping (LTMOM).

Migrating Your Business Data to SAP S/4HANA – New Implementation Scenario : Week 3

SAP NOTE 2590165

Guide: https://www.sap.com/documents/2020/05/44a27c28-977d-0010-87a3-c30de2ffd8ff.html

 

Assigned tags

      2 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Jun Chen
      Jun Chen

      Dear Roy,

      Thanks very much for sharing this useful information.

      One question regarding the result handling after function module is called, you know in file/staging approach, we can handle the result(e.g. fill the customized mapping tables) in the includes, do we have the same possibility for direct transfer? Thanks.

      Chen Jun

      Author's profile photo Himansu Sekhar Roy
      Himansu Sekhar Roy
      Blog Post Author

      Hi Jun Chen,

      Referring to SAP Note 2590165, we shouldn't commit or roll-back in the API/FM as these are handled by the standard framework i.e. within FM execution it's not possible to determine success/failure.

      Regards,

      Himansu Roy