Scriptie. Afstuderen bij Madcap // Opdracht Migreren met Drupal. Door: Jelle den Butter. Versie 1.0. Datum:

Transcriptie

1 Scriptie Afstuderen bij Madcap // Opdracht Migreren met Drupal Door: Jelle den Butter Versie 1.0 Datum: Scriptie Migreren met Drupal // Jelle den Butter //

2 1 Inhoudsopgave 1 Inhoudsopgave Voorwoord Managementsamenvatting Het afstudeerbedrijf De opdracht Het probleem De hoofd- en deelvragen De aanpak Het onderzoek Eisen en wensen van de gebruiker De handelingen van het systeem Data-analyse De mogelijkheden van Drupal De Drupal principes Content Grafische interfaces Bestaande modules De Conclusie Het functioneel ontwerp Niet-functionele eisen Functionele eisen De ontwerpbeslissingen De usecase-specificaties Conclusie Het technisch ontwerp Sequentie-diagram Conclusie Realisatie Conclusie De eindconclusie Verbeteringen Aanbevelingen Persoonlijke conclusie De bronnen Diverse bronnen [bron {getal}] De Protocollen [prot {getal}] De Literatuur [lit {getal}] De bijlagen Bijlage 1 : Extra informatie Drupal Bijlage 2 : Plan van Aanpak...41 Scriptie Migreren met Drupal // Jelle den Butter //

3 2 Voorwoord Voor u ligt de afstudeerscriptie voor mijn afstudeeropdracht. De opdracht is uitgevoerd als afsluitende opdracht voor mijn opleiding informatica aan de Hogeschool Utrecht. De opdracht is uitgevoerd bij Madcap bv, gevestigd in Hardinxveld-Giessendam. Ondanks de moeizame start bij Madcap door drukte en een afgewezen project heb ik een nieuw uitdagend project gekregen waarin ik veel heb kunnen leren. Ik wil hiervoor Jaap Broeders en Arjan van der Pol bedanken. Zij hebben mij de vrijheid gegeven zelf onderzoek en communicatie op te zetten met de verschillende betrokken partijen. Binnen het project Utrecht Your Way was behoefte aan een stabiele omgeving voor het migreren van data. Juist door die vrijheid binnen het project heb ik een generieke oplossing kunnen ontwerpen welke niet beperkt werd door tijdsdruk van de klant Utrecht Your Way. Na mijn werk voor Madcap in mijn afstudeerperiode hebben zij mij een vast contract aangeboden. Ik heb deze getekend en ben ze hiervoor heel dankbaar. Ik zal in de toekomst al mijn opgedane kennis van mijn opleiding gaan gebruiken om de klanten tevreden te gaan stellen met kwalitatieve web-applicaties. Scriptie Migreren met Drupal // Jelle den Butter //

4 3 Managementsamenvatting Madcap ontwerpt web-applicaties in alle maten en vormen voor zowel grote als kleine bedrijven met verschillende behoeften. Een voorkomende behoefte van deze bedrijven is het importeren en exporteren van entiteiten met behulp van data-applicaties. In deze scriptie verstaan we hieronder applicaties die entiteiten beschikbaar stelt en in sommige gevallen ook weer ontvangen naar verrijking door een afnemer. Utrecht Your Way is een klant met deze behoefte die Madcap een oplossing liet ontwikkelen. Deze oplossing is ontwikkelt met Drupal omdat Madcap hier in gespecialiseerd is. Door het gemis aan kennis en communicatie van zowel de klant als de uitvoerende partijen zijn hiervoor verkeerde ontwerpkeuzes gemaakt. Deze scriptie biedt een oplossing welke door gebruik van bestaande functionaliteiten in Drupal, ontwikkelaars veel tijd en werk kan besparen en de klant veel geld. Ontwikkelaars worden met deze oplossing veel onderzoek en ontwikkeling bespaard en hoeven zich hierdoor niet druk te maken over het onderhoud en de beveiliging van de data die gemigreerd wordt. Door de groeiende ondersteuning van Drupal in de wereld wordt de software goed onderhouden en kunnen bestaande modules uit de gemeenschap worden ingezet voor deze oplossing. De oplossing biedt een generieke aanpak die het mogelijk maakt om verschillende dataapplicaties te koppelen aan een Drupal-installatie. Door gebruik te maken van een dataqueue wordt data direct opgeslagen maar niet direct zichtbaar. Op deze manier kunnen beheerders op ieder moment de data omzetten naar bruikbare content. Hierbij wordt rekening gehouden met het terugzetten, bijwerken en controleren van compleetheid van de data. Van belang is hierbij dat er geen data verloren gaat. Scriptie Migreren met Drupal // Jelle den Butter //

5 4 Het afstudeerbedrijf In dit hoofdstuk zullen de organisatie en zijn activiteiten omschreven worden waarbinnen het afstudeerproject wordt uitgevoerd. Madcap Madcap is sinds 2001 aannemer van web applicaties. Hierbij zijn zij in staat het ontwerp, realisatie en beheer van een applicatie te verzorgen. Madcap maakt gebruik van open source software. De realisatie van de internetapplicaties gebeurt voornamelijk met Drupal. Drupal is een open source cms / framework geschreven in PHP. Drupal [Bron 1] heeft een wereldwijde gemeenschap van ontwikkelaars voor het realiseren van internetplatformen / websites / internetapplicaties. 10% van de bedrijvenwebsites in de wereld gebruiken dit platform [Bron 5]. Madcap heeft de kennis om op het gebied van multimedia, mobiele websites, e-commerce maatwerk-oplossingen te realiseren met dit systeem. Madcap bestaat uit 30 medewerkers en maakt onderdeel uit van de Q4 groep [Afbeelding 4.1]. Deze bestaat uit meerdere open-source bedrijven die met verschillende softwarepakketten web-applicaties realiseren voor hun klanten. Op deze manier kan de Q4 groep een grote groep klanten voorzien van software op maat. Afbeelding 4.1 Q4 Groep Projectontwikkeling De projecten worden gerealiseerd binnen de afdeling development [Afbeelding 4.2]. Binnen het betrokken project wordt gecommuniceerd met contactpersonen van verschillende klanten om de eisen,wensen, mogelijkheden te bespreken en producten op te leveren. Er worden verschillende gesprekken met sales en pre-sales gedaan om wensen toe te voegen aan de scope van een project of toekomstig project. De projecten binnen Madcap zijn zeer divers. Projecten kunnen verschillen van een eenvoudige website met content, tot koppelingen met verschillende data uitwisselingen en interactie met externe systemen. Voorbeeld eenvoudig project: Voorbeeld Complex project: Scriptie Migreren met Drupal // Jelle den Butter //

6 Het project dat leidend is voor deze scriptie is Utrecht Your Way (UYW). Dit project is een complex platform voor de provincie Utrecht. Voorbeelden: (acceptatie-server) Afbeelding 4.2 : Organigram Madcap Scriptie Migreren met Drupal // Jelle den Butter //

7 5 De opdracht Dit hoofdstuk beschrijft de toedracht van de opdracht en definieert deze met een hoofdvraag en deelvragen. In de aanpak wordt beschreven op welke wijze deze vragen beantwoord gaan worden. 5.1 Het probleem De provincie Utrecht heeft door Madcap een platform laten ontwikkelen bestaande uit meerdere websites. Deze websites tonen data welke geïmporteerd wordt uit een database met evenementen en locaties. Beide zijn entiteiten bestaande uit velden met informatie over de mogelijkheden in de provincie Utrecht. Dit kan bijvoorbeeld een rondvaart of een bioscoop film zijn op een specifieke locatie. Deze database genaamd NDTRC van het VVV [Bron 2] heeft de structuur van de content op het platform bepaald. De content wordt iedere nacht geüpdate en is hierbij direct zichtbaar op de websites. Wanneer content aangepast of toegevoegd wordt op het platform wil de NDTRC alleen de aangepaste evenementen weer in de aangeleverde oorspronkelijke vorm terug ontvangen. Om de informatievoorziening van het platform uit te breiden heeft de provincie besloten nog twee partijen te betrekken met een database met evenementen en locaties. Dit betreft de G!ds [bron 3] en het Uitburo [bron 4] welke een verschillende structuur en protocollen gebruiken voor het verzenden van data (entiteiten). Omdat de mobiele markt ook groeit zijn er ook externe partijen betrokken om applicaties te schrijven die de data (of gedeelten hiervan) uit het platform gebruiken. De nieuwe wensen vragen om een generieke oplossing voor het migreren voor data. In de huidige situatie kunnen de nieuwe databases niet in de structuur worden opgenomen en zal er data verlies optreden [Afbeelding 5:1] Met mogelijke nieuwe afnemers van de data kan ook het aanpassen van de huidige export-module veel tijd kosten. Na een scan op de Drupal website blijkt dat Drupal geen duidelijke aanpak / oplossingen biedt voor het migreren (importeren en exporteren) van gegevens zoals Utrecht Your Way dat wenst. Voor de realisatie van het migreren van de NDTRC waren drie maanden nodig. Dit betekend dat de overige twee database ook veel geld en tijd zullen kosten. Een effectievere en overzichtelijke oplossing is van belang. Scriptie Migreren met Drupal // Jelle den Butter //

