Creating Private Events Enhancing PDK-Java Portlets

7-32 Oracle Fusion Middleware Developers Guide for Oracle Portal

7.2.6 Accessing Session Information

When a user accesses any portal page, Oracle Portal initiates a public unauthenticated session and maintains a cookie to track information about the session across requests. If the user logs in to Oracle Portal, this session becomes an authenticated session of the logged-in user. This portal session terminates when the any of the following occur: ■ The browser session terminates that is, the user closes all the browser windows. ■ The user explicitly logs out. ■ The session times out because the users idle time exceeds the configured limit. As part of the metadata generation, Oracle Portal contacts all of the providers that contribute portlets to the page, if they specify during registration that they get called for some special processing. This call allows providers to do processing based on the user session, log the user in the providers application if needed, and establish provider sessions in Oracle Portal. For Database providers, this call is referred to as do_login and for Web providers it is initSession. Since most Web-enabled applications track sessions using cookies, this API call allows the provider of the application to return cookies. You can utilize the session store to save and retrieve information that persists during the portal session. This information is only available, and useful, to you during the life of the session. You should store only temporary information in the session store. Application developers may use the session store to save information related to the current user session. Data in the session store can be shared across portlets. If the information you want to store must persist across sessions, you may want to store it in the preference store instead. Some common applications of the session store are as follows: ■ to cache data that is expensive to load or calculate for example, search results. ■ to cache the current state of a portlet for example, the current range, or page, of search results displayed in the portlet, or sequence of events performed by user. Before you implement session storage, you should carefully consider the performance costs. Because portlets and providers are remote, it can be a relatively expensive operation to create and maintain even a small amount of information in the session store. For this reason, you may want to avoid altogether any session storage for public pages that are accessed frequently by many users. If scalability is an important concern for you, a stateful application may cause you problems. Stateful applications can impact the load-balancing and failover mechanism for your Oracle Portal configuration. Even though you may deploy multiple Note: When you use this technique, you must take care that the details of your event are persisted somewhere. Since portlet rendering does not happen in the same request cycle as the event processing, any data from the event required to render the portlet must be available from storage. Otherwise, the portlet or the page may lack the data it requires the next time it is rendered. If you need to persist your data, be sure to store it in a qualified manner by the user and portlet reference. Otherwise, you may accidentally associate an event from one userportlet with the rendering of the same portlet for another user on a different page, or even associate the same usersame portlet with a different portlet reference on the same page. Enhancing Java Portlets 7-33 middle-tiers accessing the same Oracle Portal instance, you must implement sticky routing where the same node handles subsequent requests in the same session to track state. Sticky routing may result in lopsided load-balancing or loss of session data in case a node crashes, impacting failover. This issue is one reason why many developers prefer to build stateless applications. However, if scalability is not a concern, then a stateful application should present no problems for you. In the example in this section, session storage is used to count the number of times your portlet has rendered in Shared Screen mode.

7.2.6.1 Assumptions

To perform the tasks in this section, we are making the following assumptions:

1. You have followed through and understood

Section 6.5, Building Oracle PDK-Java Portlets with Oracle JDeveloper .

2. You built a portlet using the wizard and successfully added it to a page.

7.2.6.2 Implementing Session Storage

The PDK Framework represents the session with a ProviderSession object, which is established during the call to the Provider Instances initSession method. This object is associated with the ProviderUser. To make data persistent between requests from Oracle Portal, you need to write data into the session object using the setAttribute method on the ProviderSession object. This method maps a java.lang.Object to a java.lang.String and stores that mapping inside the session object. The String can then be used to retrieve the Object during a subsequent request, provided the session is still valid. A provider session may become invalid for the following reasons: ■ The session times out. ■ The invalidate method on ProviderSession is called. ■ The JVM process running the servlet container is terminated. All portlets contained by the same ProviderInstance share the same session for a particular ProviderUser. Therefore, data unique to a particular portlet instance must be mapped to a unique String in the session. This is accomplished using the portletParameter method in the PortletRendererUtil class. This method makes a supplied String parameter or attribute name unique to a PortletInstance, by prefixing it with a generated identifier for that instance. You can use the returned instance-specific name to write portlet instance data into the session. For more detailed information on the PDK Framework classes, refer to the Javadoc on OTN by clicking Java Doc API on the Portlet Development page available at http:www.oracle.comtechnologyproductsiasportalportlet_development_ 10g1014.html To implement session storage, you need to perform the following tasks: ■ Import ProviderSession, PortletRendererUtil, and HttpPortletRendererUtil. ■ Retrieve the provider session. ■ Read and write the session by accessing it from within your Java portlet. ■ Set the session to true in provider.xml. 7-34 Oracle Fusion Middleware Developers Guide for Oracle Portal ■ Register the provider for session storage and set the Login Frequency. The steps that follow describe how to add a session count to your portlet that displays how many times the portlet has been rendered for the current session. 1. After using the wizard to create a portlet, you can edit the JSP for the Show page in Oracle JDeveloper. You need to import the following classes: page contentType=texthtml; charset=windows-1252 import=oracle.portal.provider.v2.render.PortletRenderRequest import=oracle.portal.provider.v2.http.HttpCommonConstants import=oracle.portal.provider.v2.ProviderSession import=oracle.portal.provider.v2.render.PortletRendererUtil import=oracle.portal.provider.v2.render.http.HttpPortletRendererUtil 2. Insert code that checks for a valid session first and then increments the count and displays it. If the session is valid and a previously stored value exists, you display the value, increment the count, and store the new value. If the session is valid but no previously stored value exists, you initialize a new count starting with 1, and display and store the value. You also want to obtain the unique string key for this portlet and then use an it in an array to count the session. If no session information was received, you want to provide information to the user indicating they may need to log back in. PortletRenderRequest pReq = PortletRenderRequest request.getAttributeHttpCommonConstants.PORTLET_RENDER_REQUEST; ProviderSession pSession = pReq.getSession; if pSession = null { String key = PortletRendererUtil.portletParameterpReq, count; Integer i = IntegerpSession.getAttributekey; if i == null { i = new Integer0; } i = new Integeri.intValue+1; pSession.setAttributekey, i; pRender count in this session: =i p } else { pThe session has become invalidp br Please log out and log in again. } 3. By default, the wizard does not set session to true in provider.xml. You need to update this flag in order for the provider to receive session information from the portal. You should only set this tag to true if you are using session information in