Look, I think we can all agree that The Godfather III sucked, and was a black mark on an otherwise amazing trilogy. The one (and probably only) highlight of the movie was Pacino giving us the sound-bite, “Just when I thought I was out, The pull me back in!”. And so we welcome Dave Paroulek to the Function1 team.

As you may or may not know, the WCI professional services world isn’t all that big. Your options for finding quality consultants are pretty much either: Oracle (for an un-godly hourly tab), us, or a couple of other firms with WCI expertise. The small resource pool of qualified WCI consultants means that when we’re looking to bring new folks on board, we start by talking to people we’ve worked with in the past (usually at Plumtree/BEA/Oracle). These folks are a know quantity, and we know they’ll represent Function1 well and make our customers happy. Such is the case with Dave. Dave is another long-time Plumtree->BEA->Oracle guy who took a little different career path than the rest of the Plumtree alumni at Function1. He put his time in working for Plumtree Public Sector professional services, and then moved onto the BEA Services Engineering team. In this capacity, Dave was focused on designing, developing, and delivering WCI add-on software directly to customers. But his development experience doesn’t stop there. About a year and a half or so ago, Dave left the mothership and took a full-time gig doing software development (specifically, playing around with GWT).

And now he’s back in the fold. Absence makes the heart grow fonder I suppose, and when we talked to Dave about coming on board at Function1, he was all about it. Dave comes to Function1 helping us codify our software development practices and expertise, and continue on our quest to take over the world, err, provide world class services and software to customers everywhere. We’re tickled pink to have Dave with us: be on the lookout for more kick-ass blog posts on software development tips and best practices from him soon.

PT Tags give you the ability to use out-of-the-box coding logic within simple HTML pages. With a little patience and a slightly different way of thinking about logic flow, PT Tags can be an inexpensive answer to your UI problem.

Function1 has been “roomies” with PT Tags for quite some time, and we love our often confusing friend. To help educate our readers on PT Tags, here’s an example of solving a joined communities tag problem for portal navigation.

The <pt:ptdata.mycommunitiesdata/> tag is a useful array to get all the communities for your portal installation. However the tag includes both joined and mandatory communities for a user. Recently, a customer asked us to remove mandatory and mandatory with tab communities so the navigation could be seperated. How? we thought.

The solution is to use a different list of data from <pt:data.mandtabcommsdata />. This tag contains an array of mandatory with tab communities. Our thought process was to loop through the communities data and compare it to a continuous loop of mandatory tab data. Whenever a link was found that did not have a matching mandatory link, we printed it as a joined community.

Those mandatory tab communities might still be needed elsewhere. The following logic first checks if there are any mandatory communities, then loops through all communities and prints a nice link. You can include any css on these links simply by adding the class attribute to the <pt:core.html/> tag.

Finally, administrators and community managers might need to edit their communities just like the out-of-the-box navigation. The following logic will print any additional buttons such as “manage communities”.

DOWNLOAD THE FULL CODE HERE

We’ve noticed that we spend so much time with Aqualogic that we think PT Tags is a person. Since it doesn’t really have a face, we’ve decided it would probably look a lot like Puck from MTV’s Real World.

If you peruse maven articles out in the blog-o-sphere, this is the message you’ll hear:

Using Maven will make you a better developer. Using Maven will make your organization more productive. Maven will solve your integration issues. Maven encourages unit testing. Maven will enforce DRY best practices and Convention over Configuration. Maven will save the rainforest and will give you thick, shiny, lustrous hair. Marcia, Marcia, Marcia! … Maven, Maven, Maven!

You (or your software dev team) might have already written quite a bit of java web apps and have managed to get by pretty well without Maven. You may have even written some killer java portal apps which your organization can’t live without.  

If you’re like me, you’re also probably a bit tired of learning scripting languages (ant, perl, make, bash, dos, ruby, on and on, and on). You’re probably hesitant to make the investment in learning another. Well, I hear you. I feel your pain. So, in this article, I’d like to give you some idea about what types of tedious tasks that Maven can help you eliminate (and by doing so, possibly save significant development cost). I also want to try to convince you that Maven is worth the effort. Stay tuned for later articles where I will dive deeper into the actual implementation details of how to best use Maven to manage your java projects.

So, to prove it to you that Maven is well worth the investment, I’ll walk you through a recent experience. As a new employee at Function1, I am very excited about the product suite currently in development. In particular, I wanted to help add some functionality to one of our new products named Formbuilder.

