Communardo Software GmbH, Kleiststraße 10 a, D-01129 Dresden
0800 1 255 255

Confluence in Connections integrieren (Teil 1)

Einleitung

Dieser tech­ni­sche Beitrag beschäf­tigt sich mit einem Integrationsansatz, bei dem Atlassian Confluence 4 und IBM Connections 4 kom­bi­niert wer­den sol­len. Dabei wird Connections als füh­ren­des System betrach­tet, in dass Informationen aus einem eigen­stän­di­gen Confluence inte­griert wer­den sol­len. Da in Connections die Activity Streams als Kernfeature eine zen­trale Rolle spie­len, liegt es nahe, Activities aus Confluence darin mit anzu­zei­gen. Im Folgenden beschrei­ben wir die Überlegungen und Schritte, die wir im Rahmen eines Proofs für die­sen Use Case durch­ge­führt haben.

Der Activity Stream in Connections

Die ver­schie­de­nen Sichten des Activity Streams stel­len aktu­elle Informationen des Systems dar, für die der Nutzer lese­be­rech­tigt ist. Beispiele hier­für sind das Anlegen einer Community, das Bearbeiten einer Wikiseite oder Status-Updates von gefolg­ten Nutzern. IBM folgt bei der Implementierung einem Standard für Social Activities: http://activitystrea.ms/

In IBM Connections gibt es drei kon­text­be­zo­gene Sichten für die Activity Streams:

  1. Nutzerspezifisches Following ("Ich folge") – Activities von Personen, denen der aktu­elle Nutzer folgt
  2. Community – Activities der aktu­el­len (aus­ge­wähl­ten) Community 
  3. Global – alle Activities
 

Atlassian Confluence Activities (Updates/Changes) 

Relevante Confluence Activities könn­ten sein:

  • Bereich erstellt, entfernt
  • Seite erstellt, bear­bei­tet, entfernt
  • Anhang zu/von einer Seite hin­zu­ge­fügt, aktua­li­siert, entfernt
  • Kommentar erstellt, bear­bei­tet, entfernt
 

Erweiterte Informationen und Funktionen zu Activities im Stream: OpenSocial Gadgets

OpenSocial Gadgets sind kleine Komponenten in XML, HTML und JavaScript, die dazu die­nen, um benut­zer­de­fi­nierte Inhalte in Connections ein­zu­bet­ten. Im Rahmen des Connections Activity Streams wer­den Gadgets genutzt, um erwei­terte Informationen und Funktionen für die kur­zen Aktivitätsmeldungen anzu­bie­ten. Bei IBM wird das mit dem Begriff  "Embedded User Experience" bezeichnet. 

Die genaue­ren Informationen hierzu fin­den Sie auf der Seite OpenSocial.

Ein IBM Whitepaper dazu fin­det sich in der IBM Connections Dokumentation.

Beispiele für die Embedded Experience fin­den sich auch in fol­gen­dem Video:

YouTube

Mit dem Laden des Videos akzep­tie­ren Sie die Datenschutzerklärung von YouTube.
Mehr erfah­ren

Video laden

IBM Connections OpenSocial Data-Model für das Posten der Activities

Das Data-Model gibt an, in wel­cher Art und Weise die Daten über die OpenSocial Schnittstelle gesen­det wer­den müssen.

Siehe auch: IBM Connections OpenSocial Data-Model

OpenSocial Gadget Template für Confluence Aktivitäten

Für ein Confluence Gadget inner­halb der "Embedded User Experience" muss eine Gadget XML erstellt wer­den, wel­che beschreibt, wie die über­mit­tel­ten Daten reprä­sen­tiert wer­den sollen. 

Ein ein­fa­ches Beispiel, wie diese XML-Beschreibung grund­sätz­lich aus­se­hen kann fin­det man hier: http://public.dhe.ibm.com/software/dw/lotus/ee/video.xml.

Auf diese Gadget XML wird inner­halb der Activity in Form einer URL ver­wie­sen, damit Connections zum Zeitpunkt der Darstellung des Gadgets weiß, wo die Beschreibung des Gadgets zu fin­den ist:

 

"openSocial": {
	"embed": {
		"gadget": "http://com19249177.mydomain.com/communardo/gadget/confluence.xml",
		"context": {
			"pageid": "${page.id}"
		}
	}
}

Technische Umsetzung

In die­sem Kapitel wer­den die ein­zel­nen Umsetzungsschritte grob beschrie­ben. Dabei wird auf Probleme und Ziele der unter­schied­li­chen Vorgehensweisen hingewiesen.

