Thoughts on Portal from Level 2 Support

What are these long and ugly URLs in Portal? Can I make them short and clean?

twcornwe ‎ 1 Comentario ‎ 23.370 vistas

Introduction
HTTP is a stateless protocol. Many web designers have utilized a combination of cookies, parameters in URLs, and other techniques to preserve state information for users visiting their websites. WebSphere Portal as a part of its design simplifies the stateless nature of HTTP and automatically encodes state information into its URLs. WebSphere Portal also encodes navigation information into its URLs (e.g. language, back button behavior, etc.). Decoding techniques do exist to decipher the URLs but by default WebSphere Portal encoded URLs cannot be viewed in plaintext and easily determine what information the URL contains.

An unfortunate side effect of encoding all of this information into the URLs is that WebSphere Portal URLs tend to be long and ugly out of the box. For example, if you access the default Portal page by its stateless URL - e.g. http://myportalsite.ibm.com:10039/wps/portal, this is automatically redirected to a stateful URL such as:
http://myportalsite.ibm.com:10039/wps/portal/!ut/p/a0/04_Sj9CPykssy0xPLMnMz0vMAfIj83Kt8jNTrMoLivV88tMz8_QLsh0VAVTAxWw!/

This article will discuss techniques to keep the Portal URLs short and clean.

2015.10.30 EDIT: Portal 8.5 cumulative fix 08 has introduced several configuration options which simplifies creating stateless URLs. See the 8.5 Infocenter for more details. This blog entry will be updated in the near future to discuss how the new parameters introduced in CF08 will interact with other configuration settings noted in this blog entry.

Out of the Box Settings

For WebSphere Portal 6.1 and later the out of the box settings will generally result in a stateful URLs. There are two primary factors that play into whether or not a stateful URL will be display:

1) The type of page - standard page or static page
2) The type of URL - a URL mapping, a Friendly URL, or a Vanity URL (8.5 and newer only)

For #1, Portal 6.1 and earlier utilized standard pages for its default page type. These were shipped with pre-defined page layout templates provided by IBM code and once portlets were added to the page they largely didn't change. Over time it was determined a new design was needed to allow for more flexibility, hence the use of static pages. Portal 7.0 and later utilized static pages for its default page type. Static pages offers many advantages over standard pages, one in particular is "You can include portlets as dynamic elements and containers as placeholders for portlets in your pages. You can display these portlets by using server side aggregation, AJAX". The general recommendation would be to utilize static pages in your WebSphere Portal design.

For #2, Portal 6.0 and earlier offered URL Mappings as a short and clean means of managing URLs. URL Mappings were not dependent on the Portal page hierarchy, hence, a URL Mapping of /wps/myportal/thisblogentry may resolve to /wps/myportal/US/en/IBM/Industry/Cloud/Solutions/WebSphere/Portal/Support/This/Blog/Entry. Over time management of URL mappings becomes difficult for large Portal sites. Portal 6.1 began offering a new feature called Friendly URLs. Friendly URLs are dependent on the Portal page hierarchy and as a result allowed for simplified management of URLs. URL Mappings and Friendly URLs are for the most part mutually exclusive ... you should try to design your Portal site with one of the two, but not both, and the recommendation would be to utilize Friendly URLs given URL mappings are now deprecated with Portal 8.5. Finally, in Portal 8.5 a new type of URL - called a vanity URL - was introduced. Vanity URLs are a complement to Friendly URLs. Friendly URLs are still available and are dependent on the site hierarchy, while vanity URLs are not dependent on the site hierarchy. Using the same example above, a vanity URL of /wps/vanityurl/thisblogentry could be created that would resolve to an actual page in the Portal page hierarchy. Vanity URLs are advantageous in cases where we want a VERY short and clean URL that does not contain the entire page hierarchy information, such as a Friendly URL. For purposes of this blog entry, we will assume every page in your page hierarchy has either a Friendly URL or URL Mapping to allow for stateless URLs. If your Portal site does not have either a Friendly URL or URL Mapping on it and you implement the steps below, some pages may no longer be accessible.

Returning to our stateful vs. stateless discussion, we have 2 * 3 = 6 possible combinations above. With the out of the box settings, here is what should happen:

        - Standard Page + URL Mapping   =   Stateless
       - Standard Page + Friendly URL    =   Stateless
       - Standard Page + Vanity URL       =   Stateful

       - Static Page + URL Mapping         =   Stateful
       - Static Page + Friendly URL     =   Stateful
       - Static Page + Vanity URL       =   Stateful

Note in particular that the fifth combination - Static Page + Friendly URL - is the recommended settings for WebSphere Portal. While an end user may be able to bookmark a short and clean url, e.g. /wps/myportal/Home/somefriendyurl, WebSphere Portal in its design will automatically 302 redirect the user to the stateful URL. The page will render successfully, but the URL in the address bar looks long and ugly. In the next section we'll discuss how to modify that behavior so it stays short and clean.

Primary references

1) The Portal 8.0 and 8.5 Infocenters offer some excellent details on how to make Portal stateless. However, there are multiple settings noted in the Infocenter and not all settings may be required for all Portal deployments. We'll explore each setting one by one.

2) The Chief Programmer of WebSphere Portal URLs has a presentation discussing the design elements of stateful URLs available here:
http://www.socialbizug.org/files/app#/file/443ae822-48ad-40d1-b106-8750f0e79447

Change #1 - Theme change with XMLAccess

1) The primary setting of interest is the hasBaseURL setting. From a Portal 85x system, I implemented this parameter via an XMLAccess script as follows:

<?xml version="1.0" encoding="UTF-8"?>
<request build="20140424-1749" type="update" version="8.5.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="PortalConfig_8.5.0.xsd">
 <portal action="locate">
 <theme action="update" active="true" context-root="/wps/defaultTheme85" default="true" defaultskinref="ZK_00000000000000A0BR2B300670" domain="rel" objectid="ZJ_00000000000000A0BR2B300QC6" resourceroot="dynamicSpots" uniquename="ibm.portal.85Theme">
 <parameter name="com.ibm.portal.theme.hasBaseURL" type="string" update="set"><![CDATA[true]]></parameter>
 </theme>
 </portal>
</request>

After changing this setting, I observed the following results:

        - Standard Page + URL Mapping           =    Stateless
       - Standard Page + Friendly URL            =   Stateless
       - Standard Page + Vanity URL               =   Stateful (redirects to stateful Friendly)

       - Static Page + URL Mapping                =   Stateless
       - Static Page + Friendly URL              =   Stateless
       - Static Page + Vanity URL                    =   Stateful (redirects to stateful Friendly)

*Author technical note: I had to manually create a new URL mapping via an XMLAccess script for the Standard Page + URL Mapping test.

Change #2 - friendly.redirect.enabled

2) Our second setting of interest is friendly.redirect.enabled noted on the following Infocenter page. To summarize the effect this setting has on your Portal environment:

- true (default) = send redirect to url with Friendly URL if comes in stateful WITHOUT friendly URL context send it to a Friendly URL ... hasBaseURL will then determine if it stays stateless, or, redirects to Friendly URL + stateful --> GOOD for Friendly URLs

- false = no redirect is sent "a request for a URL mapping will be served an HTTP 200 and the page content rather than a 302 redirect to the URL with navigational state encoded" --> GOOD for URL Mappings

Portal 85x environments should be moving away from URL Mappings, however, if your environment is migrated you may still have some URL Mappings in place and wish to have this setting as false. I did not enable this setting in my 8.5 environment given I am not using URL mappings and wanted the remote possibility of an end user coming in from a stateful URL with friendly URL context to be handled. However, this setting also affects 302 vs. 404 behavior in Portal, in addition to stateless vs. stateful behavior and you may wish to set it to false in a system with Friendly URLs only and no URL mappings. See this Technote for more details.

Change #3 - URL generation in themes

3) Our third setting is the navigation.jsp files. OK, so what exactly are these things if the tests in #1 above resulted in stateless URLs? The tests in #1 assume the user is coming into the Portal via a link sent by email, a bookmarked link, etc. If the user is already IN the Portal and navigation around by clicking the navigation at the top/sides of the page, this is where the navigation.jsp files come into play.

For example: If I manually enter my friendly URL, it retain this same friendly URL, short and clean, in the address bar:
http://myportalsite.ibm.com:10039/wps/myportal/Home/Welcome

However, if I hover over the same link at the top of the page and click it - I observed the following result:
http://myportalsite.ibm.com:10039/wps/myportal/Home/Welcome/!ut/p/z1/04_Sj9CPykssy0xPLMnMz0vMAfIjo8ziDVCAo4FTkJGTsYGBe7CBfjheBf5G-lFAaX9_H1d3I38DbwNHQzcDR2dfQ3_3EC9DAxcjrPqRTSJOPx4FUYTcH4VXCcgHWBSgOLEgNzQ0wiDTEQDA0a2H/dz/d5/L2dBISEvZ0FBIS9nQSEh/?uri=nm%3Aoid%3AZ6_00000000000000A0BR2B300GS0

For purposes of this blog entry, I performed an edit of these files on the Portal 85 default theme. HOWEVER, cumulative fixes installation may overwrite these files and it is NOT RECOMMENDED to change the default Portal 85 theme files. You should copy the theme and modify per your business requirements, implementing the navigation.jsp changes as needed. Once the files were edited, my navigation.jsp looked like the following modified:

My updated navigation.jsp under wp.theme.themes (which will affect the Welcome, Getting Started, etc. links) looked like:

<portal-navigation:urlGeneration contentNode="${nodeID}" keepNavigationalState="false"><a href="<%wpsURL.write(out);%>" class="wpthemeLeft<c:if test="${childrenStatus.count == 1}"> wpthemeFirst</c:if>"><c:choose><c:when test="${node.projectID != null}">(<c:choose><c:when test="${isHiddenPage}">[<c:out value="${node.title}"/>]</c:when><c:otherwise><c:out value="${node.title}"/></c:otherwise></c:choose>)</c:when><c:when test="${isHiddenPage}">[<c:out value="${node.title}"/>]</c:when><c:otherwise><c:out value="${node.title}"/></c:otherwise></c:choose><c:if test="${selectedNodeID == nodeID}"> <portal-fmt:text key="currently_selected" bundle="nls.commonTheme"/></c:if></a></portal-navigation:urlGeneration>

My updated navigation.jsp under wp.theme.modules was slightly different and looked like

