Monday, 27 May 2013

Problems encountered in Oracle BRM operations

1. Dunning considering oldest due date for performing dunning action
Solution-  There is a configuration to decide the due date to be considered for performing collections/dunning on the account. For example if we have configured (due date +1) to take the first action for collections, BRM can consider the oldest or the earliest due date for the same. Below is the scenario -

i.If the entry criteria of collections is greater than 5$.
ii.Customer billed outstanding for the month of Jan is 3$ on 28th Jan (Due date is 28th of the month)
iii. Customer billed  outstanding for Feb month is 1$ on 28th Feb
iv. Customer billed outstanding for Mar month is 1$ on 28th Mar.

On 28th Mar, customer total billed outstanding is 5$ and hence customer qualifies for entering collection scenario. So if the system considers the oldest due date(28th Jan), the dunning action will be taken on 28th March itself whereas if the system considers the earliest due date (28th Mar), the dunning action will be taken on 29th March. In our project the requirement was to consider the earliest date and run dunning on 29th March.

There is a configuration in CM "old_overdue_behavior", we changed the value to 0 to consider the latest bill.
# fm_collections
# If the value of the old_overdue_behavior is 0
# The latest bill due date is considered to calculate the over due date.
# If the value of the old_overdue_behavior is 1
# The earliest bill due date is considered to calculate the over due date.
# The default will value will be 0.

2. Billing didn't run at 1am since the billing delay period was set to 0:3
Solution- There is a configuration in CM "config_billing_delay" (Specifies a delay for disabling the automatic triggering of billing)
We changed the setting to 0:1 in order to start the billing of customer at 1am.

3. DB Locks encountered in bal_grp_t during order provisioning since the table was locked for update
Solution- After deploying patchset 12 on BRM 7.4 version, the instance of bal_grp_t locking issue is minimal.
When orders are provisioned in BRM from CRM through AIA this table is selected for update, and blocking locks are observed sometimes, but after the Oracle patch deployment the issue is resolved.

4. Field missing in JCA adapter due to which profile was not created
Solution - This issue was observed when some custom fields are created in BRM which were not recognized by AIA in case of opcode call through AIA. Whenever custom fields are created corresponding classes related to the custom fields class files should be added in the pcmext.jar and then BRMJCAAdapter.rar file should be deployed in AIA.  After deploying the new RAR the custom field was recognized by AIA and the issue got resolved.

5. If the product has proration on exit, if the end date is preponed by set_prodinfo, appro amount will be refunded.
Solution - We configured a product with proration on exit, which caused refunds to customer when end date was set to earlier date, so we then changed the configuration to charge for entire cycle and then pre-poned the end date, issue was resolved.

6. Pipeline crashing when trying to rate cdr for account which has purchased more than 50 discounts.
Solution - Issue was observed whenever pipeline was trying to rate a cdr for an account having more than 50 purchased discounts. Pipeline was crashing and giving memory dump at that instance. Oracle provided a patch for this issue which resolved the pipeline crash.
There were few  instances where pipeline crashed due to insufficient memory on the application server. To resolve this issue we have increated the memory thresold value parameter "ShutdownFreeMemLimit" to 15.

7. When cycle_start_t field is set to 2nd or 3rd of the month the cycle charges and related monthly free minutes where not provided to accounts
Solution - There were some customers which were created on 30th of the month and the requirement was to start the charging from 1st of the month. For this scenario some customers purchased start date used to get set to 2nd or 3rd, and cycle forward event didn't use to get created and the monthly benefits like free usage were not given to the customers.
In order to resolve this we made sure that date is set to 1st of the month to apply the MRC from 1st of the month. If there are any accounts left with incorrect start date, we called PCM_OP_SUBSCRIPTION_CYCLE_FORWARD opcode on that account to apply MRC and provide free minutes for the month.

Wednesday, 23 November 2011

BRM Interview Questions

1. Is it possible to process cash payment if the paytype in payment information of customer is set as credit card payment?
Ans - Yes it is possible to do that.

