The purpose of this entry in the blog is to relate all the tips and tricks learned about using WAB.
The main purpose of WAB (Web Application Bridge) is to “proxy” web sites behind the Portal so that users that do not have to access to those sites (e.g. due to Firewall) can still use them. The only requirement is that the Portal server has access to those sites. The user browsers don't require firewall access to sites and don't require an internet proxy to get to the sites. As far as the client browser is concerned, it is only accessing the Portal URL and only needs access to that system.
If one looks at the page source for a Portal page containing a WAB portlet, one sees that the WAB portlet is an iFrame that is sourced at the Portal plus a “context root”. So, in the case of the Apache Lucene Core site, located at “http://lucene.apache.org/core”, the iFrame would have a “src=/core”. This is a relative URL back to the Portal which accesses the “/core” context root.
Context Root of the WAB Servlet
The context root of the of the WAB servlet which is set in the WAS console only serves http "GET" requests from the IHS plugin to the WAB servlet. The iframe HTML in the portal page has a relative reference to the context root of the destination site.
The easiest way to do this is just put “/” for the context root of the servlet. This ends up being a default routing; e.g. any context root not actually used by Portal itself gets sent to the WAB servlet. By making the context root “/”, the plugin-cfg.xml file generated and propagated by the Deployment Manager to the IHS node(s) is automatic.
However, using “/” has 2 negative effects:
1) No content can be served from the IHS server since all context roots will go to Portal
2) It's considered less secure to have the plugin route “/” traffic to Portal.
Therefore, if you want to serve content from IHS as well as Portal or if you want to increase security, one should manually edit the plugin-cfg.xml file to replace the “/” with all the actual context roots for WAB back-end sites. In this case, you replace the line in the plugin-cfg.xml that reads
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/*"/>
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="/core/*"/>
Multiple WAB Portlet on a Page
This is supported and I will explain what to consider:
Technically, the iFrame for the WAB portlets will be replaced with an absolute URL with an alias to the Portal which embodies the target site of the back-end site. The main reason for this is so that when a link on the iFrame is clicked, Portal can deduce the correct routing.
Making multiple WAB portlets on a page work, requires an augmented setup for the back-end sites. Once completed, the back-end sites which use this augmented setup can either be on a page alone or along with other WAB portlets.
Here is an example of getting Apache Lucene “core” and ESPN “nfl” on the same page.
The Lucene core site is “http://lucene.apache.org/core”. The ESPN NFL site is “http://espn.go.com/nfl”.
What must be done:
1) A Resource Environment Provider “host alias mapping” must be done for each and every site that MAY appear on a page with another WAB portlet. The REP is “WP Virtual Web Application Manager Config”. The “Custom Property” called “host_alias_mapping” has to be augmented with a value of “espn=http://espn.go.com, lucene=http://lucene.apache.org”. Make sure the “name” (espn, lucene) is lower case.
2) Create the “Content Providers” in the Portal Admin “Virtual Web Application Manager” portlet as normal.
Here is the ESPN Content Provider:
Here is the Lucene Content Provider:
Notice in both cases I have used lower case for the content provider.
3) Create the WebDock portlets.
Here is the ESPN NFL WebDock:
Here is the Lucene Core WebDock:
4) Finally, create aliases in DNS for the sites. However, in my case I can't update the IBM DNS servers so I just updated my /etc/hosts file on my client. Notice this is for the CLIENTs and not the actual portal servers. This is because the iFrames that will reference the sites are from the client browser. Since the sites are “proxied” thru portal, these DNS addresses are to IP address that clients use to get to the Portal. This is likely the address of the load balancer sitting in front of the Portal IHS servers for the cluster. Here is my (redacted) /etc/hosts file:
In this case, the IP address of “portalserver1.rtp.raleigh.ibm.com” is “18.104.22.168”. The DNS address is the WAS Resource Environment Provider name prepended to the server name.
5) Restart Portal to pick up the changes to the Resource Environment Provider.
6) You can now place the portlets on the appropriate Portal pages.