Copyright 2024 - BV TallVision IT

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 interface is a single report with less than 3000 lines of ABAP coding. It supports multiple interfaces running through a single report. Where needed, a copy of the report can be created, which would be using the same datamodel (3 tables) for mappings, dataset definitions and translations. The report selection screen is quite elaborate and also quite important. To facilitate in daily use, one or more transaction codes can be created for the interface report. The report will check whether a variant name with the same name as the transaction code is available and use that variant when started. 

The selection screen of the interface report: 

Period and Selection

These blocks are provided by the LDB (Logical database) PNP and may look a little different on your system. The logical database functionality allows the end user to define a very accurate selection set where time (periods) and actual PA (Personell Administration) is concerned. Please be aware that the interface will work with all data provided via this selection screen: leave all selection fields empty = select everything. Thus the definition of the actual selection of your data is done in the selection screen, for PA data in the top section.

General settings

This block is all about the customizing settings that can be done for the interface. A set of buttons will provide SM31 access to the table for Datasets, Mappings and translations. A report can be called on these settings via the "Definition overview" button and the arrow button will call the same report without skipping it's selection screen. The last button in the range can be used to define the (all SAP-standard) file names and path names that will (can) be used by the interface. Whether actual files and file names are involved depends on the export type of the dataset (e.g. there is an export type "Show on screen" which will not involve any file names).

To run the interface, the field "Interface" is a mandatory field. When the interface name is entered, the interface will attempt to create all active datasets for the interface with the selection criteria provided.

Where a description is determined, the language to use is defaulted to English on the selection screen. Using option DESCRIBE will also use the language specified here (unless a parameter is specified - see the documentation on DESCRIBE). Then there is the default Geo-key, an article on the use of the Geo key is also available in the interface documentation. It should normally be left blank.

The next set of selection parameters is all about the Export processing. Exports are processed according to an export type which is defined on the dataset (ZHRI_DATASET). Some export types support delta's (a check whether the information has been sent out before, only produces output when changes are detected), filenames and paths (using the all-standard Filenames and logical file paths from transaction FILE) and the default settings there-of. The Server path and an example filename are displayed - for you to check where files would be created and with what name - however - the export would still need to support these settings (e.g. output type "Show on screen" would not bother with filename settings or delta's). Then the last setting is whether a file is appended to or overwritten, should the filename not be unique.

The button "Application logs" will start transaction SLG1 in which error logs (or processing logs) are stored. An example of such processing log:

The Business Application Log is a method of error logging which is used by the interface. From anywhere in the program for whatever reason, messages can be added to this log. It contains details on the interface, base date, employees selected, processing and the filenames that have been created. When the interface is executed in the foreground, the outcome that is displayed to the end user is the message from the application log (as shown above). These messages can also be stored or stored when there are errors.

Further selection screen blocks

Other selection screen blocks that follow are all linked to the selection of "data factory" information, of which there are 2 available on the interface: (1) employee data (PA and cluster data) and (2) meta data (the rest, e.g. cost centers, salary scales, ...). The development team can implement new data factory classes where needed and each one of those should have at least 1 selection block on the selection screen.

Each "additional selection block" can be switched on or off, the idea behind this is that your interface may not require e.g. cluster data, so no such data should be selected. Turn this around: make sure all selection screen blocks for the information you are interfacing are switched on !

Definition overview

The overall setup of the mappable interface is well controlled, but not very simple. Hence a check report was introduced as on-line documentation on the settings of datasets. This report is available from the selection screen, button "Overview" (Definitie overzicht) or the button with a black arrow, right next to it. These are 2 ways of starting the same report. An impression:

(Drag-drop this image to a new browser tab to enlarge)

The overview shows the settings from the dataset table and mappings table combined, with added functionality to "explain" the options. Double click on the "Options" field for a brief description of the options used. If there are translations in the option, the values for the translation are picked up and displayed as well.

The above popup is shown when double clicked on the line "ABAP:GET_CARTYPE...", it briefly explains that a bit of added Abap functionality is called to determine the value of the field. Then the value is translated using translation object (code) CARTYPE.