WebSphere Portal URL Requirements

WebSphere Portal (WP) has some specific requirements for the format and content of URL used by this application. Furthermore the WebSphere Portal URLs are not human decipherable or dependant on site taxonomy. One example of a typical WP version 6 URL might look like the following:

http://www.mycompany.com/wps/myportal/!ut/p/c1/04_SB8K8xLLM9MSSzPy8xBz9CP0os3hLRydHL1MjYwN3dyNXA6MAD3c_V2M_YwMDA30_j_zcVP2CbEdFAHUwnMg!/

The basic building blocks of this URL are defined as follows:

<protocol>://<hostname>:<port>/<portal-context>/<security-context>/[<virtual-portal-alias>]/[<portal-params>]

All elements of this URL are important to the portal server to ensure that the request is properly processed and it is very difficult to hide or manipulate any

<protocol> – This is the protocol used by the request in our case HTTP or HTTPS

<hostname> - This is the DNS resolvable host name of the entry point to our portal application

<port> - This is the port that the WebSphere Portal HTTP listener will be bound to and is often left off on a browser URL designating the port as either the default HTTP port 80 or HTTPS port 443. Any other port would need to be properly designated in the URL

<portal-context> - Portal Context is the part of the URL that determines which application on the WebSphere Server will service the request. The default for WebSphere Portal is wps

<security-context> - Security Context is the part of the URL that determines whether the user is request the anonymous or secure view of a given portal navigational element like a page. The default contexts are portal for the anonymous version and myportal for the secure version

<virtual-portal-alias> - Virtual Portal Alias (VP alias) is only relevant when the WebSphere Portal environment uses Virtual Portals. The Cisco Enterprise Portal (CEP) environment leverages the VP alias to do routing of requests to applications based on predefined service level agreement rules and

Portlet Wiring Tool

The Portlet Wiring Tool allows you to configure connections, or wires, between cooperative portlets. You can access the Portlet Wiring tool for a page by going to Edit Layout section of a page and then going to Wires tab. You should get a screen like this

Photobucket


The Portlet Wiring Tool allows you to view the properties that portlets on the page can send or receive. If a match is available between two portlets, you can create a
wire between the two portlets. Existing wires may also be deleted using the tool..

The Portlet Wiring Tool also provides the functionality to implement cross-page portlet communication. Cross-page wires allow portlets to exchange properties across pages. Before creating a cross-page wire, the target page must have receiving actions defined as global on its portlets. Setting an action as global will also make that action available to Click-to-Action menus. To set an action as global, navigate to the target page and select Edit Page Layout from the drop-down menu on the title bar. Then select the Wires tab and click on Manage Actions. This will bring up a listing of the portlets on a page and their corresponding receiving actions.

Photobucket

As an alternative to the Portlet Wiring Tool, wires can also be created interactively in the portlet. Depending on the browser, users with sufficient permissions can create wires by holding either the CTRL or ALT keys and clicking an icon or hotspot in the portlet that is already associated with a Click-to-Action function. A dialog is displayed that allows the user to create a wire to other portlets on the page.


In order to view the tool itself, users must possess at least "User" role permissions on the page and the portlet. Further access checks are performed before allowing the user to view, create, or delete wires between portlets. The user must possess at least "User" role permissions on a page and the wired portlets on it to be able to view wires for the page. Users may also be able to create or delete personal wires, which affect their view of the page, or create or delete public wires, which affect all users' view of the page. Users must possess at least "Privileged User" role permissions on the page and "User" permissions on the portlets to be able to create or delete personal wires, while at least "Editor" role permissions are required on the page and "User" permissions on the portlets to be able to create or delete public wires.

Restrictions on Cooperative Portlet

These are the restrictions on the Cooperative portlets that apply to portlets developed using IBM Portlet API and Standard Portlet API

  • The property broker does not support anonymous users. That is, for portlets on a page to transfer properties, the user must be logged in.

  • The pop-up menu functionality requires browsers with JavaScript on the client.

  • When multiple cross-page wires are triggered at the same time to different target pages, the first target page will have priority. Only the wires going to the first target page will work. The other events will be discarded.

  • Wires created on a root page may not be created by default on any child derived page. They have to be recreated on the derived page.

Configure cooperative portlets

The term cooperative portlets refers to the capability of portlets on a page to interact with each other by sharing information. The WPS supports cross-page portlet communication for cooperative portlets, allowing portlets on different pages to communicate

Cooperation between source and target portlets is faciliated by by a WPS runtime entity called the property broker. The Cooperative portlets subscribe to a model of declaring, publishing and sharing information with each other using WPS property borker. Each portlet that wants to act as either producer or consumer declares its intention using a .wsdl file. At the time of installing a portlet WPS will read the .wsdl file and make entries in database about data type that portlet can either consume or produce. After installing a portlet administer should create a connection between source and target portlet using Portlet Wiring portlet. The Portlet wiring Portlet allows you to create connection only if the source and target portlet has matching data type.

