Programmatically Managing WLP Enterprise Scope Roles

Scott S NelsonLeave a comment

Recently I was working on code to manage roles in WLP. WLP roles can be at the global, enterprise application, or web application scope and I needed it at the enterprise application scope because these roles were for use with the content repository.  However, I could only find examples for the web application scope, which generally looked like this:

RolePolicyManager rpm = new RolePolicyManager();
RolePolicyItem rpi = new RolePolicyItem();
rpi.setEntAppName("testTT");
rpi.setWebAppName("ProducerWEB");
rpi.setResourceScope(
   EntitlementConstants.WEBAPP_ROLE_INHERITANCE);
rpi.setPolicyName("myTestPolicy");
ArrayList a = new ArrayList();
a.add("testUser");
rpi.setUserList(a);
rpm.createRolePolicy(rpi);

From that example, I would assume that changing

rpi.setResourceScope(
   EntitlementConstants.WEBAPP_ROLE_INHERITANCE);

to

rpi.setResourceScope(
   EntitlementConstants.ENT_APP_ROLE_INHERITANCE);

would be sufficient. Alas, it wasn’t. The role was still created at the web application level. So, being clever, I removed

rpi.setWebAppName("ProducerWEB");

which had an interesting result. The role was created at the Enterprise Application scope, but only in the RDBMS, not in LDAP and, consequently, not in the Portal Admin Console. For someone in a hurry this might be acceptable as the role could be managed from code. And, while in a hurry, I had the long view that these roles would also need to be managed from Portal Admin Console, so don’t ask me if the role actually worked for entitling when out of sync as I never tested it.

To make a long story short (probably too late for some), I contacted support, who in turn opened a bug. The response from engineering was that the WebAppName had to remain, and that one more piece was required:

rpi.setPolicyUser(
   EntitlementConstants.P13N_APPLICATION_POLICY);

And that did the trick. I looked up the documentation for com.bea.p13n.entitlements.policy.RolePolicyItem and found the setPolicyUser method listed in the parent class, though found no reference as to its value, nor did I find a getter for the attribute, so I don’t believe it was something I missed, just one of those undocumented features that are handy to know about.

If you found this interesting, please share.

© Scott S. Nelson

Using the XIP Tool with WLP 10.3.2

Scott S NelsonLeave a comment

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.

© Scott S. Nelson

Propagation Scope Example

Scott S NelsonLeave a comment

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.

© Scott S. Nelson