
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-18-2024 03:47 AM
Hi all,
We are thinking of setting up archiving rules for our CMDB tables using the CMDB data manager to archive CIs if they haven't been discovered for 30 days.
Can someone confirm if an archived CI comes back to life (discovered again), will the existing CI record move from the archived table to the cmdb_ci table based on IRE rules or does this lead to a new record being created?
Regards,
Ayman
Solved! Go to Solution.
- Labels:
-
Data Foundations
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-18-2024 06:58 AM
Hi Ayman. My experience is that when the CMDB manager archive policy runs, a task is created to the fulfill such that the task is pending, the general 'Archive' scheduled job runs, the CI is moved to the respective archive table, then you can actually expect to have a new CI record created via discovery or a data source.
A way to test this, which I have, is to pick a CI class, preferably a simple CI class like 'computer' which may not have relationship requirements, and then follow these steps:
1. Create a CI manually either via a form or using the SNC.IdentificationEngineScriptableApi.createOrUpdateCI() API. i like to use the API because it affords me the ability to carry around a JSON payload. If needed, use the Identification Simulation tool to generate a payload.
2. Set the record's install status, lifecycle stage and status to 'Retired'.
3. Run the 'CMDB Data Manager Archive/Delete Policy Processor' scheduled job. This will generate a policy task, which you can then manually approve through the CMDB Data Manager.
4. Run the 'Archive' scheduled job. You may have to look at 'Todays scheduled jobs' to find it. This will archive your CI.
5. Use the Identification Simulation tool to test the creation of the CI, using the same payload. You will notice the output will indicate an INSERT vs. and UPDATE. This is the clue you will indeed have a new CI created.
6. Go back to step 1, and use the SNC.IdentificationEngineScriptableApi.createOrUpdateCI() API, passing in the payload which matches the CI. If using something like computer, a serial number will do, but I use a name and serial number.
7. You will notice the CI is indeed created with a different sys_id of course. You will also notice the archive table continues to hold the archived CI, provided the retention period has not passed before the CI is deleted.
I hope this helps.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-18-2024 06:58 AM
Hi Ayman. My experience is that when the CMDB manager archive policy runs, a task is created to the fulfill such that the task is pending, the general 'Archive' scheduled job runs, the CI is moved to the respective archive table, then you can actually expect to have a new CI record created via discovery or a data source.
A way to test this, which I have, is to pick a CI class, preferably a simple CI class like 'computer' which may not have relationship requirements, and then follow these steps:
1. Create a CI manually either via a form or using the SNC.IdentificationEngineScriptableApi.createOrUpdateCI() API. i like to use the API because it affords me the ability to carry around a JSON payload. If needed, use the Identification Simulation tool to generate a payload.
2. Set the record's install status, lifecycle stage and status to 'Retired'.
3. Run the 'CMDB Data Manager Archive/Delete Policy Processor' scheduled job. This will generate a policy task, which you can then manually approve through the CMDB Data Manager.
4. Run the 'Archive' scheduled job. You may have to look at 'Todays scheduled jobs' to find it. This will archive your CI.
5. Use the Identification Simulation tool to test the creation of the CI, using the same payload. You will notice the output will indicate an INSERT vs. and UPDATE. This is the clue you will indeed have a new CI created.
6. Go back to step 1, and use the SNC.IdentificationEngineScriptableApi.createOrUpdateCI() API, passing in the payload which matches the CI. If using something like computer, a serial number will do, but I use a name and serial number.
7. You will notice the CI is indeed created with a different sys_id of course. You will also notice the archive table continues to hold the archived CI, provided the retention period has not passed before the CI is deleted.
I hope this helps.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-13-2024 07:01 AM
Hello,
Which table does the CI get archived to and how long does it stay in that table? Does it get deleted after a certain period of time? if yes, how long?

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-18-2024 11:11 AM
Thanks @michaelward, thats quite helpful!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-18-2024 01:16 PM - edited 10-25-2024 06:55 PM
I would like to state some critical process related considerations for this. It is not recommended to archive active CIs after a short period like 30 days. You can consider retiring CIs once they meet the staleness criteria for a CI class (It can be defined as something like 14 days or 30 days or more for each class depending on the frequency of data population). As part of the process, it is important to define archival and data retention periods. Archival period can be something like 1 year or more after the CI gets retired. After that, the CI should get archived. Data retention period should be ideally even longer (may be something like 5 to 7 years) as data may have to be retained for audit or legal or regulatory purposes. Once the data retention period is over, the archived CI can be deleted.