This appendix explains the use of the Enriched data exchange facility. This includes a description of operation, and the structure of the database tables it uses.
The Enriched data exchange facility enables you to combine the data gathered by RUEI with other data sources. These could include, for instance, Customer Relationship Management (CRM) or Business Intelligence (BI) systems. Using this functionality, you can produce customized analysis of your web environment using your own BI tooling, as well as integrate RUEI's rich set of collected data with offline data to obtain greater insight into what drives your sales and revenue.
The facility works by exporting the data collected every 1-minute period to a database. By default, the data is exported to the same database instance as used by the Reporter. However, it is strongly recommended that you configure an alternative database instance for enriched data export. Access to data in the export database is available via SQL. The procedure to do this is fully described in the Oracle Real User Experience Insight Installation Guide.
What Data is Available for Export?
The information captured during the monitoring of network traffic is available to you via reports and the Data Browser. Broadly, it contains two types of information: application-related and service-related information. For each type, detailed information across a wide variety of dimensions is available.
In addition to the user experience data gather by RUEI, KPI data can also be exported for customized analysis. This facility enables deep-dive analysis of the performance of your network environment and business-critical applications.
As described later in this section, you can customize the content of the exported data to include information not normally collected by RUEI. For example, the contents or value of visitors' shopping baskets.
Controlling the Availability of Exported Data
The amount of data available in the export database is controlled via the Enriched data exchange retention setting in the defined Reporter data retention policies. These are fully explained in Section 12.10.1, "Defining Reporter Retention Policies". The structure of the database tables used within the export database are described in Appendix S, "Enriched Data Export Facility". Access
Example BI Implementation Using Enriched Data Exchange
This section presents an outline of a BI solution utilizing data from the Enriched data exchange facility. In this case, it makes use of Oracle Business Intelligence foundation (part of the Oracle Fusion Middleware product family). Its schematic structure is shown in Figure S-1.
Figure S-1 Schematic Overview of Data Warehouse Staging Area
The framework is based on Oracle Warehouse Builder (OWB). The RUEI-captured data is exported to a database. From the export database, it is uploaded via SQL scripts to a staging database. This then populates the production database. Once in the production DWH, the RUEI data is available through a wide variety of reports and dashboards. An example of these reports is shown in Figure S-2.
Enabling and Disabling Enriched Data Exchange
To enable the Enriched data exchange facility, do the following:
Select Configuration, then Applications, and then Enriched data exchange. The screen shown in Figure S-3 appears.
Use the Enriched data exchange enabled/disabled check box to specify whether the Enriched data exchange facility should be enabled. Use the KPI data exchange enabled/disabled check box to specify whether the export of KPI data should be enabled. By default, both are disabled. Note that the availability of export data is determined by your Reporter data retention polices (see Section 12.10.1, "Defining Reporter Retention Policies").
Optionally, you can define additional data items to be included in the exported enriched data. Typically, these are elements in the client request or server response headers that are not normally collected by RUEI, but which you want included in the exported data. To do so, click Add new item. The dialog shown in Figure S-4 appears.
Figure S-4 Add Enriched Data Export Item Dialog
Use the Source type menu to define how the required item should be identified within the data collected by RUEI, and the scope of the search. You can specify to search within the client request header or server response header, using either a literal search or an XPath expression, or to search within a custom page-tagging implementation for a specific tag. Further information about support for custom page-tagging schemes is available in Appendix A, "Tagging Conventions".
Use the Source value field to specify the specific argument or element from which the data item's value should be taken.
Use the Export name field to specify the name to be assigned to the data item. This becomes the item's element name. In the case of a custom tag, this will appear in the CONTENT
column in the BI__BIDATA_MASTER
(see Table S-2) in the format &
name
=
value
=
. Similarly, XPath expression items would be reported in the REQUEST_HEADERS
or REPLY_HEADERS
columns. Note that the Export name field is not available if you select a header-related option in the Source type menu. In this case, the name of the header is used in the appropriate column. When ready, click Save. The new item, if found in the monitored traffic, will start to appear in the reported data within 5-10 minutes.
If your definition makes use of an XPath expression, click the Namespaces tab to define the namespaces it uses. The use of XPath expressions is described in Appendix F, "Working with XPath Queries".
Existing data items can be modified by right-clicking them within Figure S-3, and selecting Edit. You can also select Remove to delete it, or select Remove all to delete all currently defined items.
Be aware that the SQL queries used to access exported data can place a significant performance overhead on the export database. For this reason, it is recommended that you pay particular attention to the following points:
Try to limit the number of SQL queries run during a 1-minute period to a minimum. In particular, try to avoid querying the same data more than once.
Use simple SQL queries to access the required data. If particular table columns are not required, they should be dropped from the returned query.
If large volumes of data are required to be handled, you should consider the use of a separate export database. The procedure to configure an alternative database is fully described in Appendix B of the Oracle Real User Experience Insight Installation Guide.
This section explains the structure of the database tables generated by RUEI for Enriched data exchange. The table used for KPI data export is explained in Section S.3, "KPI Data Exchange Database Table Structures". These tables are located in the database (local or remote) used by your RUEI installation. They can be accessed through SQL queries.
When designing your SQL queries, it is recommended that you start by examining the relevant period table (such as WG__BIDATA_PERIOD
or WG__BIDATA_USERFLOW_PERIOD
) to see whether data for a required period has been exported. If available, you can then use the combination of PROCESSOR_ID
, PERIOD_ID
, and PAGEVIEW_ID
to access the other tables. In the case of KPI-related data, only PERIOD_ID
is required.
Due to the scalability of RUEI, most tables contains a PROCESSOR_ID
column. It indicates that data for a given interval was successfully exported from the specified Processing Engine system. This column does not appear in the KPI-related tables because KPI data is exported from the Reporter, and not from Processing Engine systems. Note that if your RUEI installation does not include any configured Processing Engines, only one row is created for each interval, with PROCESSOR_ID
reported as 0
.
The STAMP
column indicates the 1-minute interval during which the data export was triggered. As data is purged from the database, according to the specified Enriched data exchange retention policy (see Section 12.10.1, "Defining Reporter Retention Policies"), rows are removed from this table. Similarly, rows are added to the table every one minute. Note that a new row will only appear in the table if exporting of the associated 1-minute period has been completed. The availability of export data is determined by the Enriched data exchange retention setting described in Section 12.10.1, "Defining Reporter Retention Policies".
In the tables described in the following sections, columns of type VARCHAR
(such as CLIENT_REGION
) are dimensions, while those of type NUMBER
(such as DYNAMIC_NETWORK_TIME
) are data counters. An explanation of both is available in Appendix E, "Summary of Data Items".
The WG__BIDATA_PERIOD
table (Table S-1), provides an outline of the available exported page data. While the export data tables do not enforce referential integrity, the combination of the PERIOD_ID
(minutes since 1970 UTC) and PROCESSOR_ID
columns provides a link to other related tables.
The actual export page data is held in the WG__BIDATA_MASTER
table, shown in Table S-2. Within each PERIOD_ID
and PROCESSOR_ID
combination, each page view receives a unique ID, which is incremented for each page view. When a new PERIOD_ID
and PROCESSOR_ID
combination is encountered, the PAGEVIEW_ID
numbering re-starts from 1. The STAMP
column specifies the page view's true timestamp, rather than a 1-minute interval. Other columns specify the page view's properties. Note that the SESSION_ID
column provides a link to the viewed pages within specific sessions.
Table S-2 WG__BIDATA_MASTER Table
Column | Type |
---|---|
|
NUMBER |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
NUMBER |
|
NUMBER |
|
VARCHAR2 (4000 BYTE) |
|
NUMBER |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
NUMBER |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
NUMBER |
|
VARCHAR2 (4000 BYTE) |
|
NUMBER |
|
VARCHAR2 (4000 BYTE) |
|
NUMBER |
|
NUMBER |
|
NUMBER |
|
NUMBER |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
NUMBER |
|
VARCHAR2 (4000 BYTE) |
|
TIMESTAMP |
|
NUMBER |
|
NUMBER |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
NUMBER |
|
VARCHAR2 (4000 BYTE) |
|
NUMBER |
Information about the reported data items in Table S-2 is available from Section E, "Summary of Data Items".
The WG__BIDATA_PROPERTIES Table
The WG__BIDATA_PROPERTIES
table (Table S-3) contains additional page view properties. Note that while each row in the WG__BIDATA_MASTER
table refers to one page view, multiple rows in the WG__BIDATA_PROPERTIES
table can refer to the same page view.
The TYPE
column shown in Table S-3 indicates that the item refers to a custom dimension (as described in Section 3.12, "Working With Custom Dimensions"). The NAME
column specifies the name of the custom dimension.
Table S-3 WG__BIDATA_PROPERTIES Table
Column | Type |
---|---|
|
VARCHAR2 (255 BYTE) |
|
NUMBER |
|
NUMBER |
|
NUMBER |
|
VARCHAR2 (64 BYTE) |
|
VARCHAR2 (4000 BYTE) |
Information about the custom items within a page view reported in the WG__BIDATA_MASTER
table can be retrieved from the WG__BIDATA_PROPERTIES
table using a SQL query based on the appropriate PAGEVIEW_ID
.
At the highest level, the WG__USERFLOW_PERIOD
table, shown in Table S-4, provides an outline of the available exported data. While the export data tables do not enforce referential integrity, the combination of PERIOD_ID
(minutes since 1970 UTC) and PROCESSOR_ID
columns provides a link to other related tables.
The STAMP
column indicates the 1-minute interval during which the data export was triggered. As data is purged from the database, according to the specified Enriched data exchange retention policy (see Section 12.10.1, "Defining Reporter Retention Policies"), rows are removed from this table. Similarly, rows are added to the table every one minute. Note that a new row will only appear in the table if exporting of the associated 1-minute period has been completed. The availability of export data is determined by the Enriched data exchange retention setting described in Section 12.10.1, "Defining Reporter Retention Policies".
Table S-4 WG__BIDATA_USERFLOW_PERIOD
Column | Type |
---|---|
|
NUMBER |
|
NUMBER |
|
TIMESTAMP |
The actual export data is held in the WG__BIDATA_USERFLOWS
table, shown in Table S-5. Within each PERIOD_ID
and PROCESSOR_ID
combination, each user flow receives an identifier, which is a timestamp.
Each page view receives a unique PAGEVIEW_ID
, which is incremented for each page view. When a new PERIOD_ID
is encountered, the PAGEVIEW_ID
numbering re-starts from 1. Other columns specify the user flow's properties.
Table S-5 WG__BIDATA_USERFLOWS Table
Column | Type | Description |
---|---|---|
|
VARCHAR2 (4000 BYTE) |
User-defined user flow category name. |
|
NUMBER |
The monetary value assigned to the user flow. |
|
VARCHAR2 (4000 BYTE) |
User-defined user flow name. |
|
NUMBER |
Internal page view ID (unique per PERIOD_ID). |
|
NUMBER |
Timestamp. |
|
NUMBER |
Processing Engine from which the data is derived. |
|
NUMBER |
Status of user flow. The possible values are explained in Table S-6. |
|
VARCHAR2 (4000 BYTE) |
User-defined step name. |
|
NUMBER |
The number of the step within the user flow. |
|
NUMBER |
Timestamp. |
Footnote 1 This column is used for internal purposes only, and should be ignored.
The Status column indicates the current position within the user flow. Its possible values are shown in Table S-6.
Table S-6 User Flow Status Values
Status | Description |
---|---|
started |
The first user flow step has been completed. |
|
The page view matched the next step in the user flow (that is, not the first), possibly skipping optional steps. |
|
With this page view, the user returned to a previous step in the user flow. |
|
The current page view matches the current step. Therefore, while the user has not moved forwards or backwards, there is activity within the user flow. |
|
The current page view is the first of a possible series of page views not in the user flow. Note that only the first of this series is recorded in the table. |
|
The current page view matches a defined abort condition. |
|
Follows a previous |
|
Indicates that there was no activity on an uncompleted user flow for more than the user configured step idle time. Note that in this case, the reported page view is more or less random, and is the last known page view and may not necessarily be part of the user flow. |
|
Follows a previous |
|
Same as |
|
The page view completes the last step of the user flow. |
The WG__BIDATA_SUITES
table, shown in Table S-7, specifies the suite types for which export information is available. A suite type only appears in this table if a suite instance has been defined for the suite type.
Table S-7 WG__BIDATA_SUITES Table
Column | Type |
---|---|
|
NUMBER |
|
VARCHAR2 (255 BYTE) |
Footnote 1 The suite type is identified using the last part of its associated suite-specific table name. For example, a JD Edwards suite would have the table WG__BIDATA_SUITE_JDE
, and would be identified by the string"JDE".
The individual suite tables are essentially extensions of the WG__BIDATA_MASTER
table, and provide the suite-specific information associated with each page view.
Table S-8 WG__BIDATA_SUITE_EBS Table
Column | Type |
---|---|
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
NUMBER |
|
NUMBER |
|
NUMBER |
Table S-9 WG__BIDATA_SUITE_FCDB Table
Column | Type |
---|---|
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
NUMBER |
|
NUMBER |
|
NUMBER |
Table S-10 WG__BIDATA_SUITE_FCUB Table
Column | Type |
---|---|
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
NUMBER |
|
NUMBER |
|
NUMBER |
Table S-11 WG__BIDATA_SUITE_FUS Table
Column | Type |
---|---|
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
NUMBER |
|
NUMBER |
|
NUMBER |
Table S-12 WG__BIDATA_SUITE_JDE Table
Column | Type |
---|---|
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
NUMBER |
|
NUMBER |
|
NUMBER |
Table S-13 WG__BIDATA_SUITE_PSFT Table
Column | Type |
---|---|
|
NUMBER |
|
NUMBER |
|
NUMBER |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
Table S-14 WG__BIDATA_SUITE_SBL Table
Column | Type |
---|---|
|
NUMBER |
|
NUMBER |
|
NUMBER |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
Table S-15 WG__BIDATA_SUITE_WLP Table
Column | Type |
---|---|
|
NUMBER |
|
NUMBER |
|
NUMBER |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
Table S-16 WG__BIDATA_SUITE_WCS Table
Column | Type |
---|---|
|
NUMBER |
|
NUMBER |
|
NUMBER |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
The WG__BIDATAWS_PERIOD
table (Table S-17), provides an outline of the available exported service data. While the export data tables do not enforce referential integrity, the combination of the PERIOD_ID
(minutes since 1970 UTC) and PROCESSOR_ID
columns provides a link to other related tables.
Table S-17 WG__BIDATAWS_PERIOD Table
Column | Type |
---|---|
|
NUMBER |
|
NUMBER |
|
TIMESTAMP |
The actual export service data is held in the WG__BIDATAWS_MASTER
table, shown in Table S-18. Within each PERIOD_ID
and PROCESSOR_ID
combination, each page view receives a unique ID, which is incremented for each page view. When a new PERIOD_ID
and PROCESSOR_ID
combination is encountered, the CALL_ID
numbering re-starts from 1. The STAMP
column specifies the page view's true timestamp, rather than a 1-minute interval. Other columns specify the page view's properties.
Table S-18 WG__BIDATAWS_MASTER Table
Column | Type |
---|---|
|
NUMBER |
|
NUMBER |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
NUMBER |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
NUMBER |
|
NUMBER |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
NUMBER |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
TIMESTAMP |
|
VARCHAR2 (4000 BYTE) |
|
NUMBER |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
NUMBER |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
VARCHAR2 (4000 BYTE) |
|
NUMBER |
Information about the reported data items in Table S-18 is available from Section E, "Summary of Data Items".
The WG__BIDATAWS_PROPERTIES Table
The WG__BIDATAWS_PROPERTIES
table (Table S-19) contains additional service properties. Note that while each row in the WG__BIDATAWS_MASTER
table refers to one page view, multiple rows in the WG__BIDATAWS_PROPERTIES
table can refer to the same page view.
The TYPE
column shown in Table S-19 indicates that the item refers to a custom dimension (as described in Section 3.12, "Working With Custom Dimensions"). The NAME
column specifies the name of the custom dimension.
Table S-19 WG__BIDATAWS_PROPERTIES Table
Column | Type |
---|---|
|
NUMBER |
|
VARCHAR2 (255 BYTE) |
|
NUMBER |
|
NUMBER |
|
VARCHAR2 (64 BYTE) |
|
VARCHAR2 (4000 BYTE) |
Information about the custom items within a call view reported in the WG__BIDATAWS_MASTER
table can be retrieved from the WG__BIDATAWS_PROPERTIES
table using a SQL query based on the appropriate CALL_ID
.
The CLIENT_COUNTRY
reported within the exported data is based on the ISO 3166-1 standard. This uses a 2-character abbreviation (for example, AU
for Australia) to indicate the end-user's country location. However, in cases were it is not possible to determine the end-user's location, a number of special codes are reported. These are shown in Table S-20.
Table S-20 Exceptions to ISO 3166-1 Country Code Reporting
Code | Description |
---|---|
|
A local (rather than top level) domain name is used for a home network. |
|
An anonymous proxy is being used as an intermediary for requests from the client. |
|
Client access to the Internet is via an ISP satellite. |
|
A corporate proxy located in Europe is being used. |
|
A corporate proxy located in Asia or the Pacific region is being used. |
For the USA and Canada, the reported CLIENT_REGION
is based on the ISO 3166-2 standard. This uses a combination of country code and region. For example, the Texas region of the USA would be reported as US-TX
. For locations in the rest of the world, the relevant FIPS 10-4 region codes are reported. For the special country codes shown in Table S-20, the region code is reported as 00
. For example, A1-00
.
This section explains the structure of the database tables generated by RUEI for the export of KPI data. These tables are located in the database (local or remote) used by your RUEI installation. They can be accessed through SQL queries.
At the highest level, the WG__BIDATAKPI_PERIOD
table, shown in Table S-21, provides an outline of the available exported KPI data. While the export data tables do not enforce referential integrity, the PERIOD_ID
(minutes since 1970 UTC) column provides a link to the other KPI-related table, WG__BIDATAKPI_MASTER
.
The STAMP
column indicates the 1-minute period interval during which the data export was triggered. As data is purged from the database, according to the specified Enriched data exchange retention for KPIs policy (see Section 12.10.1, "Defining Reporter Retention Policies"), rows are removed from this table. Similarly, rows are added to the table every minute. Note that a new row will only appear in the table if exporting of the associated 1-minute period has been completed. The availability of KPI data is determined by the KPI data exchange retention setting described in Section 12.10.1, "Defining Reporter Retention Policies".
The actual KPI data is held in the WG__BIDATAKPI_MASTER
table, shown in Table S-22. Within each PERIOD_ID
, each KPI receives a unique KPI_ID
.
Table S-22 WG__BIDATAKPI_MASTER Table
Column | Type | Description |
---|---|---|
|
VARCHAR (255 CHAR) |
User-user KPI category name. |
|
VARCHAR (255 BYTE) |
Data access definition for KPI ( |
|
BINARY_DOUBLE |
Denominator value for period. |
|
VARCHAR (255 CHAR) |
User-defined KPI description. |
|
CLOB |
Dimension-level filters definitions. |
|
NUMBER |
Internal unique KPI ID. |
|
VARCHAR (255 CHAR) |
User-defined KPI name. |
|
BINARY_DOUBLE |
Numerator value for period. |
|
NUMBER |
Timestamp. |
|
CLOB |
Metric-level requirement definitions. |
|
NUMBER |
Periods (in minutes) over which the KPI value is calculated. |
|
NUMBER |
Status of KPI (-1=unknown, 0=fail, 1=okay). |
|
VARCHAR (255 BYTE) |
Data access suite type definition (for example, |
|
NUMBER |
KPI's maximum target value. |
|
NUMBER |
KPI's minimum target value. |
|
NUMBER |
(0=none, 1=fixed, 2=automatic). |
|
NUMBER |
Current KPI value calculated over the SPAN period. |
Footnote 1 The precise values are based on those used in the GUI, and can change.