Remember Studio Server? You know, the one with the Tetris Easter Egg? Well, Formbuilder is everything Studio Server was, plus an easier to use interface and updated with the latest and greatest technologies. Formbuilder really makes it a no-brainer to create and administer surveys and polls. Formbuilder can be run as a standalone webapp inside any of the standard java web containers. It can also be installed to run as a portlet with tight integration with Web Center Interaction.

Here are the steps it took me (as a brand new F1 employee, totally unfamiliar with Formbuilder source code) to get to the point where I could compile and run Formbuilder in a development environment without Maven. Afterwards, I’ll compare how each step might have been accomplished using Maven. And you can be the judge ;-)

Formbuilder is a standard java web application. On the back end, it uses servlets to manage requests. The servlets talk to a service layer powered by hibernate that manages persisting and retrieving data to database. On the front end, it uses GWT and Ext-JS to provide the views. Administrators can create surveys (using a very slick and easy-to-use user interface, imo):

And, of course, Formbuilder also provides a page where you can complete and submit surveys:

When I first got a hold of the source code, I was really impressed how well everything was organized. The folder structure followed the normal java development best practices and coding conventions. There were no surprises from a software development point of view.  Even so, getting to the point where I could actually write code, was pretty slow going. If you’ve ever inherited a non-trivial java application to maintain, I’m sure you can relate. And in my experience, this “ramp up” time is generally accepted by most development teams as something that you “just have to roll up your sleeves and get done”. Here are the steps that were necessary for me to get from having zero knowlege of source code to where I was able to compile and run the Formbuilder application:

Check Out Source Code

The first step was to get the source code. A few emails and I had access to subversion and I was able to check out the latest and greatest using the svn command line tool.

Create Eclipse Project

Eclipse stores info about what it thinks are java projects under a file called “.project” and a folder named “.settings”. Since these had been checked into subversion, I was able to import the code directly into eclipse as an eclipse java project. Unfortunately, this only kinda-sorta worked. Since the eclipse project had been build on another machine, the Eclipse files contained hard coded paths. There were red X’s everywhere and Eclipse was not happy.

Resolved Dependencies

One of the biggest hassles working with Java is managing the thirdparty jars that each web app depends on. In this case, it was easy to see that all required jars were inside the war/WEB-INF/lib directory. However, I also noticed that all these jars had been checked into source control. For small to medium sized projects, checking jars into source control works ok. But, in my experience, as the source code grows so does the jar dependencies and pretty soon the number of jars becomes unmanageable. Checkouts from svn can quickly become excruciatingly slow. In this case, it wasn’t a big problem (but something to keep in mind for future maven articles :). I manually added each jar to the eclipse project’s build path and that made Eclipse a little happier, making a lot of the existing red X’s go away.

Compiling the UI Code

Google Web Toolkit (GWT) is a technology that allows you to write java and have it compiled into javascript. Formbuilder uses GWT to create some really slick web user interfaces. So, the next step was to download and install the Eclipse GWT plugin. This plugin handles all the configuration necessary to be able to “compile” gwt java code. After setting up the plugin, eclipse was 100% happy, all the compile errors (Red X’s) in eclipse were satisfied!

Build Database

So now it’s time to fire this bad boy up and try it out?! Oh right, I probably need to install a database. Some hunting and I found the hibernate.cfg.xml which contained the database credentials. I noticed there were 3 database flavor’s configured inside of the xml file. Two of the configurations were commented out. I learned that Formbuilder is compatible with serveral database vendors including MySql, Oracle, and Microsoft SQL Server. I chose to use MySql since it lends itself well for development. A few google searches later and I was able to use the mysql command line tool to create a new mysql database (and new mysql user) to match the credentials found in the hibernate config file. I then used the hibernate hbm2ddl tool to automatically generate the datbase schema based on annotations inside the source code. Very cool. Life was good.

Package

Okie-Dokie. Things are compiling. The database is created and is online. The next step is to build a war and then test. I found a helpful shell script (named deploy.sh) that bundled up all the compiled class files created by eclipse along with the WEB-INF directory (including all the jars) into a war file. I copied the war file into tomcat/webapps and pointed my browser to browse to http://localhost:8080/formbuilder and voila? Oh, Dag nabbit!

Runtime Error #1

From the stack trace, it looked like the servlet was not able to connect to the database. After some more hunting I found that there were several application properties files. One property file was used to build a war to run on a local development environment. Another properties file was used to build a war to run on a production server. The production properties file was “active” so I switched back to the local properties file. Ok, run deploy.sh again. Then copy the war over to tomcat/webapps again. Browse to the formbuilder page, and …. DOH!

Runtime Error #2

