|Oracle® Fusion Middleware Oracle WebCenter Analytics Administrator's Guide (for Oracle WebCenter Interaction)
10g Release 4 (10.3.0.2.0)
Part Number E14112-04
This chapter provides information on accessing and working with the Analytics Administration console.
It includes the following topics:
Log in to the portal as an administrator.
From the Select Utility drop-down list, choose Analytics Administration.
This section contains the following topics:
The Runtime Settings page lets you configure timeout periods, enable portlet view and response time data capture, and choose the format of export reports. The timeout settings that you specify on the Runtime Settings page are only for Oracle WebCenter Analytics reporting purposes; there is no relationship between these timeout settings and other portal timeout settings.
The following table describes the timeout settings that you can configure.
Table 3-1 Timeout Settings
Visit Timeout (seconds)
Type the maximum number of seconds that a user must remain inactive during a portal visit in order for Oracle WebCenter Analytics to report subsequent activity as a new portal visit. The default is 1800 seconds.
Note: If you upgraded to Oracle WebCenter Analytics 10.3 from a previous version, the Visit Timeout default setting from the previous Oracle WebCenter Analytics version remains. For example, if you upgraded from Analytics 2.1, the default Visit Timeout is 120 seconds, since that was the default in Analytics 2.1.
Active User Timeout (days)
Note: You do not need to configure this setting.
If you install the portal while Oracle WebCenter Analytics is running, Oracle WebCenter Analytics restarts the calculation of portal user activity after you have completed the installation. This may impact Oracle WebCenter Analytics user timeout reporting. For example, if you set the active user timeout to 7 days and the user goes on vacation and does not log in to the portal for eight days, Oracle WebCenter Analytics reports the user as an inactive user on Day 8. However, if you install Oracle WebCenter Interaction on Day 3 of the user's eight-day vacation, Oracle WebCenter Analytics calculates Day 3 as the first day in which the user is inactive. For this reason, the seven-day active user timeout period does not occur and Oracle WebCenter Analytics continues to report the user as an active user.
The following table describes the portlet view/response time settings that you can configure.
Table 3-2 Portlet Views/Response Time Settings
Capture portlet views/response times
Select the check box to enable the collection of portlet view and response time data. Portlet view data is reported on the Portlet Views console page. Response time data is reported on the Portlet Metrics - Response Time console page. By default, the collection of portlet view and response time data is disabled.
For guidelines on capturing portlet view and response time data, see Restricting Portlet View Data.
The following table describes the export report settings that you can configure.
Table 3-3 Export Report Settings
Note: Although TSV reports have no limitation on numbers of rows, exported reports in excess of 10,000 rows will likely take an extended period of time to generate.
The Security Settings page lets you control the data that users can access in Oracle WebCenter Analytics reports. On this page, you can add and remove roles, and launch the Edit Role window to make changes to the role (changes include adding and removing role members, capabilities and user properties to and from roles, and adding global filters to roles).
A user's roles and capabilities are retrieved by Oracle WebCenter Analytics when the user's session is being established. If you make changes to a user's roles or capabilities when that user is logged in, that user's access to Oracle WebCenter Analytics data does not change until they log off or their session expires.
The Super Users role grants members of the role to one or more capabilities and user properties. By default, in clean (non-upgraded) Oracle WebCenter Analytics 10.3 installations, the administrator user is assigned to the Super Users role with only the Application Write capability. If you upgraded to Oracle WebCenter Analytics 10.3, the Super Users role retains the members, capabilities, and user properties that it contained in the previous version of Oracle WebCenter Analytics.
The Analytics User Property Sync Job must be executed to display any new User Properties. The User Property Sync Job exists in the Analytics Jobs subfolder within the Analytics subfolder of the Admin Objects directory.
Removing the Super Users role deletes it from the system. To add the Super Users role again, you must re-create it.
The following table describes the capabilities that you can assign to roles.
Table 3-4 Oracle WebCenter Analytics Role Capabilities
Lets the role export user-level data from reports. User-level data is exported into an .xls file that can be used with Microsoft Excel. By default, this capability is not granted. The option to export user-level data exists in these reports:
When a role is not granted the capability to select All/Top/Bottom options, the role must choose one community or project; the option that is available depends on the report. By default, this capability is not granted.
Select the check box to grant the role the capability to add, modify, and remove roles.
In the Edit Role window, you can use global filters to restrict which events are included in a report. For example, you can create a filter that excludes the user accounts of the company executives from reports so that other users cannot view the executives' portal activity. Filters can be grouped by filter sets, and you can require that any or all filters in a filter set be met for a filter set to be applied. When a user views a report in the Analytics Console or an Oracle WebCenter Analytics portlet, the results are restricted by all filter sets that have been applied to all roles to which the user is assigned.
To create a new global filter set in the Edit Role window:
Click Add under Global Filters.
In the Filter Set Editor, select the event type to which the filter set applies.
Select All Events if you want this filter set to be applied to all events.
(Optional) Type a name for the filter set in the Filter Set Name box.
If you do not specify a name for the filter set, Oracle WebCenter Analytics sets a name based on the filters in the filter set.
Perform one of the following:
Select All if you want to include or exclude an event from reports only if all filters in the filter set are true or if any filter in the filter set is false for the event.
Select Any if you want to include or exclude an event from reports if any filter in the filter set is true or if all filters in the filter set are false for the event.
To create a filter:
Select a dimension on which to filter. The dimensions available depend on the type of event you selected on the previous page.
Select a property of the dimension on which to filter.
Select a comparison operator for the filter.
Specify the value you want to filter by.
Click Add to add the new filter to the filter set.
Repeat the previous step as many times as is necessary to add more filters to the filter set.
To remove a filter from the filter set, select the filter and click Remove.
After you have finished configuring the filter set, click Save.
You are returned to the Role Editor.
This section discusses the configuration of Analytics Administration's Partition Settings page. For guidelines on archiving and restoring partitions in your Oracle WebCenter Analytics database, see Archiving and Restoring Partitions.
Oracle WebCenter Analytics data is segregated into month-by-month partitions in the database. The Partition Settings page lets Portal Administrators specify the number of data partitions that are accessible to Oracle WebCenter Analytics reports. The Analytics Engine regularly scans each data partition that is accessible. For this reason, you can have more control over system performance by limiting the number of accessible partitions to only those that are needed.
At the beginning of each month, the system creates a new partition and stores all new Oracle WebCenter Analytics data in that partition until the month ends.
You also use the Partition Settings page to refresh database views after archiving or restoring partitions. To do so, click Finish. If you do not refresh the database views, Oracle WebCenter Analytics reports will fail.
The Scrolling View Window, which you configure on the Partition Settings page, is a rolling database view that changes month-to-month. For example, suppose that on August 5, you enable the Scrolling View Window and set its size to 4 months. The following occurs:
The Scrolling View Window makes data from 4 months available: May, June, July, and August. (Note that even though the month of August has not completed, the Scrolling View Window makes data from the August partition available so that the most current data appears in Oracle WebCenter Analytics reports).
On September 1, the Scrolling View Window scrolls one month forward and makes data from the June, July, August, and September partitions accessible. Though the Scrolling View Window removes the May partition from view, the partition and its data is still stored in the database. In this example, if in December of the same year the Portal Administrator wanted to make the data from the May partition available to reports, he or she would increase the Scrolling View Window size to 8 months so that it includes the May to December time frame.
To set the number of months, that are accessible to Oracle WebCenter Analytics reports, first enable the Scrolling View Window, then specify the number of months: between 3 and 60. Data from monthly partitions that do not fall within the Scrolling View Window size is made unavailable to Oracle WebCenter Analytics reports.
If you do not enable the Scrolling View Window, all data from all partitions is accessible to Oracle WebCenter Analytics reports.
At any time, you can click Preview on the Partition Settings page to view a chart that displays a representation of all partitions and indicates whether they are available or unavailable to Oracle WebCenter Analytics reports:
Green squares indicate partitions whose data is available to Oracle WebCenter Analytics reports.
Red squares with an X indicate partitions whose data is unavailable to Oracle WebCenter Analytics reports; these partitions do not exist in the database.
Grey squares indicate partitions for months that do not currently fall within the Scrolling View Window's date range. These partitions may or may not exist in the database.
The Event Registration feature lets Portal Administrators and developers register custom portal and non-portal events that are sent to Oracle WebCenter Analytics using the OpenUsage API. Event data is saved to the Oracle WebCenter Analytics database, which can then be queried for reporting to a non-portal application. This feature's user interface includes the Event Registration and Create Event pages.
Launch the Create Event page, which you use to create events and their parameters.
Enable and disable the storage of data generated by individual events. Once event data is stored in the database, you can query the data for reporting in a portal or non-portal application.
Create dimensions, which are discussed below.
This topic only discusses the Event Registration user interface. To utilize the full capabilities of this feature, you must use the OpenUsage API. For additional details on using the OpenUsage API, see Oracle Fusion Middleware Developer's Guide for Oracle WebCenter Analytics.
An event typically defines one user action that you would like to capture. Each event is composed of several event parameters, which defines the various kinds of data that is generated by the event. By default, each event includes the USERID, TIMEID, VISITID, and OCCURRED event parameters (for more details on these parameters, see Delivered Parameters).
Event Registration also lets you create your own event parameters to capture data that is not defined by the delivered defaults. To capture data of type Date, Integer, or Float, simply create an event parameter for that data type. To capture data of type String, you must create a dimension to define this data (a dimension defines data of type String). After you create the dimension, you must create a new event parameter of type String, and associate it to the dimension that you created.
We recommend that you do not create too many dimensions, since they slow down the speed of data collection and reporting.
Event Registration also lets you use dimensions from your own application's tables. To do so, create a parameter of type Integer. Then, using your database schema, map the parameter to the ID column in your dimension table.
To use a dimension, you must associate it to an event parameter on the Edit Event page. You can associate a dimension to multiple event parameters and use that dimension in multiple events.
The names that you create only define how dimensions appear on the Event Registration page. In the database, custom dimension tables use the following naming convention: ascdim_dimension_name (spaces in dimension names are replaced by underscores).
You cannot remove or change the name of a dimension after clicking Finish on the Event Registration page.
To store only unique values in this dimension's table, check Unique.
The Create Event page lets you define the event name and parameters that are included in the event. After you define the event and its parameters, click Finish to save an event and create its fact table in the database. Access the Create Event page by clicking Add on the Event Registration page.
After you save an event, you cannot change the names of the event and its parameters; you also cannot delete parameters from an event. You can, however, add parameters after saving an event. If your database was partitioned between the time the event was created and the addition of a new parameter, you must manually add a column for the new parameter to existing partitions. Partitions created after you create a new parameter will automatically include the appropriate columns.
You must set the OpenUsage API to send data to the fact table using the event name that you specified on this page, not its column name in the database.
Table names are read-only, and define the name of the fact table that will store the event's data. Custom event tables use the following naming convention in the database: ascfact_event_name (spaces in event names are replaced with underscores). For complete details on the fact tables that are delivered with Oracle WebCenter Analytics, see Working with Delivered Fact Tables.
You cannot remove or change the name of a parameter after clicking Finish on the New Event page.
Table 3-5 Parameters Delivered with Oracle WebCenter Analytics
The ID of the user who triggers the event. You must use the OpenUsage API to set the User ID.
The unique ID number that is created for each occurrence of the event. This value is set by Oracle WebCenter Analytics.
The portal visit ID of the user who triggered the event.
Note: This parameter is only compatible with events that occur in the portal. This value is set by Oracle WebCenter Analytics.
The date and time when the event was generated. The format of the date/time stamp is determined by your database type. This value is set by Oracle WebCenter Analytics.
To begin saving an event's data, select the check box next to an event on the Event Registration page and click Enable. By default, the BEA AL Analytics Collector service starts saving the event's data 30 minutes after you click Enable.
To stop saving an event's data, select the check box next to an event on the Event Registration page and click Disable. You can edit events even when they are disabled. By default, the BEA AL Analytics Collector service stops saving the event's data 30 minutes after you click Disable.
Users who have access rights to the Analytics Administration web service have the ability to access the Analytics Administration console by way of its URL, even if these users are not administrators (administrators have access to the Analytics Administration console by way of the portal user interface).
To prevent users from accessing Analytics Administration by way of its URL, remove the users' access rights to the Analytics Administration web service. For details, see Administrator Guide for Oracle WebCenter Interaction.
If you want users to access Analytics Administration by way of its URL, you must grant these users (at minimum) Read access to the Analytics Administration web service.