Retreiving web-dav content for theme in websphere portal8

Webdav :- Is the place where we store the static content related to portal theme. Different tools are used to connect to it via Anyclient,bitkonex etc. actual stored location of these files will be in JCR db.

Exporting content from the filestore is required in different scenarios, however with different files to be
exported. See the concrete scenario description for the detailed list of files to export.
You can access the filestore by using the following URL:-
http://<server>:<port>/wps/mycontenthandler/dav/fs-type1/

Use one of the following options to export the files stored there:-
Get a compressed file using your browser
You can obtain a compressed file of the content in the filestore using your browser. Enter the following
url in your browser:
http://<server>:<port>/wps/mycontenthandler/dav/fs-type1/<folder-name>/?mime-type=application/zip
Where:
1. The <server> value is the host name of the portal.
2. The <port> value is the port number for WebSphere Portal.
3. The <folder-name> value is the folder to be compressed. This value is optional.
Note: A / must follow the folder name.
The URL triggers a download of a compressed file. If you are prompted for a user and password enter
the admin user ID and password for WebSphere Portal. Store the file on the local file system.

This following url downloads the complete content of the filestore:-
http://<server>:<port>/wps/mycontenthandler/dav/fs-type1/<folder-name>/?mime-type=application/zip
The following url downloads the content of the themes folder:-
http://<server>:<port>/wps/mycontenthandler/dav/fs-type1/themes/?mime-type=application/zip

Use a WebDav Client to connect to the filestore using the following url:-
http://<server>:<port>/wps/mycontenthandler/dav/fs-type1/
Browse to the folder you need and copy the files to your local drive.

Portal8.0 tunning

Architecture :- Always try to have a combination of vertical and horizontal clustering for high performance.

Jvm  minimum and maximum size:- 3048MB

Jvm nursery memory  :- 1024MB

Session timeout: - 30 mins(Lowest the best)

Data source connection pooling: - Minimum 10 and maximum 50.

Avoid Refetching Static Content After Login

With the Portal 8.0 theme many resources do not change before and after logging in. These resources include the ra: collection URLs that are part of the theme. The same URL can safely be used for authenticated and unauthenticated users.

How to Set

1. In the WebSphere Integrated Solutions Console: Security → Global security

2. Expand Web and SIP security

3. Click on General Settings

4. Check 'Use available authentication data when an unprotected URI is accessed'

5. Save

VMM Caches

Tune VMM search results and attributes cache to improve the performance of VMM search.

How to Set in ISC

1. In the WebSphere Integrated Solutions Console Security → Global security

2. Under Available realm definitions ensure Federated Repositories is selected

3. Click the Configure button

4. Click on the LDAP Repository Identifier

5. Click Performance under Additional Properties

How to Set Manually

Edit <wp_profile_root>/config/cells/<cellname>/wim/config/wimconfig.xml.

Change the searchResultsCache settings to match the following:

<config:searchResultsCache cacheSize="12000" cacheTimeOut="600" enabled="true" searchResultSizeLimit="1000"/>

Change the attributesCache settings to match the following

<config:attributesCache attributeSizeLimit="2000" cacheSize="12000" cacheTimeOut="1200" enabled="true"/>

Internationalization Service Tuning

An internationalized (i18n) application can be configured to interact with users from different regions in culturally appropriate ways. The internationalization service enables you to configure and manage an internationalization context for an application.

This feature is needed by the WebSphere i18n classes. If your application code is not using the following classes, it is safe to disable this service.

 com.ibm.websphere.i18n.context.UserInternationalization

 com.ibm.websphere.i18n.context.Internationalization

 com.ibm.websphere.i18n.context.InvocationInternationalization

Note that Portal does not make use of these classes internally.

How to Set

In the WebSphere Integrated Solutions Console

Servers → Server Types → WebSphere application servers → WebSphere_Portal → Container Services: Internationalization service

Uncheck “Enable service at server startup”.

Disable Tagging and Rating

