The Content Import Plugin facilitates imports of any type of content into Confluence. The data has to be provided in a transfer format, which is basically an XML notation of Confluence data structures. The format supports each Confluence content type (pages, spaces, blog posts, comments, attachments) and the according meta data (creator, modifier, dates, labels). Thus the plugin is an efficient tool to support the migration of content from any system, e.g. legacy wikis, blogs and message boards, without the need to know the Confluence API.

Advantages of Content Import Plugin

The Content Import Plugin  offers a bunch of additional features in contrast to other migration tools (like the Universal Wiki Converter):

• Content Types: Each type of Confluence content is supported: pages, blog posts and whole spaces including comments and attachments. The import into existing spaces is easily possible. Content hierarchies are supported too.
• Meta Data: Each common Confluence meta data is supported (creator, modifier, creation date, modification date, tags)
• Content Formatting: The plugin supports all sorts of HTML formatting, tables, internal and external links and embedded images.
• Source Systems: The plugin is not limited to only one content source system. Virtually every legacy system such as wikis, blogs, message boards or even individual software systems are supported by using an XML transfer format.

Overview for the migration process

Further Information

[table id=8 /]

Screenshots

Jetzt ist schon fast ein halbes Jahr vergangen, als ich mich das letzte Mal mit dem Cross Site Scripting Filter (XSS) von Sharepoint 2007 befasst habe. Dieser stellt einen wesentlichen Bestandteil von Sharepoint dar und bereitete mir damals schon sehr viele Kopfschmerzen. Prinzipiell besteht die Aufgabe des XSS Filters darin, schädlichen Code oder Skripte aus dynamisch generierten HTML Seiten zu entfernen. Dass der Filter manchmal etwas willkürlich arbeitete hatte ich damals in meinen Blogbeitrag bereits gezeigt.

Was bisher geschah: Sharepoint und der eigensinnige XSS – Filter (Bericht)

Grund genug, sich einmal die Unterschiede zwischen Sharepoint 2007 und Sharepoint 2010 anzuschauen.

Um die Unterschiede zu verdeutlichen, habe ich ein HTML Quelldokument, jeweils mit einem Sharepoint 2007 und mit einem Sharepoint 2010 Server programmatisch importiert.

Folgender Programmcode kam dabei zum Einsatz.