I was seeing the same database connection error. After some troubleshooting, this time it turned out to be that some of the values inside the properties files were overwriting some of the
values inside hibernate.cfg.xml. I could see that this was intentional. This way, the deploy.sh script could easily switch back and forth between building war for development vs a war for production. Run deploy.sh again, then copy the war over (…again!).

Runtime Errors #3-15

I was now able to connect to the database. But the next errors were several runtime ClassNotFound errors. Even though I had copied all jars over from WEB-INF/libs, it turned out that I needed to find and download a few extra from various web sites. It turned out that I was using a different version of Tomcat than other developers. So I ran the bash script to create the war (…again!). Then, I manually copied and pasted the war into tomcat/webapps (…again!).

Run!

Finally! Formbuilder was running inside tomcat. I was able to create and save a new survey successfully. All in all, it took probably close to 20 hrs to get to the point where I could start being productive and writing code.

Maven

Now, I’d like to describe the steps it took me to get up and running after I “mavenized” the formbuilder project. You ready for this?

c:\> mvn install

That’s it! No lie. That single command (1) resolves and downloads required thirdparty jars (2) compiles java to class files (3) compiles gwt java to javascript (4) generates the database schema (5) runs junit tests (6) creates a war (7) and actually starts an embedded tomcat server which runs the Formbuilder web app.

I’m convinced. So What Next?

None of the steps described above will come to a surprise to anyone who’s ever written a Java web application. It can be frustrating (and costly) to manually repeat the same housekeeping tasks over and over. Maven solves this problem by forcing you to organize all your Java projects exactly the same. It gives you a common set of commands for building Java applications. Think how great it would be to be able to run “mvn install” against any piece of source code that can be found in your organization and have it handle all the tediousness for you?! Automation is a beautiful thing.

Stay tuned for Part II where I’ll cover more on exactly which common development problems that Maven solves and specifics of how to configure Maven to do so.

Recently, I was on a client project migrating from ALUI 6.1 to WCI 10gR3. Beside overcoming the usual quirks with SSL, security certificates, notification service, analytics, and upgrade documentation that seems to cover 90% of what needs to be done and leaves 10% for us to improvise, I had issues with LiquidSkin. You remember that product developed some time ago for BEA Systems when WCI was still ALUI?

A quick refresher: LiquidSkin is a set of libraries you can add to a portal install to customize the portal menu styles (dropdown, tabbed, vertical or horizontal navigation, …), the styles around portlets, pages, and communities and a whole slew of customizable navigational styles. The customization is defined in XML files that map to experience definition objects. Within the XML, you can target the customization to specific sections on a portal page; e.g. above banner, below banner, below body, above footer, etc. After the Bea acquisition, Oracle kept the assemblies current but I’m not sure if it has been thoroughly tested with WCI 10gR3.

So, after migrating this customer’s development environment to 10gR3, upon a first visit to a community, the skin defined in the experience definitions for that community rendered properly. All objects were rendered with their respective skin settings; e.g. portlets colors, page background color, etc. However, after a subsequent navigation to a different community with a different experience definition, the skin attached to it did not load. Instead, the target community was rendered with the skin attached to the community visited first. You can imagine this: a community with correct page and portlets but incorrect styles and navigational menu below the banner!

The first thing that came to our mind is the caching setting that is defined for each section in the LiquidSkin.xml for that experience definition. The setting were:

<sCacheMode value=”NONE” />

<iCacheLifetime value=”0” />

which indicate that caching is disabled for that particular section; all other sections had the same setting in the XML file.

I compared the IIS portal web site settings between 6.1 and 10gR3 and they were identical. I insured that the adaptive page layout for each experience definition object is disabled. After extensive fruitless digging, it seems that moving away from LiquidSkin to adaptive layouts for styles and navigation is the most feasible option. But we are still looking into this and will post an update if we discover a resolution.

Thanks.

Hani

Who says you can’t teach an old elephant new tricks?  In an effort to offer the best portal services available, Function1 has been spending a lot of time with Microsoft Office SharePoint server. Microsoft is a traditional market leader and its most recent incarnation of SharePoint has the technology baked-in to live up to the hype. Instead of just taking Microsoft’s word for how totally radical the software is, we did our own digging into the benefits and problems SharePoint has had over the years. We’ve been quite impressed by the integration of server and client side software, and by the general architecture of the MOSS solution. So much so, we believe the most recent SharePoint release is a viable contender for customers who want to migrate away from WCI to another  enterprise portal solution.

Before we get started, some terminology:

• WebCenter Interaction (WCI) – The Plumtree->BEA Product Stack that you’re probably running now.
• WSS (Windows SharePoint Services) – The foundation of the SharePoint server platform. This is also the gateway for developers to interact with SharePoint behind the scenes.
• MOSS (Microsoft Office SharePoint Server) – The presentation layer and pre-built components that make up the portal aspect of SharePoint.
• Web Parts – The individual components that make up a Sharepoint site.  For WCI users, these are portlets.
• Web Sites – The areas of pages and web parts that combine to create a portal. For WCI users, this is the equivalent of a community.

From here on, I’ll refer to MOSS as simply SharePoint.

The History, Myth, and Legend

SharePoint has been competing in the portal space for a long time. SharePoint 2001 was Microsoft’s first endeavor in portal technology and was primarily a document storage solution. SharePoint 2003 built on this technology, but was plagued with scalability and usability issues. By the time 2007 rolled around, Microsoft had already been given a bad wrap for their portal technology and the myths surrounding the product became legend.  But the Sharepoint 2007 release went a long way to discrediting Microsoft’s critics.  With the 2007 release, in our opinion, Microsoft made the jump from “departmental document sharing sites” to “ready-for-primetime enterprise solution”.

SharePoint makes sense for customers with a heavy investment in Microsoft technology (Server, .Net Framework, SQL Server, and Office)

Microsoft was not at the forefront of Portal technology in 2003, but this gave the company the late adopter advantage of learning from other company’s mistakes. Instead of reinventing the wheel, Microsoft took the very best of portal technology from competing products and created a fully integrated suite of tools. Tight integration has been built from the Web to the Desktop through Office Tools, and from the Web to the Developer’s desktop through Visual Studio and SharePoint Designer. There’s also WEB 2.0 goodies like blogs and wikis, as well as a workflow and document management solution right out of the box.

What you need to install to get started

The reasoning for integrating middleware is similar for both Oracle and Microsoft. If you buy the portal product, life will be so much easier if you just buy all their connecting products too. Microsoft SharePoint is no exception with tight integration in Microsoft Office, Exchange, and Developer tools.

There are a few moving parts needed for for a basic SharePoint installation.

• Microsoft Server 2003/2008 – This is self-explanatory, but the point we’d like to make is that you can use 32 or 64bit flavors of the server software. This is something we’ve been missing from Oracle WCI 10gR3.
• Active Directory – Although not required for a SharePoint installation, many of the security features and some of the add-ons require an AD source.
• IIS (Internet Information Services) – Microsoft’s web hosting platform handles application pools, memory management, and the .NET framework. SharePoint plugs right into existing IIS environments as a new website.
• SQL Server – Continuing on the theme of one company to rule them all, the database needs to be a SQL Server flavor. There are no alternatives to this, unlike WCI 10gR3 which had a number of database options.
• .NET Framework – Microsoft’s development container (it actually contains a number of languages) for the development of custom applications. Also the development base for WSS and MOSS.
• WSS (Windows Shared Services) – The nuts and bolts of any SharePoint deployment. This set of services includes web farm management, a persistence layer, workflow, content management, and search.
• MOSS (Microsoft Office SharePoint Server) – The interface, websites, and web parts that make up the user experience. Also includes integration with Office tools and SharePoint Designer.
• Visual Studio 2008 – Although not a requirement to get started, any development with the .NET framework will include Visual Studio. If you’d like a solution that includes source control, we suggest the team edition.

A Familiar Face

One of the benefits to having a Microsoft development team working on a portal product is the common user interface found in the SharePoint administrator and user experiences. Many of the menus are “office-like” and have been made even more so in SharePoint 2010 where the ribbon style interface has been employed. Behind the scenes, SharePoint employs AJAX and rich-text editing throughout the SharePoint experience. What Microsoft lacks in cutting-edge portal technology, it makes up for in robust engineering of the portal components.

Scalability and Availability

In the past, the weakest link in SharePoint deployments has been the limited amount of scalability and availability options for a systems administrator. SharePoint 2007 changes all that. With the 2007 release, Microsoft dismantled the SharePoint solution into a number of independent services that can be deployed on clustered, distributed, and virtual machines. Services communicate through the common WSS interface allowing for stateless services across a server farm. For smaller organizations, we found scalability goes both ways. SharePoint can actually run on a single computer (although highly frowned upon). Resource usage for a small organization is nominal compared to Oracle’s WebCenter 11g base deployment. Microsoft has also allowed organizations to expand on an existing SharePoint installation by reconfiguring and adding to server farms as needed.

On the availability front, load balancing can be employed through a hardware device or Microsoft’s load balancing software solution. SQL Server contains Mirroring capabilities, and content can be distributed between multiple data stores to maximize server hardware.

Thank Goodness for Documentation

