Migration von Daten nach Confluence mit dem Content Import Plugin

Im Webinar (Registrieren) demonstrieren wir das Plugin, weitere Informationen stehen nach dem Release auch auf der Communardo Homepage und im Atlassian Plugin Exchange zur Verfügung.

Click here to view the embedded video.

Interessant sind vor allem das Drag & Drop von Anhängen, die Unterstützung von Office 2007 und dem IE 8, die neugestalteten Dialoge und die Einführung von Gadgets. Damit ist 3.1 eine Confluence-Version, für die sich ein Update – wie eigentlich immer bei neuen Releases der Atlassian Produkte – lohnt.

In folgenden Blogposts werde ich dann wieder kleine, interessante Features, die wenig dokumentiert sind und die man erst in der täglichen Arbeit entdeckt, vorstellen.

public PlatformTransactionManager getTransactionManager(){
    return (PlatformTransactionManager) ComponentContainer.get("transactionManager");
}

Allerdings funktioniert dieses Codebeispiel nach einer Umstellung auf V2-Plugins nicht mehr. Der Grund: Da diese Plugins in OSGI-Bundles umgewandelt werden, welche eine andere Spring Version verwenden als die Kern-Applikation, kommt es bei der Referenzierung der transactionManager-Bean über den ComponentContainer zu einer ClassCastException.

Bei der Suche nach einer Lösung für dieses Problem bin ich über ein Ticket im Issue Tracker von Atlassian gestolpert, in dessen Kommentaren eine Alternative beschrieben wird: Abhilfe schafft die Verwendung der Shared Access Layer (SAL), einer einheitlichen Service-Schicht für alle Atlassian Anwendungen. Sie stellt neben verschieden anderen Services auch ein TransactionTemplate bereit, das für Confluence bereits den auf Hibernate basierenden PlatformTransactionManager gesetzt hat und auf folgende Weise referenziert werden kann.

Zunächst muss das Template als Komponente (Spring-Bean) im Plugin-Descriptor (atlassian-plugin.xml) importiert werden:

<component-import name="SAL Transaction Template" key="salTransactionTemplate">
    <interface>com.atlassian.sal.api.transaction.TransactionTemplate</interface>
</component-import>

Dann kann man sich die Komponente per Spring Autowiring in fast alle Plugin Modultypen (z. B. Actions und Components ) injizieren lassen. Der Name der zu injizierenden Bean entspricht dem Key des component-import Elementes im Plugin-Descriptor (in diesem Beispiel also “salTransactionTemplate” ):

public void setSalTransactionTemplate(TransactionTemplate template){
    this.transactionTemplate = template;
}

Nun kann das Template wie  oben beschrieben verwendet werden.

Noch ein Hinweis: SAL wird erst ab Confluence 3.0 mit ausgeliefert. Für Confluence 2.10 muss man also eine andere Lösung finden.

<

Es gibt eine Vielzahl an Situationen, bei den man spezifische Properties verwendet. Generelle und fast überall aufzufindende Beispiele wären die Konfiguration des Logs und der Datenbank. Für diese speziellen Ressourcen existieren zumeist spezielle Dateien, die beim Start des Servers durch individuelle Klassen/Mechanismen ausgelesen werden.

Die Frage, die zu diesem Artikel geführt hat, befasst sich mit dem Thema:

Wie können anwendungsspezfische Properties für Confluence relativ einfach und leicht wartbar hinterlegt werden?

Gemeint sind hierbei Properties, die als Schalter zwischen Modi innerhalb einer Software dienen oder die zusätzliche Konfigurationen ermöglichen.

Möglichkeiten

JVM – Parameter (Der klassische Weg.)

Dieser Weg ist für Java Anwendungen allgemeingültig und somit für die meisten Programmierer nicht neu. Als JVM – Parameter (JAVA_OPTS) wird mit dem Präfix -D und dem anschließenden Property-Wertepaar (<property_name>=<property_value>) die Property definiert. In der Anwendung selbst kann dann mit System.getProperty(“<propety_name>”) darauf zugegriffen werden. Als Rückgabewert liefert die Methode  immer ein String, den man ggf. explizit casten muss.

confluence.cfg.xml (Der elegantere Weg.)

