Hierarchies (Level-based hierarchy) in OBIEE 11G

A hierarchy is a cascaded series of many-to-one relationships and consists of different levels.
Example, a region hierarchy is defined with the levels Region, State, and City.

In the Business Model and Mapping layer, a dimension object represents a hierarchical organization of logical columns (attributes). One or more logical dimension tables can be associated with at most one dimension object. Common dimensions might be time periods, products, markets, customers, suppliers, promotion conditions, raw materials, manufacturing plants, transportation methods, media types, and time of day. Note that dimensions exist in the Business Model and Mapping (logical) layer and in the Presentation layer.

There are two types of Logical Dimensions:

1.       Dimensions with Level-based hierarchies (structure hierarchies).

2.       Dimensions with Parent-child hierarchies (value hierarchies).

Level-based hierarchies are those in which members are of several types, and members of the same type occur only at a single level.

In Parent-child hierarchies, members all have the same type. Oracle Business Intelligence also supports a special type of level-based dimension, called a Time dimension, which provides special functionality for modeling time series data.

--------------------------------------------

Level-based hierarchies are those in which members are of several types, and members of the same type occur only at a single level.

A very important new feature of the BI EE 11g is the ability to support ragged & skipped hierarchies in a normal level based hierarchy. Though it does look straight-forward in terms of functionality and also the setup, enabling these 2 options basically changes the underlying SQL Queries generated.

To illustrate this, I will be using a very simple hierarchy as shown below:

 

Ragged Hierarchy feature is also dependent on the data stored in the backend table. There should be NULLs in the levels when there is no data. Usually in BI Apps, we repeat the value till the base Level if the hierarchy stops at a level. In 10g this would have been tricky, as OBIEE would have expected each leaf member to be at the same (not to be as in the above case, node C) level, and if they weren’t, you’d need to fudge the data a bit, for example by adding dummy child members to node C. So that, each leaf was at the same level. 

Skip Level Hierarchy is another approach in defining the hierarchy as shown above. Here node F is directly linked with Parent node A, but in between there it should be parent to the node F and child to the parent node A as per the earlier version like 10g. For that again we added dummy node in between node A and node F. So that, each leaf was at the same level. 

OBIEE 11g can handle this though with the new ragged and skip-level support for level-based hierarchies. It does this by detecting NULL s in either leaf levels (for ragged hierarchies) or other levels (for skip-level

hierarchies) and uses this to modify how the new hierarchical column type in Analysis handles the missing levels.

• Step 1: Have dataset as specified below to understand these above said hierarchies. 

• Step 2: Import this table in physical layer of repository and have aliases and physical joins for further development.

• Step 3: Build the complex joins in Business Model and Mapping layer between Fact and Dimensions. Create Level-Based hierarchy on Logical Dimension (Ex: Dim Ragged & Skipped Hierarchy) as mentioned below,

•  Step 4: Create hierarchy as specified by the requirement. Here it is mentioned in this below hierarchy:

 

•  Step 5: check the property Ragged Hierarchy check box in the properties of newly created above said dimensional hierarchy.

• Step 6: Drag and drop the dimension and fact tables in to Presentation layer. Remove the detail level for the hierarchical column, which is not necessary to display.
• Step 7: Create a sample report with the Hierarchical Column, which is marked as ragged hierarchy, It shows output as below ,

 Note: As per the existing dataset, Ragged Hierarchy will not permit to show the further drill dataset, if it contains NULL value. This will be achieved with the Skip Level property of Level based hierarchy. It can consider the leaf nodes even though it contains NULL values in between.

•  Go to Step 5: Instead of selecting Ragged, now choose the check box Skipped Levels as shown below,

  

Choose the same criteria in Analytics, to identify the working nature of Skip levels and the output is as shown below,

Here It will consider the leaf nodes irrespective of NULL values in between, which the earlier does not consider. In general, these two types of hierarchies will be used at once simultaneously to avoid faults in getting reports.

x----------------------------------x------------------------------------x

Configure BI Publisher in OBIEE 11G

This Document explains about the configuration of  BI Publisher in OBIEE 11g.

Contains,

   

> SERVER CONFIGURATION.

> JNDI CONNECTION FOR BI PUBLISHER.

> REGISTER THE AUDIT-STORING DATABASE TO DOMAIN.

> REGISTER AUDITING DATA SOURCE AS JNDI DATA SOURCE.

> CREATE DATA MODEL.

> CREATE REPORTS.