8 Afbeelding 5.1 : Huidige situatie met G!ds voorbeeld Utrecht Your Way zal een case zijn voor deze scriptie. De gewenste koppelingen (dataapplicaties) in dit project worden meegenomen in het onderzoek. Binnen Utrecht Your Way (UYW) zijn er verschillende belanghebbende partijen. 1. De provincie Utrecht welke een goede informatievoorziening wil voor de provincie. 2. Drie verschillende leveranciers van data. NDTRC (VVV), Uitburo, en G!ds. Allen leveren via verschillende protocollen hun data aan in een gestructureerde xml. 3. Externe partijen welke gebruik willen maken van de data welke geïmporteerd en verrijkt wordt in Utrecht Your Way. Mogelijk willen deze partijen data van een specifieke leverancier, regio, tijd, omgeving filteren. Scriptie Migreren met Drupal // Jelle den Butter //

9 5.2 De hoofd- en deelvragen Onderstaand is de hoofdvraag geformuleerd die tot de oplossing zal leiden. Met welke generieke aanpak kan een beheerbare contentmigratie worden gerealiseerd tussen Drupal en externe data-applicaties? Onderstaand de deelvragen welke tot een antwoord voor de hoofdvraag zullen leiden. Deze deelvragen beantwoorden in chronologische volgorde delen van de hoofdvraag om zo tot een ontwerp voor een aanpak te komen. 1. Wat is Drupal? 2. Waaruit bestaat content in Drupal? 3. Wat is een externe data-applicatie? 4. Welke beheermogelijkheden zijn van belang bij een contentmigratie? 5. Welke principes binnen Drupal maken een generieke oplossing mogelijk? 6. Welke mogelijke interfaces biedt Drupal aan gebruikers voor het beheren van migraties? 7. Welke modules en functionaliteiten biedt Drupal reeds? 8. Welke handelingen moet Drupal verrichten om gegevens te migreren? 9. Welke niet bestaande functionaliteiten moeten worden gerealiseerd om migraties mogelijk te maken? 5.3 De aanpak Onderstaand is de aanpak beschreven voor het komen tot het antwoord op de hoofdvraag. Er zal een onderzoek worden gedaan die de bron is van zowel het functionele als technische ontwerp. Het gaat in op de eisen en wensen van de gebruikers van het systeem. Hiermee kan worden bepaalt welke logica en data het systeem moet verwerken en kunnen hieraan eisen worden gesteld. Vervolgens zal worden bekeken over welke functionaliteiten het systeem (Drupal) reeds beschikt en welke door de ontwikkelaar gerealiseerd moeten worden om migraties te realiseren. Met deze wetenschap zal worden geconcludeerd welke deelvragen zijn beantwoord en kan er tot een ontwerp worden gekomen om de overige vragen en de hoofdvraag te beantwoorden. In het hoofdstuk realisatie zal worden beschreven in hoeverre de realisatie is voltooid en welke stappen essentieel zijn voor het realiseren van de oplossing. Het beschrijft een volgorde van opbouw van het systeem en welke componenten en welke mogelijkheden er zijn om deze in de toekomst te hergebruiken. Scriptie Migreren met Drupal // Jelle den Butter //

10 6 Het onderzoek In dit hoofdstuk worden de functionaliteiten onderzocht die gerealiseerd en geconfigureerd moeten worden om tot een succesvolle migratie te komen. Het bevat alle informatie betreft de eisen en wensen, gebruikers, logica en mogelijkheden van een migratie. Van belang hierbij is wat Drupal reeds als functionaliteiten levert en welke hiervoor moeten worden geschreven. 6.1 Eisen en wensen van de gebruiker Onderstaande zijn met de case Utrecht Your Way geïnventariseerde wensen die er zijn voor gebruikers van het migratie-proces. Binnen het project is er gecommuniceerd met zeven verschillende partijen welke elk andere wensen en eisen hebben betreft het migreren van data. Met het samenvoegen van deze gegevens kan een goed beeld worden verkregen van een generieke migratie-proces. Om te beginnen is van het van belang te weten welke groepen gebruikers gebruik maken van het systeem. Tevens waren dit ook de verschillende betrokken partijen met het UYW-project. Webmasters van het platform. Leveranciers van eigen content (Provincie Utrecht) Leveranciers van de databases (G!ds, NDTRC, Uitburo). Externe partijen welke de content en van Utrecht Your Way gebruiken. Gebruikers van het administratie systeem. Binnen Utrecht Your Way willen de beheerders de migraties kunnen controleren en volgen. Hierbij willen zij volledig inzicht in wat er wordt gemigreerd en als er iets wordt genegeerd willen zij ook zien waarom en wat er wordt genegeerd zodat zij hier acties op kunnen ondernemen naar een partij. Zij willen controle op het handmatig invoeren en verrijken of verarmen van de data. Dataapplicaties mogen data niet ongecontroleerd automatisch zichtbaar maken. Beheerders moeten de data kunnen modereren en weigeren. Wel moeten automatische validaties kunnen worden uitgevoerd bij het importeren van data om tijd te besparen. Beheerders willen een consistente database met gegevens waarin geen dubbele data voorkomt. Met verschillende interfaces moeten zij data kunnen toevoegen en de structuur van content kunnen wijzigen. Beheerders van de content mogen alleen toegang tot data welke relevant is voor de betreffende website. Het kan zijn dat sommige data uit een data-applicatie niet relevant is voor weergave op het platform. Naast de geïmporteerde data moet het ook mogelijk zijn handmatig content toe te voegen zoals dit normaliter binnen Drupal gebeurt. Beheerders moeten de configuratie van de verschillende externe data-applicaties (leveranciers) kunnen beheren met enkele eenvoudige interfaces. Hierbij eisen zij de volgende instellingen te kunnen wijzigen: Locatie (Kan in de vorm van een uri) Authenticatie Limieten en bereiken van gegevens Filters (uitsluiten van specifieke data (entiteiten) welke niet relevant is voor migratie) Doel (voor het exporteren) Scriptie Migreren met Drupal // Jelle den Butter //

11 Tijdstip (Wanneer moet de automatische migratie worden uitgevoerd?) De beheerder van de data moet de bovenstaande instellingen zelf kunnen controleren en beheren zodat de ontwikkelaar hier niet bij betrokken hoeft te blijven. Gezien de beperkte technische kennis van de klant is het wel aan te raden een standaardconfiguratie ter beschikking te stellen zodat de klant een referentiekader heeft. Wanneer instellingen geheel verkeerd staan kunnen deze op deze wijze eenvoudig worden hersteld. Naast de configuratie van de data-applicaties moet er ook een mogelijkheid zijn tot configureren van de protocollen die het beschikbaar stellen van data naar externe partijen mogelijk maken. Dit voor zowel het exporteren in het oorspronkelijke formaat (aangeleverde formaat [voorbeeld 6.1]) als het beschikbaar stellen van content met eventuele filters op zowel items als specifieke velden. Alle beheersmogelijkheden dienen op een centrale plek beschikbaar te zijn zodat een beheerder gemakkelijk de gehele configuratie kan doorlopen. Kort samen gevat moeten beheerders content kunnen configureren, importeren, controleren, valideren, aanmaken, verwijderen en consumeren vanaf een centrale plaats in het systeem. Hierin moet ook onderscheid worden gemaakt in de verschillende typen beheerders. Hoofd beheerders mogen het gehele systeem beheren en inrichten. Data-applicatie beheerders welke beperkte rechten hebben op bijvoorbeeld een enkele dataapplicatie of alleen data mogen doorzetten naar content. Content beheerders mogen alleen de aangemaakte content verrijken en verwijderen. Tenslotte is er een groep die de data kan exporteren (consumeren) voor extern gebruik. Gebruikers / bezoekers van het systeem mogen bij alle genoemde processen geen hinder ondervinden en moeten de data zo compleet mogelijk en gecontroleerd aangeboden krijgen. Scriptie Migreren met Drupal // Jelle den Butter //

12 6.2 De handelingen van het systeem Met de eisen en wensen uit hoofdstuk 6.1 kunnen een aantal handelingen worden bepaalt welke Drupal moet uitvoeren. [Afbeelding 6.6] In dit hoofdstuk worden deze omschreven in vier categorieën. Dit betreft het configureren van de applicaties, het importeren en exporteren van de data en het verdere beheer hiervan om de content te modereren. Afbeelding 6.6 : Diagram met handelingen 1. Content beheer Beheerders moeten de geïmporteerde content kunnen beheren zoals Drupal dit normaliter ook doet. Dit houdt onder andere het toevoegen, wijzigen (verrijken van geïmporteerde content) en verwijderen van content in. Omdat het kan gebeuren dat er data vanuit een data-applicatie bijgewerkt wordt, moet ook deze optie geautomatiseerd te gebruiken zijn wanneer gewenst. Deze functionaliteit kan ook gebruikt worden wanneer besloten worden content uit te breiden met data welke eerder niet geïmporteerd werd. Handelingen a) Nieuwe content aanmaken vanuit de data-applicaties. b) Content modereren en bijwerken. c) Content bijwerken met nieuwe data vanuit de data-applicaties. 2. Externe data-applicatie configuratie. Met enkele eenvoudige beheerinterfaces moet een klant de externe data-applicaties kunnen beheren. Hieronder valt het maken van de verbinding met de data-applicaties Scriptie Migreren met Drupal // Jelle den Butter //

