Troubleshooting

This sections describes some simple troubleshooting techniques for common problems you may encounter when using the adapter for eMatrix.

Event notification

This section describes four common problems that may arise during event notification. They are:

Checking for event generation

When you debug the event notification functionality, you will first want to check whether you are successfully generating any events. To do this:

  1. Perform an action that you know will invoke a trigger which calls WBIEventLogger.
  2. Next, perform a query to see if the event was generated; for example:
    temp query bus wbi_Event **;
    
  3. If no events are being generated, make sure you have installed a trigger that will invoke WBIEventLogger.
    You can check whether a trigger was installed by opening up the appropriate business object type or relationship definition in the eMatrix Business Modeler. See Appendix D, Sample scenario for an example of how to install an event notification trigger.
    Note:
    No events are generated when the user name of the user whose actions invoke the trigger matches the adapterUser constant specified in WBIEventLogger. The adapterUser constant specifies the user name that the adapter should be using to log in to the eMatrix system.


    The point of ignoring such events is to prevent situations where the adapter modifies an entity in the eMatrix system and thereby causes an event to be logged. We assume that the adapter is aware of its own activities and does not need to log them. Keep this in mind when testing.

  4. If you wish to test whether a trigger that executes WBIEventLogger is being invoked, set the following property in the matrix.ini file:

    MX_MQL_TRACE=TRUE
    

    When you perform an action which invokes the trigger you'll see a message similar to this:

    18:15:00.826 MQL t@2900 Session: mx3f20221364f87ac7
    18:15:00.826 MQL t@2900 Program: WBIEventLogger
    18:15:00.826 MQL t@2900 args: -method recordEvent ${OBJECTID} n=wbi_cpu 
    v=Update p=1
    18:15:08.417 MQL t@2900 End Program:MQL<3>
    

    This tells you that the trigger has executed WBIEventLogger with the arguments listed above.

Checking eMatrix event business object names

If you know that events are being generated, but you still get an error every time you poll the eMatrix application, take a closer look at the name of the event business object. The business object name should look something like this:

wbi_22032.41802.50936.705_1058897313350_1892833611

If you notice upper-case words, such as FROMOBJECT, appearing in business object names, you may have specified an invalid MARCO value as an argument to the trigger. To resolve this:

  1. Check all business object type definitions in the Business Modeler.
  2. Review the triggers they use to invoke WBIEventLogger and make sure any MARCO values you provide as arguments are correct.

Finding the event vault

If you receive the following error during event polling, it means the adapter cannot find the EventVault referenced in your connector properties. The error is:

System Error: #1600039: vault 'WBI_Events' does not exist

You may get this error for one of two reasons:

Run InstallEventTables to make sure your vault was created, and check the name of EventVault in the connector properties.

Checking business object hierarchies

When you create a business object hierarchy that will be used for event notification, make sure the hierarchy does not include any child business object definitions that represent an eMatrix business object type and whose parent also represents an eMatrix business object type.

If such an object exists, the adapter will fail when polling and log a message similar to this:
An error occurred while trying to validate your WBI business object instance hierarchy.

The reason for this is that business objects which represent eMatrix business objects cannot contain attributes that also represent eMatrix business objects but are null.

Request processing

This section describes two common problems that may arise during request processing. They are:

Processing strings in commands

The values of string-typed attributes of business objects representing eMatrix commands are not quoted when they are interpolated into the command template prior to command processing. Therefore, an unquoted attribute value containing white space will be interpreted as two words of an MQL command.

Values in business object hierarchies

When sending a request, you may have child business objects in the hierarchy representing eMatrix business objects that have parent objects also representing eMatrix business objects. Make sure that any child business object is not null. The adapter will throw an error if such a hierarchy is encountered.

General tips

Here are two general problems and their resolution.

Unsupported business objects

You may receive a message like this in your log or trace file:
Unable to find version "*.*.*" of business object definition "wbi_computer_bundle_to_computer"
To resolve it, you need to add the business object mentioned in the message to the list of supported business objects in Connector Configurator.

Incomplete business object relationships

When you use the ODA, you may wish to model two business object types and their connecting relationship. Be sure to select all three in a hierarchical fashion as displayed in Figure 9.

Figure 9. Selecting business object relationships


If you do not do this, the ODA will create an incomplete model of the types and their shared relationship.

Copyright IBM Corp. 1997, 2003