A Tale of Two Migrations

My first portal migration project was not originally expected to be a migration; it was scoped and planned as an upgrade. The expectation of an upgrade was well-founded given the high-level scope of moving from one version to the next. Those involved with WebLogic Portal at the time know the move from 7.x to 8.x was in fact a migration rather than an upgrade. While there were some bridge APIs to allow the use of old code it was poorly suited to anything that was even slightly customized, which is to say every implementation in production. The project had been expected to take 4 – 6 weeks with one developer and actually took 10 weeks and 2 developers. It was the first of two migration/upgrades for the same customer and the lessons learned from the first move allowed the second move to be completed in 3 weeks with a single developer.

Fast-forward a decade and enterprises with WebLogic Portal are once again faced with a migration. This time we know up front that it will be a migration and IT managers along with their business customers are hesitant to move forward without a clear path to follow. While the last ten years have seen all J2EE-based portal products move to standard APIs for their foundation, they still have unique frameworks that serve as (from the vendors point-of-view) market differentiator and (from the customers perspective) a new form of vendor lock-in. In the case of WebLogic Portal, the vendor remains the same (albeit through acquisition) yet there is still no easy way to switch to the newer version, and a risk to staying with the old as it has been feature-frozen since 2010 and is slated for “sustaining-only support”.

The migration path from WebLogic Portal (WLP) to WebCenter Portal (WCP) is unclear for many reasons. Perhaps the most common and least-realized barrier to an “automated” migration is that WLP in his current form has 10 years of layered patches and deprecated-yet-still-in-production APIs supporting features that are a broad amalgam of proprietary solutions and customized integrations with standard APIs fueled by a demanding customer base for a (relatively) small vendor where WCP’s current form is currently a little over 3 years old and managed by a company that believes in setting the standards and letting the market follow.

Another source of great confusion is the mixed messages over time and between messengers as to whether a staged migration is practical or if it must be done in either a parallel phase out or big bang approach. To make that even more confusing, all of those options are equally the “best” approach, though the true determination of the correct approach is specific to a combination of the enterprise time-to-market needs, development skill sets, ability to maintain multiple environments and maturity of the enterprise architecture.

Given all these contributors to the fear, uncertainty and doubt surrounding a move off of a long-lived portal platform to a new, unfamiliar technology landscape I am currently in the process of acting as guide down this winding path for a company where all the various factors pointed mostly in the direction of a staged migration.

Like that first move to WLP 8.x, the approach from the 20,000 foot elevation looked very simple and straight-forward. Build the header, footer and navigation components in WebCenter and consume all of the legacy WebLogic Portal-produced portlets over WSRP. Where the WLP application had a backing file at the desktop-level that assembled user and account information at log-in, the backing file would be modified for use at the portlet level and the rest would be easy-peasy. This original understanding was entirely correct except the last phrase, i.e., no easy-peasy.

To be continued…

References for Historical Release Dates

http://en.wikipedia.org/wiki/Oracle_WebLogic_Server

http://en.wikipedia.org/wiki/Oracle_WebCenter

Facebooktwitterredditlinkedinmail
© Scott S. Nelson

It’s the Little Tags that Count

In my on-going (and infrequent) effort to post tidbits about migrating from WebLogic Potal to WebCenter Portal I ran across this little reminder today:

WSRP does not support redirects. I’m not sure if that is per the WSRP 2.0 Specification or just the way Oracle goes about it, but for those of us working with WebCenter it doesn’t matter.

So, when doing a staged migration from WebLogic Portal to WebCenter where you have JSF portlets in WLP, in addition to making sure you update your pages to use UTF-8, check your faces-config.xml and look for navigation cases like this:

<navigation-case>
	<from-outcome>goBack</from-outcome>
	<to-view-id>/pages/SOLandingPage.jsp</to-view-id>
	<redirect/>
</navigation-case>

And remove the

<redirect/>

Failure to do so will cause all of your JSF WSRP page transitions to blow up in annoying ways.

Note that this discovery was by a team member who then passed it on to me.

Facebooktwitterredditlinkedinmail
© Scott S. Nelson

The First Step of a Journey that Began Five Years Ago

Note: I will update this article with a link to the application once the customer has done their own announcements in accordance with their external communication policies and procedures.

In the Beginning there was BEA WebLogic Portal