<portal-navigation:urlGeneration contentNode="${nodeID}" keepNavigationalState="false"><a href="<%wpsURL.write(out);%>"<c:choose><c:when test="${wp.selectionModel[node] != null}"><c:out value="${node.title}"/><c:if test="${selectedNodeID == nodeID}"> <portal-fmt:text key="currently_selected" bundle="nls.Theme"/></c:if></c:when><c:otherwise><c:out value="${node.title}"/></c:otherwise></c:choose></a></portal-navigation:urlGeneration>

etc. for sideNavigation.jsp and mobileNavigation.jsp

Change #4 - WCM URL Generation

4) The final consideration is WCM content. Short and Clean URLs can be created to reference WCM content. That is a task typically associated with site design of WCM. However, WCM URL generation does not generate friendly URLs. We needed to update the themes in item #3 above to prevent the long and stateful URLs from showing, a similar change will be needed for WCM URL generation.
"
With friendly URLs for web content, you can construct URLs to content items that are clear and concise. Although you can construct friendly URLs that reference web content items, IBM® Web Content Manager itself does not generate friendly URLs by default. However, to cause the web content viewer to generate friendly URLs, you can create a plug-in that implements a content URL generation filter.
"

WCM URL generation unfortunately requires a bit more custom coding than updating a few jsp files. This custom coding was not performed for this blog article. Further, the requirements of the sample code provided note:

"
To use the sample filter that is described here, each page for which a content URL is generated must have these characteristics:

The page must be a web content page with a friendly name.
The page must have a default content association that references the parent site area of the content item.

...which may not be applicable in all environments. Also note you must have Portal/WCM v8 or higher to leverage this feature. If you are interested in this feature, please see this article for a step-by-step implementation.

Final Thoughts

- The steps outlined in the Infocenter and this blog entry should be considered a starting point for configuring stateless URLs. As a quick example, the login and logout links in commonActions.jsp will generate stateful URLs by default as keepNavigationalState="true" is preserved.

<portal-navigation:urlGeneration allowRelativeURL="true" keepNavigationalState="true" contentNode="wps.content.root" home="protected" >
<a href='<% wpsURL.write(escapeXmlWriter); %>' ><portal-fmt:text key="link.login" bundle="nls.engine"/></a>
</portal-navigation:urlGeneration>

...this would also need to be updated, and, you would need to weigh in on the consequences of losing navigational state information, e.g. returning the user to the same page they were on prior to logging in, should you change this setting to false. Many other examples exist and must be weighed out to keep or remove functionality.

- Carefully consider which area(s) of the Portal site you wish to have stateless URLs. For those areas, it may be advantageous to create a separate theme with the updated keepNavagationState="false" jsps and and hasBaseURL parameter in that theme.

- Remember: WebSphere Portal in its design assumes stateful URLs and completely eliminating all stateful URLs will require some significant effort. However, use of Friendly URLs with the configuration options noted above to keep 95%+ of your Portal site clean and consistent is a very real and achievable goal.

Modificado el por twcornwe

How to programatically refresh data from LDAP

twcornwe Etiquetas: attribute kdap cache api puma vmm ‎ 1 Comentario ‎ 17.183 vistas

Overview of LDAP caches in Portal

WebSphere Portal versions 6.1 and later leverage a number of out of the box caches to improve system performance. When configured to an enterprise LDAP, two specific sets of caches are leveraged to cache data from the LDAP
- Portal User Management Architecture (PUMA) caches
- Virtual Member Manager (VMM) caches

Rather than going to the LDAP every single time there is a need to access LDAP data, caches will instead be used, significantly reducing load on the LDAP server. A typical flow would go something to the effect of:

1) Portlet needs LDAP data (such as user or group information)
2) Portlet asks PUMA for LDAP data
3) PUMA checks PUMA caches to see if LDAP data is cached and not yet expired

-->If cached and not yet expired, it will return the data to the portlet.
-->If not cached, OR, if cache has expired, move onto next stage in flow

4) PUMA will query VMM for the data
*Technical note: Portal itself never directly talks to the LDAP during runtime. In a standalone LDAP configuration, both WAS + VMM code are used to talk to the LDAP. In a federated LDAP configuration, only VMM code is used to talk to the LDAP. However, key point is during runtime Portal itself never talks to the LDAP directly, it always goes through another layer.

5) VMM checks VMM caches to see if LDAP data is cached and not yet expired

-->If cached and not yet expired, it will return the data to PUMA. PUMA will update its caches with the data from VMM and return the data to the portlet.

-->If not cached, OR, if cache has expired, move onto next stage in flow

6) VMM queries LDAP for requested data. VMM caches are updated.

7) VMM returns to PUMA the requested data. PUMA caches are updated.
8) PUMA returns requested data to the portlet

Both caches operate independently of each other, so it is entirely possible one cache could timeout, while the other cache would still be active.

Direct Updates to data in LDAP do not show in the Portal
While caches offer the advantage of reducing load on your LDAP server, the one disadvantage is that data in the Portal is not guaranteed to be as current as the data in the LDAP. i.e. It is entirely possible that an update can be made to the data in the LDAP, but, that data will not show up immediately in the Portal, as Portal will still be pulling the cached data from either the PUMA caches or VMM caches. Generally speaking, after 30-60 minutes updates made to data in LDAP will be visible in the Portal once the caches expire.

One potential strategy is to modify the timeout values to a lower value. The following Technote discusses this strategy in more detail:
http://www-01.ibm.com/support/docview.wss?uid=swg21413947

As noted in the Technote, turning off both caches is NOT recommended. In addition to increased CPU/memory usage on the Portal server, you run the risk of overloading your production LDAP server(s), risking an enterprise outage of login services across multiple applications.

OK, so we know there is an advantage to the caches to help with performance, and there is also a disadvantage that the caches may contain stale data relative to what's in the LDAP. Is there a way to get the best of both worlds, i.e. maintain the caches in most cases, but, when needed we can pull the most recent data from the LDAP?

Answer, yes this is possible. APAR PM16430 was introduced to allow the ability to programatically invalidate the current LDAP caches and refresh from the current data in LDAP. http://www-01.ibm.com/support/docview.wss?uid=swg1PM16430

Sample Code to programatically refresh data from the LDAP
How do we implement the steps in PM16430? Let's go over some prerequisites before we get into specifics:

i. You should be in a federated LDAP configuration. Federated LDAP code is guaranteed to go through VMM (and VMM caches) every time. Standalone LDAP configuration with WebSphere Portal is not guaranteed to use VMM code every time. The APAR will still work with standalone LDAP code, but the recommendation is to have a federated LDAP configuration if you plan on implementing the APAR

-->See this Infocenter document for how to convert from standalone LDAP to federated LDAP if needed: http://www-10.lotus.com/ldd/portalwiki.nsf/dx/Changing_from_a_standalone_repository_to_a_federated_repository_on_AIX_wp7

ii. You should already have code in place which leverages the PUMA API to query data from the LDAP, OR, you should have a willingness to experiment with creating such code
iii. Review the following blog entry to be familiar with using JSPs to implement sample code: https://www.ibm.com/developerworks/mydeveloperworks/blogs/PortalL2Thoughts/entry/debugging_your_portal_with_jsps_basics28?lang=en

To get started:
1) Locate the wimconfig.xml file under:
<WP_profile_root>/config/cells/<cellname>/wim/config/wimconfig.xml

In the file, locate the section which corresponds to the LDAP server you wish to programatically invalidate caches with. From my lab system, we have:

<config:repositories xsi:type="config:LdapRepositoryType" adapterClassName="com.ibm.ws.wim.adapter.ldap.LdapAdapter"
id="PORTSELDAP" isExtIdUnique="true" supportAsyncMode="false" supportExternalName="false"

Note the id="PORTSELDAP" in particular, we'll need this a it later.

2) Login to the WAS Admin console (or Deployment Manager if in a cluster). Navigate to Resources --> Resource Environment Providers --> WP PumaStoreService --> Custom Properties

3) Create a new custom property:

Name: store.puma_default.wim.cacheinvalidation.enabled

Value: true
Type: java.lang.String

4) Create a new custom property:

Name: store.puma_default.wim.cacheinvalidation.repositoryids

Value: PORTSELDAP
Type: java.lang.String

*Note, for the value here, use the id= we identified from the wimconfig.xml file in step #1.

5) Save changes. If clustered, sync nodes.
6) Restart the Portal Servers.

7) Create a new file named reloadall.jsp with the following code:
<%@ page import="com.ibm.portal.um.*" %>
<%@ page import="javax.naming.*"%>
<%@ page import="java.util.*"%>
<html>
<head>
<%
final String BR = " ";

out.print("Starting to gathering info"); out.print(BR);

try
{
 Context ctx = null;
 PumaHome pumaHome = null;
 PumaProfile pumaProfile = null;
 PumaProfile pumaProfileForContext = null;
 PumaLocator pumaLocator = null;
 PumaController pumaController = null;

 ctx = new InitialContext();
 pumaHome = (PumaHome)ctx.lookup(PumaHome.JNDI_NAME);
 pumaProfile = pumaHome.getProfile();
 pumaController = pumaHome.getController();
 pumaLocator = pumaHome.getLocator();

 List myList = new ArrayList();
 myList.add("uid");
 myList.add("sn");

 List userList = new ArrayList();
 userList = pumaLocator.findUsersByAttribute("uid","*");

 if (userList.size() == 0)
 {
 out.print("No results returned from search! Nothing to reload"); out.print(BR);
 }
 else
 {
 out.print("Found a number of users in LDAP " + userList.size()); out.print(BR);

 for (int i = 0; i < userList.size(); i++)
 {
 out.print("About to Reload User Attributes for user number " + (i+1) + " " + pumaProfile.getAttributes((User)userList.get(i), myList)); out.print(" ");
 pumaController.reload((User)userList.get(i));
 out.print("Done Reloading. Updated User Attributes for user " + pumaProfile.getAttributes((User)userList.get(i), myList)); out.print(BR);
 }
 }
}
catch(Exception e)
{
 out.print("Exception occurred!!! " + e); out.print(BR);
}
%>
</head>
</html>

8) Upload the reloadall.jsp file to your Portal server under <wp_profile>/installedApps/<cellname>/PA_Blurb.ear/Blurb.war/jsp
9) Setup a test page with the Welcome portlet. Configure the Welcome portlet to point to the following jsp:
/jsp/reloadall.jsp

10) Allow the page to refresh. At this point, we are pulling data for the first time from the LDAP, so the information will be current / fresh.
11) Make a direct change in the LDAP to one of the users. For purposes of this article, I changed the "sn" attribute on the "uid=travis" user

from: travistest
to: travischanged

12) Now, at this point, the data in the LDAP is updated, and, the Portal/VMM caches are both stale. The first call we'll make to fetch the LDAP data will be pulling from these caches, and will contain stale/outdated data. The reload() call, now with PM16430 active, will invalidate the caches and pull the data fresh from the LDAP. The second call we'll make to fetch the LDAP data will still be pulling from the caches, however, the reload() call will have pulled fresh data into the caches, and, we'll now display correct updated data from the LDAP.

13) Enjoy! Feel free to implement within your own custom applications as needed.

*Author's technical note: The current code will reload all entries in the LDAP. This may not be a good test case if you have a large LDAP. You may update the following line of code similar to the following if you require a smaller testcase to begin with: userList = pumaLocator.findUsersByAttribute("uid","travis*");

Special Note for 85x and 8001 CF13+

WebSphere Portal originally used private internal APIs to WebSphere Application Server to achieve the cache clearing functionality for the VMM AttributesCache. Beginning in WebSphere 80x, VMM began to offer a public API for any WebSphere Application Server product to leverage. When Portal 80x was released, it was still using the default private APIs and not the public API.

For Portal 8001x, a new APAR has been created - PI19201 - which switches over from use of the private VMM APIs to the public VMM APIs. The APAR functionally is similar to PM16430 for cache invalidation. However, the APAR does NOT require the manual properties store.puma_default.wim.cacheinvalidation.enabled and store.puma_default.wim.cacheinvalidation.repositoryids. The properties were originally required for PM16430 due to private APIs in use but are no longer required for the public APIs. If you have these properties defined and you install 8001 CF13 or later, your reload() code will continue to function, however these properties will no longer be required or used.

For Portal 85x, the public VMM APIs were built into the GA code. Therefore, the manual properties store.puma_default.wim.cacheinvalidation.enabled and store.puma_default.wim.cacheinvalidation.repositoryids are not required for 85x if you implement the reload() functionality.

Addendum to Original Posting
New bits of information will be periodically added to this blog entry.

1) Data stored in a property extension database will never be stored in VMM caches. However, it is possible for that data to be stored in PUMA caches. It is possible for another application (say the Deployment Manager) to make an update to the property extension data. Thus, it possible for the same condition to occur, that is, ApplicationA (DMGR) makes an update to the property extension database, ApplicationB (Portal) is still actively using caches and may not retrieve the new data. Therefore, reload() should be used to invalidate the PUMA caches and force the updated data to be retrieved from the property extension database.

2) The APAR and reload() functionality does NOT apply to groups and listing members of a group. The results of those calls are stored in the SearchResults cache, whereas, the APAR is only applicable to invalidating the AttributesCache. Therefore, if you make a direct update to LDAP to a group (say adding a new member to a group), then the Portal server is not guaranteed to pull this new data immediately. Example, in the Manage Users & Groups portlet, search for the group name, click on the group, it may show outdated information relative to what's in the LDAP.

However, for access control purposes, such as a users ability to see pages and portlets based on which LDAP groups they belong to, there is a potential workaround in place via a membership attribute (ibm-allGroups for Tivoli Directory Server, memberOf for Active Directory, etc.). In general, membership attributes offer huge performance gains during user logins, and we recommend implementing a membership attribute if your LDAP server supports it. Normally, without a membership attribute, we query the LDAP for the groups and their members one at a time eventually determining which groups the individual user belongs to. Think of this as a "Group" operation, similar to the example above with the Manage Users and Groups portlet. Now, with a membership attribute, a single query is made to the LDAP server to pull which groups the user belongs to. Think of this as a "User" operation, and, note the particular terminology of the word "attribute". User + attribute means the membership attribute is stored in the AttributesCache, and therefore PM16430+reload()+a membership attribute will allow us to pull updated group information for a user, in addition to the other updated attribute information. Using our example above, if we call reload() for this user immediately after they are added to a group in the LDAP, and we have a membership attribute configured, their updated groups from LDAP will be successfully pulled. Note, due to other Portal Access Control caches in Portal, the changes may not show immediately. If you have a requirement to have such changes show up immediately, please open a PMR with IBM Support, reference this blog entry and an interest in "PAC invalidation API".

3) WebSphere Application Server has its own code which can be used to pull a user's groups from the LDAP. WebSphere Application Server also maintains a separate set of caches for this information. WebSphere Portal offers a configuration option to allow Portal to reuse group information from WAS. This option is disabled by default and by default Portal does not reuse group information from WAS. If the reuse WAS group information configuration option is enabled, then PM16430+reload()+a membership attribute will still refresh information from LDAP in Portal and VMM caches, but, not necessary WAS caches. In this situation, WAS caches which store group information for a user will be outdated, but Portal PUMA and VMM caches will be current. However, because Portal is configured to reuse group information from WAS, it will perform this action prior to checking its own PUMA caches or VMM caches. Therefore, WAS caches may be contain stale data and Portal will reuse that stale data. More details on this condition are noted in the following Technote: http://www-01.ibm.com/support/docview.wss?uid=swg21593268

If this condition occurs, a decision will need to be made weighing out the need to reuse WAS group information vs. implementing the functionality offered by PM16430+reload(). If the PM16430+reload() functionality is desired, then disable group reuse as noted in the Technotee. If the reuse WAS group information should remain enabled, consider adjusting your timeouts on your caches as noted further up in the original blog entry under subheading "Direct Updates to data in LDAP do not show in the Portal".

4) Portal 8001 versions CF07-CF12 do not work with PM16430. PUMA caches will invalidate with the reload() call, but the VMM attributescache will not invalidate leading to stale data being returned. A newer cumulative fix with PI19201 must be installed to restore the invalidation functionality for the VMM attributescache.

Modificado el por twcornwe

Understanding how to redirect users on logout from Portal

twcornwe ‎ 15.500 vistas

Overview

WebSphere Portal offers the ability to configure the location that a user will sent to after an explicit logout from WebSphere Portal. Explicit logout is most commonly associated with clicking the "logout" button in the theme of a Portal site. Other forms of logout, such as an implicit logout when accessing /wps/portal when logged in or a session timeout after 30 minutes of inactivity, will not utilize this configuration. This blog entry will detail several uses cases with the explicit logout configurable parameters set and the end result observed. The six parameters of interest are redirect.logout, redirect.logout.ssl, redirect.logout.url, host.name, host.port.http, and host.port.https, all documented in the Portal Infocenter.

Foreword Commentary: Settings are global

The settings outlined in this blog entry are global and will apply to all users in the Portal whenever they perform an explicit logout. If you have a requirement to send different users to different locations on logout, instead consider customizing the logout link in your theme, or, authoring custom code which can further manipulate the explicit logout process. Should you decide to implement either of these solutions (or another custom solution), do NOT implement the settings in this blog entry. If the global settings in this blog entry are implemented, then the global redirect settings will override customized logout URLs. In other words, if your logout customization sends the user to http://www.lotus.com, but the global settings in this blog entry are implemented and send the user to http://www.ibm.com, then the user will be sent to http://www.ibm.com rather than http://www.lotus.com as intended by the customization, as the global settings will override the customization.

Before you Start: How to set the configurable logout parameters
1) Login to WAS Integrated Solutions Console (or Deployment Manager if in a cluster).
2) Navigate to Resources --> Resource Environment Providers --> WP ConfigService --> Custom Properties

3) Create each custom property if not present, e.g.

Name: redirect.logout

Value: true
Type: java.lang.String

4) Save changes. If clustered, sync nodes.
5) Restart the Portal server(s). Restart of the Deployment Manager and nodeagent(s) is not required, as this change only impacts the Portal server(s).

Note, for each test case noted below, a restart of the Portal server was required for the new settings to take effect.

Test Case #1:
redirect.logout=true
redirect.logout.ssl=true
redirect.logout.url=https://www.ibm.com

Observed Result: ibm.com was encrypted over SSL

Comments: In this case, we specified an absolute URL with the https:// prefacing it and the ssl=true parameter. The pairing is redundant, however, a correct end result was observed..

Test Case #2:
redirect.logout=true
redirect.logout.ssl=false

redirect.logout.url=https://www.ibm.com

Observed Result: ibm.com was encrypted over SSL

Comments: In this case, we specified an absolute URL with the https:// prefacing it, but we did not specify the ssl=true parameter. The absolute URL takes precedence over the ssl=false parameter, and thus the https:// was preserved.

Test Case #3:
redirect.logout=true
redirect.logout.ssl=true
redirect.logout.url=http://www.ibm.com

Observed Result: ibm.com was not encrypted over SSL

Comments: In this case, we specified an absolute URL with the http:// prefacing it, and we specified the ssl=true parameter. The absolute URL takes precedence over the ssl=true parameter, and thus the http:// was preserved.

Test Case #4a:
redirect.logout=true
redirect.logout.ssl=true
redirect.logout.url=/wps/portal

Observed Result: https://myportalserver.com/wps/portal .... however, the site does not render.

Comments: In this case, we specified a relative URI. The https protocol was used given we specified redirect.logout.ssl=true. The hostname and port will be constructed using the default values, being the hostname of the portalserver, and the default https port of 443. However, the portal server itself does not listen on port 443 by default (the web server does, but the Portal server does not). Therefore, we when access the Portal server over port 443, the site does not render. Testcase #4b will comment on one additional parameter that will allow the site to render.

Test Case #4b:

redirect.logout=true
redirect.logout.ssl=true
redirect.logout.url=/wps/portal
host.port.https=10029

Observed Result: https://myportalserver.com:10029/wps/portal and the page renders successfully.

Comments: In this case, we specified a relative URI. The https protocol was used given we specified redirect.logout.ssl=true. The hostname will be constructed using the default value, being the hostname of the portalserver. We explicitly specified the https port of 10029, corresponding to the default https port of the portal server.

Test Case #5: The most common use case for systems with web servers (i.e. clustered systems)

redirect.logout=true
redirect.logout.ssl=true

redirect.logout.url=/wps/portal

host.name=mywebserver.com

host.port.https=443

host.port.http=80

Observed Result: https://mywebserver.com/wps/portal and the page renders successfully.

Comments: In this case, we specified a relative URI. The https protocol was used given we specified redirect.logout.ssl=true. The hostname will be constructed using the web server name and port of 443 given we specified host.port.https.

