Arbitrary value store (registry) for ABAP
One of the problems ABAP developers face from time to time is the need to store arbitrary values for processing. These values do not always justify creating a new table, and there is no convenient place to store such values.
Developers often come up with creative ways to store values for very specific cases to avoid hard-coding them, such as writing entries to TVARV. However, this is not a very neat solution and sometimes leads to awkward workarounds for more specific sub-cases, like inventing conventions for putting composite keys into the name.
The solution I am presenting here consists of a hierarchical value store, not unlike the Microsoft Windows Registry. It allows the developer to retrieve and store values that cannot neatly be associated with some configuration and which does not warrant the creation of a new table. An example would be when some logic needs depends on a master data value (like a certain customer), or if the developer provides some tool that provides some customization options.
The store is backed by the table INDX, which you will find standard in every ABAP installation and which is accessed conveniently with the statements EXPORT TO DATABASE and IMPORT FROM DATABASE. There is of course no reason not to use a custom table for this, but using INDX avoids you having to create yet another table; although if you are worried about keys colliding with other entries in there, you can simply use search-and-replace to specify a different table.
The solution is presented in the form of an API, the source for which is contained in an include. You could of course use the source-code view in the class editor in SE24 to add the class to the repository, but distributing the code as an include is just very convenient, and I am all for convenience.
Furthermore, the values are all stored as strings, though I imagine that if you consistently read to or write from fields of the same type, that should not be a problem. Maybe in a future version, I will look at adding a type specification for each value stored.
Additionally, there is some concurrency control in the form of optimistic locking, though I am not entirely sure whether there is a practical need for it. Adding new entries (keys) to the registry causes the new entry and the parent entry to be saved immediately, while values in each entry must be saved explicitly (although they will be saved automatically when making changes to the entries; I am still thinking about auto-saving any changes).
The second part of the solution is a registry browser/editor, which is similar to the RegEdit application on Windows, which allows an administrator/consultant to inspect the contents of the registry.
(The editor, like the library, is provided as a self-contained piece of source code that can be pasted into a report program, avoiding you having to create additional items in the repository. See below for the link to the source code).
Here is an example of how you could use the registry:
I have given some thought to security; whereby you would want to prevent your section of the registry becoming inadvertently overwritten by another application or person. One approach is to lock down the registry and require applications to write their entries and provide an applicable UI, which is analogous to how Windows applications operate, e.g. when recording user settings. Another approach would be to extend the editor so that it can be run to access only a certain branch of the registry tree and give specific users access to that.
You can find the entire source code of the include for the library, as well as the registry editor and the example program at the following Gist on GitHub: https://gist.github.com/mydoghasworms/08ea60e95dd1fa90c90a
Leave a Reply