We are currently working on a scripted solution to reduce the very large number of configurations in GC, DNG and ETM on our server. This activity is mainly based on several IBM recommendations that we have to keep the server clean and that so many (active) configurations caused performance issues in the past and will also cause further (performance) issues in future.
We currently have nearly 100.000 active configurations on our DNG server (after archiving some PAs and also configs manually).
Based on the mentioned recommendation we are trying to automatically reduce the number of configurations as much as possible by running the script periodically.
To get agreement of the users (who always fear that such cleanup will cause a lot of work) we are in parallel working on a usability widget that will allow users to restore complete GC trees in a 1-click action whenever they would need it back e.g. for audit purpose. With GC trees that can easily be 5 (or more) levels deep and overall have up to 200 local contributors such a widget is already a must have.
Status Quo:
Currently, working with archived configurations through public APIs is hardly possible. In general, GC, DNG and ETM support (automated) archiving of configurations.
There are three main use cases for interactions with configurations when considering the archiving state.
- Archiving a configuration -> e.g. scripted, with focus on whole server
- Requesting information about an archived configuration -> e.g. getting a complete GC tree to restore
- Restoring an archived configuration from the archive -> e.g. based on contribution to a GC tree
1 Archiving
- GC:
- Has a public API
- PUT on path "/gc/configuration/" after retrieving the eTag using a GET on the same path
- RM:
- No public API
- POST on path "/rm/localVersioning/configurations/archiveWithDecendants" can be used to archive
- QM:
- No public API
- POST on path "/qm/service/com.ibm.rqm.configmanagement.service.rest.IConfigurationManagementRestService/archiveConfigurations" can be used to archive
2 Requesting Information
- GC:
- Public APIs (e.g. "/gc/configuration", "/gc/contributions") consider archived configurations as not present
- GET on "/gc/gc.webui.getTreeNode" can be used to get content information of an archived configuration
- RM:
- No public API
- GET on "/rm/localVersioning/configurations" can be used to get content information
- This API is listed via a public API under path "/rm/localVersionExplorer" but is not public itself.
- QM:
- No public API
- GET on "/qm/localVersioning/configurations" can be used to get content information
- The QM services documentation under path "qm/doc/services" is lacking in content.
- The API under "/qm/localVersioning/configurations" is not listed at all.
3 Restoring
- GC:
- No public API
- POST on "/gc/gc.webui.updateConfiguration" with "setArchived=false" in the request body can be used to restore from archive
- RM:
- No public API
- POST on "/rm/localVersioning/configurations/restore" can be used to restore from archive
- QM:
- No public API
- POST on "/qm/service/com.ibm.rqm.web.common.service.rest.ITrashWebRestService/restoreItems" can be used to restore from archive
In summary, one can say that there are almost no public APIs which can be used to handle the three main use cases regarding archiving of configuration.
Proposal:
A public API to handle the archived attribute for configurations across the domains GC, RM and QM.
The API shall be reachable under a URL that is consistent across applications.
The API shall at least make it possible to archive a given configuration, query whether the configuration is archived (incl. context information / attributes / metadata) and if archived, provide a way to restore it from archive.
The API shall be documented and marked as public under "<domain>/doc/services".
