Daeja ViewONE Pro is a java applet designed to allow users to apply annotations to any* document.  That is just the starting point.  The applet has been developed whereby an implementer can interact with it via javascript to enhance the user experience.  The implementer can also dynamically change what controls and features are available to a user based upon the user’s role and permissions within the CMS.  I could go on but I would probability end up repeating Daeja’s website

Daeja also offers modules to extend the functionality of its offering.  Two modules that I have used are the PDF Module and the Permanent Redaction module.

The PDF module adds PDF (what else could I say?) support to Daeja ViewONE Pro.  Got a PDF which needs annotated outside of how Adobe does it?  Then this module offers that functionality.

The Permanent Redaction module came as a result of clients requiring annotations on documents but for them to be burned into the document for security purposes.  A redaction is a special annotation.  When placing a redaction onto a document it’s intended purpose is to obscure the information below.  In other words, make it unreadable, unrecognizable to anyone or anything.  This reminds me of the film Good Morning Vietnam when Adrian Cronauer if given news to read out most of the pages contain black bars.  This is redaction, and in this case permanent redaction.

This is where Daeja’s offering of the Permanent Redaction module comes in.  It can take the annotations** on the document, pass them through the Permanent Redaction Module and burn them into the document, producing either a TIFF or PDF as output.  Please do note, it is up to the client and implementer as to how and when the burning takes place and who has access to original content and who has access to burned content.

OK, enough about Daeja.  Back to the first project.  The client was not concerned about maintaining an annotations file.  They simply wanted all redactions to be burned into the document and for the document to be versioned (so as to maintain a history of redactions).  This was to support redacting PII (Personally Identifiable Information) in support of FOIA (Freedom of Information Act) requests. In this case all documents being handled were PDF.  If you remember one of the output options of Permanent Redaction was PDF.  This made it simple in that each new version was the result of burning.  This greatly simplified the model around security.

The client also wanted the burning process to be on-demand.  The burning process can be implemented in 2 ways, on-demand and background processing.

On implementing the burning process it was determined to run this in a separate Tomcat instance from Alfresco.  Not knowing how frequently documents were be worked on and knowing that the size of some of these PDF’s could in fact be over 200Mb in size offloading this to another instance seemed to be the correct way to go.  Daeja provide example code on how to implement the burning process but it is up to the implementor to customize this for the particular environment this is intended for.

This leads me nicely into Alfresco and it’s numerous API’s.  One of the many strengths of Alfresco is it’s numerous API’s to help with the flexibility of integration.  There is RESTful, Web Services, JavaScript, Java Foundation, JCR, etc. etc.  One of the common questions asked is ‘which API should I use?’.  For the Permanent Redaction integration, the implementer opted for a combo if Web Scripts and Web Services.  Web Scripts are awesome.  If the language you are using for integration can make an HTTP request then you can use Web Scripts.  Web Scripts are simple to implement, follow an MVC approach, support multiple inputs (think overloading) and support multiple outputs (need HTML, JSON or something returned?).  If the JavaScript API does not provide enough, it can be extended at the service level and exposed at the JavaScript.

Now, you may ask if they are so awesome why use Web Services as in combination with Web Scripts.  The issue for this client was the size of the PDF file.  Potentially 200Mb or more.  This is a limitation of Web Scripts in that uploading large files is a memory / performance hit.  This is the main reason Web Services was included in the combo.  As part of Web Services there is a highly optimized set of functions for streaming content into the repository.  Thankfully Alfresco also included the ability to share the authentication token between the different API’s!  To summarize for this client, Daeja ViewONE Pro is integrated into Alfresco.  When a document is opened for redaction, the applet is rendered to the browser through a custom webscript.  When the user clicks on the ‘burn’ button, the noderef of the document is sent to the Permanent Redaction instance running in the separate Tomcat instance, along with the annotation data.  The custom code running under the Permanent Redaction instance fetches the document from the repository via webscripts, applies the annotations and burns them into a new PDF.  This PDF is uploaded to the repository as a new version of the starting document.

