Introducing TDGfABI – Say What?

Part of a solution that is being implemented for a current client involves implementing a custom retention framework.  Before you ask, no, Alfresco RM was not chosen.  Now that question is out of the way, testing retention is painful.

The reason why I say this, retention involves a lot of categories and moving dates.  So test data that was created last month may not be useful this month.  The test data that is created is crafted to be ingested by Bulk Importer (BFSIT).

Manually creating test data for Bulk Importer is not that difficult but it is a painfully long process when needing to create nested folders with different types of content at each folder.  After a long enough period of manually creating this data I decided to implement a quick little utilty to perform this task.

Hence, TDGfABI was born.  So what does TDGfABI stand for? Test Data Generator for Alfresco Bulk Importer.  Catchy isn’t it?

As mentioned, having sample content in this case was not good enough.  Metadata files are also required so that retention states can be applied.  The next basic requirement was to create a nested folder hierarchy with documents and metadata at the bottom (leaf) folders.  So this got me thinking that this should all be configurable.  The user configuring this should be able to decide how many folders deep to go and the number of folders wide.  This essentially allows for the creation of a well-balanced tree.  A future up will allow for creating an unbalanced folder tree.

It was also determined that although for this project generation of metadata was a requirement, it should be made configurable.  TDGfABI is aiming to be a generic test data generator.

To this point the utility has the ability to create nested folders, documents and metadata at the leaf folders.  I should also add that the same numbers of documents were being created at the leaf folders so this was generating a well-balanced tree.  This is great from Alfresco‘s point of view, but not really reflective of the real world, so generating unbalanced documents at the leaf folders was added as a configuration option.  Oh, also the number of documents generated at each leaf folder is configurable and when unbalanced mode is enabled, at least one document up to max number of documents can be created.

So, a quick recap:

1. Configurable depth and breadth of folders, creating a well-balanced tree

2. Generation of documents and metadata (optional) at the leaf folders

3. Balanced or unbalanced number of documents at the leaf folders

So then I got to thinking, well we also need the ability to test versions as well.  Seeing as BFSIT only supports major versions at the minute – @pmonks, hurry up and release the next version which supports minor versions!  Hmm, should the number of major versions be balanced or unbalanced.  It should be configurable.  So like the creation of documents, the number of versions can be configured and you can decide if these should be the same for every document or unbalanced.  Let’s not forget about metadata for versions.  This should also be configurable to allow for those occasions when you do not need metadata.

But are major versions enough seeing as @pmonks will be releasing an update soon for BFSIT.  Ok, we next thing that was added was the ability to generate major and minor versions (optional, of course).  Metadata, let’s not forget metadata for minor versions, again optional of course.  Hmmm, we should also allow for balanced or unbalanced minor versions as well, configurable of course.

So, quick recap no. 2:

1. Configurable depth and breadth of folders, creating a well-balanced tree

2. Generation of documents and metadata (optional) at the leaf folders

3. Balanced or unbalanced number of documents at the leaf folders

4. Generation of major versions and metadata (optional) for documents

5. Balanced or unbalanced number of major version documents

6. Generation of minor versions and metadata (optional) for documents

7. Balanced or unbalanced number of minor version documents

The last thing that I wanted to implement was creating documents (and versions, metadata, etc.) at any folder level.  Again in the spirit of trying to make everything configurable, the user has the choice of creating documents at every folder depth or only at the leaf folders.  Folder metadata is option as well, just in case I forgot to mention this.

So far, the most documents I have generated were around 350,000.  Each of these documents also has versions and metadata of both documents and versions.  This utility is pretty flexible at creating various structures of test data but where the real configuration power comes in is the types of document and object type metadata that can be generated.

In the next blog, I will discuss how these all work and hopefully in the not too distant future we will put some lipstick on the code to pretty it and open source it.

Integrating Workflow and Custom Forms in Alfresco

Recently, while working with a client I went through the course of understanding their business processes.  What transpired was a fairly complex process.  It started out simple:


  1. Complete form, submit to manager.
  2. Manager reviews, either rejects for more information or accepts and forwards to departments.
  3. Each department then has to complete a checklist, in which the department may only complete their assigned checklist, but be able to view other department checklists.  Each checklist has a number of questions which may invoke an action.  If the question invokes an action, then the person filling out the checklist has to select a person to assign the action to.  This action should not be sent to the selected person until a later stage in the workflow.
  4. The workflow cannot proceed until each department completes their checklist.
  5. Some more steps ….
  6. On approval, all assigned actions are sent out to the appropriate people.
  7. Some more steps ….
  8. The workflow cannot complete until all assigned actions are completed by the assigned users.  Note: this could be hundreds of actions which need to be tracked!

Pretty basic stuff to implement, isn’t it?

I may have glossed over a few details.  The main driver behind this business process is the automation of the checklists.  Each checklist may vary in the responses to the questions being asked.  For example, in one checklist the answers may be “Yes|No|N/A|Unresolved”, while aanother checklist might be “New|Modified|Delete”.  As mentioned earlier clicking on an answer to the question may in fact trigger an action to be assigned to someone.  In fact, each answer could trigger an action, and each action may differ.

In order to accomplish the creation and handling of these checklists, we implemented custom datalists, services and forms.  The datalist allowed for the creation of the various questions with the appropriate answers.  The question also allowed for setting the trigger event, if any, for the various responses.  The form presents the questions to the user and groups them based upon the grouping setting and allows for the checking of the questions.  I should note than only one response is allowed.  It is conceivable, of course that multiple responses could be allowed.

Below is an example for a checklist showing all the properties and indicating if this is a trigger action.

