Category: Portal

Thoughts on portal solutions.

Drupal-Alfresco Integration and Alfresco’s Move to the Front-End

Via Dries Buytaert, Rob Purdie is announcing the relaunch of Amnesty International‘s site. The new site was built using Drupal and Alfresco.

It is interesting to see how many people have commented on both posts who are craving more information about Drupal and Alfresco integration and it is no wonder. As I mentioned last year in this post, Optaros sees the two offerings as highly complementary–they aren’t (yet) competitors.

We do a lot of implementations in both Drupal and Alfresco. We think PHP plus Alfresco, or in this case, Drupal plus Alfresco is a great combination. Why? Using PHP and Alfresco together is the best-of-both-worlds: You get the speed of development that PHP brings plus the strength of an
open, enterprise repository on the back-end. In Drupal’s case, specifically, add to that the
availability of thousands of pre-built modules as well as a true site (presentation) framework which is something Alfresco currently lacks (more on that in a second). The interface between the two is best facilitated by Alfresco’s REST-based web script framework which is itself based on lightweight coding tools (JavaScript and FreeMarker).

If you’ve been following this blog and the Alfresco Community Conferences, you know that Alfresco is making a move to the front-end. Clearly, Alfresco sees the lack of a Drupal-like front-end as a short-coming, and they are working hard to address this in their coming releases. Here are examples of what’s coming down the pike that may ultimately position Alfresco more directly against Drupal in the future:

  • Web scripts are being split out from the repository process. In the Community head it is now possible to run web scripts in a process separate from that of the core Alfresco repository process. And web scripts running in that standalone process can remotely invoke web scripts running in the Alfresco repository, even if the two are running on separate physical hosts. This will likely form the foundation of Alfresco’s dynamic web site approach: Web scripts running outside of the context of Alfresco, in a plain old servlet container, say, can take advantage of the web script framework, even if they never make a single call to Alfresco.
  • Alfresco is building a WYSIWYG, browser-based site builder tool. The Alfresco Dynamic Website (ADW) will allow you to assemble web sites and web pages by selecting modules (built with web scripts) from a module library and arranging them on the page.
  • Alfresco is moving their web clients from JSF to web script-based web sites. The new Alfresco client will be based on web scripts with the eventual goal being to build it and manage it as if it were any other normal, dynamic web site. The client will be a reference site which you can use to build your own dynamic sites.
  • Alfresco is trying to generate developer excitement around web scripts. Alfresco’s push in the developer community to get people excited about web scripts is no coincidence. If they can get the community to help develop a compelling library of web script-based modules, and if they can create a productive front-end development framework that can plug in those modules, Alfresco will be much more attractive to clients who benefit from a front-end presentation framework and pre-built components than it is today.
  • Alfresco is marketing heavily around community and Enterprise 2.0. As you may have seen at the Community Conference and other Meet-ups, Alfresco is driving towards more community, social networking, and general “Enterprise 2.0” features and functionality. This is usually mentioned in the context of being a Sharepoint Killer but it could also mean a blurring of the differences between Drupal and Alfresco as well.

I’m not saying that when the 3.0 release of Alfresco comes out it is going to be on par with Drupal. But I do think it is interesting to watch what’s happening as Drupal and PHP solutions look for more robust back-ends while Alfresco moves toward better front-end site development and module frameworks.

Running Alfresco web scripts as Liferay portlets

I’ve seen a lot of Liferay and Alfresco forum posts from people having trouble getting Alfresco running within a Liferay portal. Once that’s done, people usually want to invoke Alfresco web scripts as portlets without requiring a separate single sign-on (SSO) infrastructure. Some people have pointed to the Alfresco wiki (Deploying 2.1 WAR Liferay 4.3). That is a helpful reference but it isn’t the full story. Here are some notes that may help.

1. Download the Liferay 4.3.6 + Tomcat 5.5 JDK5 bundle. I had mixed results with the latest release 4.4.2. You may be tempted to try to download the WAR-only distribution and configure it in your existing Tomcat instance. In this case, save yourself the time and headache and get the bundle. Fool with the WAR distribution later.

