Using the XIP Tool with WLP 10.3.2

The 10.3.2 release of WebLogic Portal included changes to the file structure of the installation and packaging of the libraries. One impact to this is the need to manually update some of the legacy tools that are still included with the install but have not been updated for you. In this case, the XIP tool.

There is a support document that describes changes necessary to get the XIP tool working with 10.3.2, but it is not complete. Rather than making this entry longer and more confusing, I will ignore that article and simply list what I did to get it working.

The zip tools are located at [BEA_HOME]wlportal_10.3propagationbinxip. This is where the tool is run from and where the changes to make it work are done. All of changes are to the build.xml file. It starts with replacing the first block of two property declarations with a set of 5. For simplicity’s sake I hard-code the key definition though it is better to set this in a property file or pass it as an argument. The orginal block is:

<property name="wlserver.dir" value="@WL_HOME" />
<property name="wlportal.dir" value="@WLPORTAL_HOME" />

And the new block is:

<property name="bea.dir"
          value="C:bea1032" />
<property name="wlserver.dir"
          value="${bea.dir}wlserver_10.3" />
<property name="wlportal.dir"
          value="${bea.dir}wlportal_10.3" />
<property name="workshop.dir"
          value="${bea.dir}wlportal_10.3workshop"/>
<property name="modules.dir"
          value="${bea.dir}modulescom.bea.p13n_10.3.2.0"/>

Next, under

<!-- Library locations, should not need to modify -->

We will make some major modifications. So much so that I will simply list the completed updates:

<property name="wls.classpath"
          value="${wlserver.dir}/server/lib/wlclient.jar"/>
<property name="wlp.classpath"
          value="${wlportal.dir}/light-portal/lib/system/
netuix_system.jar;${wlportal.dir}/p13n/lib/system/
p13n_system.jar"/>
<property name="wlp-library-dir"
          value="${wlportal.dir}/portal/lib/j2ee-modules"/>
<property name="p13n-library-dir"
          value="${wlportal.dir}/p13n/lib/j2ee-modules"/>
<property name="common-library-dir"
          value="${workshop.dir}/common/deployable-libraries"/>
<property name="modules-library-dir"
          value="${modules.dir}"/>
<property name="netuix-lib-app"
          value="${wlportal.dir}/propagation/bin/xip/applib"/>

<target name="init.app.libs">
  <libclasspath basedir="${netuix-lib-app}"
                 tmpdir="${templibdir}"
                  classpathproperty="libraries.classpath">
    <librarydir dir="${wlp-library-dir}"/>
    <librarydir dir="${p13n-library-dir}"/>
    <librarydir dir="${common-library-dir}"/>
    <librarydir dir="${modules-library-dir}"/>
  </libclasspath>
</target>

If you have used the XIP tool before, once you have made the changes above, run the setDomainEnv script from a working WLP domain, then CD to the XIP path. From there, edit the xip.properties file to your needs and then run ant. The properties file is mostly self-explanatory, except that terms Import and Export are from the perspective of the database rather than where the script is being executed from. This means that if you want to get a .portal file from a running portal you would set the following in the xip.properties:

xip.command=export
If you found this interesting, please share.

Propagation Scope Example

Following my previous post on propagation, I found that the depth of the parent tree was hard to follow for many (myself included). This example helps illustrate it more clearly:

The importance of following the node tree up to remove an item from scope is best illustrated with an example. The BO InfoView iFrame portlet contains an environment-specific URL that should not be propagated. This portlet is listed in a scope file[1] as:

scope_1492=Application:portalservices:f1portal.WebApp:f1.Portal:default.Desktop:default.DefaultDesktop:default_portal_book_main.MainBook:default_portal_book_reports.BookMember:default_portal_book_reports.Book:default_portal_page_boReports1.BookMember:default_portal_page_boReports1.Page:boInfoViewIframe_1.PageMember:boInfoViewIframe_1.PortletInst

To remove this item from scope, all of the following parent nodes must be also be removed:

scope_1487=Application:portalservices:f1portal.WebApp:f1.Portal:default.Desktop:default.DefaultDesktop:default_portal_book_main.MainBook:default_portal_book_reports.BookMember

scope_1488=Application:portalservices:f1portal.WebApp:f1.Portal:default.Desktop:default.DefaultDesktop:default_portal_book_main.MainBook:default_portal_book_reports.BookMember:default_portal_book_reports.Book

scope_1489=Application:portalservices:f1portal.WebApp:f1.Portal:default.Desktop:default.DefaultDesktop:default_portal_book_main.MainBook:default_portal_book_reports.BookMember:default_portal_book_reports.Book:default_portal_page_boReports1.BookMember

scope_1490=Application:portalservices:f1portal.WebApp:f1.Portal:default.Desktop:default.DefaultDesktop:default_portal_book_main.MainBook:default_portal_book_reports.BookMember:default_portal_book_reports.Book:default_portal_page_boReports1.BookMember:default_portal_page_boReports1.Page

scope_1491=Application:portalservices:f1portal.WebApp:f1.Portal:default.Desktop:default.DefaultDesktop:default_portal_book_main.MainBook:default_portal_book_reports.BookMember:default_portal_book_reports.Book:default_portal_page_boReports1.BookMember:default_portal_page_boReports1.Page:boInfoViewIframe_1.PageMember

While the above list contains the immediate parent nodes, the parents of those nodes must also be removed to prevent propagating the portlet, so the following also must be removed:

scope_0=Application

scope_139=Application:portalservices

scope_140=Application:portalservices:f1portal.WebApp

scope_1321=Application:portalservices:f1portal.WebApp:f1.Portal

