Hi Suseela,
I have been having the same problems.
As you'll know, IRE (Identification & Reconciliation Engine) replaces all the normal things like coalescing in transform maps. Instead it uses CI Identifiers, which are rules to try to find the correct existing CI to update. The issue is that for some CI types - and database instances are one example - discovery needs to first find another CI on which the actual one depends, based on CI relationships. For database instances, discovery first needs to identify the server that the database instance runs on. That type of identification, which first involves finding another related CI, uses CI Identifiers which are "dependent" - they have Independent = false.
Whereas when IRE is called from a transform map via identifyAndReconcile(), it doesn't look up using relationships. It just identifies the target CI based on attributes of that CI, like name for example. Like a normal tranditional transform map does. That type of identification uses CI Identifiers which are "independent" - meaning you can identify the target CI without reference to any dependencies with other CIs.
The trouble being that you can only have one CI Identifier per target CI class. And that CI Identifier can be either "dependent" or "independent". OOTB ServiceNow comes with a large number of CI Identifiers for use by Discovery, and for database instance CIs they are "dependent", for the reasons above.
When you use your transform map, it's using the OOTB "dependent" CI Identifier. And because identifyAndReconcile() doesn't supply that dependency information through to the underlying IRE engine, IRE gives that MISSING_DEPENDENCY error.
I think this is a flaw in the way IRE has been designed. Because Discovery has lots of information, it can do those "dependent" identifications. Other integrations may not have all the information available about the related servers, so they need different CI Identifiers.
I have proposed in this idea on the new Ideas Portal that ServiceNow should support different CI Identifiers per data source. That would allow Discovery to use its CI Identifiers, and your transform map could use a different one. The ServiceNow developers have accepted this as something that needs doing, but it needs enough people to up-vote that idea to show that it's worth them doing.
Note that I raised that Idea following a HI Case that I'd raised for a slightly different issue, namely that I couldn't do a "lookup" type of identification with the OOTB dependent CI Identifier. But it's the same basic problem, that you can't do these things on a "dependent" CI Identifier.
In your case, at the moment you basically can't use IRE in your transform maps for database instances. So you would have to go back to doing the traditional type of transforms, with them doing the coalescing etc.
That does unfortunately mean that IRE wouldn't handle things like precedence, to control which fields your integration would take precedence for over discovery. And you said that is one of your requirements, which makes absolute sense. You could try to add code to your transform maps, to use and maintain the same underlying tables that IRE uses. Like using the reconciliation and precedence definitions, and maintaing the cmdb_datasource_last_update, which records which data source last updated each field on each CI. But it's likely to be quite complicated to do that, I'd say.
Hope this helps?
Regards
Michael
