How to handle S/4 HANA conversion impact on Remote Function Modules in S/4 HANA.
This blog is targeted to ABAP technical team working on S4 HANA conversion Projects.
Please also visit my previous blogs on custom code remediation.
This blog is the continuation of series of my blogs on handling of various code remediation scenarios which come across during HANA DB migrations and S/4 HANA Conversion.
During Code remediation phase of S/4 HANA conversion project, technical teams often come across ATC issues for Amount and Material Extension scenarios. In my previous blogs I have covered details on “How to handle Field Length Extension issues for Amount and Material”.
In this blog I am going to cover “How to handle the impact of Field Length Extension check on Amount, Material and other parameters of remote enabled function modules (RFC)”.
Consider a scenario where customer has custom remote function module Z_MAT_AMT_VALUES with parameters as Material and Amount data elements, created in system A. This Function module was called from another SAP system B (ECC system). The name of calling program from system B is Z_GET_MAT_AMT_DATA.
System A was converted to S/4 HANA without adoption of extended field length for Material and Amount. An ATC check was executed on RFC FM Z_MAT_AMT_VALUES in converted system shows following two types of errors (FUNPAR and FUNPAR_CMP).
This ATC message code covers the FLE impact check where Material and Amount data elements are used in structure (Tables tab of RFC FM) parameter of Remote Function Module.
This ATC message code covers the FLE impact check where Material and Amount data elements are used as variable parameter of Remote Function Module.
Let us see both the cases.
In system A and B Internal table I_MATDATA has the TYPE of custom structure ZBUSDATA.
In system B RFC calling program Z_GET_MAT_AMT_DATA was created as below.
DATA : lv_bukrs TYPE bukrs, lv_mwskz TYPE mwskz, lv_waers TYPE waers, lv_wrbtr TYPE wrbtr, lv_matnr TYPE char18, lv_dmbtr TYPE bseg-dmbtr, lv_objknr TYPE caufvdb-obknr, lv_sgt_rcat TYPE eban-sgt_rcat, it_matdata TYPE STANDARD TABLE OF zbusdata, lw_matdata TYPE zbusdata. lv_wrbtr = '000000049876.23'. lv_dmbtr = '000000049876.23'. lv_matnr = '123340849090909098'. lv_objknr = '12345'. lv_sgt_rcat = 'WER12345'. lw_matdata-material_1 = '123340849090909098'. lw_matdata-material_2 = '123340849090909098'. lw_matdata-value1 = '1111111111111111111112'. lw_matdata-value2 = '1111111111111111111113'. lw_matdata-amount = '000000049876.23'. APPEND lw_matdata TO it_matdata. START-OF-SELECTION. CALL FUNCTION 'Z_MAT_AMT_VALUES' DESTINATION 'S19CLNT200' EXPORTING i_waers = 'USD' i_wrbtr = lv_wrbtr i_matnr = lv_matnr i_dmbtr = lv_dmbtr i_objknr = lv_objknr i_sgt_rcat = lv_sgt_rcat TABLES i_matdata = it_matdata. IF sy-subrc = 0. ENDIF.
Parameter definitions in RFC is as below.
Below is screen shot of the values passed with internal table IT_MATDATA from calling program in system B.
Screenshot 4: Values passed from calling program to RFC.
As you see below the values which were passed from program to RFC were corrupted since field length of RFC parameters were not adjusted
Data gets corrupted during RFC call since the field lengths of Material and Amount variables were not adjusted in RFC.
RFC import and Tables parameters were adjusted in converted system as below.
After doing above changes data was passed to RFC without getting corrupted. See the screenshot below.
Please note that in the screenshot 6, only AMOUNT variable types were adjusted and not the Material, which is of type CHAR. Whereas in Screenshot 7 both Amount and Material types were adjusted.
- After S/4 HANA conversion, custom RFC parameters (Import and Tables) need to be adjusted.
- Impacted data elements of import parameters except TYPE CHAR need to be replaced with compatible ones. (FUNPAR scenario)
- All Impacted data elements of Table parameters need to be replaced with compatible ones. (FUNPAR_CMP scenario)