If you are not using the Tagging and Rating services they can be disabled. In our results, disabling this improved capacity by 3%.

How to Set

In the WebSphere Integrated Solutions Console

Resources → Resource Environment → Resource Environment Providers → WP CPConfigurationService → Custom properties

Modify the following custom properties:

 Name: com.ibm.wps.cp.tagging.isTaggingEnabled Value: false

 Name: com.ibm.wps.cp.rating.isRatingEnabled Value: false

Base Portal Tuning

WebSphere Portal 8.0 Performance Tuning Guide 25

The module can also be removed from the theme profile. The module name is wp_tagging_rating; by default it is in the deferred section of profile_deferred.json. For performance benchmarks, this module was left enabled, but the deferred section of the profile was never loaded as part of the measured workload, so the performance impact of removing it is unknown.

Mashup Multipart Tuning

The Portal 8.0 theme multipart downloading can be disabled to improve performance. Be aware that disabling this may cause performance issues on client side aggregation themes from earlier Portal releases.

How to Set

In the WebSphere Integrated Solutions Console

Resources → Resource Environment → Resource Environment Providers → WP CommonComponentConfigService → Custom properties

Modify the following custom properties:

 Name: cc.multipart.enabled Value: false (the default)

 Name: cc.multipart.correlatehosts Value: false

Cache ra:collections

To allow caching of ra:collection URLs, set resourceaggregation.cache.markup to true in WP ConfigService.

How to Set

In the WebSphere Integrated Solutions Console

Resources → Resource Environment → Resource Environment Providers → WP ConfigService

Name: resourceaggregation.cache.markup

Value: true

Disable Portlet Capability Filter

The runtime portlet capabilities filter allows a portal developer to get friendly error messages on pages if the theme profile that is in place for a page does not contain all the capabilities that the portlets on the page require. This is very useful for development purposes, but has an undesirable overhead in a production environment. In production this filter should be disabled as the pages should be properly debugged before going into production.

More information about these settings can be found at http://www-10.lotus.com/ldd/portalwiki.nsf/dx/Capability_Filters_wp8 and http://www-10.lotus.com/ldd/portalwiki.nsf/dx/Configuration_settings_for_capability_filters_wp8

To disable, set resourceaggregation.enableRuntimePortletCapabilitiesFilter to false in WP ConfigService.

How to Set

In the WebSphere Integrated Solutions Console

Resources → Resource Environment → Resource Environment Providers → WP ConfigService → Custom properties

Name: resourceaggregation.enableRuntimePortletCapabilitiesFilter

Value: false

Note:- Will be updating this blog post weekly look for more updates

Custom Impersonation portlet websphere portal

Using Impersonation based on Groups

Problem statement:

            A given user should be able to impersonate users belonging to a particular group while he must not be able to do the same for another group. For this we have IBM portlet available but there are limitations like searching via firstname etc . We have a requirement Group A admins should be able to impersonate users belonging to normal users while they should not be able to do the same for privileged users.So we want to use custom portlet to add any custom implementations.

Scenario:

            Admins – Group of admins

            PrivilegedUsers – Group of privileged users

            NormalUsers – Group of normal users

            

Steps:

Step 1:To enable the impersonation feature, run the enable-impersonation task from the wp_profile_root/ConfigEngine directory.

ConfigEngine.bat enable-impersonation -DWasPassword=password -DPortalAdminPwd=password -DCategoriesList=wp.auth.base

Step 2:            Log on to WebSphere Portal as an administrator. 

Click Administration >Users and Groups > All Portal User Groups > New Group

Create three groups Admins, Privileged Users and Normal Users

Step 3: Log on to WebSphere Portal as an administrator.

Click Administration >Users and Groups > All Portal User Groups > New User

Create three users admin, puser, nuser

Step 4: Now we have created the required users and groups. Now we have to add the users to     groups.

Log on to WebSphere Portal as an administrator. 

