Build and deployment
of all portal artifacts can be automated using scripts, but recently we had
small issue with automation of personalization rule that uses dynamic attribute
(request) . I couldn't find sample xml (/PortalServer/doc/xml-samples/) or .nodes
file to automate the creation of dynamic attribute (And also there no option to
export from PZN Editor portlet) .

I couldn't find
anything related to this on the infocenter also so thought post this here and
this can be help if anybody looking on same lines.

To
create the dynamic attribute manually

select specific application
object and click on manage properties

Enter the name of the dynamic
attribute and select type.

you can select the dynamic
attribute once it is created, but here there is no option to export/import
this dynamic attribute.

To
create the dynamic attribute using xml (.nodes)

After doing some
research, was able to create below xml(saved it as .nodes
file) that allowed me to create/import the dynamic attribute.

By
default, WebSphere® Portal does not permit shared caching for
authenticated pages. You can use the Properties portlet or the XML
configuration interface to override these default settings using
the com.ibm.portal.IgnoreAccessControlInCaches parameter, but in most
cases this is not recommended.

Portlet
level

Portlet Definition

Possible
settings at portlet definition level are

remote-cache-scope
(SHARED/NON_SHARED)

EXPIRATION_CACHE
(-1(never))

remote-cache-dynamic
(true/false) :

NOTE:
The remote cache dynamic setting is an optimization to notify the container
whether a portlet window can publish remote cache information at render time.

A proxy server caches content and serves requests for the content.
Not good for customized content. The following default values exist for portlet
definitions and themes if nothing is provided:

Note: This type of
caching should be used only for pages that contain public content that is not
personalized.

Remote cache scope
is non-shared

Remote cache expiry is 0
seconds

Non-shared
cache for a single user (Web browser cache):

The cache is typically located in each user's Web browser. Can be
used for personalized content also . But if the computer is shared among
multiple users, a user may see personalized content from other users if served
from the browser cache. To prevent this from happening, do not enable private
caching, even for personalize content.

Globabl
Settings (In WP Navigator service)

public.session

public.expires

remote.cache.expiration

remoteCacheInfo.response.header.vary

public.cache-control

private.cache-control

Calculating
how its cached

Multiple factors can
affect the cache scope and expiry time for a page. The remote-cache-scope and
remote-cache-expiration of a rendered page view is calculated as the minimum of
the following factors:

Cache scope
and expiry time specified for the page

Cache scope
and expiry time of the portlets on the page

Cache scope
and expiry time of the theme

Global
values as defined in the Navigator Service

NOTE: Ensure that the cache settings for all
portlets on the page are consistent with the cache settings for the page. For
example, if one portlet on a page is set to only be cached in a private browser
cache, then the entire page can only be cached in a private browser cache, and
performance is not optimal.

Instead of encoding
the complete navigational state into every URL on a page, WebSphere Portal
provides ways for you to encode only the difference (delta) of the state that
is represented by the URL with respect to the state of the request that
generated the markup. The state of the current request is represented (in the
HTML case) by the HTML <base/> tag in the head area of the HTML response.
Overall, relative URLs are preferable because they are smaller and require less
server resources to generate, giving better performance.

There are two ways
to control the generation of relative URLs as opposed to server-relative
URLs.

1. Global (affects
all URLs generated by WebSphere Portal)

2. AllowRelativeURL
attribute on the <portal-navigation:urlGeneration/> tag, which overrides
the global setting.

Approach
1 (Global):

1. Add/Update the
following in statemanager service ,
"com.ibm.portal.state.accessors.url.URLContext.enableRelative"
with true/false for relative urls .

Stores a base URL
which will be used while resolving relative URL's, i.e it will generate the
<base href=""> tag on the page like below. This enables shorter
URLs and can improve the page serving performance

1. If you don't
enable the "hasBaseURL" at theme level,
<portal-core:stateBase/> doesn't generate the <base
href=""> tag causing the url looks like below even if you set the
keepRelativeURL="true" i.e. it is equivalent to
"allowRelativeURL=false"

Following article explains the different URL rewriting mechanisms in webseal junctions enabled environment. ( Extracted this information from white paper that I came across recently)

Ideally, links in web pages protected by WebSEAL should be
relative links. However, WebSEAL is usually deployed in situations where the
back-end server is not under the control of the same group.

1.Link Types

a.Relative

b.Server-Relative

c.Absolute

2.Outbound Links Modification

a.Links in HTML

b.Links in Script

3.Inbound links Modification

1.In-bound Server Relative
Links

a.Junction Cookies

b.HTTP Referrer Header

c.Transparent Path Junctions

d.Junction Mapping Table

2.In-bound Absolute Links and
Virtual host junctions

Link Types

1.Relative

