7 Troubleshooting Your BRM LDAP Environment
Learn how to fix common problems in your Oracle Communications Billing and Revenue Management (BRM) LDAP environment.
Topics in this document:
Checking for Event Errors and Recovering from Failure
Periodically check for and correct event errors by doing the following:
-
Run pin_channel_report to print a list of objects whose changes could not be exported.
-
Check the dm_ldap.pinlog file for errors that prevent events from being pushed.
-
Correct each of the errors in the dm_ldap.pin.log file.
Note:
Errors are unique to specific configurations.
-
After the errors are corrected, clear them by running:
pin_channel_clear_error type poid
where:
-
type is one of the following values:
-a: Clears the status of all the channel_event objects with errors.
-i: Clears the status of a particular channel_event object.
-
poid is the particular channel_event object containing an error.
-
-
To verify that the errors are cleared, run pin_channel_report. The utility returns an empty list if all errors have been cleared.
-
After the errors are cleared, push the changes to the directory server by running pin_channel_export.
If the pin_channel_report utility does not return any errors and the changes are still not exported, the problem must be elsewhere. Run testnap to find the problem.
Verifying Event Creation by Running testnap
You can verify that channel event objects were created by running the testnap utility:
-
Create and name a test file. For example, stest.
-
Enter the following flist into the test file:
r stest 1 nap(13860)> d 1 # number of field entries allocated 20, used 6 0 PIN_FLD_POID POID [0] 0.0.0.1 /search/pin 0 0 0 PIN_FLD_FLAGS INT [0] 256 0 PIN_FLD_TEMPLATE STR [0] "select X from /channel_event where F1 = V1 or F2 = V2 " 0 PIN_FLD_ARGS ARRAY [1] allocated 20, used 1 1 PIN_FLD_STATUS ENUM [0] 0 0 PIN_FLD_ARGS ARRAY [2] allocated 20, used 1 1 PIN_FLD_STATUS ENUM [0] 4 0 PIN_FLD_RESULTS ARRAY [0] allocated 20, used 5 1 PIN_FLD_POID POID [0] NULL poid pointer 1 PIN_FLD_OBJECT POID [0] NULL poid pointer 1 PIN_FLD_CHANNEL_OBJ POID [0] NULL poid pointer 1 PIN_FLD_SUPPLIER_OBJ POID [0] NULL poid pointer 1 PIN_FLD_STATUS ENUM [0] 0
-
Run testnap and read the test file into a buffer:
testnap r file_name buffer_number
-
Search for the list entries:
search buffer_number
A list is returned, similar to this sample:
# number of field entries allocated 5, used 5 0 PIN_FLD_POID POID [0] 0.0.0.1 /search/pin 0 0 0 PIN_FLD_RESULTS ARRAY [0] allocated 4, used 4 1 PIN_FLD_POID POID [0] 0.0.0.1 /channel_event 8645 0 1 PIN_FLD_CHANNEL_OBJ POID [0] 0.0.0.1 /channel 100 0 1 PIN_FLD_SUPPLIER_OBJ POID [0] 0.0.0.1 /account -1 0 1 PIN_FLD_STATUS ENUM [0] 0 0 PIN_FLD_RESULTS ARRAY [1] allocated 4, used 4 1 PIN_FLD_POID POID [0] 0.0.0.1 /channel_event 9669 0 1 PIN_FLD_CHANNEL_OBJ POID [0] 0.0.0.1 /channel 102 0 1 PIN_FLD_SUPPLIER_OBJ POID [0] 0.0.0.1 /service -1 0 1 PIN_FLD_STATUS ENUM [0] 0 0 PIN_FLD_RESULTS ARRAY [2] allocated 4, used 4 1 PIN_FLD_POID POID [0] 0.0.0.1 /channel_event 10693 0 1 PIN_FLD_CHANNEL_OBJ POID [0] 0.0.0.1 /channel 102 0 1 PIN_FLD_SUPPLIER_OBJ POID [0] 0.0.0.1 /service -1 0 1 PIN_FLD_STATUS ENUM [0] 0 0 PIN_FLD_RESULTS ARRAY [3] allocated 4, used 4 1 PIN_FLD_POID POID [0] 0.0.0.1 /channel_event 11717 0 1 PIN_FLD_CHANNEL_OBJ POID [0] 0.0.0.1 /channel 102 0 1 PIN_FLD_SUPPLIER_OBJ POID [0] 0.0.0.1 /service -1 0 1 PIN_FLD_STATUS ENUM [0] 0
About Status Values for Channel Events
The pin_channel_export utility initiates synchronization every 60 seconds by default. All /channel_events ready to be pushed (those with a status of 0 or 4) are exported to the Connection Manager (CM). The pin_channel_export utility calls PCM_OP_REPL_POL_PUSH to export the data.
Table 7-1 shows the status values that appear in channel_event_table.
Table 7-1 Status Entries in channel_event_table
| Numeric Value | Value | Description |
|---|---|---|
|
0 |
PIN_STATUS_NOT_PUSHED |
Needs to be pushed. |
|
2 |
PIN_STATUS_PUSHED |
Channel event has been pushed. By default, pushed /channel_events are deleted from the channel event table. To save a record of a pushed /channel_event, set delete_channel_events to 0 in the CM pin.conf file. |
|
3 |
PIN_STATUS_ERROR |
Requires user intervention to fix. These errors usually occur during configuration and are less likely to happen in a stable, operating environment. |
|
4 |
PIN_STATUS_LINK_ERROR |
The directory service is down. Does not require user intervention, since errors are resolved automatically. |
Verifying the Mapping Between Object Classes and Entries
You can avoid object class violation problems in the BRM LDAP environment by making sure that BRM object class type definitions map to directory server schema entries correctly.
The following sections describe three common object class violations and provide guidance on how to resolve them.
Mismatches Between the Mapping File and Directory Server Entries
There are two common mismatches between the mapping file and directory server entries:
-
The object class type definition in the mapping file does not match the corresponding directory server name.
-
The attribute name in the mapping file does not match the corresponding directory server attribute name.
Entry Class Type Definition Contains a Typo
Problem
The name in the mapping file (BRM_home/sys/ldap.idl) does not match the name of the entry in the directory server. For example, the directory server entry is named ruesr (a typo) while the mapping file has an object type of ruser.
Solution
Verify that the object class name matches the entry type name.
Case or Spelling Mismatches in Attribute Names
Problem
There is a mismatch between the attribute name in the directory server and the name supplied in the mapping file. Sometimes, the mismatch is due to a difference in case or spelling. The most common errors are with the attributes shown in Table 7-2.
Table 7-2 Common Errors with Attribute
| Attribute Name in the Directory Server | Attribute Name in the Mapping File |
|---|---|
|
userpassword |
userPassword |
|
maxmsgcount |
maxmsgcnt |
Solution
Verify that the attribute names match (check for case).
Object Classes or Attributes are Missing in the Directory Server
BRM cannot create directory server schema elements. Therefore, you must manually define the BRM data elements that you are interested in capturing with your own directory server tools. If you do not define these object classes and attributes in the directory server, you will encounter BRM object class errors. For example, to capture BRM account object data, you must create a directory entry called r_user with an attribute called pin-poid-id, which is relevant only to BRM.
Object Class Attributes Undefined in the Directory Server
Problem
None of the attributes belonging to the object class were created in the directory server, added to the object class, or both. For example, the /r_user object class must be modeled correctly. That is, it must contain all of the required BRM attributes to push data to the directory server.
Solution
Verify that the attributes were created and added to the object class.
For more information on the /r_user directory server attributes, see "Determining the /r_user Object Class Attributes".
Attribute Used in Mapping File is Undefined in the Directory Server
Problem
An attribute specified in the mapping file is not defined in the directory server and has not been added to the corresponding object class. For example, if the attribute userPassword is referenced in the mapping file but was never defined in the directory server, any attempts to add or modify this attribute fail. This type of error may be reported as "Undefined Attribute Type" by some directory servers.
Solution
Verify that an attribute with this name exists in the directory server. If it does not exist, create it and add it to the object class. Additionally, double-check that the spelling and case of the attribute match exactly.
Directory Server Object Class Created Without Required Attributes
Problem
The object class is created without including all the required attributes. A common issue arises when all attributes of the class are designated as required, but only a subset is provided during object creation.
LDAP Data Manager verifies that all attributes marked as required in the mapping file are included when creating an object. However, suppose an attribute is marked as optional in the directory server but is needed in the mapping file. In that case, it is your responsibility to ensure that the definitions of the object class in the directory server and the mapping file are aligned.
Solution
Verify that only the attributes that are genuinely required are marked as such for the class. Additionally, ensure that the object class definitions in both the directory server and the mapping file are consistent with each other.
No Such Object Errors
Table 7-3 shows the most common no such object errors.
Table 7-3 No Such Object Errors
| Problem | Solution |
|---|---|
|
You get a "no such object error". |
The location specified in the mapping file does not exist in the directory server. For example, the location in the mapping file was o=example, and the directory server had a tree rooted at o=example.com. Verify that the tree with the correct root exists in the directory. You should also check for typos. |
|
The ou specified in the PIN_FLD_DN or in the Location in the mapping file does not exist. For example, if the PIN_FLD_DN has uid=user1, ou=ipservices, o=example.com, but the directory server has ou=serviceip, any attempt to create or modify the entry will return this error. |
Some directory servers return a constraint violation if this error is present along with a duplicate RDN_PIECE. For example, if you have the same DN and user1 already exists in the directory server, you receive a constraint violation. After you fix that problem, you will see the "No such object error". Verify that the ou specified exists in the directory server. You should also check for typos. |
|
Already exists. |
The value of the RDN_PIECE already exists in the DS. Check for duplicates. |
|
Not all attributes in the DS entry are returned when an entry is read or searched from the DS. |
The mapping file (ldap.idl) does not specify a mapping for all attributes in the directory server entry. Specify a mapping for all the fields that you are interested in reading from the entry. |
|
Not all DS entries are returned when the DS is searched using a search filter. |
The scope of the search might limit the entries returned. For example, LDAP_SCOPE_ONELEVEL (1) limits the search scope to one level from the starting point. At the same time, LDAP_SCOPE_SUBTREE (2) searches the entire subtree. Specify the correct scope depending on what you are looking for. |
|
When a complete DN is specified, you get the error "Given DN cannot reside in location Ö." |
The DN's location suffix does not match the value specified in the BRM_home/sys/ldap.idl file. For example, if ldap.idl specified a location o=example.com and the complete DN specified uid=user1, o=example. Verify that the location suffix o=example and the value specified for location o=example.com match. |