CMDB Data archiving

ayman_h
Kilo Sage
Kilo Sage

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 

1 ACCEPTED SOLUTION

michaelward
Tera Guru

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.

 

View solution in original post

6 REPLIES 6

michaelward
Tera Guru

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.

 

gg73
ServiceNow Employee
ServiceNow Employee

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? 

ayman_h
Kilo Sage
Kilo Sage

Thanks @michaelward, thats quite helpful!

Ashok Sasidhara
Tera Sage
Tera Sage

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.