Server Configuration: 

•      Login in to Oracle Business Intelligence
•      click on the Administration Tab
•      select BI Publisher (Manage BI Publisher)
•       Select Server Configuration as shown in the above snapshot.
•      Select check mark on “Enable Monitor and Audit”

Note: BI Publisher performance monitoring enables you to monitor the performance of queries, reports and document generation and to analyze the provided details. User auditing provides information about what users logged in, when, how many times, what reports they accessed, and other actions they took within the application.

  

JNDI Connection for BIP:

   >  Login to Web Logic Server Administration Console.

   > Under Services, click Data Sources.

• Click Lock and Edit button to enable editing.
• On the Summary of JDBC Data Sources page, click New and click Generic Data Source.

Enter the following details for the new data source;

•     Name (example: BIP_AuditDB)
•     JNDI Name (example: jdbc/AuditDB)
•     Database Type (example: Oracle)

>  Click Next and select the database driver (Thin XA) for Instance Connections; Versions:9.0.1 and later.

>  Enter the required connection properties like Database name, host name, port, database user name (for our exercise it’s OBI_IAU) and the password.

> Click next and accept the default setting and then click Test Configuration button as show below.

 > Click Next, Check listed servers where you want to make this JDBC connection available.

> If the connection was successful, click Activate Changes to make the changes available.

Register the Audit-Storing Database to Domain:

• Login to Web Logic Server EM (Enterprise Manage).
• Navigate to the Web Logic Domain, right clickbifoundation_domain, and then select Security, then Audit Store.

> Click Search Data Sources. From the Select Data Source dialog, select the data source you created and click OK

> Navigate to the Web Logic Domain, right clickbifoundation_domain, then select Security, then Audit Policy.

> The Audit Policy table displays all the audited applications under the bifoundation_domain. Set the Audit Level to Medium to enable auditing for BI Publisher.

Restart the Web Logic Servers/domain/Applications etc...
After this, now the BI Publisher should start feeding all the auditing data into the database table called ‘IAU_BASE’. Try login to BI Publisher and open a couple of reports, you should see the activity audited in the ‘IAU_BASE’ table. If not working, we might want to check the log file, which is located at BI_HOME/user_projects/domains/bifoundation_domain/servers/AdminServer/logs/AdminServer-diagnostic.log

Register Auditing Data Source as JNDI Data Source:

First thing you need to do is to register the audit data source (JNDI/JDBC connection) you created in the previous step as JNDI data source at BI Publisher. It is a JDBC connection registered as JNDI that means you don’t need to create a new JDBC connection by typing the connection URL, username/password, etc. You can just register it using the JNDI name. (E.g. jdbc/AuditDB)

   Ø  Login to BI Publisher as Administrator (e.g. Web Logic)

Ø  Go to Administration Page

Click ‘JNDI Connection’ under Data Sources and Click ‘New’

 

•     Type Data Source Name and JNDI Name. The JNDI Name is the one you created in the Web Logic Console as the auditing data source. (e.g. jdbc/AuditDB)
•     Click ‘Test Connection’ to make sure the data source connection works.
•     Provide appropriate roles so that the report developers or viewers can share this data source to view reports.
•     Click ‘Apply’ to save.

Create Data Model:

•     Select Data Model from the tool bar menu ‘New’
•     Set ‘Default Data Source’ to the audit JNDI data source you have created in the previous step.

       > Select your data set in the left hand pane and click on ‘SQL Query’

> Use Query Builder to build a query or just type a SQL query. Either way.

Ø  Here is sample SQL query looks like.

> Click OK and save the data model. Once saved the data model then click on XML option.

     >  Test the sample with Get XML Output and save XML to your data model.

Create Reports:

Now you can use one of the BI Publisher’s layout options to design the report layout anD visualize the auditing data. Here are some sample screenshots of my report design with Online Layout Editor.

X--------------------------------------------------------------X

SMART VIEW in Excel with OBIEE 11.1.1.7.0

Smart View is Hyperion tool that enables you to create new reports and run existing reports/Analysis, directly from Excel.

From the Home page of OBIEE, we can download Smart View as shown below,

Install it (add-on to Excel). Now we can run it from Excel Menu. To begin, from the Panel create a new connection. Follow the installation and configuration as it appears below with screen shots,

