Issues and Workarounds for Installation, Upgrade, and Documentation

These issues and workarounds are for specific areas, such as installation, upgrade, security, and documentation.

Installation

This applies to issues regarding installing Oracle BI Applications.

WLS Patching Fails to Unzip SUWRAPPER in the Applicable Location

This issue applies to the Fusion Middleware Platform Patches.

During installation of Oracle BI Applications Release 11.1.1.10.1, and while applying the Fusion Middleware Platform Patches using the 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.

Unable to Detect Machine Platform or JVM Bits

This issue applies to Oracle BI Applications installation.

When installing Oracle BI Applications, do not install WLS1036 on Windows with NFS JDK Path; instead use a local JDK location. If you use NFS JDK path, then during Oracle BI Applications configuration, the following error appears: 
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.

Upgrade

These issues involve upgrading Oracle BI Applications.

Change in PROJECT_RESOURCE_TYPE Domain Format

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.

The domain member codes for 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.

Domain Member Mapping Fails for W_TIMECARD_UOM_CODE for the Upgrade Load Plan

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.

This error occurs when you run the PSFT Upgrade Load plan(s):

  • Upgrade BIApps 111192 to 1111101 PSFT 90 HCM

  • Upgrade BIApps 111192 to 1111101 PSFT 91 HCM

  • Upgrade BIApps 111192 to 1111101 PSFT 92 HCM

The effect of this is that the W_UOM_CODE column value becomes __ERROR__ on the following key T&L tables:  

  • 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

  1. Run the task standalone.

    1. Open the Oracle Data Integrator (ODI) client.

    2. Select Projects, BI Apps Project, Mappings, SILOS, SIL_DomainGeneral_DomainMaps, Packages, then Scenarios.

    3. Right click the Scenario, SILOS_SIL_DOMAINGENERAL_DOMAINMAPS , then execute.

    4. Click OK on the Variable Values pop-up window.

    5. Execute the Upgrade Load Plan as usual.

  2. Edit the seeded Upgrade Load Plan here in ODI.

    1. Select Predefined Load Plans, then Upgrade.

    2. 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

    3. Restart from the failed step, then Save.

    4. 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__');

Fix Required for Upgrade Load Plans for JD Edwards and E-Business Suite When Upgrading from Release 7.1 to 8.1

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.

The required fix is determined by if you are running a single-source upgrade or a multi-source upgrade. Affects the following upgrade load plans:

  • 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.

  1. Backup W_ETL_LOAD_DATES.

    CREATE TABLE W_ETL_LOAD_DATES_BKUPG AS SELECT * FROM W_ETL_LOAD_DATES;

  2. 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';

  3. 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.

  4. Restart the failed increment load plan and continue your ETL.

Fix Required When Running JD Edwards Incremental Load Plans When Upgrading from Release 7.1 to 8.1

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.

Applies to:

  • Upgrade BIApps 111171 to 111180 JDE 90

  • Upgrade BIApps 111171 to 111180 JDE 91

  1. Apply this fix at first issue. 
    DELETE FROM W_OM_REASON_DS A
WHERE ROWID > (SELECT MIN(ROWID) FROM W_OM_REASON_DS B
WHERE A.INTEGRATION_ID  = B.INTEGRATION_ID
AND A.DATASOURCE_NUM_ID = B.DATASOURCE_NUM_ID );
COMMIT;
  2. Restart failed upgrade load plan to continue the upgrade.

Generate SDS DDL Fails in Fusion Applications HCM Load Plan After Upgrade

An error occurs after upgrade when running a load plan for Fusion Applications HCM after upgrade when attempting to generate the SDS DDL.

An error occurs when running this procedure. Perform the workaround. 
 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 
 )
  1. Log in to SDS schema.
  2. Execute these scripts: 
    CREATE TABLE <SDS_SCHEMA_NAME>.HCM_CO_SALARYPVO813153_BKP AS 