13 en het uitvoeren van automatische taken. Deze taken bevatten het importeren, converteren en valideren van data in Drupal. Om meer controle uit te kunnen oefenen kunnen er statistieken voor de taken, geïmporteerde data en handelingen met betrekking tot de data-applicatie worden opgemaakt. Dit geeft meer overzicht en bevorderd de communicatie tussen verschillende belanghebbende partijen. Handelingen a) Configuratie van de data-applicatie verbinding. b) Het in- en uitschakelen van de data-applicatie en bepalen op welke tijden een import/export wordt uitgevoerd. c) Het opslaan van statistische gegevens. 3. Data importeren. Deze handelingen betreffen het importeren van data en het aanmaken van content op de website. Gezien de klant data wil kunnen modereren vereist het importeren een tussenstap [ref 1] [ref 2]. Dit betekend dat data (entiteiten) niet direct aangemaakt wordt als content maar eerst door een moderatie-proces moet waarna ze wordt aangemaakt als content. Hiervoor wordt de geïmporteerde data eerst in een wachtrij opgeslagen. Vereiste data kan worden geïmporteerd als content, maar ook genegeerd wanneer deze niet relevant is, en later alsnog aan de content worden toegevoegd. Op deze manier kan de data in de wachtrij ook fungeren als back-up en zonder toestemming worden overschreven door bijgewerkte data vanuit een data-applicatie. Data kan automatisch in de wachtrij gezet worden zonder dat de klant hier op hoeft te wachten of het systeem trager wordt omdat er op dat moment ook veel gebruikers aanwezig zijn. Deze handeling kan worden ingesteld als nachtelijke taak. De data zal niet direct zichtbaar zijn voor de gebruikers wat de kwaliteit van de content kan waarborgen [Afbeelding 6.7]. Binnen Utrecht Your Way werd data direct geïmporteerd als content wat veelal leidt tot ongewenste, ontbrekende en dubbele data. Om dit mogelijk te maken moeten enkele beheerinterfaces beschikbaar gemaakt worden om deze processen te configureren en te sturen. Hierbij moet data in sommige gevallen worden geconverteerd om binnen de veld-type van drupal-content te passen. Data moet binnen dit proces worden herkend als zijnde een content-type en op de juiste plek binnen de website worden aangemaakt als content. Dit proces moet ook omgekeerd kunnen worden wanneer deze data vanuit content weer wordt geëxporteerd. Handelingen a) Importeren in een wachtrij. b) Geïmporteerde data weigeren omdat deze niet relevant is of de inhoudt niet voldoet. c) Controle op compleetheid van de data. d) Velden van data (entiteiten) converteren voor gebruik als content. e) Data door middel van controles laten toewijzen binnen een content-structuur (Acties uitvoeren bij het importeren van een entiteit). f) Data door middel van een eenvoudig proces bijwerken of verwijderen omdat de data-applicatie deze wijzigingen vereist. g) Data converteren zodat deze leesbaar is voor de gebruikers van de website. Scriptie Migreren met Drupal // Jelle den Butter //

14 4. Data exporteren. Er zijn twee verschillende typen exports te onderscheiden. De eerste exporteert een entiteit in de vorm waarin deze geïmporteerd is compleet met eventueel verrijkte data uit de content. Veld validaties moeten worden toegevoegd op velden waarbij de afnemer van de data dit verlangt. Op deze wijze kan de data worden gefilterd. In de tweede vorm kan content worden geëxporteerd zoals een derde partij dit definieert. Dit betekend dat zowel content-items als velden kunnen worden gefilterd. Handelingen a) Het definiëren van instanties om content te exporteren. b) Validaties uitvoeren op de te exporteren data in oorspronkelijke vorm. c) Het beschikbaar stellen van data in oorspronkelijke vorm met zowel de ongebruikte als geïmporteerde en verrijkte content. d) Het beschikbaar stellen van eventueel gefilterde content. Scriptie Migreren met Drupal // Jelle den Butter //

15 Afbeelding 6.7 : wachtrijstructuur Scriptie Migreren met Drupal // Jelle den Butter //

16 6.3 Data-analyse Dit hoofdstuk geeft inzicht in welke data wordt gemigreerd en op wijze dit moet gebeuren. Hierbij zal gebruik worden gemaakt van de informatie verkregen vanuit de data-applicaties in Utrecht Your Way. Er zal vastgesteld worden wat de meest effectieve manier is om de data te verplaatsen op basis van de eisen en wensen van de gebruikers. De definitie data-applicatie binnen de context van dit project houdt in dat het een applicatie betreft welke entiteiten verstrekt aan derden met van een data transfer protocol of een access protocol. Deze entiteiten bevatten een structuur met velden en hun veld-namen. Onderstaand een aantal willekeurige voorbeelden van protocollen welke het versturen van data met php mogelijk maken. XML-RPC [Prot 1] SOAP [Prot 2] (Gebruikt door de G!ds-database) REST [Prot 3] (Gebruikt door het Uitburo en NDTRC) XINS AMF JSON FTP Kijkend naar de case UYW verstuurt de data-applicatie gegevens naar Drupal en vice versa. Dit wordt gerealiseerd met twee verschillende protocollen. Dit zijn SOAP en XML-RPC waarvoor de betreffende databases een API ter beschikking hebben gesteld met een handleiding. Bovenstaande protocollen zijn een greep uit de mogelijkheden. PHP ondersteunt niet het gebruik van alle protocollen. Er zal een tussen-oplossing moeten worden gerealiseerd alvorens data over gestuurd kan worden naar Drupal door middel van een protocol dat wel ondersteunt wordt. De oplossing moet de mogelijkheid hebben om ieder protocol te implementeren ongeacht op welke wijze deze data verstuurt. De data moet door met een aantal in de oplossing standaard beschikbare functies de mogelijkheid hebben de data op te slaan in Drupal. Wanneer data in Drupal is opgeslagen kan de data worden verrijkt en moet deze ook weer in oorspronkelijke vorm naar de data-applicaties worden terug gestuurd. Wanneer een andere partij dan de leverancier de data wil ontvangen betekend dit ook dat data in andere vormen moet kunnen worden terug gestuurd waarbij entiteiten en velden gefilterd worden. Bij Utrecht Your Way wordt data van drie verschillende partijen gemigreerd van en naar verschillende data-applicaties. Verschillende protocollen werden hierbij toegepast. NDTRC en Uitburo maken gebruik van REST en de G!ds database kan worden opgehaald door middel van SOAP aanroepen. Voor REST kunnen verschillende datatypen worden overgestuurd. In beide situaties is gekozen voor XML. XML is de meest gebruikte de standaard voor het versturen van data [Ref 6] Er is dan ook gekozen om de NDTRC database [Voorbeeld 6.1] en G!ds database [Voorbeeld 6.2] te analyseren voor de structuur van de te migreren data. Scriptie Migreren met Drupal // Jelle den Butter //

17 In beide gevallen betreft het databases welke xml terug geven met attributen, velden met enkele of meerdere waarden welke in nodes kunnen worden opgeslagen zonder dat hiervoor nieuwe oplossingen voor gerealiseerd hoeven te worden. <item distance="0" trcid="aae587ad-bd29-4c5b-8f63-3f31d6ba8247" title="nederlands Pluimveemuseum" shortdescription="barneveld staat bekend als de bakermat van de Nederlandse Pluimveehouderij. En die leidende rol vervult het nog steeds. Logisch dus dat het Nederlands Pluimveemuseum daar staat. "thumbnail=" createdon=" T10:56:37" modifiedon="16/03/ :56:19" validator="vbt Validatoren" owner="vvv Barneveld Invoerders" address="hessenweg 2 A, 3771 RB BARNEVELD, NL" city="barneveld" latlng="52,132725;5,603080" calendarsummary="ma: gesloten di-za: 10:00-17:00 uur zo: gesloten" itemtype="museum" itemtypeids="54" location="nederlands Pluimveemuseum" cancelled="false" pctcomplete="85" wfstatus="approved" published="ja" deeplink=" availablefrom="6/04/ :56:37" availableto="31/12/ :59:59" translationlanguages="de;en;fr;;it;es" startdate="1/02/2011 0:00:00" phone=" " url=" Voorbeeld 6:1 : NDTRC (REST) <soap:envelope xmlns:soap=" <soap:body> <ns1:haalorganisatiemetidresponse xmlns:ns1=" <return> <ns2:aangemaaktdoor xmlns:ns2=" <ns3:id xmlns:ns3=" <ns3:naam xmlns:ns3=" importgebruiker</ns3:naam> <ns3:organisatieid xmlns:ns3=" </ns2:aangemaaktdoor> <ns2:aanmaakdatum xmlns:ns2=" 15T20:29:47+01:00</ns2:aanmaakDatum> <ns2:afkorting xmlns:ns2=" <ns2:beschrijving xmlns:ns2=" Eemland, locatie Woudenberg</ns2:beschrijving <ns2:volledigenaam xmlns:ns2=" Eemland, locatie Woudenberg</ns2:volledigeNaam> <ns2:wijzigingsdatum xmlns:ns2=" 21T16:38:39+01:00</ns2:wijzigingsDatum> <ns2:zichtbaarvoorpubliek xmlns:ns2=" </return> </ns1:haalorganisatiemetidresponse> </soap:body> </soap:envelope> Voorbeeld 6:2 : G!ds (Soap) data Scriptie Migreren met Drupal // Jelle den Butter //

