Hello Doug, Thanks for your explanation. Am I right to say that the instance ID of the AST:Attributes form should be the instance ID of the record in the BMC.ASSET dataset, and not the one of the record that creates the AST:Attribute if created from another dataset ? I guess that in case of a delete in the source dataset, but not in the BMC.ASSET dataset, the link on InstanceID between AST:Attribute and CI will be broken.
Best regards, Jean-Louis Halleux [email protected] > On 08 Apr 2015, at 08:28, Mueller, Doug <[email protected]> wrote: > > ** > 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:[email protected] <mailto:[email protected]>] On Behalf Of > Jean-Louis Halleux > Sent: Tuesday, April 07, 2015 2:26 AM > To: [email protected] <mailto:[email protected]> > 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 > [email protected] <mailto:[email protected]> > > > > On 01 Apr 2015, at 22:52, Mueller, Doug <[email protected] > <mailto:[email protected]>> 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:[email protected] <mailto:[email protected]>] On Behalf Of Andrew > Hicox > Sent: Wednesday, April 01, 2015 6:35 AM > To: [email protected] <mailto:[email protected]> > 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_ > > <image001.jpg>_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"
