Hello there fellow AtriumCore enthusiasts.
I got inspired to blog about something I've been working on with customers who synch their ADDM data to CMDB.
As a side note, ADDM is now called BMC Discovery, but I'll use ADDM for now since most people are still referring to it as ADDM. On the CMDB side we are still using dataset Id "BMC.ADDM" and "ADDMIntegrationId". I am not sure if this will change. I hope not, because it would impact previously reconciled data. Provenance (the source) is referenced in AttributeDataSourceList field and changing the DatasetId would impact Precedence rules.
Getting the discovered data across is one thing. Understanding what happens to it on the other side as another. I've sort of expected that ADDM administration skill set also includes AR Server configuration knowledge, but now I know that AR Server and ADDM administration is usually done by two mutually exclusive teams. This blog is likely going to help each side communicate their expectations to the "other" side.
For the ADDM Admin:
You already know that the Remedy AR System hostname and port is the destination for your data. You may also know that there is a Remote Procedure Call (*RPC) queue to which ADDM defaults to but is not restricted to. I'll get to the queue details later, but what is important to know next is that AR Server is running in a server group. I was trying to think of a good way to visualize this and one thing that came to mind is the three headed dog known as Cerberus. I could have also used the multi-headed Hydra as an example, but Cerberus seems more appropriate for what I want to say.
So, the dog Cerberus has three heads and it guards the underworld. If you have a dog then you already know that that dog gets pretty preoccupied when eating with just that one head. Imagine having a dog with three heads. You basically would have a dog that listens for squirrels, smokes a cigarette and has dinner all at the same time. Each head gets to decide what to do while the food goes into just one stomach. That's kind off what the AR Server does. Information is digested and deposited in one data store. Usually three or more AR Servers are interfaced with the AR Midtier and at least one of them is dedicated to processing CMDB data in bulk. Reconciliation, Normalization, and AR Escalations.
These AR System hosted features also use *RPC queues that allow for seamless data exchange between these external API's.
It keeps a dedicated queue opened for them. ADDM synchs its data to CMDB via AR Server using one of these RPC queues.
However, what you need to know is that the CMDB API used by ADDM defaults to queue number “390696”. This queue is actually the CMDB dispatcher queue and using it can sometimes cause contention with other CMDB activities.
This is likely the communication that you will have with the guys that administer AR Server. Unfortunately that CMDB RPC queue can not be changed, but BMC R&D is looking into adding more CMDB queues and perhaps even BMC Discovery (ADDM) dedicated queue. Don't quote me on that. It's a rumor. It can be set differently on the ADDM side. This is probably something that you will have to talk about with the AR Server administrators. Tell them that you want a different queue assigned. By doing so you can add more *RPC queue threads. For example 390699.
This is easily said than done because there are only two CMDB queues available. Queue 390698 and 390699.
The first one is usually used by Reconciliation engine and the other is for Normalization. BMC Discovery will do best if it has its own queue dedicated to it. But that might be difficult if that same server is used for Normalization and Reconciliation.
In this case it would be easier to add another head (AR Server) to the server group and dedicate it exclusively to specific data processing activities. In AR Server version 9.1 you can dedicate another AR Server to run normalization by setting its rank in Failover ranking form. Not the server group ranking. You may still need to install that additional instance if that AR Server provides service to Asset Operators via midtier. This would the best way to ensure best performance for ADDM to CMDB integration.
Cerberus and Hades
There is one more thing. AR Escalations. These are features that trigger when data is created or modified. You want to ask the Remedy admin to not have escalations enabled on the same server that gets the ADDM data.
For the Remedy guys:
All you really need to know is that ADDM uses Java API that send sends the data and it can toggle whether that data is sent as a "pre" or "post" 7603 data model.
Anything after CMDB version 7603 should be sent as 7603 with Impact as an attribute. This means that the CMDB will receive "Impact" relationship designation in an attribute rather the old and deprecated BMC_Impact class. It relieves the need to run the Deprecation plugin that convers the class to an attribute.