18 De structuur van de xml De structuur van data verschilt bij ieder protocol. Dit betekend dat de data die naar Drupal ondervangen moet worden op een generieke wijze moeten worden getransformeerd naar het formaat van Drupal. Daarnaast moet er ook een mogelijkheid zijn deze terug te transformeren. De onderstaande elementen zijn te onderscheiden. Voorbeelden zijn gemarkeerd in [Voorbeeld 6.1] en [Voorbeeld 6.2] : Velden zonder veldnamen. Velden met veldnamen (tags) Velden met Attributen en attribuutnamen Velden met velden (parent-child relaties) Scriptie Migreren met Drupal // Jelle den Butter //

19 6.4 De mogelijkheden van Drupal In dit hoofdstuk wordt onderzocht welke functionaliteiten Drupal bevat zodat duidelijk wordt welke functionaliteiten nog geprogrammeerd moeten worden aan de hand van de handelingen uit hoofdstuk 6.2. Hierbij wordt gekeken naar hoe Drupal data opslaat en welke grafische interfaces en principes hiervoor beschikbaar zijn De Drupal principes Drupal is een flexibel en schaalbaar systeem onder de noemer CMS/Framework. Hierbij is er een middenweg gezocht tussen beide factoren om te voorkomen dat het enkel voor een specifiek doel gebruikt kan worden en tegelijkertijd te begrijpen is voor nieuwe gebruikers. Drupal heeft de volgende uitgangspunten: Modulair en uit te breiden, Code-kwaliteit, Houden aan de standaarden, Open standaarden, Lage eis van resources, Makkelijk in gebruik, Samenwerking Drupal geeft een ontwikkelaar enkele entiteiten om een website structuur te geven en deze op verschillende manieren te tonen op de website. Voor alle entiteiten is het mogelijk het aantal data-velden uit te breiden. Afbeelding 6.1 : Drupal-lagen De basis-installatie van Drupal kent de volgende entiteiten: Gebruikers Dit zijn de gebruikers van het systeem welk met verschillende rollen en rechten verschillende taken binnen Drupal kunnen hebben met betrekking tot beheer en gebruik. Nodes Nodes zijn de entiteiten welke gedefinieerd worden in content-typen. In een contenttype kunnen verschillende velden met verschillende data-typen worden gedefinieerd om zo verschillende data vorm te geven als bijvoorbeeld een auto, huis, nieuwsbericht of een andere willekeurige entiteit. Zoals deze ook gemigreerd kunnen worden. Taxonomieën Deze entiteit kan worden gebruikt in velden van andere entiteiten voor het vormen van lijsten, woordenschat, opslag van zogenaamde tags of het categoriseren van Scriptie Migreren met Drupal // Jelle den Butter //

20 entiteiten. Entiteiten zijn geschikt voor verschillende vormen van data. Dit maakt Drupal tot een geschikt systeem voor migraties. Zoals zichtbaar in [afbeelding 6.1] zijn de entiteiten (data) (zie laag 1) binnen Drupal de onderste laag. In de tweede laag is te zien dat er modules aanwezig zijn. De Drupal-gemeenschap levert standaard een aantal contributed modules (contributed betekend aangeleverd door de gemeenschap) mee in de basis-installatie. Zonder deze modules doet het framework niets. Op de website van Drupal zijn naast deze modules ook nog duizenden andere contributed modules te vinden. Elk leveren zij een eigen functionaliteit aan het framework in de vorm van tabellen, structuren,veldsoorten, blokken of logica. Ontwikkelaars kunnen zelf bijdragen aan deze Contrib modules of een eigen module ontwikkelen om nieuwe functionaliteit te ontwikkelen of bestaande functionaliteit van modules uit te breiden. Dit gebeurt met hooks welke beschreven staan in de Drupal API. Voor de weergave worden er in de derde laag menu's en blokken gedefinieerd welke de nodes en taxonomieën in verschillende vormen weer kunnen geven. In de vierde laag worden er permissies gedefinieerd voor het limiteren van de toegang van de onderste drie lagen. De vijfde laag bepaald het uiterlijk van de website. Door de abstractie van de lagen binnen Drupal hoeven ontwikkelaars zich alleen bezig te houden met de realisatie van modules, zodat veiligheid, consistentie en weergave niet onderhouden hoeven worden en deze zelfs door externe partijen kunnen worden beheerd en ontwikkelt. Al de te ontwikkelen functionaliteiten moeten worden gerealiseerd in de modulelaag waarna configuratie hiervan in de bovenliggende lagen plaats kan vinden. Drupal-codestyle Binnen de Drupal gemeenschap zijn duidelijke richtlijnen voor het programmeren binnen Drupal. Deze richtlijnen schrijven onder andere de onderstaande relevante regels voor: Code formaten Object georiënteerd programmeren Foutverwerking Database-queries (sql) Bestanden Benoeming van functie-namen binnen modules Gebruik van Drupal-hooks Afvangen van onveilige functies (tegengaan van sql-injectie, cross site scripting) Gebruik van commentaar in de code. Geen opmaak in de code. Al deze richtlijnen zijn te vinden op: Scriptie Migreren met Drupal // Jelle den Butter //

21 Hooks Door gebruik van hooks binnen modules kunnen functionaliteiten bij elkaar inhaken en de functionaliteit ombuigen van het importeren van bijvoorbeeld een veld naar het exporteren van een veld en het ondertussen converteren hiervan. Hooks maken het schrijven van veel functionaliteiten overbodig door bestaande functies over te nemen en aan te passen. Kijk voor een voorbeeld in [Bijlage 1] Nodes De te migreren data wordt opgeslagen in nodes. Deze nodes bestaan uit gedefinieerde content-typen [Afbeelding 6:2] welke in Drupal met de bestaande interface kunnen worden gecreëerd. Deze kunnen door de beheerders van het systeem zelf worden gewijzigd en aangemaakt. Vervolgens kunnen deze worden gekoppeld aan de verschillende gemigreerde data. Afbeelding 6.2 : Voorbeeld content-type Veld-typen Drupal kent veel verschillende veld-typen. Naast dat deze het datatype kunnen specificeren van een veld in een node kunnen deze ook acties uitvoeren. Bij een migratie kunnen deze een veld koppelen aan een actie en kunnen gegevens geconverteerd worden per gekoppeld veld met behulp van hooks Taxonomieën Taxonomieën zijn lijsten met termen welke geclassificeerd en gekoppeld kunnen worden aan nodes [afbeelding 6.3] Deze kunnen in hiërarchische volgorde worden opgeslagen en worden toegevoegd bij wijze van het maken van een menustructuur of het taggen van entiteiten. Wanneer een een taxonomy (vocabulary) toegevoegd wordt aan content-typen kan deze gebruikt worden voor het categoriseren van nodes. Ook aan taxonomieën kunnen velden worden toegewezen. Binnen de gewenste oplossing kan de structuur van de te migreren data worden opgeslagen in een taxonomie en kunnen velden van content worden gekoppeld aan acties om de velden te converteren en op te slaan. Scriptie Migreren met Drupal // Jelle den Butter //

22 Afbeelding 6:3 : Voorbeeld taxonomie Zie [Bijlage 1] voor meer informatie over de Drupal API, hooks en rechten Content Dit gedeelte beschrijft hoe content binnen Drupal opgeslagen kan worden in nodes en op welke manier dit gebeurt. Ook is van belang op welke wijze hier toegang tot kan worden verkregen. Data binnen Drupal wordt opgeslagen in zowel nodes en entities. Dit zijn abstracte datavormen binnen Drupal welke de datastructuur van een web-applicatie kunnen bepalen. Nodes worden gevormd door content-typen. Een content-type definieert hoe content binnen Drupal wordt weergegeven en uit welke velden deze bestaat. Voor ieder veld kan worden gedefinieerd uit welk type data deze bestaat. Deze content wordt per item een node genoemd en kan bijvoorbeeld velden definiëren voor een concert, auto of recept. Overige entiteiten kunnen net als nodes data opslaan en uitgebreid worden met velden. Deze worden gedefinieerd door modules en kunnen uit dezelfde velden worden opgemaakt als nodes of gebruik maken van verschillende entiteiten (taxonomieën, gebruikers, nodes) in velden met relaties. Drupal ondersteunt standaard de volgende velden: Boolean Decimal File Float Image Integer List (Tekst of numeriek) Long text Long text en summary Term reference Text (varchar) Scriptie Migreren met Drupal // Jelle den Butter //

