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.

SugarCRM intro

So…what has happened on the SugarCRM side then?

In SugarCRM we have just started off by adding a simple module called AlfrescoDocs.

The issues we have discussed during the day has mainly been about how to store data in Sugar. Should there be any data in Sugar that is mapped to Alfresco or should SugarCRM only be a view of Alfresco’s documents?

What we are hoping for is to make it possible to do this as dynamic as possible and not store anything in SugarCRM. What we mean by that is that there will not be an alfrescodocs-table in the database referring to the documents in alfresco, instead all documents will be picked up in runtime. So when entering the Alfresco Docs ListView a call will be made to Alfresco through REST and the documents metadata will be added to the list in Sugar.
The only place where we really need tables is for the subpanels (relationship tables), so they will be created and contain an id of the document in Alfresco.

So this is the plan anyway. We know that it would be much easier to have a database table and store the Alfresco documents id’s and then add some logic hooks to retrieve all the information needed….but hey, why do it the easy way …if the time runs out or we find out that it is better to use a database table in Sugar then we will do that, but for now the plan is to not use a database table.

Today is a historic day for me since this is my first blog-post ever. I guess there will be some moore….

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.