Relative links do not contain the name of the server or the name
of the current directory. When the browser receives a relative link, the link
appears to be located on the WebSEAL server. Relative links are correctly
interpreted as links to other pages in the same directory on the same server.

If WebSEAL did not change the HTML, the browser would attempt to
connect directly to ServerA, bypassing WebSEAL. A correctly configured firewall
would only allow connections to ServerA from WebSEAL.

Out-Bound Links Modification

server-relative and absolute links cannot work without changes

1.Links in HTML

a.Server-relative links are
modified to include the current junction name.

b.Absolute links might or
might not need modification. Only links to WebSEAL protected resources must be
modified. WebSEAL changes the links to protected resources into server-relative
links (by default) and adds the proper junction name. If the links are for
external sites, WebSEAL does not change them.

The following example shows a fragment of an HTML page from a
back-end server:

This works only for absolute URLs (http[s]://<host
name>/<path> , where the host
name is a server in a junction) , but it might not work in every case. Consider
the following HTML coming from the back end:

WebSEAL will modify this HTML and send the following HTML to the
browser:

<SCRIPT LANGUAGE=”JavaScript”>

<!--

document.write(“<A HREF=/bad.html>This will
fail</A></BR>”);

var path = “ServerA/bad.html”;

document.write(“<A HREF=http://” + path +
“>Link</A></BR>”);

document.write(“Go to /Junction1/fun.html</BR>”);

// -->

</SCRIPT>

The first link will not be modified because it is server-relative.
The second link, http://ServerA/bad.html, will also not be modified because WebSEAL will not be able to
identify that it is a link. The string http://ServerA/fun.html will be modified even though it is not a link.

3. Create a junction with the junction cookie enabled (-j from the
command line).

In-Bound Links Modification

1.In-bound Server Relative links

a.Junction cookie

If a junction is created with the -j option (enable junction
cookie), WebSEAL adds JavaScript to every HTML page to include a cookie that
contains the junction. When the browser requests another page from the same
server, it sends back the cookie with the HTTP request

The HTML source that WebSEAL sends to the browser starts with code
such as:

<SCRIPT language=”JavaScript”>

<!--

document.cookie = “IV_JCT=%2FJunction2; path=/”;

//-->

</SCRIPT>

Using JavaScript, this code segment specifies that the cookie
IV_JCT will be sent with any request for a page on this server that starts with
a slash (/). This method fails in some cases. For example:

a.If you keep a local copy of
the page and click a link after the cookie expires,WebSEAL cannot direct the
request. A different window or tab could overwrite the cookie if you perform
the following steps:

1.Open a page using a
junction that has junction cookies enabled, The junction cookie is set to Jct1.

https://<webseal>/Jct1/index.html

2.In the same browser, open
another window for a different junction on the same WebSEAL server, which also
has junction cookies enabled, The junction cookie is set to Jct2.

https://<webseal>/Jct2/page1.html

3.When you return to the original
window and click a link, for example to /page2.html, the cookie is set to Jct2.
WebSEAL will attempt to retrieve /page2.html from the server for that junction,
instead of Jct1.

b.WebSEAL adds JavaScript to
any page that the back-end server reports to be oftype text/html. If the
back-end server erroneously reports as HTML pages that are not HTML, WebSEAL
adds JavaScript where it is not appropriate.

b.HTTP referrer header

Referer headers rely on the browser to send them out. Browsers do
not always send referer

because the browser sent the referer header to WebSEAL, WebSEAL
interprets the request as https://webseal/

Junction1/page2.html and directs it to the correct back-end server

c.Transparent Path
junctions

A transparent path junction has the same name as a directory on
the back-end server. If different Web servers use different directories, you
can use those directories as junctions. WebSEAL does not change directory names
in this scenario, server-relative links require no modification

Use the -x option to create the junctions:

s t <webseal server> create -t tcp -h backend1 -x /app1

s t <webseal server> create -t tcp -h backend2 -x /app2

d.Junction Mapping Table

The junction mapping table is a text file that contains junctions
and regular expressions. When WebSEAL looks for a junction, it tries to find
which regular expression in the table matches.

Sample

/win *.asp

/win *.htm

/junction1 /wps/myportal/*

The junction mapping table is located in
/opt/pdweb/www-default/lib/jmt.conf by default. This file name is specified in
the instance configuration file and can be modified as needed.

After you modify the junction mapping table, issue the following
pdadmin command:

s t <webseal server> jmt load

2.In-bound absolute links
and virtual host junctions

These are junctions that WebSEAL identifies using the host: HTTP
header, instead of using a directory name. With virtual host junctions,
multiple host names (for example, www.brand1.com and www.brand2.com) resolve to the IP address for WebSEAL

When WebSEAL receives the request, the HTTP header contains a
host: field that corresponds to the host part of the URL. For example, if the
browser tried to retrieve