23 Er zijn ook contrib modules beschikbaar met additionele veld-typen. Een mogelijkheid voor content-migraties is hieraan enkele zelf toe te voegen. De gegevens in Drupal worden opgeslagen in een sql database. Nodes hebben standaard de volgende velden. Wellicht kunnen deze worden gebruikt bij het opslaan van gegevens bij een migratie. Nid Id van de node Vid Id van de node revision Type Contenttype van de node. Bepaald de structuur, weergave en alle extra velden. Language Taal Title Titel-veld Uid Id van de eigenaar Status Status van de node Created Aanmaakdatum Changed Wijzigingsdatum Comment Commentaar geactiveerd? Promote Aanbieden op de voorpagina Moderate Gereed voor moderatie? Sticky Uitlichten? Tnid Node met de vertaling Translate Node vertalen? Nodes zijn een abstract begrip binnen Drupal. Er zijn functies beschikbaar om deze nodes op te halen, bewerken en hier met modules logica mee uit te voeren. Deze zijn terug te vinden in de Drupal API. Integraal wordt hierbij het content-type van de node meegenomen en de data gevalideerd door modules. Alle gedefinieerde velden binnen een content-type zijn in staat meerdere waardes per veld op te slaan. In de standaard node-velden kan alleen een enkele waarde worden opgeslagen. Nodes kunnen met hun functionaliteit zowel ingezet worden voor het opslaan en tonen van de content als het opslaan van de data in de data-queue. Scriptie Migreren met Drupal // Jelle den Butter //

24 6.4.3 Grafische interfaces Er zijn verschillende interfaces toe te passen in Drupal die zonder enige aanpassingen gegenereerd kunnen worden vanuit verschillende entities en nodes. Hiervoor is een reference-table opgesteld [Bron 7] Tabellen Afbeelding 6.4 : Voorbeeld tabel Tabellen kunnen selectieboxen, knoppen en acties bevatten per tabel, rij en kunnen gesorteerd worden per kolom [Afbeelding 6.4] Dit geeft de mogelijkheid om probleemloos content te kunnen beheren. Formulieren Formulieren kunnen in verschillende vormen eenvoudig worden weergegeven met alle veldtypen en, indien nodig, in meerdere stappen en uitklapbare groepen [Afbeelding 6.5]. Het is ook mogelijk om meerdere formulieren achter elkaar in een wizard te plaatsen. Afbeelding 6.5 : Voorbeeld formulier Paden Drupal maakt gebruik van zogenaamde paden. Dit betekend dat alle nodes, taxonomieën en gebruikers hier te definiëren zijn als argumenten. Paden met daarin zogenaamde pagecallbacks zorgen voor een navigatiestructuur in waarin rechten uitgedeeld kunnen worden. Zo Scriptie Migreren met Drupal // Jelle den Butter //

25 kunnen verschillende niveaus van beheerders worden toegewezen voor het beheren van de migraties. Bijvoorbeeld Wanneer de volgende paden worden aangemaakt: formulieren/formulier1 formulieren/formulier2 formulieren/formulier3 Bij het navigeren naar formulieren/ zat er een menu weergegeven worden naar deze drie formulieren. Wanneer aan formulier1 rechten worden gegeven aan beheerdera maar niet aan beheerderb zal dit resulteren de weergave van de links naar formulier1 en formulier Bestaande modules Onderstaand de contributed modules die functionaliteiten bevatten die in de vorige deelvragen zijn geïnventariseerd. Deze maken het schrijven van enkele functionaliteiten overbodig. Views module Views geeft ontwikkelaars de mogelijkheid om queries samen te stellen en deze in verschillende vormen weer te geven. Door middel van views kunnen verschillende beheerpanelen worden samengesteld waarop selecties en acties kunnen uitgevoerd met entiteiten binnen het systeem. Afbeelding 6.5 : Voorbeeld view Scriptie Migreren met Drupal // Jelle den Butter //

26 Services module Services geeft de mogelijkheid om nodes (content-typen) beschikbaar te stellen naar buiten door er verschillende services aan te verbinden. Voorbeelden zijn REST, XMLRPC, SOAP en JSON-RPC. Deze services zijn met Drupal te configureren waardoor integratie hiervan gemakkelijk uitgevoerd kan worden door middel van enkele interfaces. Bij het beschikbaar stellen kunnen ook specifieke velden worden uitgesloten. De service module heeft niet de functionaliteit om de geïmporteerde data aan te bieden in het oorspronkelijke formaat zoals deze werd aangeboden door de data-applicatie. Validaties moeten specifiek worden geschreven voor een data-applicaties voor het filteren van de items zelf. Dit is mogelijk met hooks. Views bulk operations (VBO) module De module stelt een ontwikkelaar in staat om tabellen te maken waarop bulk operaties (acties) kunnen worden uitgevoerd. Op deze manier kunnen er selecties gemaakt worden van entities welke gemigreerd kunnen woorden waarna de verschillende handelingen kunnen worden uitgevoerd. Elysia cron module De module stelt de beheerder van een website in staat om alle taken (crontab) op bepaalde tijden in te stellen. Hiermee kunnen de entiteiten met gespecificeerde regelmaat worden opgehaald en opgeslagen in de data-queue. Rules module De Rules module geeft de mogelijkheid aan beheerders om acties, loops met regels en verschillende conditionele validaties uit te voeren. Dit kan op het niveau van een proces, handeling op verschillende entiteiten en hun velden. Dit kan toegepast worden wanneer er content moet worden aangemaakt. Features module Deze module is in staat functionaliteit en structuren aangemaakt in Drupal op te slaan. Deze kunnen worden geëxporteerd als module zodat de entiteiten en functionaliteiten die met de modules zijn gegenereerd probleemloos overgenomen kunnen worden in een nieuwe migratie-omgeving. Dit voorkomt een lange handleiding voor het realiseren van het migratieproces. Scriptie Migreren met Drupal // Jelle den Butter //

27 6.5 De Conclusie Met behulp van de vorige hoofdstukken zijn de meeste deelvragen uit hoofdstuk 5 beantwoord. Hieruit zijn een aantal behoeften en functionaliteiten voortgekomen die migraties met Drupal mogelijk maken. De onderstaande [tabel 6.1] geeft een overzicht van de functionaliteiten welke met behulp van bestaande principes, grafische interfaces en bestaande modules kunnen worden gerealiseerd. Voor het de realisatie van deze functionaliteiten moeten functionele en technische ontwerpen worden gemaakt om met behulp van de verkregen informatie uit het onderzoek tot een complete oplossing te komen en deze te bewijzen. Reeds bestaande functionaliteit/modules is gemarkeerd met blauw. Hierbij zijn enkele kleine toevoegingen en configuratie nodig. Deze zullen in de ontwerpen worden toegelicht. Functionaliteiten Conversie-functies koppelen aan de entiteit-structuur Entiteit-structuur koppelen aan content-velden Overzicht gekoppelde contentvelden entiteit-structuur t.o.v content Algemene instellingen Instellingen voor syndicatie services Individuele Connector instellingen Batch- / Cron-instellingen Handmatige batch activeren Statistieken geïmporteerde entiteiten Rapportage van alle handelingen binnen de migratie Exporteren van content (content-typen) Exporteren van entiteiten in oorspronkelijk formaat Content aanmaken vanuit date-queue item Opvragen compleetheid van informatie in data-queue-item Data-queue-item afwijzen Data-queue-item verwijderen Validaties toekennen aan content-velden Content bewerken / aanmaken Content herstellen met de data-queue Content updaten vanuit de data-queue Tabel 6.1 : Te realiseren functionaliteiten Scriptie Migreren met Drupal // Jelle den Butter //

28 7 Het functioneel ontwerp Voor het ontwerp van de applicatie / modules wordt er gekeken naar de eisen, wensen, functionaliteiten, data en gebruikers binnen het systeem en wordt hiermee een ontwerp gerealiseerd. Het ontwerp is opgebouwd met informatie vanuit hoofdstuk Niet-functionele eisen In het ontwerp zijn een aantal niet-functionele eisen opgenomen welke geïnventariseerd zijn aan de hand van eisen van de klant Utrecht Your Way. De eisen zijn gekoppeld aan de ISO 9126 standaard [Bron 7] om de kwaliteit van software te kunnen controleren en behouden. Deze zijn vastgelegd in het Functioneel ontwerp dat door Madcap is opgesteld en samengevat in de onderstaande tabel [Tabel 7.1]. Id Non-functional requirements ISO 9126 NF1 Het migreren van willekeurige data met entiteiten. Flexibiliteit NF2 Het migreren van data in oorspronkelijke vorm. Efficientie NF3 Het gebruik maken van Drupal Beveiliging NF4 Het uitvoeren migraties op ieder moment. Flexibiliteit NF5 Gebruikers verschillende rechten kunnen geven. Beheerbaarheid NF6 Gebruik maken van bestaande functionaliteiten. Onderhoudbaarheid NF7 Het aantal weer te geven velden moet kunnen worden aangepast. Flexibiliteit Tabel 7.1 : Niet-functionele eisen 7.2 Functionele eisen In [Tabel 7.2] zijn alle functionaliteiten uit de conclusie van hoofdstuk 6 overgenomen met een MOSCOW-prioriteit. De functionaliteiten zijn ondergebracht in usecases welke de functionaliteit omschrijven. Functionaliteiten die als Must have zijn aangevinkt zijn verplicht voor de werking van de migratie. Functionaliteiten die als Should have of Could have zijn aangevinkt zijn functies om het gehele proces meer beheersbaar te maken maar zijn niet vereist voor het migratie-proces. Scriptie Migreren met Drupal // Jelle den Butter //

