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.

© Scott S. Nelson