In the new version of ServiceNow Asset Management, Assets are now in a separate table named Asset [alm_asset]. Prior to the Berlin release, assets were included in the Configuration Item [cmdb_ci] table. Removing assets from the cmdb_ci table provides more flexibility to build new features into the Asset Management application in the future and helps prevent the cmdb_ci table from growing too large.
Asset-CI mapping and synchronization
There are a lot of advantages with two tables, however the difficulty is to keep them in sync. Here are a couple notes on for asset/ci synchronization:
Model categories associate CI classes with asset classes. The model category configuration determines if ServiceNow should create an asset from a CI and if so, what class of asset.
This is straightforward how the Model Categories work. If you a certain CI, for example, Computer [cmdb_ci_computer], to create and update an related asset, it must have a model category.
It might be tempting to map every type of CI to an Asset. However it is advised to only create an asset when you are using it for financials.
Asset management and configuration management (CMDB) are related, but have different goals. Asset management focuses on the financial tracking of company property. Configuration management focuses on building and maintaining elements that create an available network of services.
Script Include: AssetAndCISynchronizer
There are five business rules that handle the Asset/CI synchronization:
Create CI on insert, Table: alm_asset
Update CI fields on change, Table: alm_asset
Create asset on model change, Table: cmdb_ci
Create Asset on insert, Table: cmdb_ci
Update Asset fields on change, Table: cmdb_ci
The good news is that you probably won't have to modify those business rules to maintain synchronization. The bad news is that you will likely have to modify the Script Include: AssetAndCISynchronizer.
This Script Include handles the field-level synchronization of Asset and CI data. Common fields like asset_tag, location, and cost_center are mapped. However your user-created fields are not mapped.
For example, if I had a field in a CI called u_project here is how I would get that field to be transferred to an asset.
1. Create the u_project field in the alm_asset and cmdb_ci table
2. Add this line to the AssetAndCISynchronizer Script Include:
changes += this._syncField('u_project', source, destination);
That is pretty easy. What happens though when the field names don't match. Here is an example when you want to map cpu_manufacturer from a CI, but the asset field you created is u_cpu_manufacturer.
1. Create the u_cpu_manufacturer field in the alm_asset table
2. Add this line to the AssetAndCISynchronizer Script Include:
changes += this._syncCPUManufacturer(destinationBaseTable, source, destination);
3. Add this function to the AssetAndCISynchronizer Script Include:
_syncCPUManufacturer : function(destinationBaseTable, source, destination) {
if ('alm_asset' == destinationBaseTable) {
if (source.cpu_manufacturer != destination.u_cpu_manufacturer) {
destination.u_cpu_manufacturer = source.cpu_manufacturer;
return 1;
}
return 0;
}
if ('cmdb_ci' == destinationBaseTable) {
if (source.u_cpu_manufacturer != destination.cpu_manufacturer) {
destination.cpu_manufacturer = source.u_cpu_manufacturer;
return 1;
}
return 0;
}
return 0;
},
Synchronization Script
If you have added new fields to a CI and an asset, adjusted the AssetAndCISynchronizer script include that will allow all future data for those new fields to transfer and sync. On every new creation of a CI/Asset or the update of a CI/Asset will cause that new field data to sync. However most of us don't want to wait until the future and want all CI and Asset data synced and updated sooner than that.
Just so happens I have a simple background sync script that you can run to sync those assets and CIs.
Couple notes on this script first.
Test first. syncing assets and CIs can take a long time
This background script should be only run when you have a new field to sync. I wouldn't suggest running it every day as it will affect performance.
You will need to adjust the script to only sync the CIs you are interested in. In my example script, I am just syncing the cmdb_ci_computer table, but they may be other tables you might want to sync. I could have built the script off model categories to sync the mapped tables, but that will be v2.
Here is the example script:
syncAllAssetRecords();
function syncAllAssetRecords() {
var grCI = new GlideRecord("cmdb_ci_computer");
grCI.query();
var updateCount = 0;
while(grCI.next()){
var ca = new AssetAndCISynchronizer();
ca.syncRecords(grCI, 'alm_asset');
updateCount++;
}
}
gs.print('Records Synced: '+ updateCount);
Hope this helps on your ITAM projects.
Mike