Making Manual Labor a 'lil less Manual
The Big Hurt
Who the heck wants to do manual labor when your finger nails are as well-manicured as ours are, eh? The WebCenter Sites Practice at Function1 is in full swing in the WCS 12c upgrade cycle, with a few clients in the process. As it were, the upgrade itself can be "sort of easy" to nearly impossible depending on the approach taken and feature(s) of your particular implementation. If the upgrade gods are shining their light down on you, you only need to go from 188.8.131.52.0 to 12c. However, there's a good chance that that isn't you, OR that that god is dead OR doesn't exist at all, but I digress (let the holy wars begin)... If this is the case for you, Function1 may be able to come to your aid or play god for at least a little while. We have been hard at work trying to develop a smarter, less cumbersome, less "let me eat a bullet" path to upgrading to 12c. Some of the serious pain involved with the latest version of the product (for users not previously using WebLogic) is the fact that WebLogic is now the only application server supported. Anyhow, if you need some help, we're in the process of doing upgrades in multiple ways for several clients. There indeed ARE several ways to skin a cat! (Yes, you guessed it. I grew up in the 1850s.) Anyhow, give us a shout before you decide to end it all... don't do it, man ... don't do it!!! CLICK HERE NOW => X
Freeze! Sir... Put Down and Back Away from the Shovel
Beyond the upgrade-related tasks themselves, as any grizzled veteran of a software platform upgrade knows, there's a whole mountain of dirt just waiting there for you to move from point A to point B. Recently while at a client, this mountain of dirt manifested itself as hard coded URLs inside of rich-text content. If you are using WCS with the OOTB URLRewiteFilter as a sole means for generating vanity URLs, then as some clients have come to understand, you are married to the WebCenter Sites context root. It used to default to "cs" in most previous incarnations of the product. As with 2 or 3 other minor changes in the 12c revision, the context has changed to "sites", and where it used to be potentially "configurable", now it is wholly unsupported by Oracle to change the context root. As the upgrade from 11g to 12c proceeded, we noticed some Basic Assets (CSS & JS) hard-coded with vanity URLs containing "cs". This discovery kicked off the wheels spinning and we quickly identified other areas with hard-coded URLs contains "cs", including rich-text fields, in a bevy of asset types. We took a few steps off the beaten path to make sure the users of the product didn't come to resent the product and the upgrade process itself (it should generally be a mostly transparent and unobtrusive endeavor from a user perspective... in an ideal world at the very least). Brute force content editing with actual users was not an option, it's error prone and just plain old annoying. So... after the upgrade of the MGMT server we did the following:
Use a Backhoe Instead
Step 1: Identify files in the /shared/ directory containing "cs" in urls and update them (to "sites" obviously). We did this via sed (no sZed's NOT dead... go watch Pulp Fiction if you missed the reference). We found the Basic Assets' files in question, as well as some files related to Revision Tracking, needing updating. It's important to update all of the files since you don't know if a roll-back will happen. Better safe than sorry. No need to leave gremlins behind. [Rides off on Motorcycle... again go watch Pulp Fiction if you don't know]
Step 2: We updated the _MUNGO tables using SQL (to replace "cs" with "sites") to update the assets for Asset Types that had rich-text attributes (CKEditor etc). Be sure to update both the STRINGVALUE and TEXTVALUE columns. This basically updates the live asset values.
Step 3: We installed Support Tools and cleared checkouts using a combination of the "Checked Out Assets" Utility in Support Tools and the Admin UI's "Clear Checkouts" functionality (this is a terribly annoying screen - there isn't a "select all" tick box at the top of the grid... jeez man... I digress YET AGAIN) and wrote some simple queries for the Bulk Edit/Save Utility in Support Tools. Then we simply bulk edit/saved all the assets in question. Violà!
Step 4: Then all we needed to do was use the OOTB publishing screens and Bulk Approve the Asset Types in question and Real-Time publish them over to the delivery cluster.
A Last Ditch Sales Pitch
Hopefully, that made some sense, and highlights the fact that upgrading the software itself can, and probably will, be the least of your concerns during a software platform upgrade.
Anyhow, If you need assistance on what can be a daunting task upgrading WCS, give us a shout. WE CAN HELP.
AGAIN... CLICK HERE NOW (DO IT NOW!!!!) => X
Until next time my fine feathered friends,