Bob, I'll not try to give the best technical guidance, but let me help Stephen and all Members so that the interaction is even more productive.
Can you pls share the more global (end to end) Use Case?
For what purpose do you want to push this CI name into a custom form?
Why asking this? there may be creative ways to achieve your goal
1 of 1 people found this helpful
Thanks Matt Laurenceau (long time no see),
The end to end use case can be quite complicated so i will try to reduce it down to something that can be conveyed on this discussion.
We maintain attribute information in a custom form about a Device at the Device Name level. Some of that information is the Service Line responsible and more importantly the Security Plan this device is under.
In a network environment the router/switch is discovered and provides device name and serial etc. This in turn will generate a CMDB record with a unique Instance ID and Recon ID. When a router/switch is replaced, it retains the device name but has a new serial number, therefore it generates a new Instance ID and Recon ID. Sometimes other factors cause Discovery to just identify the same piece of equipment as being different enough to generate a new Instance ID and Recon ID.
By keeping the data in a custom form by device name, that swap of equipment will not cause any change or loss of data about that router/switch.
The serial number and the instance ID have nothing to do with what security plan a device is under, but the device name does.
We run a continuous recon job.
My preference would be to create a custom SYSACTION type form to process newly created Computer System CI records through. So at creation I want to use workflow to push the device name (at a minimum) to the custom SYSACTION form to be processed from there into the custom Device Name Attributes form. This way i can keep a near real time escalation on the custom SYSACTION form to process the data.
This way is preferable to an escalation on the Computer System CI record because that scenario would have to grab things created since x amount of time ago. There are times that escalation jobs get stopped (easy example is during an upgrade). The escalation scenario would require to over grab data (i.e. reprocess records already processed) to cover possible escalation down time.
The custom SYSACTION way would be to just process data left in the queue.
I have need of this functionality on the IP Endpoint CI as well. So i need a solution that works on any CMDB class during this recon creation.
So I am looking to identify what ARS trigger (if any) is fired when recon creates a new entry in a CMDB class. Is it MERGE, SUBMIT? And if it does have an ARS trigger, what form in the CMDB structure would it be on? base_element, bmc_computersystem, AST:Computer System (that would be awesome but i figure unlikely since that is an asset form)?
I'm willing to take this offline if necessary.
Sr. Remedy Software Engineer IV
3 of 3 people found this helpful
BaseElement will work to capture all classes and the operation is CREATE
My gut response was creating a new record in any dataset would be a CREATE operation and merging into an existing CI already in the dataset would be SET operation, since it is all done via the api. But I really didn't want to assume. I have been working on an AI import job and an associated Recon job, so I was already kind of in this zone to test it out.
I created a filter that fires on Submit, Modify, Merge, and that did two things (a little behavior testing within my test). At first I had just one action to log to a file (as a kind of off-the-wall test I wanted to see if I could get different files based on using $OPERATION$ in the file name, it didn't work that way).
The log file that was created includes the timestamp, username, and then the operation before the form name and then finally the record data.
But then to further test and to be sure, I added a set fields before the log action that concatenates a delimiter string (<|>) and the $OPERATION$ keyword. Below is a screenshot of my final test filter actions.
Using the the Room field, in the record below you can see the CREATE from the AI import process and then another CREATE when I reconciled the imported asset into the next (destination) dataset.
I don't have a screenshot but I did one more test where I manually changed some fields of a CI in the source dataset and then ran the Recon job again to merge the updated CI into the destination dataset. The operation was a SET when the CI already exists in the destination dataset.
One thing to consider is possible performance impact. You will now be inserting an additional record into the DB every time a CI is created. This could slow down your Recon job. I am figuring the volume of new CIs isn't that great since it sounds like you already have most of the CIs in the CMDB but I figured I would mention it.
EDIT: The images ended up being a link to my email box. Replaced them with images everybody will be able to see.
2 of 2 people found this helpful
Jason Miller this pointed me to the right direction and i have now been able to work out my proof of concept.
The create event happens on the BMC.CORE:BMC_ComputerSystem form. Yes it does technically happen on the BMC.CORE:BMC_BaseElement form as well, but I determined it happens direct on the ComputerSystem form and I think this is a cleaner place to put the filter.
The other create event i was looking for happens on the BMC.CORE:BMC_ProtocolEndpoint form. This allows me to find new IPEndpoint records. Surprisingly the create does not happen on the BMC.CORE:BMC_IPEndpoint form. That form contains some additional attributes for the SystemName that apparently are updated after the ProtocolEndpoint record is created.
You are correct that we have quite a number of computer system ci's and a tremendous number of ip address ci's.
That is why running a job to process all of the ci's daily is overwhelming, something our current custom solution is doing.
I am redoing an existing custom system and rethinking the best way to process the data.
So by writing a SYS;Action record each time a new computer system is created it may take a small hit during recon but now i can have a near continuous job run to process that small set of data and i believe this to be more efficient than running a big nightly job.
I am also writing a SYS:Action record each time a computer system record is modified and the MarkAsDeleted = "Yes" so i can process delete events.
We don't want to delete the custom record, but i need to flag when all cmdb records of that name have been deleted (i.e. removed from the network). We have noticed that just because it is no longer being found in Discovery doesn't mean it is not really on the network. By flagging this in the custom record, someone can review what needs to be done (flag the custom record as obsolete, or flag the property record as "Spare", or go figure out why Discovery isn't getting to the device anymore).
As for the IP records, i am looking for two things when I process those. 1) is this the only IP for a device, if so this is the primary ip and should be marked on the custom record as such 2) is this an IP for and IP Phone (custom TPL to pull that data from the VOIP controllers since Discovery doesn't do that yet), if so modify the custom record to set this as the primary ip. VOIP Phones are on DHCP so the IP changes often. And since it is custom TPL we haven't been able to easily remove the no longer used IP address so these don't show up as being the only IP for the IP Phone.
Thanks for the assist
Sr. Remedy Software Engineer IV
I definitely agree, if you only have to keep an eye on two classes, that limiting the filter to those classes is a better approach vs. on BaseElement.