29 Usecases / Functionaliteiten Must have Should have Could have Want to have Datastructuur en conversie functies koppelen Conversie-functies koppelen aan de entiteit-structuur Entiteit-structuur koppelen aan content-velden Overzicht gekoppelde contentvelden entiteit-structuur t.o.v content Configuratie data-applicaties Algemene instellingen Instellingen voor syndicatie services Individuele Connector instellingen Batch- / Cron-instellingen Handmatige batch activeren Statistieken geïmporteerde entiteiten Rapportage van alle handelingen binnen de migratie Consumeren van content importeren van content (content-typen) Importeren van entiteiten in oorspronkelijk formaat Data-queue beheren Content aanmaken vanuit date-queue item Opvragen compleetheid van informatie in data-queue-item Data-queue-item afwijzen Data-queue-item verwijderen Content beheren Validaties toekennen aan content-velden Content bewerken / aanmaken Content herstellen met de data-queue Content updaten vanuit de data-queue Tabel 7.2 : Functionaliteiten In het onderstaande usecasemodel zijn alle usecases opgenomen uit [Tabel 7.2] en toegewezen aan de verschillende rollen. De usecases bestaan ieder uit meerdere functionaliteiten maar vullen gezamenlijk de functionaliteit van een usecase in. Afbeelding 7.1 : Usecase-diagram Scriptie Migreren met Drupal // Jelle den Butter //

30 7.3 De ontwerpbeslissingen De ontwerpbeslissingen zijn genomen op basis van hoofdstuk 6 waarin de deelvragen zijn opgenomen. Deze beslissingen leiden tot het technische ontwerp van een generieke aanpak binnen Drupal [Afbeelding 7.2] 1. Een connectie tot stand brengen met een data-applicatie module (NF1, NF3). Voor iedere data-applicatie zal een module geschreven worden welke de datastroom koppelt aan de taxonomie met structuur en de data-queue. Deze module heeft een aantal basis-functies en kan worden uitgebreid met hooks. Iedere data-applicatie heeft de mogelijkheden zijn eigen functionaliteit te implementeren met verschillende validaties binnen de migratie. Iedere module levert zijn eigen configuratiemenu. Deze wordt opgenomen in de menu-structuur waar alle data-applicaties beheert worden. Gerelateerd aan de configuratie van de data-applicaties zal de Elysia-cron module de automatische verwerkingen beheren. 2. Opslaan van de data in Drupal (NF6, NF2). Zoals hoofdstuk 6.2 onderbouwt biedt de data-queue de oplossing voor opslaan van data zodat deze kan worden gemodereerd. Deze kan worden toegepast in de vorm van een content-type. Weergave en acties op deze data-queue zullen worden gerealiseerd met de Views module en Views Bulk Operations module. Hiermee is het mogelijk eigen acties te laten uitvoeren op de geselecteerde items in de queue. Met deze acties kan de beheerder de data zorgvuldig controleren, valideren en converteren voordat deze aangemaakt wordt als content. 3. Selecteren welke data gekoppeld worden aan de content-typen velden (NF1, NF6). De beheerder kan de data koppelen aan de velden van content-typen waardoor velden uit data ook genegeerd kunnen worden. Deze koppeling gebeurt in de taxonomieën waar de structuur van de data-applicaties wordt opgeslagen. Bij deze koppeling worden ook de content-velden en conversie-functies gekoppeld. Wanneer een veld van of naar content wordt weg geschreven zal deze door de geselecteerde functie worden geconverteerd. 4. Data uit de queue opslaan als content (NF7). Een wizard zal de data uit de queue met de gekoppelde velden aanmaken als content. De betreffende beheerder kan de data hierbij indien gewenst handmatig controleren en eventueel verrijken voordat deze als content beschikbaar komt. Het wijzigen van de data zal in de bestaande node-formulieren gerealiseerd worden. De wizard zal stoppen wanneer alle gekoppelde content-velden zijn gevuld en de nodes opgeslagen. 5. Content beschikbaar stellen voor externe data-applicatie. Voor het beschikbaar stellen van de data zal de services module gebruikt worden voor het beschikbaar stellen van de content. Door gebruik van hooks kunnen velden eventueel worden geconverteerd voordat deze geëxporteerd worden. Scriptie Migreren met Drupal // Jelle den Butter //

31 6. Afbeelding 7.2 : Flowdiagram nieuwe situatie Scriptie Migreren met Drupal // Jelle den Butter //

32 7.4 De usecase-specificaties Bij het schrijven van het ontwerp is er gebruik gemaakt van usecase-specificaties om de functionaliteiten uit te schrijven. Om hiervan een beeld te geven is in dit hoofdstuk de usecase Datastructuur en conversie-functies koppelen uitgeschreven. Usecase-specificaties Datastructuur en conversie-functies koppelen Doel Het aanmaken van content vanuit de data-queue. Samenvatting Binnen deze use-case kan content worden aangemaakt vanuit de data-queue. Hierbij worden velden geconverteerd naar het juiste data-type. Bij de weergave van de items is het mogelijk de compleetheid van de data te laten berekenen met een controle van de verplichte velden. De gebruiker kan de content met behulp van een wizard laten aanmaken. Hierbij kunnen alle velden met een formulier gecontroleerd en gewijzigd worden. Er is ook een mogelijkheid om content direct laten aanmaken vanuit de data-queue. Wanneer de content niet voldoet aan de gestelde eisen kan deze worden geweigerd of geheel worden verwijderd. Bij het weigeren blijven de data-queue items bestaan. In het geval van verwijderen zal de inhoud wanneer gewenst worden verwijderd en niet meer worden geïmporteerd om het import proces te versnellen. Betrokken rollen Superadmin, Administrator, Contentadmin Triggers Deze usecase wordt gebruikt wanneer nieuwe items in de data-queue zijn aangemaakt. Paden 1. Een tabel met data-queue items wordt getoond. 2. [actie] De compleetheid van geselecteerde items kan worden berekend voor ieder item. 3. Er wordt een actie uitgevoerd op items. Bij het aanmaken worden velden geconverteerd wanneer conversie-functies zijn gekoppeld aan de content-velden. Indien velden moeten worden gecontroleerd gebeurd dit voordat het formulier wordt getoond. a) [actie] Items worden met behulp van een wizard aangemaakt zodat de velden kunnen worden gecontroleerd en gewijzigd. Een of meerdere nodes worden doorlopen. Alternatieve paden 3. a) [actie] Items worden direct aangemaakt als content. b) [actie] Items worden verwijderd. c) [actie] Items worden geweigerd. Eindtoestand Scriptie Migreren met Drupal // Jelle den Butter //

33 Nodes met content. Business rules NF1 Migreren van willekeurige data met entiteiten. Schermontwerp Afbeelding 7.2 : Beheren van de data-queue 7.5 Conclusie Het functioneel ontwerp is voor het ontwerpen van een goede oplossing een juiste inventarisatie geweest voor alle functionaliteiten in de applicatie. Hierbij gaven de schermontwerpen een goed beeld voor de structuur van de applicatie. De usecasespecificaties zijn sterk hulpmiddel bij het maken van de sequentie-diagrammen in het technisch ontwerp. Echter is het door het gebruik van bestaande modules moeilijk in te schatten welke stappen er soms gemaakt worden met de verschillende entiteiten. Het is dan ook aan te raden de documentatie en code van deze modules eerst door te lezen. Scriptie Migreren met Drupal // Jelle den Butter //

34 8 Het technisch ontwerp Het technische ontwerp dient bij de realisatie als structuur van de applicatie. Hierin zijn zowel de fysieke applicatie-structuur als de sequentie-diagrammen in opgenomen die zijn gebaseerd op de usecase-specificaties. In dit hoofdstuk wordt een sequentiediagram toegelicht. 8.1 Sequentie-diagram Het onderstaande sequentie-diagram [Afbeelding 8.1] toont de de functie-aanroepen binnen de usecase Datastructuur en conversie-functies koppelen 8.2 Conclusie Afbeelding 8.1 : Sequentie-diagram actie 3a Doordat Drupal een uitgebreide en overzichtelijke API tot zijn beschikking heeft is het voor ontwikkelaars een eenvoudig proces om tot sequentie-diagrammen te komen. Deze zijn een leidraad voor het realiseren van de functionaliteiten. Door naar de invoer en uitvoer te kijken van hooks en functies kunnen op een eenvoudige wijze de flow binnen Drupal en modules worden bepaalt. Het is aan te bevelen deze diagrammen te maken voor het verhogen van de onderhoudbaarheid van het systeem. Scriptie Migreren met Drupal // Jelle den Butter //

