Technical Overview of the Alfresco / Jive Toolkit

Recently I transitioned from my long-standing role leading Alfresco’s Professional Services team to being the in-house technologist for the Business Development team, and one of my first tasks in the new role has been to work on an integration between Alfresco and Jive Engage. This work is being done in partnership with SolutionSet (a partner of both Alfresco and Jive), and I wanted to discuss some of the technical design work that has gone into the Toolkit, ahead of its availability (which will be soon after the Jive 5.0 launch – the version of Jive that the Toolkit is targeting).

Functional Overview, aka “What will it do?”

As announced at Gartner’s Portals, Collaboration & Content Summit this week, the integration (known as the “Jive Toolkit”) is a set of pre-built components that allows Jive to store documents in Alfresco while still offering all of the same social features as “native” Jive documents (commenting, rating, discussions, etc.). While not yet all-encompassing – Jive’s “social” content cannot yet be stored or managed within Alfresco – the Toolkit will provide a foundational level of document-centric integration, allowing implementers to focus on more use-case specific integrations as required (hence the positioning as a “toolkit”, rather than a fully fledged solution).

More specifically, the initial version of the Toolkit will allow users of Alfresco and/or Jive to create “managed” documents in any of the following 3 ways:

  1. By uploading a document to Alfresco, using the Jive UI.
  2. By “publishing” an existing document from Alfresco to Jive, using Alfresco’s Share UI.
  3. By “linking” an existing document stored in Alfresco to Jive, using the Jive UI.

In all 3 cases, the result is the same: the document is visible and accessible via the Jive UI in exactly the same way as any “native” document, but the content of the document is stored and managed in Alfresco only. Jive will maintain some metadata about the document – for example the document’s filename and a pointer to the document in Alfresco – but it will not store the binary content of the document. This approach ensures that the document is a first class citizen in both the Alfresco and Jive worlds, while minimising the risk of synchronisation issues between the two systems.

Here are some screenshots that demonstrate uploading a document to Alfresco using the Jive UI:

Alfresco managedocument step1

Step 1 – Navigating to a community in Jive

Alfresco managedocument step2

Step 2 – Managing a document

Alfresco managedocument step3

Step 3 – Select a file to upload

Alfresco managedocument step4

Step 4 – Select the target space in Alfresco

Alfresco managedocument step5alf

Document details (Alfresco)

Alfresco managedocument step5

Document details (Jive)

Technical Details, aka “Rubber, meet road”

As mentioned above, there are a variety of ways that the initial “linkage” of a document between Alfresco and Jive can be achieved, however all 3 creation mechanisms produce the same end state: Alfresco has the document in its entirety (including the filename, content, etc.) while Jive has a “proxy object” (a structured data-only object that has the filename and a pointer to the document in Alfresco, but does not have the actual binary content).

This means that all downstream events (updates, metadata modifications, deletes) can be handled the same way, irrespective of how the content was linked between the two systems in the first place – a major simplification in the logic for those downstream events.

Integration Mechanism, aka “CMIS, by any other name would smell as sweet…”

Another nice characteristic of this approach is that the calls from Jive to Alfresco (to create content, update and retrieve it) can be accomplished using the CMIS API. This has several benefits, from reduced development effort in the Toolkit itself (due to the ready availability of client-side CMIS libraries), to the potential for portability to other CMIS compliant repositories in the future.

One important thing to note is that the Alfresco-to-Jive API calls are not standards-based – they make use of Jive’s proprietary REST API. Jive does not expose a standards-based API (indeed, no suitable standard exists for social business systems yet), and CMIS doesn’t provide any kind of callback mechanism for clients to be notified when repository events of interest occur (i.e. a mechanism equivalent to Alfresco’s Component Policies).

Tricky Bits, aka “The Devil is in the Details”

As with any integration between complex enterprise applications, there is some trickery in some parts of the integration, and it’s critical to understand these if you’re evaluating the Jive Toolkit.

Deletion

The first piece of trickery involves deletion of the content, specifically deletion in Alfresco. Because Jive maintains a pointer to the document in Alfresco (specifically, the “cmis:id”), rather than the content itself, if the document is deleted in Alfresco without Jive being notified, attempts within Jive to retrieve that content will fail. To prevent this, the Toolkit is currently designed to veto deletes in Alfresco if the document has been socialised in Jive. To delete a document, it will first need to be deleted in Jive at which point it can be deleted from Alfresco too. The reason the Toolkit doesn’t simply synchronise deletes between Jive and Alfresco is that there are common use cases where the document may be removed from Jive, but needs to be retained in Alfresco – replicating deletes between the two systems would have ruled out these use cases.

Full Text Indexing

The second item of trickery revolves around full text indexing of the document in Jive. To accomplish this, Jive will retain a copy of the content of the document just long enough to index it into Jive’s full text index, and once indexing is complete the content of the document will be removed from Jive. As you’d expect, Alfresco will also notify Jive of any updates to the document, so that the content can be re-indexed on the Jive side.

Access Control and Identity

