Mit einem Webinar (Registrieren) in der Reihe “Plugin of the Month” von Atlassian veröffentlichen wir am 18.2.2010 das Content Import Plugin 1.1.
Das Plugin unterstützt den Import verschiedenster Inhalte nach Confluence. Die Daten müssen in einem Austauschformat, das Confluence Datenstrukturen in XML abbildet, zur Verfügung gestellt werden. Das Austauschformat unterstützt fast alle Inhaltstypen von Confluence (Bereiche, Seiten, Blogeinträge, Kommentare und Anhänge) sowie die zugehörigen Metadaten (Ersteller, Bearbeiter, Schlagworte, Datum). So können ohne vertiefte Confluence Kenntnisse Daten aus verschiedensten Quellsystemen, wie Wikisystemen, Blogs, Foren, nach Confluence importiert werden. Weiterhin bietet Communardo einen Migrationsservice an, der den kompletten Export der Daten aus dem Quellsystem nach XML und den anschließenden Import umfasst.

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.

Im Rahmen eines Webinars habe ich die aktuelle Version von Confluence vorgestellt und neue Funktionalitäten demonstriert und kommentiert: [vimeo]http://www.vimeo.com/8602746[/vimeo]

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.

Christoph Rauhut von T-Systems Multimedia Solutions gab mit seiner Präsentation zum Confluence Community Day insbesondere für Confluence Neulinge eine Übersicht zu Makros, mit denen Confluence für den Einsatz als Projektwiki optimiert werden kann. Einen Fokus legte er bei der Auswahl der präsentierten Makros auf die Kommunikation, Zusammenarbeit, Aufgabenverwaltung, sowie Inhaltserstellung und -strukturierung im Projekt.
Die Makros demonstrierte Christoph Rauhut live und damit sehr plastisch im Wiki für ein gedachtes „Projekt“ Confluence Community Day. Die Vortragsdokumentation enthält Screenshots der Macros in Aktion und den zugehörigen Macroaufruf.
Artikel vollständig lesen »

Tino Winkler von Communardo hat auf dem Confluence Community Day in seinem Vortrag und anhand einer Demo gezeigt, dass ein vollständiger Import von Inhalten mit allen Metadaten nach Confluence möglich ist. Erfahrungen dazu hat er vor allem bei der Entwicklung des Content Importer Plugins gesammelt, das für die Migration von Inhalten aus verschiedensten Altsystem nach Confluence eingesetzt wird.

Detailliertere Informationen zu den Herausforderungen beim Import, die durch unterschiedliche Quellformate und durch spezifischen Eigenheiten von Confluence entstehen, können gemeinsam mit Lösungsansätzen in den Vortragsfolien nachgelesen werden:
Einen beispielhaften Lösungsansätze für den Umgang mit der teilweise uneinheitlichen Confluence API hat Tino Winkler live präsentiert: beim Import von Anhängen zu einer Wikiseite bietet die API keine Möglichkeit zum expliziten Setzen eines Erstellers für Anhänge, so dass der Nutzer, der den Import durchführt als Ersteller der Dokumente gesetzt wird. Um dies zu umgehen muss kurzzeitig der Nutzer, der den Import durchführt, durch den gewünschten Anhangsersteller ausgetauscht werden.

public void switchUser(SwitchUserCallback callback) {
        // retrieve user to run callback for
        User user = getUser();
        // backup current user
        User backup = AuthenticatedUserThreadLocal.getUser();
        // switch user
        AuthenticatedUserThreadLocal.setUser(user);
        // run as switched user
        callback.performAsSwitchedUser();
        // restore current user
        AuthenticatedUserThreadLocal.setUser(backup);
    }

Aus der Erläuterung dieses „Tricks“ ergab sich eine Diskussion, die gezeigt hat, das mehr persönlicher Austausch von Tipps und Best Practices die in Deutschland weit verstreuten Confluence Entwickler weiterbringen kann. Vielleicht finden sich bei kommenden Veranstaltungen mehr Entwickler, die Fragestellungen oder Lösungsideen zur Diskussion stellen um gemeinsam Herangehensweisen zu entwickeln.

