Showing posts with label WPS Concepts. Show all posts
Showing posts with label WPS Concepts. Show all posts

IBM Portal notification

Portal Notifications for IBM WebSphere Portal allows authenticated portal users to View and Send Messages to other users of the same Portal. E-mail notifications are sent to the personal email account of the recipient, along with an announcement to indicate the arrival of a new message.

Have a look at detailed article at IBM Portal Notification on WebSphere Portal Wiki.

WebSphere Portal 7 and Spring 3.0 Portlet MVC Integration

I have found this article very useful at least for those who are going to start their development with Spring Portlet MVC and WebSphere Portal 7.



Restricting public render parameter scope

JSR 286 has introduced a concept of Public Render Parameter for communication between portlets in same or different WAR.
Public render paramter declared in a portlet, are accessible for all the portlets across the portal.
But in some case you might want to restrict the scope of public render parameter.

Let's take an example to understand this...

You have got two pages on which you have each instance of Book List and Book Details portlet.
Book list portlets shows all the books available in the library and when you select any book, Book Details portlet shows all the information about the book,
like book availability, book author e.t.c.

So you have these two portlets on two different pages say Page A and Page B.

By defalut public render parameter are global, so if you select any book from Book List portlet on page A, Book details portlet on Page A and Page B will start showing same book details.

In WebSphere Portal V6.1.x, you can control this behavior by limiting the sharing scope for public parameters to a page.
To limit sharing of public render parameter to another instance of the same portlet on other page, you can limit this scope by doing following:
Go to Edit page settings for page A and set param.sharing.scope (under Advanced options - I want to set parameters) to a non-empty value such as PageAScope.

Now Book Details portlet on Page A use their own shared values for their declared render parameters, and it will not conflict with rendering data of Book Details portlet on Page B.

Enforcing SSL for a perticular portal page

Recently I have found a pretty good article on how to enforce a perticular portal page to be delivered using https.

If you have similar kind of requriment, this article would be of great help.

Controlling Portal pages visited history

History of Potal pages visited by users can be controlled by setting value of keymanager.lru.size property in StateManagerService.

This property actually indicates that navigation is affected between portal pages and not portlets.

As per IBM Info Center

"Use this parameter to specify the history expiration limit of portal pages visitedby users. This determines how far backwards users can at least navigate in therecent history of portal pages that they visited. The number that you specifydefines the minimum number of different pages selected by the user after whichthe portal can discard the render parameters of a page. (The decision whether therender parameters of the page are actually discarded depends on the expirationpolicy of the internal cache that stores the render parameters of those pages.) Ifthe user returns to a page after visiting the specified number of other pages and ifthe render parameters of that page have expired, the portal displays that page inits default state."

Note: If this parameter is enabled, number of Render Parameters in a session cansomewhat be controlled.
A typical setting would be keymanager.lru.size = 3.

Significance of wps/portal and wps/myportal

When login to portal, you might have entered portal url ending with wps/portal or wps/myportal. Did you ever think about what is the difference between a url containing with wps/portal wps/myportal. Read more to know...
For the base Portal, by default, the content root is "wps/portal" for unauthenticated users and "wps/myportal" for authenticated users.
So when an unauthenticated user accesses portal url
http://portalserver.com/wps/portal, the Login page displays by default and after login, portal default ladning page comes up.

And when you try to access any protected resource, like
http://portalserver.com/wps/portal/MyFinancePage and since you are not authenticated, so portal will redirect you to http://portalserver.com/myportal and will show you login screen.
Now after login, you will be redirected to MyFinancePage instead of portal default landing page because you have a made an attempt to access protected resource MyFinancePage.

Setting session timeout for WPS

The default value of Session Timeout is 30 minutes. Reducing this
value to a lower number can help reduce memory consumption requirements, allowing a higher user load to be sustained for longer periods of time.

How to set custom Session Timeout value: In the WebSphere Administrative Console, login as admin
1) Servers -> Application Servers
2) WebSphere Portal -> Container Settings: Web Container Settings: Web Container -> Session Management
3) Session Timeout -> Set Timeout
4) Set time out value in minutes
5) Click Ok and then save configuration

How to improve WPS Startup Performance

You can improve portal startup performance by starting server in development mode.
You can achieve in two ways..
1) At the time of installing portal

2) From WAS in case you have skipped step 1.

1) At the time of installing portal