There are some differences between the portlets developed using IBM Portlet API and Standard portlet API when it comes to cooperative portlets

1) You can create wire only between either two portlets developed using IBM Portlet API or two portlets developed using Standard Portlet API. You cannot create wire between a portlet developed using IBM Portlet API and a portlet developed using Standard Portlet API even if they have matching data type.

2)The Portlets developed using IBM Portlet API can publish a property either decleratively i.e. if wire is created between two portlets or programmatically using the Property Broker service API. But the portlets developed using Standard Portlet API can publish property only decleratively.

3) The Portelts developed using IBM portlet API's can use Click-to-Action, What that means is they can use C2A tags in the JSP for generating markup. Once you do that when you click on property it will display a context menu with list of all the consumer portlets for that portlet. You can click on one of the items in the menu to send event to consumer or you can broadcast that event to all the portlets who can consume that property. The Standard Portlets cannot use C2A JSP tags for publishing.

During the event phase, the property broker delivers notifications to cooperative portlets, and the cooperative portlets can notify the property broker of property value changes. An action may be delivered on one portlet as the result of a user clicking on an action link generated by the portlet in its markup. If cooperative portlets are used, this may result in other actions being triggered on other portlets. At any point during the event phase, a portlet may publish the value of an output property to the property broker. The portlet may provide a value at any time during the event phase. The property broker determines what needs to be done with the values. If wires exist for this property, the property broker will deliver the property value to the actions specified by the target end of the wires. This process may continue recursively; the property broker detects loops and breaks them. The property broker guarantees the completion of all property value notifications to target portlets by the end of the event phase.

Portlet deployment in clustered environment

If your WebSphere Portal server is installed on top of WAS ND or WAS XD, which most probably would be the case in non development environment then deployment of portlet would be little different than how you work on DEV environment.

When you deploy portlet on cluster using Portal Admin Console or XMLAccess first changes would be made in the portal database and then the portal server would forward control to Deployment manager which will push changes to all the servers in that portal once the changes are copied to all the nodes the portlet should be activated.

In case of clustered environment follow this procedure for either installing or updating the portal.

  1. Deploy your portlets using either the WebSphere Portal Administration page or the XML configuration interface utility (xmlaccess command).

  2. Activate the deployed portlets in the cluster by running the "WPSconfig.bat activate-portlets" command. In addition to activating the portlets, this step causes the deployment manager to synchronize the changes across the cluster members.



Second approach of installing portlets would be to first install it as Enterprise application using WAS and then allow DMGR to synchronize changes to all the nodes once that is done then inform Portal server about the portlet using XMLAccess pre deployed command. This approach is useful when you want to combine your portlet with other resources such as EJB, Web Services or other web modules. Follow these steps for deploying portlet

  1. Install the EAR through Deployment Manager, using either the Applications > Install New Application option within the Administration Console, or the AdminApp install command within the wsadmin scripting client

  2. Map the application to each cluster where it is to run, using either the MapModulesToServers option of the AdminApp install command within the wsadmin scripting client, or the Map modules to servers option under that application’s entry under Applications > Enterprise Applications .

  3. Synchronize the new application with each node in all clusters, and start the application in each cluster. By default, synchronization will automatically occur with each node hosting servers and cluster members, or both, to which the enterprise application is mapped.

  4. Use the XMLAccess application to import a portlet definition into each portal cluster using the predeployed attribute, where the element of the points to the binaries directory where the portlet application's WAR contents are contained. Choose only one cluster member in a cluster against which to run the XMLAccess import, and as a result all cluster members receive the update.

Manage deployment and removal of portal application

When you deploy a portlet on WPS two things happen first that portlet gets installed as Enterprise application on the underlying WebSphere Application Server and in addition to that WPS reads the portlet.xml and stores the configuration information in the database.

Now there are two different approaches of deploying portlet


  1. Deploy portlet using WPS: In this approach you can deploy a portlet through the WPS infrastructure either by using the Manage Web Modules portlet or using XMLAccess script. When you deploy portlet through WPS, it first takes whatever configuration information it needs from the portlet’s WAR file, and then it generates a unique object ID for this portlet. WebSphere Portal then wraps the portlet’s WAR within an EAR definition, giving it a name based on the portlet’s display name, suffixed with the generated object ID. This guarantees that the portlet’s underlying enterprise application name is unique to this portal.


  2. Deploy portlet using WAS: Other approach of deploying portlet is first deploying EAR file using WAS Admin Console and then using XMLAccess script to inform WPS about the portlet i.e. activating portlet. This approach is useful if you want your portlet to access an EJB, in that case create EAR file containing EJB and portlet. Or second approach is you want to package more than one portlet applications into one EAR file(might be useful if those applications share some third party jar)