The history manager allows you to control for how many
visited pages navigational state you want to tracked. In other words
it controls the maximum number of pages whose state is contained in
the portal URLs. The visited pages are tracked within the navigational
state in a LRU algorithm based way.
The history manager provides a configurable threshold
to define the maximum number of pages that are tracked. If the number
of different tracked pages exceeds that threshold, the history manager
discards the page that was visited the longest time ago is dropped
out. With this page the portal also drops the state of the portlets
on this page. Furthermore, the history manager this functionality
allows you to define strategies for how to proceed with public render
parameters. Limiting the navigational state to a maximum number of
pages can reduce the length of the portal URLs.
Notes: - The history manager applies to both anonymous and authenticated
users, in other words it works on public and protected pages.
- The history manager is independent of the history expiration limit
for swapped render parameters, which determines how long render parameters
are kept for swapping into the session.
Configuration of the history manager
The
history manager provides the configuration settings listed in the
following. You configure them in the WP State Manager Service. For
details about this service and how to configure these settings refer
to the topics about
Setting service configuration properties and
Portal
configuration services, in the section about the
WP State
Manager Service.
- historymanager.enabled = (true)
- This parameter allows you to disable ( false )
or enable ( true ) the history manager. The default
value is true, that is the history manager is enabled.
- historymanager.threshold = (10)
- This parameter allows you to configure the maximum number of different
pages for which the navigational state is tracked. Set this parameter
to a positive integer value. The default value is 10 .
- historymanager.prp.removalstrategy = [no_removal | wcm_id | explicit_bucket_assignment]
- This parameter allows you to specify a strategy that defines how
to proceed with public render parameters if the history manager removes
the state of a page and the portlets on this page. As public render
parameters might be used by portlets on different pages, the removal
of public render parameters needs special handling. The possible values
have the following meaning:
- no_removal
- Public render parameters are not removed. This means that only
the portlet specific state is removed, for example private render
parameters.
- wcm_id
- Public render parameters are removed if the expired page has an
explicit shared state bucket assigned that starts with the String ibm.wcm. .
- explicit_bucket_assignment
- Public render parameters are removed if the expired page has an
explicit shared state bucket assigned, regardless of a prefix. This
is a more general strategy than wcm_id . This is
the default value.
Example scenarios
The following examples
can help explain the history manager functionality. For all examples
the maximum configured number of pages that are tracked in the navigational
state is set to
3 .
- Example 1:
- A user visits portal pages in the following order: P1, P2, P3,
P4. When the user navigates to page P4, the history manager removes
the navigational state of page P1 and the states of all portlets on
that page from the state.
- Example 2:
- A user visits portal pages in the following order: P1, P1, P2,
P3, P2, P3, P1. The history manager removes no state.
- Example 3:
- A user visits portal pages in the following order: P1, P2, P3,
P1, P4. When the user navigates to page P4, the history manager removes
the navigational state of page P2 and the states of all portlets on
that page.