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 (transaction SLG1) 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.

• Next