After the installation, we can see the add-on in Excel menu bar as shown below. Once we got add-on link need to establish connection for Smart View interface with OBIEE. This interface will be used to import report views or dashboard contents to Excel single/multiple spread sheets as well as we use this as Answers in OBIEE. We can create different report views and can be saved
to OBIEE Catalog folders. The same report view can be placed on any dashboard page as per the requirement.

 For the first time, we need to specify the new connection provider type for Smart View as above stated.

 Here we have simple approach for connections related configurations, i.e. click on Panel under Smart View Section as specified above. Need to specify the requested type of connection is as Shared or Private and then configure the connection settings as below,

Once the connection is established, new add-on will be available in Excel menu bar i.e.  Oracle BI EE. This will be used for creating reports in excel spread sheet and can be used to publish or save the report vies in OBIEE Catalog folders.

 Step 1:  Click on View Designer object in Oracle BI EE section as shown below,

 

 

Step 2: Here we can find the available subject Areas from the OBIEE as shown below. Now we can    

create the report view based on required scenario.

Step 3: Choose requested fields from the subject Area and place it on Design layout of View in Excel. Once it is done, we can see properties of Pivot table tools as specified in below screen shot, similarly we can find the other related properties of Views in yellow colored section. Once requested views are ready then click on add-on button Oracle BI EE, then choose the option Publish View as shown in below screen shot.

 Publish View:

Here we need to specify the catalog folder in OBIEE to save the new View developed in Excel as below,

When it is saved we can get confirmation as below in order to save in Catalog folder as below,

    

For the confirmation, let us check in catalog folders available in OBIEE environment as below,

This is the way we can create report view from the Excel Spread Sheet and the same will be saved in to Catalog folders of OBIEE. The same report we can be placed on any requested dashboard page.

For the report, created in Excel, we can get Criteria as normal report built in Analysis as shown below,

x-----------------------------------------------------------------------x

Best Practices in Presentation Layer(OBIEE)

• Catalog should map to one Business Model & Mapping Layer (BMM) Layer objects only.
• Use Parent Folders and Sub folders to group Facts and similar Dimensions together.
• Avoid the use of Aliases when a new Presentation Column is created.
• The Presentation Columns in a table should be sorted alphabetically if no specific order is asked by the customer.
• Get Customer Sign-off of the Presentation layer structure before building reports. This will avoid later replacements of columns which affects the reports constructed.
• Make proper use of the Permissions in this layer.
• Don’t use Double quotes (“) in Column name, though its permitted.
• Presentation columns should not have the same name as Presentation Table.
• Eliminate unneeded objects to reduce user confusion.
• Limit Number of objects in folder to 7-12.
• Use Object  description field to convey information to users when they hover the mouse in Answers on a Presentation column.
• Keep names short to have space on reports.
• Give the meaning table names and columns names to identify easily on subject areas.
• Try to create separate folder for each data mart (HR, Operation, SCM, sales) if it is coming from same Business Model & Mapping Layer.
• Remove primary key columns and other unnecessary columns that doesn't going to use in the creation of the reports.

Best Practices in BMM Layer(OBIEE)

• Minimize the use of Snow-Flakes. Always go for Star Schema's.
• Always use Complex joins here. It allows OBI Server to make best decision about the exact physical SQL to be generated based on Logical query Path. In contrast to a Physical FK join, these forces a single join path between tables. If joined tables were dragged from Physical Layer, replace FK Joins with complex Joins.
• Create Dimension Hierarchies for every Dimension in the Business Model.
• Even if a meaningful hierarchy definition cannot be thought of, just create one with the Grand Total Level and Detail Level.
• For Dimension Hierarchies the ‘Number of Elements at this level’ should increase from 1 at Grand Total to the corresponding distinct values at each level. This can be approximate values; need not be the exact ones.
• Define Keys at each level of the Hierarchy.
• The Content tab of each of the LTSs in Fact should be set to the related Dimension’s Logical Level.
• Combine all attributes that describe a single entity into a single Logical table.
• Never delete logical columns that map to keys of Physical dimension tables.
• Don’t keep unwanted Physical columns in the Logical Layer.
• Give Meaningful Names to the Logical Columns. Avoid assigning a logical column the same name as a logical table or Business Model object.
• Make proper use of the where clause Content filter of the LTS to minimize number of records returned.
• Minimize the use of Conditional Checks and ‘CASE WHEN’ usage in the formula of Logical Columns. This will affect performance. Instead make proper use of the where clause Content filter of the LTS if the condition applies to all the columns/measures in the logical table.
• When Creating a logical column based on other logical columns , make sure all the columns in the expression is from the Same logical table, same Logical Table Source.
• Make proper distinction between Count and Count Distinct. If you are counting on a unique value column don’t use Count Distinct. This will affect performance.
• Minimize the use of Outer joins within LTS. This is resource consuming. Use default zero ROW_WID records at the database instead.
• Make sure a particular Report only refers one LTS in a Logical Table. Or the different LTSs should be at the same level.
• Avoid dimensions in Fact tables and avoid measures in Dimension Tables.
• Create Display folders to group tables according to STAR or Releases.
• When using Out-of-the -Box Vanilla RPD, remove unwanted Logical Tables and Hierarchies. This will minimize the time needed for Consistency Check.
• Specify the most Economical Source when there are multiple LTSs for a Dimension.
• Whenever you do Consistency Check, Right Click the Changed Business Model Object and go for Check Consistency rather than using the Global Consistency Check. This will minimize the time needed for Consistency Check.
• Arrange the logical columns alphabetically. This will save time when you revisit.
• Fix the warnings if any, don’t ignore it.