You can install portal either by selecting Full or Administrative option. If you install portal as Full option, you get all out of the box portlets and also administrative portlets, whereas when you install as Administrative option, you get only Administrative portlets.
So to get portal startup performance, select Administrative type of installation and just after this run the following scripts
For Windows
Run the ConfigEngine.bat enable-develop-mode-startup-performance -DWasPassword=password task from the wp_profile_root\ConfigEngine directory.
For UNIX
Run the ./ConfigEngine.sh enable-develop-mode-startup-performance -DWasPassword=password task from the wp_profile_root/ConfigEngine directory.

Note:- This task is for development only and is not recommended for production environments.
Read here for more Details

2) Secondly, if you have skipped step 1, you can always enable development mode from WAS.
Follow steps below
a) Login to WAS as admin
b) Go to Servers -> Application servers
c) Click on WebSphere_Portal.
d) Select Configuration tab.
c) select check box for "Run in development mode"
e) Restart Portal and server1.
Note:- Again, this setting should be enabled for development only and is not recommended for production environments.

Disabling anchors in portlet URLs

In a scenario where you have several portlets arranged vertically on a page and when you click on any action on last portlet on the page, as a result you are then forced to scroll up the browser to see the portlets from top of the page.
Haven't experienced this before?? try it out....

Let me come to the point again..
Basically portal remembers your last action clicked on portlet on a page and shows you that portlet so that you don't require to scroll up or down to see result in your portlet.


This actually happens because portal appends an anchor to the portlet URL and this causes you to manually move the browser up and see the protlets from top of the page.

In situations, you might prefer to have top of the page displayed even if you click on last portlet on the page, to achive thisyou will need to disable anchors.

Here is how you can disable anchor tag
1) Identify Skin applied of your page
2) Navigate to

<wp-profile>\installedApps\<node>\wps.ear\wps.war\skins\html\<SkinName>
3) Open file Control.jsp
4) Search for the word anchor.
5) you will find following

<c-rt:if test="${themePolicy.renderPortletFragmentIDAnchor}"><a name="<%= myPortletID %>"></a></c-rt:if>
6) Comment above line of code.
7) Save Control.jsp

that's it you are good to go.
You can verify this by performing action on last portlet on your page and now you can see that you are already on top of the page.

Setting portlet size on Runtime

You might have worked with setting size of a portlet on page from portal admin.If not, have a look at Setting Size of portlet on page.
But, did you ever think about setting portlet size on Runtime?

Here i tell you how you can set your portlet size on Runtime with these steps...
In short, this machanism will require you to change your applied/current skin jsp and putting 2 lines of javascript code to your portlet jsp, and that's it you are done...

Here you go....

1) Open UnlayeredContainer-H.jsp, located under
<WP-Profile>/installedApps//wps.ear/wps.war/skins/html/<Skin Name>
Here i am making changes to IBM skin.

2) Add an id for the first table element on this file.
for example:- <table id="neerajtableid" class="layoutRow" cellpadding="0" cellspacing="0">

3) Save the file.

4) In your portlet JSP, get the table element with the ID and get the rows and cell of portlet and set the width.

For me, i have kept two portlets on pages and page property is set to two columns container.

Java script code to be written on your portlet jsp's.

<script language="javascript">
var tableElement = document.getElementById("neerajtableid");


tableElement.rows[0].cells[1].width = "37%";
</script>

Here, rows[0].cell[1] shows portlet placed on first row second column, which is horizontally second portlet.

How to Move a portal page on WPS?

Moving a portal page involves, changing of parent page/label.

This kind of scenario could arise when you have portlets added on portal pages and later in futureyou are required to move page from one place to another.Also this page move should not disturb portlets on page being moved.

Here i am explaining with a sample page move...

Considering, we have Page A and Page B as two parent page/label.
Page P1 and Page P2 are under Page A and
Page P3 and Page P4 are under Page B.

Page A ==== Page B
Page P1 -------- Page P3
Page P2 ------- Page P4

Scenario is like, We want to move Page P4 from Page B to Page A and and this moving of pages should not disturb portlets added on page P4.

Here is how you can perform page Move...

1) Login to portal as admin
2) Go to Administration
3) Navigate to Portal User Interface --> Manage pages
4) Find Page P4
5) Click on Mark icon adjacent to Page p4.
6) You can see a message saying, "Page P4 is ready to be moved." on top of Manage Pages portlet.
7) Navigate to the page where you want page P4 to be moved. In our case, it is Page A.
8) Navigate to Page A.
Note:- You can now see Move button along with New Page, New label, New URL.
9) Click on Move button and you are done with moving page P4 under Page A.

As as result, you can see that Page p4 is moved from PageB and is now available under PageA.

How to reflect theme changes immediately on WPS ?

