The main reason my Learning Oracle ADF series -- Creating Java objects from database tables, Simple JSF data view/entry form, and Master-detail forms -- was so late is because I spent most of the month struggling with Oracle Portal, leaving me very little time to work on the series. If your boss ever brings up the subject of Oracle Portal, you should run screaming from the building. It is easily one of the buggiest pieces of software I have ever encountered.
Oracle Portal is a product for building corporate portals. It is a JSR-168 container, which means you can write little portlets that can then be assembled into pages through the portal. Even though it's a Java standard, the portlets don't actually have to be written in Java. It's really an XML-based protocol, and, in fact, several of the built-in portlets in Oracle Portal are actually written in PL/SQL.
The idea behind the product is seductive. Programmers can build little portlets to display content, query databases, display graphs, etc. Then a designer or even a sophisticated business user can use Oracle Portal to assemble these portlets into dashboards and pages that display information pertinent to specific target audiences. Conceptually they're trying to give you a way to build something similar to, say, My Yahoo. A place where users can assemble a collection of portlets into pages that deliver the business intelligence tailored for individual needs.
So, what's the problem with Oracle's Portal? The big one for me is all the bugs in the content transport mechanism. This is the tool for moving content from, say, your Development portal up into the QA and then Production portals. Now you would think that kind of feature would be rock solid. I mean that's the raison d'etre for a portal, right? To display custom content to users.
Alas, every time Oracle has patched the Portal (and in a year of running the Portal, I recall at least two major patches we had to apply) it seems they introduce bugs into the transport system. And so inevitably there are additional mandatory patches you have to apply a couple months after the main patch, to patch the new problems in the content transport system.
The latest mandatory transport patch has somehow left our portal incapable of transporting certain types of content between our portals. The frustrating thing is that the content passes all the pre-flight checks built into Portal. In other words, the Portal's own analysis tools claim the content is perfectly ready and valid for transport. But when you attempt the transport, it always fails.
Amazingly, Oracle's own support organisation knows that content transport is a problem. Whenever you talk to them, they acknowledge that this is one of the buggiest areas in a product rife with bugs. I have no idea if they'll actually be able to fix this problem for us. In the end, we may have to reconstruct these pages manually in the target portal instead of trying to transport what we built from the Development portal up into the target.
The icing on the cake is that Oracle is abandoning the Portal product. Instead they're promoting a new portal-like product called WebCenter. At least they recognise there's no way to make Portal work, so chuck it and start fresh. Given their past performance with Portal though, I'd be cautious about WebCenter as well.
Unfortunately, I don't have experience with any other JSR-168 product, like Sun's Java System Portal. I can't tell you if that would be a better alternative. All I can tell you is to avoid Oracle's implementation. Save yourself the grief.




1
Vince Casarez - 08/02/08
There are a few white papers on how to construct the portal pages to separate content from the overall page structure to simply what needs to be moved from development to production. I'd recommend that you take a look at this first to simplify the overall process.
I do understand that there are reported issues and we fix them as soon as they are reported. Hence the patch sets.
We do have a set of posted Best Practices that would help in this area. They are labeled for 9iAS but they are just as relevent for any future portal release. They are here: http://download-uk.oracle.com/docs/cd/A97688_16/generic.903/bp/portal.htm
But you couldn't be further from the truth when you say we are abandoning the portal product. We have plenty of new features in the product planned as part of App Server 11g and that includes significant improvements in how pages and content get moved from development to production. I'd strongly urge you to correct this statement as it is not accurate and gives readers the wrong impression of the direction of the product.
While you might not like your experience with the product, we have over 6,000 customers in production with the product both for Intranet access as well as Extranet and Internet access. I don't want to suggest that none of them have run into bumps in the road, but it is one of the most widely deployed portal products on the market.
I'm more than willing to discuss it directly, if you'd like to contact me.
Vince Casarez
Vice President Product Management
Oracle Portal, WebCenter, & Reports
» Report offensive content
2
David Rowe - 13/02/08
Maybe your posting title should be "Avoid using Oracle Portal Transport sets at all costs"
I've been working with Oracle Portal for over 5 years.
I agree that the internal export / import transport mechanism is the product's weakest feature. Having said that, in the >= 10.1.4 release, it is much better than in earlier releases. In fact, I just successfully migrated a bunch of stuff between two 10.1.4 portals using the transport set feature only yesterday.
Oracle Portal is much more than a JSR168 portlet consumer, I would say its feature set is centred around providing end-user document and content management - which it does a pretty good job at. If all youâre using it for is a portlet consumer, then I donât understand why youâre using the transport set functionality at all. If the content is just being provided via portlets, then surely itâs the portlet code that needs to be migrated from dev -> test -> live in the same manner any J2EE app would be.
My top tips for managing Oracle Portal environments are:
1) Allow users to publish content directly into the live environment. This is how the product is designed to work. There are plenty of features to support version control, approval workflow, draft versions etc to enable end users to manage this themselves.
2) Use a traditional dev -> test -> live waterfall process for code development â ie developing portlets in Java or PL/SQL
3) Keep any custom PL/SQL code in its own schema and export / import that at a database level before using the transport set for the portal standard portal components.
4) Keep interdependencies across page groups to a minimum. For example, it is possible to publish pages from one page group as portlets and include them in pages within another page group. While this can be a useful feature, in my experience it is these cross page group dependencies that cause most trouble when using the transport sets.
5) Donât be too hung up on the traditional dev -> test -> live migration process having to be automatic. Sometimes it is just as effective to copy and paste code from one environment to another.
6) If you want to migrate a portal whole-sale from one environment to another, the best way is to use the database level repository cloning method. Take a look at metalink note #276620.1 for more details, if youâve not already seen it.
Cheers.
David
» Report offensive content
3
Loko - 24/06/08
Hi
I agree with David from A to Z !
That's right Transport sets are the weakiest stuff of Oracle Portal. But you can't ignore all the other good points of that product.
I've been using Oracle Portal for 6 years now and 10.1.4 is a true stable system (never bounced it for more than 1 year now), very user-friendly and I develop directly on our production system in hidden pages and I'm fine with it.
Loko
» Report offensive content
4
John - 28/08/08
I'm afraid I agree with Rex, I've been working with Oracle Portal for around 6 years and it is an awful tool to use. The only reason we stay with it is because we have so much code written specifically for this platform.
I agree with the last poster that it is stable (in that it rarely needs to be bounced) but its normal functionality is far too cumbersome and glitchy. Performing a big upgrade on it is bordering on the impossible and Oracle "support" are amazingly unhelpful.
(Note: I'm not referring to the Transport functionality, I'm referring to the product as a whole).
If this thing had been written by anyone smaller than Oracle no one would buy it.
» Report offensive content
5
Loris Palmerini - 09/09/08
Hi, recently I was called to work for the ministry of SME in Romania to reengeniring the Nation site based on Oracle Portal. In reality I'm a general IT consultant, open-source and linux oriented, but also certified in Windows. As CMS I know wordpress, Joomla, PHNuke etc. I also know Oracle AS, wich I teached for a public and private administration in Italy. Well, the Romania ministry was not using portal at all. I do not consider myself a Portal Developer, I'm not, and also I do not kwon java. The fact is that in around 1 months my colleges and me, around 7 person included graphics, PL-sql -developer and administration, We was able to make available a site for an entire ministry, included security, chain on publishing, user administration etc. The fact is that Oracle require a very long time to learn, but I consider portal a Very good product for a State Administration. It's true it's too much complicated for a simple Enterprise level site.
www.palmerini.net
» Report offensive content