Best Practices in Physical Layer(OBIEE)

In this post I am sharing some of the best practices to follow while we are in OBIEE solutions.

•  Try to always import tables and columns into Physical layer rather than creating it manually.
•  This will ensure correct data types are set for each column. This is particularly useful when there is confusion between DATE and DATETIME.
• For each Physical Dimension table there should be a Primary Key and only one. For Fact Tables, there is no need to create a Primary Key.
• If only composite key is present create a single Physical key and add all the composite key columns in it.
• Minimize Opaque Views (SELECT statements) in Physical Layer.
• Create Tables (recommended) or  Materialized views in data-warehouse instead.
• Always use Foreign Key Joins in the Physical layer. Avoid using complex joins with conditions.  Complex joins are not good for performance and should be avoided. (there are a few exceptions for this case when we work with Type 2 SCD).
• Always try to use Number-Number join. This will work faster than a varchar-varchar join.
• Avoid using CAST functions in the join expression. This will destroy the usability of the Database indexes created on that column.
• Avoid any filter conditions in the Join.
• These filter conditions can in turn be added in the LTS (Logical Table Source) ‘Where’ clause content filter or as request filter in Reports.
• Facts should not be joined . This will result in Cartesian Product leading to double counting and summing.
• Use conforming Dimensions instead.
• Connection Pool considerations (15-18).
• Require fully qualified table names should be unchecked.
• Enable Connection Pooling should be checked.
• Execute queries asynchronously should be checked.
• Create a separate Connection Pool for Initialization Blocks.
• Keep Cache persistence time of all tables as Infinite.
• The columns used in Joins should be set to “NOT NULL”.
• The database Features tab should be set correctly with the Parameters supported by your backend database.
• If both are not in-sync then lot of processing will be done in the BI Server instead of the Database. This affects Performance. Pay particular attention to Locale. (They are case-sensitive).Mismatch of Locale can cause the sorting to be done in OBI Server instead of DB and performance take a bad hit!
• DERIVED_TABLES_SUPPORTED in database features tab should be  checked for Oracle Databases. This will ensure that Proper function shipping will happen to the DB in case of TOP(N) and Rank functions.
• Create Display folders to group tables according to STAR or Releases.
• Set Different Icons on objects for each Release of the Code. This will ensure in finding which entity was added in which release.
• Don’t Leave the Description field empty. Write some meaningful descriptions of the Object. This will help a lot in later trouble-shooting and Impact Analysis.

Usage of GO URL Syntax in OBIEE Environment

This section discusses various techniques for integrating Oracle OBIEE content into external web content using the GO URL syntax available in OBIEE. Note that OBIEE should be in Single Sign On with the external application otherwise authentication information is also required as part of this URL syntax. Most of this is also documented in OBIEE Web administrator guide, just some additional examples and few additional syntax are provided here and also putting them all at one place
Integrating Analytics Reports using Go URL syntax
Analytics supports a versatile “Go URL” syntax to incorporate Analytics content into external portals.

• Go URL with parameters can be posted as a Form or
• Issue it as a URL with parameters.