You are creating a new theme and skins, making changes to your theme and skin jsp's, and want to see those changes immediately on portal?
You can do this by forcing application server and reflect your changes immediately.


For this, you will require to enable automatic JSP reloading..

Here you go....
1) Open file "ibm-web-ext.xmi", located under

<wp-profile>/config/cells/<cell-name>/applications/wps.ear/deployments/wps/wps.war/WEB-INF/ibm-web-ext.xmi

2) Find the following entry in above file

<?xml version="1.0" encoding="UTF-8"?>
<com.ibm.ejs.models.base.extensions.webappext:WebAppExtension xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:com.ibm.ejs.models.base.extensions.webappext="webappext.xmi" xmi:id="IBM_WPS_Ext" reloadInterval="3" reloadingEnabled="false" fileServingEnabled="true" directoryBrowsingEnabled="false" serveServletsByClassnameEnabled="false" preCompileJSPs="false">

3) Make reloadingEnabled value to true

4) Save the file and

5) Restart portal server.

After making these changes, you should be able to see your theme and skin change immediately...

Important :- To see changes to your JSP's that is being included by another(parent) JSP, you should make a change(you can simply enter and save jsp) to parent JSP to tell the sever that reload parent as well.

For example:- you can see that, head.jspf is included in your default.jsp
<%@ include file="./head.jspf" %>

Now, if you are making changes to head.jspf, and want to see your changes, you will also require to make a change in parent jsp, which is default.jsp.

Important Point:-
Enable automatic JSP reloading should be done for testing and development purpose only and should always be disabled for Production environment for performance issues.

What is XMLAccess and why to use XMLAccess?

All about XMLAccess what i have learnt so far...

What is XMLAccess - in short
XMLAccess is a command line utility that comes with WPS portal.This utility connects to the server using HTTP connection and allows us to configure portal remotely.

Why to use XMLAccess

The very important benefit of XMLAccess is it's ability to update a portlet app or update portal pages without loosing user customization. This is really most important point i like about xml access. If you perform any updates via XMLAccess, user customization to page or portlet will remain same.
How does it remain same? Speaking technically, when you perform update vai XMLAccess, objectID of the portlet or pageremains same, and this is the reason portlet app gets updated without loosing user customization.

Consider a scenario, where your portal has a weather portlet.Users of your portal have customized weather portlet to see weather of certain cites.Now, if you update this portlet you don't want user customization to be lost. XML Access is the command you can use to achieve the same. XML Access will allow you to update weather portlet application without loosing user customization.

How to Rum XMLAccess
XMLAccess is located under <portalServer>/bin
with WPS 6.1.x, you can also find xmlaccess.bat/xmlaccess.sh under <portalServer>/wp-profiles/PortalServer/bin

XMLAccess syntax
xmlaccess -in file.xml -url ://:/wps/config -user wpsadmin -password wpsadmin
file.xml is your xmlaccess command. For example DeployPortlet.xml
rest all parameters are self explanatory

What all you can do with XMLAccess
You can use the XMLAccess tool to transfer a complete configuration, including:
* Portlets
* Access Control List
* Portal Web application configurations (portlet applications)
* Portal skin definitions
* Portal theme definitions
* Portal portlet configurations
* Portal site map (pages, labels, and links)
* Portal URL mappings

XML-Access samples
You can find XMLAccess samles inside your portal installation located under<PortalServer>/doc/xml-samples/


For deployment and updating a portlet applications, you can use refer to DeployPortlet.xml

Technote on Using XmlAccess to deploy standard (JSR 168) portlet application might also be helpful.

Enabling SSL connection between WPS and MicroSoft Exchange Server

I was working on a project where our JSR 168 portlets was communicating with Exchange Server.
Later on we were asked to add a feature so that portlets can also communicate to exchange server over SSL.
For this we first enabled SSL on Exchange server ( FBA authentication on OWA and Exchange Server 2003) and then we exported certificate from Exchange server.

To make this type of communication, we were required to import the same certificate into WPS portal.

Below article helped me for importing certificate into WebSphere Portal and this made our portlets to communication over SSL with MicroSoft Exchange server.
Enabling SSL connection between WebSphere Portal and Microsoft Exchange Server

WPS Shared Library Creation and Usage scenarios

You might be aware of default Shared library of WPS, which is <PortalServer> /shared/app folder and it is the place where we keep the jar files which we want to be shared across all applications deployed on portal. Jar files placed here are loaded with portal class loader.

You can find entry for this portal shared library entry on WAS under

Environment --> Shared Libraries --> WPSlib



