As this is an Object Oriented setup, the class diagram can provide excellent inside views on how the process hangs together. This article describes the main tasks the report will run through to select great big heaps on HR data, apply the mapping that is defined in mapping tables and produce output.
The main processes are grouped as Data factory, Dataset builder and Export, with a group Utility along side. A brief summary on each group:
Data factory
The data factory selects and holds the data that is interfaced. For HR PA data this is implemented via a logical database PNP which is in fact the soul supplier of PA (read: infotype 0000 - 9999) data. The idea is that all information that is to be interfaced is put in the belly of this report, in the form of data factory classes. As mentioned before, the data factory classes (in the example lcl_Data_Employee and lcl_Data_Meta are all about selecting and holding data. In the case of lcl_Date_employee a few additional methods (Register( ) and Focus( )) were added to support building or accessing the data on the data factory class.
Feel free to add your own selections on an existing data factory class, or add new ones where you see fit.
There are many chances and opportunities to pick up additional data from the database "on the fly" - but it's preferred to select all you need to interface in the data factory classes.
Dataset builder
The dataset builder is a rather elaborate machine that composes an internal administration of what needs to be interfaced. Eventually a series of instances of the lcl_Dataset class will be created and filled up. Note that an instance of lcl_Dataset holds attributes gt_rows and gt_columns in which actual mapped data will be stored.
If the whole group dataset builder is regarded as a black box, the information from the data factories is put in along with the information from the mapping (customizing) tables and a set of lcl_Dataset is thrown out. This table can be found in attribute lcl_ControlCenter=>gt_datasets.
Class lcl_ControlCenter does what it's name suggests, it's the central manager of the interface process. From this class a selection class is instantiated (controlled by the primary table on dataset customizing) and a selection of data from the data factories is done.
The setup for the lcl_Select class is superclass/subclass construction: for each type of primary table that is defined on the customizing table, a selection class needs to be implemented. So for primary table P0001 selection class lcl_SelectP0001 needs to be implemented.The class needs to be linked in method processDatasets( ) of class lcl_ControlCenter.
In the mean time, the class lcl_Abap is packed with option-processing functionality you are likely to use. Nevertheless you may need other points where you would like to involve a bit of Abap coding to get the correct value. Hence for each interface you can add an Abap class like lcl_AbapADP which inherits from lcl_Abap and can hold Abap logic (field level logic) specific to the interface. Which brings us to a rather big point: this setup does not just support a single interface. Whenever you want to add logic, you will have to decide: is it specific to this interface, or could other (HR) interfaces benefit ?
Other that that, there is also the option to have you own abap class inherit from an interface specific class, just because you need the same plus a little extra.
Export
The lcl_Export class holds functionality on filenames, which you don't necessarily need. Are you creating an outbound Idoc with the gaterhered information ? It is an XML file you need ? Add a type and add your class to support the type. The Execute method will be called with a full set of filled datasets available to you (on lcl_ControleCenter=>gt_datasets).
Utility
This group of classes holds a few utility classes - that do play an important role in the whole. Class lcl_Logging can be used to add information, warnings or errors to the interface log. Logs are set up as BAL (Business Application Log) which can be viewed in transaction SLG1 or via a button on the interface selection screen. The log is also displayed at the end of a run. Use it when you implement your own logic - if something goes wrong just throw the error (method set_error( ).
Then there it the lcl_Option class, which takes apart the ZHRI_MAPPINGS-OPTION and chops it up to manageable chunks. You'll have no business directly using this class.