35 9 Realisatie Voor de realisatie van het migratie-proces is het realiseren van een generieke aanpak niet mogelijk door de lange geschiedenis die Madcap met het project Utrecht Your Way heeft. Door de grote druk van verschillende partijen en een beperkte tijd en budget wordt de kwaliteit benadeelt. Er is dan ook voor gekozen maar enkele functionaliteiten uit deze scriptie over te nemen in het huidige project. Echter betekend dit niet dat dit geen perspectieven biedt voor de toekomst. Door het bijhouden van import-statistieken en het analyseren hiervan kunnen argumenten aangevoerd worden om het systeem alsnog de nodige vorm te geven zodat deze in de toekomst zonder problemen aan de niet-functionele eisen kan voldoen. Utrecht Your Way biedt veel ruimte voor verbetering en heeft Madcap veel kennis gegeven voor projecten met deze behoeften in de toekomst. Met de gerealiseerde en reeds ontworpen prototypen kunnen in de toekomst nieuwe klanten worden bedient. 9.1 Conclusie Het realiseren van een migratie met verschillende data-applicaties is een proces van inventarisatie van de documentatie, technieken en entiteiten. Communicatie met alle betrokken partijen over de toekomst van het systeem is hierbij heel belangrijk. Het maakt het verschil tussen een snelle specifieke oplossing, of een generieke aanpak waarmee in de toekomst veel geld en tijd bespaard kan worden op het moment dat een systeem moet worden uitgebreid. Drupal biedt vanuit de gemeenschap een aantal kant en klare functionaliteiten welke door de flexibiliteit van Drupal hergebruikt kunnen worden om deze in te passen in het migratie-proces. Scriptie Migreren met Drupal // Jelle den Butter //

36 10 De eindconclusie Bij het opstarten van deze afstudeeropdracht was er nog veel onduidelijk voor zowel mij als Madcap over het project Utrecht Your Way en de manier waarop Drupal met migraties kan omgaan. Madcap heeft mede hierdoor niet direct de keuze kunnen maken om de migraties op een generieke wijze op te pakken. Deze scriptie heeft hier veel inzichten in gebracht door in brede zin te kijken naar het verplaatsen van data tussen Drupal en data-applicaties. Dit met een zeer effectieve en eenvoudige oplossing waarbij het onderhoud minimaal is door het gebruik van bestaande functionaliteiten en principes. Uit het onderzoek is gebleken dat veel bestaande modules gebruikt kunnen worden om tot het gewenste resultaat te komen. Door deze modules kan veel ontwikkeling worden voorkomen doordat de gemeenschap van Drupal deze onderhouden. Dit heeft positieve gevolgen op veiligheid van de software welke van belang is bij migraties. Ook wordt veel tijd en geld bespaard voor de klant en kan deze op eenvoudige manier migraties beheren. Doordat Drupal veel ondersteuning biedt met bestaande modules en een goede documentatie is het eenvoudig om tot een technisch ontwerp te komen en de bestaande functionaliteiten her te gebruiken in nieuwe modules Verbeteringen Doordat Utrecht Your Way en Madcap in de initiële fase van het project kozen voor de structuur van de NDTRC is het tot op heden niet mogelijk geweest de oplossing uit deze scriptie te implementeren. Enkel het beheren van de cron taken, het opmaken van statistieken en de taxonomie met de structuur zijn deels gerealiseerd. Dit betekend dat er voor Utrecht Your Way nog enkele grote wijzigingen doorgevoerd kunnen worden om de onderhoudbaarheid, beveiliging en flexibiliteit te verhogen. De druk van de klanten zorgt er nu vaak voor dat er gekozen wordt voor snelle work-arounds. Wanneer dit gedaan wordt kan de kwaliteit achteruit gaan en kan de geboden oplossing niet worden bereikt doordat functionaliteiten te specifiek worden gerealiseerd naar de eisen van de klant Aanbevelingen Met de geboden oplossingen kan Madcap in de komende projecten een generiek migratieproces aanbieden voor gebruikers die gebruikersvriendelijk is en te beheren is door verschillende partijen en verschillende verantwoordelijke beheerpartijen. Omdat veel functionaliteiten nog niet zijn gerealiseerd is de oplossing nog niet getest op prestaties. Omdat in de data-queue oplossing alle data bewaard wordt, is het mogelijk dat dit gevolgen heeft op de prestaties voor het beheer van het migratie-proces. Daarom is mijn aanbeveling om de oplossing goed te testen alvorens deze bij een klant in te zetten. Scriptie Migreren met Drupal // Jelle den Butter //

37 10.3 Persoonlijke conclusie Persoonlijk heb ik met dit project veel geleerd over de communicatie met verschillende partijen in een project. De vele eisen en wensen zijn soms moeilijk te inventariseren en daarnaast zijn er ook tegenstrijdige belangen. Voor mij betekende dit dat ik de kwaliteit van de software in het oog moet blijven houden en blijven kijken naar de het product in plaats van de emoties van de gebruikers. Doordat het project Utrecht Your Way een lopend project was en hierin door mij ook functionaliteiten gerealiseerd zijn terwijl de afstudeeropdracht werd uitgevoerd was het soms lastig het onderzoek en het ontwerp van elkaar te scheiden. Desondanks heeft dit project mij veel kennis gebracht van Drupal en ETL-processen. Deze tweede heeft mij veel geleerd over het denken in generieke oplossingen. Deze kennis en ervaring kan van pas komen wanneer software modulair, uitbreidbaar en herbruikbaar moet zijn. Scriptie Migreren met Drupal // Jelle den Butter //

38 11 De bronnen 11.1 Diverse bronnen [bron {getal}] 1. Drupal website 2. VVV Nederland 3. G!ds voor Nederland 4. Uitburo 5. Buildwidth 6. ISO 9126 standaard 7. Referentie tabel grafische interfaces De Protocollen [prot {getal}] 1. XMLRPC 2. SOAP 3. REST Scriptie Migreren met Drupal // Jelle den Butter //

39 11.3 De Literatuur [lit {getal}] De onderstaande artikelen hebben bijgedragen aan de ontwerpkeuzes in de aanpak voor de migraties. 1. Concept modeling for ETL processes %20Modeling%20ETL%20processes%20in%20DW.pdf 2. From Semistructured data to xml 3. A UML Based Approach for Modeling ETL %20Modeling%20ETL%20processes%20in%20DW.pdf 4. Migrating data-intensive Web Sites into the Semantic Web 5. Storing and Querying Ordered XML Using a Relational Database System 6. A General Technique for Querying XML Documents Scriptie Migreren met Drupal // Jelle den Butter //

40 12 De bijlagen 12.1 Bijlage 1 : Extra informatie Drupal Drupal API De drupal API bestaat uit een bibliotheek op Drupal.org waarin alle beschikbare functies, classen, globals, constanten en variabelen staan gedefinieerd. Hierbij kunnen voorbeelden worden toegevoegd en staat gedefinieerd hoe hooks worden toegepast. Hooks Het uitbreiden of toevoegen van functionaliteit met een module kan door middel van hooks. Een hook is een functie waar door andere functies op ingehaakt kan worden. Voorbeeld hook_menu kan binnen modules worden gebruikt om een menu aan te maken in een Drupal installatie. Bijvoorbeeld voor de module 'example' zal dit example_menu zijn. Het gedeelte 'hook' wordt altijd vervangen door de module naam waarna deze hook-functie in diezelfde module gebruikt moet worden. Dit betekend dat bij iedere keer dat het framework een pagina laat deze hook wordt uitgevoerd en een menu-item voor de 'example' module wordt ingesteld. Binnen een menu functie is het mogelijk om gebruikers permissies te geven tot pagina's. Permissies Binnen Drupal kunnen er permissies aan menu-items worden toegewezen. Deze permissies worden toegewezen aan rollen. Deze rollen worden uitgedeeld aan gebruikers van Drupal. Op deze wijze kunnen er binnen een module meerdere rechten worden uitgedeeld aan gebruikers. Naast de hooks in Drupal heeft een ontwikkelaar alle vrijheid om functies te ontwikkelen. Dit kan mogelijk ook object georiënteerd. De ontwikkelaar dient zich hiervoor wel aan enkele voorschriften te houden genaamd: Drupal coding standards. Deze zijn te vinden op: Scriptie Migreren met Drupal // Jelle den Butter //

41 12.2 Bijlage 2 : Plan van Aanpak Scriptie Migreren met Drupal // Jelle den Butter //

42 1 Over het bedrijf De afstudeeropdracht zal uitgevoerd worden bij Madcap. Zij zijn aannemer van het project Utrecht Your Way voor de provincie Utrecht. 1.1 Achtergrondinformatie Madcap Madcap is sinds 2001 aannemer van web applicaties. Hierbij zijn zij in staat het ontwerp, realisatie en beheer van een applicatie te verzorgen. Madcap maakt voornamelijk gebruik van open source software. De realisatie van de internetapplicaties gebeurt voornamelijk in het Drupal cms/framework. Hierbij heeft Madcap alle kennis in huis om op het gebied van multimedia, mobiele websites, e-commerce en community's maatwerk oplossingen te realiseren in PHP of andere programmeertalen waar nodig. Madcap bestaat uit 25 medewerkers en maakt onderdeel uit van de Q4 groep. Deze bestaat uit meerdere open source bedrijven welke met verschillende softwarepakketten werken. Op deze manier kan de Q4 groep een grote groep klanten aantrekken. Op de locatie waar de afstudeeropdracht wordt uitgevoerd werken directie, projectmanagers, developers, themers, sales en administratieve medewerkers. 1.2 Ontwikkelomgeving De afstudeeropdracht wordt uitgevoerd binnen de afdeling development en projectmanagement. De afdeling projectmanagement is voornamelijk betrokken bij het stellen van de kaders,voorwaarden, communicatie met de klant en begeleiding van het project. Communicatie binnen deze afdeling verloopt met Jaap Broeders en Arjan van der Pol. Binnen de afdeling development worden de drupal-modules gerealiseerd. Binnen deze afdeling kan ik met mijn vragen terecht bij Elizabeth Escribano. Zij is de medeontwikkelaar binnen het project Utrecht Your Way en is betrokken geweest bij de ontwikkeling van deelprojecten binnen UYW. In mijn positie als ontwikkelaar ben ik actief binnen development waarin ik zelf communiceer met de klant en partijen van derden om invloed uit te oefenen op de op te leveren producten. Scriptie Migreren met Drupal // Jelle den Butter //

