Structure…

Time flies and the for the last days not much time has been spent on this project. Until today when we formally defined the project scope:

Release 1

1. Create document in Alfresco from Sugar
2. List documents in SugarCRM
3. Create realtion between a document in Alfresco and a Sugar ‘object’
4. Delete a document in Alfresco from SugarCRM
5. Check out/in documents from SugarCRM
6. Search a document stored in Alfresco from SugarCRM
7. Create SugarCRM content model
8. Alfresco space structure
9. Dashlet in Share that summarizes the current users Sugar interests
10. Dashlet in Share that retrieves information about the Sugar documents stored in Alfresco

Release 2

1. Folder structure in Alfresco reflecting the structure in SugarCRM
2. SSO between Alfesco and SugarCRM
3. Remove the IDs in the Sugar documents module
4. Create folders in Alfresco from SugarCRM
5. Create JSF component to view referenced SugarCRM docs in Alfresco Explorer

Everything might not be completely clear but the main points are:

• We are initially going to store Alfresco node-ids in SugarCRM (because the design of Sugar modules let us save a lot of time this way). The goal is to later remove this dependency and only have references from Alfresco to SugarCRM.
• The goal for release 1 is two-fold: First to be able to manage document stored in Alfresco from SugarCRM, secondly to create some sort of dashlet in Share that presents a summary of SugarCRM in the current users context.

Sugar SOAP in Share

Today I have created a client for the SugarCRM web service and written a simple Share dashlet to show some information from SugarCRM. Infact it was easier than I thought to get the applications speaking with each other but during the way I also found some issues that will need a bit more investigation. More one these further below…

Basically what I did was using Axis 1.4 to generate a Java stub from the SugarCRM wsdl (I could not use CXF because SugarCRM uses RPC bindings). Axis 1.4 was also in the Alfresco libs so I used it from there, building a jar with the SugarCRM web service api. I found a pretty good guide to the SugarCRM web services here.

After that I created a webscript in Alfresco that connected to SugarCRM using the web service api. I made it simple, just logging in and retrieving some Account information from Sugar. The webscript then rendered output like this:

Accounts from SugarCRM presented by a webscript

To view the same information in Share I wrote a site-webscript that basically called the accounts webscript in Alfresco and presented it as a dashlet. It looked like this:

One decision made here was to retrieve all information from SugarCRM through Alfresco. This means that Share will not have connector to SugarCRM but use the ‘alfresco’ connector which in turn uses the SugarCRM web services to communicate with SugarCRM. This decision was based on the following arguments:

• Alfresco needs to access SugarCRM as well, instead of having communication spread out to both Alfresco and Share it is centralized to Alfresco.
• Alfresco will act as the model for SugarCRM data and Share will render a view based on the output from the Alfresco webwscripts. I felt this was in line with the two-tier architecture of Share.

I would really appreciate comments on this!

Now on to a summary of the issues I have encountered today:

1. Though creating the web service api and make some simple calls it will require some effort to write a user friendly facade around the web service.
2. A lot of the work in Share will be about the “view”… which is not my favourite thing.
3. The user authentication between SugarCRM and Alfresco needs be thought of a bit.
4. It would really be nice to have some kind of tool to build Share extensions, or at least a description on a recommended project setup for such projects.
5. I would appreciate some more samples on Share/SURF extensions than the few ones available on the wiki.

After all, the day has been very interesting and I feel this was a good end of 2008.

What is already there…?

Before starting developing this integration we made a (quick) investigation of the current integrations between Alfresco and SugarCRM. We found two projects on the SugarForge (and none on Alfresco Forge):

1. SugarSpaces
2. Alfresco Document Management in SugarCRM

Of these the first one is still in planning stage (for how long?). The second one seems more to be a view of the Alfresco repository inside SugarCRM documents module than really using the Alfresco DM capabilities to integrate with Sugar.

Then I got a comment pointing out this integration between SugarCRM and KnowledgeTree. Though it is not Alfresco I think this is more what we are aiming for. Thanks for sharing this project, it could really be use full when building the SugarCRM extension!

Overview

Background
Today we have had some discussions on the overall project architecture. Basically we would like to make documents in the Alfresco repository available from SugarCRM. This is easy with the webscript toolbox provided by Alfresco out-of-the-box. What is more intriguing is how to identify a specific document as belonging to a specific object in SugarCRM. With “object” I mean things like “an account”, “a lead” or “a project” in Sugar-lingo. One document might be referenced from multiple objects in SugarCRM.

In SugarCRM the new functionality is contained within a module, referred to as “documents”. From within the documents module itself it should be possible to search (using Alfrescos search engine). All other functionality that the documents module provides is available from the documents sub-panel in other modules.

To communicate with the Alfresco repository, SugarCRM will use the CMIS webscript API. Communication from Alfresco to Sugar (yes, it will be there primarily to fetch metadata about Sugar modules) SOAP based web services are used.

Share and the repository will use webscripts to present SugarCRM data in Share. Typically we imagine listing the current users projects in SugarCRM and referenced documents. There will be not direct communication between Share and SugarCRM, Share will instead use services (webscripts) in Alfresco that might look-up information in SugarCRM if necessary.

A last point is authentication. This is not the primary goal to solve in this project but a very “nice-to-have” feature.

System integration

Hard vs weak references

The first consideration is whether SugarCRM needs hard references to document nodes in Alfresco. This implies that an account-object has a table keeping id-references to the documents. These ids are later used to look-up information about the document; name, version, url etc. The module-framework in SugarCRM would probably favor this option because it makes some assumption about the “child” objects (aka documents) in a module.

Hard referenced documents from SugarCRM

With weak references on the other hand SugarCRM would have no connection to the documents inside Alfresco. Instead each document will be tagged with the objects it are referred by. When SugarCRM needs to list documents for an object it simply asks Alfresco for “all objects with this tag”. In this way the systems are much more loose-coupled.

Whats next?
Tomorrow we hope to actually write some code Maybe listing documents in Alfresco from SugarCRM.

Mission statement

1. Provide a solid document repository for SugarCRM, with search, pdf-generation and metadata.
2. Build a dashlet for Alfresco Share that gets and/or posts information to SugarCRM, using the available SOAP Web Services.
3. Explore the CMIS protocol.

This blog covers our work to deliver these features: An integration between Alfresco ECM and SugarCRM.

Monday December 22 the project will start with a one day spike; a day of testing what is possible to get a feeling for the best way to implement different features. The project will not be full time and follwingly this blog will not be updated on a regular basis, but when we have something to tell.

The work with this integration is sponsored by Redpill Linpro AB, the leading Open Source provider in Scandinavia. Redpill Linpro provide consulting, training, support, application management and IT operations for the open source product ranging from infrastructure, data-bases, middleware and enterprise applications to customer specific solutions based on open source management.