Thoughts on Portal from Level 2 Support
Today WebSphere Portal Level 2 support and development hosted our first Twitter chat session. This is an important event in the Social Workshop. We took our first baby step in our social engagement with Portal customers. We had hoped there could be more customers joining us and bring their questions. In the end, only a few showed up.
Here is the summary of the chat and discussions I composed at Storify,
The following showed some statistics. The free service won't keep the result for long though.
ffeng 270003GNYR 2,902 Visits
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.
The following blog discusses Portal v8 installation best practices, things to avoid and some general information:
General Information on IIM:
General Information on WebSphere Portal 8 Installation:
Portal v8 Regular Offerings (Server, Enable, Extend, WCM, WCM SE)
Things to Avoid:
Portal v8 Express Offering
Things to Avoid:
httweed 120000PJAG 1,394 Visits
New Portal v8 tutorials are available at this site:
So far the choices are limited (Installation, DB2 database-transfer and Customizing the site) but it seems very promising, so worth keeping an eye on I think. The tutorials are very easy to follow for Portal beginners.
twcornwe 0600025RJ4 3,174 Visits
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 globalThe 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.
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.
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:
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.
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:
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:
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
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)
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.
jbroz 060000WDC6 827 Visits
LDAP users must be defined by Distinguished Name in a group
In some LDAP servers, it is possible to set up a group whose members are not defined by DN as in this example:
Even if the groupConfiguration in wimconfig.xml is correctly defined with the appropriate objectClass and scope, this arrangement will cause VMM to treat the name identifier (here shown as memberUid) as a standard attribute and not a membership attribute.
Rather than returning all members by name, which VMM expects, the identifier will be returned followed by the members as a simple list of values:
DN: cn=group,o=ibm,c=com ... Type: Group
memberuid=memberUid: bob, mary, jim, alice;
VMM determines the group has no members.
To correct the configuration, ensure that all group members are defined with a fully qualified Distinguished Name:
You may get in situation where the JCRCollection1 appears to be correctly set up with no errors but notice the following
-Zero count document after successfully starting and running the crawler
- No errors exists in the logs
- Even a JCRCollection recreate has not help .
In such a scenario resetting the various JCR databse tables that backup the collections and the JMS services associated with the collection may be an option
Please uncheck the "Force Complete Crawl" checkbox.
After that, please reset the database tables of crawler by executing the below sqls:The Force complete Crawl option will be located under "General Parameters" tab for the content source
1. delete * from jcr.icmstjcrtssubscriptionmanager;
2. delete * from jcr.icmstjcrtsseedlistpending;
3. update jcr.icmstjcrtsfullcrawltopics set TS=null,subscriberid=null;
Once the sqls are executed, Please do the following :
1. Enable the JCR TextSearch trace com.ibm.icm.ts.*=finest.
2. Go to Administration - Manage Search - JCRCollection1 - JCRSource. Run the Crawler only once.
3. Check and confirm whether the number of documents in JCRSource is greater than 0.
httweed 120000PJAG 941 Visits
The new IBM WebSphere Portal v8 Cluster Guide is now published and can be found here.
Hope you guys find it useful!
WebSphere Portal Support Goes on Social
We recently launched IBM WebSphere Portal Support Facebook page. Along with the revamped Twitter handle, we have formally started our social engagement with Portal customers, business partners, and IBM service personnels. The Facebook page can be accessed with URLs http://www.facebook.com/WebSpherePortalSupport and the Twitter handle @PortalSupport can be accessed through URL http://www.twitter.com/PortalSupport
Adopting social media as a means for customer support, some industries may find an easier fit because of their business models, for example tourism, real estate, airlines, retail stores, etc. In a recent report about the social media adoption in airline industry, the number of social conversations (through Twitter) is about the same as those through the traditional voice calls. More and more companies realized that the support through social channels can be a differentiation for competitive advantage, and it can be made real-time, and it is very effective to reduce customer frustration, increase satisfaction, and eventually help sales. Although the resolution may not always be conclusively positive, the consumers are pleased with the acknowledgement on social channel and the effort by the airline support personnels.
For service and support of IT companies, such as IBM, it is a challenge to figure out what can be done for customers in the social space. Due to the complexity of the technical problems in a lot of customer cases, often it’s impractical to resolve technical issues through social media, for example, Twitter communication, due to limited information and data exchanged. WebSphere Portal is a very complicated product set. For example, you may not even be able to describe the problem with 140 characters of a Twitter message. Apparently, social media is not suitable for solving such complicated problems.
We are still hopeful that social media can play important role in customer support. We can take advantage of the social tools to explore the following areas and adapt in the new territories along the way:
It has been speculated how we know that our customers are on social media and are willing to communicate through social channels. Our answer is, if we are not getting on social media, like Twitter or Facebook, we may never know the answer. Only when we put ourselves into this space, may we be able to find out. Social media is the first choice to many. We don’t intend to have it to replace any traditional tools. We provide such a service and intend to use it for those customers who are active in social space. If you are not comfortable, you are still welcome to use traditional ways to contact support.
Some reports have found out that the young people between age 14 - 32, more than 75% of them make first attempts to find answers through various online tools, including social media, not the traditional support channels.
Here I would encourage customers who are active on Facebook and Twitter to sign up and voice your concerns and opinions. Follow us on Twitter (@PortalSupport), and like our Facebook page (http://facebook.com/WebSpherePortalSupport). We can also add other social tools in future, as long as there is demand and audience. Let’s enjoy a healthy dialogue and effective conversation on Facebook and Twitter. You will also hear us more about our social commitment through other support channels.
Social Media Customer Service Lessons from the Airline Industryhttp://www.radian6.com/blog/2012/04/social-media-customer-service-lessons-from-the-airline-industry/
How to Tackle Real-Life Social Media Customer Service Obstacles
mowusua 270000PTV9 1,492 Visits
So a usually fully functional search component gets into a conditions where it doesnot return any results at all. Seemingly it does not even see the collection
Excerpts of log entries below[4/28/12 2:55:13:208 BRT] 000000eb SecurityManag E com.ibm.hrl.portlets.WsPse.SecurityManager checkAccess EJPJO0030E: Missing location for collection
[4/28/12 2:55:13:209 BRT] 000000eb SearchSession E com.ibm.workplace.wcm.services.siapi.SearchSession setSearchCollection com.ibm.siapi.SiapiException: Message0:
SEVERITY_ERROR: Message ID: [SIAPI0009E] Resource Bundle: [com.ibm.siapi.SiapiResources] Message Text:  Message Arguments: Arg0:String: [null]
at com.ibm.hrl.wp.siapi.pseAdapter.util.PSEutil.verifyCollectionSecurityAccess(Unknown Source)
at com.ibm.hrl.wp.siapi.pseAdapter.search.SearchAdapterImp.verifyCollectionAccess(Unknown Source)
at com.ibm.hrl.wp.siapi.generic.search.SearchableImp.<init>(Unknown Source)
at com.ibm.hrl.wp.siapi.generic.search.SearchServiceImp.getSearchable(Unknown Source)
[4/28/12 2:55:13:215 BRT] 000000eb SearchCmpnt E com.aptrix.pluto.cmpnt.SearchCmpnt: resolve
com.ibm.workplace.wcm.services.siapi.SearchException: Message: com.ibm.siapi.SiapiException: Message0: SEVERITY_ERROR: Message ID: [SIAPI0009E] Resource Bundle: [com.ibm.siapi.SiapiResources] Message
Text:  Message Arguments: Arg0: String: [null], Cause:
com.ibm.siapi.SiapiException: Message0: SEVERITY_ERROR: Message ID:
[SIAPI0009E] Resource Bundle: [com.ibm.siapi.SiapiResources] Message
Text:  Message Arguments: Arg0: String: [null]
To resolve1. Confirm the component has the correct collection assigned
"go to authoring ui - component - search component. With the search component opened, you should see the collection that it is associated
2. There is a known issue where the access permissions to tthe collections are compromised and essentially disappears. You can fix the access issues via the following below and ensure the appropriate users have the right access
Access > Resource Permissions > PSE Sources > <collection> > Assign Access
3. This apar documents this issues and should presumeably avoid the condition in the future
PM36559: PORTAL SEARCH COLLECTIONS DISAPPEAR FROM WCM COMPONENT BECAUSE THEY LOSE THEIR UNIQUE NAME
4.You can delete and recreate the collection to reset the collection and permissions.
Overview of LDAP caches in Portal
WebSphere Portal 6.1 and 7.0 both 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
By default the PUMA caches are set to 10 minutes, and the VMM caches are set to 20 minutes. Both settings are configurable, and the defaults generally allow a good mix of performance during peak busy periods and will expire the caches during non-busy periods so as not to use up too much server memory. 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 from the defaults of 10 minutes for PUMA, and 20 minutes for VMM to a lower value. The following Technote discusses this strategy in more detail:
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.
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:
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"
supportPaging="false" supportSorting="false" supportTransactions="false" certificateFilter=""
certificateMapMode="EXACT_DN" ldapServerType="IDS" translateRDN="false">
<config:baseEntries name="o=ibm,c=us" nameInRepository="o=ibm,c=us"/>
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:
4) Create a new custom property:
Name: store.puma_default.wim.cacheinvalidation.repositoryidsValue: PORTSELDAP
*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.*"%>
final String BR = "<br><br>";
out.print("Starting to gathering info"); out.print(BR);
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();
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);
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("<br>");
out.print("Done Reloading. Updated User Attributes for user " + pumaProfile.getAttributes((User)userList.get(i), myList)); out.print(BR);
out.print("Exception occurred!!! " + e); out.print(BR);
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:
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
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.
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".
Since we moved to our cumulative fix strategy, we've received several PMRs where our users install one cumulative fix, uninstall it, then reinstall a different cumulative fix. More often than not, the user hits this failure:
"Profile version is not as same as portal binary version before updating portal binary: wp_profile, update aborts!"
This happens because of a commonly overlooked step during a cumulative fix uninstall. During installation, the Portal binaries and profile are updated at the same time. Or rather, the Portal Update Installer (PUI) applies the cumulative fix to the Portal binaries and runs a ConfigEngine script to update the profile for you automatically.
During uninstallation though, that is not the case. PUI uninstalls the cumulative fix from the binaries, but it does NOT uninstall the CF from the profile! That is where the failure comes from....
A second step is needed to uninstall the CF from the profile. From the CF readme (7001 for example):
c. Run the following command:==============================
If you uninstall a CF yourself, make sure you don't skip that step!
WebSphere Portal customers should be aware of the following technote: http://www.ibm.com/support/docview.wss?uid=swg21579757
From the technote:
The WebSphere Plugin comes with a plugin-key.kdb file upon installation, and contains a personal certificate that is set to expire by April 26, 2012. The keyfile itself also has a password "WebAS" that is set to expire by April 26, 2012. Action may be required to maintain encryption between the plugin and application server(s). This affects WebSphere Application Server V6.1, 7.0 and 8.0.
Refer to the Flash technotes from the WebSphere Application Server support team to determine if you are affected and what steps may be needed to correct this situation (direct links):
Need a collection of performance resources documentations at your finger tips. Check out this tech note. It should get you started on your basic performance tuning /troubleshooting activities
Knowledge Collection: IBM WebSphere Portal Performance http://www-01.ibm.com/support/docview.wss?uid=swg21590163
Ordinarily at server startup portal server plays back recovery logs and attempts to reconcile transactions activity information before the prior shutdown.If , for whatever reason, the server was brought down abruptly, an existing or in route transactions may not have either completed successfully or completely rolled back. The net effect is transactions are left in in detreminate state and may prevent full functionality of the server. While not necessarily the only sign of such problem the following stack is typical..
XARminst E WTRN0037W: The
transaction service encountered an error on an xa_recover operation. The
resource was com.ibm.ws.rsadapter.spi.WSRdbXaResourceImpl@21c121c1. The
error code was XAER_RMERR. The exception stack trace follows:
at com.ibm.ws.rsadapter.spi.WSRdbXaResourceImpl.recover(WSRdbXaResourceImpl.java:1086)at com.ibm.ws.tx.jta.RecoveryManager.performResync(RecoveryManager.java:114)
To resolve you may need to completely delete the problem transactions. Here is the sample process
Remove the contents of the /tranlog and /partnerlog subdirectories which
are located under the <profile_name>\tranlog\cell_name\node_name\server_name\transaction . Occasionally you may need to go as far as removing all the contents(including contained directories
After that restart server and server should ordinarily startup without any problems
Needless to say the ideal scenario is a graceful shutdown