URL Generation Comments: The reason this use case is recommended for systems with web servers is that host.name and host.port.https are used in URL generation throughout the Portal. In other words, if we had specified redirect.logout.url=https://mywebserver.com/wps/portal, while the logout to that location certainly would have worked, it is possible that other URLs generated in the Portal would still be pointing to the Portal server direct hostnames/ports, rather than the webserver hostname/ports. With host.name, host.port.https and host.port.http all set, explicit logouts and URL generation will always go through the webserver as we expect.

Test Case #6: The most common use case for systems without web servers (i.e. standalone systems)
redirect.logout=true
redirect.logout.ssl=true

redirect.logout.url=/wps/portal

host.name=myportalserver.com

host.port.https=10029

host.port.http=10039

Observed Result: https://myportalserver.com:10029/wps/portal and the page renders successfully.

Comments: In this case, we specified a relative URI. The https protocol was used given we specified redirect.logout.ssl=true. The hostname will be constructed using the portalserver name and port of 10039 given we specified host.port.https.

URL Generation Comments: The additional parameters specified are not strictly required, however, it is a good idea into getting into a habit of specifying them. Should the system have a web server added to it, a quick update to the configuration settings (test case #5) will allow everything to begin flowing through the web server, rather than having a potential mixture of web server URLs and portalserver direct URLs.

Utilizing auto-login URL across the web

twcornwe Etiquetas: unencrypted encrypted url protected login auto-login authentication secured sniff password ‎ 13.924 vistas

Login URL overview:

WebSphere Portal 6.0 and later offer the ability to login to the Portal using a specially crafted user of the following format:

http://server:port/wps/portal/cxml/04_SD9ePMtCP1I800I_KydQvyHFUBADPmuQy?userid=userid&password=password

A full example of this URL in use would be:
http://myportalserver.raleigh.ibm.com:10039/wps/portal/cxml/04_SD9ePMtCP1I800I_KydQvyHFUBADPmuQy?userid=wpsadmin&password=wpsadmin

This URL does not bypass normal authentication mechanisms. The username and password are passed along the PUMA, WAS, and VMM/WMM layers as would occur with a normal login via the login portlet. Once authentication completes, users will be redirected to the first page which they have authorization to access (for example, the Getting Started page). The login URL offers a means of convenience for Portal administrators to bookmark their sites and automatically login each time. Other applications also make use of this URL; Rational Application Developer, for example, uses this same URL when invoking the Portal Admin Console. This login URL can also offer a potential means for Portal adminsitrators to access the Portal Admin console if unable to do so via normal means (i.e. the login portlet, theme, etc. are not functioning correctly). Namely, you can enter the following URL:

http://myportalserver.raleigh.ibm.com:10039/wps/portal/cxml/04_SD9ePMtCP1I800I_KydQvyHFUBADPmuQy?userid=wpsadmin&password=wpsadmin

followed by:

http://myportalserver.raleigh.ibm.com:10039/wps/myportal/Administration

...which should in turn bring the Portal administrator to the Administration area without ever accessing the login portlet. There are many other uses of the login URL, and these example illustrate a few of the more common use cases.

Using the Login URL over the internet:

A STRONG warning should be given for the utilizing this URL over the internet. The existing URL by itself is unencrypted with the http protocol. Using software such as Fiddler (http://www.fiddler2.com/) or WireShark (http://www.wireshark.org/), it is trivial to sniff the unencrypted http URL and thereby obtain a valid username and password into the Portal system. Therefore, it is recommended to secure this URL if it will be sent over an unsecure network (such as the internet) prior to arriving at the Portal server.

Although there are means to force the WebSphere Portal login portlet to use a secureURL when authenticating users, that same option is not available for the login URL. The login URL can be encrypted with SSL security. However, if this is enabled, then the entire Portal site must also be enabled with SSL, which may not be desirable. If utilizing a web server to access the Portal, such as IBM HTTP Server, it may be possible to include a mod_rewrite rule to force this specific URL over SSL, while all other requests would be permitted over HTTP. However, note this should only be used as a failsafe. Meaning, if a user accesses the login URL over the internet, and accidentally sends the request over HTTP, then the username and password would already be sent in the clear prior to it ever reaching the web server and/or Portal server. The web server with the mod_rewrite rule could reject such requests over HTTP, but, the action would have already been committed and the username and password already potentially sniffed off the network. The web server can still act as a failsafe, but, the client-side must be updated to ensure the first request sent out is not sent out in the clear.

Therefore, if using the auto-login URL, on the client-side, whether it be via a web browser, a custom application, etc., be SURE to utilize the auto-login URL over SSL as a best practice.

Disabling the Auto-login URL

The automagic login URL may be disabled in Portal 8001 cumulative fix 12 or later, or, any version of Portal 8.5.. To do so:

i. Login to the WebSphere Administration Console
ii. Navigate to Resources > Resource Environment Providers > WP AuthenticationService > Custom Properties
iii. Create a new custom property
name: authentication.isLoginUrlActive
value: false
type: java.lang.Boolean
iv. Save changes. If clustered, sync nodes.
v. Restart the Portal server.

If you are not on one of these versions of Portal and need to block the auto-login URL, utilize a rewrite rule on your web server.

Modificado el por twcornwe

WebSphere Portal v8 Installation Best Practices and Things to Avoid

alle ‎ 3 Comentarios ‎ 13.556 vistas

The following blog discusses Portal v8 installation best practices, things to avoid and some general information:

General Information on IIM:

IBM Installation Manager replaces the ISMP installer and Portal Update Installer (PUI) and manages life cycle for WAS 8 and WP 8. IIM can install and uninstall core products, update or rollback fixpacks and fixes, modify and remove features
IIM version 1.5.2 or higher required
Silent install supported on all platforms. GUI mode supported ONLY on Windows/Unix platforms. Command line supported ONLY on z/OS.
Can record a response file without actually installing the product either by manually editing a sample response file that comes with the media or record one using IIM.
IIM is composed of a binary directory (from where you run the product) and a data directory (logs are recorded here).
IIM cleans up everything after a failed install. Need to create a log.properties with debug lines to pause IIM on a failure. This will allow for time to collect logs.
When viewing IIM logs for a Portal 8 install, use a browser to open the index.xml file from the IIM logs location for better formatting of the logs. You will need the log.xsl file in the same directory.
To uninstall IIM, for GUI navigate to IM_DATA_DIR/uninstall/uninstall, for console navigate to IM_DATA_DIR/uninstall/uninstallc

General Information on WebSphere Portal 8 Installation:

Portal 8 packaging comes from 3 sources: Live repository via Passport Advantage, physical DVD's, and electronic images.
Can install WAS 32-bit on a 64-bit platform
Can install to an existing WAS for any content offering. Express MUST install its own WAS.
Using an advanced configuration, can change such options as context root, default home, profile name, etc.
Content offerings (Enable, Extend, WCM and WCM SE) are an extended offering of WP 8 Server and cannot be installed without a WP 8 Server.
WAS ND binary cannot be shared between multiple WP 8 Server offerings

Portal v8 Regular Offerings (Server, Enable, Extend, WCM, WCM SE)

Best Practices:

A repository contains the required parts for installation. For Portal, one needs WAS, Portal, content offering, and Setup repositories.
Single set of Portal binaries for each content offering (Server, Enable, Extend, WCM, etc.)
Provide up-sell from server to WCM offering without reinstall
Select all required iFixes for WAS 8.0.0.3 when installing Portal 8
Extract all electronic images to the same directory.
Setup disk is unique to each offering. It's different for Server, Enable, Extend, etc. If installing all at the same time, make sure to have the correct assembly.
There is no tracing or logging with launchpad.
Always choose the repository.config from the setup disk, <Setup_Disk_location>/eimage, when chosen, there are no prompts for individual disks over choosing the repository.config from individual offerings (WAS, Portal, Portal Offering).
For iSeries ONLY, change Portal profile to 64-bit JVM SDK. Requires WAS managesdk task and ConfigEngine modify-jvm-heap-size and swith-64bit-lum-file tasks.

Things to Avoid:

Windows XP and Windows 2003 are NOT supported with Portal 8
For installing as non-root, apply PM64484
WAS 8 ND can be uninstalled while leaving Portal 8 installed. This will leave a broken Portal server that will not work. Do NOT do this.
Launchpad does not appear in user's language. Run 'setup LaunchPadLocale xx' where "xx" is fr, es, de, etc.
WAS 8.5 Liberty profile will not work with Portal because it does not contain WebContainer. Need to install WAS with 'Full Profile'.

Known issues:

May need clean up of some directories after uninstalling Portal and WAS. Should only be a remaining AppServer directory. This is expected.

Portal v8 Express Offering

Supported only on Windows, Linux, iSeries. Now supports 32-bit and 64-bit on Windows/Linux. 32-bit is only on 32-bit, 64-bit is only on 64-bit.
Must install WAS with Portal. Cannot install to an existing WAS.
No advance install – ports, profile name and context root are default
Install DB2 v9.7 under the covers
Does NOT support clustering except for Idle-Standby function
Available in trial version. Timesout after 60 days. If you buy the full version, you can run a Config task that picks up the license and turns off the timeout. Don't need to do anything else.
Only on Express will you be prompted for a DB2 user name and password.
Full install only, no base or custom installs.

Best Practices:

For Express, make sure a failed install is cleaned up. Especially true because of DB2 user id's.

Things to Avoid:

On Windows, need to have C drive present. Don't have to install C drive, it just needs to be present.
In trial version, if the <PortalServer root>/bin/lum/files get lost, Portal will not start up. Need to restore from backup or electronic image.
May need to first blank out password fields on the DB2 user id and password panel if you decide to change the user id.

How to update and redeploy wps.ear

twcornwe ‎ 1 Comentario ‎ 10.797 vistas

Introduction

In Portal 6.0, themes and skins were typically deployed in the wps.ear application. This included any customized themes and skins for your Portal site. The wps.ear applications, for all intents and purposes, is the primary application for WebSphere Portal that runs on top of Websphere Application Server. Updating a customized theme or skin in Portal 6.0 often was an effort that had to be scheduled during maintenance windows due to the fact an update to the wps.ear file was required. Thankfully, newer versions of Portal no longer require you to include your customized themes and skins in the wps.ear application. Instead, you may deploy such themes and skins in your own application on the Portal server independent of the wps.ear application.

However, there are occasions in newer versions of Portal where updates to the wps.ear application may still be required. For this blog entry, we will focus on the following APAR:

http://www-01.ibm.com/support/docview.wss?uid=swg1PM23905

The APAR itself introduces new code into the WebSphere Portal product. The new code changes the default behavior of the WebSphere Portal if activated. The new code is NOT activated by the action of installation of the APAR itself. Instead, manual changes must be made to a file inside of the wps.ear application, and the wps.ear application must be redeployed with those changes for the new code to become active.

Steps to update wps.ear for APAR PM23905
0) If in a cluster, execute these steps from the Deployment Manager.

1) Navigate to the /AppServer/bin directory