class Program
    {
        static void Main(string[] args)
        {
            using (SPSite site = new SPSite("http://....."))
            {
                using (SPWeb web = site.OpenWeb())
                {
                    PublishingWeb pubWeb = PublishingWeb.GetPublishingWeb(web);
                    string pageFileName = "Test";

                    PageLayout[] pageLayouts = pubWeb.GetAvailablePageLayouts();
                    PageLayout currPageLayout =  pageLayouts[4];

                    PublishingPageCollection pages = pubWeb.GetPublishingPages();
                    PublishingPage currentPage = pages.Add(string.Concat(pageFileName,".aspx"),currPageLayout);

                    string htmlContent = GetFileContent();

                    currentPage.ListItem[FieldId.PublishingPageContent] = htmlContent;
                    currentPage.ListItem.Update();
                    currentPage.Update();
                    currentPage.CheckIn("Checked in by me");
                }
            }
        }

Die Ergebnisse des Tests zeigt die folgende Tabelle.

Positiv fällt auf, dass Sharepoint 2010 endlich die Anführungszeichen an Attributen unangetastet lässt. Die 2007 er Version löschte derartige Zeichen kompromisslos weg. Kommentare akzeptiert Sharepoint 2010 immer noch nicht als HTML Elemente – sie werden ebenfalls gelöscht. <li> Elemente dürfen keine Bilder als Listen Icons besitzen. Möchte man sein eigenes Icon zu einer Liste hinzufügen sollte auf eine externe CSS Klasse zurück gegriffen werden (Dies ist in jedem Falle zu empfehlen). Die Eigenschaften “inherit” sowie “none” hingegen werden unterstützt.

Script Tags werden völlig korrekt entfernt. Ebenso Iframe Elemente. Diese sind nicht erwünscht.

Weiterhin positiv aufgefallen ist, dass Elemente des Typs <input/> endlich korrekt geschlossen werden. Das Attribut “Name” wird leider gelöscht. Warum kann ich mir nicht erklären, es scheint aber so, als würden alle Attribute mit der Bezeichnung “name” gelöscht.

Als letzte Besonderheit fällt auf, dass Sharepoint nun konsequent alle absoluten Urls in relative überführt. In Sharepoint 2007 blieben absolute Urls unangetastet. Relative Urls, welche keinen Bezug zu dem aktuellen Sharepoint Server besitzen, wie etwa <a href=”../../beispiel.htm”>, werden weiterhin gelöscht.

Fazit: Es scheint als hätte sich das Sharepoint Entwicklungsteam einige Gedanken über XHTML & Co gemacht. So fallen die geschlossen Tags sowie die Anführungszeichen positiv auf. Einige Baustellen bleiben weiterhin offen.

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.

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.

Hin und wieder kommt es vor, dass man Dateien im BLOB-Format in einer Tabelle ablegt. Wenn man nun “schnell” auf diese Daten zugreifen will, steht man vor einem Problem, denn der Standard-SQL-Befehlssatz bietet keine Möglichkeit, Spalten mit Binärdaten zu füllen bzw. diese Daten wieder auszulesen und in eine Datei zu speichern.

Nun hat man nicht immer eine Entwicklungsumgebung zu Hand, um ein Programm zu schreiben, das per ADO oder ADO.NET diese Spalten befüllt. Auch der SQL-Server selbst bietet Möglichkeiten, um hier z.B. mittels Management-Studio tätig zu werden. Im Folgenden beschreibt ein Beispiel das generelle Vorgehen:

Als vorbereitende Maßnahme legt man eine Datenbank namens [pictures] an, die eine Tabelle mit dem Namen [images] enthält. Diese Tabelle enthält einfachheitshalber nur einen Primärschlüssel und das eigentliche Datenfeld. Wichtig hierbei ist, dass das Datenfeld den Datentyp [varbinary](max) hat.

CREATE DATABASE pictures
GO
USE pictures
GO

CREATE TABLE [dbo].[images](
[imageid] [int] IDENTITY(1,1) NOT NULL,
[imageblob] [varbinary](max) NOT NULL
PRIMARY KEY CLUSTERED ([imageid]))
GO

Nun wird die Tabelle mittels INSERT befüllt. Mittels OPENROWSET in Kombination mit der Option BULK ist es möglich, Spalteninhalte als Binärstrom aus einer Datei (im Beispiel: bild1.jpg) zu lesen.

INSERT [dbo].[images]([imageblob])
SELECT BulkColumn
FROM OPENROWSET( BULK 'C:\bild1.jpg',
SINGLE_BLOB) as ExternalFile
GO

Führt man nun einen SELECT auf die Tabelle aus, sieht man, dass die Binärdaten gespeichert wurden.

Der umgekehrte Weg ist leider nicht ganz so einfach. Hierzu muss man das Programm bcp bemühen. Um bcp per SQL aufzurufen, muss der Server konfiguriert werden, dass Shell-Aufrufe möglich sind. Auch das ist (notwendige Berechtigungen vorausgesetzt) per SQL-Statement möglich:

EXECUTE sp_configure 'show advanced options', 1
RECONFIGURE WITH OVERRIDE
GO
EXECUTE sp_configure 'xp_cmdshell', '1'
RECONFIGURE WITH OVERRIDE
GO
EXECUTE sp_configure 'show advanced options', 0
RECONFIGURE WITH OVERRIDE
GO

Für den eigentlichen Export ist noch eine Konfigurationsdatei erforderlich. Diese beinhaltet die Formatbeschreibung. Wird diese nicht verwendet hat die resultierende Datei zwar die passende Größe, kann aber nicht gelesen werden, da bcp beim Export einige automatische Zeichenersetzungen vornimmt. Die Formatdatei kann auf Kommandozeilenebene mit bcp erstellt und dann angepasst oder direkt mittels Editor erstellt werden.

Die resultierende Datei sollte final wie dargestellt aussehen:

Nun kann mittels eines BCP-Befehls eine Datei erstellt werden. Wichtig hierbei ist, dass immer nur 1 Spalte und eine Zeile ausgegeben wird, da a) nur eine Datei geschrieben wird und b) dies auch in der eben erstellten Formatdatei so beschrieben ist.

exec master..xp_cmdshell ‘bcp “select [imageblob] from [pictures].[dbo].[images] where imageid = 1″ queryout C:\kopiebild1.jpg -T -S . -f c:\imageblob.fmt’

Die Datei liegt nun als kopiebild1.jpg wieder vor.