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.

My DevX Article on How Enterprises Measure EA Progress...

Can be found at DevX.com. Free registration required.

My Article on PrimeFaces...

Can be found at DevX.com. Free registration required.

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.

Perpetuating Propagation Perplexity

The WLP 10.3.2 documentation: Propagation Inventory Compatibility states

WebLogic Portal inventories saved with WebLogic Portal 8.1 or 9.2 cannot be used with WebLogic Portal 10.3.2 propagation tools.

While this implies that a 10.2 inventory can be used, it does not specifically say so.  This came up for someone I know who then asked support if one could propagate from a 10.2 environment to a 10.3.2 environment since they wanted to build out a new, clean infrastructure for their upgraded WLP application rather than running an upgrade in the old production environment. The response was quick and short: "No".

So, being the way I am, I tried it anyway. Works fine. Granted, there are probably many legitimate reasons for not doing this, and I would never suggest it for on-going operations, but as a one-shot move from an existing environment to a new environment it is definitely worth a test run before changing your upgrade strategy.

Resurrecting the WLP Data Sync Web Application in 10.3.2

In WLP 10.3.2, the datasync web application has been deprecated. This makes sense if you consider the recommended approach is to test all of your Datasync Project work in DEV mode and then propagate up once you have everything the way you want. However, if you are upgrading or have a development process where this is not the easiest policy to implement, you may wish to bring back the datasync.war. If that is you, fear not! Blogging to the rescue!

While in previous versions of WLP it was automatically added to a portal EAR project, in 10.3.2 you must manually add the dataync.war.

The documented  approach (How To Import and Add the Deprecated 'Datasync.war' to the WebLogic Portal Application (Doc ID 1268447.1)) to add it is to use OEPE, right-click on the EAR project, select Import War, and import [WLP_HOME]\p13n\deprecated\lib\datasync.war. Doing so creates a datasync project in your workspace.

The documentation goes on to describe an edit to the MANIFEST.MF to include the classes from ImportedClasses on the classpath. When I tried it, I could get to the data sync application index page, but would get a 500 error past that.

Digging through the logs, I found class not found exceptions. I eventually fixed this by moving the jsp folder under/datasync/ImportedClasses/WEB-INF/classes/com/bea/p13n/management/data to /datasync/ImportedClasses/com/bea/p13n/management/data, re-building and re-deploying.

Running Two WLS Domains with Pointbase

I hope this guy's blog lasts forever so I don't have to manually write the steps to run two WLS domains using Pointbase on the same machine: http://www.jroller.com/gmazza/entry/reconfiguring_pointbase_databases_on_weblogic.

You would think that you could plan ahead and simply change the values for DBMS and Port on the Configure JDBC Data Sources screen, but the "wizard" still spits out config files using the default 9093 port for Pointbase.

My alternative approach is to search for .cmd, .properties, and .xml files containing "9093" and change it to "9094" for the second domain. Not as step-by-stepish, but easy to remember :)

Creating SAML Token Tip for Non-WLS Admins

The documentation for setting up SAML for WLP WSRP is very straight-forward except for one small item that us non-admins may not think of: Once you have your command window open, you need to run the setDomainEnv script in that window before calling the keytool. Otherwise, you get a nice response from the commands, but the domain is not configured to use the results!

Three Types of Product Consulting Engagements

Barring the long-term partner projects, I find there are three types of consulting engagements when you work for a product company:

Strategic: Getting the project off the ground

Tactical: Providing a solution to an isolated slice of the client project

Rescue: For the clients who thought about the first two engagements, rejected them, and then got stuck

An experienced product consultant will have experience across the full SDLC, but rarely for a single project. This is simply an observation and not positive or negative outside of the subjective context of the individual consultant.

Have you experienced another type of engagement? Post it here as a comment!

Useful Eclipse Update Sites for WLP Developers

Two handy plug-ins with the update URLs that work with OEPE:

SQL Explorer -  http://eclipsesql.sourceforge.net/

Subversion for Eclipse -  http://www.polarion.org/projects/subversive/download/1.1/update-site/

Remember: Examples are Just Examples

For example, the documentation at Using the WebLogic Server JMX Timer Service gives a very straight-forward and standards-compliant example of how to run a task at intervals.  I used this example almost in its entirety to create a module to poll a database for a specific change every 2o minutes. I then noticed that the timer would stop for no apparent reason at no obvious interval.

After many hours of digging through logs looking for some cause, I was ready to give in and post a plea for help on a mailing list. It just so happened used a text editor to grab the code to post, and noticed in the text editor that there was one place where unregister would be called on the bean: under contextDestroyed in the servlet to at registered the timer.  In the clarity of hind-sight I realized that the timer was stopping more often in environments that were accessed less often because the efficient WebLogic Server was garbage collecting the unused servlet handle, resulting in contextDestroyed being invoked, thus killing my timer. As it normally should, except in the case where the timer should continue running as long as the server was running.

Lesson learned: Think it all the way through between copy and past.

For those who like links and confessions:  There is an example of using a timer in my JavaBoutique article that contains precisely the same flaw in logic.