This chapter provides an overview of the feature enhancements introduced in Oracle Communications Offline Mediation Controller 6.0 Patch Set 1 through Offline Mediation Controller 6.0 Patch Set 3.
Note:
Offline Mediation Controller 6.0 patch sets are cumulative. Offline Mediation Controller 6.0 Patch Set 3 includes all the changes introduced in Offline Mediation Controller 6.0 Patch Set 1 through Offline Mediation Controller 6.0 Patch Set 3.Offline Mediation Controller 6.0 Patch Set 3 includes enhancements to the following components:
This section describes the enhancements to Administration Client.
In the previous releases, when you edited a node programming language (NPL) rule file in Offline Mediation Controller NPL Editor, there was no option to compile and validate the NPL rule file in NPL Editor. The NPL rule file was compiled when you saved the node. If the compilation failed, the node could not be saved.
With this patch, you can now compile and validate the NPL rule file in NPL Editor and make changes in the NPL rule file in case of any validation errors.
To compile the NPL rule file in NPL Editor:
Log on to Offline Mediation Controller Administration Client.
The Node Hosts & Nodes (logical view) screen appears.
In the Mediation Hosts table, select a host.
In the Nodes on Mediation Host section, select a node and click Edit.
The Node dialog box appears.
From the Rule File list, select an NPL rule file and click Edit.
The NPL Editor dialog box appears.
If you have any changes, modify the rule file.
From the Actions menu, select Compile.
The NPL rule file is compiled and the result is displayed in the Compilation result section. If the compilation fails, update the rule file and recompile.
Save the file and close the NPL Editor dialog box.
With this patch, you can now search for the NPL functions in the NPL functions table and filter the NPL functions to view the required function.
To search for NPL functions in NPL Editor:
Log on to Offline Mediation Controller Administration Client.
The Node Hosts & Nodes (logical view) screen appears.
In the Mediation Hosts table, select a host.
In the Nodes on Mediation Host section, select a node and click Edit.
The Node dialog box appears.
From the Rule File list, select an NPL rule file and click Edit.
The NPL Editor dialog box appears.
From the Lookup menu, select Builtin Functions.
The NPL Functions table dialog box appears.
In the search field, enter a function name.
As you enter text, the list of functions is displayed.
Note:
Do not enter the CTRL keys, function keys, and the arrow keys in the search field.If you enter a space character in the search field, it is considered as a NULL character and the trailing space characters entered at the end of the search string are truncated.
Close the NPL Functions table dialog box.
Save the file and close the NPL Editor dialog box.
With this patch, you can now enter the Internet Protocol address or the host name of the computer on which the application is installed, localhost, or 127.0.0.1 when configuring the host in the following locations:
The Map dialog box when mapping Node Manager during import customization and import configuration in Administration Client
The addhost, import, and export commands in NMShell
You can now configure the maximum and minimum memory sizes the Java Virtual Machine (JVM) uses when running Administration Client. By configuring the maximum memory size, you can reduce the amount of memory JVM uses when running Administration Client.
To set the maximum and minimum memory sizes:
Open the OMC_Home/bin/gui file in a text editor, where OMC_Home is the directory in which Administration Client is installed.
Add or modify the following entries:
InitializeExternalConfig(){ NM_MIN_MEMORY=value NM_MAX_MEMORY=value }
where value is the appropriate value for the respective entry.
For example:
InitializeExternalConfig(){
NM_MIN_MEMORY=1024
NM_MAX_MEMORY=3500
}
Save and close the file.
This section describes the enhancements to Administration Server.
You can now configure the maximum and minimum memory sizes the JVM uses when running Administration Server. By configuring the maximum memory size, you can reduce the amount of memory JVM uses when running Administration Server.
To set the maximum and minimum memory sizes:
Open the OMC_Home/bin/adminsvr file in a text editor.
Add or modify the following entries:
InitializeExternalConfig(){ NM_MIN_MEMORY=value NM_MAX_MEMORY=value }
where value is the appropriate value for the respective entry.
For example:
InitializeExternalConfig(){
NM_MIN_MEMORY=1024
NM_MAX_MEMORY=3500
}
Save and close the file.
This section describes the enhancements to the cartridge packs.
With this release, you can now configure a duplicate check enhancement processor (EP) cartridge, which identifies duplicate records while processing the call detail records (CDRs).
For more information, see Offline Mediation Controller Enhanced Duplicate Check Cartridge User's Guide.
Offline Mediation Controller collects CDRs from different input sources and normalizes the CDRs by mapping the following external data to the internal data formats that are supported by Oracle Communication Billing and Revenue Management (BRM) before sending the enhanced records to the next node in the mediation node chain:
Social number
Prefix description
Service code
Usage class
Access point name (APN)
With this release, you can now configure a record enhancement charging EP cartridge node to enhance the CDRs for charging before sending the records to the next node in the mediation chain.
With this release, Offline Mediation Controller now supports collecting CDR input files conforming to the Oracle CDR format, which is the CDR file format used by BRM. You can now configure an Oracle CDR Format Collection Cartridge (CC) node to collect the CDR input files in the Oracle CDR format, parse the data in the Oracle CDR format into a NAR file using the configured schema, and send the records to the next cartridge node.
For information about Elastic Charging Engine (ECE) Distribution Cartridge (DC) mapping to support Oracle CDR format, see Offline Mediation Controller Elastic Charging Engine Cartridge Pack User Guide.
To configure the Oracle CDR format CC node:
Log on to Offline Mediation Controller Administration Client.
The Node Hosts & Nodes (logical view) screen appears.
In the Mediation Hosts table, select a host.
In the Nodes on Mediation Host section, click New.
The Create a Node dialog box appears.
Select Cartridge Kit and click Next.
Select Collection Cartridge (CC) and click Next.
Select Oracle CDR Format File Collection Cartridge and click Finish.
The New Node dialog box appears.
In the Name field, enter a name for the node.
From the Rule File list, select the rule file that matches the type of input file processed by the CC node.
To edit the rule file, see "Configuring the NPL Rule File for Oracle CDR Format".
Click the General tab and do the following:
From the Debug list, select one of the following:
To log short debug messages in the node log file, select OFF.
To log detailed debug messages in the node log file, select ON.
In the Max Log File Size field, enter the maximum size in bytes for the log file. When the log file reaches its limit, the node closes the file and opens a new file. The minimum value is 50000 and the maximum value is 2000000000.
Select the Enable Statistics check box, which enables node statistics.
Select the Enable bulk read/write check box, which enables the node to read or write files in bulk.
In the NARs Per File field, enter the maximum number of NARs allowed in an output file. The minimum value is 1 and the maximum value is 10000.
In the Idle Write Time field, enter the number of seconds Offline Mediation Controller waits before transferring the NAR output file to the output directory of the processing node, whether or not it has reached its maximum size. The minimum value is 1 and the maximum value is 3600.
Click the File Location tab and do one of the following:
To collect files using File Transport Protocol (FTP), select Files are pulled (via FTP), and do the following:
In the Local Directory field, enter the path and name of the directory where the CDR input files after collection are stored.
In the Prefix of Files after Collection field, enter the prefix to rename the CDR input file after collection.
In the Suffix of Files after Collection field, enter the suffix to rename the CDR input file after collection. The default is .done.
Select the Delete Files After Processing check box, which deletes the CDR files after processing.
To collect files from a directory, select Files are pushed to this node, and do the following:
In the Check for New Files Period field, enter the duration of time that the node waits before checking for new files in the input directory. You also select the time unit: Seconds, Minutes, or Hours.
In the Local Directory field, enter the path and name of the directory that contains the input files to process.
Configure a file pattern: To configure a file pattern for the input files, select Prefix and enter the prefix in the Prefix field and suffix in the Suffix field. The default for Suffix is .complete; to configure a regular expression file pattern, select Reg.Expr and enter a file name pattern. To test the regular expression, click Test.
In the Prefix of Files after Collection field, enter the prefix to rename the CDR input file after collection.
In the Suffix of Files after Collection field, enter the suffix to rename the CDR input file after collection. The default is .done.
Select the Delete Files After Processing check box, which deletes the CDR files after processing.
If you selected Files are pulled (via FTP), click the FTP Settings tab and do the following:
From the FTP Interval list, select the interval in minutes or hours the node waits before checking for incoming data.
From the Interrupt Timer Delay list, select the default timeout for the FTP client when opening a socket.
Select the Delete remote files check box, which deletes the CDR files from the remote location after the files are collected.
Select the Rename remote files check box, which renames the CDR files in the remote location after the files are collected.
Click Add.
The FTP Configuration dialog box appears.
From the FTP Type list, select one of the following:
If the client initiates the control connection with the server and the server initiates the data connection with the client, select Regular.
If both the data and the commands are transferred in specially formatted packets through a single connection, select Secure (SFTP). When using SFTP, all data sent between the client and the server is encrypted using an encryption cipher.
If the client initiates all connections with the server, select Passive. The server informs the client about the port to be used for the data connection.
In the Host field, enter the IP address of the FTP server.
In the Username field, enter a valid user name for accessing the FTP server.
In the Password field, enter the password for the user name.
In the Verify Password field, re-enter the password used in the Password field.
In the Directory field, enter the name of the remote directory that contains the input files to process.
Configure a file pattern: To configure a file pattern for the input files, select Prefix and enter the prefix in the Prefix field and suffix in the Suffix field; to configure a regular expression file pattern, select Reg.Expr and enter a file name pattern. To test the regular expression, click Test.
Click OK.
The FTP configuration is saved and the FTP Configuration dialog box closes.
Click the Advanced tab and do the following:
Select the File Level Transaction check box, which enables file-level transactions.
Select the Reject Files With Duplicate File Name check box, which enables validating the name of the input file for duplicate file names.
The Expiry Time to Reject Duplicate Files field is enabled.
In the Expiry Time to Reject Duplicate Files field, enter the time in minutes after which the file names are flushed from memory. The minimum value is 1, and the maximum value is 129600. The default is 1.
Do one of the following:
To enable validating the order of the sequence number in the input file, select the Sequence Ordering by File Name check box.
To enable multithreading to process multiple files in parallel, select the Multi Threaded check box and enter the number of processing threads you require for your thread pool in the Processing Threads field. The maximum value is 20. If you require the order of the output data across all threads to be processed in the same order as the input data, select the Enable Ordering check box.
Click the Schema File tab and do the following:
From the Schema file list, select the schema file that is used to parse the Oracle CDR format data files.
Click the Destination tab and do the following:
Select the Enable check box, which enables the connection between the CC node and any destination cartridge node.
From the Routing list, select one of the following:
If the Enable check box is not selected, select None.
To enable multicast routing between the CC node and the destination cartridge node, select Multicast.
To enable round-robin routing between the CC node and the destination cartridge node, select Round Robin.
Click Save.
The Oracle CDR Format CC node uses the schema information in a schema file to parse the CDR files conforming to the Oracle CDR format into NARs.
To configure a new Oracle CDR format schema for the Oracle CDR Format CC node:
Log on to Offline Mediation Controller Administration Client.
The Node Hosts & Nodes (logical view) screen appears.
In the Mediation Hosts table, select the mediation host that contains the Oracle CDR Format CC node.
Stop the Oracle CDR Format CC node.
Copy the new schema file into the OMC_Home/config/sol42/schema directory.
In the Offline Mediation Controller Administration Client Mediation Hosts table, select the mediation host that contains the Oracle CDR Format CC node.
In the Nodes on Mediation Host section, select the Oracle CDR Format CC node for which you want to change the schema file, and click Edit.
The Node dialog box appears.
In the Node Configuration section, click the Schema File tab.
From the Schema file list, select the new schema file, which contains the schema information used to parse the Oracle CDR format data files.
Click Save.
The configuration is saved.
Start the Oracle CDR Format CC node.
To configure the NPL rule file for Oracle CDR format:
Log on to Offline Mediation Controller Administration Client.
The Node Hosts & Nodes (logical view) screen appears.
In the Mediation Hosts table, select the mediation host that contains the Oracle CDR Format CC node.
In the Nodes on Mediation Host section, select the Oracle CDR format CC node that you want to configure, and click Edit.
The Node dialog box appears.
From the Rule File list, select one of the sample NPL rule files.
Click Edit for the selected rule file.
The NPL Editor dialog box appears.
In the configuration block, do the following:
Add the following entry, which defines the Oracle CDR format header record fields written to the NAR output file:
AddHeaderFields "headerFieldName1, headerFieldName2,...";
where headerFieldNameX is the name of the field in the Oracle CDR format header record.
If you want all the fields in the header record to be part of every NAR written by the Oracle CDR format CC node, specify ALL.
For example:
AddHeaderFields "RECORD_TYPE, RECORD_NUMBER";
Add the following entry, which defines the Oracle CDR format trailer record fields written to the NAR output file:
AddTrailerFields " trailerFieldName1, trailerFieldName2,...";
where trailerFieldNameX is the name of the field in the Oracle CDR format trailer record.
For example:
AddTrailerFields "RECORD_TYPE";
Add the following entry, which defines the order of the records:
RecordOrder "HEADER,DETAIL*,TRAILER";
For the DETAIL* record field, define the associated type of records and sub-records. For example:
RecordOrder "HEADER,DETAIL*,TRAILER"; DETAIL "ASSOCIATED_CHARGE*,ASSOCIATED_ZONE,ASSOCIATED_INFRANET*,ASSOCIATED_GPRS,ASSOCIATED_WAP,ASSOCIATED_GSMW*,ASSOCIATED_CAMEL,ASSOCIATED_MESSAGE,ASSOCIATED_SMS,ASSOCIATED_MMS,ASSOCIATED_SUSPENSE,ASSOCIATED_ROAMING,ASSOCIATED_CIBER"; ASSOCIATED_CHARGE "RUM_MAP*,CHARGE_PACKET*,DISCOUNT_PACKET*,TAX_PACKET*"; DISCOUNT_PACKET "DISCOUNT_SUBBALANCE*"; ASSOCIATED_ZONE "ZONE_PACKET*"; ASSOCIATED_INFRANET "BALANCE_PACKET*,SUB_BAL_IMPACT*,MONITOR_ PACKET*,MONITOR_SUB_BAL_IMPACT*"; SUB_BAL_IMPACT "SUB_BAL*"; MONITOR_SUB_BAL_IMPACT "MONITOR_SUB_BAL*"; ASSOCIATED_GSMW "SS_EVENT_PACKET*";
Compile and save the file.
Close the NPL Editor dialog box.
Click Save.
The configuration is saved.
By default, the file-based Collection Cartridges (CCs) do not validate the input files based on the file names. The CC nodes process the input files based on the alphabetical order of the file name.
With this patch, you can now configure a CC node to identify the duplicate files based on the file names and to validate the order of the sequence number in the input file name before processing the files.
If the CC node is configured to validate the order of the sequence number in the input file name, the CDR input file name must be with the following file name format:
sourceFilename[_seqNum].fileExtension
where:
sourceFilename is the name of the original CDR input file.
seqNum is the sequence number of the CDR input file. This should contain a fixed number of digits.
fileExtension is the extension of the original CDR input file.
The CC node now reads the CDR input file names and stores the file names in memory and in the OMC_Home/ocomc/scratch/node_id/file_duplicate_info file for a specified length of time, and stores seqNum in memory and in the OMC_Home/ocomc/scratch/node_id/file_seq_order_info file.
where:
OMC_Home is the directory in which Offline Mediation Controller is installed.
node_id is the unique ID assigned to the node when the node configuration is saved.
The CC node compares the names of the incoming files to the names in memory. If the file name does not exist in memory, the file is processed. If the file name does exist in memory, the CC node renames the file to sourceFilename.fileExtension.duplicate, logs a warning in the node log, and displays an alarm.
The CC node performs the following validations on seqNum of the incoming files:
If the file name does not include _seqNum, the CC node logs a warning in the node log and displays an alarm before processing the input file.
If the file name includes _seqNum and seqNum is in numerical order, the CC node sets seqNum in memory and in the file_seq_order_info file and processes the input file without any warnings. For example:
When the CC node processes ABC_10.txt as the first CDR input file, the CC node sets seqNum to 11, which is the next sequence number, and processes the input file.
If the CC node receives ABC_11.txt as the next CDR input file, the CC node sets seqNum to 12 and processes the input file.
If the file name includes _seqNum and seqNum is not in numerical order, the CC node logs a warning in the node log and displays an alarm before processing the input file. For example:
When the CC node processes ABC_10.txt as the first CDR input file, the CC node sets seqNum to 11, which is the next sequence number, and processes the input file.
If the CC node receives ABC_15.txt as the next file, the CC node logs the out-of-sequence file name in the node log, processes the input file, and resets seqNum to 16.
If the CC node receives ABC_5.txt as the next file, the CC node logs the out-of-sequence file name in the node log, processes the input file, but does not reset seqNum.
You can use the node log information to identify the out-of-sequence file names.
If the CC node stops while processing CDR input files, Offline Mediation Controller uses the information in the file_seq_order_info and file_duplicate_info files to resume the file-name-based validations when the CC node is restarted.
To configure file-name-based validations:
Log on to Offline Mediation Controller Administration Client.
The Node Hosts & Nodes (logical view) screen appears.
In the Mediation Hosts table, select the mediation host that contains the node that you want configure for file-name-based validations.
In the Nodes on Mediation Host section, select the CC node that you want to configure for file-name-based validations, and click Edit.
The Node dialog box appears.
In the Node Configuration section, click the Advanced tab.
Select the Reject Files With Duplicate File Name check box, which enables validating the name of the input file for duplicate file names.
The Expiry Time to Reject Duplicate Files field is enabled.
In the Expiry Time to Reject Duplicate Files field, enter the time in minutes after which the file names are flushed from memory. The minimum value is 1, and the maximum value is 129600. The default is 1.
Select the Sequence Ordering by File Name check box, which enables validating the order of the sequence number in the input file name.
The Multi-Threaded check box is disabled.
Click Save.
The configuration is saved.
Table 2-1 lists the Advanced tab configuration fields for file name validations.
Table 2-1 Advanced Tab File Name Validations Fields
| Field | Description |
|---|---|
|
Reject Files With Duplicate File Name |
Select this check box to enable validating the name of the input file for duplicate file names. |
|
Expiry Time to Reject Duplicate Files |
Enter the time in minutes after which the file names are flushed from memory. The minimum value is 1 and the maximum value is 129600. The default is 1. |
|
Sequence Ordering by File Name |
Select this check box to enable validating the order of the sequence number in the input file name. Note: This check box is enabled only when the Multi-Threaded check box is disabled. |
By default, Offline Mediation Controller processes the call detail record (CDR) input file as individual records.
With this patch, Offline Mediation Controller can now process the CDR input file as a single unit. This enables Offline Mediation Controller to reject the original CDR input file at any stage of processing by the nodes in the node chain.
When processing individual records, the collection cartridge (CC) node processes the CDR input file, and each CDR in the CDR input file is converted to a NAR. In the CC node, any run-time errors during the CDR data processing are handled through the NPL rule file, and the CDR input file is renamed to sourceFilename.error. The records that are already processed by the CC node and sent to the next cartridge node cannot be rolled back.
With this patch, you can configure a node to process the CDRs at file level. In case of any file errors, Offline Mediation Controller now allows rejecting the original CDR input file by the nodes in the node chain. If a node rejects the original CDR input file, the already processed records are rolled back and the rejected CDR input file goes through the batch suspense process.
You can configure file-level transaction for nodes, only if:
Each node's configuration supports file-level transaction.
The node chains contain a single flow without any splits.
When processing CDR input files, Offline Mediation Controller performs the following tasks:
Generates a transaction ID and associates the ID with the input file.
Does one of the following:
If the transaction is successful, completes the transaction and renames the original CDR input file to sourceFilename.processedFileSuffix.
where:
sourceFilename is the name of the original CDR input file.
processedFileSuffix is the file pattern suffix configured in the CC node to rename the CDR input file post processing. The default is .done.
If the transaction is rejected, renames the CDR input file to sourceFilename.reject and moves the file to the OMC_Home/reject directory. These rejected files are made available for suspense handling. See "About File-Level Transaction Suspense Workflow".
Provides statistics related to the file-level transaction. The statistics are displayed in the Transaction Details table in the Node Performance screen.
When processing the input files, you can optionally configure the file-level transaction threshold in the Node Manager configuration file. The file-level transaction threshold determines what percentage of records in a file can be suspended before the entire input file is rejected. This is an optional parameter. The default is 100%.
For example, if you have configured the file-level threshold to be at 40%, if a file contains 10 records, the file will be rejected when the fourth error record is encountered.
By default, CC supports only file-level rejections. You can configure other cartridge nodes to suspend records and recycle the records at the record level by using the record suspense workflow or reject the complete file and resubmit the file at the file-level by using the batch suspense workflow.
See the discussion about suspending and recycling call detail records in Offline Mediation Controller Suspending and Recycling Call Detail Records User's Guide for more information about the suspense workflow.
When file-level transaction is enabled in the nodes in the mediation node chain, depending on the configuration in the NPL rule file, the records are processed as follows:
When file-level transaction is enabled in a CC node, any rejections by the CC node due to a validation failure must be handled in the NPL rule file, which results in the rejection of the original input file.
Note:
CCs do not support record-level rejection.See "Configuring the NPL Rule File for File-Level Transaction".
If the input file is successfully processed by the CC node, any records rejected by the other cartridge nodes in the mediation node chain will be written to the OMC_Home/suspense/TransactionID_suspendedRecs.inProg file as suspended records, where TransactionID is a unique ID generated when the CDR input file was processed by the CC node.
When the Distribution Cartridge (DC) node completes the transaction, the DC node renames the TransactionID_suspendedRecs.inProg file to TransactionID_suspendedRecs.complete. The DC node also renames the original CDR input file to sourceFilename.processedFileSuffix.
The NAR CC node configured to read the suspended records from the OMC_Home/suspense directory sends the TransactionID_suspendedRecs.complete file to the Suspense DC node. The input record block of the NAR CC node NPL rule file is a superset of the input record blocks of all the cartridge nodes in the mediation node chain.
The Suspense DC node generates the Create or Update files in a format that is understood by Suspended Event (SE) Loader, which is a component of BRM.
See the discussion about the suspense-handling workflow for event CDRs in Offline Mediation Controller Suspending and Recycling Call Detail Records User's Guide for more information about the event suspense workflow.
When file-level transaction is enabled in the nodes in the mediation node chain, depending on the validations, the files are processed as follows:
The original CDR input file can be rejected by any cartridge node in the mediation node chain.
If the entire CDR input file is rejected, Offline Mediation Controller renames the CDR input file to sourceFilename.reject and moves the file into the OMC_Home/reject directory.
Offline Mediation Controller generates a NAR file with the file name sourceFilename_uniqueID.arch in the OMC_Home/reject directory, where uniqueID is the time in milliseconds when the CDR input file was rejected. This NAR file contains a single record with following fields:
Original source file name
Original source directory
Error directory
Error reason
Pipeline name
Pipeline category
Original source file name prefix
Original source file name suffix
Target source file name prefix
Target source file name suffix
The NAR CC node sends the sourceFilename_uniqueID.arch file to the Suspense DC node.
The Suspense DC node generates the Create or Update files in a format that is understood by SE Loader, which is a component of BRM.
See the discussion about the suspense-handling workflow for batch CDRs in Offline Mediation Controller Suspending and Recycling Call Detail Records User's Guide for more information about the batch-suspense workflow.
Important:
If a node is in a mediation node chain, you cannot enable file-level transaction for a single node. For an existing mediation node chain, to enable file level transaction for the individual nodes, you must first remove the node connections, enable file-level transaction for each node, and then reconnect the node chain.To configure file-level transactions for an existing mediation node chain:
Log on to Offline Mediation Controller Administration Client.
The Node Hosts & Nodes (logical view) screen appears.
In the Mediation Hosts table, select the mediation host that contains the node that you want configure for file-level transaction.
If the node that you want to configure for file-level transaction is in a mediation node chain, first remove the node connections.
In the Nodes on Mediation Host section, select the node that you want to configure for file-level transactions, and click Edit.
The Node dialog box appears.
In the Node Configuration section, click the Advanced tab.
Select the File Level Transaction check box, which enables file-level transactions.
Note:
If this check box is selected for a node in the mediation node chain, every node in the mediation node chain must have this check box selected.Click Save.
The configuration is saved.
Repeat the steps 4 through 7 for each node in the mediation node chain.
Reconnect the nodes in the mediation node chain.
Table 2-2 lists the Advanced tab configuration fields for file-level transaction.
To configure file-level transactions for a new node:
Log on to Offline Mediation Controller Administration Client.
The Node Hosts & Nodes (logical view) screen appears.
In the Mediation Hosts table, select a host.
In the Nodes on Mediation Host section, click New.
The Create a Node dialog box appears.
Select Cartridge Kit and click Next.
Select a cartridge type and click Next.
Select a cartridge and click Finish.
The New Node dialog box appears.
In the Node Configuration section, click the Advanced tab.
Select the File Level Transaction check box, which enables file-level transactions.
From the Rule File list, select one of the sample NPL rule files.
To edit the rule file, see "Configuring the NPL Rule File for File-Level Transaction".
Click Save.
The configuration is saved.
To configure the NPL rule file for file-level transaction:
Log on to Offline Mediation Controller Administration Client.
The Node Hosts & Nodes (logical view) screen appears.
In the Mediation Hosts table, select the mediation host that contains the node that you want configure for file-level transaction.
In the Nodes on Mediation Host section, select the node that you want to configure for file-level transactions, and click Edit.
The Node dialog box appears.
From the Rule File list, select one of the sample NPL rule files.
Click Edit for the selected rule file.
The NPL Editor dialog box appears.
In the InputRec block, define the input fields as shown in the example.
In the OutputRec block, define the following parameters as shown in the example:
The output fields.
FileReject: Specifies that the entire CDR input file is rejected if the conditions are met. When you set this parameter, the node does not wait for the file-level transaction threshold to be reached.
RecordReject: Specifies that only records are rejected if the conditions are met. When you set this parameter, the node verifies if the percentage of rejected records in the CDR input file is within the file-level transaction threshold and accordingly processes the file.
Define the validation conditions using an if() statement.
Compile and save the file.
Close the NPL Editor dialog box.
Click Save.
The configuration is saved.
The following example of an NPL rule file contains the FileReject and RecordReject parameters.
InputRec {
String calling_number;
String product_type;
String Start_time;
String End_time;
String Duration;
} in;
OutputRec {
String calling_number;
String product_type;
String Start_time;
String End_time;
String Duration;
Byte FileReject;
Byte RecordReject;
} out;
if ( in.calling_number == null)
out.FileReject = 1;
if ( in.calling_number != "10220100111" || in.product_type != "VOICE" )
out.RecordReject = 1;
//Map input to output
write(out);
See "Configuring the File-Level Transaction Threshold" for more information about configuring the file-level transaction threshold.
See Offline Mediation Controller Suspending and Recycling Call Detail Records User's Guide for more information about configuring error detecting NPL rule files.
The file-level transaction threshold determines what percentage of records in a file can be suspended before the entire input file is rejected. This is an optional parameter.
To configure the file-level transaction threshold:
Stop Node Manager.
Open the OMC_Home/bin/nodemgr.cfg file in a text editor.
Add the following entry to the file:
FILE_LEVEL_TRANSACTION_THRESHOLD 'value'
where value specifies the threshold percentage.
For example:
FILE_LEVEL_TRANSACTION_THRESHOLD '50'
Save and close the file.
Start Node Manager.
To view the file-level transaction performance:
Log on to Offline Mediation Controller Administration Client.
The Node Hosts & Nodes (logical view) screen appears.
From the Administrative Function list, select Node Performance.
In the Mediation Hosts table, select the mediation host that you want to monitor.
The Transaction Details table displays the file-level transactions currently running under the selected mediation host.
In the previous releases, Elastic Charging Engine (ECE) Distribution Cartridge (DC) supported only the Terminate usage type for offline usage requests.
With this patch, ECE DC now supports the following usage types:
Update
Refund_Unit
Refund_Amount
Cancel
Note:
For refund usage types, the call detail records (CDRs) should contain the correlation_identifier of the original debit request.For more information, see Offline Mediation Controller Elastic Charging Engine Cartridge Pack User Guide.
Long-duration sessions can be received by Offline Mediation Controller in multiple call detail records (CDRs). Depending on how you configure Aggregation Processor (AP), you can aggregate the CDRs into one or more network accounting records (NARs) that are written to a NAR archive file.
You can now aggregate CDRs based on:
Time. You specify the time duration allowed for aggregating CDRs in memory before writing the aggregated CDRs as one or more NARs to a NAR archive file.
Volume. You specify the maximum volume of a usage event in the CDR to aggregate before writing as one or more NARs to a NAR archive file.
Both time and volume. You specify the arrival time of the CDRs and the volume of the aggregated CDRs. Depending on which condition is fulfilled first, AP writes the aggregated CDRs as one or more NARs to a NAR archive file.
Offline Mediation Controller supports aggregating the CDRs based on the arrival time of the CDRs before AP writes the aggregated CDRs as one or more NARs to a NAR archive file.
If you set the option for session segmentation by the arrival time of the first CDR, the CDRs are aggregated in memory from the arrival time of the first CDR until the time configured in the Flush Time field (or until the arrival of a termination CDR). When the flush time is reached, AP writes the aggregated CDRs as a NAR to a NAR archive file. With this option, if the flush time occurs before the arrival of the termination CDR, the CDRs are written as multiple NARs to a NAR archive file.
For example, if the segmentation of the aggregated CDRs is time-based set by the arrival of the first CDR, the flush time is set to 600 (10 minutes), and the flow of CDRs is as follows:
The first CDR for session A arrives at 10:10 am
The second CDR for session A arrives at 10:15 am
The third CDR for session A arrives at 10:17 am
The fourth CDR for session A arrives at 10:21 am
The first three CDRs are aggregated and stored in the memory until 10:20 am (time of arrival of the first CDR + flush time). At 10:20 am, AP writes the aggregated CDRs as a NAR to a NAR archive file. The fourth CDR is aggregated and stored in the memory in a new aggregation session.
If you set the option for session segmentation by the arrival time of the last CDR, the CDRs are aggregated in memory from the arrival time of the last CDR until the time configured in the Flush Time field (or until the arrival of a termination CDR). When the flush time is reached, AP writes the aggregated CDRs as a NAR to a NAR archive file. If a new CDR arrives before the flush time is reached, the flush time is reset to begin from the arrival time of the new CDR. With this option, the CDRs for long-duration sessions are aggregated into a single NAR unless the flush time is reached before the arrival of the termination CDR.
For example, if the segmentation of the aggregated CDRs is time-based set by the arrival of the last CDR, the flush time set to 600 (10 minutes), and the flow of CDRs is as follows:
The first CDR for session A arrives at 10:10 am
The second CDR for session A arrives at 10:15 am
The third CDR for session A arrives at 10:17 am
If no more CDRs arrive, the three CDRs are aggregated and stored in memory until 10:27 am (time of arrival of the last CDR + flush time). At 10:27 am, AP writes the aggregated CDRs as a NAR to a NAR archive file.
Offline Mediation Controller supports aggregating the CDRs based on volume. When the volume of the aggregated CDRs reaches the configured maximum volume, AP writes the aggregated CDRs as a NAR to a NAR archive file.
For example, if the segmentation of the aggregated CDRs is volume-based, the data volume is a maximum of 1 MB, and the flow of CDRs is as follows:
The first CDR for session A has the value of 300 KB in the CDR's dataVolume field
The second CDR for session A has the value of 700 KB in the CDR's dataVolume field
The third CDR for session A has the value of 100 KB in the CDR's dataVolume field
The maximum volume limit is exceeded when the third CDR arrives and AP writes the aggregated CDRs as a NAR to a NAR archive file.
Note:
When using volume-based aggregation, AP may create NARs for a partial session. That is, if the session contains two CDRs of 6 MB and 2 MB respectively, and the maximum volume is set to 1 MB, Offline Mediation Controller creates two NARs for the session instead of one NAR per session.Offline Mediation Controller supports aggregating the CDRs based on the arrival time of the CDRs and on the volume of the aggregated CDRs. Depending on which condition is fulfilled first, AP writes the aggregated CDRs as one or more NARs to a NAR archive file.
To configure time-based, volume-based, or both time-based and volume-based aggregation:
On the Aggregator tab, do one of the following:
To configure time-based aggregation, select Time Based Session Segmentation.
To configure volume-based aggregation, select Volume Based Session Segmentation.
To configure both time-based and volume -based aggregation, select Both (Time Based and Volume Based Session Segmentation).
The fields related to the session segmentation are enabled.
If you selected Time Based Session Segmentation, do the following:
Select the Segmentation by 1st CDR arrival time check box, which sets the flush time to begin when the first CDR arrives.
Deselecting this check box sets the flush time to begin when the last CDR arrives.
In the Flush Time field, enter the interval in seconds.
In the Compression Threshold field, enter the number of stale records the node allows before compressing the aggregation table.
If you selected Volume Based Session Segmentation, do the following:
In the Volume Field field, enter the name of the field in the NPL file that provides information about the data volume in the incoming CDR. In the NPL file, this field is of Long data type.
In the Maximum Volume field, enter the maximum amount of data AP has to gather before the aggregated CDRs are written to an output file. You also select the data unit: kilobyte (KB), megabyte (MB), gigabyte (GB), or terabyte (TB).
If you selected Both (Time Based and Volume Based Session Segmentation), do the following:
Select the Segmentation by 1st CDR arrival time check box, which sets the flush time to begin when the first CDR arrives.
Deselecting this check box sets the flush time to begin when the last CDR arrives.
In the Flush Time field, enter the interval in seconds.
In the Compression Threshold field, enter the number of stale records the node allows before compressing the aggregation table.
In the Volume Field field, enter the name of the field in the NPL file that provides information about the data volume in the incoming CDR. In the NPL file, this field is of Long data type.
In the Maximum Volume field, enter the maximum amount of data AP has to gather before the aggregated CDRs are written to an output file. You also select the data unit: kilobyte (KB), megabyte (MB), gigabyte (GB), or terabyte (TB).
Select the Scheduled Daily CDR Flush check box, which writes all the aggregated CDRs to a NAR archive file at the specified time regardless of whether the aggregator is finished.
If the Scheduled Daily CDR Flush check box is selected, in the Daily Flush at Time (hh:mm) field, select the time at which the aggregated CDRs are flushed.
Click Save.
Table 2-3 lists the fields in the Aggregator tab to enable aggregating the CDRs based on the CDR arrival time, volume of the aggregated CDRs, or both.
Table 2-3 Fields in the Aggregator Tab
| Field | Description |
|---|---|
|
Time Based Session Segmentation |
Select to aggregate CDRs based on the arrival time of CDRs. This is the default. |
|
Volume Based Session Segmentation |
Select to aggregate CDRs based on the volume of the aggregated data. |
|
Both (Time Based and Volume Based Session Segmentation) |
Select to aggregate CDRs based on CDR arrival time and data volume. |
|
Segmentation by 1st CDR arrival time |
Select to flush the aggregated CDRs from memory to a NAR archive file based on the arrival time of the first CDR processed in an aggregated set of CDRs. Note: Use this option for time-based aggregation of CDRs. |
|
Flush Time |
Enter the interval, in seconds, AP waits before the aggregated CDRs are written to an output file. This is a positive number. The minimum value is 1. The recommended range is 1 to 604800. The default is 7200. Note: Use this option for time-based aggregation of CDRs. |
|
Compression Threshold |
Enter the number of stale records the node allows before compressing the aggregation table. |
|
Volume Field |
Enter the name of the field in the NPL file that provides information about the data volume in the incoming CDR. In the NPL file, this field is of Long data type. The default is DataVolume. Note: Use this option for volume-based aggregation of CDRs. |
|
Maximum Volume |
Enter the maximum volume of CDRs to aggregate in memory before writing the aggregated CDRs to a NAR archive file. You also select the data unit: kilobyte (KB), megabyte (MB), gigabyte (GB), or terabyte (TB). The default is 1000 KB. Note: Use this option for volume-based aggregation of CDRs. |
|
Scheduled Daily CDR Flush |
Select to write all the aggregated CDRs to a NAR archive file at the specified time regardless of whether the aggregator is finished. |
|
Daily Flush at Time (hh:mm) |
Select the time at which the aggregated CDRs are flushed. |
In the previous releases, when configuring File Transport Protocol (FTP) in ASCII Collection Cartridge and Network Accounting Record Collection Cartridge, you could only select passive FTP or regular FTP.
With this patch, while configuring FTP, you can now select secure FTP (SFTP) from the FTP Type list of the FTP Configuration dialog box. Table 2-4 lists the values in the FTP Type list of the FTP Configuration dialog box and their description.
Table 2-4 Values in the FTP Type List
| FTP Type List Value | Description |
|---|---|
|
Regular |
The client initiates the control connection with the server and the server initiates the data connection with the client. |
|
Secure (SFTP) |
Both the data and the commands are transferred in specially formatted packets through a single connection. When using SFTP, all data sent between the client and the server is encrypted using an encryption cipher. |
|
Passive |
The client initiates all connections with the server. The server informs the client about the port to be used for the data connection.Use the Passive FTP mode when the FTP server is not able to establish the data connection; for example, when using FTP over a network firewall. Though you can define a firewall rule to open the FTP connections, the servers may not be authorized to open the data connection through the firewall. By using the Passive FTP mode, both types of connections are opened from the client side. |
Offline Mediation Controller now supports caching the bulk processing of network accounting record (NAR) data. By default, each intermediate NAR archive file is created and read line by line by each processing node.
With this patch, when the Enable bulk read/write check box is selected, each NAR archive file is read and stored in memory for processing by the respective node, and the NAR output files are written into memory before writing to the cache output file, reducing the processing time.
For more information, see "Improving the Reading and Writing of Network Accounting Records".
By default, processing nodes read and write intermediate NAR archive files line by line.
You can configure the node to use bulk read and write. The bulk read and write function:
Reads and stores each intermediate NAR archive file as a whole into memory for processing by the respective node.
Writes the NAR output file as a whole into memory, until either the maximum number of NARs for a file is reached or the idle write time has expired, before writing the output data to a cache file.
Bulk read and write operations process and pass data records using memory, reducing the processing time.
Important:
If you have system memory constraints, use the Enable bulk read/write function only for your critical path node chains.Configuring Bulk Reading and Writing of Network Accounting Records
To configure bulk reading and writing of NARs:
Log on to Offline Mediation Controller Administration Client.
The Node Hosts & Nodes (logical view) screen appears.
In the Mediation Hosts table, select the mediation host that contains the cartridge node that you want to configure for bulk reading and writing.
In the Nodes on Mediation Host section, select the cartridge node that you want to configure for bulk reading and writing, and click Edit.
The Node dialog box appears.
In the Node Configuration section, click the General tab.
Select the Enable bulk read/write check box.
In the NARs Per File field, enter the maximum number of NARs allowed in an output file.
In the Idle Write Time field, enter the number of seconds Offline Mediation Controller waits before transferring the NAR output file to the output directory of the processing node, whether or not it has reached its maximum size.
Click Save.
Table 2-5 lists the General tab configuration fields for bulk reading and writing.
Table 2-5 General Tab Bulk Read and Write Fields
| Field | Description |
|---|---|
|
Enable bulk read/write |
Select this check box to enable bulk reading and writing of network accounting record (NAR) archive files. When selected, each NAR archive file is stored in memory for processing by the respective node, and output NAR archive files are kept in memory until the maximum number of records for a file is reached, or the idle write time has expired. Important: Do not enable if your system is low in memory, such as, for nodes that run high volumes of data processing. |
|
NARs Per File |
Enter the maximum number of NARs allowed in an output file. The range is 1 to 10000. |
|
Idle Write Time |
Enter the number of seconds Offline Mediation Controller waits before transferring the NAR output file to the output directory of the processing node, whether or not it has reached its maximum size. The range is 1 to 3600. |
The maximum log file size for all cartridges has increased to 2 GB.
To set the log file size:
From the Node Configuration window, click the General tab.
In the Max Log File Size field, enter the number of bytes. For example, to set the maximum size to 2 GB, enter 2000000000.
The default is 100000, the minimum value is 50000, and the maximum value is 2000000000.
When the maximum size is exceeded, the node closes the log file and opens a new log file. Closed log files are saved using the cartridge node name, and a timestamp extension in the format YYYY.MM.DD.HH.MM.SS. For example, Node_Name.2013.07.03.23.24.58.
The JDBC Distribution Cartridge (DC) now supports character large object (CLOB) and binary large object (BLOB) data types. You can insert image, audio, and multimedia objects into the database using the JDBC DC.
To support CLOB and BLOB data types in the JDBC DC:
Open the OMC_Home/customization/rules/CartridgeKit/OI/JDBC/JDBCDC_NPL.npl file in a text editor, where JDBCDC_NPL is the name of the JDBC DC NPL file.
Add the following entry in the configuration clause:
LOBData "LOBMAPPING";
Add the following block for the LOBMAPPING configuration parameter:
Expose for LOBMAPPING{ out.attribute1 "CLOB"; out.attribute2 "BLOB"; }
where:
attribute1 is the CLOB data column of an Oracle database table.
attribute2 is the BLOB data column of an Oracle database table.
Save and close the file.
This section describes the enhancements to Offline Mediation Controller when integrated with external applications.
Offline Mediation Controller now integrates with BRM to support suspense handling of call detail records (CDRs).
The Offline Mediation Controller Suspense Distribution Cartridge (DC) receives the suspended CDRs, generates files in a format that is understood by the BRM components, and distributes these files to the BRM database. After being corrected by Suspense Management Center or the pin_recycle utility, the suspended CDRs are recycled back into Offline Mediation Controller, where the Recycle AQ Job Collection Cartridge (CC) picks up the recycle notification and the Recycle Enhancement Processor (EP) restores the CDRs. The corrected CDRs are then sent to the Elastic Charging Engine, which is a component of BRM, for rating.
For more information, see Offline Mediation Controller Suspending and Recycling Call Detail Records User's Guide.
This section describes the enhancements to Node Manager.
Offline Mediation Controller now supports multi-threaded record processing with Record Processing Enhancement Processor (EP) nodes.
By default, an EP processes records in sequential order, using a single processing thread. When you use a single-threaded EP to enrich the data records with a multi-threaded Collection Cartridge (CC) and a multi-threaded Distribution Cartridge (DC), the records processing is slower. With this patch, when multi-threading is enabled for Record Processing EP nodes, multiple files are processed in parallel, reducing the processing time.
To configure multi-threaded processing for Record Processing EPs:
Log on to Offline Mediation Controller Administration Client.
The Node Hosts & Nodes (logical view) screen appears.
In the Mediation Hosts table, select the mediation host that contains the Record Processing EP node that you want configure for multi-threading.
In the Nodes on Mediation Host section, select the Record Processing EP node that you want to configure for multi-threading, and click Edit.
The Node dialog box appears.
In the Node Configuration section, click the Advanced tab.
Select the Multi Threaded check box.
When the Multi Threaded check box is selected, the Processing Threads field and the Enable Ordering check box are enabled.
In the Processing Threads field, enter the number of processing threads you require for your thread pool. The maximum value is 20.
(Optional) If you require the order of the output data across all threads to be processed in the same order as the input data, select the Enable Ordering check box.
Click Save.
Table 2-6 lists the Advanced tab configuration fields for multi-threading.
Table 2-6 Advanced Tab Multi-Threading Fields For Record Processing EPs
| Field | Description |
|---|---|
|
Multi Threaded |
Select this check box, to enable multi-threading. |
|
Processing Threads |
Enter the number of processing threads required for your thread pool. For Record Processing EPs:
|
|
Enable Ordering |
Select this check box to keep the order of the output across all threads in the same order as the input data, when using the multi-threaded process for Record Processing EPs. |
Offline Mediation Controller now supports multi-threaded processing with file-based Collection Cartridge (CC) nodes and file-based Distribution Cartridge (DC) nodes and Local Data Manager (LDM).
By default, file-based CC and file-based DC node input files are processed in sequential order, using one processing thread. With this patch, when multi-threading is enabled for file-based CC and DC nodes, multiple input files are processed in parallel, reducing the processing time.
For more information, see "About Multi-Threading with File-Based Cartridges".
Currently, LDM uses a single-threaded process, which transfers all the first-processing-node output files, before beginning to transfer all the second-processing-node output files to the destination cartridges. With this patch, LDM transfers the output files in parallel from multiple processing nodes to the destination cartridges, reducing the processing time or the transfer time.
For more information, see "About Multi-Threading with Local Data Manager".
LDM moves data between processing nodes on the same mediation host, using a multi-threaded process.
In a multi-threaded process, LDM transfers the output files in parallel from multiple processing nodes to the destination cartridges. The number of source nodes you have in your node chain is the number of threads.
By default, file-based CC and file-based DC node input files are processed in sequential order, using one processing thread.
When multi-threading is enabled for file-based CC and file-based DC nodes, input files are processed in parallel.
Defining the Processing Order of Files
By default, file-based CC nodes process input files based on the ascending order of the filenames. When multi-threading is enabled, the order is not maintained. If you require your file-based CC and file-based DC nodes to output files in the order that the files are read and processed, even when multi-threading is enabled, select the Enable Ordering check box.
Note:
For ASCII DC file-based cartridges:If Multi Threaded and Enable Ordering are enabled, the maximum number of records set in the Max Records Per File field in the File Output node tab is disregarded. Files retain the original number of records received by the ASCII DC node.Configuring Multi-Threading Processing for File-Based Cartridges
To configure multi-threading processing for file-based cartridges:
Log on to Offline Mediation Controller Administration Client.
The Node Hosts & Nodes (logical view) screen appears.
In the Mediation Hosts table, select the mediation host that contains the file-based cartridge node that you want configure for multi-threading.
In the Nodes on Mediation Host section, select the functional file-based cartridge node that you want to configure for multi-threading, and click Edit.
The Node dialog box appears.
In the Node Configuration section, click the Advanced tab.
Select the Multi Threaded check box.
In the Processing Threads field, enter the number of processing threads you require for your thread pool. The maximum value is 20.
(Optional) If you require the order of the output data across all threads to be processed in the same order as the input data, select the Enable Ordering check box.
Click Save.
Table 2-7 lists the Advanced tab configuration fields for multi-threading.
Table 2-7 Advanced Tab Multi-Threading Fields
| Field | Description |
|---|---|
|
Multi Threaded |
Select this check box, to enable multi-threading. |
|
Processing Threads |
Enter or select the number of processing threads required for your thread pool. For file-based cartridges:
|
|
Enable Ordering |
Select this check box to keep the order of the output across all threads in the same order as the input data, when using the multi-threaded process for file-based cartridges. |
The following Node Manager performance improvements were made:
Start time processing
Currently, when you start multiple nodes in a node chain, faster-starting nodes have to wait for slower-starting nodes, before they can process any available input data. For example, a node that receives input data from a database will take longer to start than a node that receives input data from a file.
With this release, when you start multiple nodes in a node chain, Node Manager processes the requests in parallel, improving the time in which the input data starts to be processed.
Response time between Administration Server and Node Manager
Currently, when you run operational requests such as Start, Stop, Delete, Clear, and View Log, you have to wait until one operation request is finished before you can run another operational request.
With this release, Administration Server processes Administration Clients incoming requests asynchronously, allowing multiple independent operations to run at the same time, improving the user experience.
System resource allocation
Currently, you can start multiple instances of Node Manager from the same installation location.
With this release, you can start only one instance of Node Manager from the installation location, improving system resource allocation.
Note:
If you use multiple Node Managers to control large sets of node chains, you must install each Node Manager in a different location.This section describes the enhancements to Record Editor.
In the previous releases, to edit an attribute in a network account record (NAR) file, you could edit only one record at a time.
With this patch, you can now update or delete the attribute of multiple records at one time.
For more information about editing multiple records, see the discussion about updating and deleting multiple records in Offline Mediation Controller System Administrator's Guide.
When editing NAR archive files, you can edit the records in XML format rather than in NAR format.
With this patch, you can now export all the records in a NAR archive file to an XML file, manually edit the records in the XML file, and import the edited records back into a NAR archive file.
For more information, see the discussion about working with NAR archive files and XML files in Offline Mediation Controller System Administrator's Guide.
This section describes the enhancements to support and certification.
With this patch, Offline Mediation Controller Administration Client is now certified on Windows 8.1.
With this patch, Offline Mediation Controller is now certified with Apache Xalan 2.7.2.
With this patch, Offline Mediation Controller is now certified with J2SSH Maverick 1.6.5.
With this patch, Offline Mediation Controller is now certified with SNMP API 4.0 Service Pack 7.
With this patch, Offline Mediation Controller is now certified with OSS Nokalva ASN.1 tools for Java 6.0.
With this patch, Offline Mediation Controller now supports Remote Diagnostic Agent (RDA) 8.03.
This section describes the enhancements to system administration.
In the previous releases, the closed log files were saved using the Offline Mediation Controller component or cartridge node name, and a timestamp extension in the format YYYY.MM.DD.HH.MM.SS; for example, Node_Name.2013.07.03.23.24.58.
With this patch, the closed log files are saved using the Offline Mediation Controller component or cartridge node name, and an incrementing number; for example, nodemgr.log.1, nodemgr.log.2.
With this patch, when an Offline Mediation Controller component or a node is started for the first time, a logger properties file is dynamically created in the OMC_Home/config/component directory and the reporting level is set to log the information messages (where component is the Offline Mediation Controller component, such as nodemgr, adminserver, and GUI).
You can now set the log4j.logger.component.component entry in the logger properties file to the following reporting levels:
NO = no logging
WARN = log only warning messages
INFO = (default) log information messages
DEBUG = log debug messages
ALL = log warning, information, and debug messages
For more information about Offline Mediation Controller log files and their logger properties files, see the discussion about using logs to monitor Offline Mediation Controller components in Offline Mediation Controller System Administrator's Guide.
With this patch, Offline Mediation Controller now allows you to create users for the following new user roles:
Administrator
Designer
Operator
Guest
For more information about the user roles, see the discussion about users in Offline Mediation Controller in Offline Mediation Controller System Administrator's Guide.
In the previous releases, when you used the -d parameter with the nodemgr, adminsvr, or gui scripts, the debugging messages were stored in a .out file. With this patch, when you use the -d parameter with the nodemgr, adminsvr, or gui scripts, the debugging messages are stored in a log file. Table 2-8 lists the scripts and their log files with their locations.