Archive for the ‘Atrium CMDB 2.x’ Category

Adding an Attribute to the CMDB via a CMDB Driver Script

Thursday, April 3rd, 2014

There are a number of ways to create an attribute in the CMDB. You could use the BMC Atrium Core Console, Remedy API, or the CMDBDriver.

The BMC Atrium Core Console offers a nice GUI interface, and is fairly slick when used via the mid-tier. I have noticed some issues using the mid-tier version vs the UserTool version. One issue that I’ve noticed is that sometimes custom fields do not show up when your viewing the classes. When viewed from the UserTool, everything is there. Another issue I have noticed is that the Menu Style field shows different results when compaired to what one see’s in the UserTool.

The Remedy API is a very powerfull feature, if used correctly, and you understand what your doing. I have built everything from forms, fields, active links, filters, and guides with the API and really, one takes for granted what the GUI does for you.

But the topic is the CMDBDriver tool. This is not a user friendly tool, but once you understand it, its great for automating alot of your work.

The one feature is the “execute” command. This allows you to execute a driver script that is basically a list of commands (like a macro) that you want the driver to execute. The following text is what is used to create a selection field, with 3 entries, on the BMC_Application class:

ca
BMC.CORE
BMC_Application
CUS_BusinessGroup
OS-0050368f00f39DRrUwYP1cqw21KL
6
900100102
2
2
3
Corporate Group
12100
Customer Group
12200
Enterprise Group
12300
F
1
8
4
CUS.CUSTOM
0

These lines would sit in a text file, and the driver would execute the contents. The first line is the “CA” command which stands for Create Attribute. The following lines would be the supplied input for the process of manually creating an attribute.

The power of this feature is that you could maintain a number of these commands in the text file, allowing you to create as many fields, on as many forms as you like. For example, when I build out a new server environment, I can execute just one file that will add every custom field we added to the CMDB, bringing it upto speed with our existing environments.

CMDBDriver - Start Up

CMDBDriver – Start Up

 The next step is to enter the “init” command. This initizlizes the session, closing off any other session that you may have been already logged into. This is the first step that you must do when first opening the application. The next step is to enter the “log” command. Here you are logging in with your UserID, Password, and Server Name. Finally, if you are using a port number to connect to your server, enter the “ssp” command. This allows you to enter your TCP port number.
Initialization and Login

Initialization and Login

The next step is to issue the “ex” command. This will prompt you for the command/driver file to load. Enter in the full path and filename. No need to enclose everything in quotes, as spaces dont matter.

Execute Command

Execute Command

This is the part of the process that gets cluttered, and leaving you wondering whats going on. As the CMDBdriver executes the script, prompts for data are appearing on the screen. Normally you would manually enter the values, but our command file is supplying the data for us. I would have been nice if the values were actually displayed as the system exectued the file. Depending on how many attributes, which class your hitting, and the amount of data in your CMDB, this could take a few seconds or minutes to complete.

If you have multiple attributes being created, this screen will repeat the the cluttered block for each one. Once done, you should finally see the Command prompt come back.

Execution of the command file

Execution of the command file

Over the years, dealing with problem tickets with BMC Support and talking with the application engineers, they all have said that they use the CMDBDriver for most of the work that they do. When you use the Atrium Core/Class Manager to add attributes, the CMDBDriver is actually being called in the background to do the work. It pulls its information from the OBJSTR:Class form (these are your Pending records). Once the driver completes the task, the record in the OBJSTR:Pending form is removed.

One nice thing about the CMDBDriver is that if something goes wrong, it tells your right away. If something goes wrong using the AtriumCore/ClassManager, you have to go in and start deleting records in various forms.

One last helpful hint if AtriumCore/ClassManager does not appear to be completing the building of your new field, you can grab the ‘Pending ID’ and from within the CMDBDriver, issue the “sync” command, which will prompt you for the Pending ID. This will force the attribute to complete for you, and the matching record in the OBJSTR:Pending form will disapear (As long as there are no errors in your system, but thats another issue to resolve). Note that the ‘Pending ID’ is not visible on the form, but you have to export the data, or manually type it out from the report option. On most of my sites, we have made this field visible (read only) so its easy to grab.

 

 

Troubleshooting Building Classes in CMDB 2.0

Tuesday, September 27th, 2011

The process flow of saving a class in the Class Manager of CMDB 2.0 is the following:

1. When you click on the Save button on a class from the Class Manager, the Active Link OBJSTR:ClassDef_SaveChanges_CallFilterApi does a push fields to create a new record in the OBJSTR:Pending form

2. The filter OBJSTR:Pend_InitiateApplicationCommand fires on creation of a record in the OBJSTR:Pending form, and does a run process:

  • Application-Command CMDB Sync-Meta-Data -o “$PendingID$

which is an internal process, which puts a record in the Application Pending form and sends a signal to 390308

3. The dispatcher receives that signal, and since arcmdbd process registers with the dispatcher for entries where category = CMDB, the dispatcher signals the arcmdbd process that it has work to do. (the same basic mechanism applies to all the application server processes – including Approval Server, Assignment Engine, and Brie)