SELECT * from <SDS_SCHEMA_NAME>.HCM_CO_SALARYPVO813153;  
TRUNCATE  TABLE  <SDS_SCHEMA_NAME>.HCM_CO_SALARYPVO813153;  
ALTER TABLE <SDS_SCHEMA_NAME>.HCM_CO_SALARYPVO813153 MODIFY (SALARYPEOACTIONOCCURRENCEID VARCHAR2(18 CHAR)); 

    INSERT INTO <SDS_SCHEMA_NAME>.HCM_CO_SALARYPVO813153 
(SALARYPEOSALARYBASISID ,       
SALARYPEOSALARYAPPROVED,       
SALARYPEOSALARYAMOUNT,         
SALARYPEOLASTUPDATEDBY,         
SALARYPEOLASTUPDATEDATE,       
SALARYPEODATETO ,               
SALARYPEODATEFROM  ,           
SALARYPEOCREATIONDATE ,         
SALARYPEOCREATEDBY  ,           
SALARYPEOBUSINESSGROUPID ,     
SALARYPEOASSIGNMENTID,         
SALARYPEOACTIONOCCURRENCEID, 
SALARYID    ,                   
SALARYBASESPEOSALARYBASISCODE , 
SLRYBSSPSLRYNNLZTNFCT774832679, 
SALARYBASESPEOGRADERATEID ,     
SALARYBASESPEOELEMENTTYPEID,   
SALARYBASESPEOLASTUPDATEDATE , 
ASSIGNMENTPEOEFFECTIVEENDDATE , 
SSGNMNTPFFCTVLTSTCHNG546539429, 
ASSIGNMENTPEOEFFECTIVESEQUENCE, 
SSGNMNTPFFCTVSTRTDT829875410,   
CDC$_SRC_LAST_UPDATE_DATE ,     
CDC$_RPL_LAST_UPDATE_DATE ,     
CDC$_DML_CODE  )  

SELECT SALARYPEOSALARYBASISID ,       
SALARYPEOSALARYAPPROVED,       
SALARYPEOSALARYAMOUNT,         
SALARYPEOLASTUPDATEDBY,         
SALARYPEOLASTUPDATEDATE,       
SALARYPEODATETO ,               
SALARYPEODATEFROM  ,           
SALARYPEOCREATIONDATE ,         
SALARYPEOCREATEDBY  ,           
SALARYPEOBUSINESSGROUPID ,     
SALARYPEOASSIGNMENTID,         
TO_CHAR(SALARYPEOACTIONOCCURRENCEID),   
SALARYID    ,                   
SALARYBASESPEOSALARYBASISCODE , 
SLRYBSSPSLRYNNLZTNFCT774832679, 
SALARYBASESPEOGRADERATEID ,     
SALARYBASESPEOELEMENTTYPEID,   
SALARYBASESPEOLASTUPDATEDATE , 
ASSIGNMENTPEOEFFECTIVEENDDATE , 
SSGNMNTPFFCTVLTSTCHNG546539429, 
ASSIGNMENTPEOEFFECTIVESEQUENCE, 
SSGNMNTPFFCTVSTRTDT829875410,   
CDC$_SRC_LAST_UPDATE_DATE ,     
CDC$_RPL_LAST_UPDATE_DATE ,     
CDC$_DML_CODE   
FROM <SDS_SCHEMA_NAME>.HCM_CO_SALARYPVO813153_BKP;
  3. Resubmit the Load Plan after marking the failed step as complete.

Must Disable PAYGRADE_DIM When Upgrading Load Plan for Fusion Applications HCM

Disable PAYGRADE_DIM when upgrading the predefined load plan for Fusion Applications HCM named Upgrade BIApps 111192 to 1111101 FUSION 9.

  1. Open the ODI client.
  2. Select Load Plans and Scenarios.
  3. Select Upgrade, then Upgrade BIApps 111192 to 1111101 FUSION 9.
  4. Go to the steps, then expand UPGRADE_DIMENSIONS, When Value = Y, HCM, SDE, then PAYGRADE_DIM.
  5. Add a Scenario Step (Restart from failed step).

    • Scenario: EXEC_TABLE_MAINT_PROC

    • Version: -1

    • Name: EXEC_TABLE_MAINT_PROC - BEFORE

    Select the new step in the Property inspector Scenario Variables, then overwrite with: 
    BIAPPS.DDL_TABLE_LIST: W_PAY_GRADE_DS,W_FSN_PER_GRADES_F_TMP