Click Administration >Users and Groups > All Portal User Groups > Admins/Privileged Users/Normal Users > Add Member.

Add admin à Admins group, puser à Privileged Users and nuser à Normal Users group.

Step 5: Now we need to create a new page.

            Log on to WebSphere Portal as an administrator.  Click Administration à Manage Pages à Content Root à New Page

            Create a portlet and add it to the page you just created.

Step 6: For doing impersonation we need ImpersonationService object and for identifying the group of a particular user we need PUMA service object.

Declare the following variables inside the portlet.

privatestatic PortletServiceHome pshImpersonate = null;

privatestatic PortletServiceHome psh = null;

privatestatic PumaHome pumaHome = null;

privatestatic ArrayList<String>GROUP_ATTRS = null;

privatestatic ImpersonationService impersonationService = null;

Add the following code inside method to get the service objects.

try{

Context ctx = new InitialContext();

   //gets the impersonation service object

pshImpersonate = (PortletServiceHome) ctx.lookup(ImpersonationService.JNDI_NAME);

impersonationService = (ImpersonationService) pshImpersonate.getPortletService(ImpersonationService.class);

   //gets the puma service object

   psh = (PortletServiceHome) ctx.lookup(PumaHome.JNDI_NAME);

pumaHome = (PumaHome) psh.getPortletService(PumaHome.class);

                                   

GROUP_ATTRS = new ArrayList<String>(1);

GROUP_ATTRS.add("cn");

                       

} 

catch (NamingException e) {

   e.printStackTrace();

}

Step 7: Add the following code the processAction to determine the group of a given user and determine whether to allow impersonation or not.

try{

   String userId = request.getParameter("userId").trim();

           

   PumaLocator pumaLocator = pumaHome.getLocator(request);

   PumaProfile pumaProfile = pumaHome.getProfile(request);

   //gets the user using the user id                               

List<User> users = pumaLocator.findUsersByAttribute("uid", userId);

                                   

   User user = users.get(0);

                                   

if(user != null) {

           

List<Group> groups = pumaLocator.findGroupsByPrincipal(user, false);

                       

            for (Iterator<Group> iter = groups.iterator(); iter.hasNext();) {

Group group = (Group) iter.next();

Map<String, Object> attributeMap  = pumaProfile.getAttributes(group, GROUP_ATTRS);

String groupName = (String) attributeMap.get("cn");

               //allow impersonation if the user is a normal user

if("NormalUsers".equals(groupName)) {

impersonationService.doImpersonate(request, response, users.get(0));

}

elseif("PrivilegedUsers".equals(groupName)) {

            //do not allow impersonation if the user is a privileged user

request.getPortletSession().setAttribute("message", "Sorry, you do not have permissions to impersonate.");

}

}  

}

} catch (Exception e) {

e.printStackTrace();

}

Step 8 : Add the following markup to the view jsp of the portlet.

<%String message = (String) renderRequest.getPortletSession().getAttribute("message");

            %>

            <%if(message != null) {%>

                        <span><%=message%></span><br/>

            <%}

%>

<ahref='<portlet:actionURL>

                                    <portlet:paramname="userId"value="puser"/>

                        </portlet:actionURL>'>Privileged User</a>

<ahref='<portlet:actionURL>

                                    <portlet:paramname="userId"value="nuser"/>

                        </portlet:actionURL>'>Normal User</a>

<%renderRequest.getPortletSession().setAttribute("message", null);%>

Step 9:Finally to allow the users of group admin to have impersonation privileges do the following:

Complete the following steps to assign the Can Run As User role to the appropriate user:

1. Log on to WebSphere Portal as an administrator.
2. Click Administration.
3. Click Access > User and Group Permissions.
4. Click Users.
5. Search for the user(user under Admins Group) you want to assign as Can Run As User.
6. Click the Select Resource Type icon for the required user.
7. Navigate to the page that contains the Virtual Resources option, using the Page Next button and click that link.
8. Navigate to the page that contains the USERS option and click the Assign Access icon.
9. Select the Explicitly Assign check box for the Can Run As User role.
10. Click OK.
11. Verify that the required user now has User and Can Run As User access.