4. The arcmdbd process receives the signal, deletes the record from the Application Pending form, and makes the CMDBSyncMetaData API call

5. The creation of the forms/workflow, and updates to metadata to be Active, occurs inside the CMDB API. This logic occurs in the server side files – cmdbsvr20.dll / libcmddbsvr20.so / libcmdbsvr20.sl and cmdb20api.dll / libcmdb20api.so / libcmdb20api.sl. Upon completion of the API, the CMDB API updates the status of the entry in OBJSTR:Pending form to “Complete”

6. The filter OBJSTR:Pend_DeleteCompletedEntry is trigged by the status change, and sets ‘deleted’ field to True.

7. This triggers the filter OBJSTR:DeleteEntry to delete the record from the OBJSTR:Pending form

Note: The mechanism described above is specific to saving the class from the Class Manager – it is designed to give visibility in the client, for a process that fundamentally all happens on the server. If you make changes via cmdbdriver, no record is created in OBJSTR:Pending or Application Pending, and the dispatcher and arcmdbd process are not used.

 

Troubleshooting problems where the class stays in “Pending” status:

1. Click on the Change Pending record in the Class Manager and click on the View Log button. If there was an error in synching the class, the status will say Error and give an error message. If the status is “Pending”, it either means the arcmdbd process never issued the CMDBSyncMetaData API call, or the process is still happening within the CMDB API.

2. Check if the arcmdbd server process is running, and if the dispatcher (arsvcdsp) server process are running on the server. If not, verify both are listed in the armontor.cfg/conf file. This server process is responsible for telling the CMDB to build the class.

3. Enable arcmdbd logging by adding CMDB-Debug: T and CMDB-Debug-Level: 5 to the ar.cfg/conf file and restart the AR Server. If no log file is generated, comment out the line from armonitor.cfg/conf file and run that line from the console to verify the arcmdbd is running properly.

4. Verify the shared libraries for CMDB 2.0 are specified in the ar.cfg/conf file, and if not, correct the issue and restart the AR Server:

  • Load-Shared-Library: cmdbsvr20.dll,or libcmdbsvr20.sl, or libcmdbsvr20.so
  • Load-Shared-Library-Path: <path to the above file>

5. Enable API logging in BMC Remedy Administrator. Below is an example of how the CMDB API calls appear in the ARAPI log:

<API > <TID: 0000000010> <RPC ID: 0000088636> <Queue: Admin > <Client-RPC: 390696 > <USER: Remedy Application Service > /* Sat Apr 01 2006 21:19:47.9234 */+SYNC CMDBSync — from Unidentified Client (protocol 12) at IP address 172.23.33.40

In CMDB 2.0, the CMDB API calls and their results are written to the ARServer API log. The AR API calls that implement the work are also listed afterward, so it is easy to correlate which AR API calls are issues to perform the work of the CMDB.

Duplicate CIs even when values of Serial Number, HostName, and Domain match, Oracle database.

Saturday, September 3rd, 2011

Solution:

The identification rules used in Topology Discovery 1.4 and Configuration Management Configuration Discovery Integration for CMDB 7.1.1 use qualifications such as the following:

(‘SerialNumber’ = $SerialNumber$ AND ‘HostName’ = $HostName$ AND’Domain’ = $Domain$)

AND ( ‘SerialNumber’ != $\NULL$ AND ‘HostName’ != $\NULL$ AND ‘Domain’ != $\NULL$)

AND ( ‘SerialNumber’ != “” AND’HostName’ != “” AND’Domain’ != “”)

where the three meta-clauses are:

<attributes match>

AND <attributes are not NULL>

AND <attributes are not empty string>

On a SQL Server database, the third clause is required since NULL and empty-string are two different values at the database, and the qualification needs to check for both values to ensure the attribute value is suitable for using for identification. So the qualifications are correct if the AR Server is using any database other than Oracle.

On an Oracle database, the empty string is the same as NULL. This means the second meta-clause above is sufficient to check for both conditions. It also means the third meta-clause will always return a FALSE result, since

!= NULL

will always return a result of FALSE. (It is improper syntax for checking for NULL)

Workaround:

If the database used by ARSystem/CMDB is Oracle, the workaround is to update the Identification rules to remove the clauses which check for Empty String. For example, in the qualication above, it would remove the third meta-clause:
AND ( ‘SerialNumber’ != “” AND ‘HostName’ != “” AND ‘Domain’ != “”)

————————

Though this problem with Reconciliation can occur with other Reconciliation Jobs, the two Jobs where it has been identified are:

Configuration Discovery Reconciliation Process

BMC Topology Import – Identification, Merge, and Purge

Defects have been submitted to correct these issues in a future version of Topology Discovery and Configuration Management Configuration Discovery Integration for CMDB products:

SW00277889 Defect against CDI

QM001535938 Defect against Topology Discovery

Defect SW00294045 has been logged against AR System, indicating it should provide a way to search for (NULL OR Emptry String) in a way that will work for all databases.