2. How is data synchronized from BRM Infranet to Pipeline for rating?
Ans - Data is synchronized by publishing events through eai_js. The payload is generated and data is sent to dm_ifw_sync process which inturn sends the data to ifw_queue. The pipeline listener module picks the data from the queue for rating purpose.

3. How to add custom attributes to invoice to display additional event data on the invoice?
Ans - The prep_invoice policy opcode can be leveraged to add the custom attribute on the invoice. However for better performance the event attribute can be set in pipeline rating process through an iscript. This attribute can be set in the invoice automatically by enabling the usage/pipeline event in the invoice.

4. What are the different modes of invoice generation and where is the information stored?
Ans - The different modes of invoice generation is summary/detail invoice. This information is stored in the field INV_TYPE of the payinfo object. Value 0 (Detail) and 1 (Summary)

5. What are the different opcodes called during customer creation in BRM?
Ans - The PCM_OP_CUST_COMMIT_CUSTOMER calls certain opcodes in sequence to create the same. PCM_OP_CUST_PREP_CUSTOMER which validated the customer data. After this PCM_OP_CUST_CREATE_CUSTOMER is called to create acctinfo, payinfo, billinfo data to create an account.

6. What are the different status of bill items in BRM and what is the significance of status field?
Ans -There are 3 values of "status" field of bill items - 1 (Pending), 2 (Open), 4 (Closed). Item status Pending is for unbilled items, Open is for billed items but not yet paid and Closed status is for items for which due amount is paid.

Saturday, 16 April 2011

Frequently Used Macros in FM Opcodes

BRM provides certain functions to perform object manipulation operations. These functions are defined as macros which are widely used in opcodes to access BRM database and modify objects in BRM.
1. POID Management Macros (POID is a special datatype of BRM which identifies a unique object in database. Each object is defined as a storable class and has a unique POID. For example /account )

PIN_POID_GET_TYPE – This macro returns the poid object type for the poid object
PIN_POID_FROM_STR – Function to convert string value to poid value
PIN_POID_GET_ID – It gives the unique id from a poid value

2. FLIST Management Macros (All the opcodes performing business logic understand the flist data type as input. The flist is a the list of field value pairs of attributes for input/output to an opcode)-

PIN_FLIST_ELEM_GET – It fetches an ARRAY element from the flist
PIN_FLIST_ELEM_SET – This macro adds an array element into an input flist
PIN_FLIST_FLD_GET, PIN_FLIST_FLD_SET As name suggests, these two macros gets and sets a field from/to an flist
 
PIN_FLIST_COPY - This macro can be used to copy field from one flist to other. Instead of doing PIN_FLIST_FLD_GET and then PIN_FLIST_FLD_SET, directly PIN_FLIST_COPY can be used.

3. Error Management and Logging Macros (All the logging of information is done in the file cm.pinlog which the main log to track and troubleshoot any issue while executing an opcode)

PIN_ERR_LOG_MSG – This macro sets a string message to troubleshoot issue in the opcode. This really helps to identify the location of the file where the error is occurring.
PIN_ERR_LOG_FLIST – This macro is to print flist in the log file (cm.pinlog). This is to debug the data which is being set in the flist.
PIN_ERR_IS_ERR – This is to check if the program has encountered an error.
PIN_ERR_SET_ERR – If error is encountered this opcode sets the error with proper error message logging.

4. POID/FLIST Creation Macros (POID/Flist needs to be created in order to generate the input data for the opcode)
PIN_POID_CREATE, PIN_FLIST_CREATE – As name suggests these macros helps in creation of poid and flist objects.
Note – After the execution of the opcode, the newly created flist objects must be destroyed in order to free unused memory space. If they are not killed it may lead to memory leak issues. PIN_FLIST_DESTROY_EX is the macro to delete the data of an flist and set the reference of the flist object to null.
 
5. There are different set of macros for decimal data type manipulations. For example for decimal addition operation there is a macro "pbo_decimal_add_assign" , other decimal macros are starting with pbo_decimal*.