Installed VirtualBox 2.0.0 on my Windows Vista SP1 machine, then booted on a live CD image of OpenSolaris inside VirtualBox. In the live CD, OpenSolaris was able to connect to the internet. But after installing it on the virtual hard drive, it showed no internet connection.
After googling, I restarted the virtual machine and now I am making this entry inside OpenSolaris/VirtualBox. Cool!
Monday, September 29, 2008
Tuesday, September 16, 2008
Plans not displaying in Customer Center: Issue 2
Even though most of the accounts reported in Issue 1 were resolved, there were still some accounts that has the same problem. The reasons are varied. The following were some of the reasons that is causing the issue:
- Missing plans - this is caused by somebody deleting deals/plans in the database a while back. Even though most of the plans were recreated in the database, a few plans were not. The error it logs in the DM is: NOTICE OP_ROBJ: do_sql_select() NOTHING FOUND ("/plan", XXXXXXX) where XXXXXXX is the plan poid.
- Missing deals - same reason as above. For the missing plan/deal issue, the workaround was to create the mentioned plan/deal in by inserting a record in the database. This path was chosen because there was already a precedent to this issue i.e. somebody deleted the deals/plans in production and operations decided to just create them manually in the database since they are not offered to customers anymore.
- DM logs say Portal is looking for a plan with POID 0 for a particular account. This one is different from the others. It was confusing considering the object /plan 0 shouldn't have existed in the first place. After checking the logs, it appears that BRM looks at the event_billing_product_action table for the deals/plans when you want to display the plans in CC. Apparently, if the service is still active, BRM will look for the plan object that is in the flist returned by the query to the product action event table. If not active, it will not look for the plan object. For unknown reasons, this account has '/plan 0' in the product action event table and has a valid deal. Since the service associated with the deal/product is still active, BRM attempts to look for this '/plan 0' in the plan table and throws the error when it cannot find it. The two options were either to insert a '/plan 0' in the database or update the event table to reflect the correct plan for the account. By looking at the deal object in the event table, one can deduce the plan to which it belongs. The second option was chosen to be implemented in production.
Wednesday, August 27, 2008
Plans not displaying in Customer Center: Issue 1
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.
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.
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)