Jean-Louis, Well, it is linked with the reconciliation ID as the primary link. As you note, the reconciliation ID ties the lifecycle to all instances of the CI across datasets. This is the way things should work in the system and it is one of the big improvements of moving the Asset data out of the CMDB.
However, it is also tied by instance ID. When an instance is created by loading to the AST join, records are created in the CMDB and in AST:Attributes. OK so far. Now, there is no reconciliation ID at this point. So, how can the records be tied together? By the Instance ID. The Instance ID on the AST:Attributes form is the instance ID of the record that caused the AST:Attributes record to be created. When that instance gets reconciled (identity reconciled), the reconciliation ID is updated on that record – found using the Instance ID. So, you can see that it is critical that they match. Otherwise, you could not find the record to update it with the reconciliation ID. Now, the fact that the AST:* joins are joined on the reconciliation ID is good, but not really sufficient. Why? Because all is fine as long as a reconciliation ID is present, but what about before the reconciliation operation? Well, the CI instance that created it and the AST:Attribute record are joined by the instance ID. So, the AST:* join criteria really should be that the reconciliation ID match OR the instance ID match. This gives you everything you get today PLUS you get the CMDB and AST:Attributes records joined before the reconciliation identity job has been run. We are going to update this join criteria as the standard in the next release. (this fact of the link being by two different things was noted by Jarl in his message to the list) So, it is critical that the instance ID is put on the AST:Attributes record. It is the way the reconciliation ID gets set on the AST:Attributes record and it is going to be added to the join critieria to make the join work before reconciliation in the future. I hope this addresses your question, Doug Mueller From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Jean-Louis Halleux Sent: Tuesday, April 07, 2015 2:26 AM To: arslist@ARSLIST.ORG Subject: Re: Setting 'InstanceId' on AST:* submit? ** Hello Doug, To my knowledge, the AST:Attribute is not linked to the CMDB record with its InstanceID, but rather with its ReconciliationID (in Atrium 8.0 at least). This has the effect that one AST:Attribute is related to multiple CI records though different datasets. Of course, those multiple CI records do represent only one physical CI in reality as the records are reconciled. However, I feel a little awkward when I read " It is critical that the Instance ID in the AST:Attribute record match the instance ID”, because you have different instance IDs through different datasets, while only one AST:Attribute. So my question: “why is it critical” ? Thanks for your support. Jean-Louis Halleux supp...@arsmarts.com<mailto:supp...@arsmarts.com> On 01 Apr 2015, at 22:52, Mueller, Doug <doug_muel...@bmc.com<mailto:doug_muel...@bmc.com>> wrote: ** Andy, It is fine if you want to control the creation of an Instance ID on the CI side. It just needs to be a GUID. However, it is not OK to just generate a new GUID for the AST:Attribute record itself. It is critical that the Instance ID in the AST:Attribute record match the instance ID of a corresponding entry in the CMDB form. In your case, you are loading to the AST:* join form that joins the CMDB form and the AST:Attribute form. Workflow there pushes appropriate values to each of the two underlying forms along with the Instance ID field. Whether that field is generated by workflow or supplied by you, it shouldn’t matter (OK, I am hedging by saying shouldn’t vs. doesn’t but I believe the logic in the system doesn’t overwrite if you supply an instance ID – if it does, you just need to overlay the filter that sets the instance ID to check to make sure it isn’t already set). From other responses, it has the logic handled correctly. Just make sure you don’t try and create an Instance ID on the fly for the AST:Attribute form. It must be supplied one that matches the CMDB record it is tied to. Doug Mueller From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Andrew Hicox Sent: Wednesday, April 01, 2015 6:35 AM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Setting 'InstanceId' on AST:* submit? ** Hi everyone, I have a situatuon where some home grown workflow needs to create CI's. I'm doing this by pushing fields directly to the AST:* form corresponding to the Class we want to create the CI in, and up to that point it works flawlwssly. However, I need to pull the 'InstanceId' of the CI I just created back into the form where the workflow fired the push fields (so I can set up relationships, etc). Doing this reliably has become more of a headache than I'd imagined. There are almost no uniqueness restraints in cmdb (sort of a corollary to Igor's thread about unique indexes). So there's almost nothing I can search by other than 'InstanceId', that's guaranteed to get 1 or 0 results. so here's my question. What if I generate my own GUID and push it into 'InstanceId' on the AST:* form? Does anyone know of this will break something in asset or cmdb? On the surface, this seems like a legitimate thing to do, but just wondering if anyone has been down this road before? -Andy _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