Atlassian Confluence nutzt eine zentrale Datei (confluence.cfg.xml) in der Properties definiert werden können. Diese Datei  befindet sich im data Verzeichnis.

Wie die Extension vermuten lässt, handelt es sich hierbei um eine XML Datei. Die Definition der einzelnen Properties erfolgt wie folgt:

 <confluence-configuration>
  <setupStep>complete</setupStep>
  <setupType>custom</setupType>
  <buildNumber>1517</buildNumber>
  <properties>
    <property name="attachments.dir">${confluenceHome}\attachments</property>
    ...
    <property name="this.is.an.example">true</property>
  </properties>
 </confluence-configuration>

In diesesm Ausschnitt habe ich eine neue Property mit Namen “this.is.an.example” mit dem Wert true angelegt. (rot gekenntzeichnet) Um nun in Quellcode diesen Wert auslesen zu können muss die Serviceklasse BootstrapManagers verwendet werden.

Eine Variante dafür wäre die getProperty() Methode zu nutzen.

 BootstrapManager bootstrapManager = BootstrapUtils.getBootstrapManager();
 Object objectVal = bootstrapManager.getProperty("this.is.an.example");
 // here comes the explicit cast
 boolean booleanVal = ((Boolean) objectVal).booleanValue();

Möglich wäre auch die getString() Methode zu wählen.

 BootstrapManager bootstrapManager = BootstrapUtils.getBootstrapManager();
 String stringVal = bootstrapManager.getString("this.is.an.example");
 boolean booleanVal = Boolean.valueOf(stringVal);

Die kürzeste Variante allerdings ist die Methode isPropertyTrue() zu verwenden. Die kann folgendermaßen aussehen:

 BootstrapManager bootstrapManager = BootstrapUtils.getBootstrapManager();
 boolean booleanVal = bootstrapManager.isPropertyTrue("this.is.an.example");

Fazit

Meiner Meinung nach steigt durch die Nutzung der confluence.cfg.xml die Übersicht. Da zum einen die Daten lesbar (XML) abgelegt und zudem zentral an einer Stelle konfiguriert werden. Ein weiterer Vorteil gegenüber den JVM Parametern ist,  dass der Betrieb, der die Wartung der Skripte und der Anwendung auf dem Server vornimmt, keine Konfigurationen vergessen bzw. überschreiben kann. Letztlich ermöglichen solche gebündelten Konfigurationen in einer einzigen Datei, dass sie relativ unproblematisch für bestimmte Anwendungsfälle/Instanzen ausgetauscht werden können.

Die Präsenation von Martin Koser ist auf Slideshare verfügbar.

Ein Blogbeitrag zum Vortrag und zum Confluence Communitiy Day hat Martin in seinem frogpond Blog veröffentlicht. Herzlichen Dank an Martin Koser für seine Vortrag und den Bericht zur Veranstaltung!

Diese Wissensdatenbank dient also nicht nur den Mitarbeitern bei VBH, sondern insbesondere auch den Kunden und Lieferanten. Die auf Atlassian Confluence basierende Wissensdatenbank hat bei VBH das bisher genutzte Diskussionsforum abgelöst. Neben dem Bereich “Rat+Tat” wurde auch ein Begriffslexikon mit 11.000 Artikeln integriert.

Das System ist inzwischen seit mehr als 6 Monaten im Einsatz und bietet Kunden und Lieferanten einen Mehrwert durch umfangreichere und aktuellere Informationen rund um die angebotenten Produkte. Aber auch die Mitarbeiter im Unternehmen nutzen die Wissensdatenbank aktiv.

Inhalte werden von Mitarbeitern des Hauses kooperativ erstellt. Die Freigabe von Inhalten, die extern verfügbar gemacht werden sollen, erfolgt jedoch weiterhin zentral. Insbesondere der Bereich “Rat+Tat” soll aufgrund guter Akzeptanz noch weiter ausgebaut werden. Die leistungsstarke Suche von Confluence hilft gerade auch den Kunden aus dem Handwerksbereich, schnell an wichtige Informationen zu gelangen. Auf Basis der Inhalte der Wissensdatenbank wird regelmäßig ein aktueller Newsletter für die Kunden erstellt und versandt. Um die zunehmende Verbreitung mobiler Endgeräte zu nutzen, wird untersucht, auf welche Weise ein mobile Zugriff auf die Wissensdatenbank erfolgen soll.

