When a CSR tried to display the Plans of the customer in Customer Center, the Plans tab will just display a blank pane. When CM pinlog is checked, the following error showed up:
map_poid_to_table_info("product_t", 5402881) failed, err 4
The strange thing is that the ID in the error above is not the ID of a product, rather it is the ID of a deal in the database.
I asked about the history of BRM in the company regarding products/deals in the database and was told that somebody deleted plans,deals and the account's purchased products in the database a while back. A solution was already implemented to recreate those plans,deals and purchased products, but there were still some related issues cropping up and this was one of them.
The table account_products_t was examined for the accounts that were reported to not display the plans. There were objects in that table that has blank values for the following fields: plan_type and deal_type . This should not be an issue if the plan/deal ID is 0, however, the plan/deal IDs for the records were valid.
The fix was to populate the blank fields. For example, a record has valid deal/plan IDs but blank deal/plan type. These blank fields were just inserted with the values: '/plan' for missing plan type and '/deal' for missing deal type. The plans were now able to display in the Customer Center.
Wednesday, August 27, 2008
Issues in extending custom service
An existing custom class /service/dsl was to be extended with the new class /service/dsl/new as part of a promotion to be offered to customers. Using Developer Center SCE, the tool did not complain when the new class was committed and a price plan was even committed(that is, using Pricing Center) using this new service. However, when CM/DM is restarted, and Developer Center restarted, the new service inexplicably disappeared from SCE.
The pin_deploy utility was tried to create this new service, but pin_deploy threw an error and the DM pinlog showed the following: " sdo_create_new_tti:no parent for /au_service/dsl/new".
Just to verify the process, a totally new service was created and extended using SCE, and the services were created without errors. After checking out the objects that were created, I found out that BRM creates two objects for each new service class, one as /service and another one as /au_service. For example, if /service/local is created, the objects that are created in the database are /service/local and /au_service/local.
The existing custom service class /service/dsl was examined and found out that it does not have its corresponding /au_service object. The other custom service classes don't have their corresponding /au_service objects as well and threw a similar error when extended. The standard services that comes with BRM has their /au_service objects however, and can be extended.
To resolve this issue, a /au_service/dsl object was inserted into the database with the POID value being the increment of the /service/dsl object POID and all other fields remain identical. After this was done, the new service was able to commit to the database without errors, either using SCE or pin_deploy.
Now, the question is "How come those objects were missing if BRM was supposed to create them automatically whenever a new service class is created?"
The answer is: Who knows?!? The solution is there and the problem seems to be in no danger of repeating itself. :) Although most probably it was caused by enabling/disabling audit trails.
The pin_deploy utility was tried to create this new service, but pin_deploy threw an error and the DM pinlog showed the following: " sdo_create_new_tti:no parent for /au_service/dsl/new".
Just to verify the process, a totally new service was created and extended using SCE, and the services were created without errors. After checking out the objects that were created, I found out that BRM creates two objects for each new service class, one as /service and another one as /au_service. For example, if /service/local is created, the objects that are created in the database are /service/local and /au_service/local.
The existing custom service class /service/dsl was examined and found out that it does not have its corresponding /au_service object. The other custom service classes don't have their corresponding /au_service objects as well and threw a similar error when extended. The standard services that comes with BRM has their /au_service objects however, and can be extended.
To resolve this issue, a /au_service/dsl object was inserted into the database with the POID value being the increment of the /service/dsl object POID and all other fields remain identical. After this was done, the new service was able to commit to the database without errors, either using SCE or pin_deploy.
Now, the question is "How come those objects were missing if BRM was supposed to create them automatically whenever a new service class is created?"
The answer is: Who knows?!? The solution is there and the problem seems to be in no danger of repeating itself. :) Although most probably it was caused by enabling/disabling audit trails.
Wednesday, August 20, 2008
Create a new PCM user
Create a user/customer(regular) in Customer Center. For this user, purchase a plan that has PCM_CLIENT and/or ADMIN_CLIENT as services.
If the plan does not exist, create a plan with the abovementioned services.
To test if the new user works:
1. Connect to BRM with either any of the front-end applications like Customer Center,Developer Center.
2. Connect using testnap. If you want to use this username in an application, edit the application's login/password entries in the pin.conf/Infranet.properties file to the values you set for the account you just created. If you only want to test if the username works, copy pin.conf in $PIN_HOME/sys/test and put it in a temporary directory. Then, set the entries for login name and password in the pin.conf to the values you specified for the account you just created. Then connect to testnap.
This might be useful when you have an application that you want to monitor in the CM pinlog file.
If the plan does not exist, create a plan with the abovementioned services.
To test if the new user works:
1. Connect to BRM with either any of the front-end applications like Customer Center,Developer Center.
2. Connect using testnap. If you want to use this username in an application, edit the application's login/password entries in the pin.conf/Infranet.properties file to the values you set for the account you just created. If you only want to test if the username works, copy pin.conf in $PIN_HOME/sys/test and put it in a temporary directory. Then, set the entries for login name and password in the pin.conf to the values you specified for the account you just created. Then connect to testnap.
This might be useful when you have an application that you want to monitor in the CM pinlog file.
ERR_BASIC_RATEPLAN error
The company just offered a new plan to customers and a new rateplan was created for this offer. However, after the plan was saved and the pipeline restarted, the pipeline crashed and has the following error in its log: ERR_BASIC_RATEPLAN
It turned out that the 'Basic' checkbox shows up as checked when you first open the Pricing Center Pipeline Toolbox. As it is checked, you tend to leave it as it is. But if you check in the database, it is not set. This could be a bug in the Pricing Center interface that has something to do with the locale as some of the other guys do not have this problem.
To verify if 'Basic' is set in the database, check the ifw_rateplan table given the rateplan name. Then, with the result of this query, check ifw_rateplan_ver and look at the 'Basic' field. It should be set to 1. If it is not set to 1, then open the pipeline toolbox and modify the created rateplan. Manually check/uncheck/check the checkbox and save the changes. Verify the result in the database. The pipeline should come up now.
It turned out that the 'Basic' checkbox shows up as checked when you first open the Pricing Center Pipeline Toolbox. As it is checked, you tend to leave it as it is. But if you check in the database, it is not set. This could be a bug in the Pricing Center interface that has something to do with the locale as some of the other guys do not have this problem.
To verify if 'Basic' is set in the database, check the ifw_rateplan table given the rateplan name. Then, with the result of this query, check ifw_rateplan_ver and look at the 'Basic' field. It should be set to 1. If it is not set to 1, then open the pipeline toolbox and modify the created rateplan. Manually check/uncheck/check the checkbox and save the changes. Verify the result in the database. The pipeline should come up now.
Subscribe to:
Posts (Atom)