Nach dem Beitrag zum verbesserten Sicherheitskonzept beim Verschieben von Seiten in Confluence 3.0 möchte ich meine Reihe der kleineren, dennoch erwähnenswerten Confluence Features fortsetzen:
Das Atlassian Drag and Drop Firefox Plugin erlaubt es einen oder mehrere Anhänge direkt in einen Inhalt in Confluence oder Jira zu ziehen. Wird dieser Inhalt gerade bearbeitet, wird der Anhang – wenn möglich – direkt in die Seite eingebettet, etwa als Bild oder über das Macro {viewfile}. Wird lesend auf den Inhalt zugegriffen, wird die Datei als Anhang zum Inhalt gespeichert.

[youtube]http://www.youtube.com/watch?v=p1qh89jSKNg[/youtube] Demovideo von Atlassian

Das Plugin unterstützt Firefox bis zur Version 3.5, Confluence (getestet für Version 2.8 – 3.0) sowie Jira und ist Teil des Office Connector Addons für den Firefox. Das Addon wird beispielsweise benötigt, um in Wikiseiten eingebettete Office Dokumente direkt zu bearbeiten oder Wikiseiten in Word zu öffnen.
Den spontanen Szenenapplaus hat sich dieses nette Gimmick beim Atlassian Summit wirklich verdient!

Confluence 3.0 ist ja nun schon seit einigen Wochen veröffentlicht; wir haben gleich unser Intranet geupdated und die ersten Kunden beginnen auch auf die neue Version zu wechseln. Dabei entdeckt man immer wieder interessante Features, die zwar in den offiziellen Releasenotes untergehen, aber dennoch eine Erwähnung verdienen. Ich möchte in der nächsten Zeit ein paar Ausgewählte vorstellen – heute beginne ich mit der Lösung für ein Sicherheits- und Berechtigungsproblem.

Bisher konnten Nutzer, auch wenn sie im Bereich nicht die Berechtigung zum Löschen von Seiten hatten, Seiten löschen, in dem sie die Seiten in ihren Persönlichen Bereich verschoben haben. Dort darf standardmäßig der Eigentümer Seiten löschen. Damit konnte jeder Nutzer Seiten verschwinden lassen und es war nur sehr schwer möglich, diese Löschaktionen nachzuvollziehen.

Seit Confluence 3.0 werden beim Verschieben von Seiten die Berechtigungen feingranularer abgeprüft – Verschieben innerhalb des Bereiches darf jeder, der das Recht zum Bearbeiten von Seiten hat. Das Verschieben von Seiten in einen anderen Bereich ist jedoch nur noch für Nutzer möglich, die im Bereich auch das Recht zum Löschen von Seiten haben.

Damit ist eine ärgerliche Lücke im Berechtigungskonzept behoben wurden.
Danke Atlassian!

Häufig habe ich schon erlebt, dass Nutzer nach der Einführung von Confluence die Dokumentation bei Atlassian lesen, dabei viele neue Plugins entdecken und um die Installation der Plugins bitten. Administratoren sind dann oftmals unsicher, nach welchen Gesichtspunkten über die Installation der Plugins entschieden werden soll.
Auf der einen Seite erweitern Plugins die Funktionalität von Confluence und können damit die Benutzerakzeptanz steigern und eine effizientere Arbeit mit dem Wiki erlauben. Auf der anderen Seite können Plugins die Stabilität, Sicherheit und Performance eines Confluence-Systems entschieden beeinträchtigen. Mit Hilfe von Plugins können alle Teile des Wikis und sogar die Datenbank verändert werden.

Wie soll da über die Installation eines Plugins entschieden werden?

Die folgende Checkliste, unterteilt in Fragen zur fachlichen und zur technischen Bewertung, will Anhaltspunkte geben – wenn auch in die letztendliche Entscheidung über die Installation eine Plugins die Erfahrung des Administrators oder vielleicht das Knowhow eines Confluence-Consultants einfließen.

Fragen zur fachlichen Bewertung:

• Wird das Plugin wirklich benötigt um das bestehende Wiki zu verbessern?
  So ist möglicherweise das Sudoko-Plugin nicht unbedingt geeignet um ein Wissensmanagementsystem zu verbessern, dagegen können mit Hilfe des Rate-Macros die Wissensinhalte bewertet werden und damit den Nutzern erweiterte Information zur Einordnung des Inhalts zur Verfügung gestellt werden.
• Wird die Funktionalität des Plugins bereits durch Standardfunktionalität von Confluence oder durch andere bereits installierte Plugins abgebildet?
  Das Excel-Plugin erlaubt beispielsweise die Inhalte von an Wikiseiten gehängten Excel-Dokumenten anzuzeigen – diese Funktionalität und weitere Features zum Anzeigen und Bearbeiten von Office-Dokumenten werden jedoch auch (tw. in verbesserter Form) durch den mitgelieferten Office Connector zur Verfügung gestellt.
• Soll mit dem Plugin Funktionalität ins Wiki gebracht werden, für die andere Systeme vorhanden und besser geeignet sind?
  Das Calendar-Plugin erlaubt zum Beispiel eine Terminverwaltung, dennoch ist für die persönliche Terminverwaltung sicherlich bessere Software als ein Wiki denkbar. Das Metadata-Plugin und Metadata-Plugin 2 hingegen bringen semantische Funktionalitäten ins Confluence (auf Wikiseiten können beispielsweise semantische Informationen hinterlegt werden, die auf anderen Wikiseiten ausgewertet werden können) und erweiteren damit die Kernfunktionalität des Wikis.

Fragen zur technischen Bewertung:

• Ist das Plugin zu meiner Confluence-Version kompatibel?
  Dies ist eigentlich die wichtigste Frage für die technische Bewertung eines Plugins. Die Informationen sind meist auf der Homepage des Plugins verfügbar. Wenn das Plugin nicht zur Confluenceversion kompatibel ist oder die Kompatibilitätsinformationen fehlen, sollte auf die Installation verzichtet werden.
• Was hat die Installation und Nutzung des Plugins auf dem Testsystem ergeben?
  Vor der Installation auf dem Produktivsystem sollten Plugins immer auf einem Testsystem installiert und getestet werden. Dabei zeigen sich häufig schon eventuelle Probleme bei der Verwendung des Plugins. Plugins, die unsauberen HTML-Code ausliefern, können beispielsweise das Layout einer Seite kaputtmachen. Außerdem gibt es Macros, die für eine sehr lange Ladezeit ihrer Seiten sorgen usw. Auch auf die Ausgabe eventueller Fehlermeldung in den Logfiles sollte geachtet werden.
• Wird das Plugin von Atlassian supportet?
  Plugins, die von Atlassian supportet werden, haben eine gewisse Qualitätskontrolle bestanden und Atlassian hilft im Falle von Problemen mit dem Plugin weiter. Die fehlende Unterstützung durch den Atlassian Support sollte jedoch kein alleiniger Grund sein, die Installation abzulehnen.
• Wer hat das Plugin zur Verfügung gestellt?
  Plugins, die von Atlassian, renomierten Atlassian Partnern wie Adaptavist oder Customware, oder Communardo zur Verfügung gestellt werden, sind vertrauenswürdiger als die erste Version des ersten Plugins eines einzelnen Entwicklers.
• Haben andere Nutzer Erfahrungen mit dem Plugin und wie bewerten sie das Plugin?
  Diese Informationen finden sich meist in den Kommentaren auf der Homepage des Plugins, manchmal geben auch die Entwickler des Plugins selbst Hinweise zur Einsatzfähigkeit des Plugins.
• Wie ist die Performace des Plugins?
  Häufig werden Plugins für kleinere oder mittlere Confluence-Systeme entwickelt und die besonderen Herausforderungen eines großen oder gar geclusterten Systems werden nicht beachtet. Eine endgültige Aussage über die Performance eines Plugins können nur Lasttests liefern.
