EPiserver är ett kommersiellt innehållssystem baserat på Windows-teknik såsom IIS och MSSQL. Drupal är ett fritt innehållssystem baserat på öppen webbteknik såsom PHP och MySQL.
I detta fall fanns det en EPiserver sajt som skulle konverteras till en Drupal-sajt. Databasen var en MSSQL-databas. Det fanns bristfälliga möjligheter till att via utvecklare få bakgrundsinformation kring databas-flytt eller annan information om hur EPiserver-sajten var uppbyggd, dock fick jag en rå MSSQL-dump av hela databasen som uppackat blev 300MB stor.
Data från denna MSSQL-dump skulle anpassas och presenteras i Drupal miljö. Drupal har en fantastisk import-modul som kan läsa av en CSV-fil och skapa noder för specifik innehållstyp, jag har tidigare kört Node import och det skulle köras även i detta fall bestämde jag tidigt.
Man kan göra en rå databasimport rakt in i MySQL via till exempel PHPMyAdmins CSV-import funktion. Jag har gjort det förrut, bland annat för kommentarer kopplade till poster i Drupal. Det är inte att rekommendera att köra rå databasimport i ett Drupal-system eftersom man måste läsa på databasen väldigt bra då för att vara säker med att man får allting in och mycket kan strula eller leda till effekter man inte räknade med.
Med Node import får man mycket gratis, men samtidigt kräver Node import en perfekt CSV-fil, något som kan vara struligt att bygga speciellt vid stora tabeller.
Bak-filen som var backup av MSSQL-databasen monterades på en lokal Microsoft SQL Server 2008, en användare skapades och via verktyget SQL Server Management Studio fick man något som rudimentärt kunde liknas vid PHPMyAdmin, tillräckligt för att få en att bygga upp en uppfattning om hur databasen var uppbyggd samt köra frågor.
Min första tanke var att exportera de tabeller från MSSQL-databasen som var aktuella till MySQL genom att köra en fråga i MSSQL och sedan spara resultatet som en CSV-fil. Därefter skulle jag bygga upp en stor CSV-fil via egenutvecklade PHP-skript som via sin logik rad efter rad printade ut en validerad CSV-rad efter en annan. Slutligen skulle man genom PHPMyAdmin importera denna för att testa att den verkligen fungerade (att den var validerad rätt) och därefter exportera denna till en importfil för Drupal. Smidigt, då man slapp testa sig fram att importera i Drupal, vilket kan vara omständigt.
Detta visade sig vara mindre lyckat då man mer som regel än undantag får trasiga CSV-filer av inbyggda exportfunktioner vilket kräver stor handpåläggning, det hade fungerat om databasen hade upp emot 20.000 rader, men i detta fallet med 200.000 var det inte hållbart att sitta och ”rätta” resultatet för hand.
Valet föll då på att jobba mot MSSQL-databasen direkt från PHP, något man faktiskt inte tänkte på direkt efter flera års fokus på MySQL i kombination med PHP.
Att jobba mot MSSQL i PHP är i stort sett som MySQL, det kan dock vara knepigt att få upp utvecklingsmiljön, men det finns flera olika metoder man kan pröva tills man lyckas. Jag skulle dock personligen egentligen ha upprättat en virtuell server enbart ämnad MSSQL-installationen, dock hade jag inte tid för detta nu. Men det är något som kan vara bra att ha inför framtiden (Drupal kommer ju expandera när version 7 kommer gissar jag).
Hur är databasen i EPiserver uppbyggd?
I mitt fall var jag endast intresserad av att exportera artiklar skrivna i EPiserver samt upphovsmakarna till artiklarna.
Tabellen tblPage
Tabellen som håller alla artiklar är tblPage, man kan mer kalla den navet man utgår ifrån för den innehåller inte artiklarnas huvudtext. Från tblPage tar vi ID-numret från pkID. Lägg märke till kolumnen fkCreatorID och fkPageTypeID. fkCreatorID är ID-numret för användaren som skapade artikeln. fkPageTypeID är vilken sidtyp sidan har, alltså en slags klass som sidtyper -CCK- i Drupal, i tabellen tblPageDefinition kan man se vad de olika fkPageTypeID numren är för något.
Viktigt är att lägga märke till kolumnen PublishedVersion. Likt Drupal finns det ett slags revisionssystem i EPiserver så man kan stega bak till äldre varianter av en sida. Kolumnen PublishedVersion håller vilken version av revisionerna som är den publiserade och vilken man kan skippa vid export.
Tabellen tblWorkPage
Tabellen tblWorkPage innehåller återigen nyckeln pkID, men tblPage.pkID är nyckeln till tblWorkPage.fkPageID. Vad ska vi göra med tblWorkpage.pkID då? Läs vidare..
Tabellen tblWorkProperty
Via tblWorkPage.pkID kan vi nå tblWorkPageID och själva innehållet i artikeln/sidan, utan information från denna tabell skulle vi bara få med rubriken vid export. Texten ligger i kolumnen LongString. Tabellen tblWorkProperty är en intressant tabell då den innehåller flera poster som är relevant för en artikel, det vill säga, man kan inte bara söka efter ett ID-nummer och sen få allt man behöver, man behöver data från flera olika poster som relaterar till samma artikels ID-nummer. Det vi ska kolla på i denna tabell är kolumnen fkPageDefinitionID som är relaterad till tabellen tblPageDefinition
Tabellen tblPageDefinition
Denna tabell håller olika fält för en sida, i Drupal-språk kan man säga att denna tabell håller CCK-fälten för en innehållstyp. Genom att titta på tblPageDefinition.pkID och sedan titta på det ID som värdet pekar på i tblWorkProperty kan man se vad för nytta de olika posterna har, kanske behöver man inte ingressen eller annan del i Drupal, då är det onödigt att exportera det.
Andra intressanta tabeller
Tabellen tblCategory innehåller kategorier för sidor och vilket ID-nummer en kategori har (kolumnen pkID), tabellen tblCategoryPage visar vilken sida som är knuten till vilken kategori (detta blir i Drupal en taxonomi som användare kan välja från Drop-downlista när de skapar innehåll i CCK-typen).
Tabellen tblUser är den klassiska users-tabellen, här hittar man användares namn, ID-nummer (fkSID) och e-postadress. Viktig information om man vill ta med relationen mellan användare och skriven artikel i Drupal.
Jag nämnde under tabellen tblPage att kolumnen fkPageTypeID håller ID-numret för vilken innehållstyp sidan är gjord i, fkPageTypeID står i relation till tabellen tblPageType där vi hittar relaterat pkID och namnet på innehållstypen som ligger i kolumnen name.
Att bygga CSV-filen
Det absolut bästa när man gör en stor import från främmande datakälla är att man bekantar sig med hur en CSV-fil ser ut och hur den bör anpassas för att fungera med det importverktyg som finns. Ett bra tips är också att börja med 10 poster istället för 10000 och lära sig se vad de olika felmeddelanden man kan få betyder.
I PHP finns det funktioner för att skriva till fil, genom att via PHP-skript bygga funktioner som hämtar den data man vill ha till variabel från databasen och sedan printar ut denna enligt CSV-format till en fil får man en färdig importfil. Att bygga själva PHP-skriptet som bygger CSV-filen är dock en mödosam procedur men väldigt tillfredställande när den producerar solid output.
Glöm dock inte att filen behöver konverteras till UTF8 (utan BOM) annars lär du få strul med svenska tecken. De kolumner som skall importeras bör också ha skapats på Drupal-installationen och om titeln för kolumnerna i CSV-fil är samma som i Drupal vinner man mycket tid eftersom man inte behöver mappa upp fält till kolumner då.
Lycka till!
Välkommen att kontakta mig via mail om tjänster i form av databasmigrering mellan innehållssystem såsom Drupal, WordPress och EPiserver önskas.