2. Unpack the Liferay distribution and fire it up. Make sure you can log in as the test@liferay.com (password: test) user to validate that all is well with the Liferay install.

2a. Create a test user. (“Create Account” on the Liferay login screen). Remember the email address. This will matter shortly. For this discussion I’ll assume Foo User with a screen name of fuser and an email address of fuser@foo.com. Make sure you create a home directory. In this example, we’ll call it “fuser”.

2b. Verify that you can log in as your test user.

3. Shut down the server.

4. Download Alfresco 2.1.2 Enterprise, WAR only. Alfresco 2.1.1 has a known issue (AWC-1686) with the way authentication is handled for web scripts in the context of Liferay so make sure you are using 2.1.2.

5. Expand the Alfresco 2.1.2 WAR into the Tomcat webapps/alfresco directory (which you’ll have to create the first time). If you are tweaking the install (such as pointing to a specific MySQL database, using something other than MySQL, pointing to a different data directory, etc.) make sure you have copied your good set of extensions into Tomcat’s shared/classes/alfresco/extension directory.

6. Copy the MySQL connector into Tomcat’s common/lib directory.

7. Start Tomcat. When it comes up, you’ll have Liferay running and you’ll have Alfresco running, but Liferay doesn’t yet know about Alfresco. Verify that you can log in to Alfresco as admin.

7a. While you are here, create a test user account. You need to create a user account that has an email address that matches the test user account you created in Liferay. In this example you created Foo User with a screen name of fuser and an email address of fuser@foo.com so you need to create an Alfresco user with the same settings. You’ll log in to Alfresco as fuser. You’ll log in to Liferay as fuser@foo.com.

7b. Verify that you can log in to Alfresco as fuser.

8. Shut down Tomcat.

9. Now you need to configure Alfresco as a Liferay plug-in. This involves adding four files to Alfresco’s WEB-INF directory: liferay-display.xml, liferay-plugin-package.xml, liferay-portlet.xml, and portlet.xml. Why aren’t these available in the Alfresco source or on the wiki? Apparently someone tried to address this at some point because there is a link on the wiki but it is broken. Until that’s addressed, I’ve put them here.

10. Remove the portlet-api-lib.jar file from Alfresco’s WEB-INF/lib directory.

11. Re-package alfresco.war. It is now ready to hand over to Liferay.

12. Start Tomcat.

13. Find your Liferay deploy directory. If you are running out-of-the-box on Linux, Liferay’s “deploy” directory is called liferay/deploy and it resides in the home directory of the user who started Tomcat. I’m running it as root so my Liferay deploy directory is /root/liferay/deploy.

14. Copy the alfresco.war you just created into the deploy directory. Watch the log. You should see Liferay working on the WAR. He’s finding the plug-in config files and essentially deploying the Alfresco portlets.

15. Now log in to Liferay using the Liferay admin account (test@liferay.com). Go to a page, then use the global navigation dropdown to select “Add Content”. The list of portlets should appear and you should see the “Alfresco” category. If you don’t, look at the log because something is amiss. Add the My Spaces portlet to the page. You may see an error at this point but ignore it. The problem is you probably don’t have a user in Alfresco that has an email address of “test@liferay.com”, which is the currently-logged in user.

16. Log out.

17. Log in as your test user that exists in both Alfresco and Liferay (fuser@foo.com).

18. Go to the page. You should see the “My Spaces” portlet. You should be able to upload content, create spaces, etc.

Exposing your own web scripts as portlets

All Alfresco web scripts are automatically exposed as JSR-168 portlets, including the ones you create. To add your web scripts as portlets, first make sure you have authentication set to “user” and transaction set to “required” in your web script’s descriptor. Then, update portlet.xml, liferay-portlet.xml, and liferay-display.xml. Follow the pattern that’s in those files already and you’ll be fine. For example, if you deploy the Hello World web script from my web script tutorial, you need to add a new portlet to portlet.xml with a “scriptUrl” like: /alfresco/168s/someco/helloworld?name=jeff. Then you update liferay-portlet.xml and liferay-display.xml with the new portlet name or portlet ID.