Choosing websphere portal server architecture

IT-Architecture:- The word signifies aligning databases, services,application servers,web servers, cache,JVM memory etc  such that it will be scallable for high user loads with high performance or throughput .

Different possible architectures in web-sphere portal :-
1) Single server topology
2) Stand-alone server topology
3) Cluster server topology(Vertical and Horizontal clusters)
4) Portal farm topology
5) Multiple clusters

1) Single server topology :- Websphere portal,Websphere application server,Database all are installed on same server. This environment would be better for test,development and poc concepts or as a small production system. If requirement is for multiple user's need to look for clustered environment.

2) Stand-alone server topology :- In this type of topology ldap,web-server,database,portal server are installed are installed on individual physical machines . Where as in single server toplogy all are installed on same machine.

3) Cluster server topology:-  Cluster the word itself says it is a group of servers. In cluster environment we will be having deployment manager under which all clusters will be handled. consider there are 5 clusters all these will be having same deployment manager. Any installation,deployment of war,configuration change need to be done on deployment manager. The changes will be synced to all underlying clusters where one cluster will be acting as deployment manager. For remaining all clusters the was consoles wont be available but portal admin consoles will be available.

Types of clusters:-

3A) Vertical cluster :- Vertical cluster will be having multiple portal servers installed on same physical machine. limitation of number of servers will depend on physical resources available in the machine. A node can contain multiple portal servers and cell can contain many nodes and the managed cell will be controlled by deployment manager. The disadvantage of vertical cluster will be if physical system fails everything will be down.

3B) Horizontal cluster :- The only difference will be nodes will be installed on different physical systems.Below we can observe combination of horizontal and vertical clusters. Where each node is on different physical system and each node has portal servers installed in vertical cluster model.

4) Portal farm :- Here multiple instances of WebSphere portal is installed on same machine. Like clustered environment portal farm wont-be having any deployment manager to manage installation,configuration etc. It should be done manually on each portal server.

5) Multiple clusters :- By having multiple clusters you can bring down one cluster and perform up-gradation while other cluster is serving users. By this way we can have 100% availability of system. Multiple clusters can be different cell or it can be same cell as mentioned below.

Multiple Cell

Single Cell

WCM Cache instances used in Web content manager

WCM Cache Instances
With WebSphere Portal 8.0, the WCM caches are managed via the WebSphere Application Server administrative console under
Resources > Cache instances > Object cache instances.

WCM Item Caching
services/cache/iwk/strategy
Default size: 2000, default lifetime: infinite, usage pattern: regular.
This cache stores internal WCM items. Any WCM item read from the database will first check this cache. WCM items cover Content, Workflow, Workflow Stages, Workflow actions, Taxonomies, Categories, Authoring Templates, Presentation Templates, Sites, Siteareas, and all Library Components. The cache entry will be updated or cleared when its corresponding WCM Item is updated or deleted.

WCM Summary
services/cache/iwk/summary – WCM summaries
Default size: 2000, default lifetime: infinite, usage pattern: regular.
This cache stores summaries of WCM Items. The summaries are used to display in lists in the authoring portlet or used internally in the WCM API to calculate WCM Item Document IDs used for Iterators. The cache entry will be cleared when a WCM Item is updated that will affect this summary.

WCM Basic Caching
services/cache/iwk/module
Default size: 2000, default lifetime: infinite, usage pattern: regular.
This cache is used for WCM Basic caching. See the InfoCenter on setting up Basic caching. The Basic cache stores the entire response. The key is based on the URL only, so all users will see the same response.

