This chapter provides an overview of the new features in Oracle Communications Billing and Revenue Management (BRM) 7.5 Patch Set 14 through BRM 7.5 Patch Set 23.
For information about new features in related products, see the following guides:
BRM Elastic Charging Engine 11.3 Release Notes, Release 7.5
Oracle Communications Billing Care Release Notes, Release 7.5
Oracle Communications Pricing Design Center Release Notes, Release 11.2
This section describes the enhancements to accounts receivable.
Oracle Communications Pricing Design Center (PDC) now supports wildcard (*) in item type selectors. By setting the true or false value for the applicableToAllChildServices and applicableToAllChildEvents elements in PDC, you can configure whether all the child services or events of a service or event must be considered for item assignment.
If set to true, the real-time rating engine and batch rating engine consider all child services or events for the specified item assignment. If set to false, the real-time rating engine and batch rating engine do not consider child services or events for the specified item assignment.
If you are using wildcard in item type selectors, you must set the PDCEnable entry to true in the DAT_ItemAssign module in the Pipeline_home/conf/wireless.reg file.
For more information on using wildcard in item type selectors, see PDC 11.2 Release Notes.
In previous releases, you could perform bill-level adjustments only for the remaining due amount (current bill due) for a fully or partially paid bill.
You can now improve performance of bill-level adjustments for fully or partially paid bills by setting the BillPaymentDeallocation field in the ar instance of the /config/business_params object to enabled.
When the BillPaymentDeallocation field is enabled, you can use PCM_OP_AR_BILL_ADJUSTMENT to adjust the total bill amount for a fully or partially paid bill. The amount of adjustment for the bill can be more than the remaining due, but it cannot exceed the total bill amount. For example, if the total bill amount is $5 and you have already made a partial payment of $2, the remaining due is $3. In this scenario, you can perform a credit adjustment for up to $5 (total bill amount).
However, if there is an A/R action (such as an adjustment or a dispute) already performed on the bill, you can perform adjustments for only up to the amount due after the initial A/R action is performed. For example, if an item-level adjustment of $1 is made on a bill of $5 and you have already made a partial payment of $2, the remaining due is $2. In this scenario, you can perform a credit adjustment for only up to $4 (which is the amount due after item-level adjustment).
For more information, see the discussion about improving bill-level adjustments for fully or partially paid bills in BRM Managing Accounts Receivable.
This section describes the enhancements to billing.
In previous releases, when an account was moved to a hierarchy as a child account, the bills generated for the account earlier were not displayed in the bills list.
With this enhancement, you can view the bills that are generated before and after moving the account to a hierarchy in the account's Bills > Switch Bills menu. For more information, see the discussion about switch bills in the Billing Care Online Help.
You can now collect the general ledger (G/L) data for trial billing by setting PerfAdvancedTuningSettings in the billing instance of the /config/business_params object to 64. This enables the creation of journals (/journal objects) for trial billing.
For more information, see the discussion about billing business_params entries in BRM System Administrator's Guide.
You can now skip the previous total unpaid bill for an open item accounting type bill unit (/billinfo object) when calculating the current bill by setting the business profile key, Skip_Prev_Total. By setting Skip_Prev_Total, you can reduce the time taken for calculating the current bill for open item accounting type.
For more information, see the discussion about using business profiles to improve performance by skipping the previous total for an open item accounting type when calculating the current bill in BRM System Administrator's Guide.
This section describes the enhancements to Oracle Communications Billing and Revenue Management (BRM) Business Operations Center.
For more information on the following functionality, see Oracle Communications Billing and Revenue Management (BRM) Business Operations Center Online Help.
You can now resolve the following types of failed BRM payments in Business Operations Center:
Failed credit card transactions.
Payments failed due to issues in the payment clearing house.
Payments failed due to loss of connection.
You can now configure a product catalog synchronization job in Business Operations Center to update plans for different pricing components, such as charge offers, discount offers, packages, and so on, in the BRM server.
You can now configure a job in Business Operations Center to find accounts that have refund items and to make online refund transactions.
Business Operations Center now enables you to do the following:
Send email notifications to users after a job is completed.
Display completed and upcoming jobs in a scrolling, calendar-like format.
Configure a recurring job to run at the last day of the month.
Edit a job.
Deactivate and activate a job.
Create a blackout period.
A blackout period is a time in the future during which one-time jobs cannot be scheduled to run.
This section describes the enhancements in customer management.
In previous releases, the discount proration was not set properly if the discount validity was starting or ending in a future cycle.
With this enhancement, during billing, BRM identifies the discounts that starts or ends in the next billing cycle and sets the discount validity and proration appropriately. For example, if proration for a discount is set to Full discount, full discount is applied even if the discount validity ends in the middle of the next billing cycle.
For more information on discount validity, see the discussion about configuring discount validity in PDC User's Guide if you are using PDC or the Pricing Center Online Help if you are using Pricing Center.
In previous releases, you could not migrate legacy service and balance data incrementally into the BRM system by using the pin_cmt utility. For example, when the legacy data was migrated into BRM in phases, if the account already migrated to BRM had some services associated with it, you could not migrate additional legacy services for the same account. As a result, the legacy service and balance updates could not be loaded incrementally into Oracle Communications Billing and Revenue Management Elastic Charging Engine (ECE) in real time.
With this enhancement, you can migrate legacy service and balance data incrementally into the BRM system by using the pin_cmt utility and also load the migrated data into ECE synchronously in real time. For example, after the initial migration of the legacy account and service data into BRM and ECE, you can migrate additional legacy services and balances for the same migrated accounts into BRM and also synchronize them with ECE in real time.
To migrate the legacy service and balance data incrementally into BRM and ECE synchronously, the following changes have been made in BRM:
The CMT_Service.xsd schema file has been introduced to support incremental migration of legacy service data.
The CMT_Balances.xsd schema file has been modified to support incremental migration of legacy balance data.
A new entry, infranet.cmt.uselegacybalances, has been introduced in the BRM_home/apps/cmt/Infranet.properties file to support incremental migration of legacy balance data.
The cmt_mta_cycle_fees utility, which is run internally by the pin_cmt utility, has been modified and renamed as cmt_mta_deploy. Do not run this utility by itself.
Following new parameters are introduced for migrating legacy data by using the pin_cmt utility:
deploy_db specifies to deploy the migrated data in BRM and also load them into ECE synchronously (in real time). You can use this parameter only when you are migrating the complete legacy data and you have ECE integrated with BRM.
Note:
After deploying the legacy data by using this parameter, you need to load the data manually into ECE by using the CustomerLoader utility and then run the pin_cmt utility with the apply_cycle_fees parameter to apply the cycle fees for the migrated accounts.For information on loading data using the CustomerLoader utility, see the discussion about using CustomerLoader in BRM Elastic Charging Engine Implementation Guide.
apply_cycle_fees specifies to apply the cycle fees for the migrated accounts. You can apply the cycle fees after deploying the migrated accounts in BRM and then loading them into ECE synchronously. You can use this parameter only when you are migrating the complete legacy data and you have ECE integrated with BRM.
deploy_ece specifies to deploy the migrated data in BRM and also load them into ECE synchronously. You can use this parameter when you are migrating the legacy data incrementally and you have ECE integrated with BRM.
Note:
If ECE is not integrated with BRM, you can use the deploy parameter for both complete and incremental migration of legacy data into BRM. For more information, see the discussion about loading legacy data into the BRM database in BRM Managing Customers.When you use the deploy_ece parameter, the pin_cmt utility deploys the migrated data in BRM and also sends it to ECE in real time through External Manager (EM) Gateway. In this case, both the BRM database and the ECE cache updates occur in a single transaction. If the ECE cache update succeeds, the updates are saved to the BRM database. If the cache update fails, the database updates are rolled back. This ensures that the BRM and ECE data remain synchronized whether the cache update succeeds or fails. You can use the cmt.pinlog files in BRM and error logs in ECE to troubleshoot the errors. For more information on troubleshooting Conversion Manager, see BRM Managing Customers. For more information on troubleshooting ECE, see BRM Elastic Charging Engine System Administrator's Guide.
For migrating service or balance data incrementally, see:
Migrating Legacy Service Data Incrementally into BRM and ECE
Migrating Legacy Balance Data Incrementally into BRM and ECE
BRM merges the migrated legacy balance data with the existing balance data in the BRM database. If the sub-balance already exists in the BRM database, it replaces the sub-balance with the corresponding legacy balance. If the sub-balance does not exist, it adds the legacy balance to the BRM database. BRM identifies the existing sub-balances in the BRM database by using the combination of the following data in /cmt_balances objects:
resource ID
POID of the granting product/charge offer or discount
VALID_FROM date
In case if the VALID_FROM date is not specified, the first sub-balance available for the specified granting product or discount is replaced with the legacy balance. However, you must ensure that the VALID_FROM date is specified for all the legacy balances to be migrated. This ensures that the balances are replaced appropriately.
In case if the POID of the granting product or discount is not specified, a new sub-balance is created with the specified VALID_FROM and VALID_TO dates.
Migrating Legacy Service Data Incrementally into BRM and ECE
To migrate the legacy service data incrementally into BRM and ECE synchronously:
Create XML files with the legacy service data, which conform to the format detailed in the CMT_Service.xsd file.
Go to the BRM_home/apps/cmt directory.
Import the legacy service data into the BRM database by running the following command:
pin_cmt -import -file XML_input_data_file stage_ID
where:
XML_input_data_file is the XML file with the legacy service data.
stage_ID is the unique identity of the staging area.
Note:
Ensure that the stage_ID is unique for each migration.Ensure that all the pricing data is loaded into the ECE cache. See the discussion about verifying that pricing data is loaded into ECE in BRM Elastic Charging Engine Implementation Guide.
Ensure that the real-time synchronization is enabled in ECE. See the discussion about enabling real-time synchronization of BRM and ECE customer data updates in BRM Elastic Charging Engine Implementation Guide.
Deploy the staged data to the production area and load the data into ECE synchronously by running the following command:
pin_cmt -deploy_ece DOM stage_ID
where DOM is the billing cycle's day of month.
The services are deployed in BRM and are synchronized with ECE in real time.
After deploying the services, the pin_cmt utility does the following:
Applies the cycle fees in BRM and synchronize them with ECE if the infranet.cmt.deploy.opcode entry is set to true. See the discussion about applying cycle fees to deployed accounts in BRM Managing Customers.
Deploys the legacy balances if the infranet.cmt.uselegacybalances entry is set to true. For more information, see "Migrating Legacy Balance Data Incrementally into BRM and ECE".
For more information on migrating data, see the discussion about loading legacy data into the BRM database in BRM Managing Customers.
Migrating Legacy Balance Data Incrementally into BRM and ECE
To migrate the balance data incrementally into BRM and ECE synchronously:
Open the BRM_home/apps/cmt/Infranet.properties file in a text editor.
If you want to replace the existing balances in BRM with the legacy balances, set the infranet.cmt.uselegacybalances entry to true.
Note:
This entry takes precedence over the infranet.cmt.deleteexistingbalances entry. If set to true, the infranet.cmt.deleteexistingbalances entry is not used.Important:
When the infranet.cmt.uselegacybalances entry is set to true, you must ensure the following:Check if the VALID_FROM date is specified for all the sub-balances to be migrated. The VALID_FROM date is required for identifying the sub-balances to be replaced.
Import the legacy balances before deploying the account and service data to the BRM production area. You cannot replace the balances after you deploy the migrated account and service data.
Save and close the file.
Create XML files with the legacy balance data, which conform to the format detailed in the CMT_Balances.xsd file.
Go to the BRM_home/apps/cmt directory.
Import the legacy balance data into the BRM database by running the following command:
pin_cmt -import -file XML_input_data_file stage_ID
where:
XML_input_data_file is the XML file with the legacy balance data.
stage_ID is the unique identity of the staging area.
Note:
Ensure that the stage_ID is unique for each migration.Ensure that all the pricing data is loaded into the ECE cache. See the discussion about verifying that pricing data is loaded into ECE in BRM Elastic Charging Engine Implementation Guide.
Ensure that the real-time synchronization is enabled in ECE. See the discussion about enabling real-time synchronization of BRM and ECE customer data updates in BRM Elastic Charging Engine Implementation Guide.
Deploy the staged data to the production area and load the data into ECE in real time by running the following command:
Important:
You can import the legacy account, service, and balance data into the BRM database and then deploy all the legacy data together.For deploying accounts and services, see "Migrating Legacy Service Data Incrementally into BRM and ECE" and the discussion about loading legacy data into the BRM database in BRM Managing Customers.
pin_cmt -deploy_ece DOM stage_ID
where DOM is the billing cycle's day of month.
The imported legacy data is deployed in BRM and synchronized with ECE in real time.
By default, BRM does not apply proration rules to product purchases or cancellations that align with the start of the product cycle. This allows you to apply full cycle fees or refunds for such purchases or cancellations. For example, if start date of the product cycle is July 14 and the product is purchased on the same day, proration rules are not applied and full cycle fees are applied for that product. However, if the product is purchased on July 20, proration rules are applied and the cycle fee is prorated.
You can now configure BRM to apply proration rules for all product purchases or cancellations irrespective of whether they align with the start of the product cycle or not. You can configure this by enabling the ApplyProrationRules business parameter in the subscription instance of the /config/business_params object.
For more information, see the discussion about enabling BRM to apply proration rules in BRM Configuring and Running Billing.
By default, BRM retrieves product details from the rating cache during product purchase. However, reading a large number of rate plans for retrieving product details can consume a lot of time. This slows down product purchase.
To speed up the product purchase process, you can enable BRM to retrieve product details directly from the BRM database during product purchase and disable the retrieval of product details from the rating cache. You can do this by setting the GetRatePlanFromCache field in the subscription instance of the /config/business_params object to disabled.
Note:
Setting the GetRatePlanFromCache field to disabled will impact the billing performance.For more information, see the discussion about improving performance in retrieving product details during product purchase in BRM System Administrator's Guide.
In the previous releases, when using an external application to connect to BRM, BRM did not log any information about a request from the external application. If the request failed, identifying the original request from the external application was not easy.
With this patch, BRM can now log the external user and the external correlation ID in the correlation ID of the error message header in the BRM error logs. The external user and the external correlation ID can be used to track the original request from the external application.
The input and output flists of the standard and policy opcodes called by the external application now include the following optional fields in the PIN_FLD_CONTEXT_INFO substruct:
PIN_FLD_EXTERNAL_USER: Specifies the external user from the external application
PIN_FLD_CORRELATION_ID: Specifies the external correlation ID from the external application
Note:
If the external application does not provide the external user and external correlation ID, the correlation ID displays empty strings.For more information, see the discussion about using error logs to troubleshoot BRM in BRM System Administrator's Guide.
This section describes enhancements to event notification.
In previous releases, each entry in the event notification list had to match the full name of an event type. Sometimes, that requirement made the list very long and difficult to maintain.
Now, you can shorten the list by using regular expressions to make a single entry apply to multiple event types.
For example, you can replace all the following entries:
301 0 /event/session/call 301 0 /event/session/dialup 301 0 /event/session/pcm_client 301 0 /event/session/telco 301 0 /event/session/telco/gprs 301 0 /event/session/telco/gprs/master 301 0 /event/session/telco/gprs/subsession 301 0 /event/session/gsm 301 0 /event/session/imt 301 0 /event/session/telco/pdc
With one regular expression:
301 0 /event/session/*
To use this feature, you must enable it.
For more information, see the discussion on using regular expressions in the event notification list in BRM Developer's Guide.
This section describes the enhancements to LDAP Manager.
BRM now supports Transport Layer Security (TLS) to provide secure communication between LDAP Data Manager and Connection Manager (CM).
To enable secure communication between LDAP Data Manager and CM:
Download the Oracle Database 12c Release 1 (12.1.0.2.0) client libraries (32-bit) for Linux from the Oracle Technology Network Web site.
Install the client libraries in a location that is accessible to LDAP Data Manager (dm_ldap).
Open the start_dm_ldap script in a text editor.
Add the following lines immediately after line 58:
LDAP_12C_LIBS=client_libraries_path if [ "$LD_LIBRARY_PATH" = "" ]; then LD_LIBRARY_PATH=${LDAP_12C_LIBS} else LD_LIBRARY_PATH=${LDAP_12C_LIBS} :$ {LD_LIBRARY_PATH}
where client_libraries_path is the path to Oracle Database 12c Release 1 (12.1.0.2.0) client libraries.
Save and close the file.
Create a soft link of dm_ldap to point to dm_ldap12c by running the following command:
ln -sf BRM_home/bin/dm_ldap12c BRM_home/bin/dm_ldap
Restart LDAP Data Manager (dm_ldap).
BRM now supports TLS to provide secure communication between LDAP Manager and LDAP Directory Severs.
For more information, see the discussion about enabling secure communication between LDAP Manager and LDAP Directory Severs in BRM LDAP Manager.
This section describes the enhancements to payments.
Credit card networks, such as VISA, MasterCard, Diners, Discover, JCB, and American Express, support the stored credential framework. They allow the merchants to use stored credentials for transactions. A stored credential is a payment information (such as an account number or a payment token) of a card holder stored by a merchant or its agent, a payment facilitator, or a staged digital wallet operator to process future transactions for the card holder. The Paymentech card processors also support customer-initiated or merchant-initiated transactions with stored credentials.
With this enhancement, BRM supports payment transactions with stored credentials for VISA, MasterCard, Diners, Discover, JCB, and American Express cards. You can also customize BRM to support stored-credential transactions for other card networks. When VISA, MasterCard, Diners, Discover, JCB, and American Express cards are used for payments, the PCM_OP_PYMT_COLLECT opcode sends the following information required for card transactions to Paymentech Data Manager (dm_fusa) and stores the responses received from Paymentech DM for future transactions:
Type of charge, such as recurring, one-time, and installment.
Transaction type.
Information on whether the card details are stored for future use.
A unique ID (TXID) obtained from a previous verify/charge transaction of the same type
You can override this information sent to Paymentech DM based on your business requirements. If you do not want to store credentials for future transactions, you can remove this information from the input passed to the PCM_OP_PYMT_COLLECT opcode.
For more information on storing or purging card credentials, see the following:
If you already have payment information stored in BRM for cards that support the stored credential framework, see "Migrating Legacy Payment Information".
To support the stored credential framework, the following changes have been made in BRM for this feature:
A new array, PIN_FLD_TRANSACTIONS, has been introduced in the /payinfo/cc storable class with the following optional fields to hold the Stored Credential Framework-specific information:
PIN_FLD_BILLINFO_OBJ. The bill unit (billinfo) for which payment is applied using the payment information (payinfo) in this array.
Note:
You can associate one payment information with multiple bill units. Each bill unit has its own recurring cycle and each series of recurring cycles must have its own TXID.PIN_FLD_MODE. The message type with which the initial transaction was performed.
PIN_FLD_TRANS_ID. The TXID received in the initial transaction response.
A new array, PIN_FLD_TRANSACTIONS, has been introduced in the /event/billing/charge/cc and /event/billing/validate/cc storable class with the following optional fields to hold the Stored Credential Framework-specific information:
PIN_FLD_TRANS_ID. The TXID received in the initial transaction response.
PIN_FLD_MODE. The message type with which the transaction was performed.
PIN_FLD_FLAGS. The flag which indicates whether the credentials are stored in the file.
PIN_FLD_TYPE. The transaction type.
The following opcodes have been modified to include the PIN_FLD_TRANSACTIONS array:
PCM_OP_PYMT_COLLECT
PCM_OP_PYMT_POL_PRE_COLLECT
PCM_OP_PYMT_CHARGE
PCM_OP_PYMT_CHARGE_CC
PCM_OP_CUST_COMMIT_CUSTOMER
PCM_OP_CUST_CREATE_PAYINFO
PCM_OP_CUST_SET_PAYINFO
PCM_OP_CUST_POL_VALID_PAYINFO
The following tables have been added to store the information in the PIN_FLD_TRANSACTIONS array:
EVT_BILLING_CHARGE_CC_TRANS_T
EVT_BILL_VLDT_CC_TRANS_T
PAYINFO_CC_TRANS_T
BRM payment collection utilities, such as pin_collect and pin_deposit, have been enhanced to support stored credentials.
For more information on the field definitions and valid values, see BRM Opcode Flist Reference.
Storing Card Credentials for Future Transactions
To store the credit card information for future transactions, use PCM_OP_PYMT _COLLECT.
This opcode does the following:
Receives the PIN_FLD_TRANSACTIONS array from the following opcodes if a VISA, MasterCard, Diners, Discover, JCB, or American Express card is registered for payment:
PCM_OP_CUST_COMMIT_CUSTOMER. This opcode passes the PIN_FLD_TRANSACTIONS array as input when you register a new customer with Credit Card as the default payment method and the cc_validate or cc_collect flag in the CM configuration file or credit card tokenization is enabled.
PCM_OP_CUST_SET_PAYINFO. This opcode passes the PIN_FLD_TRANSACTIONS array as input when you set Credit Card as the default payment method for the account.
PCM_OP_CUST_CREATE_PAYINFO. This opcode passes the PIN_FLD_TRANSACTIONS array as input when you add a new credit card and set that as the default payment method for the account.
Accepts the card information in the PIN_FLD_TRANSACTIONS array, adds missing information as required, and then passes the information as input to the PCM_OP_PYMT_POL_PRE_COLLECT policy opcode.
Note:
You can add, update, or remove the card information in the PIN_FLD_TRANSACTIONS array by customizing the PCM_OP_PYMT_POL_PRE_COLLECT policy opcode.Receives the updated card information and PIN_FLD_CHARGES from the PCM_OP_PYMT_POL_PRE_COLLECT policy opcode.
Sends the card information in the PIN_FLD_TRANSACTIONS array to Paymentech DM by calling the PCM_OP_PYMT_CHARGE or PCM_OP_PYMT_CHARGE_CC opcode.
Paymentech DM appends the required records based on the information received and sends the transactions to Paymentech. If the transaction is successful, Paymentech DM retrieves the TXID from the Paymentech response and passes it to the PCM_OP_PYMT_COLLECT opcode.
Accepts the TXID received from Paymentech DM and stores it in the PIN_FLD_TRANSACTIONS array in the /payinfo/cc object for future transactions.
When Credit Card is set as the default payment method, the PIN_FLD_TRANSACTIONS array with the card information for each bill unit is stored in the /payinfo/cc object. If the default payment method is changed to any other method or card, the PIN_FLD_TRANSACTIONS array in the /payinfo/cc object are automatically purged from the database if the payments for the accounts are not in cardholder-initiated installments. If the payments are in cardholder-initiated installments, the card holder must delete the PIN_FLD_TRANSACTIONS array manually after the payment is made for the last installment.
Migrating Legacy Payment Information
If there is legacy payment information in BRM for cards that support stored credential framework, it is automatically migrated to the new format, which includes the fields for storing credentials. BRM uses this information only for merchant-initiated transactions.
After migration, when the merchant initiates the first transaction with this payment information, the PCM_OP_PYMT _COLLECT opcode sets the TXID in the input as EXISTING9999999 to indicate that this transaction is initiated with the legacy payment information. The opcode then stores the TXID received from Paymentech DM as an additional TXID.
For credit card validations or authorizations, Paymentech Data Manager (dm_fusa) sends the Fraud Format Indicator (FR) or Product Record (PFR) record with the card security presence value. When the card security code (such as VISA CVV2) is present in the PIN_FLD_SECURITY input flist field, Paymentech DM sets the card security presence value to 1 and sends the FR or PFR record for validation by default.
With this enhancement, you can customize BRM opcodes to send other card security presence values (such as 9 (No Value)) in the input flist to Paymentech DM. You can use the PIN_FLD_AVAILABLE flist field to provide the card security presence value.
Note:
The PIN_FLD_AVAILABLE field can be used for both online and batch transactions.Following are the enumerated names and values supported in the PIN_FLD_AVAILABLE field:
typedef enum pin_pymt_card_secid_presence {
PIN_PYMT_CSP_BLANK = 0,
PIN_PYMT_CSP_AVAILABLE = 1,
PIN_PYMT_CSP_ILLEGIBLE = 2,
PIN_PYMT_CSP_NOT_PROVIDED = 5,
PIN_PYMT_CSP_NO_CSV = 9,
} pin_pymt_card_secid_presence_t;
These names and values are defined in the BRM_home/include/ pin_pymt.h file.
You can customize the PCM_OP_PYMT_POL_PRE_COLLECT opcode to send PIN_FLD_AVAILABLE and PIN_FLD_SECURITY_ID in the input flist.
For credit card transactions, Paymentech Data Manager now does the following:
If only PIN_FLD_SECURITY_ID value is present in the input flist, Paymentech DM sends the FR or PFR record for validation with the card security presence value set to 1 (value present).
If both PIN_FLD_SECURITY_ID and PIN_FLD_AVAILABLE values are present in the input flist, Paymentech DM sends the FR or PFR record for validation with the card security presence value set to the PIN_FLD_AVAILABLE value.
If only the PIN_FLD_AVAILABLE value is present in the input flist, Paymentech DM sends the FR or PFR record for validation with the card security presence value set to the PIN_FLD_AVAILABLE value.
If both PIN_FLD_SECURITY_ID and PIN_FLD_AVAILABLE values are not present in the input flist, FR or PFR record is not sent for validation.
BRM applications may log flists containing the sensitive customer data. In previous releases, the card security code, such as VISA CVV2 or American Express CID, passed in the PIN_FLD_SECURITY_ID input flist field was not masked and appeared as clear text in the logs.
With this enhancement, the PIN_FLD_SECURITY_ID value is masked during logging. The card security codes passed in this field appear as masked fields in logs.
In previous releases, when the pin_recover utility and a custom application were run in parallel to resolve failed credit card or debit card payments, duplicate transaction IDs were created for such transactions.
With this patch, a new entry, event_search_delay, has been introduced in the BRM_home/apps/pin_billd/pin.conf file to specify the delay interval for resolving failed payments. You can now run the pin_recover utility with event_search_delay to delay the search of events so that pin_recover processes only the events (event/billing/charge/cc) that were created before the specified delay interval.
To configure delay interval for resolving failed payments:
Open the billing utility configuration file (BRM_home/apps/pin_billd/pin.conf) in a text editor.
Search for the event_search_delay entry.
Specify the delay interval:
pin_recover event_search_delay value
where value is the delay interval in seconds. By default, it is set to 0.
For example, setting the event_search_delay entry to 300 delays the event search for resolving failed payments by 5 minutes:
pin_recover event_search_delay 300
Save and close the file.
You can improve performance of the payment allocation by disabling the payment validation for due amounts. To disable the payment validation for the due amounts, set the DisableBatchDue entry in the PaymentTool.ini configuration file to 1. When the payment validation is disabled for due amounts, the due amounts are not displayed in the Due Amount column in Payment Tool.
For more information, see the discussion about improving payment allocation performance in BRM Configuring and Collecting Payments.
In the previous releases, you could create only one payment suspense account per schema to handle suspended payments. This payment suspense account was identified by using the first name, payment, and the last name, suspense.
With this patch, you can now create multiple payment suspense accounts per schema. Each payment suspense account is identified by using the first name, payment_value, and the last name, suspense_value, where value is any string to distinguish the payment suspense account.
value can be same or different for payment and suspense. For example, payment_USD suspense_country or payment_USD suspense_USD.
You can categorize the incoming suspended payments by distributing them among the multiple payment suspense accounts.
You can now access Payment Center using suspense account credentials to view the payments related to that account only.
You can now search for the payment suspense account information by using the Suspense Account list in Payment Center. For more information about the search criteria in Payment Center, see the Payment Center Help.
For more information about multiple payment suspense accounts, see the discussion about creating payment suspense accounts in BRM Configuring and Collecting Payments.
Payment Tool now allows you to make a payment to an account in any currency. The amount will be converted to the account's primary currency and then posted to the account.
For more information about making payments in Payment Tool, see the discussion about working with multiple currency types in Payment Tool in BRM Configuring and Collecting Payments.
This section describes the enhancements for Pipeline Manager.
You can now configure Pipeline Manager to support 28-digit decimal rather than the default of 15-digit decimal.
To configure Pipeline Manager to support up to 28-digit decimal, set the MAX28DIGIT_DECIMAL_SUPPORT environment variable to Y before you start Pipeline Manager and its services.
This section describes the enhancements for rating.
In the previous releases, ECE was using the Portal object IDs (POIDs) generated in BRM for tracking rated events and bill items created in ECE.
With this enhancement, POIDs can be generated in ECE. ECE uses Rated Event Formatter to generate the required POIDs. To support this feature, the following changes have been made in BRM:
All the existing BRM storable class definitions have been modified to include the event type. The event type is used for creating separate partitions for different set of events. When you create new custom classes in BRM, you must now set the Event Type field. For more information, see "About Creating Custom Classes".
The PCM_OP_SDK_SET_DD, PCM_OP_SET_DD, and PCM_OP_GET_DD opcodes have been modified to support the partitioning of prepaid events.
The following have been introduced to enable partitions for prepaid events:
The prepaid_partition_set and prepaid_partition_transition_mode entries introduced in dm_oracle.
The prepaidPartitionSet parameter introduced in the system instance of the /config/business_params object.
For more information, see "Enabling Prepaid-Event Partitions".
The partition_utils utility now supports the -t prepaid parameter. You can run the partition_utils utility with the enable operation and this parameter to create partitions for the prepaid events.
Enabling Prepaid-Event Partitions
If you are using ECE for usage rating, you must enable prepaid-event partition in BRM for generating the POIDs in ECE.
To enable prepaid-event partitioning:
Important:
In multischema systems, perform this task first on the primary BRM installation machine and then on the secondary BRM installation machines.Open the BRM_home/sys/dm_oracle/pin.conf file in a text editor.
Set the prepaid_partition_set entry to a numerical value between 2 and 7. For example:
- dm prepaid_partition_set 2
If this entry is set to 0, ECE uses the POIDs received from BRM for the prepaid events.
Set the prepaid_partition_transition_mode entry to 1:
Note:
Setting this entry to 1 enables Data Manager to retrieve the partitions for the existing events. After retrieving all the partitions for the existing events (for example, after 90 days), set this entry to 0 to disable this mode.
- dm prepaid_partition_transition_mode 1
Save and close the file.
Create an editable XML file from the system instance of the /config/business_params object:
pin_bus_params -r BusParamsSystem bus_params_system.xml
Set the prepaidPartitionSet parameter to the value you specified in step 2. For example:
<prepaidPartitionSet>2</prepaidPartitionSet>
Save the file as bus_params_system.xml.
Load the XML file into the BRM database:
pin_bus_params bus_params_system.xml
Stop and restart the CM.
(Multischema systems only) Run the pin_multidb script with the -R CONFIG parameter. For more information, see BRM System Administrator's Guide.
Go to the BRM_home/apps/partition_utils directory.
Create partitions for the prepaid events by running the following command:
partition_utils -o enable -t prepaid
For more information, see the discussion about partitioning database tables in BRM System Administrator's Guide.
For information on enabling POID generation and prepaid-event partitions for ECE, see the discussion about POID generation in BRM Elastic Charging Engine Release Notes.
When you create new custom classes in BRM, you must now set the Event Type field. Table 2-1 lists the event types in BRM. For instructions on how to create custom classes, see the discussion about creating custom classes in BRM Developer's Guide.
Important:
When you create a custom class, note the following:If the event type is set to NONE, the corresponding event is not synchronized with PDC.
When you add a subclass, ensure that the event type matches the event type of the parent class if the event type is set to anything other than NONE.
| Event Type | Description |
|---|---|
|
USAGE_PREPAID |
Specifies the prepaid events (real-time charging events) from ECE. |
|
USAGE_POSTPAID |
Specifies the delayed events in BRM and postpaid events (offline charging events) from ECE. |
|
SUBSCRIPTION_RECURRING |
Specifies the recurring subscription event. |
|
SUBSCRIPTION_ROLLOVER |
Specifies the subscription events generated for rollovers. |
|
SUBSCRIPTION_BILL_TIME_DISCOUNT |
(For internal use only) Specifies the subscription events generated for bill-time discounts. |
|
SUBSCRIPTION_FOLD |
(For internal use only) Specifies the subscription events generated for folds. |
|
SUBSCRIPTION_ONE_TIME |
(For internal use only) Specifies the one-time subscription events. |
|
SUBSCRIPTION_REMITTANCE |
(For internal use only) Specifies the subscription events generated for remittances. |
|
NONE |
Specifies that the event does not belong to any other event type. |
After you create the custom class and synchronize it with PDC, it is not recommended to change the event type of the custom class. However, if you have set the incorrect event type, you can change the event type by updating it first in BRM and then in PDC.
For changing the event type in BRM by editing the custom class, see the discussion about creating, editing, and deleting fields and storable classes in BRM Developer's Guide.
For updating the event type in PDC and publishing it to ECE, see the discussion about synchronizing and publishing the event type in PDC 11.2 Release Notes.
In the previous releases, sometimes there was a lag between the BRM database and the ECE cache update when the BRM data commit failed. During the lag, the BRM and ECE data were unsynchronized.
With this enhancement, the ece_post_commit_enabled entry has been introduced in BRM. The ece_post_commit_enabled entry specifies to commit the data in the ECE cache after the BRM data commit. The default value is 0. You must set this entry in the Connection Manager (CM) configuration file to 1 to enable post commit in BRM. This ensures that the data in BRM and ECE are synchronized even if the BRM data commit fails.
For information on enabling post commit in BRM and ECE, see BRM ECE 11.3 Release Notes.
When the BRM server performs customer management and billing transactions, it stores the results in the BRM database. To enable Oracle Communications Billing and Revenue Management Elastic Charging Engine (ECE) to rate usage events properly, all customer data updates made in the BRM database must also be made in the ECE cache.
In the previous releases, such updates were published to ECE asynchronously. In that mode, the ECE cache was updated after the updates were saved to the BRM database and the transaction was closed. The process used the Account Synchronization Data Manager (DM), an Oracle Advanced Queuing (AQ) database queue, and the ECE Customer Updater. Because delays could occur when Customer Updater dequeued the updates, a lag could exist between the time the BRM database was updated and the time the ECE cache was updated. During the lag, the BRM and ECE data were unsynchronized. In addition, because the updates had already been saved to the BRM database, the BRM and ECE data would be unsynchronized if the ECE cache update failed. If ECE used the unsynchronized data to rate usage events, the events might be incorrectly rated.
Now, such updates are published to ECE synchronously. In this mode, both the database and the cache updates occur within the original transaction. If the ECE cache update succeeds, the updates are saved to the BRM database. If the cache update fails, the database updates are rolled back. Because both the database and the cache are updated within the same transaction, no lag time occurs, and the BRM and ECE data remain synchronized whether the cache update succeeds or fails. Maintaining the synchronization of the BRM and ECE data preserves the integrity within the BRM system of calculations ECE makes based on that data. This process uses ECE External Manager (EM) Gateway.
See the discussion about synchronizing BRM and ECE customer data in BRM Elastic Charging Engine Concepts.
With this patch, BRM now sends account-level product, discount, discount-sharing group, and charge-sharing group details to ECE during rerating.
See the discussion about supporting customer-level product, discount, charge-sharing, and charge offers published by BRM in the ECE documentation.
This section describes the enhancements to support and certification.
With this patch, BRM 7.5 supports Oracle Database 18c R1 and Oracle Real Application Clusters 18c R1.
For more information, see BRM Installation Guide.
Currently, BRM 7.5 is certified with Perl 5.28.0. With this patch, BRM 7.5 is certified with Perl 5.28.1.
For more information, see BRM Installation Guide.
Currently, BRM 7.5 is certified with Java JRE 1.8.0_45. With this patch, BRM 7.5 is certified with Java JRE 1.8.0_201.
For more information, see BRM Installation Guide.
Currently, BRM 7.5 is certified with Business Intelligence Publisher 11.1.1.9. With this patch, BRM 7.5 is certified with Business Intelligence Publisher 12c.
For more information, see BRM Installation Guide.
Currently, BRM 7.5 is certified with Apache Xerces-C++ 3.2.1 and Apache HttpComponents HttpClient 4.5.3. With this patch, BRM 7.5 is now certified with Apache Xerces-C++ 3.2.2 and Apache HttpComponents HttpClient 4.5.8.
For more information, see BRM Installation Guide.
Currently, BRM 7.5 is certified with Perl 5.26.1. With this patch, BRM 7.5 is certified with Perl 5.28.0.
For more information, see BRM Installation Guide.
Currently, BRM Client Applications and Pipeline Configuration Center (PCC) are certified on Windows 8.
With this patch, BRM Client Applications and PCC are now certified on Windows 10.
For more information, see BRM Installation Guide.
Currently, BRM 7.5 is certified with Apache Xerces-C++ 3.1.4 and Xerces-J (Java) 2.11.0. With this patch, BRM 7.5 is now certified with Apache Xerces-C++ 3.2.1 and Xerces-J (Java) 2.12.0.
For more information, see BRM Installation Guide.
Currently, BRM 7.5 is certified with Vertex Communications Tax Q Series CTQ 1.00.13, CTQ 1.01.06, CTQ 2.00.05, and CTQ 3.0.
With this patch, BRM 7.5 is now also certified with Vertex Communications Tax Q Series 3.00.02.
For more information, see BRM Installation Guide.
Currently, BRM 7.5 is certified with Vertex Sales Tax Q Series STQ 3.1.6, STQ 3.2.21, and STQ 4.0.6.
With this patch, BRM 7.5 is now also certified with Vertex Sales Tax Q Series 5.0.
For more information, see BRM Installation Guide.
With this patch, BRM 7.5 supports Oracle Database 12c R2 (Oracle 12.2.0.1.0) and Oracle Real Application Clusters 12c R2.
For more information, see BRM Installation Guide.
Currently, BRM 7.5 is certified with Perl 5.24.0. With this patch, BRM 7.5 is certified with Perl 5.26.1.
For more information, see BRM Installation Guide.
Currently, Web Services Manager is certified on Apache Tomcat version 7.0.62.
With this patch, Web Services Manager is now certified on Apache Tomcat version 8.5.16.
For more information, see BRM Installation Guide.
Currently, BRM 7.5 is certified with Xalan-Java 2.7.2 and Xalan-C++ 1.11. With this patch, Xalan-Java and Xalan-C++ are not supported in BRM 7.5. BRM now uses Oracle XDK.
For more information, see BRM Installation Guide.
Important:
From BRM 7.5 Patch Set 21, BRM does not support the Xalan XSLT processor for generating HTML invoices. You can use a different XSLT processor by configuring it for BRM. For more information, see the discussion about using an XSLT Processor other than the Xalan XSLT Processor in BRM Designing and Generating Invoices.Currently, BRM 7.5 is certified with Vertex Communications Tax Q Series CTQ 1.00.13, CTQ 1.01.06, and CTQ 2.00.05.
With this patch, BRM 7.5 is now also certified with Vertex Communications Tax Q Series 3.0.
For more information, see BRM Installation Guide.
Currently, BRM 7.5 is certified with Perl 5.18.2. With this patch, BRM 7.5 is certified with Perl 5.24.0.
For more information, see BRM Installation Guide.
Currently, BRM 7.5 is certified with Xalan-Java 2.7.1. With this patch, BRM 7.5 is now certified with Xalan-Java 2.7.2.
For more information, see BRM Installation Guide.
Currently, BRM 7.5 is certified with Apache Xerces-C++ 3.1.3. With this patch, BRM 7.5 is now certified with Apache Xerces-C++ 3.1.4.
For more information, see BRM Installation Guide.
Currently, Web Services Manager is certified on Oracle WebLogic Server 12c Enterprise Edition 12.1.3.
With this patch, Web Services Manager is now also certified on Oracle WebLogic Server 12c Enterprise Edition 12.2.1.
With this patch, BRM 7.5 supports Solaris 11.2.
Important: You cannot upgrade from Solaris 10 to Solaris 11.2. For Solaris 11.2, Oracle recommends that you install BRM 7.5 using the BRM 7.5 installer package for Solaris11.
For more information, see BRM Installation Guide.
With this patch, you can use Oracle Communications Billing and Revenue Management Business Operations Center to run the following operations: billing, payment collection, invoicing, and general ledger (G/L) reporting. You can also use Business Operations Center to view graphs that track business trends based on data generated by those operations.
For more information about Business Operations Center, see the following:
"Using Business Operations Center" in BRM System Administrator's Guide
Business Operations Center Installation Guide
Business Operations Center security in BRM Security Guide
Business Operations Center Help
Currently, BRM 7.5 is certified with Business Intelligence Publisher 11.1.1.7.
With this patch, BRM 7.5 is now also certified with Business Intelligence Publisher 11.1.1.9.
Currently, BRM 7.5 is certified with Apache Xerces-C++ 2.7.0 and Apache Xerces-C++ 3.1.1.
With this patch, BRM 7.5 is now also certified with Apache Xerces-C++ 3.1.3.
With this patch, BRM 7.5 supports Oracle Linux 7.x and Red Hat Enterprise Linux 7.x.
For more information, see BRM Installation Guide.
With this patch, BRM 7.5 no longer supports Oracle Linux 4.x and Red Hat Enterprise Linux 4.x.
For more information, see BRM Installation Guide.
Currently, Web Services Manager is certified on Oracle WebLogic Server 11g Enterprise Edition 10.3.6.
With this patch, Web Services Manager is now also certified on Oracle WebLogic Server 12c Enterprise Edition 12.1.3.
This section describes the enhancements to system administration.
BRM now includes the following security enhancements to protect the subscriber's personal data:
Deleting closed accounts and all the related objects (such as events, items, bills, invoices, journals, newsfeeds, and user activities) and the audit data automatically from BRM after the specified retention period.
Purge deleted accounts and the associated customer data synchronously on BRM and Oracle Communications Elastic Charging Engine (ECE). For more information, see the discussion about purging accounts from the ECE cache in BRM ECE 11.3 Release Notes.
Securing communications between BRM applications and the database. See the discussion about configuring SSL for the BRM database in BRM 7.5 Patch Set 22 Installation Guide.
To support the security enhancements, the following changes have been made in BRM:
The ClosedAcctsRetentionMonths business parameter has been introduced to specify the retention period for the closed accounts. See "Specifying Retention Period for Closed Accounts".
The pin_del_closed_accts utility has been introduced to delete closed accounts from BRM after the specified retention period. See "pin_del_closed_accts".
The PCM_OP_CUST_DELETE_ACCT opcode has been modified to ensure that all the BRM objects and audit entries containing the subscriber's personal data are purged.
Caution:
You can use the PCM_OP_CUST_DELETE_ACCT opcode to delete accounts in a production system, but ensure that you use this opcode with care.For more information on the PCM_OP_CUST_DELETE_ACCT opcode, see the discussion about deleting accounts in BRM Opcode Guide.
Important:
The PCM_OP_CUST_DELETE_ACCT opcode does not delete all the custom objects. You can write a custom logic to clean up the custom objects in BRM when the /event/notification/account/pre_delete and /event/notification/account/delete events are generated by the PCM_OP_CUST_DELETE_ACCT opcode.Specifying Retention Period for Closed Accounts
You can specify the number of months the closed accounts must be retained in BRM by setting the ClosedAcctsRetentionMonths parameter in the customer instance of the /config/business_params object.
To specify the retention period for closed accounts:
Go to BRM_home/sys/data/config.
Create an XML file from the /config/business_params object:
pin_bus_params -r BusParamsCustomer bus_params_customer.xml
Set the ClosedAcctsRetentionMonths entry to the number of months that you want to retain the closed accounts:
<ClosedAcctsRetentionMonths>number_of_months</ClosedAcctsRetentionMonths>
Save the file as bus_params_customer.xml.
Load the XML file into the BRM database:
pin_bus_params bus_params_customer.xml
Stop and restart the CM.
(Multischema systems only) Run the pin_multidb script with the -R CONFIG parameter. For more information, see BRM System Administrator's Guide.
You can delete the closed accounts in BRM after the retention period by using the pin_del_closed_accts utility.
To delete closed accounts:
Go to the BRM_home/apps/pin_billd directory.
Do the following as appropriate:
Note:
To delete all the closed child accounts in a hierarchy and the sharing groups you need to run the following commands in the following order.To delete all the closed nonpaying child accounts at different levels in a hierarchy, run the following command:
pin_del_closed_accts -subord -leaf pin_del_closed_accts -subord
To delete the member accounts of the sharing groups, run the following command:
pin_del_closed_accts -members_sharing
To delete the paying child accounts at different levels in a hierarchy, run the following command:
pin_del_closed_accts -members_billing
Note:
You need to run this command for each paying account in a hierarchy. For example, if there are two paying accounts in the hierarchy, you must run this command twice to delete both the paying accounts.Run the following command, which deletes all the remaining closed accounts, including the top-level parent account in the hierarchy:
pin_del_closed_accts
If you want to delete specific closed accounts by using a file, run the following command:
Note:
Run the pin_del_closed_accts -file command only if you want to delete specific accounts, but ensure that you use this command with care.pin_del_closed_accts -file file_name
For example:
pin_del_closed_accts -file closed_accts_list.txt
The utility deletes the accounts specified in the input file. You must provide the account details in the flist format in this file. For example:
0 PIN_FLD_RESULTS ARRAY [0] allocated 20, used 1 1 PIN_FLD_POID POID [0] 0.0.0.1 /account 123 0 0 PIN_FLD_RESULTS ARRAY [1] allocated 20, used 1 1 PIN_FLD_POID POID [0] 0.0.0.1 /account 234 0
For more information on the pin_del_closed_accts utility and parameters, see "pin_del_closed_accts".
Use the pin_del_closed_accts utility to delete closed accounts from BRM. This utility calls the PCM_OP_CUST_DELETE_ACCT opcode to delete the closed accounts that are older than the specified retention period. For specifying the retention period, see "Specifying Retention Period for Closed Accounts".
To connect to the BRM database, the pin_del_closed_accts utility needs a configuration file in the directory from which you run the utility. See the discussion about connecting BRM utilities in BRM System Administrator's Guide.
BRM_home/bin
pin_del_closed_accts -subord [-leaf] -members_sharing -members_billing -file file_name [-verbose][-help]
subord [leaf]. Deletes the closed nonpaying child accounts at the bottom of the hierarchy.
subord. Deletes the remaining closed nonpaying child accounts which are parents of other child accounts at the different levels of the hierarchy. Running the pin_del_closed_accts utility with this parameter does not delete the top-level parent account in the hierarchy.
You need to run the pin_del_closed_accts utility without any parameters after deleting all the paying and nonpaying child accounts at different levels in the hierarchy to delete the top-level parent account.
members_sharing. Deletes the member accounts of the sharing groups; for example, discount and charge sharing groups.
members_billing. Deletes the closed paying accounts in the hierarchy that are used for billing purposes.
file file_name. Deletes the accounts specified in the input file. The file_name is the name and location of the file that contains the list of accounts for deletion. The account details in this file must be in the flist format.
Important:
Running the pin_del_closed_accts utility with this parameter deletes all the accounts specified in the input file even if the accounts are not older than the retention period. When you use this parameter, ensure that the input file contains only the closed accounts that need to be deleted.verbose. Displays information about successful or failed processing as the utility runs.
help. Displays the syntax and parameters for this utility.
The pin_del_closed_accts utility notifies you when it successfully deletes the closed accounts and the associated customer data.
If the pin_del_closed_accts utility does not notify you that it was successful, look in the utility log file (default.pinlog) to find any errors. The log file is either in the directory from which the utility was started or in a directory specified in the configuration file.
After you have resolved the errors, you can delete the closed accounts by running the pin_del_closed_accts utility again.
When you run the pin_crypt_app utility with the -genrootkey parameter, BRM now prompts for the root wallet password. This ensures that the root wallet is secured.
For more information, see the discussion about modifying the root encryption key in BRM Developer's Guide.
Currently, when you run the pin_crypt_app utility with the -genrootkey parameter, a root encryption key is generated and is stored in an Oracle wallet.
With this patch, if the root encryption key already exists, you can run the pin_crypt_app utility with the -genrootkey parameter to modify the existing root encryption key.
Important:
After you modify the root encryption key, re-encrypt all the passwords and update the entry in the appropriate configuration file.Note:
For multischema systems, you must run the pin_crypt_app utility with -genrootkey only from the primary schema, which will update the existing root encryption key in the Oracle wallet with the new root encryption key. The utility re-encrypts the data keys in the CRYPTKEY_T table with the new root encryption key for all the secondary schemas.For more information, see the discussion about modifying the root encryption key in BRM Developer's Guide.
This section describes the enhancements to Web Services Manager.
Currently, Web Services Manager supports the SOAP 1.1 format.
With this patch, Web Services Manager supports the SOAP 1.2 format for both BrmWebServices.war and infranetwebsvc.war files.
With this patch, Web Services Manager supports the OAuth 2.0 protocol for authorization. OAuth 2.0 is an open standard protocol for token-based authentication and authorization that enables client applications to obtain access to BRM web services without sharing a password. OAuth 2.0 provides various authentication flows. Web Services Manager supports the Authorization Code Grant flow.
When this feature is enabled, Web Services Manager authenticates and authorizes clients' access to BRM web services by validating an access token that clients use. To use OAuth 2.0 with BRM web services, configure a service for OAuth 2.0 on the Oracle Identity and Access Management server.
For more information about OAuth support in Web Services Manager, see the discussion about securing BRM web services with OAuth in BRM Web Services Manager.
In the previous releases, Web Services Manager used the BrmWsmRole.properties file, which contained Apache Axis handler configurations, to authorize web services.
With this patch, Web Services Manager now uses WebLogic Server security policy to authorize and authenticate BRM web services.
Note:
The BrmWsmRole.properties file is no longer part of the Web Services Manager installation package.For more information, see BRM Web Services Manager.
In the previous releases, Web Services Manager used the Apache Axis framework to support SOAP web services as an XML string payload and an XML element payload.
With this patch, Web Services Manager no longer uses Apache Axis framework for SOAP web services as an XML element payload. Web Services Manager now uses the JAX-WS framework to support SOAP web services as an XML element payload. To continue to use SOAP web services as an XML element payload, regenerate the web services clients with JAX-WS-based service URLs.
For more information, see BRM Web Services Manager.