Single sign-on with no single sign-on?

The web script runtime has a JSR-168 authenticator. So when your web scripts get invoked by the portlet, the current credentials are passed in. That’s why your web script can run without requiring an additional sign in. Prior to this being put in place, people had to implement Yale CAS (or an equivalent) to get SSO between Liferay and Alfresco web scripts.

What’s not covered in these instructions is that you’ll probably want to (1) configure both Alfresco and Liferay to authenticate against LDAP and (2) change the configuration of either Alfresco or Liferay to use the same credential (either username or email address) for both systems so that if you do have users logging in to both, they don’t have to remember that one requires the full email address but the other doesn’t.

Troubleshooting

If you see one of the Alfresco portlets displaying “Data is not currently available” or somesuch, try hitting
Alfresco in another tab. Log in, then log out. Then go back to the
portal and open the page again. It should work now. I’m not sure what’s going on there. I think it may have to do with me switching back-and-forth between Liferay instances (4.3.2 versus 4.4.2) so maybe you won’t see it.

Open issues

You may see an error like this:

21:22:15,965 WARN [BaseDeployer:1038] Unable to format /usr/local/bin/liferay-4.3.6/temp/20080408212212978/WEB-INF/faces-config-jbpm.xml: Error on line 5 of document file:///usr/local/bin/liferay-4.3.6/temp/20080408212212978/WEB-INF/faces-config-jbpm.xml : A ‘)’ is required in the declaration of element type “application”. Nested exception: A ‘)’ is required in the declaration of element type “application”.

I haven’t chased that down yet. I’ll update this post with a comment when I find out. I’m sure fixing that will also fix the problem that you’ll see if you try to start an advanced workflow from a piece of content displayed in the My Spaces portlet.

I was also seeing an error when trying to use the “Add Content” link in the straight Alfresco client. I think it is JSF-related. Again, I’ll update this post with a comment when it is resolved (or when I find a Jira ticket).

JBoss World is coming up

JBoss World is coming up next month. It’s in Orlando February 13th – 15th. If you are interested in JBoss Portal, specifically, Thomas Heute lets you in on the Portal-specific sessions here.

Much to my wife’s chagrin (“You’re going to a conference on Valentine’s Day?!”) I’ll be at the conference. I’m looking forward to soaking up some JBoss goodness.

Go go gadget: JBoss Portal adds Google Gadget capability

InfoWorld says the latest version of JBoss Portal allows you to drop in Google Gadgets. I haven’t tried it out yet but I like the concept. The JBoss Portal Portlet Catalog is rather sparse (as is the collection of open source JSR-168 portlets in general as pointed out by Christopher Laprun) so adding to the collection of what’s effectively available out-of-the-box is a Good Thing.

I suppose people using JBoss Portal for consumer facing sites will make the most use of the Google Gadget capability at first. I doubt internal-facing enterprise portals have much use for the Bart Simpson Quote of the Day gadget. From an enterprise perspective, what we’ll probably see is the same thing Laprun points out with regard to JSR-168 portlets–companies will leverage the Google Gadget API to develop their own internal gadgets, but may not be able (or willing) to make them freely available to the community.

Exposing reports & analytics through portal gets easier

CBR Online is reporting that Liferay, an open source portal, and Pentaho, an open source business intelligence platform, are working on better integration between the two products. This is good news to Enterprise clients who often want to expose BI data such as reports and dashboards to users across the company via the web. Tighter integration through JSR-168 will make it easier to personalize and deliver Pentaho portlets through Liferay.

Mixing BI, or quantitative data and technologies, with ECM, which is more qualitative, can be powerful. Here are a couple of examples. Clients sometimes ask about reporting capabilities in Alfresco. Alfresco has pretty granular auditing capabilities. When you enable it, events get written into a set of auditing tables in your relational database. Once that happens, it’s simply a matter of using a reporting or BI tool, like Pentaho, to create all the reports you might need, and you could deliver them via your Liferay portal.