Plumtree Portal/ALUI/WCI  has never been credited to have a broad base of documentation, knowledgebase articles, examples, and blogs from users. As a former BEA consultant, I have felt the pain customer’s go through when trying to troubleshoot an undocumented problem. Oracle, similarly, has little documentation from real world WebCenter 11g users, because the product is so new to the market. SharePoint, on the other hand, has been widely used in various industries and there is a ton of documentation out there to support a SharePoint shop. From developer examples to 3rd party add-ons to UI Themes, the SharePoint community is verbose.

I’m sold, lets get on the SharePoint train!

Not so fast. Much like Oracle WebCenter 11g, there is no real clear path on migrating content from WCI to SharePoint. Although the technologies have similar portal components, SharePoint is a database driven solution whereas WCI was split between databases and file system storage. Don’t expect a migration plan from Microsoft’s rival, but that’s where we are hoping to help. As portal experts, we have the tools and knowledge to help you make the move from WCI to SharePoint. No, we haven’t received payola from Microsoft, we just want our customers to have the best solution for their investment. If you’re thinking about moving from WCI to SharePoint, or are just interested in more information about SharePoint Server in general, contact us. We’re happy to get you up to speed on your options.

When we very recently refreshed our web site’s design, we also decided to change our blogging platform from MovableType to WordPress. As expected, as part of the migration we carefully migrated all of our blog content to our new site. However, we almost overlooked one detail that could potentially have both made our content inaccessible to some of our readers, as well as hampered our site’s search engine rankings.

Some background information: the URLs for the old blog posts were in the form http://www.function1.com/site/[year]/[month]/[post title].html. The URLs for the new blog posts are in the form http://www.function1.com/[year]/[month]/[post title]. For example, the old blog post http://www.function1.com/site/2007/12/check-search-server-status-the.html can now be found at http://www.function1.com/2007/12/check-search-server-status-the-hard-way/

So what’s the problem? Broken links, better known as 404 errors. Take a look at the following screenshot from Google Webmaster Tools:

Function1.com Crawl errors on Google Webmaster Tools

Other sites are linking to our content, and specifically to our blog posts, and that is important to us. The table in the screenshot represents just a small subset of the links from other sites for which Google is now reporting crawl errors; this manifests into a lot of content that is sitting on our blog but is inaccessible because it’s being referenced by an invalidated URL. If people stumble across pages linking to our old blog posts, we of course want them to be able to get to our content. Now, do a Google search for “site:www.function1.com/site/”. As you can see, Google still holds a reference to many of our old URLs. Yes, Google is aware of the URLs of our new links (for example, through our sitemap), but we don’t want to lose the history we’ve established with Google, especially since Big G really does care about our old links going dead.

If all of the above didn’t make sense, here’s a made up example: what if Yahoo! decided to change its name to Oohay!, and in the process moved its domain from Yahoo.com to Oohay.com? The news stories, sports scores, images, movies, and all the other content would still exist, and we can be sure that Google would eventually discover all of the new URLs. But all of the old links to the content would effectively be severed, and as far as the search engines are concerned, it would be like one site completely shut down and a brand new site sprung up. The PageRank that the old URLs had earned would be blown away.

In comes our hero, the 301 redirect. The 301 HTTP status code tells the browser that a requested resource has permanently moved to a new location. In other words, we can configure our web server so that a request for http://www.function1.com/site/2007/12/check-search-server-status-the.html returns with a message to the browser that the resource has moved permanentely, and that the new location is http://www.function1.com/2007/12/check-search-server-status-the-hard-way/

To implement these redirects, I set aside some time setting up an .htaccess file that would hold the mappings for all of our old blog post URLs and some other old paths to the valid URLs. Again, the point is to make sure that our content is still accessible via the old URLs but is still ultimately located at the new URLs. Due to the number of blog posts that had to be redirected, I ended up writing a script to do a lot of this for me. If you are interested in the script, check it out at http://github.com/mshafrir/MovableType-to-WordPress-.htaccess-Generator/blob/master/htaccess.py. In any case, here’s a look at a slice of our current .htaccess file.

For further reading, here’s an article on .htaccess files and 301 redirects.

And just to make sure I’m not making all this up, do a search for “site:www.function1.com/site/” on Google. Choose any link in the results, but before you click on it, note the URL in green. Finally, click on your chosen link, note that the content you expected came up, and then compare the URL in your location bar with the URL on the search results page. You’ve just observed 301 redirects in action.

Hopefully you’ve learned a little bit about the issues and risks that can arise from changing your site’s URL structure which may come about from migrating your site’s blogging platform or content management system (CMS). Please feel free to post your comments or questions below.