BIAPPS.DDL_RUN_MODE: AFTER
  6. Add a Scenario Step (Restart from failed step).

    • Scenario: EXEC_TABLE_MAINT_PROC

    • Version: -1

    • Name: EXEC_TABLE_MAINT_PROC - AFTER

    Select the new step in the Property inspector Scenario Variables, then overwrite with: 
    BIAPPS.DDL_TABLE_LIST: W_FSN_PER_GRADES_F_TMP
BIAPPS.DDL_RUN_MODE: AFTER
  7. Add a Scenario Step (Restart from failed step).

    • Scenario: EXEC_TABLE_MAINT_PROC

    • Version: -1

    • Name: EXEC_TABLE_MAINT_PROC - AFTER

    Select the new step in the Property inspector Scenario Variables, then overwrite with: 
    BIAPPS.DDL_TABLE_LIST: W_PAY_GRADE_DS
BIAPPS.DDL_RUN_MODE: AFTER
  8. Save the changes.

Inconsistent WORKER_TYPE_SYSTEM~WORKER_TYPE_USER Domain in E-Business Suite

This issue applies to all E-Business Suite adaptors.

EBS customers must perform these manual steps after running the upgrade load plan from 11.1.1.9.2 to 11.1.1.10.1:
  1. After the upgrade load plan run, go to Configuration Managerand map the source domain to warehouse domain for WORKER_TYPE_SYSTEM~WORKER_TYPE_USER.using the Manage Domains and Mappings dialog.
  2. After mapping the source to target domain, run the following scripts against the warehouse schema so that the impacted tables would be run in full mode during the next incremental run: 
    UPDATE w_etl_load_Dates SET COMMITTED=0 where TARGET_TABLE_NAME LIKE 'W_WRKFC_EVT_%F%'; 
UPDATE w_etl_load_Dates SET COMMITTED=0 where TARGET_TABLE_NAME LIKE '%EMPLOYMENT_D%';

W_Status_Code Populating With Error

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.
  1. After the UPGRADE9.2 to 10.1 load completes and before running the next incremental load, run the following SQL script: 
    UPDATE W_ETL_LOAD_DATES SET COMMITTED=0 WHERE TARGET_TABLE_NAME='W_STATUS_DS'. 
AND PACKAGE_NAME LIKE 'SDE_%_STATUSDIMENSION_FINAPAPPROVALSTATUS';  
COMMIT;  
UPDATE W_ETL_LOAD_DATES SET COMMITTED=0 WHERE TARGET_TABLE_NAME='W_STATUS_DS'. 
AND PACKAGE_NAME LIKE 'SDE_%_STATUSDIMENSION_FINAPVALIDATIONSTATUS';  
COMMIT;
  2. After the incremental load completes, verify the W_STATUS_CODE data using the following query: 
    SELECT * FROM W_STATUS_D WHERE W_STATUS_CLASS IN  
('FIN_AP_APPR_STATUS','FIN_AP_VALD_STATUS');

    Note:

    Records for 'FIN_AP_VALD_STATUS' will not be available for EBS11510, PSFTxx, and JDExx sources.
  3. If still '__ERROR__' is seen, then run the following SQL script: 
    UPDATE W_STATUS_D SET W_STATUS_CODE=(SELECT DS.W_STATUS_CODE FROM W_STATUS_DS  
DS WHERE W_STATUS_D.INTEGRATION_ID=DS.INTEGRATION_ID AND  
W_STATUS_D.W_STATUS_CLASS IN ('FIN_AP_APPR_STATUS','FIN_AP_VALD_STATUS')); 
COMMIT;
  4. Verify the data.

SDE_ORA_ProductTransactionFact_Delete_UPG Package Fails in Upgrade BIApps 111192 to 1111101 EBS 1213 Load Plan

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.