Thinking more strategically, maybe you want to monitor certain analytical aspects of your business and convene a response team if any metrics fall below a certain level. You could do that with a Liferay-Pentaho-Alfresco solution. Pentaho could generate the reports and fire of an event when a certain metric is reached. That event triggers an Alfresco workflow which routes a snapshot of the report through a workflow or creates a discussion thread in the Alfresco repository, setting permissions appropriately and notifying the members of the response team who can then use Pentaho’s analytic tools to slice-and-dice the data to their heart’s content.

Gartner Portals, Content, and Collaboration Conference: Day 2 Notes

Portals, SOA, and Mashups

Portals have worked well in some enterprises, but there are problems:

  • Heavyweight technology requires specialized skills
  • Over-engineered platforms and protocols are complex and expensive

Portals will likely be an entry point for enterprise mash-ups

Interesting tidbit: Systems reflect the structure of the organizations that build them. If you have a dysfunctional organization, it is likely your systems will be too. Building the “perfect” system doesn’t help. Over time, the system will degrade to match the structure of the organization. (Melvin Conway, 1968).

I’ve definitely seen evidence of this at clients. A really obvious example is in workflow-centric solutions. Companies rarely take the time to streamline and cleanup processes the way they need to before formalizing the processes in automated workflows (“Implementing the new system is enough change. Let’s automate the way we do it now to encourage user adoption. We’ll come back later and tweak the business processes.”). So what you end up with is a system that works exactly like the current business process, warts and all.

More info on Conway’s Law at http://en.wikipedia.org/wiki/Conway’s_Law

Portal of the Future

More discussion about the differences between Digital Natives (the generation of workers entering the workplace today) and Digital Immigrants (the generation of workers who’ve had to adapt to digital technology). Where this relates to the “Portal of the Future” is primarily about expectations regarding how we interact with relevant data. The nature of this interaction has to be client-independent, device-independent, context-aware, and truly-mobile.

Trends:

  • Portal vendors will decompose products into services
  • Portal as entry point for enterprise mash-ups
  • Portals sharing data (due to most enterprises having multiple portals deployed)

Sites to check out for good examples of alternatives models of content aggregation:

These are basically the next generation of the old “My” portals.

Portal interoperability touchpoints:

  • Portlets (Standards exist here, but not for the rest)
  • User Profiles
  • Directory
  • Security
  • Metadata

Mash-up tools/APIs:

Seven Key Strategies for Combining Portal & CM

Probably a better title for this presentation would have been, “Seven high-level ideas that are related to portals, content, and collaboration”. It didn’t really discuss the combination of the two at any level of detail.

1. Build a foundation for a high-performance workplace

  • Provide a flexible environment to support the non-routine tasks people do every day. Key technologies: Collaboration and Content Management (Basic Content Services).
  • Focus on non-routine tasks and decision-making enablement
  • Content and collaboration are “birthright” technologies for your employees

2. Use the right tool for the right task

  • The problem is that email is being used to create/share content
  • Use BCS as a way to migrate people away from email

3. Take a process view

  • If you want to really get a handle on collaboration and content you need to start by looking at the processes in which collaboration plays a part or which involve content.
  • Gartner talked about two types of content/collaboration apps using two acronyms: CEVA & WEBA. Hopefully, these new acronyms won’t out-live the conference, but just in case they do…
  • CEVA stands for Content-Enabled Verticalized Applications. This is an application that is focused on a core business process. For these apps you should be able to provide templates, workflows, and automate some or all of the business process. (A lot of the workflow apps I’ve built over the years have been CEVA’s. Who knew?)
  • WEBA stands for Workplace-Enhanced Business Applications. These are apps that our really outside of your core business process. For these you need to define policies, communicate best practices, provide support, and examples.

4. Intranet & repository consolidation

  • The path of least resistance is to freeze your legacy content and create all new content in the new repository. The legacy repositories will dry up and go away over time.
  • The other alternative is migration, which can be costly, but at least gives you the chance to clean up.
  • The route you choose is really about cost.

