Troubleshooting Building Classes in CMDB 2.0

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.

Comments are closed.