Workflow-Checklists within Alfresco ECM

Data-checklists-within Alfresco


To tie the datalist and forms together, custom services were created.  The services took care of assembling the questions by their grouping (it anyone) and providing these to the form.  The service would also manage tracking the answers.  As an added bonus: the services were exposed to the webscripts tier to facilitate reporting against them.

Below is an example of a checklist


So now we have sucessfully created a checklist, but we still need to incorporate it into the workflow.  Seeing as custom forms are being used, it makes this a little more challenging to wrap these up within the workflow process.  Fortunately at Armedia, we are full of creative people, itching to solve problems.  And thankfully Alfresco is implemented in a way to cater for creative people:)

To integrate the workflow and the custom forms, this was achieved by implementing an alternative way to invoke the custom workflow/forms.  A simple dashlet was created to allow users who would be creating these workflows to start them from their Dashboard

Creating a New Workflow within Alfresco


This dashlet invoked some custom code which allows the custom form and the workflow to be “glued” together.  By taking this approach it has allowed  us to  custom logic (ie. making sure everything is completed correctly) before allowing the workflow buttons to be enabled.  As part of the business process it is important that the workflow not proceed until all conditions are met.  For example, if a checklist is completed but a question has been marked as “Unresolved” then the workflow should not proceed.

Below is a sample of the javascript which is used as the wrapper around the custom workflow and custom form.

* @namespace Alfresco.module
* @class Alfresco.module.MocWrapper
(function() {
    var Dom = YAHOO.util.Dom, Event = YAHOO.util.Event, Element = YAHOO.util.Element, Bubbling = YAHOO.Bubbling, KeyListener = YAHOO.util.KeyListener

    nodeRef = "";

     * MocWrapper constructor.
     * @param htmlId {string} A unique id for this component
     * @return {Alfresco.module.MocWrapper} The Moc Wrapper  instance
     * @constructor
    Alfresco.module.MocWrapper = function(containerId, nodeRef) {, containerId, nodeRef);

        return this;

    YAHOO.extend(Alfresco.module.MocWrapper, Alfresco.module.FormWrapper, {

The downside to this approach means that the custom workflows cannot be started using the “Out of the Box” start workflow as we need to associate the custom form noderef with the workflow.  Seeing as this is version 1 of the solution, we had to leave something for the next release, to more seamlessly integrate the custom forms and workflow.

In the overview of the business process, I indicated that when completing the checklist, you may need to assign an action to someone.  Believe it or not, we have a service for this!  Each time an action is created it is associated with the checklist.  By doing this it allows the action to be tracked once it is eventually sent to the assigned user.

Below is an example of the actions that have been assigned during the checklist process

Automatic-Responsibilities assigned during Alfresco Workflow

The list of actions is visible from within the form.  Note that we track who assigned the action, who it is assigned to and what the status is.   As this is only an example, a real view would actually include many more actions.   Each column can be sorted to help the author of this workflow.  This will help in finding out which actions are completed and which ones are still in process.

Finally, to make all of these workflows available for users to access and view as a consumer a custom dashlet was created which users can place on their dashboard.  This dashlet shows all of the workflows that are currently in process and completed.


By clicking on the Workflow # the user is taken to the form where they can view all the details associated with it, like checklists, actions, documents.

There is more to this solution to talk about. However, I will leave that to future blog posts!

Annotate This!

Over the past 12 months (or maybe longer) I have been involved with 2 separate projects involved in Alfresco integration with Daeja ViewONE Pro.

Daeja ViewONE Pro is a java applet designed to allow users to apply annotations to any* document within a document management system.  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.  Let’s take a look at the two functionalities that i needed and how Daeja delivered on these needs:


I’m in eRoom, Get Me Out of Here!

[turns up amplifier, cranks up volume to 11, puts Huey Lewis and the News vinyl on record player….]
I start up Visual Studio 6.0 and settle down to some nostalgic programming with Visual Basic (VB) 6.  Ah, college memories come flooding back and strangely not many related to actual study.  I feel like I have stepped back in time – the processor has worked its speed up to 88 mph and now I am back using VB6.  I also remember learning Delphi Version 1.0 so that I could *help* a friend do their final year project. Good times.

A long time ago I posted this blog.  I had not realized it was over a year ago, but I will continue on with more information around the Export.  I chose to use VB6 as it was the easiest way to start working against eRoom’s API’s.  John and I discussed whether we should attempt to migrate against the eRoom database tables or use its API’s.  It was decided to go down the path of using the API’s which should provide more flexibility going forward.  Though I do still like the idea of migrating from the database directly.

The design of the export piece is fairly simplistic.


I don’t need anything, well, just my phone but nothing else!

This year for fun and education (although many of our friends know another way that we might refer to this…but this is a public blog…,*wink*) Chris and I took a road trip around ‘Lesser Spotted America’. The trip took us through Texas, Oklahoma, Kansas, Nebraska, South Dakota, Wyoming, Utah, Colorado, Arizona and New Mexico. One of the goals of this trip was to try and use ‘mom and pop’ establishments all the way. This proved more difficult to do as we wanted to stick to a tight budget. Another goal was to record / blog the trip whilst on the road. A good test as to how the telecommunication industry is reaching out to small town America and to ascertain what the digital divide is like between rural and urban USA.

This is probably one of the first vacation’s I have taken which did not include a laptop. A few reasons were “an extra thing to worry about when leaving it in the car”, “when camping there is no wireless” and “I could not be bothered carrying it through airport security”. I could continue but you get the point. Ultimately those were just excuses; the main reason for not taking my laptop was to see how good mobile technology has come along.

At this point let me point out a couple of things about me and mobile technology: