Overlay datasets
Overlay datasets in BMC Helix CMDB let you make controlled changes without overwriting your production data. Overlays provide a separate layer where you can modify instances, review changes in context, and merge updates into the underlying dataset when needed.
BMC Helix CMDB offers overlay datasets, which enable you to:
- Make changes in a separate partition without overwriting your production data.
- See your changes in context with the unchanged portions of your data.
- Avoid duplicating your entire production dataset.
- Reuse one set of reconciliation definitions when merging multiple overlay datasets into production.
- Reuse one set of reconciliation definitions when merging multiple overlay datasets into production.
How overlays work
When you create an overlay dataset, you must specify an existing regular dataset for it to overlay. Although an overlay dataset starts out empty like any other dataset, any request for an instance in the overlay dataset passes through the overlay dataset and returns that instance from the underlying dataset.
When you modify an instance in the overlay dataset for the first time, it is copied there from the underlying dataset with your modifications. You can also create instances in the overlay dataset. The underlying dataset still holds the unmodified versions of its original instances, but it does not hold the modified instances. A request to the overlay dataset for a modified instance returns that instance from the overlay dataset, and a request to the overlay dataset for an unmodified instance returns it from the underlying dataset.
The following figure illustrates queries against an overlay dataset, one for a modified instance and one for an unmodified instance. Notice that the modified instance shares the same reconciliation ID with its unmodified counterpart, but not the same instance ID.
Query to an overlay dataset
Result of deleting instances from an overlay dataset
If you attempt to delete from an overlay dataset an instance that actually exists there, the instance is deleted only from the overlay dataset and remains in the underlying dataset.
You can mark an instance as deleted regardless of whether it already exists in the overlay dataset. In either case, this results in an instance in the overlay dataset that is marked as deleted.
Instance ID and identity in overlay datasets
When an instance is first created in an overlay dataset as the result of a modification, it retains the reconciliation identity of the instance in the underlying dataset, but is assigned a new instance ID.
If the underlying instance has not yet been identified when it is modified in the overlay dataset, the instance has no reconciliation identity in either dataset. This is not a problem. When you eventually identify and merge the two datasets, your identify rules should be able to match these instances so that they receive the same identity. If you decide to keep the changes that you modeled in an overlay dataset, you can merge the overlay dataset into the underlying regular dataset.
Make sure that you identify the instance in the underlying dataset first. To identify the overlay dataset instance, run the existing reconciliation job that was created for the underlying dataset in the event-driven reconciliation mode. For information about event-driven reconciliation, see Dynamic dataset and qualification values in event-driven reconciliation jobs.
If you want to run a job in event-driven reconciliation mode, you must create the required entry in the Application Pending form. For information about the run process workflow, see Run process workflow action to perform event-driven reconciliation.
The underlying dataset is the target dataset in your job. When you run the job in event-driven reconciliation mode, replace the source dataset with your overlay dataset.
Related topics
Best-practices-for-managing-datasets