The interface report is set up to support multiple interfaces. The inheritance feature of classes was used to cater for this growth. This article describes how the class holding conversion logic can be made specific to an interface. After implementing this, the developer get's to chose where to put new functionality: should it be available to all interfaces or is it an interface-specific theme ?
There's a class called lcl_Abap and it has a main method describing the main function of the class. Method CONVERT_FIELD will transform the value of an interface field into whatever is needed/required. For this conversion there is a field called OPTIONS which can hold instructions on how the field should be converted. The focus here is on understanding how lcl_Abap and lcl_AbapADP hang together - ADP is a company to interface to, so in this example the lcl_AbapADP class is an interface specific class.
The lcl_Abap class
A sneak preview of the definition of lcl_Abap:
CLASS lcl_abap DEFINITION.
PUBLIC SECTION.
CLASS-DATA:
gt_translations TYPE STANDARD TABLE OF zhri_translation,
gt_result_objec TYPE STANDARD TABLE OF objec, "<= holds result of get_struc
BEGIN OF gw_datesettings,
absolute_begin TYPE d VALUE '19000101',
absolute_end TYPE d VALUE '20501231',
empty TYPE c LENGTH 10 VALUE '00-00-0000',
END OF gw_datesettings,
BEGIN OF gw_processing,
option_parameter TYPE c LENGTH 40,
param1 TYPE string,
param2 TYPE string,
param3 TYPE string,
length TYPE i,
translationdone TYPE boolean,
abap_requested TYPE boolean,
END OF gw_processing,
go_options TYPE REF TO lcl_option,
gw_zhri_mappings TYPE zhri_mappings.
CLASS-METHODS:
class_constructor.
METHODS:
prepare_interface,
* This method is called to perform the report's main task - at field
* level. A value was determined before and conversion logic is applied
* here - dictated by the OPTIONS field (lcl_mappings-options).
convert_field IMPORTING field TYPE any
CHANGING value TYPE any,
* Utlity methods, which are not specific to an interface, logic that can be
* applied to multiple interfaces.
formatdate
IMPORTING parameter TYPE any
CHANGING value TYPE any,
formatnumber
IMPORTING parameter TYPE any
CHANGING value TYPE any,
apply_translation
IMPORTING source TYPE any
CHANGING value TYPE any,
get_looncomponent_value
IMPORTING p1 TYPE any p2 TYPE any p3 TYPE any
EXPORTING value TYPE any,
find_earliest_date
IMPORTING infotype TYPE any
EXPORTING startdate TYPE any,
get_hr_leaving_date
EXPORTING leaving_date TYPE any,
get_struc
IMPORTING otype TYPE objec-otype
objid TYPE any
evaluationpath TYPE t778a-wegid
depth TYPE hrrhas-tdepth DEFAULT 0
RETURNING value(success) TYPE boolean.
ENDCLASS. "lcl_dataset DEFINITION
The class holds PUBLIC SECTION data needed to process Abap logic - on field mapping level. As the interface specific abap class is defined INHERITING FROM the lcl_Abap class, all of these attributes and all of these methods will be available from your own" class. Now here's the deal: when the report starts, there is an attribute on lcl_ControlCenter=>go_abaplogic which is defined as being a type ref to lcl_Abap. Since the interface-specific version of lcl_Abap (lcl_AbapADP) is inheriting from lcl_Abap, the lcl_ControlCenter=>go_abaplogic attribute can also be set to the interface specific class.
The lcl_AbapADP class - interface specific
So how would you add an Abap field conversion class - that will only be used/available for you own interface ? First of all define the class. The definition would look something like:
CLASS lcl_abapadp DEFINITION INHERITING FROM lcl_abap.
PUBLIC SECTION.
METHODS convert_field REDEFINITION.
ENDCLASS.
Then to get the interface report to involve the class, it needs to be assigned to lcl_ControlCenter=>go_abaplogic. This can be done on the control center class, method INITIALIZE, a bit of coding:
*-----------------------------------------------------------------------
* Assign the lcl_abap class specific to the interface. This is the full
* list of supported interfaces - which have thier own abap source support
CASE lcl_constants=>gv_interface.
*-----------------------------------------------------------------------
WHEN 'ADP'.
* The ADP interface, which works with a set of up to 70 files or datasets
DATA: lo_abapadp TYPE REF TO lcl_abapadp.
CREATE OBJECT lo_abapadp.
go_abaplogic = lo_abapadp.
*-----------------------------------------------------------------------
WHEN OTHERS.
* The lcl_abap class is assumed when no supported Interface could be matched
CREATE OBJECT go_abaplogic.
ENDCASE.
Note that if no interface-specific abap class is specified, the lcl_Abap class itself will be used, so you only need to implement this when you really need to apply your own conversion logic (which is very likely to be a requirement). In your own class only the method you would need to redefine is the CONVERT_FIELD method. You want to call the CONVERT_FIELD from lcl_Abap, like so:
* Support the Abap coded routines from the global setup super->convert_field( EXPORTING field = field CHANGING value = value ).
If it is a specific type of processing you don't want the lcl_Abap class to do, consider calling the super class conditionally (so: don't call it for the specific case you want to avoid or do differently).
The beauty of this setup is that logic you add for your interface lands on an area specific to your interface. The interface report will call CONVERT_FIELD method via lcl_ControlCenter=>go_abaplogic, which could be pointing at the general lcl_Abap->convert_field( ) method, but it could just as well be pointing at you own lcl_AbapADP->convert_field( ) method. Either way, the logic on lcl_Abap itself is never lost (always available to use).