| Oracle® Fusion Middleware Federated Portals Guide for Oracle WebLogic Portal 10g Release 3 (10.3.6) Part Number E14235-07 |
|
|
View PDF |
| Oracle® Fusion Middleware Federated Portals Guide for Oracle WebLogic Portal 10g Release 3 (10.3.6) Part Number E14235-07 |
|
|
View PDF |
This chapter focuses on best practices for developing portlets in a producer. By following the practices described in this chapter, you will help to ensure that remote portlets created in consumers function properly. We recommend that you review Chapter 3, "Federated Portal Architecture" before using this chapter.
This chapter the following sections:
Section 14.5, "Avoid Accessing Request Parameters in Rendering Code"
Section 14.10, "Portlet Programming Guidelines and Best Practices"
Section 14.14, "Managing Delivery of Headers and Cookies to the Browser"
As explained in Section 3.5, "Life Cycle of a Remote Portlet", the rendering and interaction phases of a remote portlet's life cycle are decoupled. As a result, you cannot expect a portlet to receive the same HTTP response or request for the render phase as it receives for an interaction.
A portlet that is being rendered must not expect to receive form data in the request object. This is because the request may have been submitted some time ago and is being rendered now, and you may not have the same data.
If you want to maintain data between requests, you need to store that data locally, typically in the session. For instance, if you are processing and order ID, you can store that ID locally.
If you are using page flows, data is automatically passed forward. However, if you are using backing files with a remote portlet, you need to make sure that data is stored in the session, because you won't get back the same request object.
Note:
Page flows are a feature of Apache Beehive, which is an optional framework that you can integrate with WLP. See "Apache Beehive and Apache Struts Supported Configurations" in the Oracle Fusion Middleware Portal Development Guide for Oracle WebLogic Portal.
To avoid problems, keep the following points in mind:
Portlets will not get the same servlet request for the interaction and render phases, even after the first rendering after an interaction.
Decouple rendering from interaction processing. A portlet should be able to render itself as many times as necessary without depending on the user's interaction directly. Store interaction changes for future rendering. Note that WebLogic Portal stores state automatically for page flows.
Use JSP tags with render parameters.
Use HTTP session for backing files.
Rather than create explicit dependencies between portlets, use events to communicate between portlets. For example, suppose that on a portal page, there is a portlet for collecting orders and a portlet for displaying the status of all orders. When an order is taken, data is stored in the database, and the data is then displayed in the order status portlet, as shown in Figure 14-1.
In this scenario, a strong dependency is created between the collect order and the order status portlets. The Collect Order portlet needs to somehow communicate some information (the order ID) to the Order Status portlet. Storing the ID in the session or other common state between the portlets creates a strong dependency between the Collect Order and Order Status portlets. Depending on the implementation of the portlets, if one of them is changed or replaced, the changes will necessarily affect the other portlet.
To avoid this dependency, use events to communicate between portlets. In this example, if an event is used to communicate order information to the order status portlet, the order status portlet does not have to care about where the order came from. The order status portlet just handles an event, retrieving, for example, an order ID from the event's payload.
For more information on how event handling occurs in WebLogic federated portals, see Section 3.5.4, "Interportlet Communication with Events".
Use events to communicate between remote portlets.
Use event names for dependencies.
Avoid using sourceDefinitionLabels on events.
Some portals are built with inherent portal layout dependencies. For example, a login portlet might be designed to function differently if it is on a human resources page versus a finance page. In other words, when an interaction takes place, the portlet tries to find out what page it is on before taking action. This practice closely couples the portlet to the Portal Framework elements, such as pages, books, or desktops on the consumer.
This scenario does not work in a federated portal, because the producer does not know what page layouts exist on the consumer. Avoid this scenario when possible. If it is required, deploy those portlets locally on the consumer, or use shared components where possible and create alternative layouts that are offered through separate portlets.
If you embed URLs in your portlets, such as in links, you may find that your portlets work as expected when they are running locally. However, when you move those portals to a federated environment, the links no longer work. For example, in the following code fragment, a developer is invoking the action of a page flow portlet on the same portal using string manipulation.
Note:
Page flows are a feature of Apache Beehive, which is an optional framework that you can integrate with WLP. See "Apache Beehive and Apache Struts Supported Configurations" in the Oracle Fusion Middleware Portal Development Guide for Oracle WebLogic Portal.
In a federated portal, this sort of construction will not work. Typically, this sort of programming arises because of reverse engineering, where a developer looks at and copies how links are created.
String url = "http://mydomain.com/portal/portal.portal?"; url = url + "myportlet_actionOverride=login"; url = url + "...";
Likewise, the following resource URL will not work in a federated portal because it includes an explicitly specified link to a document. Because the document doesn't exist on the consumer, the consumer doesn't know what to do with it:
<img src="images/logo.jpg"/> <a href="/docServlet?docId=9999">Download</a>
Common URL problems found in federated portals include the following. These problems stem from the fact that remote portlets do not follow the same URL structure as portlets in a local environment.
Creating links to page flow actions, images or files through string manipulation.
Note:
Page flows are a feature of Apache Beehive, which is an optional framework that you can integrate with WLP. See "Apache Beehive and Apache Struts Supported Configurations" in the Oracle Fusion Middleware Portal Development Guide for Oracle WebLogic Portal.
Directly adding parameters to URL strings.
Getting a page flow action name from the outer request.
It is important that you let the WebLogic Portal Framework create URLs for you using the proper set of JSP tag libraries and utility classes. Use the following tags and classes:
netui tags
page flow tags
struts tags
render tags
GenericURL class
All of these tags go through the WebLogic Portal URL rewriters and will work properly in a federated environment.
It is important to realize that there are inherent differences between remote portlets and local portlets. Developers must not expect that all correctly functioning local portlets will function properly as remote portlets, although in many cases they do.
When you deploy a local portlet, the portlet can access the request parameters from the portal's request and the request attributes set by other portlets on the same page. If you implement a portlet to depend on such request parameters and attributes, the portlet will not function correctly in a WSRP environment. In a WSRP environment, remote portlets are running on remote systems; the HTTP request received by a remote portlet on a producer is not the same as the one that is received by the consumer portal.
When you add producers and create remote portlets, the producer registry (WEB-INF/wsrp-producer-registry.xml) and the portal framework database tables contain specific information about the producer, such as its WSDL address and the addresses of ports described in the WSDL. If you move the producer from one environment to another, this data becomes invalid. In this case, consumers whose proxy portlets reference the producer's portlets will no longer be able to find them.
If you must move a producer from one environment to another (such as a staging to a production environment) WebLogic Portal supports two mechanisms for achieving this.
The first mechanism, shared registration, is only recommended for WebLogic Portal producers older than version 10.0. With shared registration, the staging and production environments share the same producer registration handle. This model has a number of serious drawbacks. Only use this model when the producer is a version of WebLogic Portal prior to 10.0. For more information on shared registration and propagating WSRP producers in this case, see the Oracle Fusion Middleware Production Operations Guide for Oracle WebLogic Portal.
The second mechanism is recommended for producers, such as WebLogic Portal versions 10.0 and higher, that support WSRP 2.0 exportPortlet and importPortlet operations. When producers are propagated using these operations, producer registration handles do not need to be shared. The propagation tool in WebLogic Portal versions 10.0 and higher handles these operations automatically. See the Oracle Fusion Middleware Production Operations Guide for Oracle WebLogic Portal for details.
You can also update the database entries for a producer programmatically. The following class provides methods to get and update producer information:
com.bea.wsrp.consumer.management.producer.ProducerManager
Refer to the Oracle Fusion Middleware Java API Reference for Oracle WebLogic Portal for information on this class.
In some cases, you may want to expose portlets with WSRP from a producer environment that does not include any WebLogic Portal components. For example, you may be running a Struts Web application in a Basic WebLogic Server Domain, or a Java Page Flow application in a Basic Oracle Enterprise Pack for Eclipse Domain. In either case, WebLogic Portal is not part of the server configuration. For detailed information on using a non-portal server domain to host remote portlets, see Chapter 8, "Configuring a WebLogic Server Producer."
Note:
Page flows are a feature of Apache Beehive, which is an optional framework that you can integrate with WLP. Apache Struts is also an optional framework that you can integrate with WLP. See "Apache Beehive and Apache Struts Supported Configurations" in the Oracle Fusion Middleware Portal Development Guide for Oracle WebLogic Portal.
If you are using a Portal Web application as your producer, all the portal artifacts are available in the web application; however, for any WSRP producer that is not a Portal Web application, you cannot use portal features such as property sets. If you need to access portal features in your producer, use a Portal Web application.
Securing WSRP messages ensures their confidentiality between just the interested parties. When a portlet's messaging is secure, only parties authorized to handle the contents of that portlet's messages can see those messages. To secure WSRP messages:
Use SSL on any port through which the Producer will be offered.
Configure the Producer to offer secure portlets by specifying true for all secure attributes in the <service-config> element of the Producer project's WEB-INF/wsrp-producer-config.xml file, as shown in Example 14-1.
If you make any changes to wsrp-producer-config.xml, you will need to redeploy or restart the server before the changes become active.
For detailed information on configuring single sign-on security for federated portals, see:
Chapter 15, "Establishing WSRP Security with SAML" – Discusses how to configure SAML security between WebLogic Portal domains. This chapter also covers cross version compatibility: security between WebLogic Portal 9.2 and 8.1x domains.
Chapter 16, "Configuring User Name Token Security" – User Name Token, or UNT, is an alternative to SAML and provides the same basic single sign-on capability as SAML provides.
This section gives an overview of error handling techniques for federated portals.
To prevent stack traces from appearing, handle errors on the producer side and provide a suitable business message.
In Oracle Enterprise Pack for Eclipse, with a remote portlet open:
Click the portlet in the editor to display the Properties view.
Enter a path for the error page (JSP or HTML page).
You can use interceptors to handle errors returned from a producer. For instance, if a specific producer is not registered, you can trap the registration error and handle it as you wish. For detailed information on using interceptors, see Chapter 9, "The Interceptor Framework."
This section discusses guidelines and best practices for developing remote portlets.
Requests and Sessions
If two or more remote portlets share session data, host them on the same producer. You cannot assume that session information will be shared by portlets hosted on different systems.
Look and Feel
Let portlets use standard style attributes and specify those attributes on the portal skins. For information on look and feel, see the Oracle Fusion Middleware Portlet Development Guide for Oracle WebLogic Portal.
Backing Files
You can use backing files on the consumer side (remote-portlet) to take some action based on session / request objects or property sets. For information on backing files, see the Oracle Fusion Middleware Portlet Development Guide for Oracle WebLogic Portal.
Caching WSRP Portlets
Producer – Use <wl:cache> or p13nCache wherever possible.
Consumer (remote-portlet) – Use the RenderCacheable attribute if you want to cache the remote portlet's rendered HTML. However, this is a session scoped cache and is not configurable.
For more information on caching, see the "Portlet Caching" section of the Oracle Fusion Middleware Portlet Development Guide for Oracle WebLogic Portal.
To ensure optimal performance of your producers and consumers, we recommend the following performance tuning guidelines on the producer and the consumer.
This section lists several ways to improve the performance of producer applications.
One way to improve performance on the producer is to make sure the SAML Authentication Provider is deployed in front of other authentication providers. To reorder the providers:
Log in to the WebLogic Server Administration Console.
Select Security Realms in the Domain Structure tree.
In the Realms table, select the active security realm used by the producer application.
In the Settings page, select the Providers tab.
In the Change center, click Lock & Edit.
Below the Authentication Providers table, click Reorder.
In the list of providers, use the arrow buttons to move SAMLAuthenticator to the top of the list, and click OK.
In the Change center, click Activate Changes.
Enable attachment support by adding <markup transport="attachment"/> to WEB-INF/wsrp-producer-config.xml, as shown in Example 14-2.
Example 14-2 Enabling Attachment Support
<?xml version="1.0" encoding="UTF-8"?>
wsrp-producer-config
xmlns="http://www.bea.com/servers/weblogic/wsrp-producer-config/8.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.bea.com/servers/weblogic/wsrp-producer-config/8.0
wsrp-producer-cnfig.xsd">
<service-config>
<registration required="false" secure="true"/>
<service-description secure="true"/>
<markup secure="true" rewrite-urls="true" transport="attachment"/>
<portlet-management required="false" secure="true"/>
</service-config>
Let the producer create correct URLs by using consumer-supplied URL templates. This is the default practice.
Use caching. For more information on caching, see the section "Portlet Caching" in the Oracle Fusion Middleware Portlet Development Guide for Oracle WebLogic Portal.
Enable multi-threaded (forked) rendering. For more information, see the section "Portlet Forking" in the Oracle Fusion Middleware Portlet Development Guide for Oracle WebLogic Portal.
Accept the default behavior to enable caching for remote portlets.
Enable forked rendering for remote portlets.
Set connection timeout. See Section 5.6, "Setting a Timeout Value on a Remote Portlet" for detailed information on setting timeouts.
Disable logging by undeploying MessageMonitor servlet from WEB-INF/web.xml.
Local proxy support allows co-located producer and consumer web applications to short-circuit network I/O and "SOAP over HTTP" overhead. When you enable this feature, the consumer tries to determine if the producer is deployed on the same server and, if it discovers that the producer is so deployed, it uses a local proxy to send requests to the producer. If the producer is not deployed on the same server, the consumer uses the default remote proxy. Remote producers can still be invoked as usual even when the local proxy support is enabled.
This section describes how to implement local proxy support. It includes information on the following subjects:
Local proxy mode provides a number of advantages over the default remote proxy when you are working with co-located consumers and producers. Among the most significant advantages of local proxy mode are:
Avoids local network I/O.
Avoids serialization and deserialization of SOAP.
Invokes remote portlets using the same execute thread.
Writes portlet markup directly to the response without intermediate buffers.
Enables large file uploads without causing OutOfMemoryErrors.
Additionally, by enabling local proxies, customers can take advantage of the decoupling benefits of WSRP without incurring its performance overhead.
To take advantage of local proxy support:
Deploy the producer and consumer web applications on the same server. These applications could be in the same enterprise application or across different enterprise applications.
Enable local proxy support by setting <enable-local-proxy> to true in WEB-INF/wsrp-producer-registry.xml in the consumer web application, as shown in Example 14-3:
Example 14-3 Setting <enable-local-proxy> to "true"
<wsrp-producer-registry
xmlns="http://www.bea.com/servers/weblogic/wsrp-producer-registry/8.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.bea.com/servers/weblogic/wsrp-producer-
registry/8.0 wsrp-producer-registry.xsd">
<!-- Upload limit (in bytes) -->
<upload-read-limit>1048576</upload-read-limit>
<!-- Timeout (in milli seconds) -->
<connection-timeout-secs>120000</connection-timeout-secs>
<!-- Enable local proxy -->
<enable-local-proxy>true</enable-local-proxy>
...
</wsrp-producer-registry>
You can also enable local proxy support by setting a system property com.bea.wsrp.proxy.LocalProxy.enabled = true. If this system property is set to true, it will override the <enable-local-proxy> setting in WEB-INF/wsrp-producer-registry.xml.
Local proxy support is disabled by default in web application templates.
Figure 14-2 compares the layers of operations involved when local proxy support is enabled (top flow diagram) and when it is not (bottom flow diagram). In the local proxy case, there is no network or SOAP related overhead and the servlet API is used for communication.
Figure 14-2 Local Versus Remote Proxy Flow Diagrams
Note:
It is a recommended practice to enable local proxy mode when you deploy JSR-168 portlets using the JSR-168 Import Utility. As far as performance and complexity are concerned, there is no difference between the way JSR-168 portlets and WSRP local proxy interoperate in WebLogic Portal versus other vendors. For more information on the import utility, see the section "Deploying JSR-168 Portlets in a WAR File" in the Oracle Fusion Middleware Production Operations Guide for Oracle WebLogic Portal.
Table 14-0 summarizes the evolution of the WebLogic Portal local proxy architecture.
Table 14-1 Evolution of Local Proxy Architecture for WebLogic Portal
| Version | Local Proxy Architecture |
|---|---|
|
WLP 8.1x |
Exchange XmlBeans between consumer and producer. |
|
WLP 9.2 |
Convert POJOs into XmlBeans while sending data from the consumer to the producer. |
|
WLP 10.0 |
Exchange POJOs between the consumer and the producer. |
As powerful a tool as local proxy support is, you should only use it when it will benefit your application. The most common reasons for using local proxy support are:
When portlets are deployed in self-contained web applications on the same server. The local proxy support provides isolated portlet deployment. In this mode, each portlet web application can be deployed as a WSRP producer. Portlets can therefore be loaded by separate class loaders and have their own servlet context and session. Portlet web applications can be deployed/undeployed without affecting the portal web application.
When you don't need advanced monitoring software between the producer and consumer.
On the other hand, you should not use local proxy support when interoperating with non-Oracle producers and consumers.
You can monitor activity between producers and consumers by using the message monitor servlet installed with Oracle Enterprise Pack for Eclipse. You can also create custom logs to display specific information about WSRP sessions. These features can help you debug problems with remote portlets.
This section contains information on these subjects:
To monitor the response and request headers, as well as the action SOAP messages that are passed between producers and consumers:
Ensure that the producer and consumer applications whose communication you want to monitor are running.
Open a new browser and enter the following URL:
host:port/webProject_name/monitor
Where:
host:port is the host and port you want to monitor. This can be the host and port of either the producer or consumer server.
webProject_name is the web project you want to monitor.
For example:
http://localhost:7001/wsrpMonitorTest/monitor
The monitor appears in the browser. Click Enable to start monitoring. Click Refresh to see the latest transactions. Click Clear to remove all messages from the browser window.
Tip:
The monitor does not display new transactions until you click Refresh.
Each time the remote portlet communicates with the producer, a request and response message headers appear on the monitor screen, as shown in Figure 14-4.
Figure 14-4 Monitor Appearing in a Browser
By clicking Show, you can display the content of the request or the response, as shown in Figure 14-5. Click Hide to close the message content.
To create custom logs, we recommend that you use the Interceptor Framework described in Chapter 9, "The Interceptor Framework."
You can also create custom logs that display particular information about a WSRP session by using Logger and Handler objects instantiated by WebLogic Server. You can use these objects to create your own message handlers and subscribe them to loggers. For example, if you want the remote portlet to listen for the messages that the producer generates, you can create a handler and subscribe it to a logger in the producer. For detailed information on using Logger and Handler objects, see "Filtering WebLogic Server Log Messages" in Oracle Fusion Middleware Configuring Log Files and Filtering Log Messages for Oracle WebLogic Server.
The WSRP 2.0 clientAttributes feature permits the producer to send cookies and headers to the client (browser) application. Before WSRP 2.0, cookies were retained and managed by the consumer and returned to the producer. The browser never received cookies directly. This limitation made it difficult to share cookies between different producers in the same domain. In addition, before WSRP 2.0, the consumer removed header information from the response before forwarding the response to the browser. This limitation restricted the use of certain browser operations, such as using the content-disposition header to allow the browser to display the "Save As" dialog box before opening a file when the resource was clicked inside the producer portlet.
The best practice for setting cookies and headers that you want to send to the client (browser) is to set them in the portlet's pre-render code. This practice is the best way to ensure that the cookie or header will reach the browser. For example, if you are using a portlet backing file, set the cookies or headers in the preRender() method. For information on backing files, see "Backing Files" in the Oracle Fusion Middleware Portlet Development Guide for Oracle WebLogic Portal.
Although not a best practice, if you want to set cookies or headers in the portlet's render code, you can set an option on the consumer to prevent the consumer from flushing responses until the buffer fills. While this can allow cookies and headers to reach the browser, more server resources are required to cache the entire response during rendering. If you want to use this feature, set the <avoid-response-commit> element to true in WEB-INF/wlp-framework-common-config.xml. See also "Avoiding Comitting Responses" in the Oracle Fusion Middleware Portlet Development Guide for Oracle WebLogic Portal.
This setting avoids committing the response until all the portlets have rendered or until the buffer fills. This behavior differs from the WLP default behavior, which is to stream responses without caching them.
Tip:
If the buffer fills and thereby begins to render before all the portlets' render() methods are called, the last portlet headers and cookies will be lost. That is why it is best practice to set headers and cookies in the preRender() method.
WLP always sends cookies and response headers from the consumer to the browser. However, as mandated by the WSRP 2.0 specification, anything represented elsewhere in the specification, such as content-type, content-length, transfer-encoding, and user-agent, are not sent. In addition, some headers that are not useful to transmit are not sent, like accept-ranges, age, and proxy-authenticate. The same is true for request headers from the client. To override this default behavior, the best option is to write an interceptor. For information on interceptors, see Chapter 9, "The Interceptor Framework."
WLP provides two producer-side settings that you can use to control the way client attributes (headers and cookies) are handled. Both of these settings can be configured in the WEB-INF/wsrp-producer-config.xml file on the producer.
isPreferClientCookies – Sets whether or not the producer will use the cookie sent from the client (browser) or from the consumer in the event of a name collision. True = prefer from client (browser). False = prefer from consumer. (Default: false)
headerMode – Sets where headers and cookies are sent. Possible settings are Consumer, Client, or Both. The default is Both. The Client setting specifies that headers and cookies set by the portlet will be directed to go to the client. (browser). The Both setting specifies that headers and cookies set by the portlet will be directed to go to the client and the consumer. If you do not want headers to be sent to the client (browser), set this attribute to Consumer.
Tip:
You can also set the header mode in Java portlets using a Container Runtime option: com.oracle.portlet.wsrpHeaderMode. For information on container runtime options, see "Using Container Runtime Options" in the Oracle Fusion Middleware Portlet Development Guide for Oracle WebLogic Portal.
If the browser receives a cookie with a domain attribute value that is different than the domain it connected to, the browser will reject the cookie. By default, WLP forwards all cookies from the producer to the browser without interfering in any way, except for the handling of the JSESSIONID cookie for security reasons (see Section 14.14.6, "Managing Security Between Consumer and Producer"). If you want to manipulate a cookie before it is sent from the consumer to the browser, you can do so by writing an interceptor. For details, see Chapter 9, "The Interceptor Framework."
WSRP 2.0 does not define, and WLP does not support, the notion of rewriting URLs inside of cookies or headers.
If you use secure cookies, be sure that you are using a secure transport protocol (for example, HTTPS) between the consumer and the client (browser).
In most cases, the connection between browsers and consumers lies outside the network's DMZ. Likewise, the consumer to producer connections generally lie behind the network's DMZ. If you want to avoid the network overhead of using HTTPS behind the DMZ, you can use an insecure protocol (like HTTP) for the consumer to producer connection.
Caution:
If you use an insecure connection between consumer and producer, the SOAP messages between the consumer and producer can contain cookies that are destined for the browser. If you intend these cookies to be secure, then it is recommended that you use a secure channel between consumer and producer. For more information, see Section 14.8, "Security for Remote Portlets."
For more information, see Section 14.8, "Security for Remote Portlets."
For security reasons, the JSESSIONID cookie from the producer is not sent to the browser. In addition, if a cookie is set as isSecure, the cookie is sent to the browser only if the communication between client and consumer is secure. Note that it is possible to receive a secure cookie on the browser even though the producer and consumer communication may be on an insecure protocol. This scenario allows a consumer and producer that are both behind a company firewall in the same domain to communicate and still issue secure cookies to the client (browser).
This section describes techniques for preventing the loss of the consumer session when resource requests are made to a remote portlet. These techniques include:
If you have a remote portlet that contains images, WebLogic Portal sends cookies and other headers from the producer to the browser when an image resource is requested. Note that when resource requests are made to a portlet in a producer, it is possible for the user's browser to drop or lose the consumer session. This situation occurs when the producer and consumer are configured to include only the default path ("/") in the session cookies, which causes the browser to replace the Set-Cookie header set by the consumer with the Set-Cookie header set by the producer.
To prevent this potential loss of the consumer session, open weblogic.xml, and configure your web applications to include the domain name and web application path for session cookies. This technique prevents the cookie names from overlapping. See "session-descriptor" in Oracle Fusion Middleware Developing Web Applications, Servlets, and JSPs for Oracle WebLogic Server for details on how to set the domain name and path.
In most cases, using different cookie names solves the problem of lost consumer sessions following resource requests. In some cases, however, this solution does not work. One such use case is when single sign-on is used with the producer and consumer running in the same domain. In this case, identical cookie names are required. For cases where using different cookie names does not work, set the following system property:
wlp.resource.proxy.servlet.block.response.headers=true
By enabling this system property, WebLogic Portal prevents a Set-Cookie header from being sent back to the user's browser. This property prevents the consumer's cookie from being overwritten by the producer's cookie on the browser when a resource is returned. Using this technique, you can keep the cookie names the same for both the producer and consumer applications, which is required for single sign-on.
To block cookies to the browser, set <resource-cookies> to block-all in WEB-INF/wsrp-producer-registry.xml in the consumer web application, as shown in Example 14-4. When this element is set to block-all, the resource proxy servlet does not transfer any cookies from the producer resource to the browser. Cookies are not blocked by default. The default setting is block-none.
Example 14-4 Blocking Cookies to the Browser
<wsrp-producer-registry
xmlns="http://www.bea.com/servers/weblogic/wsrp-producer-registry/8.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.bea.com/servers/weblogic/wsrp-producer-
registry/8.0 wsrp-producer-registry.xsd">
<!-- Upload limit (in bytes) -->
<upload-read-limit>1048576</upload-read-limit>
<!-- Timeout (in milli seconds) -->
<connection-timeout-secs>120000</connection-timeout-secs>
<!-- Enable local proxy -->
<enable-local-proxy>true</enable-local-proxy>
<!-- Block cookies to the browser -->
<resource-cookies>block-all</resource-cookies>
...
</wsrp-producer-registry>
User sessions on CWEB applications might be lost if session cookies between producers and consumers overlap. To prevent this, open weblogic.xml, configure your web applications to include the domain name and web application path for session cookies. See "session-descriptor" in Oracle Fusion Middleware Developing Web Applications, Servlets, and JSPs for Oracle WebLogic Server for details on how to set the domain name and path.
Whenever multiple views of a remote portlet are created, links in the portlets can be inconsistent and not work properly. Typically, multiple views occur when a remote portlet uses the popup mechanism in a page flow, or when a user floats a remote portlet using the portlet Float button.
Note:
Page flows are a feature of Apache Beehive, which is an optional framework that you can integrate with WLP. See "Apache Beehive and Apache Struts Supported Configurations" in the Oracle Fusion Middleware Portal Development Guide for Oracle WebLogic Portal.
If a WebLogic Portal producer is set up to use consumer-supplied URL templates, the producer caches those templates in a session created on the producer. However, when multiple views of a portlet are created either through the page flow popup mechanism, or through a Float button, the cached templates may not be valid for the current view.
You can correct the inconsistent links using one of these methods:
Disabling the caching of templates for your remote portlets. To do this, in the .portlet file for each remote portlet that is affected, change the value of the templatesStoredInSession element to false.
Configure the producer to require consumer rewriting. To do this, set the rewrite-urls element to FALSE in the wsrp-producer-config.xml file.
If the user's identity changes while a request generated from the portal is in progress, remote portlets can behave inconsistently. Typically, this occurs when the portal desktop includes a portlet or other mechanism for logging in and logging out a user. If the user identity changes, any user-specific data loaded by the portal can become invalid. In the case of remote portlets, such data includes their persistent state. When user identity changes, the consumer portal can send incorrect persistent state data to producers.
To avoid this problem, be sure to always use a browser redirect call immediately after a login or logout. The browser redirect ensures that data loaded by the portal is valid for the request.
This section discusses the Store Registration Properties feature and why enabling it is generally recommended.
When you register a producer either using Oracle Enterprise Pack for Eclipse or the WebLogic Portal Administration Console, you have the option of storing registration property sets on the consumer. Registration properties are values that are passed from the consumer to the producer when the producer is registered. These values can be used to allow producers to control which portlets are offered to specific consumers.
Tip:
For detailed information on consumer entitlement and creating registration property sets, see Chapter 11, "Consumer Entitlement."
This section explains why storing registration properties is the recommended procedure for storing registration properties using both Oracle Enterprise Pack for Eclipse and the Administration Console. This section includes these topics:
It is recommended that you choose to store registration properties when you register a producer. This option provides these advantages:
If the producer is unable to provide registration properties, they are still available to your portal application. The producer may be unable to provide registration properties if:
The producer is not a WebLogic Portal 10.2 or later version. The WSRP extension for providing registration properties from the producer does not work with WebLogic Portal 10.0 or older versions or with third-party producers.
The producer is configured not to offer support for the WSRP registration property extension. Typically, the a producer is configured in this way to prevent sending registration property values back from the producer as a security measure. In this case, you might consider it to be acceptable to store the registration property values on the consumer and retain the benefits of registration property storage.
The producer is temporarily unavailable.
If you choose to modify the registration properties for a producer, the Modify Registration Properties dialog box will always be filled in with the currently used registration properties. The procedure for modifying registration properties is described in Section 20.2, "Modifying Producer Registration Properties".
The Store Registration Properties check box is provided in the Enter Producer Properties dialog of the Add Producer Wizard, as shown in Figure 14-6. (The complete procedure for registering producers is discussed in detail in Chapter 18, "Adding Remote Resources to the Library.")
Figure 14-6 Store Registration Properties Option
You can change the value of the Store Registration Properties check box in the WebLogic Portal Administration Console. Go to the Summary tab of the producer and click Producer Properties to bring up the Update Producer Url dialog. This dialog lets you change the setting.
The Store registration properties in local registry check box is provided in the Register dialog of the Remote Portlet Wizard, as shown in Figure 14-7.
Tip:
You can also store registration properties for remote books and pages. See Chapter 4, "Creating Remote Portlets, Pages, and Books" for detailed information in the wizard used for creating remote portlets, pages, and books.
Figure 14-7 Storing Registration Properties
When Store registration properties in local registry is checked, the wsrp-producer-registry.xml file is updated with the stored registration information. A sample is shown in Example 14-5. To provide flexibility, this option is always selected by default even if there are no properties defined. If the checkbox is selected during registration you can add registration properties later.
You can only edit the registration properties using the IDE dialog when initially registering or re-registering a producer. To change the properties after the producer is registered, you need to edit the XML file directly using an XML editor.
Example 14-5 Registration Property Information
...
<registration-properties>
<stringProperty name="{urn:bea:wlp:prop:reg:propset-1}Selection">
<value>OK</value>
</stringProperty>
<stringProperty name="{urn:bea:wlp:prop:reg:propset-1}Choices">
<value>Electronics</value>
</stringProperty>
</registration-properties>
<store-registration-properties>true</store-registration-properties>
...
You can customize the producer-generated WSDL. For example, you might want the WSDL to point to a proxy server other than the default one. To customize the default WSDL, you can edit the WEB-INF/beehive-url-template-config.xml file. The easiest way to edit this file is to copy it to your workspace in Oracle Enterprise Pack for Eclipse. To do this, locate the file in the Merged Projects view in Oracle Enterprise Pack for Eclipse. Right-click the file and select Copy to Workspace. The template file uses URL templates. See Javadoc for the GenericURL class for information on configuring URL templates.
This section explains how to configure custom JAX-RPC handlers on the WSRP consumer or producer. Custom handlers can be used to intercept and process the outbound SOAP requests and inbound SOAP responses. For example, handlers can inspect the incoming and outgoing messages, change the messages before they make it to the end point, log information, and so on. This section only explains how to configure and register a handler, not how to write a handler class.
Tip:
The handler class must implement the javax.xml.rpc.handler.Handler interface or extend javax.xml.rpc.handler.GenericHandler.
This section includes these topics:
Edit the file WEB-INF/wsrp-consumer-handler-config.xml to add a custom handler the consumer. The easiest way to edit this file is to copy it to your workspace in Oracle Enterprise Pack for Eclipse. To do this, locate the file in the Merged Projects view in Oracle Enterprise Pack for Eclipse. Right-click the file and select Copy to Workspace.
Example 14-6 shows an example configuration file:
Example 14-6 Event Handler Configuration
<wsrp-consumer-handler-config
xmlns="http://www.bea.com/ns/portal/90/wsrp-consumer-handler-config">
<description>Description goes here</description>
<soap-handler>
<name>ProducerHandlesFilter</name>
<description>Producer Handles Filter test handler</description>
<!-- List of producer handles to deploy to, if none are specified ALL
producers will have this handler -->
<producer-handle>NoOpProducer1</producer-handle>
<handler-class>com.bea.wsrp.qa.consumer.handlers.ProducerHandlesFilter
</handler-class>
<!-- If true, the handler will run before the SAML token is added. -->
<pre-security>true</pre-security>
<!-- init parameters if needed -->
<init-parameter>
<name>param1</name>
<value>value1</value>
</init-parameter>
<init-parameter>
<name>param2</name>
<value>value2</value>
</init-parameter>
<!-- Specify which ports to add the handler to. -->
<port-name
xmlns:wsrp="urn:oasis:names:tc:wsrp:v1:wsdl">wsrp:WSRPServiceDescriptionService
</port-name>
<port-name
xmlns:wsrp="urn:oasis:names:tc:wsrp:v1:wsdl">wsrp:WSRPBaseService</port-name>
<port-name
xmlns:wsrp="urn:oasis:names:tc:wsrp:v1:wsdl">wsrp:WSRPRegistrationService
</port-name>
<port-name
xmlns:wsrp="urn:oasis:names:tc:wsrp:v1:wsdl">wsrp:WSRPPortletManagementService
</port-name>
<port-name
xmlns:wsrp="urn:oasis:names:tc:wsrp:v1:wsdl">wsrp:WLP_WSRP_Ext_Service
</port-name>
<soap-role>someRoleHere</soap-role>
</soap-handler>
On the producer edit the file WEB-INF/webservices.xml as defined by the JAX-RPC specification.
|
 Copyright © 2010, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|