Mit dem Erfolg zahlreicher Webanwendungen dringen Web 2.0 – Technologien nun auch in firmeninterne Netzwerke vor. Doch was sind die Anforderungen an Webtechnologien im Unternehmenseinsatz? Welche Vorteile, aber auch Herausforderungen und Hürden bringt der Einzug dieser Systeme mit sich?

Anhand dieser Fragestellungen beleuchtet ein von Communardo durchgeführtes Webinar die grundlegenden Paradigmen moderner Intranetsysteme und leitet Anforderungen an den Einsatz von Wiki-Technologien im Unternehmensumfeld ab. Besonderes Augenmerk wird auf die Integration externer Anwendungen sowie die Möglichkeiten der Zusammenarbeit und die Strukturierung von Inhalten gelegt. Am Beispiel des Enterprise-Wikis Atlassian Confluence werden mögliche Lösungen, Hinweise und Anregungen für die Erfüllung dieser Anforderungen gegeben.

Das Webinar findet am 10.11.2009 um 14 Uhr statt. Für die Teilnahme ist eine kostenlose Anmeldung auf der Communardo Homepage erforderlich. Der Teilnahmelink wird vor Beginn des Webinars per E-Mail versendet.

Das dritte Treffen der Liferay User Group Deutschland (LUGD) fand am 16.09.2009 in Frankfurt am Main statt. Auf der Agenda standen 2 Praxisberichte sowie eine erste Auswertung der in den Arbeitskreisen erzielten Ergebnisse. Nachdem Communardo bereits beim letzten Treffen der LUGD mit vertreten war, bot diese Veranstaltung eine gute Gelegenheit, sich gegenseitig ein wenig über die Schulter zu schauen und über erreichte Ziele bzw. offene Punkte auszutauschen.

Den Start des Treffens bildete der Vortrag “Das B2B-Händler-Portal der Gunz Warenhandels GmbH” von Stefan Niantschur (eNs IT-Beratung). Die Präsentation gab einen Einblick, wie Liferay als Grundlage für ein marketingorientiertes und mandantenfähiges B2B-Portal verwendet werden kann. Im konkreten Beispiel – dem Portal der Firma Gunz – wurde neben der Anbindung eines bestehenden Warenwirtschaftssystems u.a. Alfresco für die Integration von CMS-Inhalten verwendet. Die Verbindung von Liferay und Alfresco wurde als äußerst gewinnbringend bewertet und kann wohl inzwischen als eine Art quasi-Standard für die Einbettung von CMS-Funktionalität angesehen werden. Neben der hohen Stabilität eines laufenden Liferay-Systems konnten weiterhin die gebotenen Sicherheitsmerkmale (Authentifizierungsmöglichkeiten, Rechte- und Rollenverwaltung) positiv bewertet werden.

Den zweiten Vortrag stellte Rainer Sträter, Software Engineering & IT Director der ZEITGEIST at work AG. Unter dem gleichnamigen Portal verbirgt sich ein auf Liferay basierender Expert-Matching-Service, in dem Experten und Projektanbieter zusammenfinden können. Der Vorteil von Zeitgeist gegenüber bisherigen Systemen liegt u.a. in einer semantikbasierten Suche und einem integrierten Bewertungssystem. Auch hier konnte weitestgehend von positiven Erfahrungen mit Liferay als Portalsystem berichtet werden. Es wurde aber auch deutlich, dass die für Liferay verfügbaren Portlets die gestellten Anforderungen zwar zu einem großen Teil abdecken, trotzdem aber immer ein Rest von etwa 25 Prozent Customizing bzw. Eigenentwicklung verbleibt. Insbesondere in diesen 25 Prozent können sich dann auch echte Fallstricke und grundlegende Probleme verbergen. Ein vollständiges Portal lässt sich also nach wie vor in den meisten Fällen nicht rein konfigurativ erstellen. Trotzdem wurde auch in diesem Vortrag das unternehmenstaugliche Grundgerüst  (Authentifizierung, Rechteverwaltung, Nutzerverwaltung, Stabilität, Unterstützung von Portletstandards) und der hohe Funktionsumfang im Gegensatz zu anderen Portalsystemen positiv hervorgehoben. In diesem Zusammenhang stellte sich auch heraus, dass die Vielzahl der mitgelieferten Portlets zwar häufig ein gutes und wichtiges Verkaufsargument darstellt, diese in der Praxis dann aber kaum eingesetzt werden. Hier spielt der Gedanke “Ich könnte, wenn ich wöllte…” eine große Rolle im Bewußtsein der Anwender.