The second project followed more of the traditional annotation model.  The client wanted the ability to annotate documents based upon content type, content format and user role and permissions.  One of the requirements was to NOT version the document.  To be honest, requirement I like.  The document itself is not changing so why constantly version it?  The way Daeja works is it maintains a separate content file with the annotations.  The initial integration  of Daeja and Alfresco was by Dr. Qu (Alfresco) and further continued by Jared Ottley (Alfresco).  This initial integration includes a basic annotation content model which associates the annotation file to the document as a child association.  Simple and effective.  The one thing that was annoying me for this client, it would be nice to version the annotations applied to the document so that there was a visual history.  Using the power of Web Scripts and Free Marker a template was created to list versions of the annotation file associated with a document, if it has one.

Some more information on Daeja is the ability to specify a server side script, cgi, etc. the call when the annotation save button is pressed.  Web Scripts are invoked via HTTP.  This means the Daeja save annotation button can invoke a custom webscript.  This webscript adds the versional aspect to the annotations file (if it is not already attached) then versions the annotation file.  This webscript also attached the Free Market template to the document to provide access to the versioned annotation files.  When clicking on a previous annotation this opens the document with the specified annotation and displays this in Daeja ViewONE Pro.  Oh, and this is in read only mode so that previous versions cannot be rewritten!

The other more interesting requirement was each annotation added to the document also needed text below this annotation to indicate who created it and when. Daeja provides this functionality as a tooltip but for compliance reasons this needed to be added to the document to be seen visually and not as a tooltip.  Unfortunately Daeja does not provide this capability (though it has now been logged as a feature request and has gotten their boffins pondering on it).  In the meantime a workaround was provided.  Again highlighting the flexibility of Daeja.  The applet provides events which can have custom coded attached to them.  In this instance when a save annotation takes place and event is triggered.  It was then possibly to have custom javascript be invoked on this event.  This is were the fun started and flash backs to maths and geometry classes happened.  It should be noted the user/date label being applied to the document was actually an annotation.  Annotations must be on the document and not fall outside the page boundaries.  This meant some calculations were needed to determine the location of the annotation and to decide if the label would be applied below or above the annotation.  The next consideration was how close to the right hand margin was the annotation.  I would like to say some complex mathematical formula was implemented but it was some simple maths that came to the rescue.  Actually this functionality is most likely cause for another blog as there are other things to consider.

This project was different to the first project but both were great learning experiences in the areas of annotation and redaction and what clients are looking for.  It has provided great information and ideas on what else could be done in the area of integration to provide even more cool integration features.

*currently Daeja supports over 300 document types!

**TIFF and PDF support a subset of annotations which can be burned into the document.

Let me tell you a story about SharePoint, Alfresco, design choices, and downloading files.

My Java-based application uses SharePoint 2010 to store files.  CMIS is the obvious tool for my app to talk to SP 2010, and in fact, CMIS and SP2010 work just fine together, as you may have gathered from my colleague Tim Lisko’s last few articles.

So it came time for me to write the download feature, thus allowing users to download the files stored in SP2010 from my application.  Chemistry makes it very easy to retrieve a file object by ID:

So I said to myself: OK, I’ll just construct a URL including the CMIS object ID, then I’ll pass that object ID straight through to my Java method.

All you guys that have used CMIS against both Alfresco and SharePoint (hi Colin!) know what’s coming next.

SP2010′s object ID looks like this: 42-512.  So my URL’s looked like this:

http://<host>/<context>/docs/download/2316/42-512

No problems here!  A nice valid URL, and my download code worked great!

So yesterday, I had an idea (actually, my boss had the idea). Let’s stand up the app against Alfresco!

Alfresco’s object IDs turn out to look like this:

workspace://SpacesStore/ecd60ff9-adbb-45fb-824d-9bc93aa61b0f

Which turned my download URL into this grim-looking thing:

http://<host>/<context>/docs/download/2316/workspace://SpacesStore/ecd60ff9-adbb-45fb-824d-9bc93aa61b0f

I’ll leave what happened when I clicked that link to your imagination (hint: it wasn’t pretty!).

Since I wanted to be up and running on Alfresco pretty quickly, I applied a short-term fix: I replace the colons and slashes in the object ID with strings that should not be part of any real object ID, and my download controller reverses the process.  Now my URLs look like this:

http://<host>/<context>/docs/download/2316/workspace-c!–s!–s!-SpacesStore-s!-ecd60ff9-adbb-45fb-824d-9bc93aa61b0f

The good: the download code works again.  The bad: I shouldn’t have to encode and decode my own download URL this way!  The ugly: as you can see, the aesthetics of the above URL leave a lot to be desired.