43 2 Aanleiding Utrecht Your Way (UYW) is een toeristisch platform welke door de provincie Utrecht is opgezet om toeristen en inwoners van Utrecht te informeren over de culturele mogelijkheden binnen de provincie Utrecht. Deze informatie wordt weergegeven in evenementen en locaties. Om een overzichtelijk beeld te geven zijn deze opgedeeld in verschillende websites van VVV's en specifieke websites over de gebieden binnen Utrecht. Deze kunnen vervolgens door de verschillende toeristenorganisaties worden gebruikt. Enkele voorbeelden: 1. Hoofdportaal 2. Streekportaal VVV hoofdportaal 4. VVV locatie De websites binnen verschillende domeinen zijn allen gerealiseerd met een enkele Drupal Content Management Systeem distributie. Drupal is in staat de gevraagde functionaliteiten van Utrecht Your Way te ondersteunen met modules. Echter moeten deze modules door Madcap ontwikkeld worden voor bijvoorbeeld een kalender, domeinondersteuning of het weergeven van locaties en evenementen. Dit op een door de klant in een functioneel ontwerp gedefinieerde manier. Utrecht Your Way heeft Madcap om een aantal basisfunctionaliteiten gevraagd voor het platform waaronder een database-koppeling. Gezien de database met evenementen en locaties zo compleet mogelijk moet zijn heeft UYW besloten twee nieuwe externe partijen te benaderen. Te weten de G!ds en het Uitburo. Zij leveren elke een eigen database-verbinding met beide een eigen datastructuur en techniek. Gezien de bestaande structuur van UYW betekend dit dat de datasctructuren niet overeen komen. Dit maakt dat het integreren van deze databases een complex en lastig traject zal worden. Deze complexiteit is onnodig met een generieke opbouw van de Drupal-structuur. Hiermee kan veel tijd bespaard worden gezien het bouwen van de NDTRC-koppeling drie maanden heeft geduurd. Om tot een goed product te komen moet er gecommuniceerd worden met de beheerders, ontwikkelaars van de databases en met het communicatiebureau dat UYW begeleid. Scriptie Migreren met Drupal // Jelle den Butter //

44 3 Probleemstelling 3.1 Het probleem Drupal is een wereldwijde community voor het realiseren van internetplatformen / websites / internetapplicaties. 10% van de bedrijvenwebsites in de wereld gebruiken dit platform [Bron: Buildwidth.com]. Bedrijven kiezen voor oplossingen met Drupal doordat deze flexibel is, goed onderhouden wordt en vele mogelijkheden biedt om gebruikers zelf hun product te laten beheren. Door snelle ontwikkelingen binnen het systeem is het schrijven van documentatie en het overzicht houden van de mogelijkheden een tijdrovende taak. Na kort onderzoek blijkt dat Drupal geen duidelijke aanpak / oplossingen biedt voor het importeren en exporteren van gegevens met zoals Utrecht Your Way dat nodig heeft. Voor een opdracht als Utrecht Your Way lag het door het gemis van een duidelijke aanpak niet voor de hand een generieke oplossing te maken voor het importeren van gegevens. Hierdoor is de structuur van NDTRC overgenomen voor UYW wat nu tot de nodige uitdagingen leidt bij het uitbreiden het aantal te importeren externe databases. In de toekomst zal er ook een api nodig zijn om de gegevens te exporteren. Ook hiervoor is een snellere aanpak van belang. Voor het importeren van de NDTRC waren drie maanden nodig. Dit is niet de bedoeling. Utrecht Your Way zal een case zijn voor de scriptie welke generieke oplossingen voor het migreren met Drupal geeft. Ook de overige koppelingen worden meegenomen in het onderzoek voor deze generieke oplossingen. Met een duidelijke generieke aanpak kunnen toekomstige vergelijkbare project tijdbesparend zijn voor zowel Madcap als de Drupal-community. 3.2 Hoofdvraag Om makkelijk tot een antwoord te komen voor de gegeven opdracht zijn er verschillende deelvragen te formuleren. Deze geven antwoord op de volgende hoofdvraag. Met welke generieke aanpak kan een beheerbare contentmigratie worden gerealiseerd tussen Drupal en externe data-applicaties? 3.3 Deelvragen 1. Wat is Drupal? 2. Waaruit bestaat content in Drupal? 3. Wat is een externe data-applicatie? 4. Welke beheersmogelijkheden zijn van belang bij een contentmigratie? 5. Welke principes binnen Drupal maken een generieke oplossing mogelijk? 6. Welke mogelijke interfaces biedt Drupal aan gebruikers voor het beheren van migraties? 7. Welke modules en functionaliteiten biedt Drupal reeds? 8. Welke handelingen moet Drupal verrichten om gegevens te migreren? 9. Welke niet bestaande functionaliteiten moeten worden gerealiseerd om migraties mogelijk te maken? Scriptie Migreren met Drupal // Jelle den Butter //

45 4 Aanpak 4.1 Aanpak Binnen de categorie School/Scriptie van de planning zullen enkele onderzoeken gedaan worden naar Drupal. Drupal-modules, applicatie- en databasestructuur en welke interface de klant te zien krijgt. Alle deelvragen zijn redelijk alomvattend en zullen uitgebreid worden met deelvragen bij de uitwerking in de scriptie. Bij het beantwoorden zullen enkele tabellen gebruikt worden om tekst toe te lichten. Om een duidelijk inzicht te krijgen in wat Drupal is en wat de principes zijn van het framework zal hier met behulp van de meest recente Drupal-installatie en de Drupal documentatie een helder beeld van worden geschetst. Met de bovenstaande informatie kan logica van de opdracht worden onderzocht. Wanneer duidelijk is met welke gegevens gemigreerd kan worden zal er een onderzoek gedaan worden naar de datastructuur van Drupal en hoe hier een generieke aanpak voor kan worden ontworpen om migraties mogelijk te maken. Hierbij zullen de mogelijke interfaces worden voorgesteld en wordt er een pad beschreven welke de data door de applicatie zal bewandelen (flow). De beschreven structuur zal worden onderbouwd met prototypen en codevoorbeelden welke door zowel Madcap als de Drupal-community worden gecontroleerd en kunnen worden gebruikt bij de realisatie van een migratie. 4.2 Uitvoering De planning voor de case is ontstaan vanuit de volgende werkwijze. Zoals in de planning te zien is de opdracht opgedeeld in een aantal activiteiten. De activiteiten zijn opgedeeld in categorieën. De categorieën ontwikkelen en testen kunnen worden geïnterpreteerd als iteraties. Daarnaast is er verantwoording / scriptie welke een eigen iteratie kent en de gehele planning doorloopt. Iteraties hebben een vaste levensloop binnen de case: Iteratie Onderzoek / verantwoording 1. Onderzoek / bestuderen 2. Ontwerp 3. Verantwoording / Scriptie 4. Prototypes ontwikkelen. 5. Testen 6. Verantwoording / Scriptie Voor iedere activiteit geldt dat er tussentijdse communicatie kan plaatsvinden met zowel de klant als de projectleider. Scriptie Migreren met Drupal // Jelle den Butter //

46 4.3 Projectgrenzen en randvoorwaarden scriptie Het platform Utrecht Your Way zal ongewijzigd te blijven ongeacht de toevoeging van de te schrijven modules. De scriptie zal zich beperken tot enkele onderzoeken en ontwerpen. Enkel de case met de G!ds-module zal worden gerealiseerd. De uitgewerkte oplossingen in de scriptie zullen niet direct worden opgenomen en doorgevoerd in Utrecht Your Way doordat de klant hier over beslist. Drupal wordt momenteel uitgegeven in versie 6 en 7. Oplossingen zullen voor zowel Drupal 6 als 7 worden gegeven. Voorbeelden van broncode van de G!ds-module case komen uit Drupal 6. Voorbeelden van broncode voor de uitgewerkte oplossingen zullen Drupal 7 zijn met oog op nieuwe projecten welke hierin gerealiseerd zullen worden. 4.4 Te realiseren producten Gezien deze situatie moet het volgende worden gerealiseerd. Drupal-modules welke aan de eisen en wensen van UYW voldoen. Scriptie Een generieke structuur en aanpak voor het importeren en exporteren van gegevens met Drupal. Scriptie Migreren met Drupal // Jelle den Butter //

47 5 Projectactiviteiten met een beschrijving Legenda kleuren Scriptie / School Communicatie Ontwikkelen Testen / Optimaliseren Vrije uren Scriptie Migreren met Drupal // Jelle den Butter //

48 Scriptie Migreren met Drupal // Jelle den Butter //

49 Scriptie Migreren met Drupal // Jelle den Butter //