DAC Error Message – No Physical folder information found for PLP

Working on a OBI Apps project, I was getting the DAC configurations ready and bumped into the following error message, stating “Error whle calculating build information!”.  The message stated “MESSAGE:::No physical folder information found for PLP”.   This occured when I was trying to build my newly created execution plan.

Solution

I had created a new execution plan and added my subject area(s) but forgot to click the “Generate” button on the Parameters sub-tab after I had selected the subject areas that I wanted built for that particular execution plan.  To fix the error, I just highlighted the newly created execution plan, clicked the Parameters sub-tab and clicked “Generate ”

Read More

DAC - Replace Base: Procedure for Upgrading

10.6.1 Replace Base: High-Level Process Flow

Figure 10–4 shows a high-level process flow for using the Replace Base option to upgrade the DAC Repository when you are phasing out an older release of a transactional application and moving to a newer release.

The term base is used to refer to a source or target container that you have not changed or customized in any way.

Figure 10–4 Upgrade Process for Replace Base Option

 

In Step 1 of the high-level process flow, you import the repository data for the new base container into the repository temporary tables. This repository is referred to as the source in the Upgrade/Merge Wizard

In Step 2, you create a Difference Report that compares the new base container (source repository) with the existing base container (including customizations). The existing base container is referred to as the target

In Step 3, you accept or reject the objects that the Difference Report shows as being present in the source but not the target or changed in the source but not the target. See Section 10.8.3, "Possible Repository Merge Outcomes Based on Your Decisions" for a description of how objects are merged based on the action you take.

In Step 4, after you have resolved the differences, you then execute the merge. In Step

5, the DAC references the customizations in the newly merged repository with the new base container.

Note: The repository data is imported from a file system and should be in the DAC 10.1.3.4 format. If it is in the 7.9.x format, you should do the following:

1. Restore the repository data into a database using the 7.9.x DAC (using the regular DAC import process).

2. Install and configure DAC 10.1.3.4 to the 7.9.x repository.

3. Export the relevant source system container to a file folder.

The metadata in the folder in Step 3 above will become the source for this upgrade.

10.6.2 Replace Base: Procedure for Upgrading

Follow this procedure to use the Replace Base option to upgrade the DAC Repository when you are phasing out an older release of a transactional application and moving to a newer release.Before you begin this procedure you should review the section"Resolving Object Differences in the View Difference Report" to gain an understanding of your options for resolving object differences.

To upgrade an existing DAC Repository

1. Navigate to the Upgrade/Merge Wizard by selecting Tools, then DAC Repository

Management, and then Upgrade/Merge Wizard.

2. From the drop-down list, select Replace Base, and then click OK. The Import Source System Container dialog box appears.

3. Click Change import/export folder to navigate to the directory that holds the metadata files for the new base container to which you are upgrading.

4. Select the appropriate container from the Source System Container drop-down list, and click OK.

5. In the Importing Tables dialog box, re-type the text in the text box to confirm you want to proceed, and click Yes. When the import process is complete, the Importing Tables dialog box tells you how long the process took.

6. Click OK. The Create Difference Report dialog box appears.

7. Create the Difference Report to view the differences between the new and existing DAC repositories.

a.      Enter a name for the Difference Report, or leave the default name.

b.      Select the appropriate existing container.

c.       (Optional) Enter a description for the Difference Report.

d.      Click OK.

When the Difference Report is complete, the Creating Difference Report dialog box tells you how long the process took.

e. Click OK.

Read More

DAC - Simplified Refresh From Base Option

10.5 About the Simplified Refresh From Base Option

The Simplified Refresh From Base option is similar to the Refresh Base option. It allows you to upgrade from a DAC Repository from an older release of Oracle BI Applications to a new release, but you cannot compare repositories and create aDifference Report.

If you want to upgrade a DAC Repository from an older release of Oracle BI Applications to a new release and you want to compare repositories and create a Difference Report before merging the repositories, you must use the Refresh Base option. See "About the Refresh Base Option" for more information.

Before you begin this procedure, do the following:

■ Determine what customizations were made to your existing DAC Repository.

■ Make sure you have renamed and backed up your existing DAC Repository into a

