To check the latest patch installed on Oracle BRM:
Infranet: Type 'pinrev' or check pinrev.dat
Pipeline: Check 'version.info.txt' in $IFW_HOME
To be sure that these files are current, the patches must be installed using the installer. These files might not get properly updated if, for example, instead of running the installer, you extract the new files from the tar file and then just plunk them in their respective directories.
Thursday, January 8, 2009
Migrating IPL files
The following are common causes of IPL files throwing errors when committing them in production after taking them from a test/integration environment:
- The resources and GL/IDs used by products and discount rules in the IPL file does not exist in production.
- The discounts mentioned in the deals are not included in the IPL file to be committed.
- The service used by the products in the IPL does not exist in production.
Failover CM hosts in Java apps
To make sure that your Java application only connects to one CM server, take out the failover entry in the Infranet.properties file.
This has caused a lot of grief with a colleague because he was canceling products thinking he was connected to a test environment but was actually connected to production. The test environment was down and he had a failover entry for the production environment in his properties file.
To avoid this situation, better comment this entry (Infranet.failover.nn) out.
This has caused a lot of grief with a colleague because he was canceling products thinking he was connected to a test environment but was actually connected to production. The test environment was down and he had a failover entry for the production environment in his properties file.
To avoid this situation, better comment this entry (Infranet.failover.nn) out.
Monday, September 29, 2008
Internet in OpenSolaris and VirtualBox combo
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!
After googling, I restarted the virtual machine and now I am making this entry inside OpenSolaris/VirtualBox. Cool!
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.
Subscribe to:
Posts (Atom)