In 2006, the famous (infamous? I can never get those two words straight) street artist Banksy put on a show in an LA warehouse named, “Barely Legal”.  The centerpiece of the show was “The Elephant In The Room”, a painted live elephant that seemed like, IMO,  a pretty blase metaphor all dressed up in shock and awe.  But I’m sure there was deeper meaning that I was missing…what do I know about art anyways?  In any case, it’s a new decade now, and I don’t need to literally paint an elephant to point out that there’s an elephant in the room for WCI customers: Oracle WebCenter 11g.  I’m sure you’ve all seen some of the marketing around Oracle’s new portal platform, and maybe even seen a demo or two.  But here at Function1, we’ve been spent a lot of time and effort digging past the marketing material to try to understand the real value proposition of WebCenter 11g, both for new portal customers, and for existing WCI customers.  So, without further adieu, a gentle introduction to WebCenter 11g for WCI customers.

Since marketing people seem to like to give similar names to completely different things, let’s start with some terminology :

• WebCenter Interaction (WCI) – The Plumtree->BEA Product Stack that you’re probably running now
• WebCenter Suite 11g - Oracle owns 3 portal products:  WCI (Plumtree->BEA acquisition), BEA Portal (BEA acquisition), and WebCenter (Oracle Organic product).  WebCenter Suite is the blanket license you can buy to acquire all three of these portal products.
• WebCenter Framework – A set of ADF components and APIs that let developers tap into the Oracle product stack
• WebCenter Services – A set of pre-built business components (Blogs, Wikis, Social Graph, etc) that developers can utilize to build applications.  These are essentially out of the box portlets
• WebCenter Spaces – The homegrown out of the box Oracle portal product
• WebCenter 11g - The term used for collectively referring to Oracle WebCenter Spaces, WebCenter Services, and WebCenter Framework

The rest of this post will focus on WebCenter 11g, and the components that comprise it.  So what is Oracle WebCenter 11g?

At heart, WebCenter is a development platform

If you take nothing else away from reading this, remember that WebCenter is a development platform first.  Specifically, WebCenter is an integrated, end-to-end Java development solution for delivering enterprise applications.  This differs dramatically from the WCI approach.  In the WCI world, product is first, and development is second.  The focus of WCI is to provide a configurable, out of the box portal experience for users.  WebCenter, on the other hand, is geared towards providing developers a set of components and APIs that can be pieced together to build and deliver enterprise applications.  The addition of WebCenter Spaces (the WebCenter Portal) to the stack is just one method to surface custom WebCenter apps.

WebCenter makes sense for customers with a heavy investment in Java and Oracle

If you’re a .NET shop thinking about replacing WCI, you should probably stop reading now and start thinking about Sharepoint (We’ll have a similar intro to Sharepoint for WCI users post up soon).  Sure, WebCenter is committed to open development standards, which means you can write .NET portlets and wrap them in WSRP so that they get consumed through WebCenter Spaces.  But going down this road is kind of like putting ketchup on a nice steak.  Yeah, you can do it, but why would you want to?  At the end of the day you’re just wasting time and money.  If you wanted something to put ketchup on, you should have just had the burger for dinner.  If you’re going to eat steak; eat steak.  If you’re a Microsoft shop, let your developers build their stuff in Visual Studio and take advantage of the tight integration with the Sharepoint platform.  If you’re an Oracle shop, let your developers build their code in JDeveloper and take advantage of the tight integration with the Weblogic App server and the rest of the WebCenter/Oracle platform.

WebCenter is a way to surface Oracle’s Fusion Middleware stack

Oracle is probably happy that you pony up the cash to use WebCenter, but they really want you to run your enterprise on Oracle software.  Not coincidentally, there are APIs and components built into the WebCenter Framework that allow you to nicely integrate and surface Fusion middleware components.  Things like their BPEL engine, SOA suite, etc.  If you’ve invested in Fusion, the addition of WebCenter might be a nice way for you to tie a bunch of disparate middleware components together.

OK, so what do I get out of the box?

Just because WebCenter is targeted at development shops doesn’t mean that Oracle left you high and dry if you just want to install products and get going.  Out of the box, you get a portal environment in WebCenter Spaces.  The portal provides you Group Spaces (i.e. WCI communities), Personal Spaces (i.e. WCI my pages), user customization, and a security model.  The user security model is built on top of Weblogic Server security.  This means that, out of the box, your users are going to be stored in the LDAP user store embedded in WebLogic.  You can, however, delegate security out to your corporate LDAP/AD, or integrate with an SSO solution.  In addition, you get the functionality (i.e. pre-built portlets) of WebCenter Services.  These services include Document Collaboration, Blogs, Wikis, Tasklists, Tagging, Search, Activity Streams, Calendaring, and more.  You also get a limited use license for Oracle Universal Content Management (UCM).  UCM is the Oracle branding for their Stellent acquisition, and the product is actually quite mature and worthwhile as an enterprise content management solution.  For more info on UCM, take a look here.