Access control to the documents is also tricky, primarily because the Alfresco and Jive ACL models differ in their level of granularity. Jive’s access control is primarily Community-centric (i.e. defined and enforced at the level of the Community), while Alfresco has a fine grained, per-node (file or folder) ACL mechanism. In this first release, the Toolkit will initially create the document in both systems in such a way that the ACLs are in sync, but modification of those ACLs in either system will not be replicated to the other system. The upshot is that direct manipulation of the document’s ACLs in Alfresco may cause errors in Jive (i.e. users who can see the document in the Jive UI, but are unable to download it).

Furthermore, in order for Alfresco and Jive to agree on the principal set, the initial version of the Toolkit assumes that both Alfresco and Jive are configured to use the same LDAP repository for user identity and authentication. During the design sessions it was felt that this was likely to be a requirement for an integrated solution anyway and hence wouldn’t be an impediment, but we’re keen to have that assumption validated as broadly as possible.

In Conclusion

So there you have it – a whirlwind tour of the upcoming Jive Toolkit! As a v1.0 there are some more sophisticated use cases that the Toolkit doesn’t address yet, including multi-document / library based integration, and capture of Jive’s social content (discussions, ratings, wiki pages, etc.) in Alfresco. The intention with the Toolkit is to initially provide Alfresco+Jive Systems Integrators (such as SolutionSet) with a small but solid base on which such extensions could be built, and if/when common requirements are identified for these more sophisticated use cases they can be rolled back into the Toolkit.

We’re keen to hear your feedback and look forward to your participation in the project!

Tags: , ,

  • MilesD

    Nice first step. But wer’e really struggling with control/capture of the social content? Any timeframe/roadmap for the next versions?

    Cheers

  • http://www.sydneyclimbing.com/ Peter Monks

    MilesD, I’d be keen to hear more about your specific use case for capturing the social content into Alfresco.

    The background is that we reviewed several different sets of end user requirements but didn’t really identify a common use case (unlike binary documents, where the use case was relatively clear) – one use case was around synchronisation of social content between Alfresco and Jive, another involved periodic snapshot of social content into Alfresco, and a third involved explicit ‘declaration’ of social content to Alfresco (at which point it would be frozen in Jive).

    Because of this variety, we elected to push social content out of scope for v1.0 of the toolkit and wait for further feedback from the customer community to try to identify a common use case around formal management of social content (hence the request to hear more detail about what you require).

  • http://www.synapps-solutions.com TimN

    Hi Peter,

    We’re embarking on the Jive/Alfresco journey (as a Systems Integrator). With one particular client (financial services) there will be information contained in the social content that will influence business decisions and will therefore need to be retained as a record (due to the regulated nature of their business). I do not believe that this client, and industry vertical, are alone in this requirement. As the use of social business platforms such as Jive increases and becomes a more integral part of day-to-day working, valuable business information will be generated within social content (e.g. micro-blogging). As the Jive platform is not designed as a content/records management solution, there needs to be a mechanism to capture social content into solutions such as Alfresco.

    The use case around documents is highly valid – a case study of Jive’s is BUPA who have a 7,000 user deployment of Jive. Out of all the content types being generated, binary documents have, by far, grown the greatest thereby illustrating that users still think/work around “documents” so effective management of those types is necessary.

    For me the other interesting area, which may be a touch off-topic, concerns use-cases involving Share and Jive which may require the synchronisation of social content. In fact, as and when (if) Share introduces more “social” features then one may question the validity of a Jive/Alfresco solution and look to use either in isolation. As I am a content management purist, I would want the ability to manage any unstructured content in a CMS platform, therefore social business capabilities implemented directly on a CMS (e.g. Share/Alfresco) would be preferred over a standalone social business platform (assuming functional parity).

    Cheers

  • SteveH

    Hi Peter,
    What about the WCM functionality of Alfresco. The WCM functionality could prove to be very valuable in Jive. Has this usecase been accounted for/tested? And will this be supported? I see this as being much more useful than document management integration.

  • TonyV

    Peter,

    I too am very interested the WCM functionality in Jive.

  • http://www.sydneyclimbing.com/ Peter Monks

    SteveH, TonyV – the toolkit does support something like this, albeit using HTML snippet files rather than the original structured data itself. In this model, Alfresco Web Quick Start would be used for the editorial process (forms based content entry, workflow / approval, RenditionService to generate the HTML snippets etc.), and then the resulting files would be automatically socialised to Jive (e.g. as part of the approval workflow). Jive would then be customised to render those HTML snippets inline rather than using the generic document UI (the details page with the various document actions etc.).

    Can you go into a bit more detail on how you envisage this working? Is Alfresco delivering structured content to Jive, which transforms it to HTML on demand and presents the resultant HTML to visitors? How is the structured content represented in Jive (as custom content types, for example)?

  • Pingback: CMS & Content-Migration - Alfresco stellt Jive Connector vor

  • Jeremy Carson

    Will the Alfresco Jive Connector Toolkit work with Jive Cloud ?

    • pmonks

      It requires installation of a Jive Plugin, which I don’t believe the SaaS Jive Cloud supports. Their hosted offerings used to support this, but it’s been a while since we reviewed those offerings.


Alfresco Home | Legal | Privacy | Accessibility | Site Map | RSS  RSS

© 2012 Alfresco Software, Inc. All Rights Reserved.