Portals and Integrating Other Applications

After the SSO question, probably one of the most commonly asked questions is, “How do I surface an application or applications on the portal?”  It’s an interesting question because there are a lot of options and it all comes down to how deeply you want to integrate it and how much you want to use Portal services like personalization and security with it.

Before I dive too deeply, I want to highlight a response to this by Marshall Lamb, an IBM Software Engineer.  He gives a WebSphere Portal explanation that’s valid for most portal technologies.

Application Integration Techniques

Revolutionize Your Business With Generative AI

From product design and software development to virtual agents, content creation, and reporting, GenAI is transforming business. Our AI experts help you unlock GenAI’s full potential and drive growth.

Let’s Get Started

Application Integration Techniques – Decision Trees

I’m probably going to repeat more than a little of what Marshall says on the subject but that’s ok because we’ve been giving out the same answers for a while.  Before you make a decision on what tool or tools you are going to use, you need to get some things prepped.

1. List the applications that  need to be surfaced on the portal or have some sort of linkage with the portal
2. Figure out your SSO strategy.  A portal can help with this but if you have a lot of applications, you probably want a true SSO solution like TAM, OAM, Siteminder, or OpenSSO
3. For each application, figure out what kind of user experience you need.  Is a disjointed experience where you just link to it ok?  Do you need the same look and feel?  Do you need to have the application personalized?   Is the current UI ok or is it too cumbersome?  Do you really only need a small portion of the functionality on the portal and the rest can be in the larger web application?
4. Figure out what kind of resources you can put to this.  The general rule of thumb is that the more consistent the user experience and the more personalized the application, the more effort it takes.  No company has the time and resources to do it all.   Prioritize what’s most important.

Now once you’ve answered some of those questions, then you can move on to the options you have.   Keep in mind one best practice.  The portal is an aggregation technology.  It’s not meant to replace massive applications.  It can be a development platform but it’s not best suited for it. When you take a large existing application, you usually want to follow the 80/20 rule.  80% of the functionality should remain in the original application. 20% of the functionality could be surfaced on the portal natively.  For example, If you have a time and expense module SAP, you may want to surface the timesheet in the portal and link to it from the home page of an employee portal.    Here’s why: The orginal UI is clunky. Getting to the time sheet takes a lot of clicks and wastes time.  If you pull it into the portal, you’ve just saved a lot of people time……………and time is money.

When it comes to surfacing applications on the portal, here are some of the most common approaches:

1. Build a native portal application that takes advantage of all portal services. This is by far the best user experience but also the most costly in development time.
2. iFrame it.  You just point to it and go.  You still have to figure out SSO for it. You will most likely need to strip out some higher level navigation and match the style sheets if you don’t want a hugely jarring experience.  We’ve done it before and very successfully when you are willing to make some minor mods to the web app you are surfacing on the portal.
3. Clip it with some sort of web clipper app. Most portals have something like this.  It’s my least favorite approach.  It’s the most likely to break.  It also give a pretty jarring user experience because colors, styles, fonts, etc don’t match. However, it’s a really fast way to get something in portal.
4. If it exists as a gadget or widget then pull it in.  Most portals have some sort of portlet to do this.  If they don’t, these things are most likely a RESTful service call and that’s really easy to call from a simple portlet.
5. Build it as a Web Services Remote Portlet and put it on an app server somewhere. Microsoft, IBM, Oracle/BEA, and a bunch of others support this standard.  It still means building it to a standard so we are talking development but you can put the processing off the portal.  WSRP 2.0 is out but it’s still not heavily used so count on running into issues.
6. Link to it and make sure SSO works.   It’s simple and usually the first thing that people do on a portal.  The step after that is to create a small portlet that gives some information and then links to it.  For example, build an email portlet that says, “You have 15 new messages and 3 calendar items today”  you gave some quick value and then the user can dig deeper by clicking on the link.
7. This last option I’ve only seen on WebSphere Portal but I like it.  It’s called Web App Integrator (WAI).  WAI is really just a logical extension of RESTful services.  The idea is that portal provides some pretty cool services and applications.  Why do you need to be in the portal to take advantage of them.  Why can’t you use them in another web site.  What IBM did was to create RESTful services for a lot of these things.  You can inject portal navigation, portlets, and a host of other things.  If you manage a bunch of different sites and would like to create an easy to configure taxonomy that can be used everywhere then this is your site. If you have one simple portlet that you want people to use even in an html only web site, then WAI will help.

So there are your options.   It’s a fairly subjective process and one that takes some forethought as you decide what and how you will integrate portal to other applications.