• Ist die Installatio über das Plugin Repository möglich?
  Plugins, die über das Plugin-Repository installiert werden können (und nicht per Kopieren von Dateien in den Ordner “WEB-INF/lib”) erlauben einfacheres Warten und Updaten des Plugins.

Fazit: Bei der Entscheidung zur Installation eines Plugins gilt der allgemeine Leitsatz
“So viel nötig, so wenig wie möglich” auch!

(das Nennen von Plugins in diesem Artikel enthält keinerlei Bewertung für die Auswahl des Plugins. Die genannten Plugins dienen nur als Beispiele, die die Fragen der Checkliste verdeutlichen sollen)

Am 23.10.2008 haben wir auf der Atlassian User Group in Berlin Per Fragemann, den Chef des Confluence-Entwicklerteams von Atlassian getroffen. Bei seinem Vortrag und im persönlichen Gespräch konnten wir einen Blick auf die nächsten Versionen von Confluence (Confluence 2.10, Confluence 3.0 und folgende) werfen. In typischer Manier veröffentlicht Atlassian zwar keine konkreten Releasetermine und Featurelisten – Per Fragemann begründet das mit der effizienteren Arbeitsweise, die den Entwicklungsteams so ermöglicht wird: es werden nur vollständige, “runde” Versionen veröffentlicht und keine Releases, die durch den Druck eines Veröffentlichungungsdatums halbfertige Funktionen enthalten, die hinterher ein aufwendiges Bugfixing erfordern.  Seine Begründung kann ich gut nachvollziehen, dennoch ist es immer wieder ein ungutes Gefühl, wenn man auch als Atlassian Partner die Fragen der Kunden nach den nächsten Versionen nur ausweichend beantworten kann. 

Confluence 2.10

Schon relativ konkret ist die Confluence Version 2.10, die Ende November veröffentlicht werden wird. Artikel vollständig lesen »

Um Inhalte aus anderen Wikisystemen in ein Confluence-Wiki zu migrieren, stellt Atlassian den Universal Wiki Converter zur Verfügung.
Zuerst werden die Inhalte aus der Datenbank des “Altsystems” exportiert, als Textdatei im lokalen Dateisystem abgespeichert und dann ins Confluence migriert.
Für den Export gibt es für die verschiedenen Wikisysteme Exporter, die in Properties-Dateien konfiguriert werden. Normalerweise werden dort Name, Nutzer und Pfad der Wikidatenbank angegeben.

Der Export aus einem MediaWiki neuerer Version schlägt jedoch aufgrund geänderter Datenbankfelder fehl. Dies kann behoben werden, indem in der Properties-Datei folgende angepasste SQL-Abfragen angegeben werden:

db.sql.pagedata=select page_id, page_namespace, page_title, page_latest from page where
     page_namespace!='8' and page_namespace!='12';
db.sql.textdata=select old_text from pagecontent where old_id = (
     select rev_text_id from revision where rev_id = 'db.column.textid' );
db.column.title=page_title
db.column.namespace=page_namespace
db.column.pageid=page_id
db.column.textid=page_latest
db.column.text=old_text

(Angepasst in den exporter.mediawiki.properties, Getestet mit MediaWiki Version 1.11)

Um die Ladezeit einer Website bei reduzierter Bandbreite zu testen, können über das Freewaretool SHUNRA\Nimbus einfach und sehr schnell Bandbreiten zwischen 28.8 und 256 kbit/s emuliert werden.

Leider ist das Tool ein wenig veraltet und auf der offiziellen Website nicht mehr zum Download verfügbar, aber mit einer Google-Suche nach „shunra nimbus“ werden viele Quellen gefunden.

Es gibt ein weiteres, aktuelleres Freewaretool zum Drosseln der Bandbreite, das vor der ersten Nutzung aber einigen Konfigurationsaufwand erfordert (-> Details)

Ausgangspunkt meiner Recherche zu diesem Thema war der Versuch mit einem JMeter Lasttest Aufrufe von Webservices über Mobilfunk zu simulieren.

Mit SHUNRA\Nimbus hat das sehr gut funktioniert, da die Drosselung direkt für die Netzwerkkarte des PCs durchgeführt wird.