In 2008, Oracle acquired BEA Systems. 19 days after the official merger, Oracle announced that premiere support for WebLogic Portal would end in 2014. The current policy document (latest can be found on http://www.oracle.com/us/support/lifetime-support/index.html) has moved this date out to 2018, though they have been sticking to the “no new feature release” policy since the 10.3.2 release in 2010. 10.3.2 was intended to be 11g, except it came out a year later than originally announced at Open World in 2008 and was released as a “dot” release of 10g despite the fact that it had several major enhancements and new features.

I had been hired by BEA in 2006 as a WebLogic Portal consultant due to my extensive experience with the product as a consultant for netNumina Solutions. In 2009, Oracle released WebCenter 11g and I attended the Masters Training two weeks prior to the GA date where I learned just how very different the two portal products are.

Which Way Do We Go?

I have been unable to find any officially published direction for WebLogic Portal customers who wish to migrate to WebCenter Portal, though I have had numerous conversations with engineers, architects, consultants and product managers about how to go about this. These discussions revealed three general approaches.

One approach is to simply re-build the portal in WebCenter. This is quite viable for very small portals and avoids the pitfall of other approaches, which is the need to maintain two architectures. It is not a very practical approach for medium to large portals as it is a great deal of effort and expense over a long period of time to just to provide the same functionality.

Both the second and third approaches are about transitions. On method is to create the new WebCenter portal and build all new features there and link over to the legacy WebLogic Portal for existing features. This is very quick and easy to deliver but difficult to maintain.

The third approach is staged migration. This approach creates the a new WebCenter portal that is the where users log in and interact, with the legacy functionality being exposed using WSRP. This solution allows for the immediate introduction of the WebCenter architecture and minimizes maintenance cost. By following a policy where any legacy portlet that requires modification be first moved over to WebCenter, Business and Technology stake holders can plan the complete retirement of the WebLogic Portal infrastructure as best suits the Enterprise as a whole.

Every Journey Starts with a Sprint

This month marks the deployment of the third solution to production for my current client. It is a medium-sized, high-complexity portal and it was brought from inception to production in six months using a mixed-Agile approach. It consists of 20 portlets produced by the legacy WebLogic Portal application and two legacy JSF portlets that were migrated in two days because they include file download functionality that made them easier to migrate than to dig through the documentation to fix as WSRP. The portal also includes managed content from WebCenter Content and a shared navigation structure with a legacy Struts 1.1 application.

The Enterprise Portal Architecture for the customer is to migrate all legacy functionality from WebLogic Portal to WebCenter Portal over the next year in staged releases that will also include the introduction of new features and functionality.

Facebooktwitterredditlinkedinmail
© Scott S. Nelson

Stopping Sticky States in WebLogic Portal Beehive Producers in a WebCenter Portal Consumer

Recently had an issue where Beehive pageflows would retain their state when the user navigated to another page and returned. The business owners would not accept either the use of a button to start over or the ever-popular “Well, then don’t do that”. Understandable given it is a public site.

Without putting you through the tedium I went through to obtain the solution from Oracle Support (https://support.oracle.com/epmos/faces/DocumentDisplay?id=1419774.1 for those with an account, and thanks to Ming Kwok for providing it), turns out there is a setting accessible from the WebCenter Portal Page Definition that will cure this ill:

portletStateLifetime="ViewScope"

The above is an attribute of a portlet element. Note that in this project, all portlets are placed at design time (not fun with WebCenter, BTW). We did a bulk update of the entire application by doing a find and replace of

retainPortletHeader="false"

with

retainPortletHeader="false" portletStateLifetime="ViewScope"

Additional effort is required for JSF portlets, which a colleague is working on will be posted here when he completes his solution.

Facebooktwitterredditlinkedinmail
© Scott S. Nelson

Stopping _afrLoop Looping Refresh

While building out a new environment I found that my WebCenter portal application URL would go into a long cycle of refreshing the page at login when more than one managed server in the cluster was running.

To save many of you the long process of research I went through, the key piece to my puzzle was that SiteMinder is used for perimeter authentication. The fix for this combination (WebCenter and SiteMinder) is to change the WebLogic cookie name from JSESSION to anything else and ALL_CAPS. In my case, there was already a custom cookie name, but it was lower case.

While I did not test each part of the fix, I’ll include the rest and let someone else do so. That is, setting the cookie name as the same in both the Apache plug in and the WebCenter application. For the Apache plug-in, the cookie name is managed by WLCookieName. In the application, it is done by setting the cookie name in weblogic.xml:

<session-descriptor>
 <cookie-name>MYWEBCENTERCOOKIE</cookie-name> 
</session-descriptor>

Also, there were many posts suggesting to remove the Trinidad filter to address this. That is the wrong solution in most cases and will lead to new and annoying issues.

Official solution can be found at Oracle Support Document 1491984.1 (ADF Application Redirects Browser Indefinitely) can be found at: https://support.oracle.com/epmos/faces/DocumentDisplay?id=1491984.1. I found the all-caps naming convention on some post, and don’t know if it is necessary but do know that it is working now.

Facebooktwitterredditlinkedinmail
© Scott S. Nelson