*** 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 220.127.116.11, 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:
<portlet action="locate" name="Manage Seed List" objectid="<Manage_Seed_List_objectID"></portlet>
<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.
I would like to take a high level overview of the various programming entry points that WebSphere Portal provides to allow you access into the internals of the Portal to both make changes as well as request information about various aspects of the Portal.
The first thing to understand is that you will almost always have to get a home object which represents the starting point for interactions in that package. Such that if you wanted information on access control you would use a JNDI lookup to retrieve AccessControlHome, or for PumaHome if you want to get information on the Portal User interface. Once you have the Home you will need to get either the Model or the Provider object depending on the needs of the code. Next we will look at the most common packages and their uses.
This package will contain information regarding access control information on various resources. You can check the ACL data on any item that supports the Identifiable interface(which is most everything in portal). So this would include Pages, Portlets, Containers, whatever you might have. you can pass in and either get the entire role data set or check to see if certain users have a specific permission, or if the current user has a specific permission. You could use this to customize visible data in your portlets, and on your pages depending on what was needed for the environment.
This next package is useful for customizing the Portal login/logout mechanism. These will only be triggered when you try to access a Portal protected resources. This replaces the customization that used to be made in the LoginUserAuth classes by now adding them to the Portal login filter chain. One thing to be aware of is the difference between implicit and explicit login/logout. The Implicit login is where a user us already authenticated to WebSphere AppServer but then attempts to reach a portal resource. They will then go through the Portal implicit login chain.
This package has many providers that will see some of the most use out of the other ones. With this package you can retrieve a list of languages the Portal supports, the markup that the Portal supports, information about the navigation, content, navigation selection, portlets, themes, skins and helpers to localize resources when presenting them to users. All of these models will be read only while the subpackage com.ibm.portal.model.controller will give you write access to all of these. All of these will be scoped to the user making the request. With the controller package you can create pages, add portlets to the page and remove them, set skins on the page, alter properties about all of these including ordinality. A developerworks article is in the plan for this from support to show examples of the most common questions using the controller SPI
The providers in this package will allow you to traverse the tree for navigation of the current user. they can be useful in creating breadcrumbs and creating your own custom navigation portlets. These along with the com.ibm.portal.state package can be used to create links to do a grand variety of actions within portal. Please see Advanced URL helpers for a detailed sample on using the state package to create links to various Portal resources.
com.ibm.portal.portlet and com.ibm.portal.portletmodel
These two packages provide a lot of information concerning the various layers of portlets they can be used to make changes to the portlet configuration and also can retrieve preferences layers for review.
Also known as PUMA this is the usermanagment part of the SPI, with it you can do user management, and queries. For more on PUMA please see PUMA whitepaper
This covers the majority of the SPIs that customers use, and can do 90% of what you need to do in your custom Portal environment for management and administration.
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.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]
There has been a recent documentation change on how to filter search results based on Authoring templates
Prior documentation had indicated using the + character when specifying the authoring template within the scope document
It should be ^ character instead . So specifying search results on authoring template TEMP-Article will be accurately represented as follows
New to Websphere Portal Performance? Need to better review and understand all aspects of a javacore? Want to have meaningful discussions with L2 support on performance issues based on javacore and data collected?
IBM Research has created a new tool to enable you to review , troubleshoot and analyze performance issues regardless of expertise.
IBM Whole-system Analysis of Idle Time (WAIT) is a lightweight and powerful tool that can be used in almost any Portal or other Java environment. The tool is graphical and can be used by anyone, newbies and experts alike. You can determine the source of performance issueS, easily review call stacks and determine who wrote any piece of code in a portal call stack(WebSphere , Portal , WCM other IBM product or other third party entities)
There is an upcoming demo and discussion of the WAIT tool for Websphere Portal Customers on November 10, 2011
See the following document for more information on the event .
Customer Open Mic: The WAIT tool - Portal Performance Diagnosis and Beyond http://www-01.ibm.com/support/docview.wss?uid=swg27023208
You can review the tool at the following locations
Sneak previews here: http://snappy.watson.ibm.com/wait
External Site http://wait.researchlabs.ibm.com
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:
- z/OS: <wp_profile_root>/PortalServer/bin/UpdateProfile.sh uninstall CF skipPreCheckProfile
- All other platforms: To downgrade a profile after an
uninstall, the following command can be used to downgrade all profiles
(including the primary profiles). See the following link for multiple
profiles Supporting multiple profiles: wp7.
<wp_profile_root>/PortalServer/bin/UpdateProfile.bat|.sh uninstall CF
If you uninstall a CF yourself, make sure you don't skip that step!
As we had planned, the second WebSphere Portal version 8 Installation Twitter chat was held at 1 PM ET. Like last week, the participation is not ideal. We will not have another session. The end of this chat session also the end of our first social workshop. Although we didn't see a lot of direct interactions between support and customers, we have a collection of documents and knowledge left for future references. We also gained experience on how to organize such events. In future, we may ask the suggestions and opinions of our customers. You can also read a request for a potential future session on Portal migration.
Here is a summary of today's chat session from Storify.com
The statistics of today's session can be seen in the following report from Hashtracking.com
Many thanks to following people from WebSphere Portal Level 2 support:
Hunter Tweed, Vasantha Alle, Michael Watkin, David Betres, Tony Donato, Jerry Dancy, Travis Cornwell, and Chris Clarke.
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:
- Pushing the latest and greatest updates of the products, and driving the content awareness and sharing: There is a fundamental difference between the traditional RSS feeds and the new social tools, such as Twitter. That is, a dialogue can be initiated in real-time on social channel, but the traditional RSS is normally one-way street, i.e. the information only flows from support to customers. On social media, like Twitter, a question and answer (Q&A) session can be immediately started after a technote is made public, for example, if a customer has a question, or comment, or request. Social space is a much more dynamic environment, support engineers and customers can have a lot of interactions while enjoying the close dialogues.
- Promoting best practices with coaching, mentoring, and learning: In support, we have seen numerous problems which can be easily avoided if the best practices are known to customers. Some human errors can be reduced or prevented. Often the education is mutual, not only support engineers can share their knowledge, but customers can also feedback their experiences and discoveries. Many studies have proved that social media is a deciding drives of readership of online blogs and the increase before and after introducing social media is multi-folds. Based on studies like this, if we consider the support materials as blog-like content, there is no doubt that social media will play the same role as a readership driver.
- Organizing online discussions: it has been proven that online discussions and open mics are effective ways of communicating and exchanging technical information with, transferring knowledge to, and receiving feedback from clients, all at the same time. Twitter chat should not be a stranger to people who are familiar with and active on Twitter. We also often see that Twitter chats can be arranged with on-going conferences to broadcast live information such that people worldwide can get the live presentation even they are not present at the conference floor. Google hangout is a similar tool that can allow live video stream as well. Such kind of online discussions often are centralized with a single topic and multiple questions asked. People who join the chat or hangout can freely express their views and opinions. This format of communication is suitable for political gathering and technical discussions.
- Spontaneous comments, feedback, and Q&As: Sometimes we have questions and need to consult someone for a quick and short discussion. Some of these questions may be very simple, and can be answered in a few minutes, or may be directed to an online resource, such as a technote, or a blog, or a quick fix. Under such circumstances, do we really have to go through complicated support procedure to open a support ticket? The tools like Twitter would be an excellent fit. Also social media can play important roles as a suggestion or feedback box, , or a “contact support” channel. Research reveals that 46% of customers want to solve a problem when they're engaging with a brand on social media, and 39% are looking to give feedback about a product or service.
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 Industry http://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
Many folks are getting started looking at getting certified for WebSphere Portal v7.0. In this first part we will take a look at the test, its makeup, information on it and how to prepare.
First thing to know is that this test is more difficult than the previous versions of the tests. The questions are much more specific and will cover a wider array of topics given all the new v7 functionality.
Taking a look at the test there will be 60 questions, in which you have 75 minutes to answer them. You must get 67% right to pass the certification. Those questions will be compromised of the following areas.
|Architecting a Portal solution
|Installation, Setup, and Configuration
|Additional Development Concepts
|Portal Frameworks & Portlet Services
|Testing, Debugging, Performance Monitoring
There will also be 2 unscored questions.
From the chart above we can see that the test is broken up into 7 core areas with some areas getting more focus that others. For this test you will want to understand the themes and skins of Portal 7.0, the APIs for both portlet specs, as well as the additional portlet services and frameworks that are provided. This covers a very broad range of topics so plan to spend a significant amount of time on each of the major sections.
To start off with your main areas of study will be the following:
Most of the questions will be from these three documents, after careful study you will most likely remember the items that you had read while studying, but be careful to read the whole question as often a key word is changed to make the test challenging.
You can find more about the test here
. There you can find links to additional test information as well as link to a sample test. It would be a good idea to go through the sample test at least once to get yourself prepared for the test.
In future installments we will delve into the specific sections with more study pointers on each section.
Here it is, the new white paper showing how to clone an installation of IBM WebSphere Portal version 7.0 that has been configured for specific deployment needs:
I have been testing the document myself and have come up with a number of observations:
1. The steps have been vastly simplified since the Portal 6.1.x instructions came out. Also there have been some improvements which allow for more flexibility if the new node is on the same LAN, unlike previous versions.
2. These steps are only usable if your OS to OS is comparable -- i.e. Windows 32-bit to Windows 32-bit, or RHEL 32 bit to RHEL 32 bit, etc.
3. Certain 64 bit OS versions will not support the GUI. My first attempt was with RHEL 64 bit in which the exceedingly more complicated ifcli.sh|bat must be run instead of the ifgui.sh|bat which is much simpler to use. At the very least I would suggest that one's initial test should be using the GUI version shown in the white paper.
4. I'm still playing around with but I have noticed that on certain target systems there have been some apparent port conflict problems. I'm still working on what may have caused this as it's not very clear how this occurred.