In our environment for non-asset CIs we don't currently populate any of the CORA fields, so when we attempt to use GRLoader to make updates to other attributes on an existing non-asset CI we get one of two outcomes.
1. We get an error stating the GRLoader won't insert new CIs without -n variable
2. If we add the -n to the command string, a duplicate CI is created and the existing CI we were trying to update remains unchanged.
Is it possible to make updates to existing non-asset CIs when all CORA fields are null without creating a duplicate CI?
Unfortunately the answer to your question is no CORA is what actually prevents duplicates from being created. It does this by the weighted CORA fields - if there are a certain level of them matching, then it detects it as a duplicate. If there are none matching then it does not see it as a duplicate and so it creates a new one. The only way to do this would be to populate the CORA fields first, then do a load which would properly detect the duplicates.
There may be some other folks out here on the communities that have been in the same situation, and can share some other ideas with you.
I'm vaguely surprised that you can create a record without at least one of the CORA attributes (not even 'name'?). However, you might still be able to use pdm_load. If you have a unique combination of attributes that identify the CI then you should be able to use pdm_deref to insert the CI's UUID into your update record and then 'pdm_load -u' should be able to update it.
Hope that helps!
Like James I'm a bit surprised, also about how you work with it if it doesn't have a name...
You may also be able to update the CI if it has a federated_asset_id from source (MDR) that you can leverage with GRLoader.
And yet a third option would be to load it into TWA and then avoid the duplicate CI record by loading from TWA after having made sure it reconciles with the existing CI...
James - I apologize for the confusion. We do populate the 'name' field. However when that is the only CORA field populated it doesn't seem to carry enough weight in the reconciliation process and one of the two outcomes I listed above occurs depending on our command string.
Will try the different options provided
Thanks for the help