In the same way, there could be scenarios where you have several portlet applications deployed on portal and some of them might be using common libraries. 
We generally keep libraries in individual applications lib folder but few jars files might be common to some applications. In this case, there is no meaning to put these common jars to individual applications lib folder. Ultimately we will be increasing size of EAR or WAR  and reloading of same jar file from different application.

Best solution to this would be to create our own shared library.
The way WPS share library works, we can also create our own shared library and put common jars there so that all our applications make use of them and now we don't require to put those common jars in our application specific lib folder.

Here i tell you, how to achieve the same.
First, we will create a folder on drive, and then we will copy our common jar files to this folder.
For example:- /shared/app/appsharedlib

Next step would be to create a shared library entry in WAS and pointing it to above path
1) login to WAS as admin
2) navigate to Environment --> Shared Libraries
3) select your node where you want to create library
4) click on New
5) provide following details on the screen
Name:-
Classpath:- ${WPS_HOME}/shared/app/appsharedlib
6) click on ok and then save.
7) Restart Portal and WAS.

You can now test by putting all the common jars to our appsharedlib folder and remove those jars from applications lib directory.

Setting size of portlets on a page

When you have more than one portlets on a page and you want to set size of portlets, you just make use of Show Layout tools.
If it is disabled, just enable it and set size of portlets in either pixel of number.
Here you go....

Enable Show Layout Tool link
1.Login to portal as admin and click on Manage pages.
2.Navigate to you page where you have added portlets.
3.Click on Edit Page Layout of the page
4.Go to Edit_shared_setting of Edit Layout portlet
5.Select the check box for Show toggle link for "Show layout tools/hide layout tools"
6.Click ok
You should see Show layout tools link.

Setting portlet size
1.Click on Show Layout tools link
2.You should now see Not Set link in each container
3.Click on Not Set link and there you have pop up, where you can specify portlet width in pixel or a number followed by "%" Example: 30% or 200.

What is PUMA and how it works

Few information on What is PUMA and how it works...

* PUMA is Portal User Management Architecture and from developers prespective, it provides an API to get portal user information.

* PUMA is configured by default and if later on you cofigure your portal to LDAP, PUMA automatically starts pointing to LDAP.

*When you use PUMA api to get user information, basically PUMA makes a call to VMM (Virtual Member Manager) and VMM makes an internal call to your datastore( LDAP, AD, etc).

In more detail, VMM first looks into a mapping file, a file in which Portal attributes are mapped to LDAP attributes and this mapping is done automatically at the time of configuring potal to LDAP.

*In addition to above information,
when you create a new portal user using Profile Portlet, you have following attributes by default
User ID:
Password:
Confirm Password:
First Name:
Last Name:
Email:
Preferred language:

other then these attributes, if you want to add additional attributes in the list, then just go to Configure mode the portlet and select attributes that you wish to appear in the list.

PUMA scenarios in WPS

If you are planning to architect portal solutions which includes customizing the existing forms and screens for custom user management ans wants to provide solution based on the needs for individual user management, you need to have study on Portal User Management Architecture in WPS.

Here is an article which talks about Portal User Management Architecture(PUMA) and their scenarios in WPS.

Have a look at PUMA sample scenarios in IBM WebSphere Portal

Configuring WebSphere Portal server as a test environment

If you have RAD installed without portal test environment and you have WebSphere portal installed, you can make your portal work as Test environment within RAD.

For WebSphere Portal 6.0 and later portal and portlet projects, you can use the WebSphere Portal 6.0 and later installation as a local test environment as long as it is installed on the same machine as your Rational tools development environment and this will also allow you to use all the portal features that you can't use with portal test environment.

The portal server requires no special configuration to be used a test environment; however, if Rational tools does not detect a WebSphere Portal server or test environment installation that you have already installed, you will need to create a new runtime environment.
To create a new runtime environment, complete the following steps:

  • Switch to the Web perspective by selecting Window > Open perspective > Other > Web.
  • Select Window > Preferences from the menu bar.
  • Expand the Server section, and click Runtime Environments.
  • Select the appropriate version WebSphere Portal, select the check box, and click Edit.
  • Verify the WebSphere Portal Location and WebSphere Application Server Location values with the version-specific WebSphere Portal installation directories that you specified when you installed WebSphere Portal.
  • Click Finish.
  • Click OK in the Preferences dialog box.
The WebSphere Portal server version that you specified should now be available as a test environment server for testing, debugging, or profiling.
Also important to note
This runtime environment will only be available in your current workspace. You must create a new runtime environment for any new workspace that you create.