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.
The setup is as follows: when the interface is run, all the fields on all the active datasets for the interface are mapped and composed. If a geokey is specified on the selection screen of the report, the interface will ALSO apply mapping entries for the matching geokey, AFTER regular mapping entries (which have a blank geoKey field) are mapped.
To explain this concept - consider the following example: you want to multiply the salary for yourself and a group of friends by 10, just to test the system (otherwise you would be a fraudulent person of course).
- Find the field mapping that contains the salary, for example sake this is P1234-SALARY.
- Copy this field mapping, fill in MORESALARY in the geoKey field
- Also add a formatting option to the newly copied mapping, by filling in NUMBERFORMAT:10X
- Save the new field mapping.
All you need to do now is run the report in 2 shifts: the first shift should exclude the shortlist of your friends (e.g. on personnel number) and the second run should only be for the shortlist of your friends. Also: in the selection screen of the second run, the geoKey MORESALARY should be set.
So exception processing via the geoKey can be done directly on the mapping table.
Automatic population of the geoKey
The geoKey usage as described above can be used to deviate from the regular mappings controlled via a field on the selection screen. What happens to this field is that the value from the selection screen geoKey is placed in the lcl_controlcenter=>gw_interface
structure. Whenever the mapping for a field is completed and conversion rules are applied, the interface will check whether a mapping for the specific geoKey is also available and process and complete it for the same field.
The other way to use the geoKey is the determined/composed key. For each lcl_Select
involvement the geoKey can de composed from the data that is being processed. The geoKey could thus be set to the company code or the company code combined with something else. Mapping entries that are for a specific company code only can be captured this way.
So what if both mechanisms are used simultaneously ? The value entered on the selection screen is a default that can be overwritten in the lcl_Select
methods. Unless of course you want to do this the other way around, which you can control yourself.