Great, so what do I have to install and manage to make this stuff work?

This is kind of a loaded question, as the answer changes depending on how much Oracle functionality you want to expose through WebCenter.  At a bare minimum, however, you’re probably going to have the following components in your WebCenter environment.

• JDK 1.6 – Yep.  It’s the JDK.  You’re running Java, so you need the Java runtime and associated toolkits
• Weblogic Server – Oracle’s J2EE app server of choice since the BEA acquisition.  Note that Weblogic Server licenses are an additional cost in the procurement of WebCenter
• Database – WebCenter has support for both Oracle and SQL Server databases.  Not sure why you’d be running SQL Server if you have so much other Oracle product, but you can if you want to.  There are several schemas that get installed as part of the WebCenter installation to manage meta-data for the various applications in the stack.
• UCM – With the release of UCM 11g this summer, things will change a bit and UCM will just be another WAR/EAR that you deploy to Weblogic server.  For the time being however, plan on installing a standalone Java server that runs the UCM application.
• WebCenter WAR files - Deployed and manged in Weblogic server are various WAR files for running WebCenter components (Spaces, Services, etc)
• Apache – You probably don’t really need Apache, but everybody seems to like to stick it in front of Weblogic for serving up static HTML content.
• JDeveloper – Like it or not, it’s the IDE your developers are going to be using for composing WebCenter applications.

And what if I’m concerned about things like scalability and high availability?

This is one area where I’m personally quite happy with the way Oracle did things.  Because everything is deployed to a J2EE container, you can architect your solution as a traditional 3-tier web application.  Install a hardware load balancer for web request distribution and fail over.  Scale out your web tier horizontally as needed for load and high availability.  Cluster your app servers.  And use your Database vendor’s replication solution of choice (Oracle RAC, etc).  One item of note here is that we’ve found WebCenter applications to be quite RAM intensive (moreso than even most Java Apps).  Luckily, like talk, RAM is cheap.  So plan on loading up your servers with a bunch of RAM to avoid a painful user experience.  Also, consider how you’re licensing WebCenter.  If you’re paying by Server/CPU/Power Unit/whatever term they use these days, building out a large fault tolerant environment can get pretty costly, and you might be better served to just look into an ELA/all you can eat model.

So, what kind of skillsets should I have on my team?

IMO, you’re going to want some number of the following resources on your team to run a WebCenter project successfully:

• Java developers- You’ll want these guys to be familiar with J2EE and JSF.  If you’re really lucky, they’ll know all about Oracle ADF (Oracle’s proprietary extension to JSF) as the ADF learning curve is non-trivial.  It would probably also be good if they have experience developing in JDeveloper.
• System Architect – Somebody who can plan your hosting environment for you and knows how all the pieces fit together.  i.e. somebody who understands your network topology and can tell you which segment of the network to stick servers in.  Somebody who can implement a highly available solution.  Somebody who can tell you how much horsepower you’re going to need to run your environment, and, additionally, how you can scale to meet increased demand.
• Weblogic Expert – The vast majority of the components you use, and the code you write, is going to get deployed to Weblogic Server.  Having production support who know the in’s and out’s of Weblogic is a good idea.
• Functional People – These are the same functional folks that you’d have for any portal project.  They’re going to help define governance, drive development, and generally take care of the important stuff that your tech guys don’t want anything to do with.

I’m sold, how do I migrate?

This is, literally, the million dollar question.  Your first step towards migration is moving your licenses over from WCI to WebCenter Suite.  Once you’ve gotten over the sticker shock of doing so, the world is your oyster.  Except…uh…there’s no migration plan from Oracle; no real roadmap to help you get from point A to point B.  And that’s where we hope to fit into the equation.  Function1 understands both the WCI and WebCenter environments.  We can help you get the most out of your WebCenter installation, without completely throwing away your investment in WCI and starting from scratch.  If you’re thinking about moving from WCI to WebCenter, or are just interested in more information about WebCenter in general, give us a ring or drop us a line.  We’re happy to come out and talk to you.

Oh, and one other thing…

Some of us on the Function1 team delivered a much more detailed deep dive presentation on WebCenter recently.  As a show of team unity, we all decided to grow moustaches.  As a thanks for reading this whole post, here’s a picture of our best ’stache.

