These issues and workarounds are for specific areas, such as installation, upgrade, security, and documentation.
This applies to issues regarding installing Oracle BI Applications.
This issue applies to the Fusion Middleware Platform Patches.
APPLY_PATCHES.pl
script, WebLogic patch (BUNQ) fails to apply and displays the unzip suwrapper in the location error. If you run into this issue while performing the patch application procedure, then you can manually apply the patch.Workaround
To manually apply Weblogic patches, refer to Applying the Fusion Middleware Platform Patch, Oracle Business Intelligence Applications Installation Guide.
This issue applies to Oracle BI Applications installation.
Unable to detect machine platform or JVM bits.
Workaround
If you install the WLS by JDK from NFS, then replace all NFS JDK locations to local JDK location in the following two files:
C:\work\biapps10.1dw\biappsmw1\wlserver_10.3\.product.properties C:\work\biapps10.1dw\biappsmw1\wlserver_10.3\common\bin\commEnv.cmd
Find all JDK path like \\adcnas418\farm_fmwqa\java\win64\jdk6
and replace them to path like c:\work\jdk
.
These issues involve upgrading Oracle BI Applications.
This issue applies to Project Analytics customers who are using E-Business (any release) OLTP and are upgrading from Oracle BI Applications 11.1.1.9.2 to 11.1.1.10.1.
PROJECT_RESOURCE_TYPE
domain is sourced through two different maps. This can potentially result in duplicates. To overcome this issue, prefixes to the domain member codes have been appended.Workaround
After running the E-Business upgrade load plan, revisit Oracle BI Applications Configuration Manager (BIACM) and redo the target and source domain mapping between W_PROJECT_RESOURCE_TYPE
and PROJECT_RESOURCE_TYPE
domain members.
Anew domain member mapping TIMECARD_TRC_TYPE_CODE~TIMECARD_TRC_UOM_CODE to 'W_TIMECARD_UOM_CODE was not loaded from the Configuration Manager seed data into the data warehouse table W_DOMAIN_MEMBER_MAP_G within the Upgrade load plan.
Upgrade BIApps 111192 to 1111101 PSFT 90 HCM
Upgrade BIApps 111192 to 1111101 PSFT 91 HCM
Upgrade BIApps 111192 to 1111101 PSFT 92 HCM
W_TLB_ENTRY_TYPE_D
W_TLB_RPTD_F
W_TLB_PRCSD_F
Follow the steps in the appropriate procedure depending on if you have already run the upgrade load plan.
If You Have Not Yet Run the Upgrade Load Plan
Run the task standalone.
Open the Oracle Data Integrator (ODI) client.
Select Projects, BI Apps Project, Mappings, SILOS, SIL_DomainGeneral_DomainMaps, Packages, then Scenarios.
Right click the Scenario, SILOS_SIL_DOMAINGENERAL_DOMAINMAPS , then execute.
Click OK on the Variable Values pop-up window.
Execute the Upgrade Load Plan as usual.
Edit the seeded Upgrade Load Plan here in ODI.
Select one of the upgrade load plans:
Upgrade BIApps 111192 to 1111101 PSFT 90 HCM
Upgrade BIApps 111192 to 1111101 PSFT 91 HCM
Upgrade BIApps 111192 to 1111101 PSFT 92 HCM
In the step UPGRADE_GENERAL, add a Run Scenario step.
Scenario Name: SILOS_SIL_DOMAINGENERAL_DOMAINMAPS
Version: -1
Step Name: SILOS_SIL_DOMAINGENERAL_DOMAINMAPS
Execute the Upgrade Load Plan as usual.
If You Have Already Run the Upgrade Load Plan
Run the following SQL against the data warehouse schema to correct the affected data.
-- update dimension update w_tlb_entry_type_d u set w_uom_code = 'HOURS' where uom_code like 'H~%'; update w_tlb_entry_type_d u set w_uom_code = 'AMOUNT' where uom_code like 'A~%'; -- Reported Time fact update w_tlb_rptd_f u set rptd_calc_amt = (select rptd_calc_amt from w0tlb_rptd_f f where u.integration_id = f.integration_id) where rptd_calc_amt is NULL and uom_code like 'A~%' update w_tlb_rptd_f u set w_uom_code = 'HOURS' where uom_code like 'H~%' and (w_uom_code IS NULL OR w_uom_code = '__ERROR__'); update w_tlb_rptd_f u set w_uom_code = 'AMOUNT' where uom_code like 'A~%' and (w_uom_code IS NULL OR w_uom_code = '__ERROR__'); -- Processed Time fact update w_tlb_prcsd_f u set prcsd_calc_amt = (select prcsd_calc_amt from w0tlb_prcsd_f f where u.integration_id = f.integration_id) where prcsd_calc_amt is NULL and uom_code like 'A~%'; update w_tlb_prcsd_f u set w_uom_code = 'HOURS' where uom_code like 'H~%' and (w_uom_code IS NULL OR w_uom_code = '__ERROR__'); update w_tlb_prcsd_f u set w_uom_code = 'AMOUNT' where uom_code like 'A~%' and (w_uom_code IS NULL OR w_uom_code = '__ERROR__');
After upgrading from Oracle BI Applications Order Management release 7.1 to release 8.1, incremental loads fails at SIL_OMReasonDimension_SalesOrderReturn task until upgrade load plans are updated.
Upgrade BIApps 111171 to 111180 EBS 11510
Upgrade BIApps 111171 to 111180 EBS 120
Upgrade BIApps 111171 to 111180 EBS 1211
Upgrade BIApps 111171 to 111180 EBS 1212
Upgrade BIApps 111171 to 111180 EBS 1213
Upgrade BIApps 111171 to 111180 JDE 90
Upgrade BIApps 111171 to 111180 JDE 91
If Running a Single-Source Upgrade
The affected ETL task SILOS_SIL_OMREASONDIMENSION_SALESORDERRETURN fails but no data is impacted. At the first issue, run this SQL to correct the wrong datasource number in W_ETL_LOAD_DATES, then restart the failed incremental load plan in release 8.1.
UPDATE W_ETL_LOAD_DATES SET DATASOURCE_NUM_ID=999 WHERE PACKAGE_NAME='SILOS_SIL_OMREASONDIMENSION_SALESORDERRETURN'; COMMIT;
If Running a Multi-Source Upgrade
Apply the fix in all upgrade load plans, then follow the steps to correct the wrong DSN in W_ETL_LOAD_DATES, then restart the failed incremental load plan in release 8.1.
Backup W_ETL_LOAD_DATES.
CREATE TABLE W_ETL_LOAD_DATES_BKUPG AS SELECT * FROM W_ETL_LOAD_DATES;
Run the SQL to determine number of records regarding mapping SILOS_SIL_OMREASONDIMENSION_SALESORDERRETURN.
SELECT * FROM W_ETL_LOAD_DATES WHERE PACKAGE_NAME='SILOS_SIL_OMREASONDIMENSION_SALESORDERRETURN';
Correct the DSN in W_ETL_LOAD_DATES. Assuming there are four records returned in step 2, whose datasource numbers are 310,320,410,415, then issue the SQL to delete three of them and only keep one, per this example SQL.
DELETE FROM W_ETL_LOAD_DATES WHERE PACKAGE_NAME='SILOS_SIL_OMREASONDIMENSION_SALESORDERRETURN' AND DATASOURCE_NUM_ID IN (310,410,415); COMMIT; UPDATE W_ETL_LOAD_DATES SET DATASOURCE_NUM_ID=999 WHERE PACKAGE_NAME='SILOS_SIL_OMREASONDIMENSION_SALESORDERRETURN' AND DATASOURCE_NUM_ID=320; COMMIT;
Note:
Be sure to use the correct datasource number values in the WHERE clause for DATASOURCE_NUM_ID IN() and DATASOURCE_NUM_ID.Restart the failed increment load plan and continue your ETL.
Incremental load fails at task SIL_OMReasonDimension_SalesOrderReturn and ETL is not able to continue until the failure is corrected. This issue might happen when running a single-source upgrade multiple times, which causes duplicate records in W_OM_REASON_DS.
Upgrade BIApps 111171 to 111180 JDE 90
Upgrade BIApps 111171 to 111180 JDE 91
An error occurs after upgrade when running a load plan for Fusion Applications HCM after upgrade when attempting to generate the SDS DDL.
Error running ALTER TABLE FUSION_SDS.HCM_CO_SALARYPVO813153 MODIFY (SALARYPEOACTIONOCCURRENCEID VARCHAR2(18 CHAR)) (<type 'java.sql.SQLException'> - java.sql.SQLException: ORA-01439: column to be modified must be empty to change datatype )
Disable PAYGRADE_DIM when upgrading the predefined load plan for Fusion Applications HCM named Upgrade BIApps 111192 to 1111101 FUSION 9.
This issue applies to all E-Business Suite adaptors.
This issue applies to warehouse status codes populating with error instead of valid codes for Fusion, E-Business, PeopleSoft, and JD Edwards releases.
W_STATUS_D.W_STATUS_CODE
is populated as '__ERROR__'
after upgrade from release 11.1.1.9.2 to 11.1.1.10.1 for W_STATUS_CLASS
in FIN_AP_APPR_STATUS
and FIN_AP_VALD_STATUS
.This issue applies to Oracle E-Business (EBS) users using EBS release 12.1.3 applications as a data source along with Supply Chain Management and Manufacturing Oracle BI Applications offerings and upgrading from Oracle BI Applications Release 11.1.1.9.2 to 11.1.1.10.1.
SDE_ORA_ProductTransactionFact_Delete_UPG
package is failing in the Upgrade BIApps 111192 to 1111101 EBS 1213 load plan.Workaround
Note:
Ensure that you have access to the ODI Studio and an account with developer access to be able to patch the mappings.This issue applies to the Oracle E-Business (EBS) customers using EBS release 12.1.3 applications as data source and upgrading from Oracle BI Applications release 11.1.1.9.2 to 11.1.1.10.1.
BIAPPS.DDL_RUN_MODE
variable.Workaround
Note:
Ensure that you have access to ODI Studio and an account with developer access to be able to patch the predefined load plan.This issue applies to Oracle E-Business release 12.1.3 users.
W_MFG_JOB_DAILY_SNP_F
in DDL_TABLE_LIST
parameters.Workaround
This issue applies to PeopleSoft load plans for Human Capital Management.
W_WRKFC_EVT_F
during the following upgrade load plan runs:
Upgrade BIApps 111192 to 1111101 PSFT 90 HCM
Upgrade BIApps 111192 to 1111101 PSFT 91 HCM
Upgrade BIApps 111192 to 1111101 PSFT 92 HCM
UPGRADE_FACTS > Is HCM enabled > When Value = Y > HCM > SIL > WRKFRCEVT_FG
W_WRKFC_EVT_POW_F
fact from W_WRKFC_EVT_F,W_WRKFC_EVT_AGE_F,W_WKFC_EVT_POW_F,W_WRKFC_EVT_MERGE_F,W_WRKFC_EVT_MONTH_F,W_RCRTMNT_RQSTN_A_TMP2,W_RCRTMNT_RQSTN_A
to W_WRKFC_EVT_F,W_WRKFC_EVT_AGE_F,W_WRKFC_EVT_POW_F,W_WRKFC_EVT_MERGE_F,W_WRKFC_EVT_MONTH_F,W_RCRTMNT_RQSTN_A_TMP2,W_RCRTMNT_RQSTN_A
.This issue applies to Fusion Direct (Non SAAS) run.
The full or incremental load after upgrade runs into an error as the FscmTopModelAM.DooTopAM.ReturnReason
view object is missing in the 11.1.1.10.1 RPD.
Workaround
Use these instructions to import the FscmTopModelAM.DooTopAM.ReturnReason
view object in to the physical and logical layers.
This issue applies to Fusion Direct upgrade.
error ORA-00001:unique constraint violated for Unique Constraints named W_TLNT_PRFL_RQRMNT_FS_U1 and W_TLNT_PRFL_ACHVMNT_FS_U1
Workaround
This issue applies to Fusion V1 adaptor ODI artifacts.
Workaround
Redo your customization after successfully upgrading to Oracle BI Applications release 11.1.1.10.1.
This issue applies to the Cloud adaptor FTS tasks execution process during the ODI repository upgrade.
a
and a
. In the source, these are distinct records as the second record has an additional space. However if the space is trimmed, while loading the warehouse, it will result in both records having the same value and hence result in duplicates. Setting a property in the JDBC driver URL for the Physical connection for the files will stop the trimming from happening.Workaround
To resolve the above issue, complete the following steps:
jdbc:snps:dbfile?ENCODING=UTF-8
. Whereas, the JDBC URL after the update statement is jdbc:snps:dbfile?ENCODING=UTF-8&NO_RTRIM_DEL_STRING=TRUE
.
Note:
NO_RTRIM_DEL_STRING=true
property to the file driver URL in the JDBC details dialog of the new connection in ODI. This applies only for File Physical connections and not other types. To verify if your file JDBC connection is fine, do the following:
in ODI Studio’s Topology Tab, click Technologies.
Navigate to File and open the File Physical Data server connection you want to verify.
Click on JDBC tab for that Data Server and verify that the JDBC URL is jdbc:snps:dbfile?ENCODING=UTF-8&NO_RTRIM_DEL_STRING=TRUE
.
If you have applied this setting before performing upgrade of the BI Apps version, then this setting gets carried over to the upgraded repository. If, however, you did not perform this setting before the upgrade, then you must perform this post the upgrade. Otherwise you will notice that the character data is trimmed when using Cloud Adaptor.