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 > On 01 Apr 2015, at 22:52, Mueller, Doug <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 > 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_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