scope_1322=Application:portalservices:f1portal.WebApp:f1.Portal:default.Desktop

scope_1323=Application:portalservices:f1portal.WebApp:f1.Portal:default.Desktop:default.DefaultDesktop

scope_1324=Application:portalservices:f1portal.WebApp:f1.Portal:default.Desktop:default.DefaultDesktop:default_portal_book_main.MainBook

In addition, any child nodes should be removed to prevent possible errors:

scope_1241=Application:portalservices:f1portal.WebApp:f1portal.Library:default_portal_book_reports.Book:default_portal_page_boReports1.BookMember:default_portal_page_boReports1.Page:boInfoViewIframe_1.PageMember:boInfoViewIframe_1.PortletInst:boInfoViewIframe_1.Localization

 

[1] It is important to note that the scope file changes on every propagation run, and must be re-created for each run.

If you found this interesting, please share.

Scoped Propagation Notes

This is from a document I recently wrote intended to provide examples and guidance for running certain scoped propagation scenarios for a client. The examples were done using an application I had handy at the time, and actual results of scoped-based propagation are application-specific, so your mileage may vary.

Scoped propagation should be tested in lower environments prior to running propagation with a Production destination. The scope properties file used for scoped propagation must be revised each time scoping is used to ensure all desired nodes are propagated.

With careful testing and experience, scoped propagation can be very useful. Without testing, scoped propagation can lead to unrecoverable state for the portal functionality. Debugging propagation scope seems at first difficult, though once an intuitive understanding of Important Scope Notes is achieved and experience obtained reading the propagation logs, configuring the scope.properties file becomes much simpler.

Important Scope Notes

The following concepts around scoping must always be considered when using scoped propagation to minimized risk.

Any scope listed will automatically include all children of that scope

If the Application:SecurityService:SecurityProviderService node is listed in the scope.properties files, all children of Application:SecurityService:SecurityProviderService will be propagated, regardless if they are specified or not.

Dependency Checking

One example of a dependency check: If a portlet (or any asset that can be entitled) is in scope and the definition of the role is out of scope and the role does not exist in either environment, the entire propagation task will fail.

The variety of dependency checks that will occur for default nodes are far too numerous to be listed, and the possibilities increase exponentially with each application-specific node. There are two purposes to pointing out dependency checking in relation to propagation. First, that the use of scoped propagation where all dependencies are not explicitly known in advance can have undesirable functional side effects. The second is that due to the complexity of potential dependency relationships, relying on the propagation servlet to detect all dependencies is a very risky assumption and not recommended or supported.

Examples and Assumptions

my_propagation_ant.xml is the propagation Ant build file used for the tests and based on the examples in the standard WLP documentation and the one that comes installed with WLP (<WLPORTAL_HOME>/propagation/bin/propagation_ant.xml).

The examples below assume all files are contained in the root of the working directory and that the commands are run from that same location. The examples also assume that default policy properties are used.

Common Scoping Steps

These steps will be referred to or repeated throughout this document with minimal change:

  1. ant -f my_propagation_ant.xml downloadSrc
  2. ant -f my_propagation_ant.xml listScopes
  3. Starting at the parent node, remove all nodes of the undesired scopes from the resulting listScopes_scopes.properties file and save as scope.properties
  4. ant -f my_propagation_ant.xml downloadScopedSrc
  5. ant -f my_propagation_ant.xml downloadScopedDest
  6. ant -f my_propagation_ant.xml combineWithScope
  7. ant -f my_propagation_ant.xml uploadCombined
  8. ant -f my_propagation_ant.xml commit

Scoped Propagation: No Content

This is a basic scenario, and one that is listed under Best Practices for propagation. These steps have a high likelihood of success used as-is in most environments.

Steps to perform scoped propagation where all managed content is left out of scope:

  1. ant -f my_propagation_ant.xml downloadSrc
  2. ant -f my_propagation_ant.xml listScopes
  3. Remove all nodes that begin with scope_[#]=Application:ContentServices from the resulting listScopes_scopes.properties file and save as scope.properties
  4. ant -f my_propagation_ant.xml downloadScopedSrc
  5. ant -f my_propagation_ant.xml downloadScopedDest
  6. ant -f my_propagation_ant.xml combineWithScope
  7. ant -f my_propagation_ant.xml uploadCombined
  8. ant -f my_propagation_ant.xml commit

Scoped Propagation: No Security

In propagation scope, Security specifically refers to the definition of Security Services under the Application:SecurityService node. These values can be scoped to a very fine level, keeping in mind the limitations listed under Important Scope Notes. With this in mind, follow the Common Scoping Steps with the undesired Security Services scopes removed.

Scoped Propagation: Desktop

Propagating admin-only changes scoped to a desktop level is very straight-forward. At step 3 of Common Scoping Steps, all nodes that do not start with the individual desktop node should be removed from the listScopes_scopes.properties and saved as scope.properties. The general format of the node is:

scope_[#]=Application:portalservices:[APP_NAME].WebApp:[PORTAL_NAME].Portal:[DESKTOP_NAME].Desktop:[DESKTOP_NAME].DefaultDesktop

Again, keep in mind the Important Scope Notes.

Scoped Propagation: Roles and Entitlements

Entitlements are entirely dependent on roles. If an asset is entitled, it cannot be propagated if a role entitled to it is not present or propagated[1]. In order to de-scope a role from propagation is also necessary to de-scope all assets entitled to that role.


[1] As noted in Examples and Assumptions, these tests were done with default policies. It may be possible to propagate entitled assets without the roles entitled, though this would result in the asset not being entitled in the destination environment, which is generally an undesired result. Custom policies also add another layer of complexity to scoped propagation.

If you found this interesting, please share.