In der abschließenden Auswertung der LUGD-Arbeitskreise wurde schnell deutlich, dass viele der anwesenden IT-Dienstleister mit den gleichen Problemen bezüglich Liferay zu kämpfen haben und dabei unbewusst parallel an deren Lösung arbeiten. Der Vorschlag eines gemeinsamen Erfahrungsaustauschs bei einem eher technikorientierten Treffen fand also schnell große Zustimmung. Dabei sollen in Kurzvorträgen Best-Practices sowie Tipps und Tricks zur Arbeit mit Liferay ausgetauscht werden. Dringende Probleme (u.a. Verbesserung des CMS und der Suchfunktion) können dabei im Entwicklerkreis diskutiert und im besten Fall gemeinsam angegangen werden.

Als Fazit bleibt das äußerst positive Klima und der kooperative Gedanke der Teilnehmer in der LUGD zu bemerken. Beim Einsatz von Open Source Technologien ist offenbar vielen bewusst, dass es sich um ein Geben und Nehmen handelt und alle von einem gemeinsamen Wissens- und Erfahrungsaustausch profitieren können.

Für die Integration von JIRA-Inhalten in Confluence stehen 3 Möglichkeiten zur Verfügung:

• Einbinden einer Jira-View über das Macro “jiraissues”
• Einbinden von Jira-Portlets über das Macro “jiraportlet”
• Verwenden von Trackbacks.

Die Anzeige bestimmter Filter ist allerdings nur für eingeloggte Benutzer möglich. Daher sollte entweder eine Trusted Connection zwischen Jira und Confluence etabliert werden oder im Aufruf des Macros der Benutzername und das Passwort enthalten sein.

Näheres zur Zusammenarbeit von Jira und Confluence findet sich unter http://confluence.atlassian.com/display/DOC/Confluence%20and%20JIRA.

Einbinden von Jira-Views in Confluence

Über das Macro “jiraissues” lassen sich beliebige in JIRA angelegte Views in Confluence integrieren. Auf diese Weise können z.B. Ansichten für offene Vorgänge oder zugewiesene Aufgaben eingefügt werden.

Standardmacro