The 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.
  1. Open the ODI Studio and log in to the ODI Master Repository using a developer account.
  2. Click View, click ODI Designer Navigator to go to the Designer tab. Expand BI Apps Project by clicking Mappings.
  3. Scroll down to the Upgrade folder and open the relevant subfolder as follows:
    Data Source EBS Release Upgrade Mapping Folder Name
    EBS R12 SDE_ORAR12_11.1.1.9.2_to_11.1.1.10.1_Upgrade
    EBS R12.1.1 SDE_ORAR1211_11.1.1.9.2_to_11.1.1.10.1_Upgrade
    EBS R12.1.2 SDE_ORAR1212_11.1.1.9.2_to_11.1.1.10.1_Upgrade
    EBS R12.1.3 SDE_ORAR1213_11.1.1.9.2_to_11.1.1.10.1_Upgrade
    EBS R12.2 SDE_ORAR122_11.1.1.9.2_to_11.1.1.10.1_Upgrade
  4. Expand the SDE_ORA_ProductLotTransactionFact_Delete_UPG package.
  5. Edit the SDE_ORA_ProductLotTransactionFact_Delete_UPG.W_PRODUCT_LOT_XACT_F interface.
  6. Select the Key check box for target columns DATASOURCE_NUM_ID and INTEGRATION_ID.
  7. Click Target Datastore Header and set the Update Key drop-down to <Undefined> .
  8. Save the mapping and regenerate the scenario.

E-Business Upgrade Load Plan Fails With No Value For BIAPPS.DDL_RUN_MODE Variable

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.

The EBS Upgrade load plan is failing with no value for 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.
  1. Open ODI Studio and log in to the ODI Master Repository using a developer account.
  2. On Designer tab (View > ODI Designer Navigator), expand Designer Navigator subtab Load Plans and Scenarios.
  3. Scroll down to the Predefined Load Plans folder and double-click the load plan Upgrade BIApps 111192 to 1111101 EBS 1213.
  4. Click on Steps tab in the Left Navigation bar and expand UPGRADE_GENERAL > UPGRADE_ITEM_COST > SDE.
  5. Click on Step EXEC_TABLE_MAINT_PROC_AFTER
  6. Set AFTER as the value for BIAPPS.DDL_RUN_MODE variable.
  7. Save and exit.

E-Business Upgrade Load Plan Fails With Table Model Not Returning Any Rows

This issue applies to Oracle E-Business release 12.1.3 users.

The table maintenance procedure called before and after in the upgrade load plan is passing incorrect table name  W_MFG_JOB_DAILY_SNP_F in DDL_TABLE_LIST parameters.

Workaround

  1. Open ODI Studio and log in to the ODI Master Repository using a developer account.
  2. On Designer tab (View > ODI Designer Navigator), expand Designer Navigator subtab Load Plans and Scenarios.
  3. Expand the Upgrade Load Plan folder and expand the UPGRADE_FACTS step.
  4. Expand the Is MFG enabled step.
  5. Navigate to the SIL step and expand the MFG_SRC step.
  6. Correct the DDL_TABLE_LIST parameter value under the EXEC_TABLE_MAINT_PROC_BEFORE step to W_MFG_JOB_DETAIL_SNP_F instead of W_MFG_JOB_DAILY_SNP_F.
  7. Expand the PLP step and correct the DDL_TABLE_LIST parameter value under the EXEC_TABLE_MAINT_PROC_AFTER step to W_MFG_JOB_DETAIL_SNP_F instead of W_MFG_JOB_DAILY_SNP_F.
  8. Save the load plan.

Create Unique Index Error in PeopleSoft HCM Upgrade Load Plan

This issue applies to PeopleSoft load plans for Human Capital Management.

Duplicate records inserted to workforce event fact 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

  1. Go to Load Plan definition, open steps, and navigate to UPGRADE_FACTS > Is HCM enabled > When Value = Y > HCM > SIL > WRKFRCEVT_FG
  2. Select the step EXEC_TABLE_MAINT_PROC - DROP ALL and rename it to EXEC_TABLE_MAINT_PROC - BEFORE
  3. Under the Scenario Variable section, modify the Value for BIAPPS.DDL_RUN_MODE from DROP_ALL to BEFORE.
  4. Go to load plan definition, navigate to Reset History Tracking Table > Reset - HCM - Warehouse.
  5. Under Scenario Variable list for BIAPPS.DDL_TABLE_LIST, correct the table name for 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.