The long-term fix (by “long-term” I mean “by Monday”) is to not place the object ID in the URL in the first place, and use an opaque sequence-driven numeric database ID instead.  Then all my URLs will look like this, no matter what repository is in use at the moment:

http://<host>/<context>/docs/download/2316/42

Why didn’t I do this in the first place?  Well, I certainly should have.  For the most part I would never use a natural key such as the CMIS object ID in this situation.  I’m pretty sure I was trying to avoid a database lookup.  In the end I needed to do a database lookup anyway, but it never occurred to me to rethink my earlier design choices.

I’m not going into any deep personal thoughts on Alfresco ECM architecture today; rather I am going to share my thoughts on working with the Alfresco repository and the Alfresco Share UI from a software developer’s standpoint that had (almost) no prior experience with Alfresco, or ECM platforms in general.

I am relatively new to Armedia, and went headfirst into learning Alfresco ECM.  NOTE! It is generally a good idea to get a “crash-course” in a new product from a product expert before jumping headfirst into a new product, even if Alfresco has thorough documentation via their Wiki (http://wiki.alfresco.com/wiki/Main_Page).  My coworkers and I had the pleasure to have an “Alfresco Architecture Crash-Course” presentation shared with us from Dimy Jeannot who was working on another Armedia Alfresco project.

The high-level architecture is as seen below.  Any numerous UI technology, frameworks, etc are represented by the presentation layer (Alfresco Share, jQuery, EXTJS, etc).  The presentation layer can communicate with the Alfresco repository, or via Alfresco data web scripts (data layer).

High-Level Alfresco Architecture

The more detailed Alfresco architecture is seen below; we use the Alfresco Share UI as our example here.  Share, and any custom Share code you write, calls RESTful presentation and/or data web scripts.  These web scripts, in turn, communicate directly with Java Core Services exposed by Alfresco (i.e. document, search, node), or any custom services you may need to add for your application, to communicate with the Alfresco Repository.

Never assume that Alfresco and Share are running on the same server host.  For example, you should not hardcode localhost or any other hostname in your Share code.  Instead, use Share’s proxy URL when invoking a data web script (i.e. from a Share ftl, use Alfresco.constants.PROXY_URI when invoking your data web script -> Alfresco.constants.PROXY_URI + “<URL>”).

Where should you store your web scripts?  If you are concerned with data, store your web scripts in the data layer.  When your data web scripts are deployed, they are stored at webapps\<alfresco webapp context>\WEB-INF\classes\alfresco\templates\webscripts, create custom packages for your application.  Else you are concerned with presentation (such as from a Share dashlet), store your code in the presentation layer (it should then in turn call a data web script to get its data!).  When your presentation web scripts are deployed, they are stored at webapps\<share webapp context>\WEB-INF\classes\alfresco\site-webscripts, create custom packages for your application.

Detailed Alfresco Architecture

Looking back now and reading the Alfresco Wiki’s, the Alfresco architecture makes sense, I just needed guidance on putting the big picture together to start feeling comfortable with working with a new product.  If you ask me do I enjoy developing with Alfresco now, I would say yes <with smiles>.

When you work for a while in the software you get numbed to “technologies have come and gone…” occasionally though some become commodities and others trend setters. We have seen that with many products like Apache, Tomcat, Lucene, Drupal …etc that have stabilized and matured over the past years with the help of increased development from the open source realm. Wait! Did I mention the word “Open Source” and going to talk about the enterprise content management?

So without any more ado, we have Alfresco- catering to a rapidly increasing demand of the enterprise content management solutions which is built over the open source technologies such as Spring, Hibernate, and Lucene platforms. Having done years of Documentum development and several Alfresco projects of late, I think there are some interesting overlaps and differences of approach that I feel would make the developers get adapted quicker.

With the wiki site overwhelmed with Introduction, API’s, Development, Deployment and the Forums to answer all the questions regarding the issues faced during the project phase, I am here to talk purely from the developers perspective on what’s the key areas that I happen to witness the difference from the Documentum space.

The road map for my next series of blog is going to cover each of the areas mentioned below in more detailed, code abundant and developer centric approach which will answer the questions:

• Does this feature exist in Documentum or Alfresco or both?
• If yes, how different is the approach?

So with that preamble, and in no particular order, I give you my list of the key areas I got hands on and learnt how different Alfresco is:

• Aspects

Custom data model is the core for any enterprise content management solution. The use of “Aspects” as its core is the fundamental concept for content modeling in Alfresco. Although in the form D6, aspects was introduced, how different is the use and approach in Alfresco is something I will take a deep dive in my next blog.

• Web Scripts

Alfresco Web Scripts brings together the world of content repository and the web. Being a Documentum developer earlier ways of interaction with the repository have been either using DFC API’s or DQL. In Alfresco, Web Scripts provide RESTful access to content within the repository and we can build our own interface using java script. A custom move operation is implemented using the Web Scripts and the comparison of the implementation with the Documentum would be a something to be noted.

• Integration

On my last project, we had requirements for the customers to be able to permanently redact Personally Identifiable Information (PII) from existing documents stored in the repository and version the original document upon save. For various reasons, we decided to integrate the 3^rd party tool Daeja ViewOne module to provide this capability. I will discuss the topic as part of this blog series.

I started this series based on my experience implementing Alfresco projects and I invite you to share any of your experiences with any part of the road map wherein you run into interesting twists and turns? Did you drive off the road to get some help? I welcome your feedback as the blog takes its shape. See you all soon in Take 2.

It’s simple.  The new Content I/O Suite.  Armedia’s Content I/O Suite allows users to collect information from all of those billions of sources, migrate it to the centralized repository in the company, and then, if needed, deliver that information to the different web portals that may need to view the information later.  In fact, it can even send the information to multiple repositories all from the same interface.  So what if Human Resources uses Documentum, and Accounting uses Laserfiche, and some departments have their own collaborative eRoom set up, but you just merged with another company who uses SharePoint and FileNet.  What if one user could capture the information coming in from the website, or through email, or through regular snail mail, and deliver it into the appropriate system, without that one user ever having to be trained in each of those systems?  Sounds too good to be true, doesn’t it?  Check it out at http://armedia.com/products/suite/.

-Kristin Evans

A custom view is a portal that can be attached visually to a space. It is a great way to convey information about a space and it’s contents. A custom view can be attached to any space, but can be particularly effective when used on a company’s division, department or a specific project space.

The templates for Custom Views are found in:

Company Home > Data Dictionary > Presentation Templates

In this example, we are going to use a simple template called “readme.ftl” to convey information about a weekly status call for a fictitious “Phoenix” project.

The template files are <FreeMarker> templates. For more information on FreeMarker see:  http://freemarker.sourceforge.net/

For the purposes of this example, you don’t need to know anything about FreeMarker.
Use an editor of your choice and create a readme.html file. Here is what mine looks like:

<H1>Welcome to The Phoenix Project!</H1>
<p>
This is a reminder that we will have our weekly Status meeting tomorrow, <b>Wednesday April 1st, from 10:00 to 11:00 am</b>.  Please find tomorrow’s agenda, and this week’s reports (OWL, Kudos, & Events) in the <i>Weekly Meeting Materials</i> folder below.  The conference line information is listed below for all of our off-site colleagues:
<p>
<b>Call in #:  1 (888) 990-3160</b>
<br>
<b>Pass code: 39007728</b>
<p>
Thank you,
<br>
Sam Cooke
<br>
Program Assistant, Phoenix Project
<br>
(733)961-1990
<br>
sam.cooke@phoenix.com
<br>
<H4>Progressive Division of American Resource Management</H4>
<br>
The Phoenix Project
<br>
New Out of Old
<p>
<a href=”www.arm.com/phoenix”>www.arm.com/phoenix</a>

Once you are finished creating your readme.html file, import it into the space where you want the message to appear. Like so:

To select the template for your Custom View,  you will want to view the details of your space. Go up one level to the parent space and then select the View Details icon for your space. It’s the icon in the middle that looks like a sheet of paper. This is the View Details screen for our example space:

Once you are on the View Details screen, select the Modify Icon for Customer View. It’s the blue one just to the left of the trash can. Next select the readme.ftl  template like so:

Hit OK and then navigate to your space. Voila!, there is our meeting message. No need to email the information weekly any longer. Now it’s right there in Alfresco along with all the other project documentation. To update the information simply check out and update the readme.html file. When the file is checked back in, the view will automatically update with the new information.

This example is a very simple one. There are a number of presentation templates bundled with Alfresco, or you can create your own template.