So now what? You still have requirements to easily build forms and workflows and reports, but aren’t planning on a full move to another platform in the short term. Well, at a recent project where we’ve deployed Atlassian’s Confluence (also integrated with WCI), we came across this great form-builder plugin called Frevvo Live Forms.

In a word, it’s awesome – check out this quick demo (more videos here):

That got us thinking: what about using Frevvo as a replacement for Studio? We could develop the integration so that forms could be added as portlets and administered just like Studio. It’d do everything Studio can (integrate with portal security settings, custom-define forms and fields), have great new features (new data types, drag-and-drop form building, workflows), and, well, it wouldn’t suck like Studio.

So, that’s exactly what we did:

Interested in how to dump Studio and move on to a more powerful form-builder with workflows and much cooler reports? Contact us.

If so, whether you’re looking at a third-party application, open-source code base, or are planning to develop your own custom application, there are Four Tenets of Portal Integration you should consider.  Check them out!

1. User Interface.  Ideally, you’d run the application behind the portal gateway as a portlet, and have the portal add the necessary styles, headers, and footers to provide your users with a seamless experience.  But that isn’t always feasible (more on this another time).  Sometimes you have to fake the funk, and simply get your 3rd-party application to LOOK LIKE the portal, so that even though the URL changes as users navigate from the portal to the application, it’s still a seamless experience.  This blog is an example of that; you’re looking at a WordPress blog, but the other couple of pages on this site are running WebCenter Interaction - did you notice the font changes?
2. Authentication.  Again, gatewaying is the best way to ensure this happens seamlessly; when I log into the portal and navigate to another application like this blog (whether through the gateway or directly to the application’s URL), I don’t want to have to log in again.  Authentication refers to verifying that I am who I confirm I am – and I only want to confirm this once without having to maintain two accounts in two different systems.
3. Authorization.  This one’s even harder than Authentication; any out-of-the-box application will have its own authorization system, which defines who can see or do what they have privileges for once they’re authenticated.  In the portal world, this means that I as an adminstrator of the portal should be able to configure the security of the application the same way – and with the same groups – as I do the portal itself.
4. Search.  Back to user experience:  one of the biggest benfits of the portal is a consistent user experience.  And one of the biggest unifying services (aside from those mentioned above) is Search.  When I’m in the portal and do a search, I want to search not only the objects within the portal – including communities, pages, portlets, and the Knowledge Directory – I want those results to be integrated with the results from my external application.

So there you have it; if you get all four of these integration points knocked, you can officially consider your application “fully integrated” with the portal.  Notice there’s a huge amount of leeway here (such as “gatewaying is not necessarily mandatory”); following on the promise of the portal itself, “Integration” is all about a consistent user experience, regardless of back-end technology being used.  Your users shouldn’t have to know what back-end applications they’re actually using; it should all be completely seamless.