different database. When you backup the DAC Repository, you export the DAC metadata, in XML format (using the DAC's Export tool), into a folder other than the standard DAC export folder where backups are stored (DAC\export). For instructions on exporting DAC metadata, see "Exporting DAC Metadata".

To upgrade the DAC metadata repository

1. Upgrade your existing DAC Repository tables to be compatible with the new DAC Repository release.

a. Configure the new DAC client version to read the DAC metadata from your existing DAC Repository.

b. Log in to the DAC and select Yes if prompted to upgrade the repository tables.

2. Export the custom applications from your existing custom repository to a folder

other than the standard DAC export folder (DAC\export) or the folder into which you backed up metadata in the previous format.

3. Import the new DAC metadata for your application from the standard DAC export folder (DAC\export). Select the Truncate Repository Tables check box. For instructions on importing DAC metadata, see "Importing DAC Metadata".

4. Import the customized DAC metadata that you exported in Step 2, and deselect the Truncate Repository Tables check box. This will append all the custom data to the repository, thus bringing in the customizations, which include the following:

■ All modified data.

■ All newly created custom data.

■ All deleted data.

5. Refresh the source system container to locate any missing objects in your customized application. The missing objects are any new objects that the preconfigured applications may have that are not referenced in the custom applications.

a. Navigate to the Upgrade/Merge Wizard by selecting Tools, then DAC Repository Management, and then Upgrade/Merge Wizard.

b. From the drop-down list, select Simplified Refresh From Base, and then click OK.

c. Select the appropriate container from the Source System Container drop-down list, and click OK.

d. Confirm that you want to refresh the source system container.

6. Rebuild all the subject areas and execution plans in your customized application to include any new changes in the object dependency. For information about building subject areas and execution plans, see "Customizing DAC Objects and Designing Subject Areas" and "Building, Running and Monitoring Execution Plans".

Read More

DAC - Peer to Peer Merge

10.7 About the Peer to Peer Merge Option

This section includes the following topics

■ Peer to Peer Merge: High-Level Process Flow

■ Peer to Peer Merge: Procedure for Merging

The Peer to Peer Merge option enables you to merge DAC repositories of different instances of the same release. For example, in a development environment you may have two instances of a DAC Repository used with Oracle BI Applications release 7.9.5 that you want to merge.

10.7.1 Peer to Peer Merge: High-Level Process Flow

Figure 10–5 shows a high-level process flow for using the Peer to Peer Merge option to merge DAC repositories of different instances of the same release.The term base is used to refer to a source or target container that you have not changed or customized in any way.

Figure 10–5 Merge Process for Peer to Peer Merge Option

 

In Step 1 of the high-level process flow, you export one instance of the existing customized source system container to the file system and then import this container into the repository temporary tables. This repository is referred to as the source in the

Upgrade/Merge Wizard.

In Step 2, you create a Difference Report that compares the instance 1 container (including customizations) with the instance 2 container (including customizations).

The instance 2 container is referred to as the target.

In Step 3, you accept or reject the objects that the Difference Report shows as beingpresent or changed in the source but not the target. See Section 10.8.3, "Possible Repository Merge Outcomes Based on Your Decisions" for a description of how objects are merged based on the action you take.

In Step 4, after you have resolved the differences, you then execute the merge. In Step

5, the Upgrade/Merge Wizard references the customizations in the newly merged container with the instance 1 base container.

10.7.2 Peer to Peer Merge: Procedure for Merging

Follow this procedure to use the Peer to Peer Merge option to merge DAC repositories of different instances of the same release. Before you begin this procedure you should review the section"Resolving Object Differences in the View Difference Report" to gain an understanding of your options

for resolving object differences.

To merge two DAC repositories of different instances of the same release

1. Navigate to the Upgrade/Merge Wizard by selecting Tools, then DAC RepositoryManagement, and then Upgrade/Merge Wizard.

2. From the drop-down list, select Replace Base, and then click OK.The Import Source System Container dialog box appears.

3. Click Change import/export folder to navigate to the directory that holds the metadata files for instance 1 of the source system container you want to merge.

4. Select the appropriate container from the Source System Container drop-down list and click OK.

5. In the Importing Tables dialog box, re-type the text in the text box to confirm you want to proceed, and click Yes.When the import process is complete, the Importing Tables dialog box tells you how long the process took.

6. Click OK.

The Create Difference Report dialog box appears.

7. Create the Difference Report to view the differences between the instance 1 container and the instance 2 container.

a. Enter a name for the Difference Report, or leave the default name.

b. In the Existing Container drop-down list, select the instance 2 container.

c. (Optional) Enter a description for the Difference Report.

d. Click OK.

When the Difference Report is complete, the Creating Difference Report dialog box tells you how long the process took.

e. Click OK.

The View Difference Report dialog box displays the differences between the instance 1 and instance 2 containers.

8. In the View Difference Report dialog box, resolve the differences between the instance 1 and instance 2 DAC repositories. The instance 1 repository is referred to as the source or existing container, and instance 2 as the target or new container. For detailed information about the View Difference Report, see"Resolving Object Differences in the View Difference Report". To resolve the differences, you either accept or reject the objects that appear as new or changed in the instance 1 container but do not appear in the instance 2 container. a. In the navigation tree, select the repository object for which you want to view the differences between the instance 1 and instance 2 containers. If the object selected in the navigation tree is a hierarchical object, the subtabs for the child objects appear in the bottom pane of the Object Differencewindow.

b. (Optional) Filter the objects that appear in the top, right window by selecting one of the options from the drop-down list in the toolbar.

c. For parent objects in the top pane and any child objects in the bottom pane, accept or reject the object in the difference list by selecting or deselecting the Accept Source check box. For detailed information about these options and the merge outcome, see "Possible Repository Merge Outcomes Based on Your Decisions".

Note: If a child object has been changed but not the parent object, the parent object will still appear in the Object Difference window even though it has not been changed.

d. (Optional) Once you have made a decision about whether to accept or reject the difference, select the Resolved check box to indicate you have resolved the object.

e. Repeat Steps a, b, and c, until you have resolved all object differences.

f. Click Merge. The Merge dialog box appears and lists the details of the merge.

9. Click Merge to begin the merge process.

10. Click OK in the Merging Repositories dialog box when the merge process is complete.

Read More

DAC - W_DAY_D and Configure the Multi Calendar support

Oracle BI Applications come with a predefined Informatica Repository and a pre-built DAC (Datawarehouse Administration Console) repository. When loading the BAW (Business Analysis Warehouse, the predefined schema) for the first time, this is called a full load.

One table is of particular interest: W_DAY_D, implementing the time dimension, storing one record for each day between 1st of January 1980 and 31st of December 2010.

 

How to populate W_DAY_D ?

Using the DAC Client this question is easily answered. There are four tasks that take care of W_DAY_D.

The main task SIL_DayDimension has two parameters which are passed to the Informatica workflow. 

$$START_DATE has a default value of 1980-01-01 and $$END_DATE one of 2010-12-31.

Before you can update these parameters, you have to create a custom container using the functionality in the DAC File menu. Once the container is created, 

Go to the SIL_DayDimension task, click the Parameters tab and update the parameters according to your needs.

When a referenced object in the DAC repository is changed, it will be cloned and you have to commit that in a dialog box.

Now we have to enforce a full load on the W_DAY_D table, which means setting the table's refresh date to NULL. This is standard behavior of the DAC. It will start the task in full mode when the refresh date of the target table(s) are set to NULL.

To do this, navigate to Setup > Physical Data Sources > DataWarehouse and click the Refresh Dates tab. Here you query for the table and set the refresh date to NULL.

Set refresh date for W_DUAL_G, W_DAY_D, W_WEEK_D, W_MONTH_D, W_QTR_D and W_YEAR_D tables to NULL.

About setting up Gregorian Calendars:

Set calendar type option like 445 or 13 period calendar

Whatever calendar type you want to deploy, you must set up the start date and end date range for the Gregorian calendar, I did that.

Note: The tasks that load the Day dimension will run as part of the Execution Plan for your Subject Areas. Please note that there are no separate Subject Areas for common dimensions. They are included in the core Subject Areas.

To set up a 13 Period calendar

1.       1.   In DAC, display the Design view, and select an appropriate adapter.
2.       2.   Display the Source System Parameters tab.
3.              Set the value of $$GBL_CALENDAR_ID and $$GBL_DATSOURCE_NUM_ID as follows:

•   GBL_CALENDAR_ID: Should be the CALENDAR_ID of the Generated Calendar (4-4-5 or 13 period type of Calendars). By default the 4-4-5 calendar has a CALENDAR_ID of '10000' and the 13-period calendar has a CALENDAR_ID of '10001'.   
• GBL_DATASOURCE_NUM_ID: If Global Calendar is Generated Calendar: Should be the DATASOURCE_NUM_ID value of the OLAP (Data warehouse).

1.     4.   Using a text editor, edit the values in file_mmcal_config_g.csv.
2.     5.   In DAC, set the value of 13P_CALENDAR_ID to 10001.

Note: The task SIL_TimeDImension_McalWeek13Period will run as part of the Execution Plan for your Subject Area. Please note that is no separate subject are for common dimensions. They are included in the core Subject Areas.

•    By default the 4-4-5 calendar has a CALENDAR_ID of '10000' and the     13-period calendar has a CALENDAR_ID of '10001'.

Click on OK

Click on Yes.

Data Sources and Associated DATASOURCE_NUM_ID Values

•    GBL_DATASOURCE_NUM_ID: If Global Calendar is Generated Calendar: Should be the DATASOURCE_NUM_ID value of the OLAP (Data warehouse).

Click on OK

Click on Yes.

Now Configure the Multi Calendar support

1 Create custom subject area for multi calendar

2 Add table as W_DAY_D From table tab from below tab panel:

 Select “Multible Calendar Support “ from below configuration tab:

Assemble Multi calendar subject area:

Click on Assemble tab and ok

Click on Accept button

Click on Continue

Click on OK

Show different support Mappings related to Multi calendar   

Create Execution Plan for Multi calendar subject area

Create Execution plan and add multi calendar subject area:

Click on Parameters tabs and click on Generate tab and OK

It show Parameters and click on OK

Change the Values:

Build Execution Plan for click on BUILD button:

Click on OK

Click on OK

Click on Orders Tasks and It will show Depth:

Click on RUN button and Click on YES

Click on OK

Verify the data in W_DAY_D 

Read More