Wir bedanken uns bei Frau Lahm für den interessanten Vortrag und wünschen weiter viel Erfolg mit der VBH Wissensdatenbank.

Im Panel vertreten waren vor allem Vertreter von Google, Atlassian, SocialText, IBM und eXo. OpenSocial ist eine Entwicklung die von Google nun als Open Source verfügbar gemacht worden ist. Die ursprüngliche Ausrichtung war auf das Umfeld von Social Networking ausgerichtet.

Die Technologie hat sich in den letzten beiden Jahren stark weiterentwickelt, liegt nun als Version 0.9 vor und geht nun auf die Version 1.0 zu. Inzwischen nutzen Dienste mit in Summe von mehr als 800 Mio. Nutzern die OpenSocial Technologie. Inzwischen wird viel über den Unternehmenseinsatz diskutiert. Google wird in Kürze ein “Enterprise OpenSocial Whitepaper” veröffentlichen.

Nachfolgend die Zusammenfassung der Diskussion im Panel.

IBM ist an den OpenSocial Entwicklungen beteiligt. Hervorzuheben ist der Lotus Mashup Maker. IBM hat auch ein eingenes iWidget Protocol entwickelt. IBM sieht OpenSocial vor allem nützlich für Dashboards. Dies wird bei IBM vor allem über die JAZZ Foundation vorangetrieben. IBM sieht Verbesserungsbedarf für OpenSocial, vor allem im Bereich Stabilität, Interoperabilität zu iWidgets, OpenAjax und Dojo.

Apache SocialSite ist ein Social Networking Service, der ursprünglich von Sun entwickelt worden ist. Mit SocialSite kann man Social Networking features auf Basis von Gadgets in bestehende Websites integrieren kann.

Atlassian bietet OpenSocial Unterstützung in seine Produkten Jira und Confluence. Dabei geht es in der Regel um die Zusammenarbeit von Mitarbeitern, z.B. im Softwareentwicklungsprozess. Mit OpenSocial kann man in Jira und Confluence nun eine standard-basierte Applikationsintegration vornehmen, z.B. um Dashboards zu erstellen, Statusupdates zu integrieren. Hinweis: Communardo ist Atlassian Partner.

GateIn verbindet JBoss Portal Technologien mit OpenSocial. GateIn ist quasi eine OpenSocial Bridge, um OpenSocial Gadgets als JSR-168 Portlet in ein JBoss Portal integrieren zu können.

SocialText bietet eine Wiki und Collaboration Suite als Online-Service und Appliance. SocialText unterstützt OpenSocial für den Aufbau von Dashboards und für die Integration mit anderen Applikationen, z.B. mit einem CRM-System. Die Vertreterin von Socialtext sieht Ensatzaspekte von OpenSocial vor allem im Bereich oAuth (Authentifikation gg. externe Internetdienste), Aufbau von Kontaktnetzwerken, Aufsüren von Inhalten und Personen in externen Diensten, Austausch von Profildaten zwischen internen und externen Diensten, z.B. LinkedIn.

Die Teilnehmer am Panel sehen eine viel reichhaltigere Community für OpenSocial Gadgets als z.B. im Bereich der Java-basierten Portlets. Als Grund dafür wird die wesentlich einfachere Javascript-basierte Entwicklung von OpenSocial Gadgets angesehen. Für OpenSocial gibt es auch eine REST-basierte API.

Die von Herrn Hummel präsentierte Lösung ersetzt das gedruckte Handbuch einer Software für Reiseunternehmen. Dieses litt an geringer Akzeptanz bei den Kunden, die somit auch für triviale Fragen den in der Folge überlasteten Support in Anspruch nahmen.

Aus dieser Ausgangssituation leiteten sich die Anforderungen an ein neues Handbuch ab: Die Akzeptanz bei den Kunden sollte gesteigert und somit der Support entlastet werden. Außerdem sollten die Kosten für den Druck des Handbuches gesenkt, sowie die Entwickler der Software von den aufwendigen Reviews des Handbuches für jedes neue Release befreit werden.

