SAP S/4 HANA Migration Cockpit – Direct Transfer: Creating custom API for LTMOM
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.
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:
- COMMIT / Rollback – Shouldn’t be executed within FM
- Error Handling – To return messages use BAPIRET2 and no exception should be mentioned.
- Test mode – try to provide one
- Plausibility check (for the test mode)
- Return identifiers when data instances are created by process
- 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.
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).
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.