This documentation supports the 20.02 version of Remedy Action Request (AR) System.

To view an earlier version, select the version from the Product version menu.


Improving ARDBC LDAP runtime performance

You can improve your ARDBC LDAP runtime performance by using time-based queries and caching.

Using time-based queries

Time-based queries reduce the time it takes to search your directory service.

BMC Remedy AR System retrieves modifyTimestamp and whenChanged attributes from the directory service. When creating a vendor form, add one of these fields to store a time stamp. In the Advanced Search Bar, enter a query for records that meet your time-stamp criteria. For example, use modifyTimeStamp >= "8/9/2007 4:00:00 PM" to consider only records modified after 4:00 PM on 8/9/07.

This query is evaluated by the plug-in, which uses it to query the directory server so that it returns only records modified after a specified time.

Using caching

The ARDBC LDAP plug-in uses client-side caching. Before a search request is sent to the directory server, BMC Remedy AR System checks the cache to determine whether the same request was made before. If an earlier request was cached, the search results are retrieved from the cache to avoid running a new search on the server.

Use the ARDBC LDAP Configuration form to enable caching and to control caching by specifying the maximum size of the cache and the maximum amount of time to keep an item in the cache.

Troubleshooting the ARDBC LDAP vendor form

If you have problems with your ARDBC LDAP vendor form, consider these tips:

  • Any field (except display-only fields) on the vendor form must reference an LDAP attribute that exists in the specified context. For example, if you use MS Active Directories, the uid attribute does not exist by default and should not be referenced in your vendor form. If you specify invalid attributes, you might receive unexpected results on your searches.
  • If data is not being returned correctly, create a vendor form with only a Request ID and one other field (referring to valid LDAP attributes). Test a search. If it works, continue adding fields until you identify the one that does not work.
    • If any values are NULL, you receive ARERR (100) Entry ID list is empty, and no records are displayed in the client.
    • If more than one record has the same value, you retrieve data only for the first matching entry.
    • For most LDAP servers, dn is the attribute of choice for the Request ID. For MS Active Directories, sAMAccountName is usually a good choice.
  • For optimal performance, set the Directory Page Size field to 1000.
  • If you configure the Base DN For Discovery field, the plug-in searches from this Base DN rather than from the root DN. This offers better performance.
Was this page helpful? Yes No Submitting... Thank you

Comments