Oracle® Real User Experience Insight User's Guide Release 6.0.1 for Linux x86-64 Part Number E16359-02 |
|
|
View PDF |
This appendix provides a detailed discussion of the support available for the accurate monitoring of WebLogic Portal (WLP)-based applications. Note that WLP support is provided as part of the default RUEI installation. No separate installation procedure needs to be applied.
RUEI supports out-of-the-box monitoring of WLP applications. It automatically discovers WLP Web applications, and translates network objects to business functions. Using this support, individual user actions are automatically matched to the correct Web application, desktop, portal, book, and page to provide contextual analysis.
RUEI supports the monitoring of file-based portals as well as streaming portals. For the latter, the Disc framework must be enabled. For the monitoring of file-based portals with the Disc framework not enabled, additional information must be uploaded about the configuration of the monitored portal. This is described in Section H.3, "Synchronizing RUEI with your WLP Environment". Note that the monitoring of streaming portals that do not use the Disc framework is not supported.
The monitoring support described in the rest of this appendix has been verified against applications based on WLP version 10.3.
You can create suite definitions for WLP-based applications in the same way as for any other supported Oracle Enterprise architecture. The procedure to create suites is described in Section 6.4, "Working With Suites".
The procedure to define a WLP suite instance is briefly summarized as following:
Select Configuration, then Applications, then Suites, and click New suite.
Specify a name for the suite instance. The name must be unique across suites, services, SSO profiles, and applications, and is restricted to a maximum of six characters. Note that it cannot be renamed later. Use the remaining fields in the dialog to specify the scope of the suite. See Section 6.4, "Working With Suites" for information on this. When ready, click Next.
Select the "WebLogic Portal" option from the Suite type menu. When ready, click Next. Upon completion, the suite definition you have specified is displayed. An example is shown in Figure 7-12.
If the monitored suite instance is a file-based portal with the Disc framework not enabled, RUEI needs to understand how the portal is implemented within your environment. Do the following:
Copy the create_WLP_info.pl
script from the /var/opt/ruei/processor/local/download/wlp
directory to the location where you intend to run the script. Copy to the same location the .portal
file used by the monitored application.
Run the create_WLP_info.pl
script on the Report system. This script creates translations for the monitored environment. The script must be run with the following required parameter:
pearl create_WLP_info.pl -portal file.portal
where file
is the name of the .portal
file used by the monitored application.
In multiple instance environments, run the script for each required instance, and separately preserve their created .txt
files. Create a separate suite definition for each instance, as described in Section H.2, "Creating WLP Suite Definitions". In addition, be aware that if you make any changes to the monitored application, you need to re-run the script, and re-import the generated .zip
file.
The script creates a number of .txt
files in the directory where the script is executed. All relevant .txt
files are collected and stored in a .zip
file. Copy this .zip
file to a location that can be used for uploading the files to the RUEI Reporter system.
Select Configuration, then Applications, then Suites, and select the suite you defined earlier in Section H.2, "Creating WLP Suite Definitions,". Click Upload Configuration. The dialog shown in Figure H-2 appears.
Specify the name of the .zip
file containing the generated .txt
files. To protect against receiving empty definitions, the upload will fail when it contains empty .txt
files. When ready, click Upload.
As explained previously, session information is based on cookies. The procedure to specify the cookie technology used by your applications is fully explained in Section 7.1, "Specifying Cookie Technology".
When creating a WLP suite instance, a preconfigured cookie for the WLP environment is automatically created. This is implemented as a custom cookie, with the name JSESSIONID
. Because WLP is based on the WebLogic technology, it is likely that the preconfigured cookie is suitable for your WLP applications. However, depending on the configuration of your environment, you may need to modify this. In addition, to enable RUEI to monitor and track users over the complete session, you should ensure the cookie path is set to "/".
RUEI supports out-of-the-box monitoring of WLP applications that employ user authentication based on the REST framework. However, if the monitored portal uses some other user authentication mechanism, then this needs to be configured. The procedure to do so is described in Section 6.2.9, "Defining User Identification".
To ensure the quality of the data being collected and reported by RUEI for your WLP-based applications, it is strongly recommended you verify their reported details. You should pay particular attention to the number of associated pages detected for the defined suite(s).
Select Browse data, then select the All pages group, and then the Applications sub-group. Within the individual dimensions, such as Pageviews and hits, you can see pageviews are reported for several applications. The suite name in the definition is shown between brackets. An example shown in Figure H-3 is for a streaming portal.
A WLP application can be identified with a hostname. Generally, a WLP suite can be accessed in two ways: using only the hostname, or using the fully-qualified hostname (including the domain). Generally, you only need to specify the domain.
Table H-1 shows how the dimensions of a WLP application are reported in RUEI.
Table H-1 WLP Definition Mappings.
Dimension level | Content |
---|---|
Application.name |
For streaming portals:
For file-based portals:
|
Application. page-group |
For streaming portals:
For file-based portals:
|
Application.page-name |
For streaming portals:
For file-based portals:
|
Where:
action
is the name of the (REST) action executed by the user. In the All pages group, only actions are reported. In the WLP group, there is also an report option for actions. At the lowest level of actions, information about the involved portlet (if available) is reported. See Section H.8, "Known Limitations" for important information.
book
is the title of the book for which a page is requested.
desktop
is the name for the desktop used for the portal.
page
is the title for the page that is requested.
portal
is the name for the portal used within the Web application.
web-app
is the name for the Web application used.
Figure H-4 shows an example of how a streaming portal is reported in RUEI.
Figure H-4 Example of WLP Application Page Reporting
Currently, RUEI does not support all WLP functionality. In particular, the following known limitations exist.
Reporting is based on the last activated area. Hence, when a end user is browsing simultaneously in multiple browser windows, the reported page name may contain incorrect information.
Reporting on portlet level is very limited. For streaming portals, when actions involve a portlet (such as "move portlet on page"), and the portlet definition label is found in the response content or the URL of the action, is the portlet definition label reported in the WLP group. In the All pages group, portlets are not reported.
For file-based portals, when the action involves a portlet, the instance label is reported because file-based portals do not have portlet definition labels. File-based portlet instance labels are only reported when a portal configuration file is upload (see Section H.3, "Synchronizing RUEI with your WLP Environment").
The monitoring of streaming portals with the Disc framework not enabled is not supported.