{jiraissues:url=http://jira.xml.url}

Hierbei ist zu beachten, dass als URL der XML-Link aus dem Jira Issue Navigator verwendet werden sollte. Diesen Link findet man, wenn man in Jira auf “Find Issues” geht und dort die gewünschte View anlegt (eine ausführliche Anleitung findet sich in der Dokumentation des Macros).

Auswahl von Spalten

{jiraissues:url=http://jira.xml.url|columns=type;key;summary}

Benutzername und Passwort

{jiraissues:url=http://jira.xml.url?os_username=johnsmith&os_password=secret}

Aufruf ohne Trusted Connection

{jiraissues:url=http://jira.xml.url|anonymous=true}

Screenshot

Einbinden von Jira-Portlets in Confluence

Über das Macro “jiraportlet” lassen sich Portlets aus dem Jira-Dashboard in Confluence integrieren. Dafür muß die URL des entsprechenden Portlets angegeben werden. Diese findet man heraus, indem man auf dem Jira-Dashboard in den Configure-Modus wechselt und dann den Link hinter dem Namen des gewünschten Portlets kopiert.

Standardmacro

{jiraportlet:url=urlOfJIRAPortlet}

Benutzername und Passwort

{jiraportlet:url=urlOfJIRAPortlet?os_username=johnsmith&os_password=secret}

Screenshot

Integration per Trackback

Eine recht simple Möglichkeit der Interaktion zwischen JIRA und Confluence besteht in der Verwendung von Trackbacks. Voraussetzung dafür ist, dass in beiden Systemen Trackbacks aktiviert sind. In JIRA findet sich die Option unter Administration – Global Settings – Trackback, in Confluence unter Administration – Allgemeine Konfiguration – Trackback. Verlinkt dann eine Confluence-Seite auf ein JIRA-Issue (oder anders herum), wird die verlinkte Seite informiert und blendet die Linkquelle ein. In JIRA führt das zu folgendem Ergebnis:

Neues in Confluence 2.10

Mit Version 2.10 wurde die Integration von Jira-Issues in Confluence-Inhalte weiter verbessert. Das Macro “jiraissues” liefert nun eine Tabelle, die im Gegensatz zu früheren Versionen bequem angepasst werden kann. Spalten können nun – wie von Windows gewohnt – verschoben und sortiert werden. Die Sortierung erfolgt dann je nach Spalteninhalt entweder alphabetisch oder z.B. auf/absteigend nach Priorität. Einzelne Spalten können auch ganz ausgeblendet werden. Zu beachten ist allerdings, dass diese Änderungen nicht gespeichert werden – sobald man die Seite verlässt und neu aufruft, ist wieder die standardmäßige Anordnung und Sortierung eingestellt. Lange Listen werden nun seitenweise dargestellt und können bequem durchblättert werden.

Für die Entwicklung von Plugins bietet Confluence die Möglichkeit, die standardmäßig im System vorhandenen Actions (z.B. die ViewPageAction und die EditPageAction) mit eigenen Action-Klassen zu erweitern bzw. bestehende Klassen zu ersetzen. Auf diese Weise kann eine Vielzahl der Standardfunktionen auf individuelle Bedürfnisse angepasst sowie neue Funktionalität implementiert werden.

Die in Confluence verwendeten Actions sind in Packages organisiert und werden in der Datei xwork.xml verwaltet. Jedes der dort enthaltenen Packages kann in der Datei “atlassian-plugin.xml” des eigenen Plugins erweitert werden. Soll z.B. die Klasse ViewPageAction überschrieben werden, muß das Package “pages” erweitert werden. Ein solcher Abschnitt kann wie folgt aussehen:

<xwork name="View Page Action" key="myviewpageaction">
	<package name="pages" extends="pages" namespace="/pages">
	<default-interceptor-ref name="validatingStack"/>
	<action name="viewpage" class="de.communardo.confluence.plugins.actions.MyViewPageAction">
		<result name="error" type="velocity">/pages/myerrorsite.vm</result>
		<result name="page" type="velocity">/pages/myviewpage.vm</result>
	</action>
	</package>
</xwork>

Dabei ist grundsätzlich darauf zu achten, dass im Parameter “extends” der Name des zu erweiternden xwork-Packages angegeben wird. Mit dem Tag <action> können dann eigene Action-Definitionen für dieses Package angegeben werden. Wird dabei im Parameter “name” der Name einer bereits existierenden Action eingetragen, wird diese durch die in “class” angegebene Klasse ersetzt. Dabei können auch die nach einer Action aufzurufenden Velocity-Templates und Actions im Tag <result> mit eigenen Results, Templates und Klassen ersetzt werden.

Beim Überschreiben der ViewPageAction ist allerdings eine Besonderheit zu beachten: beim Aufruf einer Seite durch die ViewPageAction wird standardmäßig in der Methode getWebInterfaceContext überprüft, ob die Seite von der Klasse “com.atlassian.confluence.pages.actions.ViewPageAction.class” aufgerufen wurde. Anhand dieses Klassennamens wird ermittelt, ob die aufgerufene Seite gerade angezeigt oder editiert wird.
Ersetzt man nun die originale ViewPageAction durch eine eigene Klasse, muß also auch in dieser Klasse die Methode getWebInterfaceContext implementiert und entsprechend des neuen Klassennamens angepasst werden. Für obiges Beispiel muss also folgende Methode implementiert werden:

public WebInterfaceContext getWebInterfaceContext() {
	DefaultWebInterfaceContext result = new
		DefaultWebInterfaceContext(super.getWebInterfaceContext());
	if (getClass().equals(MyViewPageAction.class)) {
		result.setParameter(ViewingContentCondition.CONTEXT_KEY, Boolean.TRUE);
	}
	return result;
}

Bei der Entwicklung von Confluence Plugins kommt häufig die auf Java basierende Buildmanagement-Software Maven zum Einsatz. Ziel dabei ist es, die Entwickler vom Anlegen des Projektes bis hin zum Kompilieren und Testen zu unterstützen und möglichst viele Schritte des Softwaremanagements automatisiert ablaufen zu lassen. Ein Tutorial für die Entwicklung von Confluence Plugins mit Hilfe von Maven findet sich auf den Seiten der Confluence Community.

Wenn eine solche Entwicklungsumgebung eingerichtet wurde, kann der Buildprozess eines Plugins noch weiter vereinfacht werden. Dafür stellt Atlassian das Plugin Developer Kit for Maven2 (kurz PDK) zur Verfügung. Dabei handelt es sich um ein Maven-Plugin, welches einfach in der POM des eigenen Projektes eingebunden werden muss und dann automatisch beim Buildprozess heruntergeladen und installiert wird. Ein solcher Aufruf kann z.B. so aussehen:

<plugin>
   <groupId>com.atlassian.maven.plugins</groupId>
   <artifactId>atlassian-pdk</artifactId>
   <executions>
      <execution>
         <phase>package</phase>
         <goals>
            <goal>uninstall</goal>
            <goal>install</goal>
            <goal>rescan</goal>
         </goals>
      </execution>
   </executions>
</plugin>

Dabei können verschiedene Goals angegeben werden, welche hintereinander ausgeführt werden und z.B. das Plugin direkt nach dem kompilieren in einem laufenden Confluence deinstallieren und die neue Version installieren. Eine sinnvolle Reihenfolge wäre z.B. Uninstall – Install – Rescan.

Vorsicht ist allerdings bei der Benutzung des Confluence Trigger Plugin Moduls geboten. Hat man einen Trigger in seiner atlassian-config.xml eingebunden und installiert das Plugin über das PDK direkt in ein laufendes Confluence, sollte nach einem Install kein explizites Enable des Plugins ausgeführt werden. Der Grund dafür ist: der Job wird bereits beim Install angelegt. Bei einem folgenden Enable wird dann erneut versucht, dieser Job anzulegen – was natürlich fehlschlägt und mit einer ObjectAlreadyExistsException quittiert wird. Ein Install und ggf. Rescan ist in diesem Fall also ausreichend.

Damit Confluence seinen vollen Funktionsumfang erreichen kann, sollte dem System ein Onlinezugang ermöglicht werden. Dadurch kann unter anderem das Plugin-Repository genutzt werden, mittels welchem die von Atlassian bereitgestellten Plugins bequem auf dem eigenen System installiert und verwaltet werden können. Aber auch zahlreiche Plugins basieren auf einer bestehenden Onlineverbindung. So können zum Beispiel durch das RSS-Feed-Macro sowohl externe als auch innerhalb von Confluence generierte RSS-Feeds auf eigenen Seiten eingebunden werden. Mit dem IM-Presence-Plugin können Confluence-Nutzer ihren Onlinestatus in verschiedenen Instant Messenger – Systemen auf einer Seite anzeigen lassen. Dieses Plugin ist besonders für persönliche Seiten und Blogs interessant.

Wenn Confluence kein direkter Internetzugang ermöglich werden kann (z.B. wenn das System innerhalb eines internen Netzes betrieben wird), besteht die Möglichkeit einen WebProxy anzugeben. Dafür muß im Startscript des Applikationsservers (beispielsweise eine Datei “catalina.bat” im “bin” Verzeichnis eines Tomcat-Applikationsservers) die Variable

JAVA_OPTS

mit dem Parameter

set JAVA_OPTS="-Dhttp.proxyHost=proxy.example.com -Dhttp.proxyPort=3128"

versehen werden.