Hi AST:Attribute should be linked to CMDB with ReconciliationID or InstanceID.
Regards, Jarl 2015-04-07 11:25 GMT+02:00 Jean-Louis Halleux <[email protected]>: > ** > 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] > > > > On 01 Apr 2015, at 22:52, Mueller, Doug <[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] <[email protected]>] *On Behalf Of *Andrew > Hicox > *Sent:* Wednesday, April 01, 2015 6:35 AM > *To:* [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_ > > > _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"