If you are issuing parameters as part of a URL, they need to be escaped properly.
Calling GO URL:
When calling from within Analytics Dashboard or HTML view simply use the URL
saw.dll?GO
When calling from another screen from the same Web server then use the syntax
/analytics/saw.dll?Go
When calling from a different Web server the use full syntax:
http://server_name_or_ip_address/Analytics/saw.dll?Go
Authentication with the GO URL
It is assumed that Analytics Web site has Single Sign On (SSO) enabled within corporate web-sites.Single Sign On authentication information is not required as a part of the “Go URL”. If Single Sign On is not enabled then additional authentication parameters must be supplied with the Go URL
http://server_name_or_ip_address/Analytics/saw.dll?Go&NQuser=xxx&NQPassword=xxx
Structure of the Go URL
Basic structure of the Go URL is as follows:
saw.dll?Go&Path=/Shared/Training/ParameterReport
Here, the path is the catalog path for the Analytics report ParameterReport. This basic URL syntax displays the default result view for the report in standard style.
There are number of optional arguments to this URL syntax
Displaying Report Results in different format
Display ‘Modify’, Download’ ‘Print’, ‘Refresh’ options along with the report
saw.dll?Go&Path=/Shared/Training/ParameterReport&Options=mdr
Print report in HTML format
saw.dll?Go&Path=/Shared/Training/ParameterReport&Action=print
Print in xx format, where xx=PDF,Excel, mht or xml
saw.dll?Go&Path=/Shared/Training/ParameterReport&Action=print&format=pdf
saw.dll?Go&Path=/Shared/Training/ParameterReport&Action=print&format=excel
saw.dll?Go&Path=/Shared/Training/ParameterReport&Action=print&format=mht
saw.dll?Go&Path=/Shared/Training/ParameterReport&Action=print&format=xml
Download report directly in the xx Format where xx= Excel, csv or mht
saw.dll?Go&Path=/Shared/Training/ParameterReport&Action=download&format=csv
saw.dll?Go&Path=/Shared/Training/ParameterReport&Action=download&format=excel
saw.dll?Go&Path=/Shared/Training/ParameterReport&Action=download&format=mht
Note: Download does not support filters to be passed from the GO URL
Showing specific view of the report:
saw.dll?Go& Path=/Shared/Training/ParameterReport &ViewName=pivot
Displaying all the records in a table view:
saw.dll?Go&Path=/Shared/Training/ParameterReport &Action=Scroll&P5=-1&ViewID=go~Table
Displaying Dashboard or Dashboard Pages:
Syntax for displaying entire Dashboard or specific Dashboard pages URL syntax is:
saw.dll?Dashboard&PortalPath=/shared/Training/_Portal/Training
Displaying specific Dashboard page:
saw.dll?Dashboard&PortalPath=/shared/Training/_Portal/Training&Page=Sales%20by%20Region
Displaying specific Dashboard page in PDF format:
saw.dll?Dashboard&PortalPath=/shared/Training/_Portal/Training&Page=Sales%20by%20Region&Action=print&format=pdf
Passing Parameters to the Report using Go URL optional argument
The Go URL can also be used to pass context such as filters to a destination request. This is done by adding additional parameters to the call. You need to make sure that any columns you are passing are set up in the destination with Is Prompted filters, or specific default filters. Up to 6 parameters can be passed to the target report
New syntax for GO URL in addition passing the parameters only supported in OBIEE 10.1.3.2 or above
New syntax for Go URL in Analytics. You can now pass as many parameters and values as you want
note the syntaxt &col1=&val1=
http://webserver/analytics/saw.dll?Go&Path=%2Fshared%2FSupplier%2FRegionDollars&Action=Navigate&col1=Periods.%22Year%22&val1=%221999%22&op1=eq&nquser=Administrator&nqpassword=Administrator
Also an operator can be included in the URL, default is ‘eq’ if op1 etc. are not included
http://webserver /analytics/saw.dll?Go&Path=%2Fshared%2FSupplier%2FRegionDollars&Action=Navigate&col1=Periods.%22Year%22&val1=%221998%22&op1=gt&nquser=Administrator&nqpassword=Administrator
The syntax is pretty flexible and can include as many parameters and operators there is no limit.
http://webserver/analytics/saw.dll?Dashboard&PortalPath=%2Fusers%2Fadministrator%2F_portal&Page=TestPrompts&Action=Navigate&col1=Markets.Region&val1=%22EASTERN%20REGION%22&col2=Markets.District&val2=%22PHILADELPHIA%20DISTRICT%22&col3=Markets.Market&val3=%22PHILADELPHIA%22&col4=Periods.%22Year%22&val4=%222001%22&col5=Periods.%22Month%22&val5=%222001-03-01%22&col6=Periods.Week&val6=%22WEEK%20ENDING%2003%2F10%2F01%22&col7=Products.Type&val7=%22COATINGS%22&col8=Products.Brand&val8=%22Enterprise%22&col9=Products.UPC&val9=%22Enterprise%20Steel%20Gloss%22&nquser=Administrator&nqpassword=Administrator
 -------------------------------------------------------------------------------------------