Es wird hier­bei von einer gemein­same Nutzerbasis aus­ge­gan­gen. (Nutzer aus System A ist eben­falls im System B vor­han­den und kann ein­deu­tig aus einem System in das andere System refe­ren­ziert werden)

Das Vorgehen wird anhand des nut­zer­spe­zi­fi­schen Activity Streams von IBM Connections beschrieben.

Atlassian Confluence Activities ermitteln

Confluence ver­fügt über zahl­rei­che inhalts­be­zo­genge Events (z.B. Seite wurde geän­dert), für die man inn­ner­halb von Plugins so genannte Event Listener imple­men­tie­ren kann. Dieser Mechanismus ermög­licht es, auf ein­fa­che Art und Weise auf kon­krete Systemereignisse zu reagie­ren, was uns in unse­rem Integrationsansatz hilft, um rele­vante Ereignisse zu erken­nen und an Connetions  "wei­ter­zu­lei­ten".

Relevanten Empfängerkreis im Connections für die Activities ermitteln

Die Schnittstelle von IBM Connections sieht vor, dass die Activities ein­zeln in den jewei­li­gen Activity Stream gesen­det wer­den müs­sen. Es gibt kein Automatismus, der die Activity, die an einen Connections-Nutzer gesen­det wird, auch an die zuge­hö­ri­gen Followers in Connections dele­giert. Diese Einschränkung ist darin begrün­det, dass Informationen aus einer ange­bun­den Applikation zugriffs­be­schränkt sein kön­nen, sodass u.U. die Followers der ande­ren Applikationen diese Activity gar nicht erhal­ten dür­fen (Berechtigungsproblematik).

Jedoch sieht das Opensocial ActivityObject Format vor, dass meh­rere Empfänger einer Activity im to/deliverTo Element ein­ge­tra­gen ein­ge­tra­gen wer­den kön­nen. Siehe auch Connections Wiki

Connections und Confluence besit­zen jeweils einen Follower Mechanismus. In die­sem Beispiel wird davon aus­ge­gan­gen, dass es keine Follower-Synchronisation zwi­schen den Systemen gibt, sodass in jeden Anwendung eine unab­hän­gige Nutzer-Follower Beziehung existiert.

Für das Beispiel wer­den die Followers/Beobachter an den Confluence-Entitäten ver­wen­det, um sie auch im Connections über die Activities zu informieren.

Senden der Daten an Connections

Nachdem die Empfänger und die Daten erar­bei­tet wur­den, kön­nen nun die Activities über die OpenSocial REST API in die ent­spre­chende nut­zer­spe­zi­fi­schen Activity Streams gesen­det wer­den. Der not­wen­dige REST Service wird in der Connections Dokumentation beschrie­ben. Ein Beispiel fin­det man auch im Blog von Luis Benitez: http://www.lbenitez.com/2012/05/how-to-post-events-into-opensocial.html

Hinweise

Berechtigungen des Systemnutzer und BASIC Authentication 

Für das authen­ti­fi­zier­ter Versenden der Confluence Updates wurde ein Systemnutzer in IBM Connections erstellt, der zusätz­lich die Berechtigung erhal­ten musste, Activities auch für andere Nutzer ein­stel­len zu kön­nen. Die Berechtigung kann kon­fi­gu­ra­tiv ver­ge­ben wer­den. Die Authentifizierung des Systemnutzers gegen die OpenSocial REST Schnittstelle kann mit  "BASIC Authentication" erfol­gen. Hierbei ist dar­auf zu ach­ten, dass die URL /basic/ ent­hält z.B. 

/connections/opensocial/basic/rest/activitystreams/@me/@all/@all 

Viele Updates und Follower in Confluence kön­nen zu zahl­rei­chen Aufrufen und somit zu Lastproblemen führen

Für das Senden der Aktivitäten wäre es gut, wenn Anfragen gebün­delt wer­den könn­ten. Leider wer­den die im Standard vor­ge­se­hen BATCH-Aufrufe von Connections 4.0 noch nicht unterstützt.

Ausblick

Im nächs­ten Teil wer­den wir uns damit beschäf­ti­gen, wie man die Authentifizierung des Confluence Gadgets mit OAuth rea­li­sie­ren kann.

Autoren: Andreas Reif und Ralf Borchers

Related Posts

Gibt es schon irgendwo Teil 2 die­ses Artikel? Ist auf jeden Fall ein inter­es­san­ter Ansatz.

MFG

Wir wer­den in der kom­men­den Woche unser Produkt C²-Connect zur Integration von Confluence Aktivitäten in Connections vor­stel­len. Später wer­den wir auch inter­es­sante, tech­ni­sche Aspekte hier wie­der veröffentlichen.

Comments are closed.

Pin It on Pinterest