Issue with Asset Serial Number Clearing on Insert and Stay

[Siddhesh Jadhav]

Hello All,

We have encountered an issue on the alm_asset table related to duplicate asset serial number validation.

Issue Summary:
1. We implemented a check to prevent duplicate assets with the same serial number by displaying an error message if an asset with the same serial number already exists.
2. During testing, we discovered an OOTB (Out-of-the-Box) functionality that affects our validation when using the Insert and Stay UI action.

Observation:
1. On the first insert, the Configuration Item (CI) field gets cleared, and the error message appears stating that an asset with the same serial number already exists.
2. Without leaving the form, when we perform another Insert and Stay, the serial number gets cleared automatically.

Investigation:
1. Today, I found a Business Rule (BR) named "Null out CI on Insert and Stay" on the alm_asset table.
2. After disabling this BR, I tested the functionality again, and this time, the serial number did not get cleared.

Request for Assistance:
1. Could you help me understand the flow of this behavior? Specifically:

2. How does this Business Rule impact the serial number field?
3. Is this clearing behavior expected as part of standard CMDB functionality?
4. Would disabling this BR have any unintended consequences on other processes?

Thanks,
Siddhesh Jadhav

[Kieran Anson]

I wouldn't deactivate that BR - You're not seeing an issue when it is deactivated because the logic to create a CI ( in a later BR) isn't running. This later BR (Create CI on Insert) is what causes the insert failure as createCIUsingIRE function throws an error.

Oddly, when you double-use "insert and stay" , the second time around the serial_number value is present in the transaction, but current.serial_number is empty. Which is why the serial number field is empty. It's as if something is removing it before business rules run.

[CMDB Whisperer]

I would not advise using Insert and Stay command on Assets or CIs in general.  What is your reasoning for doing so?  I would suggest simply disabling this command on Asset and CI tables (or at least on Hardware) might be a better way to go.  While it's a useful tool in some cases for cloning an existing record, on principle I don't think it fits with the leading practices for how assets and CIs should be created.  A new asset should be the result of a purchase, and a new CI should be the result of the deployment of an asset or some other logical/virtual configuration, not by "manually duplicating a record in a database".  "Insert and Stay" is basically like "Copy and Paste" and just isn't a good indication that you are following practices that are good and sustainable for the health of your asset and configuration management processes. 

I also echo the statement that you should not be disabling out of the box business rules that are in place to manage your asset and CI creation or synchronization processes.  That's just asking for trouble.  Instead ask yourself: Why do I have this new asset?  Where did it come from?  Can I import this as a new record and map the data to the appropriate fields?  Also, there is already a BR that ensures you won't have duplicate serial numbers on a CI.  Asset creation will fail if you try to do this, because when the CI creation results in a duplicate, the asset creation will abort.

While I'm sure we could dive in deeper and get you the actual technical answers to your questions, I think the more important answer is that your basic use case is probably flawed and you should reconsider what you're trying to do.