Sadly, he has nothing on this guy.

]]> http://www.function1.com/2010/01/the-elephant-in-the-room-a-gentle-intro-to-webcenter-11g-for-wcialui-customers/feed/ 1 http://www.function1.com/2010/01/welcome-to-2010/ http://www.function1.com/2010/01/welcome-to-2010/#comments Mon, 11 Jan 2010 18:15:19 +0000 Brian Hak http://www.function1.com/?p=481 Howdy all, and welcome to to the new decade.  To kick off the new year in style, you may have noticed that we re-branded our website.  New look and feel, new content, and new back-end engine:  we swapped Movable Type out in favor of Wordpress.  So what do you think?  Like it?  Love it?  Hate it?  Doesn’t make all that much of a difference in your life?  Leave a comment and let us know.

As a company, Function1 is pretty excited about the opportunity that 2010 brings.  While continuing our focus on WCI, we’ve also been investing in new technologies to the company (namely, WebCenter Suite and Sharepoint), and spending time developing kick-ass software.  Stay tuned for more info about our software offerings and musings about WebCenter and Sharepoint in the coming months.

As always, thanks for reading…we hope the new year finds you happy, healthy, and prosperous.

$pub_root/foo/foo.html

contains a link to another content item that looks like:

http://pubcontentserver/bar/bar.html

So far so good, except that during the content migration, the foo and bar directories are getting rolled into one new folder named foobar.  When this happens, we’ll end up with the following files:

$pub_root/foobar/foo.html

$pub_root/foobar/bar.html

http://pubcontentserver/bar/bar.html

What we’d like to happen, though, is for our link to point to the new location of the file, i.e.:

http://pubcontentserver/foobar/bar.html

This particular client has a bunch of published content items (in the tens of thousands), which makes it pretty impractical to ask someone to manually go through every published content item and look for links that are going to break.  So I volunteered to write a script/program to go through and identify potential problem links automatically.  I have to admit I first volunteered because I thought this was going to be really easy to figure out via. a recursive grep:

From $PUB_CONTENT_ROOT on filesystem

find . | xargs grep -i ‘publishedcontent’

Just to make me mad though, while the grep approach works, it returns too many false positives.  It turns out that a lot of the out-of-the-box content items have links back to themselves, i.e something like:

in the file $PUB_CONTENT_ROOT/foo/foo.html

http://pubcontentserver/foo/foo.html#myTarget

And Publisher is smart enough to fix these self-referencing links when you move the items around, i.e. the link above gets updated to

1) Recurse down the published content tree and examine all the published content items
2) Check for links to other published content items in each file.  This can be done by looking for a specific token, which by default, is “publishedcontent”
3) At this point, we have a list of all the links to content items in the file.  However, we need to filter out the self-referencing links that will get auto-updated by Publisher.  To do this, let’s look at the path in the link, and ignore any references that point to the same directory.  For example:

In the file $PUB_CONTENT_ROOT/foo/foo.html
We’ll capture the link http://putcontentserver/bar/bar,html
But we’ll ignore the link http://pubcontentserver/foo/mystuff.html because it will be auto-updated by Publisher.

4) Dump all matches found out to a file so the links can be reviewed and fixed.

So I wrote some code that does the above.  Go grab LinkChecker.java if you’re interested.  The code is pretty simple, but it does have a few caveats which are all listed in the comments.  You should be able to compile the code with a JDK 1.5+ compiler without any external dependencies:

javac com\function1\utility\LinkChecker.java

java -classpath . com.function1.utility.LinkChecker my/path/to/pubcontent_root/publish

WebCenterInteraction_10.3.0.0.0.exe -f example-silent.properties

Annoyingly, you get no feedback at all on the state of the install when running this way.  Your  DOS prompt will return immediately, but have no fear, the installer is running.  Open up Task Manager, and look for the “WebCenterInteraction…” process.  Once it disappears, the installer is done.

3) Portal does an OS check when it starts up, and doesn’t like you running on a non-supported platform.  Luckily, the check it does is pretty easy to trick.  Just tell Java to set the OS.name environment variable to Windows 2003 when you start your app server.  For Weblogic and Tomcat, you’ll want to add something like this to the script you’re using to start the server:

set JAVA_OPTS=-Dos.name=”windows 2003″

4) Oh, and one other thing.  Even when you do all the above, you /might/ have problems with getting configuration manager to lay down correctly.  Luckily, Configuration manager is just a straight forward web app.  We made it work by running the installer on a Win2K3 box, and just copying over the entire configmgr directory.  Works like a charm.

And that’s all she wrote.  Have fun, and good luck.  Just to brighten up this post a little bit, here’s a picture of my just completed, first ever piece of handmade stained glass…enjoy :)