http://webserver/analytics/saw.dll?Go&Path=%2Fusers%2Fadministrator%2FAllPromptTestReport&Action=Navigate&col1=Markets.Region&val1=%22EASTERN%20REGION%22&col2=Markets.District&val2=%22PHILADELPHIA%20DISTRICT%22&col3=Markets.Market&val3=%22PHILADELPHIA%22&col4=Periods.%22Year%22&val4=%222001%22&col5=Periods.%22Month%22&val5=%222001-03-01%22&col6=Periods.Week&val6=%22WEEK%20ENDING%2003%2F10%2F01%22&col7=Products.Type&val7=%22COATINGS%22&col8=Products.Brand&val8=%22Enterprise%22&col9=Products.UPC&val9=%22Enterprise%20Steel%20Gloss%22&nquser=Administrator&nqpassword=Administrator

Old syntax for passing parameters works both in OBIEE and previous releases e.g. 7.7, 7.8, 10.1.3.1 etc.
Pass one parameter:
saw.dll?Go&Path=/Shared/Training/ParameterReport&Action=Navigate&P0=1&P1=eq&P2=Periods.Year&P3=1+1999
Pass 2 parameters:
saw.dll?Go&Path=/Shared/Training/ParameterReport&Action=Navigate&P0=2&P1=eq&P2=Periods.Year&P3=1+1999&P4=eq&P5=Customers.State&P6=1+CA
Here the operator P1=eq can be of different type as documented in the Siebel Analytics Web Admin guide e.g. like, lt, gt etc.
saw.dll?Go&Path=/Shared/Training/ParameterReport&options=md&Action=Navigate&P0=2&P1=eq&P2=Customers.State&P3=1+CA&P4=like&P5=Products.Type&P6=1+”B%”
Include the numeric parameter value in “ e.g. &P2=Periods.Year&P3=”1998”
Also position Like operator at the end of the parameter list.
Passing parameter to a Dashboard prompt:
If a Dashboard is using prompts then values can be passed to it similar to above syntax as follows:
http://webt43/analytics/saw.dll?Dashboard&PortalPath=/shared/Training/_Portal/Training&Page=Filters&Action=Navigate&P0=1&P1=eq&P2=Products.Type&P3=Beef
Issuing Direct SQL to Siebel Analytics using URL syntax:
Following URL syntax can also be used to directly issue a SQL against Analytics
saw.dll?Go&SQL=select+Region,Dollars+from+SupplierSales
following URL will bypass web cache and issued directly to the Analytics server
saw.dll?Go&IssueRawSQL=select+Region,Dollars+from+SupplierSales
Calling BI Publisher reports directly similar to GO URL
URL to directly call a BI Publisher report.
It will prompt the login screen if BI publisher is not single sign-on with the calling app
http://webserver:9704/xmlpserver/Business+Intelligence/Paint+Demo/Paint+Demo.xdo
Calling BI publisher report from OBIEE URL similar to Go URL syntax
Use ExecuteReportObject syntax
http://webserver/analytics/saw.dll?ExecuteReportObject&Path=/Business%20Intelligence/Paint%20Demo/Paint%20Demo.xdo
New syntax for Go URL in Analytics. You can now pass as many parameters and values as you want
note the syntaxt &col1=&val1=
http://webserver/analytics/saw.dll?Go&Path=%2Fshared%2FSupplier%2FRegionDollars&Action=Navigate&col1=Periods.%22Year%22&val1=%221999%22&nquser=Administrator&nqpassword=Administrator
Calling a Dashboard page works the same way.
If Page has some prompts then those can also be filtered using new syntax
http://webserver/analytics/saw.dll?Dashboard&PortalPath=%2Fusers%2Fadministrator%2F_portal&Page=page2&Action=Navigate&col1=Periods.%22Year%22&val1=%221999%22
If a page has only a BI publisher report and also has a prompt then
You can pass filters to the BI publisher report using Go URL syntax as below
http://webserver/analytics/saw.dll?Dashboard&PortalPath=%2Fusers%2Fadministrator%2F_portal&Page=page2&Action=Navigate&col1=Periods.%22Year%22&val1=%221999%22