This chapter describes how to fix common Oracle Communications Billing and Revenue Management (BRM) LDAP environment problems.
Periodically check for and correct event errors:
Run pin_channel_report to print a list of objects whose changes could not be exported.
Check the dm_ldap.pinlog 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. This returns an empty list if all the errors have been cleared.
After the errors are cleared, push the changes to the directory server by using 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.
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
by typing:
r file_name buffer_number
Search for the list entries by typing:
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
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. 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 the 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 Connection Manager pin.conf file. |
|
3 |
PIN_STATUS_ERROR |
Requires user intervention to fix. These errors usually occur during configuration and are less likely to occur 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. |
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 common object class violations are:
Mismatches between the Mapping File and Directory Server Entries
Object Classes or Attributes are Missing in the Directory Server
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.
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.
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 these 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 attributes names match (check for case).
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.
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".
Problem: An attribute used in the mapping file was not defined in the directory server, nor was it added to the object class in the directory server. For example, userPassword was never defined in the directory server, but it was used in the mapping file. Any attempt to add or modify this attribute to the directory server entry will fail.
Note:
This error is reported as "Undefined Attribute Type" in some directory servers.Solution: Verify that an attribute with this name exists in the directory server. If it does not, create it, and add it to the object class. Make sure that the case matches, too.
Problem: The object class is created without all the required attributes for the class. A common problem is that all attributes of the class are marked as required and only a subset is supplied during object creation.
LDAP Data Manager verifies that all the attributes marked as required in the mapping file are supplied during object creation. However, if an attribute is marked as optional in the directory server and required in the mapping file it is your responsibility to make sure that the object class definition in the directory server and mapping file are in sync.
Solution: Verify that only required attributes are marked as required for the class and the object class definition in the directory server and mapping file are in sync.
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=portal, and the directory server had a tree rooted at o=portal.com. Verify that the tree with the correct root exits 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=portal.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 be limiting the entries returned. For example, LDAP_SCOPE_ONELEVEL (1) limits the scope of the search to one level from the starting point of the search. Whereas, LDAP_SCOPE_SUBTREE (2) will search the entire sub tree. 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 o." |
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=portal.com and the complete DN specified uid=user1, o=portal. Verify that the location suffix o=portal and the value specified for location o=portal.com match. |