2) Run the wsadmin command to export the wps.ear file to a temporary directory (I used /tmp)

./wsadmin.sh -user wpsadmin -password wpsadmin -c '$AdminApp export wps /tmp/wps.ear'

*Note, this does NOT impact your existing running Portal server. This is a copy we are updating, not the running version.

5) Open the /tmp/wps_expanded/wps.war/WEB-INF/web.xml file in a text editor

6) At the VERY top of the file, just under display name

Add the following:

<filter-name>Home Substitution Filter</filter-name>
<filter-class>com.ibm.wps.engine.ServletSubstitutionFilter</filter-class>

</filter>

Resulting in:

7) After the very LAST </filter> and before the very first <filter-mapping>, i.e.

Add the following between these two lines:
<filter-mapping>
<filter-name>Home Substitution Filter</filter-name>
<url-pattern>/portal/*</url-pattern>
</filter-mapping>

resulting in:

8) Save changes.

9) Portal v8 only: Open the /tmp/wps_expanded/wps.war/WEB-INF/web_merged.xml file in a text editor. Repeat steps 6-8 in this file.

10) Backup the wps.ear file in the /tmp directory. Thereafter, delete the wps.ear file in the /tmp directory.

11) Run the EarExpander utility to collapse the files in /tmp/wps_expanded (including the web.xml just updated) into a new wps.ear file:
./EARExander.sh -ear /tmp/wps.ear -operationDir /tmp/wps_expanded/ -operation collapse

12) Run the wsadmin command to redeploy the updated wps.ear file

./wsadmin.sh -user wpsadmin -password wpsadmin -c '$AdminApp install /tmp/wps.ear {-update -appname wps -deployejb -deployejb.classpath /usr/IBM/WebSphere/PortalServer/base/wp.base/shared/app/wp.base.jar}'

*Note: This command will NOT impact the current running Portal Server loaded into in server memory. However, any files contained within the wps.ear file that are referenced by the Portal Server may be impacted. Thus, it is recommended to run this command during a maintenance window to minimize potential impact.

13) If in a cluster, sync nodes. Wait 5-30 minutes for the new wps.ear to be deployed across the cluster.

14a) Verify the web.xml under:
/usr/IBM/WebSphere/wp_profile/config/cells/<cellname>/applications/wps.ear/deployments/wps/wps.war/WEB-INF

includes the changes made in steps #6 and #7. This will verify the updated wps.ear file was deployed successfully.

14b) Portal v8 only: Verify the web_merged.xml also contains the changes.

15) Restart the Portal server(s). Changes should now be in effect.

Addendum to Original Posting

New bits of information will periodically be added to this entry.

1) Portal Infocenters

The official source of information should be the Portal Infocenters, with blog entries (such as this one) providing supplemental information to the Infocenters.

v61 Infocenter:

- Exporting the wps.ear file:

http://publib.boulder.ibm.com/infocenter/wpdoc/v6r1/index.jsp?topic=/com.ibm.wp.ent.doc_v615/admin/wsrpt_secltpa_expear1.html

- Redeploying the wps.ear file:

http://publib.boulder.ibm.com/infocenter/wpdoc/v6r1/index.jsp?topic=/com.ibm.wp.ent.doc_v615/admin/wsrpt_secltpa_redeploy.html

v70 Infocenter:

- Exporting the wps.ear file:

http://www-10.lotus.com/ldd/portalwiki.nsf/dx/Exporting_the_portal_EAR_file_wp7

- Redeploying the wps.ear file:

http://www-10.lotus.com/ldd/portalwiki.nsf/dx/Redeploying_the_portal_EAR_file_wp7

v80 Infocenter:

- Exporting the wps.ear file:

http://www-10.lotus.com/ldd/portalwiki.nsf/dx/Exporting_the_portal_EAR_file_wp8

- Redeploying the wps.ear file:

http://www-10.lotus.com/ldd/portalwiki.nsf/dx/Redeploying_the_portal_EAR_file_wp8

2) Portal v8 web_merged.xml file:

The original article was targeted towards WebSphere Portal 6.1 primarily. Additional actions are required for WebSphere Portal 8.0. In particular, both the web.xml and web_merged.xml file for wps.ear must be updated for changes to go into effect. (Thanks Thomas for the tip!)

Modificado el por twcornwe

Excessive alarm monitor warnings after upgrade to WAS 70.0.25

mowusua ‎ 9.683 vistas

If you upgraded to WAS 7.0.0.25 , regardless of your Portal version, you may notice a lot of otherwise innocuous alarm monitor threads warning along with various call stack such as below

AlarmThreadMo W UTLS0008W: The return of alarm thread "Non-deferrable Alarm : 1" (0000001f) to the alarm thread pool has been delayed for 40968 milliseconds. This may be preventing normal alarm function within the application server. The alarm listener stack trace is as follows:
<TRUNCATED>

WebSphere Application Server 7.0.0.25 introduced new serviceability feature to enhance the monitoring/configurability of Alarm threads. However the various settings introduced have default values that are rather low and too low for Portal operations . One of the parameters is

com.ibm.websphere.alarmthreadmonitor.threshold.millis

which determines how long an alarm thread runs before the warning is issued. So, for example, if the default settings value of com.ibm.websphere.alarmthreadmonitor.threshold.millis is used then the warning and possible stack traces are generated if the alarm threads runs for more than 40 secs

The default is 40 secs which is very low for most of the portal activities.

See this technote for the changes and how to implement new thresholds, etc
AlarmThreadMonitor warnings and stack traces on shutdown of WebSphere Portal http://www-01.ibm.com/support/docview.wss?uid=swg21623512

Creating a new CSA2 theme

jwbarnes Etiquetas: v7 theme csa2 ‎ 6.363 vistas

test

Creating a new theme in WebDAV:

In Websphere Portal v7, themes are broken apart into static template files and dynamic files. The static template files are stored in WebDAV and use dynamic content spots to reference JSPs or other dynamic resources. The dynamic resources are stored in a WAR file. WebDAV directories include files for the following theme functionality: theme, skin and layouts.

The following steps will create a new theme in portal using WebDAV.

Using a WebDAV client Connect to http://<server>:10039/wps/mycontenthandler/dav/themelist/
Copy the csa2.theme to your local directory
Rename the csa2.theme folder on your local system to sample.theme
Update the metadata\localized_en.properties to reflect the new title. You would need to modify each localized properties file for each languange.
Modify the theme_en.html file so that you can verify the correct theme is applied. This file is found in the nls directory
For example:
<body class="lotusui tundra locale_en" >

Sample Theme
Copy the sample.theme folder to the themelist entry point using the web dav client.
In portal create a new page named Sample Theme and apply the Sample Theme theme using the admin portlet, best practice is to create the page using the edit mode of the theme, however creating it through the admin portlet will reveal some differences in page types in 7.0, and a common customer scenario.
Render the page and verify that your theme_en.html is being rendered. You should see the text ?Sample Theme? rendered on the page
Modify your theme_en.html to the following:
<body class="lotusui tundra locale_en" >

Sample Theme Modified 

Copy the modified theme_en.html back to the server using the themelist entry point
Do you see the update?
By default the WebDAV files are cached for 24 hours. You will need to change the cache values during theme development in order to see the changes immediately.

Open the WSAS admin console and go to the WP_ConfigService Resource Evironment Provider (REP) Resources ->Resource Environment ? Resource Environment providers
In the custom properties you will see several entries like the following:

Please see the following section in the infoCenter for more details about this caching:
http://www-10.lotus.com/ldd/portalwiki.nsf/dx/Using_WebDAV_file_store_for_the_Page_Builder_theme_and_mashup_integration_wp7

Change all of the following entries to a value of 1 and restart the server. This will reduce the caching for the WebDAV files to 1 second.
filestore.cache.expiration.0.seconds
filestore.cache.expiration.1.seconds
filestore.cache.expiration.2.seconds
filestore.cache.expiration.3.seconds

Render the page again and you should see the modified output from the theme_en.html

note: best practice is to use the fs-type1 entry point for modifying the files and not the themelist entry point. The themelist entry point is an admin entry point and is used for altering theme metadata including the titles. Please note the cache above will only effect the themelist entry point not the fs-type1. As an additional exercise reset the caching to default values, restart the server, and then make a change via the fs-type1 entry point and see that your changes are immediately visible.

Now that the new theme is created lets take a few minutes to understand what happened by generating a complete xmlAccess export of the server using the following technote:

http://www-01.ibm.com/support/docview.wss?uid=swg21260098

Note that you will be using this XMLAccess export in a future step.

You should now see a theme defined like the following (the objectid may be different):

<theme action="update" active="false" context-root="/PageBuilder2" default="false" domain="rel" objectid="ZJ_4GFA8VO20G3ID0IMR5PK562006" resourceroot="PageBuilder2">

....

<localedata locale="en">

<title>Sample Theme</title>

<description/>

</localedata>

....

<parameter name="theme.capability.dojo" type="string" update="set"><![CDATA[1.4.3]]></parameter>

<parameter name="com.ibm.portal.friendly.name" type="string" update="set"><![CDATA[sample.theme]]></parameter>

<parameter name="com.ibm.portal.themetype" type="string" update="set"><![CDATA[CSA2]]></parameter>

<parameter name="theme.capability.oneUI" type="string" update="set"><![CDATA[2.1]]></parameter>

<parameter name="com.ibm.portal.theme.template.ref" type="string" update="set"><![CDATA[dav:fs-type1/themes/sample.theme/]]></parameter>

<parameter name="theme.capability.mashups.enabler" type="string" update="set"><![CDATA[2.4]]></parameter>

</theme>

The newly created sample theme is using the PageBuilder2 war file. This can be seen from the context-root and resourceroot attributes. There are also several parameters defined for the theme. If present, the ?com.ibm.portal.friendly.name? parameter is used as the display name for the theme in the themelist webDAV entry point. This should be a unique value in the system but this is not enforced. If the ?com.ibm.portal.friendly.name? parameter is not available then the uniquename of the theme is used as the display name. If neither the ?com.ibm.portal.friendly.name ? or the uniquename are defined for the theme then the theme's OID will be used as the display name.

The themelist webdav entry point mirrors the fs-type1 entry point. Since the themelist uses the ?com.ibm.portal.friendly.name as the display name it has to be unique. If there are two themes that have the same value, only one will be displayed.

When our sample theme is rendered the default.jsp of the PageBuilder2 WAR is the main entry point. The default.jsp will then call the correct theme.html file to execute. It determines the correct path by using the com.ibm.portal.theme.template.ref parameter.

Creating a new theme WAR file

The theme WAR file will contain the dynamic resources. As stated in the previous section the default.jsp of the

PageBuilder2 theme is used when our sample theme renders. If you want to modify the default.jsp or any of the dynamic resources you should create a new WAR to contain them.

Copy the following WAR into a temporary working directory:

<portal install>\theme\wp.mashup.cc.theme\installedApps\wp.mashup.cc.theme.ear\PageBuilder2.war

In Rational Application Developer (RAD) or Eclipse, create a new Dynamic Web Application titled PageBuilder2 theme from the temporary working directory you created above for the new WAR.

I created a new project then pasted the contents of the war directory into the web content directory
Open up the web.xml and change the display name to ?SampleTheme?
<display-name>SampleTheme</display-name>
Under the themes\html directory your will see a folder named PageBuilder2. Rename this directory to SampleTheme. This directory name will be used as the resourceroot in a later step so if you name it something different you will need to update the resourceroot later.
We will also add some content to the Default.jsp so that we can verify the correct theme is being picked up.
Open the default.jsp and add the following code right after the include to the bootstrap.jspf:(this default.jsp will be in the root html directory not in the theme directory
<%@include file="./bootstrap.jspf" %>

SampleTheme Default.jsp 
Export the WAR from RAD
Import the WAR into the WSAS admin console.
When importing the theme use ?/sampletheme? as the context root for the theme. This will be used in a later step for the ?context-root? in the xmlAccess file. If you name this differently you will also have to change the context-root value in later steps.
Start the application in the WSAS admin console
We will use the xmlAccess export from a previous step to change the context-root and resourceroot of the sample theme to point to the newly created WAR file.

Note: Please refer back to step 4 and step 7 if the values for context-root and resourceroot are not clear.

Example :
<?xml version="1.0" encoding="UTF-8"?>

<request build="wp700_606_01" type="update" version="7.0.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="PortalConfig_7.0.0.xsd">
<portal action="locate">
<theme action="update" active="false" context-root="/sampletheme" default="false" domain="rel" objectid="ZJ_4GFA8VO20G3ID0IMR5PK562006" resourceroot="SampleTheme">
<localedata locale="en">
<title>Sample Theme</title>
<description/>
</localedata>
<parameter name="theme.capability.dojo" type="string" update="set"><![CDATA[1.4.3]]></parameter>
<parameter name="com.ibm.portal.friendly.name" type="string" update="set"><![CDATA[sample.theme]]></parameter>
<parameter name="com.ibm.portal.themetype" type="string" update="set"><![CDATA[CSA2]]></parameter>
<parameter name="theme.capability.oneUI" type="string" update="set"><![CDATA[2.1]]></parameter>
<parameter name="com.ibm.portal.theme.template.ref" type="string" update="set"><![CDATA[dav:fs-type1/themes/sample.theme/]]></parameter>
<parameter name="theme.capability.mashups.enabler" type="string" update="set"><![CDATA[2.4]]></parameter>
</theme>
</portal>
</request>

Note: You will need to use the information from your export since the OIDs will be different. You cannot use the xml above.
Import the modified xml file using xmlAccess. You can do this by simply navigating to the Portal Administration Console and choosing the import XML option and then pointing to the updated xml file for the theme.
Now render the page again and you should the following:
Now modify the bannerNav.jsp to add some additional markup.
Example:
Sample Theme bannerNav.jsp 
<%-- Renders the links in the banner (Home, Admin, etc.) server side --%>
Rebuild the WAR and then update it in the WSAS admin console.
Refresh the page, do you see the updated markup you added in the bannerNav.jsp?
You should not see your changes in the bannerNav.jsp

The default.jsp of the Sample Theme is used when rendering the page with the theme applied. However as stated previously the default.jsp will call the static theme template that is defined in the themes metadata. For the sample theme
it uses the following:

dav:fs-type1/themes/sample.theme/

If you inspect the theme_en.html file you see the following dynamic-content-spot that is used to render the bannerNav.

<a rel="dynamic-content" href="dyn-cs:id:bannerNav@tl:oid:csa2.theme"></a>

This markup will inform the static page parser in WebSphere Portal to look for dynamic-content-spot with an id of bannerNav. You will also notice that the href contains @tl:oid:csa2.theme. This instructs the static page parser to look in the theme with a uniquename of csa2.theme for any dynamic-content-spot overrides. All this means is that your theme is still using the bannerNav.jsp from the PageBuilder2 WAR file and not from your custom SampleTheme WAR.

If you want it to your content spots to pull from your custom war you would need to change them to reference your custom war.
You have three options:
Please see the following section of the InfoCenter for more details http://www-10.lotus.com/ldd/portalwiki.nsf/dx/Working_with_dynamic_content_spots_wp7

Defining a custom content spot via the resource environment provider
adding an override to the theme metadata
changing the href to be a resource url
<a rel="dynamic-content" href="res:/sampletheme/themes/html/SampleTheme/bannerNav.jsp"></a>

Things to consider when creating new virtual portals in Websphere Portal v7

twcornwe Etiquetas: security initialization script portal virtual initialize vp permision xml ‎ 6.316 vistas

*** Location of Virtual Portal Scripts

When you create the virtual portal by using the Virtual Portal Manager portlet, the virtual portal is pre-filled with default content. This default content is determined by the default XML script file for initializing virtual portals.

In previous versions of Portal, the Virtual Portal (VP) initialization xml scripts are stored on the file system in the directory ...//wp_profile/installedApps/<node_name>/wps.ear/wps.war/virtualportal. In Portal 7, the VP initialization scripts are located in a WebSphere Application Server (WAS) asset named VirtualPortal.zip. To get to this file, access a WebSphere Application Server administrative console, select Applications -> Application Types -> Assets, and locate the file in the list.

This VirtualPortal.zip file is physically located in:<wp_profile>/config/cells/<cellname>/assets/VirtualPortal.zip/aver/BASE/bin (in a stand-alone Portal environment)

<DMGR_profile>config/calls/<DMGR_Cell_name>/assets/VirtualPortal.zip/aver/BASE/bin (in a clustered environment)

In a migrated Portal v7 environment, as part of the migration process the virtual portal scripts are removed from the .../wps.ear/wps.war/virtualportal directory and moved to a WAS asset zip file named MigratedVirtualPortal.zip and is located in the .../VirtualPortal.zip/aver/BASE/bin directory as mentioned above.

*** WebSphere security role required

As the VP initialization scripts are now located in a WAS asset, WAS security comes into consideration when Portal class is accessing WAS services. As a result, if the user who attempts to create or initialize the VP has no proper privileges on the WAS, the task cannot access the XML file used to initialize the virtual portal and it will fail with the exception "EJPAH2012E: Can not find xmlaccess script".

This issue was reported under APAR PM39581, and a fix was released as part of Cumulative Fix CF006 for Portal 7.0.0.1, but unfortunately the WAR is not redeployed in CF06, CF07, or CF08. The WAR is properly redeployed in CF09.

Therefore, in CF06, CF07, or CF08 to take advantage of this fix, customers should manually redeploy the WAR by copying PortalServer/ap/wp.ap.virtualportal/installableApps/ManageVirtualPortals.war to PortalServer/installableApps/ManageVirtualPortals.war and then running the ConfigEngine.sh/bat deploy-portlet-upgrade-wp.ap.virtualportal

If you can not upgrade Portal to the later CF that includes this fix, you can workaround this issue by logging in to the IBM® WebSphere® Integrated Solutions Console (ISC) admin console as the WAS administrative user and giving the user who is trying to create or initialize the virtual portal the "Monitor" role, which is the minimum requirement.

* Steps to add "Monitor" role for a user:

- Go to: Users and Groups >> Administrative user roles >> Add

- Highlight the "Monitor" role in the Role(s) box

- Search for the user and select the user from the search results

- Click the "Add" button

- Click "OK". Then save to the master configuration.

- Restart Portal

After these steps, user should be able to create virtual portals using the Virtual Portal Manager portlet and to initialize the virtual portal created previously that failed to initialize.

This situation is described in more details in IBM Technote # 1469910

*** Migrated VP scripts vs. Fresh Install VP scripts

Another issue that may occur in Portal v7 environment migrated from Portal v6.1 is caused by a missing Portal resource in Portal v7. The migrated VP initialization script may contain references to the "Manage Seed List" portlet, which has become obsolete in Portal v7 and will cause the script to fail with exception such as:

"EJPXA0025E: The resource was not found in the portal, either because it does not exist or because you have not specified an identifying attribute in the XML input. [portlet <portlet_objectID> name=Manage Seed List]"

The reason that these scripts are not updated during migration is that they are considered customer scripts. The scripts that ship with Portal just have the sample content and pages in them. So there is an assumption that the customer may have updated the scripts with their own pages and content; therefore, the migration process just moves these scripts untouched into the WAS asset VirtualPortal.zip in the target Portal v7 environment.

To avoid this issue,

* BEFORE MIGRATION: Remove those references to "Manage Seed List" in your VP xml scripts. For example, remove these lines:

And this:

<portletinstance action="update" domain="rel" objectid="portletinstance_objectID" portletref="<Manage_Seed_List_objectID>" shareref="5_CGAH47L008DE402BK8543I18D4"></portletinstance>

(The object ids, portletrefs, sharerefs, etc ... may vary in your installation.)

* AFTER MIGRATION: If you have already migrated, use the WAS admin console to export the VirtualPortal.zip asset, update the VP initialization script as above, then re-import the asset. Refer to the section "Asset Collection" of the Websphere Application Server v7 Information Center for details on how to update the asset.

WAS may make multiple calls to Active Directory domain controller for each Portal login attempt

twcornwe Etiquetas: ldap active directory ad authenticate domain login ‎ 5.507 vistas

There has been at least one case when a customer reported that in the Production environment, when a user attempted to authenticate with Portal and put in the wrong password 2 times, at the 3rd attempt, his/her LDAP account was locked and the user could no longer log in to Portal

In this specific environment, Portal is configured with the Active Directory (AD) LDAP. The AD LDAP is set up to allow 5 invalid attempt. During troubleshooting Portal support suggested that customer tested with authentication with AD directly, and it indeed allowed up to 5 invalid attempts. Whereas, Portal would lock the user account at 3rd attempt to login to Portal, after 2 failed attempts.

Customer also has a Test environment with similar Websphere/Portal version, but the problem did not exist there: users could still log in to Portal at 5th attempts in the Test environment server.

Support then found that in the Test environment (which was working correctly), the LDAP host name pointed to a single LDAP server. Whereas, in the Production environment (where the problem occurred), the LDAP host name pointed to the LDAP Domain Controller.

So, it appears in the case of Production environment, for each attempt to log in to Portal, two calls were made to the AD Domain Controller. Thus, after two invalid Portal login attempts, the AD Domain would see those as 4 invalid attempts, so at subsequent attempt to authenticate with Portal (which make them the 5th and 6th LDAP calls), the AD user account was locked.

A review of Portal login traces showed the following:

---------------------------------------

[10/18/11 15:51:19:545 PDT] 00000062 ltpaLoginModu 3 Authenticating "WPS/e123456"

[10/18/11 15:51:19:545 PDT] 00000062 LTPAServerObj > authenticate Entry

[10/18/11 15:51:19:545 PDT] 00000062 UserRegistryI > checkPassword Entry e123456

****

.......

[10/18/11 15:51:28:107 PDT] 00000062 ltpaLoginModu 3 Authenticating "WPS/e123456"

[10/18/11 15:51:28:107 PDT] 00000062 LTPAServerObj > authenticate Entry

[10/18/11 15:51:28:107 PDT] 00000062 UserRegistryI > checkPassword Entry e123456

****

[10/18/11 15:51:28:107 PDT] 00000062 LdapRegistryI > checkPassword Entry e123456

[10/18/11 15:51:28:116 PDT] 00000062 LdapRegistryI 3 Found user CN=Test User(E123456),OU=EAST,OU=SALES,DC=IBM,DC=COM

[10/18/11 15:51:28:117 PDT] 00000062 LdapRegistryI 3 enterJNDI:WebContainer : 1

[10/18/11 15:51:28:146 PDT] 00000062 LdapRegistryI 3 exitJNDI:WebContainer : 1

[10/18/11 15:51:28:146 PDT] 00000062 LdapRegistryI < checkPassword Exit javax.naming.AuthenticationException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C0903AA, comment: AcceptSecurityContext error, data 775, v1772 ]

at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3045)

at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2991)

...

---------------------------------------------

As we can see from the traces, the wrong password was entered twice. The 3rd time, the correct password was submitted. The LDAP responded back that it found the user. But then immediately after that the LDAP threw the LDAP: error code 49 - data 775 (Note: data 775 means: user account locked").

The root cause of in this specifc case was that the LDAP custom property "com.ibm.websphere.security.ldap.retryBind" was not explicitly set. By default, it's set to "true". The WAS APAR PK42672 introduced a couple of LDAP security custom properties. Depending on how LDAP fail over is configured, either of them can be implemented to avoid this type of issue from happening.

Excerpt from the APAR document:

---------------------------

"When single LDAP hostname is mapped to multiple IP address in network configuration, If invalid password is entered at the time of login, WebSphere makes LDAP bind retries as many times as (number of associated ip addresses + 1) This may cause LDAP account lockout."

The following custom properties are introduced to prevent the issue from happening. It depends on the LDAP failover configuration to choose which property to use.

1. If LDAP failover is configured by registering backend LDAP server hostnames using wsadmin command, set the following property to true by going Security --> User Registries --> LDAP --> Custom Properties in the WAS administrative console.

com.ibm.websphere.security.registry.ldap.singleLDAP

If this property is set to true, Application Server does not resolve an LDAP hostname to multiple IP addressed. The default value for this property is "false".

2. If LDAP failover is configured by associating hostname with mutlipe IP addresses using network configuration, set the following property to false by going Security --> User Registries --> LDAP --> Custom Properties in the WAS administrative console.

com.ibm.websphere.security.ldap.retryBind

If this property is set to "false", Application Server does not retry LDAP bind calls. The default value for this property is "true".

-----------------------------

Clearing out Cookies with Portlet code

twcornwe ‎ 5.483 vistas

Introduction

WebSphere Portal end users can run into situations where cookies in the web browser are not always cleaned up properly. It can be helpful to have code available which can remove cookies automatically and transparently to the end user. In earlier versions of WebSphere Portal, this was accomplish through a quick bit of javascript code, often enabled in a custom theme. With WebSphere Portal v8 and newer, the HttpOnly attribute is set on cookies which prevents javascript code from cleaning up the cookies. Removing the HttpOnly attribute from the cookie is not recommended, as you leave your end users open to possible cross-site scripting attacks.

This article will explore an alternative method to clearing out cookies - use of a portlet on a WebSphere Portal page. The code performs two functions:

1) Clear out the JSESSIONID, LtpaToken, and LtpaToken2 cookies if present in the web browser.
2) Redirect the user to a different location once the cookies are cleared

This article will also discuss setting up a page in WebSphere Portal where the portlet can be deployed, however, the page will not be visible to end users.

A download link is available at the end of the article with sample code and a sample page in WebSphere Portal.

Setting up the Portlet

IBM Rational® Application Developer for WebSphere® Software v8.0.4 was used to develop this portlet. However, any software which can create a JSR286 portlet with two-phase rendering capabilities can be used to author the necessary code. Instructions will be detailed specific to Rational Application Developer.

1) Create a new portlet project. I called mine "cookieeater".

2) Select a target runtime of WebSphere Portal 7.0 stub or later. Do not add a project to an EAR. Select JSR286-Basic API with Basic Portlet type. Do not enable Web 2.0 Features. Optionally, you my add an action listener, however it is not required for the code in the portlet.

3) Open the portlet descriptor. Add the a container runtime option of javax.portlet.renderHeaders with value true.

4) Open the portlet descriptor. Update the default namespace to a value of your choice.

*Note: My end result in portlet.xml for steps #3-#4 looked like
<portlet-app>
...
<portlet>
...
</portlet>
<default-namespace>#default</default-namespace>
<container-runtime-option>
 <name>javax.portlet.renderHeaders</name>
 <value>true</value>
</container-runtime-option>
</portlet-app>

5) Open the jsp file under your WebContent folder. Add the following snippet of javascript code:

*Note: Modify this location to the actual location you wish to send end users after cookies are cleared out. e.g.

http://myportalserver.ibm.com:10039/wps/portal

6) Open the java source code for your portlet. Add the following two constants:

final String PATH = "/";
final String DOMAIN = "";

*Note: Modify these two constants specific to your configuration.

7) Add the following method to the source code:

public void doHeaders(RenderRequest request, RenderResponse response)

8) Within the doHeaders method is where the cookie clearing logic occurs. My code looked like the following:

Cookie[] cookies = request.getCookies();
       if (cookies != null)
       {
           for (Cookie cookie : cookies)
           {
               if (cookie.getName().equals("JSESSIONID") || cookie.getName().equals("LtpaToken") || cookie.getName().equals("LtpaToken2"))
               {
                    cookie.setPath(PATH);
                   cookie.setDomain(DOMAIN);
                   cookie.setMaxAge(0);
                   cookie.setValue("");

                   response.addProperty(cookie);
               }
           }
       }

*Authors' note: Removing the cookies does NOT perform a logout from WebSphere Portal! Do NOT use this code as a substitute for logging out.

9) Export your code to a WAR file.

10) Done with coding! Let's setup our Portal page with this portlet now.

Setting up the Portlet

1) Deploy your cookieeater.war file via the "Web Modules" portlet

*Author's note: I'm not sure why, but the web.xml file for my portlet contained the following stanza repeated multiple times <welcome-file-list>. Portlet deployment initially failed as a result for me. Manually cleaning up the web.xml file so only a single <welcome-file-list> stanza existed resolved the issue.

2) Create a new page in WebSphere Portal either via the Manage Pages portlet, or, via Edit Mode. I called my page "eatme" and created it under the "Home" label. Give it a friendly URL of "eatme".

3) Add the cookieeater portlet to the page using either the Edit Page Layout portlet in Manage Pages, or, via Edit Mode.

4) Navigate back to your Home label in your theme. You should now notice a page called "eatme".

5) Click the "eatme" page.

- Your JSESSIONID, LtpaToken and LtpaToken2 cookies should be cleared out.

- You should be redirected to the site specified in the javascript of your jsp.

At this point, while the "eatme" page accomplishes 2 of 3 of our end goals, its sitting out there in plain site of end users. Any user who happens to click on the page will have their cookies removed and will be forced to relogin to Portal. Not good. Next steps are to hide this page.

6) Navigate back to your WebSphere Portal. Log back in as an Administrator.

7) Navigate to the Manage Pages portlet. Click the 4th icon to "export" the page.

8) Open the exported page.xml file. Locate the following two lines:

</pagecontents>
<parameter name="com.ibm.portal.IgnoreAccessControlInCaches" type="string" update="set"><![CDATA[false]]></parameter>

9) Update to the following, adding the new parameter "com.ibm.portal.Hidden" with value "true".

</pagecontents>
 <parameter name="com.ibm.portal.Hidden" type="string" update="set"><![CDATA[true]]></parameter>
 <parameter name="com.ibm.portal.IgnoreAccessControlInCaches" type="string" update="set"><![CDATA[false]]></parameter>

10) Save changes.

11) Navigate to the Import XML portlet in the Administration area.

12) Import the updated page.xml with the new page parameter added.

*Author's note: Any page parameters that begin with com.ibm.portal.* cannot be set via the GUI. The only means to set them is through XMLAccess scripting.

13) The "eatme" page should no longer be visible within your Portal site.

14) Test the Friendly URL of the page, e.g.

http://myportalserver.ibm.com:10039/wps/myportal/Home/eatme

15) Your cookies should be removed and you should be redirected to the site specified in the javascript of your jsp.

16) (Optional): Set anonymous permissions on the page and portlet.

17) Enjoy! Feel free to implement and modify for your own specific Portal site. You should be able to send users to this friendly URL as needed within your Portal site to clear out cookies.

Sample End Result Portlet and Page

https://greenhouse.lotus.com/files/app/file/f7930521-d50e-4f23-b628-9a452df64bac

Modificado el por twcornwe

WebSphere Portal version 8 Installation Social Workshop

ffeng ‎ 5.340 vistas

IBM WebSphere Portal Support team ("Portal support" henceforth) is pleased to announce that WebSphere Portal version 8 Installation Social Workshop will be held from 7/9 to 7/26. This is a great opportunity for IBM support to engage customers, business partners, and IBM service and technical sales personnels ("customers" henceforth) on our current social media presence, i.e. Facebook page (http://www.facebook.com/WebSpherePortalSupport) and Twitter (@PortalSupport, or http://twitter.com/PortalSupport).

WebSphere Portal version 8 is the latest release of the product. The installation takes a brand new form, using IBM Installation Manager (IIM, or IM). Thus potentially customers could meet many new challenges never encountered before. In this social workshop, Portal support will share with customers the best practices and troubleshooting knowledge of potential problems.

During the 3 week period, we encourage customers to download the product from IBM Passport Advantage site and start testing the installation process. During the period of the workshop, we will try to answer customer's questions on the social media. This is our first time to experiment the social channel. By no means, we are replacing our normal support procedures. As a matter of fact, support may suggest customers to open PMRs when the problems become so complex that is beyond the capacity of social media.

The detail of the workshop are the following,

- On 7/9 (Monday), we start a thread with URL links to some best practice presentations and blogs. Customers can start reading, researching and testing the installation process;

- On 7/12 (Thursday), we will have a Twitter chat session at 1 PM ET, with hashtag "#wpv8chat". If you are not familiar with Twitter, get an account now and start tweeting;

We will publish a summary of the first Twitter chat session.

- On 7/19 (Thursday), we will schedule another Twitter chat session at 1 PM ET. Hopefully, after the first week, most of concerns and questions are addressed and answered, and customers have gained some basic experience. This session would deal with maybe some in-depth issues.

- Tentatively, we will schedule another Twitter chat on 7/26 at 1 PM ET. If this is unnecessary, we can cancel it with an announcement on the Facebook page.

- Between these scheduled sessions, we still encourage customers to send us questions, suggestions, and requests on our Facebook page and Twitter handle.

Please come join us, participate in the dialog, and increase your social engagement.

How to test xmlaccess with your server

Tony Donato Etiquetas: xmlaccess ‎ 5.148 vistas

One of the more common type of "health check" errors that may occur during a fixpack installations is a failure during its xmlaccess test section. You may receive a BUILD FAILED message that looks like this:

Server validation failure: XMLAccess test script failed. Please ensure that your WebSphere_Portal server is functional and that PortalAdminPwd, WasPassword, XmlAccessHost, XmlAccessPort, WpsHostName, WpsHostPort, and database passwords are all correct in their respective C:/IBM/WebSphere/wp_profile/ConfigEngine/properties files. After doing so, rerun the PTF.

This often indicates that some of the properties you have listed above are not correct or that the server is not resolving properly to either its host name or local host.

This simple troubleshooting script can often help with finding out the culprit:

1. On the portal server, open a command window and change to the <profile>/PortalServer/bin directory.

2. Copy this file:

<WAS_root>/PortalServer/base/wp.xml/doc/xml-samples /Task.xml to the <profile>/PortalServer/bin directory

3. Enter this command replacing all < > entries with your Portal's values:

xmlaccess.bat|sh -in Task.xml -user <PortalAdminPwd> -password <admin pwd> -url http://<portal hostname>:<port>/wps/config -out results.xml

By testing both the localhost name, fully, qualified host name, port, and expected PortalAdminPwd you can often determine what may be off with your properties settings.

Here is an example of a failed run of the command:

C:\IBM\WebSphere2\wp_profile\PortalServer\bin>xmlaccess.bat -in Task.xml -user wpsadmin -password xxxxxxxx -url http://IBMD1.ibm.com:10040/wps/config -out resul

ts.xml

Licensed Materials - Property of IBM, 5724-E76, 5655-R17, and 5655-M44, (C) Copy

Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract

with IBM Corp.

EJPXB0006I: Connecting to URL http://IBMD1.ibm.com:10040/wps/config

EJPXB0004I: Writing output file C:\IBM\WebSphere2\wp_profile\PortalServer\bin\results.xml

EJPXB0002I: Reading input file C:\IBM\WebSphere2\wp_profile\PortalServer\bin\Task.xml

EJPXB0019E: Server response indicates an error. For status and details of the XmlAccess error look at file results.xml.

Here is an example of a successful run of the command:

C:\IBM\WebSphere2\wp_profile\PortalServer\bin>xmlaccess.bat -in Task.xml -user wpsadmin -password wpsadmin -url http://IBMD1.ibm.com:10040/wps/config -out results.xml

Licensed Materials - Property of IBM, 5724-E76, 5655-R17, and 5655-M44, (C) Copy

Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract

with IBM Corp.

EJPXB0006I: Connecting to URL http://IBMD1.ibm.com:10040/wps/config

EJPXB0004I: Writing output file C:\IBM\WebSphere2\wp_profile\PortalServer\bin\results.xml

EJPXB0002I: Reading input file C:\IBM\WebSphere2\wp_profile\PortalServer\bin\Task.xml

EJPXB0020I: The request was processed successfully on the server.

Ever Needed to tune WSSECUREMAP cache?

mowusua Etiquetas: tuning portal caches ‎ 5.074 vistas

Ordinarily all cache tuning information are found in the Portal tuning guides below at the bottom of the page . The documentation usually contain the recommended cache sizes and lifetime as well as how/where to set. WSSECUREMAP is not one of them . There is the description but not how to set it even though it must be stated you probably may not need to tune this cache often

Here is how and where to tune it

WSSecureMap is the DynaCache used for Security Attribute Propagation. This cache should be created with DynaCache default size of 2000.
The DynaCache default could be changed but that would affect all caches created with the DynaCache default.

1. If you wish to change only the size of WSSecureMap, you can use following 2 custom properties:

com.ibm.ws.security.WSSecureMapInitAtStartup=true
com.ibm.ws.security.WSSecureMapSize=X (X = desired size - positive integer more than 100)

Note that the specified size is used ONLY if the ...InitAtStartup   property is also configured and set to true.

To set the property from administrative console page,

Click Security > Global security > Custom properties
Click New to add new custom properties and associated  values as mentioned.

2. The lifetime of entries cannot be configured. Entries in this cache remain valid until the Subject contained in the entry is no longer
valid. This is usually the LTPA timeout which defaults to 2 hours. If you have any problem ( Ex: WSSecureMap is not working as expected)

If you have any issues with this cache, Open a support pmr with the Security Mustgather http://www-01.ibm.com/support/docview.wss?uid=swg21470063

Portal Caches information [http://www-10.lotus.com/ldd/portalwiki.nsf/dx/WebSphere_Portal_caches_%28Tuning_Guide_6.1.x%29]
Portal 7 tuning guide [http://www-10.lotus.com/ldd/portalwiki.nsf/dx/WebSphere_Portal_Tun]

Determining the Number of Users Logged Into Portal

twcornwe ‎ 5.006 vistas

Introduction

One of the questions we often receive is a fairly simple question - "How many users are logged into Portal right now?". Most of the time, the response is not a straightforward answer, but a series of counter-questions which ask "What do we define as the user being logged in?"

- If a user clicks logout, that can be considered a straightforward answer of "they are no longer logged in, therefore, do not count them".
- If a user perform a login to Portal with Firefox, then perform a login to Portal with Chrome, do we consider that one login, or two logins?
- If a user closes their web browser, but doesn't logout from Portal, do we still consider them logged in, or, are they logged out?
- If a user steps away from their machine for a brief period of time, and comes back, the session timeout has tripped but the LTPA timeout has not tripped - do we consider them logged in or logged out at that point?
- If a user adds an item to a shopping cart, but is not yet logged into the Portal site, do we consider that as being "logged in?"

And this is the tip of the iceberg without going into the multitude of additional configuration options available in WAS/Portal which could spawn many many more questions. For purposes of this blog entry - we will define the number of logged in users to Portal to be roughly equivalent to the sessions that exist in the Portal. For Portal sites which require a login to the Portal, this will provide a fairly accurate count of users active in the Portal server. For Portal sites which do not require a login, but do have public session enabled, the same logic holds - it is a good approximation of how many users are active on the Portal server. For Portal sites which do not require a login and do not require a public session, this blog entry will unfortunately not apply to those sites and a different set of tools are needed to make determination for such sites. For the Portal sites which do require a session - we will answer that question in this blog entry.

Setting up Monitoring

WebSphere Application Server ships a built-in set of monitoring code called Performance Monitoring Infrastructure (PMI). PMI can be used to monitor a number of different activities in a WAS server - such as the total number of database connections, total number of LDAP connections and for what we are interested in discussing - the total number of active sessions in a Portal server. PMI itself is enable on a per application basis and for WebSphere Portal there are typically over a hundred applications deployed to a Portal server. Enabling PMI across all applications would be expensive and unnecessary to answer our basic question. Instead, we would look to enable PMI on a single application only - wps - and monitor the session count of that application.

To enable PMI for the number of sessions on the wps application - perform the following steps:
1) Login to the Deployment Manager / WAS Console
2) Navigate to Monitoring and Tuning > Performance Monitoring Infrastructure > WebSphere_Portal
3) In the configuration tab, select "Basic" if not already selected.
4) Save changes.
5) If in a cluster, repeat steps #2-#5 for each Portal server in the cluster. Sync nodes.
6) Restart the Portal server(s)

While more advanced PMI beyond the "Basic" setting can be enabled on the Portal server(s) - the Basic level is sufficient to answer our original question posed.

Monitoring Session Count

1) Login to the Deployment Manager / WAS Console
2) Navigate to Monitoring and Tuning > Performance Viewer > Current activity > WebSphere_Portal
3) On the left-hand side, click the Plus (+) next to WebSphere_Portal > Performance Modules > Servlet Session Manager > wps#wps.war
4) Click "Start Monitoring"
5) Repeat steps #2-#4 for each Portal server in the cluster.
6) Navigate back to the wps#wps.war per Portal server to see the session count.

In the screenshot below, a single session / user logged in is shown for demonstration purposes:

In a live production system with hundreds or thousands of users logged in - you can monitor the activity over time to determine when peak loads may exist.

Modificado el por twcornwe

Canal de información para entradas de blogs Canal de información para comentarios de blogs

Blogs