The outbound customizable HR interface - alias - HR Channels. The HR module is quite elaborate and SAP recognized this could cause issues when HR information needs to be interfaced. They came up with a huge interface toolbox transaction called PU12 which will guide you through a series of steps in order to produce an interface of some sort. The transaction pre-dates Object Oriented programming, and I have had the pleasure to work out an outbound interface in an Object Oriented fashion, which uses customizing tables to map its fields.
The original plan was derived from a large interface request - HR data needed to be interfaced to an ADP system. Due to the sheer scale of data to be interfaced, the approach utilizing mapping tables was introduced right at the beginning. ADP expects it's data in (up to) 70 datasets with (up to) 800 fields (that's the fields of all datasets combined).
This concept has been moulded into a full grown product, more on HRchannels.nl
These articles describe how the interface works and can be regarded as the technical design documentation for the coding. It shows how a somewhat larger setup can be used to create outbound interface files, utilizing Object Oriented programming features. The setup shows how it all works and also why it was done the way it was done. Of course the example setup is for HR data, but there is no reason to adjust the (local) data factory classes to your own requirements.
Presentation for a demonstration
A presentation (in PDF format) is made available in which the author explains how this setup works.
Key selling points
The interface is a fresch object oriented approach to outbound HR interfacing, for which a 3-table data model was set up and a super-user report on mapping settings was added. A complete package with these main selling points:
- The PNP logical database (the largest logical database available) was utilized for the selection of employee infotype information. Unsupported infotypes can be added with very limited effort.
- Employee cluster information can be used (through structure
HRF_TIM_B2, which holds 35 internal tables with cluser data). - Organisation plan data can be made available (in a form like presented in transaction
PPSM). - SAP standard tooling like Logical file name and file path (transaction
FILE) and progress/error logging via the Business Application Log (transactionSLG1) are used. - An object oriented setup is used, in which additions have a predefined location. There is a class-diagram for thes setup available and there is also a class-diagram which clearly shows where additions in coding may be required and where whole subclassed are to be added.
- The setup has had a number of succesful implementations
- Mapping through customizing settings directly means that no (abap) logic is executed for an interface, dataset or field on a dataset anywhere in the interface program - unless it is triggered by the mapping settings. This is a great feature for maintenance. Every bit of coding was build to (1) support all possible interfaces, datasets or fields OR (2) implement a selection (
lcl_select...) field mapping (lcl_abap...) or export (lcl_export...) in line with mapping settings. - Even though the interface is to be regarded as an interface toolbox, which can support multiple interfaces, the main program can also be copied. This would create a spin-off where the same tables with mapping settings can be used and the same mapping report program can be used. Scalable without limits.
- When a change is requested - there is a very good chance the super-user can do it - as mapping settings are customizing settings.
The HR customizable outbound interface tool that is described here was created when a large interface with over 40 separate datasets was required, all on HR data. The PU12 tool was an option, but the setup needed to be lean and mean, so a mappable new solution was designed - and built. As a brief product overview, the look and feel of this setup is outlines in this article.
The data that should be interfaced is to be selected. This is a task for the data factory classes of the interface and - due to the re-useable nature of the setup - the selection should be fully controlled by selection screen parameters and select-options.
The mapping information that is held on customizing tables controls how the interface populates it's fields. In effect, the mapping tables reflect the datasets (record structures, file layouts (where several file layouts could be applied to the same file, sequences of interface fields) from the receiving system. To do this, a total of 3 tables are required.
The interface is delivered with a wide variety of options, which could be applicable to any interface. Whether you want to CONDENSE a field or turn it into an UPPERCASED value, the options list is listed here. Of course if your option is not there, check out how to add your own:
Abap coding blocks can be created where needed. They are aimed at getting the value for 1 specific field and can effectively do anything to achieve this goal. A number of coding blocks are already available which can be used for your interface or as a reference on how to set up an Abap coding block.
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 ?
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 geoKey works as an exception catcher, on a mapping level. If something needs to be done in a different way for an interface run, the Geographical Key is the way to specify the deviation route. A geographical key indicates the key value for which a different mapping should be applied. As this is quite often a geographical matter, it is called geoKey. The company code, a cost center or an arbitrarily chosen name can all be geoKeys.