Importing View Object to Physical and Logical Layers

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.

  1. Stop BI Services and open RPD.
  2. In the Physical Layer of the RPD, right click Connection Pool under oracle.apps.fscm.model.analytics.applicationModule.FscmTopModelAM_FscmTopModelAMLocal.
  3. Click Import Metadata.
  4. In the Import Metadata — Select Metadata Objects dialog, enter ReturnReason in the Find field and click Search icon.
  5. Select FscmTopModelAM.DooTopAM.ReturnReason in the Data Source View pane, select oracle.apps.fscm.model.analytics.applicationModule.FscmTopModelAM_FscmTopModelAMLocal in the Repository View pane, and click the Import Selected icon.
  6. Click Finish when import is complete.
  7. The previous steps were for the Physical Layer. Now add RefreshNumber attribute from the VO to the Z - VO OBIA ETL Logical Table in BMM Layer. Select the attribute, drag and drop it in to the Z - VO OBIA ETL logical table.
  8. Save and close the RPD.
  9. Restart the BI Services.

SDE_FUSION_TALENTMGMT_REQUIREMENTSFACT Fails In Fusion Direct Upgrade

This issue applies to Fusion Direct upgrade.

Upgrade BIApps 111192 to 1111101 FUSION 9 upgrade load plan fails with the following error: 
error ORA-00001:unique constraint violated for Unique Constraints named W_TLNT_PRFL_RQRMNT_FS_U1 and W_TLNT_PRFL_ACHVMNT_FS_U1

Workaround

  1. Log in to Datawarehouse database schema.
  2. Truncate W_TLNT_PRFL_RQRMNT_FS and W_TLNT_PRFL_ACHVMNT_FS tables.
  3. Resubmit the load plan for execution.

Upgrading Fusion V1 Adaptor ODI Artifacts to Use Fusion 9 Adaptor

This issue applies to Fusion V1 adaptor ODI artifacts.

When upgrading Fusion V1 Adaptor ODI artifacts to use Fusion 9 Adaptor, the upgrade process from 11.1.1.9.2 to 11.1.1.10.1 as described in Oracle Business Intelligence Applications Upgrade Guide will not upgrade customization done on Fusion V1 Adaptor in Release 11.1.1.9.2 ODI repository.

Workaround

Redo your customization after successfully upgrading to Oracle BI Applications release 11.1.1.10.1.

Character Data Getting Trimmed While Using Cloud Adaptor During ODI Repository Upgrade

This issue applies to the Cloud adaptor FTS tasks execution process during the ODI repository upgrade.

While using Cloud Adaptor, Source data containing spaces in character data at the end of the string might get trimmed. This can in turn cause duplicate records to get created. As an example, assume Source Data has two primary key values as 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:

  1. Connect to the 11.1.1.10.1 ODI Repository schema using Oracle data base client tools such as SQL plus or SQL Developer.
  2. Run the following script: 
    /* Script Begins */ 

UPDATE SNP_MTXT MT SET MT.FULL_TXT='jdbc:snps:dbfile?ENCODING=UTF-8'||'&'||'NO_RTRIM_DEL_STRING=true' WHERE MT.I_TXT IN  (SELECT MT1.I_TXT FROM SNP_CONNECT CN INNER JOIN SNP_MTXT MT1 ON 
MT1.I_TXT=CN.I_TXT_JAVA_URL AND CN.JAVA_DRIVER='com.sunopsis.jdbc.driver.file.FileDriver' INNER JOIN SNP_TECHNO TH ON CN.I_TECHNO=TH.I_TECHNO AND TH.TECH_INT_NAME='FILE'); 
COMMIT;

/* Script Ends */
This SQL script updates all existing file physical connections to have this property set. For example, the JDBC URL before the update statement is 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:

Whenever you add a new file data server, you must ensure that you run the mentioned script or manually add the 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.

Documentation Corrections

This information provides corrections and additions for documentation and Help for Oracle BI Applications.

General Documentation Issues

There are currently no documentation errors.