As with the case for new generation of IDOC types, most of the IDOC used in SAP Cloud for Customer (C4C) integration are Function module based IDOC, also known as generated IDOC. In this case IDOC type and ALE interfaces are generated using transaction code BDFG (ALE Interfaces from Function Module), based on a complex data type, which is wrapped in a function module. You can find more information about it on SAP help portal at this link.
Note : Unless there is a need to pass multiple customer specific fields or the standard IDOC structure has no extra fields, it is advisable to find some unused fields from the IDOC structure to pass the information needed. This way the IDOC regeneration and adjusting ALE function modules, if required, can be avoided.
Some examples of Generated IDOC offered for C4C integration are:
- COD_STOCK_REPLICATE01 etc..
Unlike conventional IDOC, these IDOC types can not be extended using WE30. To extend these types of IDOC, we need to extend the underlying complex data type and regenerate the IDOC using BDFG. In this blog we will look at how to extend an generated IDOC step by step.
Steps to be followed:
- Enhance the data type
- Generate the IDOC type and ALE interface using BDFG, in customer namespace
- Adjust the partner profile to use the new IDOC type
- Implement the appropriate BADI.
For this blog I am using the IDOC for equipment replication to C4C, COD_EQUIPMENT_SAVE01.
Note: We are in process of providing the relevant BADI for all IDOC types except COD_EQUIPMENT_SAVE01. This should be available with C4C 1911 release. Implement note 2820485, to use extension for IDOC type COD_EQUIPMENT_SAVE01.
The IDOC COD_EQUIPMENT_SAVE01, is based on Function Module COD_EQUIPMENT_SAVE, which uses the complex data type COD_S_EQUI_ROOT
As a first step, extend the data type based on your requirement using Append Structure in SE11, for example for this blog I have added a custom field at the header level directly under structure COD_S_EQUI.
Once the structure has been enhanced, we need to generate the ALE interfaces using BDFG.
Provide the Function module name and system will auto populate the Business Object type and Message Type.
Now change/edit the interface (F6)
Note: Don’t create a new Message Type, else the Initial load reports will not work as they use the standard message type name to find the correct ALE function modules.
Provide a name for IDOC type and Function Module name for ALE processing in customer namespace.
System will generate the IDOC, the ALE function modules and create the necessary linkages (advantage of using BDFG, developer need not worry about writing code to map to and from IDOC structure)
Note: For some IDOC types, there can be cases where some special logic might have been added to the generated ALE function modules. Check the original ALE function modules and copy the additional code to the newly generated ALE function module in customer namespace. As an example, the ALE function module for Sales Order replication to C4C (ALE_COD_REPLICATE_SALES_ORDER), has some additional logic to handle BINREL.
As a next step, update the partner profile to use the new IDOC type.
Finally implement the BADI to populate the extension field in the append structure. For Equipment replication the BADI is COD_SLS_SE_EQUIPMENT_REPL, which can be found in the main function module GET_EQUI_DATA_FOR_IDOC
Now let’s run a test by changing description for an equipment.
This will trigger the IDOC based on change pointers, we can find our extension segment in the outbound IDOC.
Similarly for proxy based objects, one can use ABAP-based Metadata Repository (MDR) for creating data type enhancements, in case there is no JAVA based ESR system is available. Refer to SAP Note 1575707 for more information. You can also refer to the informative SCN blog by Florian on, MDR: Defining web services from ABAP without requiring PI
That’s all about this blog.