Diese Anforderungen wurden mittels Atlassian Confluence realisiert. Dazu wurde das Confluence Wiki von emplse erweitert und ein spezielles Inhaltskonzept entwickelt. Durch eine entsprechende Strukturierung des Inhaltes in Bereiche und  Seitenhierarchien konnten die Formularstruktur der Software sowie Mehrsprachigkeit und kundenspezifische Inhalte (z. B. Arbeitsanweisungen) auf das Wiki abgebildet werden. Ein weiterer Vorteil ergibt sich für die Kunden in der direkten Integration der Hilfe in die Software, die mittels eines von empulse entwickelten Webservice auch nach verwandten Hilfethemen zu einem Formularelement sucht. Dazu wird zu jedem Formularelement in der Software eine Seite im Wiki gepflegt, die sich bei Aufruf der Hilfe im Webbrowser öffnet. Des Weiteren profitieren Support und Kunden von der kollaborativen Idee eines Wikis: Supportmitarbeiter können, anfangs geführt durch einen Moderator, selbstständig Änderungen an unklaren Formulierungen in der Hilfe vornehmen. Die Hinweise dazu können Kunden durch Verwendung der Kommentarfunktion in Confluence geben. Dies führt zu einer ständigen Verbesserung des Handbuches.

Weitere Informationen zum Projekt können auch im Blog von empulse gefunden werden.

Mit seinem Vortrag hat Christoph Rauhut sehr anschaulich gezeigt, dass Confluence über verschiedenste Makros, die von einer großen Community zumeist frei zur Verfügung gestellt werden, flexibel als Prokjekwiki und für viele weitere Einsatzzwecke erweitert kann. Eine weiterer Ansatz Confluence im Projektalltag zu verwenden, ist sicherlich eine enge Integration mit (im Unternehmen bereits vorhandenen) Werkzeugen zur Verwaltung von Dokumenten und strukturierten Daten (z.B. Micrsoft Sharepoint oder Atlassian Jira).

Der Umbruch in der Autoindustrie ist war von Vorteil für das Projekt, denn die Menge an Informationen, die es auszutuaschen gilt, hat enorm zugenommen. Besondere Herausforderungen im Automobil-Sektor sind die extreme Geheimhaltungsanforderung und die Sicherstellung des Vertrauensverhältnisses zum Kunden. Dafür müssen Geheimhaltungsvereinbarungen gewissenhaft durchgesetzt werden.

Daher hat bei der Auswahl auch ein ausgereiftes Berechtigungssystem des der einzusetzenden Software eine wichtige Rolle gespielt. Auf der anderen Seite hat sich das Festhalten an Freigaben von Inhalten als bedeutsame Hürde herausgestellt. GFi hat daher Confluence und Jira in ein klassisches CMS (Joomla) eingebunden. In Joomla konnten die Freigabemechanismen abgesichert werden.

Um die Qualität von Inhalten zu sichern, hat man sich zusätzlich auf den Aufbau von Projektwikis konzentriert. Als Anwendungsfälle sind dabei insbesondere die Dokumentation von Besprechungen und das Brainstorming in der Gruppenarbeit erwähnenswert.

Beim Aufbau des Wikis hat man sich zunächst auf Einzelkämpfer konzentriert, die Informationen für sich aufbereitet haben, um die eigene Arbeit zu verbessern. So sind in der täglichen Arbeit persönliche Seiten / Wikis entstanden, die dann mit steigendem Reifegrad in die Zusammenarbeit eingeflossen sind. Die Einführung dauert auf diesem Weg natürlich etwas länger, aber die Akzeptanz ist auf diese Weise schrittweise gestiegen. Die persönliche Darstellung ist hier eine Haupt-Antriebskraft. Weitere Erfolgsfaktoren waren zudem die Nutzung der Confluence-Suche und die Nutzungs des Wikis zur Bewältigung der Informationsflut in neuen Projekten einzusetzen.

Eine wichtige Erfahrung aus dem Projekt bei GFi war, Geduld mit Entscheidern haben, die lernen müssen, loszulassen. Des weiteren hat es sich als zielführend herausgestellt, nicht die ganz großen Probleme lösen zu wollen, sondern die Alltagsprobleme der Mitarbeiter in ihren konkreten Projekten anzugehen. Der anfängliche Top-down-Ansatz ist stecken geblieben und wurde dann durch einen erfolgreicheren Bottom-up Ansatz ersetzt.

Kai Nehm hat in seinem Blog über den Confluence Community Day berichtet.