WCM Advanced & Resources cache
services/cache/iwk/processing
Default size: 2000, default lifetime: 1 month (configurable), usage pattern: regular.
This cache stores the binary MIME for file and image resources in WCM. The maximum size of resources to store is set in the WCMConfigService.properties file as the property resourceserver.maxCacheObjectSize (in kb). Resources over this size are not cached and are streamed directly to the response. The expiry is set in the same file as: resourceserver.cacheExpiryDate. The cache entry will be cleared when that resource is updated.
This cache also stores page data if WCM Advanced caching is enabled. See the InfoCenter for enabling WCM Advanced caching. The processing cache stores advanced caches for the following types:
 Site: Similar to “Basic” Caching except that “Connect Tags” are processed each time.
 User: Stores a copy of an item in the cache for each user
 Secured: Users that belong to the same groups will access the same cached items
 Personalized: Users who have selected the same personalization categories and keywords, and who belong to the same Group, will access the same cached items
Note that the ‘session’ option for Advanced caching is not stored in the processing cache, but the ‘session’ cache.

Session Cache
services/cache/iwk/session
Default size: 2000, default lifetime: infinite, usage pattern: regular.
This cache stores the page data for when session advanced caching is enabled. See the InfoCenter for enabling WCM Advanced caching.

Menu
services/cache/iwk/menu
Default size: 2000, default lifetime: infinite, usage pattern: regular.
This cache stores WCM Menu entries. An entry comprises of the Content IDs associated with a particular menu. The entries are retrieved and cached without applying security. Whenever a user needs that menu’s results, their specific security will then be applied to the cached results. A dynamic menu, which is one that is affected by the current user’s context (e.g. based on categories in a user’s profile) will store a separate cache entry for each different context. The cache entry will be cleared when a WCM Item is updated that will affect this menu.


Navigator
services/cache/iwk/nav
Default size: 2000, default lifetime: infinite, usage pattern: regular.
This cache stores parent to child relationships that comprise a WCM navigator. A complex navigator might have multiple parent to child relationships (e.g. if siblings are included). The navigator entry is made up of the IDs of the parent and children. This cache will be cleared upon any WCM Item update in the system.

Absolute Path
services/cache/iwk/abspath
See description below.
services/cache/iwk/abspathreverse
Default size: 5000, default lifetime: infinite, usage pattern: regular.
These two caches store JCR path to WCM item ID relationships (one cache is used for Path-to-ID relationships and the other for ID-to-Path relationships). The cache entry will be cleared when a WCM Item is updated that will affect it. Typically these two caches should be configured to have the same size.

Missed Items
services/cache/iwk/missed
Default size: 5000, default lifetime: infinite, usage pattern: regular.
This cache stores JCR paths that do not exist. This is used primarily for multi-locale solutions to determine if items of other locales exist or not. The cache entry will be cleared when a WCM Item is updated that will affect it.

Library
services/cache/iwk/global
Default size: 2000, default lifetime: infinite, usage pattern: regular.
This cache contains a lookup for library id, name and path to the library object. This is pre-populated up to the cache size at Portal startup.xmlformat

Library Parent
services/cache/iwk/libparent
Default size: 2000, default lifetime: infinite, usage pattern: regular.
Web Content Management Caches
158 WebSphere Portal 8.0 Performance Tuning Guide
This cache stores a list of all children library ids to a given parent id. This was introduced for Quickr to group libraries within a teamspace.
WCI Object IDs

WCM Ojects 
wci/wcmobjectids
Default size: 2000, default lifetime: infinite, usage pattern: regular.
The WCI object ids cache does not have a significant effect on performance. It is used internally by the WCI consumer to ensure that concurrent distributed feed consumers do not cause inconsistencies.

VMM High level view websphere portal

VMM:- Is virtual member managment everyone says about it what is it actually? For any user to login he need to register first those details will be stored in a database(LDAP or XYZ). Now we need some way to retrieve this information what user register later when user login in for business purpose. For this ibm has provide a way to write adapaters and connect to our required repository and get the information in a xml format such that websphere portal understands it(UserRegistery.xml). This all process happens in VMM. Portal connects to VMM via Puma api and retrieve the required information. Below picture explains the flow.