5. B2C web presence

  • Most enterprises will need both Portal and Content Management
  • Each has specific areas of functionality they are responsible for, but there is some overlap in the gray area between the two.
  • For some reason, the speaker went deep into eforms at this point which I found strange as the bullet is about B2C web presence. I don’t downplay eforms as important, particularly as a low-hanging fruit for most enterprises, but it seemed like a non-sequitur.

6. Customer-centric communication

  • Nothing significant to note for this one.

7. SOA framework for the assembly of services

  • Again, kind of fizzling out at this point but the speaker did point out that your metadata approach can impact your ability to provide meaningful integration between or federation of your repositories. Enterprise-wide efforts to define and update an enterprise-wide data model help but can be costly.

Usability & Productivity: Are We There Yet? (Jakob Nielsen)

This was my first time hearing Nielsen speak. I found him to be insightful, engaging, and entertaining. Catch him when you can.

Usability is not just about visual design–it must also include information architecture and interaction design. You cannot just come in after the coding is done and slap on a pretty interface.

Everyone can do (and should be doing) usability testing

  • Doesn’t require a lot of fancy equipment
    • Closed door
    • Web cam
    • Screen capture
  • Plan on roughly five users for each type of user in the system. If overlap exists across user types, you can get by with less than five.
  • Keep it simple
  • Make it iterative. Don’t make it a big production. Maybe test one user type on one iteration and another on the next.

Of award-winning intranets, the following are the usability methods employed by those teams:

  • User testing (#1 method)
  • Survey
  • Card sorting
  • User test of prototype or wireframe
  • Heuristic evaluation
  • Field studies
  • Accessibility testing

The Web 2.0 sites/technologies getting covered the most by the media are not necessarily what you should be doing in your projects

  • The ugly truth about user-contributed content: 90% of the users contribute very little, 9% contribute a moderate amount, and only 1% are the hardcore, heavy users
  • Get back to basics
  • Search
  • Task-oriented navigation
  • Learn how to write for the web
  • People scan when they read online. Writers have to adapt to that style.
  • Use HTML pages instead of PDF. PDF versions of online manuals on a corporate intranet could be costing you “hundreds of thousands of dollars” in productivity loss
  • Tiny text with low contrast is really hard for people over 45 years old to read

“Banner blindness” is a strong phenomenon

  • Showed some eye tracking test graphics in which users were not giving a single glance to any of the ads
  • Non-ad content that simply *looks* like an ad gets skipped
  • Environments where a user should know there are no ads (like an intranet) are not immune to this effect

Roller leaves the nest

According to CMS Wire, Java-based blog server Roller has graduated from the Apache incubator. At Optaros, we’re doing some work for a client right now that involves implementing Roller as one component of the company’s Enterprise 2.0 initiative. Their Enterprise 2.0 stack includes Liferay for portal/presentation services, Alfresco for portal content, documement, and web content management, Roller for internal and public-facing blogs, and Confluence for internal wiki.

So far, Roller has been relatively straightforward to integrate with Liferay, but in the initial phase we’re doing very light integration. It essentially involves skinning the Roller UI so that the experience will be fairly seamless as portal users move from the RSS portlet to Roller (for example, when they comment on a blog post). In a later phase we hope to implement a much tighter integration, perhaps through Roller-specific Liferay portlets.

Links to info on SharePoint Server 2007

Many in the content management industry are curious to see exactly what is going to be included as part of Microsoft Office SharePoint Server 2007. CMSWire has a few links to some Microsoft resources in this recent post.

At Navigator we had at least one client that was betting heavily on the new release. They believed Microsoft’s promise that it will include web content management, records management, workflow and better security. As more and more people get experience with Beta 2 we should start to find out how well they’re going to be able to keep that promise.

In the meantime, if you’re ready to do an MCMS 2002-to-Alfresco conversion, just let me know.

Alfresco promises better portal integration

Recently, John Newton sent me an email thanking me for my post on Alfresco’s JBoss Portal integration. He said they are looking at providing additional Alfresco portlets in up-coming releases. Being able to use Alfresco as a replacement JCR repository for JBoss Portal is also in the works. Apparently the Liferay-Alfresco bundle is configured in this way but I haven’t had a chance to take a peek yet.