Eindverslag. Yet Another Meeki Sync Tool. IN3404 Bsc-Project Robert Ros Jip Man Vuong

Transcriptie

1 Eindverslag Yet Another Meeki Sync Tool IN3404 Bsc-Project Robert Ros Jip Man Vuong TU Delft, Technische Informatica Datum: 19 september 2008 Opdrachtgever: Arco Iris B.V. Contactpersoon opdrachtgever: Ir. D. Los TU begeleider: Ir. C. Pronk Coördinator BSc: Ir. B.R. Sodoyer

2 Eindverslag YaMST Voorwoord Op 7 April zijn wij begonnen met het bachelorproject voor Arco Iris b.v. in Dordrecht. Dit project is voor ons de afsluiting van de bachelorfase van de opleiding Technische Informatica aan de Technische Universiteit Delft. Het bachelorproject duurde voor ons 11 weken waarin wij fulltime aanwezig waren bij Arco Iris in Dordrecht. Het project wordt afgerond met een presentatie op een nader te bepalen datum. Arco Iris heeft ons de opdracht gegeven om een tool te ontwikkelen die ervoor zorgt dat de webwinkel Meeki product- en klantgegevens gebruikt uit een backoffice-systeem zoals Exact Globe. Orders die in Meeki worden geplaatst moeten ook opgenomen worden in het backofficesysteem. Graag willen wij Dirk-Jan Los bedanken voor de begeleiding bij dit project. Verder willen wij ook de begeleiders aan de TU, ir. C. Pronk en ir. B.R. Sodoyer, bedanken voor hun adviezen en coördinatie van het project. Wij hebben 11 plezierige en leerzame weken achter de rug waarin wij veel ervaring hebben opgedaan. Dordrecht, juli 2008 Robert Ros Jip Man Vuong I

3 YaMST Eindverslag Inhoudsopgave 1 Inleiding Probleemstelling Doelstelling Organisatie project Planning Communicatie Documentatie Analyse Opdrachtbeschrijving Ontwerp WebInterface BeheerInterface Core Modules SynchronisationModule CometModule SyncDatabase Utilities DataAdapters IBackofficeAdapter IMeekiAdapter CometAdapter Implementatie Core WebInterface YaMSTControl YaMSTService SyncDatabase SynchronisatieModule Loggen van problemen SwanLibrary (klantspecifieke klassen) SwanLibraryLoader SwanDataAdapters Projectevaluatie Wat ging goed? Wat kon beter? Conclusie en aanbevelingen Conclusie Aanbevelingen...15 II

4 Eindverslag YaMST 1 Inleiding In dit project is er een tool ontwikkeld waarmee het mogelijk is om een webshop te koppelen aan een bestaand backoffice-systeem. Arco Iris heeft in samenwerking met Wendrich (vormgeving) en Quercis (Exact implementatiepartner) de webwinkel Meeki ontwikkeld. Meeki is een standaard webwinkel met een koppeling naar een backoffice-systeem. Momenteel bestaat er nog geen koppeling tussen de webwinkel en de backoffice-systemen. Deze koppeling wordt in dit project ontwikkeld. 1.1 Probleemstelling De door Arco Iris ontwikkelde webwinkelsoftware Meeki is momenteel een op zichzelf staand informatiesysteem. Nieuwe klanten gebruiken in veel gevallen al een eigen backoffice-systeem waarin zij voorraad, bestellingen en prijsafspraken beheren (CRM/ERP). Omdat Meeki momenteel geen koppeling kent zouden deze klanten voorraad, bestellingen en prijsafspraken op meerdere locaties en/of systemen moeten beheren. Het probleem is dus het ontbreken van de synchronisatie tussen Meeki en de bestaande backoffice-systemen. 1.2 Doelstelling Arco Iris wil dit probleem verhelpen door in Meeki een synchronisatielaag in te bouwen die ervoor zorgt dat gegevens tussen Meeki en de verschillende bestaande backofficesystemen uitgewisseld worden. Hierdoor krijgen klanten een webwinkel die aansluit op hun bestaande informatiesystemen. Het is de bedoeling dat bijvoorbeeld prijs- en voorraadinformatie (semi-) realtime worden aangepast op de webpagina s van de webwinkel (Meeki) als deze in het backoffice-systeem worden aangepast. Hierdoor wordt Meeki een stuk interessanter voor potentiële klanten. Tenslotte is het van belang dat in de toekomst andere, nu buiten beschouwing gelaten, backofficesystemen eenvoudig ondersteund kunnen worden door Meeki. In eerste instantie is het de bedoeling dat er ondersteuning komt voor Exact Globe (ERP/CRM pakket) Inleiding 1

5 YaMST Eindverslag 2 Organisatie project 2.1 Planning Aan het begin van het project hebben wij een plan van aanpak opgesteld waarin wij ook een globale tijdsplanning hadden gemaakt. Het was in deze fase van het project moeilijk te bepalen hoeveel tijd we per onderdeel nodig zouden hebben, daarom hebben wij een globale planning gemaakt van de dingen die we per week zouden doen: Week 1: 7 april t/m 11 april Aanpassen/bijwerken Plan van Aanpak. Orienteren op.net omgeving en opzetten van deze omgeving. Uitzoeken van API s van backoffice-systemen (Exact Globe). Week 2-4: 14 april t/m 2 mei Requirements opstellen. Functioneel ontwerp document uitwerken. Logisch datamodel maken (ERD). Testplan en testcases opstellen. Technisch ontwerp maken met behulp van UML diagrammen. Week 5-8: 5 mei t/m 30 mei Implementeren van de ontworpen klassendiagrammen. Testen aan de hand van het eerder gemaakte testplan. Evalueren/aanpassen van de implementatie. Testverslag opstellen. Omdat we eigenlijk al aan zagen komen dat we met de tijd in de knel zouden komen hebben we voor de laatste weken de planning iets aangepast: Week 7: 19 mei t/m 23 mei Voorbereiden van de werkomgeving (installeren en configureren van de benodigde software) Globale opzet van alle klassen maken (stubs) Beginnen met implementeren en testen van de mapping database, de data-adapters (met name de Backoffice-adapter) en de functionaliteit voor het loggen van problemen. Mapping database en de logging-functionaliteit is afgerond aan het eind van deze week Week 8: 26 mei t/m 30 mei Afronden backoffice-adapter (incl. testen) Afmaken Meeki-adapter (incl. testen) 2 Organisatie project

6 Eindverslag YaMST Beginnen met synchronisatie-module (synchroniseren, het detecteren van updates met behulp van de adapters) Hierbij horen ook een aantal delen in YaMST main, zoals de webinterface voor externe aanroepen. Ook moeten er integratie-tests gedaan worden tussen de synchronisatie-module en de adapters. Documentatie schrijven van het model en de interfaces. Week 9: 2 juni t/m 6 juni Afronden synchronisatiemodule (incl. unittest) en YaMST main Beheerinterface en documentatie schrijven. Week 10: 9 juni t/m 13 juni Integratie testen van de beheerinterface, synchronisatiemodule en de adapters en problemen verhelpen. Installatieprocedure documenteren. Afmaken eindverslag en documenten bijwerken. Week 11: 16 juni t/m 20 juni Afronden van implementatie en documentatie. 2.2 Communicatie Tijdens het project hebben we constant contact gehad met de opdrachtgever. Omdat wij elke dag op kantoor werkten konden we met onze vragen en problemen direct bij de opdrachtgever terecht. Om toch regelmatig terug te kijken op wat we in een week gedaan hebben, hebben we elke maandag een uurtje met elkaar de week doorgesproken en de ingeleverde documenten doorgesproken. Tijdens deze sessies hebben we ook besproken wat we in de daaropvolgende week zouden doen. Met de begeleider van de TU maakten we eens in de twee weken een afspraak om de ingeleverde documenten door te spreken. Hij gaf hierbij altijd goede opbouwende kritiek die we goed konden gebruiken. Ook heeft de heer Pronk ons via de mail tips en advies gegeven. Wij hebben dit als zeer prettig ervaren. 2.3 Documentatie Omdat het de bedoeling is dat er van een aantal zaken duidelijk documentatie moet zijn hebben we besloten dat deze wordt geschreven na de implementatie. Wij doen dit om te voorkomen dat de documentatie inconsistent wordt met de implementatie. Tijdens het programmeren hebben we de code duidelijk gedocumenteerd met de zogenaamde XML documentatie-tags. Deze worden net zoals de javadoc annotations in commentaar in de code geplaatst zodat er later een API beschrijving kan worden uitgedraaid. Organisatie project 3

7 YaMST Eindverslag 3 Analyse In de analysefase hebben we onderzoek gedaan naar de opdracht. We hebben samen met de opdrachtgever de opdrachtbeschrijving geformuleerd. Aan de hand hiervan en een gesprek met de opdrachtgever hebben we de requirements opgesteld die terug te vinden zijn in het RAD. Tijdens deze fase hebben we ook goed gekeken naar de documentatie van zowel Exact Globe en ZenCart. We hebben enkele keren overleg gehad met Quercis over de Exact -implementatie. 3.1 Opdrachtbeschrijving De op XML gebaseerde koppeling dient generiek ontworpen en gerealiseerd te worden voor het koppelen van back-office systemen met de open source webwinkel. Deze backoffice-systemen maken gebruik van diverse databronnen (o.a. CSV-bestanden, SQL databases) die onderling verschillend van structuur zijn. Onderwerp van de koppeling zijn product-, prijs-, voorraad-, klanten ordergegevens. Het onderzoek naar hoe de koppeling het beste opgezet kan worden, welke aspecten daarbij een belangrijke rol spelen en welke technieken daarvoor toegepast kunnen worden is onderdeel van de opdracht. Nadat de koppeling gerealiseerd is wordt deze toegepast op verschillende webwinkels, waarbij tevens de AJAX-Comet technologie wordt toegepast. Deze technologie zorgt ervoor dat aanpassingen in de back-office (bijvoorbeeld prijzen en voorraden) rechtstreeks op de pagina van de webwinkel worden ververst (live updates), waarbij de webserver enkele variabelen in de webpagina aanpast zonder dat de gebruiker hiervoor actie onderneemt. Concreet houdt dit het volgende in: Onderzoek welke backoffice-systemen initieel ondersteund dienen te worden en hoe deze benaderd kunnen worden. Het bedenken en beschrijven van een generieke interface die het mogelijk maakt dat er in de toekomst eenvoudig ondersteuning voor nieuwe backoffice-systemen toegevoegd kan worden aan Meeki. Bepalen welke gegevens gesynchroniseerd dienen te worden. Onderzoek naar de te gebruiken Comet technologie voor het (semi-)realtime aanpassen van de informatie in de webwinkel. 4 Analyse

8 Eindverslag YaMST 4 Ontwerp De belangrijkste eis aan het ontwerp van YaMST is dat het mogelijk moet zijn om gemakkelijk ondersteuning voor andere/nieuwe backoffices te bouwen. Daarom zijn er interfaces bedacht die de toegang tot een backoffice en Meeki abstraheren, implementaties van deze interfaces noemen wij backoffice- en Meeki-adapters. Hierdoor kan men de ondersteuning van backoffices uitbreiden zonder dat er overal code aangepast hoeft te worden, er hoeven slechts nieuwe data-adapters geschreven te worden. Waar dus opgelet moet worden is dat het ontwerp ontwikkelaars genoeg vrijheid geeft om eigen implementaties te maken van adapters, zonder dat de globale werking aangetast wordt door incompatibiliteit. Een globaal overzicht van het ontwerp is te vinden in de Requiremens Analysis Document. Wij zullen deze kort bespreken. 4.1 WebInterface De WebInterface maakt het mogelijk voor externe systemen of componenten om YaMST op de hoogte te stellen van bepaalde gebeurtenissen of om bepaalde acties uit te laten voeren. YaMST is dus gedeeltelijk event-driven. Een voorbeeld van een gebeurtenis die gemeld wordt bij de WebInterface is wanneer er wijzigingen zijn opgetreden in het backoffice-systeem of wanneer er gecontroleerd moet worden op wijzigingen. Het enige wat de WebInterface doet is dus het ontvangen van events en deze doorgeven aan andere objecten. De precieze werking van de WebInterface wordt in het hoofdstuk over de implementatie uitgelegd. 4.2 BeheerInterface Met de beheerinterface worden de webpagina's bedoeld waarmee een beheerder configuratieopties van YaMST in kan stellen, logbestanden lezen en modules aan of uit zetten. 4.3 Core In dit package bevinden zich alle belangrijkste klassen voor YaMST. Ook de controllerklassen die alle verschillende klassen combineren tot een systeem zitten hierin. Deze zijn verantwoordelijk voor de verbinding tussen bijvoorbeeld de beheerinterface en YaMST. Ten slotte zijn de klassen voor producten, orders en klanten hier te vinden (het model). Ten behoeve van de leesbaarheid van het diagram zijn deze weggelaten, gedetailleerde informatie over deze klassen zijn te vinden in het Requirements Analysis Document. 4.4 Modules Dit zijn niet kritieke componenten voor het operationeel zijn van YaMST, voorbeelden hiervan zijn de synchronisatiemodule en de detectiemodule SynchronisationModule Dit is de synchronisatiemodule, zorgt ervoor dat wanneer er een wijziging is opgetreden in bijvoorbeeld productinformatie, dit wordt verwerkt. Deze module is sterk afhankelijk van de Ontwerp 5

9 YaMST Eindverslag webinterface voor het waarnemen van wijzigingen in de data CometModule De Cometmodule verzorgt de koppeling tussen de CometAdapter en YaMST, deze zullen wij nog niet implementeren SyncDatabase Deze klasse voorziet in een versimpelde toegang tot de database waar synchronisatiegegevens in worden opgeslagen. Zo worden er methodes beschikbaar gesteld die gemakkelijk mappings kan opzoeken, wijzigen, toevoegen en verwijderen. Dit is geen module, maar hoort bij de synchronisatiemodule en zit daarom ook in de modules groep. 4.5 Utilities Hier bevinden zich enkele klassen die niet specifiek met YaMST te maken hebben, maar een ondersteunende rol hebben. 4.6 DataAdapters Hier bevinden zich klassen die de daadwerkelijke toegang tot backoffice, Meeki maar ook Lightstreamer verzorgen. Elke backoffice- en Meeki-adapter voldoet aan de voorgeschreven interfaces IBackofficeAdapter De interface voor backofficeadapters, enkele mogelijkheden die deze interface voorschrijft zijn het lezen en schrijven van orders, producten en klanten. Merk op dat sommige van deze methodes (schrijven van producten, klanten, lezen van orders) niet geïmplementeerd zijn in de specifieke implementatie die wij hebben gemaakt. De reden hiervoor is dat deze methodes niet nodig zijn voor die implementatie IMeekiAdapter Vergelijkbaar met IBackofficeAdapter, maar dan voor operaties op Meeki CometAdapter Dit is geen interface, maar een klasse die door Lightstreamer ingeladen zal worden en wijzigingen in data met behulp van Lightstreamer kan doorsturen naar gebruikers. Dit component is nog niet geïmplementeerd. 6 Ontwerp

10 Eindverslag YaMST 5 Implementatie Uitgaande van het ontwerp hebben wij YaMST geïmplementeerd en specifieke backoffice- en Meeki-adapters voor een bepaalde klant. Uitgaande van de MoSCoW-methode is de implementatie van de Cometmodule niet aan de orde gekomen. Van de geïmplementeerde software zullen wij kort het implementatieproces bespreken en enkele noemenswaardigheden. Wij zullen hier geen exacte beschrijving geven van de klassen en hun attributen, deze zijn te vinden in de betreffende bijlage. 5.1 Core In Core bevinden zich delen van de WebInterface, de hoofdcontroller (YaMSTService), de verschillende klassen voor klanten, orders en producten (het model). Met het model worden de klassen die producten, klanten en orders modelleren bedoeld. In deze klassen is haast geen logica aanwezig, hiermee wordt bedoeld dat er niks met de data wordt gedaan die in instantie van deze klassen worden gestopt. De reden hierachter is dat elke dataadapter mogelijk andere eisen kan stellen aan bijvoorbeeld de lengte en het formaat van een wachtwoord van een klant. Het is dus de bedoeling dat elke data-adapter zelf verantwoordelijk is voor de juistheid van de data. Om ontwikkelaars meer mogelijkheden te bieden bevat elke klasse de mogelijkheid extra data op te slaan naast de minimaal benodigde informatie. Het implementeren van het model is een zeer iteratief proces geweest, vaak zijn er datatypes van bepaalde attributen iets veranderd en zijn er attributen bijgekomen/weggehaald. Maar omdat het model een van de eerste onderdelen is dat gemaakt is, was dit wel enigszins te verwachten. De belangrijkste klasse in Core is YaMSTService, deze klasse combineert alle losse componenten tot een geheel (YaMST). Het implementeren van deze groep kostte niet veel tijd omdat er relatief weinig ingewikkelde code geschreven hoefde te worden, met uitzondering van YaMSTService. 5.2 WebInterface De WebInterface bestaat eigenlijk uit drie delen, een ASP.NET pagina, een interface en een implementatie hiervan. De bedoeling is dat deze webinterface aangeroepen wordt door een ASP.NET pagina die HTTP requests afvangt en events doorstuurt met behulp van remoting. Remoting houdt in dat een applicatie een methode van een instantie van een object, dat op een andere computer draait kan aanroepen. Doordat de ASP.NET pagina aangeroepen kan worden met behulp van normale HTTP requests kunnen externe partijen gemakkelijk gebruik maken van de webinterface. Tijdens het implementeren hadden wij problemen met het goed werkend krijgen van de ASP.NET pagina op de tweede testserver, dit lag aan bepaalde compilatieinstellingen en heeft ons een dag of 2 gekost. Ook het werkend krijgen van remoting was iets lastiger dan was gedacht, maar dit probleem was relatief snel opgelost. 5.3 YaMSTControl Deze klasse lijkt op de webinterface, maar biedt de functionaliteit om YaMST te beheren, de Implementatie 7

11 YaMST Eindverslag ASP.NET pagina behorende bij deze klasse is namelijk de beheerinterface. Tot de functionaliteit van deze klasse behoren onder andere het: weergeven van logbestanden, inloggen van beheerders, starten/stoppen/herstarten van modules en statusinformatie weergeven. Deze klasse is niet geïmplementeerd en zal later toe worden gevoegd. 5.4 YaMSTService De YaMSTService klasse is een uitbreiding op een ServiceBase klasse, deze klasse stelt een Windows-service voor die in Windows zelf beheerd kan worden (gestopt en gestart). Deze klasse is dus eigenlijk YaMST (de applicatie). Verder zorgt deze bij initialisatie ervoor dat de modules geladen worden, YaMSTControl en de webinterface beschikbaar worden gesteld en de ingestelde data-adapters dynamisch worden geladen. Alle instellingen worden opgeslagen in een configuratiebestand dat automatisch wordt ingeladen en verwerkt bij het opstarten. Hierin staat onder meer de soort backoffice- en Meekiadapters die geladen moeten worden (deze adapters zijn opgeslagen in een apart DLL-bestand, hierover meer in de komende paragrafen), instellingen voor deze adapters en nog wat instellingen voor YaMST zelf. Het schrijven van deze klassen was een uitdaging omdat wij erachter kwamen dat we een klasse nodig hadden die alle klantspecifieke code kan laden, hier hadden wij tijdens de ontwerpfase nog niet over nagedacht. Een andere ontdekking was dat er voor deze specifieke implementatie een detectiemodule nodig die wijzigingen detecteert en ook opdracht moet geven tot downloaden van nieuwe CSV-bestanden. Dit leidde tot herziening van de data-adapters, uitbreiden van de klantspecifieke code met de loader en detectiemodule en het geheel onderbrengen in een DLL bestand. 5.5 SyncDatabase De SyncDatabase/mapping-database gebruikt een MSSQL database en heeft als doel om het benaderen van synchronisatie meta-data te vergemakkelijken. Deze klasse heeft methodes voor de volgende functionaliteiten: 1. Toevoegen mapping 2. Opzoeken mapping van backoffice naar Meeki 3. Opzoeken mapping van Meeki naar backoffice 4. Verwijderen mapping Backoffice id's zijn strings met een maximale lengte van 50 karakters. Meeki id's zijn integers groter dan of gelijk aan 0. Verder moet elke mapping een bepaald type hebben, dit type is een string van maximaal 50 tekens, dat aangeeft om wat voor soort mapping het kan gaan. Een voorbeeld van een mapping kan zijn: ( BACKOFFICE_0, 0, MappingVanEenOrder ) Hier is BACKOFFICE_0 het id van een order uit het backoffice, 0 het id van de bijbehorende order uit Meeki en MappingVanEenOrder geeft aan dat het om orders gaat. 8 Implementatie

12 Eindverslag YaMST Door deze implementatie (en het flexibele model) is er genoeg vrijheid voor de data-adapters om zeer specifieke gegevens op te slaan. De code voor deze klasse was niet erg lastig te schrijven doordat wij al veel met databases gewerkt hebben en het ontwerp van de database zelf erg simpel is. 5.6 SynchronisatieModule De SynchronisationModule verzorgt de basislogica achter het synchroniseren van gegevens. De daadwerkelijke actie delegeert deze door naar de adapters. Deze module bestaat voornamelijk uit methodes die worden aangeroepen door de webinterface met behulp van events. Het volgende voorbeeld illustreert de werking van deze module: public void MeekiOrderAddedEventHandler(object source, MeekiEventArgs args) {... Order o = meekiadapter.readorder(args.meekiid); backofficeadapter.writeorder(o);... } De SynchronisationModule zal wanneer deze krijgt doorgegeven dat een nieuwe order is gevonden in Meeki (dit geeft Meeki zelf door), de hierboven gegegeven methode uitvoeren. Deze methode hoeft alleen maar te weten dat deze een order moet lezen uit Meeki (het id van die order krijgt hij mee uit het event) en weg moet schrijven naar het backoffice. Deze handler-methodes worden gekoppeld aan de events in de webinterface door YaMSTService. Dit betekent dat er een standaard set aan events is gedefinieerd die gebruikt kunnen worden, het gebruikmaken van zelfgedefinieerde events is niet mogelijk. Dit kan een beperking zijn bij het implementeren van bepaalde data-adapters. Ook hier viel de moeilijkheidsgraad van de code erg mee, er moest het meest gelet worden op de foutafhandeling, met name het loggen van problemen. 5.7 Loggen van problemen Voor de implementatie van het loggen van problemen hebben wij gekozen voor een extern logging-framework, namelijk log4net. Deze laten wij loggen naar tekstbestanden (met de FileAppender) die dan ingezien kunnen worden door beheerders en (later) ook vanuit de beheerinterface. Voor meer informatie over de loggingfunctionaliteit kunt u terecht op: Het gebruik van dit framework ligt redelijk voor de hand, dus hebben wij hier weinig problemen mee gehad. Alleen het correct configureren van het logging framework kostte iets meer tijd dan verwacht. 5.8 SwanLibrary (klantspecifieke klassen) Dit hoofdstuk beschrijft globaal de library die gebouwd is voor een bepaalde klant van de opdrachtgever (Swan). Implementatie 9

13 YaMST Eindverslag De klantspecifieke klassen zijn de klassen die nodig zijn voor een specifiek backoffice-systeem en de bijbehorende Meeki-installatie. Een globaal overzicht van deze klassen is hieronder te vinden, ook worden de klassen hieronder verder beschreven SwanLibraryLoader De data-adapters worden onafhankelijk van YaMST gecompileerd naar een apart DLL bestand, dit is dus een aparte binary. De data-adapters zijn niet de enige bestanden die naar een DLL worden gecompileerd. Naast klassen die zorgen voor controle van het model voor deze specifieke implementatie en wegschrijven van data is er ook nog een verplichte LibraryLoader klasse aanwezig (dit is een klasse die de interface ILibraryLoader implementeert). Deze wordt door YaMSTService geinstantieerd waarna deze de data-adapters gereed moet maken, de r eden dat er een aparte klasse nodig is voor initialisatie is omdat dit per data-adapter verschillend is. Ten slotte maakt deze specifieke ILibraryLoader klasse een detectiemodule, die ervoor zorgt dat het backoffice aan de webinterface kan doorgeven wanneer er een wijziging is. Dit is optioneel en mag ook weggelaten worden. Een voorbeeld om dit alles te illustreren: 1. YaMST leest dat het bestand.dll moet inladen. 2. YaMST zoekt naar een klasse X die voldoet aan de interface ILibraryLoader en instantieert deze. 3. X krijgt een verwijzing naar YaMSTService en dient zichzelf gereed te maken in zijn initialisatie-methode. Deze methode wordt aangeroepen door YaMST. 4. Wanneer X klaar is verwacht YaMSTService dat de backoffice- en Meeki-adapters gereed zijn (in dit specifieke geval is er ook een detectiemodule aangemaakt). 5. Initialisatie van de data-adapters is voltooid. In de volgende twee paragrafen zullen wij de implementatie van de backoffice- en Meeki-adapter bespreken die specifiek voor het systeem van een klant van de opdrachtgever zijn ontworpen SwanDataAdapters Backoffice-adapter De backoffice-adapter krijgt zijn informatie uit CSV bestanden gedownload van een FTP-server. Voor het downloaden en inlezen van deze CSV bestanden gebruiken wij aparte libraries die deze functionaliteit verzorgen (Jelovic.FtpLib en FileHelpers). Dit proces is alleen geldig voor het inlezen van gegevens, het schrijven van gegevens geschiedt door XML-bestanden weg te schrijven naar een bepaalde plek op de FTP-server. Omdat het downloaden en verwerken van CSV-bestanden een kostbare taak is laten wij de backoffice-adapter dit hooguit eenmaal per halfuur doen (zie Requirements Analysis Document voor meer informatie). Om dit te bewerkstelligen maken wij gebruik van de mogelijkheid van YaMST om een detectiemodule te gebruiken, deze hebben wij zodanig gemaakt zodat er elk halfuur een event wordt gegenereerd op de webinterface die aangeeft dat er nieuwe bestanden 10 Implementatie

14 Eindverslag YaMST gedownload moeten worden. De backoffice-adapter luistert naar dit event, downloadt nieuwe bestanden en kijkt of er wijzigingen zijn in de data. Indien dit het geval is zal deze nieuwe events genereren die bijvoorbeeld aangeven dat er een product is verwijderd, dit wordt dan door de synchronisatiemodule verder afgehandeld. Hoewel het detecteren van wijzigingen relatief makkelijk is, was het een redelijke klus om bijvoorbeeld een product uit de CSV data te lezen, reden hiervoor is dat deze verspreid is over meerdere bestanden, hierdoor moest er gewerkt worden met koppelingen tussen gegevens. De enige schrijfactie die deze adapter heeft is het wegschrijven van orders, hier worden orders geconverteerd naar een XML-formaat wat weer weggeschreven wordt naar de FTP server. Het converteren van orders naar XML was erg lastig omdat dit samenhangt met het valideren van het model, ook waren er kleine aanpassingen nodig aan het formaat vanwege onvoorziene zaken. Een probleem waar wij tegenaan liepen was dat het erg onhandig bleek om maar 1 id op te slaan in een willekeurig object uit het model, daarom is besloten om zowel een backoffice id als een Meeki id attribuut te definieren. Ook het valideren van orders had haken en ogen, zo hebben wij voor het valideren van prijzen geen rekening gehouden met kortingen in procenten, of zomaar afgeprijsde artikelen. De belangrijkste verandering is dat wij (erg laat) te horen kregen van onze implementatiepartner Quercis, dat alleen prijzen exclusief BTW doorgegeven hoeven te worden. Meeki-adapter De Meeki-adapter bestaat uit twee delen, ten eerste is er de implementatie van IMeekiAdapter (dit is de interface die YaMST gebruikt om de adapter mee aan te roepen), ten tweede is er voor deze specifieke implementatie gekozen om een lees- en schrijfacties te doen met behulp van een HTTP-API, een extra abstractielaag in de vorm van een script. Dit houdt in dat wanneer er een order gelezen moet worden het volgende zal gebeuren: 1. YaMST roept ReadOrder(1) aan op de Meeki-adapter, 1 is een willekeurig id van een order. 2. De Meeki-adapter maakt een HTTP-request naar: 3. yamst.php stuurt dan een XML-pagina terug met de opgevraagde gegevens 4. De Meeki-adapter verwerkt de XML-pagina en converteert deze naar een Order-object. Voor de implementatie van de HTTP-API hebben wij gekozen om deze in PHP te schrijven, dit is namelijk ook de taal waarin Meeki is geschreven. Het PHP-script doet in het geval van de Meeki-adapter het meeste werk aangezien de meekiadapter eigenlijk alleen maar een doorgeefluik is. Het grootste probleem met dit script was het vinden van de juiste tabellen en velden. De data die wij gebruiken in onze order-, product- en klantobjecten zijn namelijk over meerder tabellen verspreid. Aanvankelijk dachten we eenvoudig de API van ZenCart te kunnen gebruiken voor het ophalen en wegschrijven van de data. Helaas bleek dat veel velden ontbraken of via form-requests toegankelijk waren. Daarom hebben we er toch voor gekozen om zelf queries te bouwen en deze op de database van Zencart uit te voeren. Hierna is het vrij eenvoudig om een XML document op te bouwen die vervolgens teruggestuurd kan worden naar YaMST. Voor het wegschrijven van data doen we enkele simpele checks aangezien de checks ook al worden uitgevoerd in YaMST zelf. Implementatie 11

15 YaMST Eindverslag 6 Projectevaluatie In dit hoofdstuk zullen we onszelf de volgende vraag stellen: 'wat ging goed, en wat had beter gekund?'. Eerst zullen we de dingen bespreken die goed gingen, vervolgens de dingen die beter hadden gekund. 6.1 Wat ging goed? Project setup Voordat we zijn begonnen met implementeren moesten we eerst een ontwikkelomgeving opzetten. We hadden voor dit project nog nooit met Visual Studio, Source Safe en SQL Server gewerkt, ook hadden we nog nooit eerder in C# geprogrammeerd. Toch leverde dit geen problemen op en konden we snel beginnen met de implementatie. Requirements analyse Wij denken een goed Requirements Analysis Document te hebben opgesteld. We hebben hier achteraf gezien wel iets teveel tijd in gestoken zodat we in de knel kwamen met de planning. Toch denken we dat we goed de functionele eisen hebben kunnen aanwijzen. Communicatie met opdrachtgever en begeleider Zowel de opdrachtgever als de begeleider hebben ons goed begeleid bij dit project. Wij vinden dat de communicatie met hen dan ook zeer goed was en dat dit zeker heeft bijgedragen aan het succesvolle resultaat van dit project. 6.2 Wat kon beter? Planning We hebben de tijd die nodig was voor de implementatie enigzins onderschat. Dit kwam mede omdat we teveel tijd hadden gestoken in het verbeteren en aanpassen van het RAD en het ADD. Hierdoor hebben we niet alles op tijd kunnen implementeren en zijn er enkele componenten die niet geïmplementeerd konden worden (beheerinterface, cometmodule). Testplan Doordat we enigzins in tijdnood kwamen zijn we eerder begonnen met implementeren, hierdoor is het test- en implementatieplan niet helemaal op tijd afgerond. Dit hebben we tijdens het implementeren alsnog aangepast en uitgebreid met enkele testcase beschrijvingen. Communicatie met externe partijen Voor informatie over het backofficesysteem was er redelijk wat communicatie nodig met een externe partij, deze liep niet heel erg soepel omdat er redelijk laat door hun werd gereageerd op onze vragen. 12 Projectevaluatie

16 Eindverslag YaMST 7 Conclusie en aanbevelingen 7.1 Conclusie We kunnen stellen dat dit bachelorproject redelijk succesvol was, de Meeki synchronisatietool is grotendeels geïmplementeerd en klaar om toegepast te worden op backoffice-systemen van klanten van Arco Iris (ookal is er nog geen beheerinterface). Wij denken dat dit een uniek product is aangezien andere webshops voor backoffice-systemen worden ontwikkeld vanuit de techniek van het backoffice-systeem zelf. Bij Meeki is er gekozen voor een aanpak vanaf de andere kant. Wij kijken dan ook uit naar toekomstige projecten die gebaseerd zijn op YaMST. Dit project was niet alleen van grote waarde voor Arco Iris maar ook voor onszelf. Wij willen daarom iedereen die ons begeleid heeft bij dit project nogmaals bedanken. 7.2 Aanbevelingen Nu YaMST zo goed als af is, is het belangrijk om te kijken naar uitrollen en onderhouden van YaMST. Bij het maken van nieuwe data-adapters voor andere backoffice-systemen kan een programmeur kijken naar het RAD en het ADD maar vooral de documentatie die de interfaces van de data-adapters beschrijft. De code van de huidige data-adapter implementatie is ook zorgvuldig voorzien van commentaar. Een ander belangrijk punt is dat er van de mapping-database regelmatig backups worden gemaakt. YaMST zelf bevat namelijk geen database backup functionaliteit dus een beheerder van de server zal zelf regelmatig backups moeten maken, en ze handmatig terug moeten zetten in geval van een storing. Tevens is het van belang dat er bijvoorbeeld tussen YaMST en het Meeki PHP script een beveiligde verbinding wordt gebruikt. In het kader van ons project hebben wij hier geen rekening mee hoeven houden. Toch is het vrij eenvoudig dit in een later stadium toe te voegen. Tenslotte is het belangrijk dat er één of meerdere personen zorgen dat de productinformatie actueel blijft. Deze mensen zullen ook in Meeki zelf foto's/video's moeten toevoegen aan de producten aangezien hier geen mogelijkheid voor is in de meeste backoffice-systemen. Conclusie en aanbevelingen 13

17 Requirements Analysis Document IN3405 Bsc-Project Versie 0.6 Dordrecht, 13 mei 2008 Robert Ros Jip Man Vuong

18 Requirements Analysis Document YaMST Inhoudsopgave 1 Inleiding Huidige situatie Het te bouwen systeem Overzicht Functionele eisen Synchronisatiemodule Cometmodule Extern Niet-functionele eisen Gebruikersinterface en menselijke factoren Documentatie Hardwarezaken Prestatie-eigenschappen Foutafhandeling en extreme omstandigheden Systeemcommunicatie Kwaliteitseisen Systeemaanpassingen Fysieke omgeving Beveiliging Pseudo requirements Systeemmodellen Use case modellen Objectmodellen Dynamische modellen Userinterface...29 INHOUDSOPGAVE I

19 YaMST Requirements Analysis Document Document status Algemeen Document titel: Identificatie: Auteurs: Document status: Requirements Analysis Document rad-0.6.pdf Robert Ros en Jip Man Vuong Final Document geschiedenis Versie Datum Reden van verandering Draft versie Interne opmerkingen verwerkt Opmerkingen van C. Pronk verwerkt Interne opmerkingen verwerkt Opmerkingen van C. Pronk verwerkt Opmerkingen van C. Pronk verwerkt, final II DOCUMENT STATUS

20 Requirements Analysis Document YaMST 1 Inleiding Deze opdracht is voortgekomen uit de vraag van bedrijven die een bestaand backoffice-systeem hebben en hun producten online willen aanbieden, hierbij is het belangrijk dat deze webwinkel aansluit op de bestaande systemen. Momenteel biedt Meeki, de door Arco Iris ontwikkelde webwinkelsoftware deze integratie nog niet. Er zijn vele verschillende backoffice-systemen reeds in gebruik, onze taak is om een zo generiek mogelijke interface te ontwerpen om deze backofficesystemen met de webwinkel te koppelen. Meeki is een standaard webwinkel met een koppeling naar een backoffice-systeem. Het is een initiatief van drie partijen: Arco Iris (voor de webtechnologie), Wendrich (vormgeving/communicatie gespecialiseerd in groot- en detailhandel) en Quercis (Exact implementatiepartner met verstand van backoffice-systemen). Daarbij is de webwinkel gebaseerd op een opensource webwinkel (ZenCart) die Arco Iris verder heeft uitgebouwd. Het te ontwikkelen synchronisatiesysteem wordt in de context van dit project aangeduid met de naam YaMST. YaMST staat voor 'Yet another Meeki Sync Tool'. INLEIDING 1

21 YaMST Requirements Analysis Document 2 Huidige situatie Aangezien Meeki nog niet gelanceerd is, is er nog geen huidige situatie, maar we kunnen wel schetsen wat er zou gebeuren als Meeki gelanceerd zou zijn zonder de functionaliteit van YaMST: Voor elk nieuwe product dat toegevoegd/gewijzigd/verwijderd wordt in het backofficesysteem, moet deze handeling handmatig herhaald worden in Meeki Voor elke wijziging in de voorraad moet iemand handmatig een vergelijkbare actie uitvoeren in Meeki Elke bestelling die geplaatst wordt via Meeki moet handmatig ingevoerd worden in het backoffice-systeem. Zodra een prijs van een product wordt gewijzigd in het backoffice, zal dat niet zichtbaar zijn in Meeki totdat deze wijziging ook is toegepast in Meeki. Zonder YaMST moet elke wijziging in zowel het backoffice-systeem als in Meeki worden doorgevoerd in het andere systeem. Aangezien het veel tijd kost om het backoffice elke keer handmatig te synchroniseren van en naar Meeki, zal het gebruiken van een dergelijke oplossing hoge kosten met zich mee brengen. 2 HUIDIGE SITUATIE

22 Requirements Analysis Document YaMST 3 Het te bouwen systeem 3.1 Overzicht Het te realiseren synchronisatiesysteem zorgt ervoor dat Meeki gekoppeld kan worden aan verschillende backoffice-systemen. Hierdoor kunnen product-, prijs-, voorraad- en ordergegevens tussen beide systemen gesynchroniseerd worden met zo min mogelijk tussenkomst van beheerders. Daarnaast moeten na het synchroniseren ook pagina's die op het moment van synchronisatie openstaan in webbrowsers bijgewerkt worden met de nieuwe data, dit moet gebeuren met behulp van Comet technologie geïmplementeerd met een Lightstreamer-server. Ten slotte moet er een synchronisatieinterface gedefiniëerd worden zodat er in de toekomst gemakkelijk ondersteuning voor andere backoffice-systemen toegevoegd kan worden. 3.2 Functionele eisen Voor de synchronisatie- en cometmodule definiëren wij de volgende functionele eisen Synchronisatiemodule Voor de synchronisatie module is er maar een gebruiker, namelijk de beheerder. Deze persoon moet Meeki beheren en heeft toegang tot het backoffice-systeem. De beheerder heeft de volgende mogelijkheden: 1.1. Starten/Stoppen van de synchronisatiemodule Configureren van de synchronisatiemodule via de webinterface (precieze beschrijving van de te configureren opties kunt u vinden bij Logbestanden en foutrapporten bekijken. De module moet de volgende functionaliteit hebben: 3.1. Detecteren van wijzigingen in productgegevens veroorzaakt door (een gebruiker van) het backoffice en deze wegschrijven naar Meeki Detecteren van statuswijzigingen in orders veroorzaakt door (een gebruiker van) het backoffice en deze wegschrijven naar Meeki Detecteren van wijzigingen in de klantgegevens veroorzaakt door (een gebruiker van) het backoffice en deze wegschrijven naar Meeki Detecteren van nieuwe orders aangemaakt door een gebruiker van Meeki en deze wegschrijven naar het backoffice Notificatie van beheerder door en sms bij fouten, problemen of complicaties Loggen van problemen en belangrijke gebeurtenissen. HET TE BOUWEN SYSTEEM 3

23 YaMST Requirements Analysis Document Cometmodule Voor de cometmodule is er eveneens een beheerder (dezelfde als voor de synchronisatiemodule). Daarnaast is er ook een gebruiker. Een gebruiker is iedereen die een webpagina aan het bekijken is die gegenereerd wordt door de Meeki webwinkelsoftware. De beheerder heeft de volgende mogelijkheden: Overige eisen: 5.1. Starten/stoppen van de cometmodule Configureren van de cometmodule via de webinterface Logbestanden en foutrapporten bekijken Webpagina's in Meeki voorzien van updates in data Loggen van problemen en belangrijke gebeurtenissen Extern De volgende functionele eisen vallen buiten het YaMST (bijv. het aanmaken van een order wordt buiten YaMST gedaan, in de Meeki frontend en Meeki zelf), maar tot gevolg hebben dat een eis in YaMST geactiveerd wordt. Alle eisen die geen effect hebben op YaMST worden weggelaten. Voor een gebruiker van Meeki zijn de volgende functionele eisen van belang: 8.1. Aanmaken van een order (producten kopen) 8.2. Meeki webpagina's bekijken waarvan bepaalde data automatisch wordt bijgewerkt zonder de pagina te herladen. Aan de kant van het backoffice zijn ook dergelijke eisen te vinden, ook hier geldt dat alleen de relevante mogelijkheden genoemd worden. Een gebruiker van het backoffice heeft de volgende mogelijkheden: 9.1. Aanpassen van de eigenschappen van een product 9.2. Toevoegen van een product aan het backoffice 9.3. Verwijderen van een product uit het backoffice 9.4. Aanpassen van de status van een order 9.5. Een klant toegang geven tot Meeki 9.6. Een klant toegang ontzeggen tot Meeki 4 HET TE BOUWEN SYSTEEM

24 Requirements Analysis Document YaMST 3.3 Niet-functionele eisen Gebruikersinterface en menselijke factoren De gebruiker van de beheerinterfaces van de synchronisatie en Comet modules is een beheerder die ook beheerrechten heeft op het backoffice-systeem en Meeki, deze beheerinterface zal webgebaseerd zijn. Van de beheerder wordt aangenomen dat hij genoeg kennis heeft om logbestanden met fouten te kunnen begrijpen. De taal van de gebruikersinterface dient in het Nederlands te zijn Documentatie Voor de volgende items dient er documentatie geschreven te worden: Installatieprocedure: Er dient gespecificeerd te worden hoe YaMST moet worden geïnstalleerd. Belangrijk hierbij is dat de beschikbare configuratieopties helder worden uitgelegd (Nederlands). Beheerinterface: Voor de beheerder moet er documentatie beschikbaar zijn die de functionaliteit van de beheerinterface duidelijk beschrijft (Nederlands). Interface naar Backoffice-systemen: Er moet worden beschreven hoe een data-adapter gemaakt moet worden zodat er in een later stadium adapters voor backoffice-systemen anders dan Exact Globe geschreven kunnen worden. Deze documentatie is van zeer groot belang aangezien ontwikkelaars aan de hand hiervan nieuwe adapters moeten ontwikkelen (Nederlands) Hardwarezaken YaMST zal op elk redelijk modern serversysteem kunnen opereren. Ook is het mogelijk dat Meeki, het backoffice-systeem en YaMST op verschillende systemen draaien Prestatie-eigenschappen Er zijn geen specifieke eisen aan de prestaties van de beheerinterface. Wel dient de snelheid van deze interface zodanig te zijn dat de gebruiker geen hinder ondervindt tijdens het gebruik ervan Synchronisatiemodule De data van het backoffice is toegankelijk vanaf een FTP server in meerdere CSV (Comma Separated Values), deze bevatten alle gegevens uit het backoffice. De getallen en tijden hieronder gaan uit van ongeveer 50MiB aan CSV-data (dit komt overeen met ongeveer producten, productattributen klanten en orderstatussen )en een downloadsnelheid vanaf de FTP server van minimaal 1MiB/s. De verbinding tussen YaMST en Meeki bedraagt ook minimaal 1MiB/s. Verder hanteren wij de volgende definities: aanpassing Een aanpassing is een wijziging in de eigenschappen van een dataobject, maar ook het verwijderen of toevoegen van een dataobject vallen hieronder (de definities van de HET TE BOUWEN SYSTEEM 5

25 YaMST Requirements Analysis Document dataobjecten vindt u in de volgende hoofdstukken). In Meeki is de enige relevante aanpassing een nieuw aangemaakte order. De relevante aanpassingen in het backoffice zijn het wijzigen van producteigenschappen, het toevoegen van een nieuw product (en diens eigenschappen), het verwijderen van een product, het aanpassen van de status van een order, een klant toegang geven tot Meeki en ten slotte een klant de toegang tot Meeki ontzeggen. detectie van een aanpassing Een aanpassing is gedetecteerd zodra YaMST kennis heeft genomen van een specifieke aanpassing. Het is de bedoeling dat zowel Meeki als het backoffice YaMST op de hoogte stellen van aanpassingen, de actie moet dus van buiten YaMST komen. De tijd die nodig is voor een detectie meten wij vanaf het wegschrijven/opslaan van een wijziging in de databron tot en met het binnenkomen van de mededeling over de aanpassing bij YaMST. Een voorbeeld hiervan is het aanmaken van een nieuwe order door een klant in Meeki, dit moet door Meeki zelf bij YaMST gemeld worden. synchronisatie van een aanpassing Een synchronisatie begint met het inlezen van het te schrijven dataobject door YaMST en eindigt met het wegschrijven van het object naar het doel. Nadat een dataobject is ingelezen wordt deze met behulp van conversieroutines omgezet naar een intern formaat. Vervolgens wordt het dataobject gemapt naar het doel, hier wordt de identificatie omgezet van bijvoorbeeld Meeki naar het backoffice. Ten slotte wordt het gemapte dataobject weggeschreven naar het doel. Wij maken dus duidelijk onderscheid tussen detectie en synchronisatie. Het detecteren van een aanpassing in Meeki dient binnen 10 seconden te gebeuren. Vanwege het ontwerp en de werking van Meeki (Zencart) kunnen wij deze tijd handhaven indien er geen problemen optreden. Voor het backoffice geldt dat detectie binnen 10 minuten afgerond moet zijn. Deze tijd is nodig omdat voor detectie van aanpassingen in dit specifieke backoffice eerst alle data van de FTP server gedownload moet worden (Dit kost 50 seconden, hooguit 1 minuut), vervolgens moet de data ingelezen worden (In het geval van CSV bestanden hebben wij gemeten dat dit ook hooguit 1 minuut kost). Daarna moet YaMST uitzoeken of er wijzigingen zijn opgetreden, nadat dit is afgelopen zijn er een of meer aanpassingen gedetecteerd. De resterende 8 minuten zijn voor eventuele uitloop van downloaden, inlezen van data of het analyseren van de data. Om het eventuele gemiste detecties van aanpassingen te voorkomen, moet er minimaal elke 30 minuten gecontroleerd worden op aanpassingen in Meeki. Het backoffice zal zelf elke 30 minuten nieuwe CSV data genereren en YaMST hiervan op de hoogte stellen. Er zijn twee soorten synchronisaties, het synchroniseren van een dataobject uit Meeki naar het backoffice en andersom. Voor een synchronisatie van de eerste soort geldt dat deze niet langer mag duren dan 1 minuut, dit is ruim voldoende voor het lezen van een dataobject (Alleen orders eigenlijk) uit Meeki en deze na conversie en mapping uploaden op de FTP server. Voor een synchronisatie van het backoffice naar Meeki kan hetzelfde, maar dan in omgekeerde volgorde gebeuren. Dus hier stellen wij ook als eis dat dit niet langer mag duren dan een minuut, overigens verwaarlozen wij de tijd benodigd voor de conversie en de mapping, omdat wij deze niet interessant achten in contrast met de benodigde tijd voor de overige handelingen. Bovenstaande getallen en tijden zijn geldig wanneer er geen fouten of andere extreme omstandigheden voorkomen, de afhandeling van fouten komt in het onderdeel foutafhandeling aan bod. Wat wel vast staat is dat het kwijtraken van data nooit mag voor komen en zelfs bij fouten 6 HET TE BOUWEN SYSTEEM

26 Requirements Analysis Document YaMST mag een order niet verdwijnen. Hieronder volgen enkele voorbeelden om de gedefineerde prestatie-eigenschappen te illustreren: 1. Een klant maakt een order aan in Meeki, die meldt dat binnen 10 seconden aan YaMST, vervolgens wordt deze binnen 1 minuut weggeschreven naar het backoffice. 2. Een voorraadmedewerker past van een product de prijs aan in het backoffice, dit wordt binnen 10 minuten gedetecteerd. YaMST schrijft vervolgens binnen 1 minuut de gewijzigde prijs naar Meeki. 3. Een klant maakt een order aan in Meeki, maar op het moment dat deze het wil melden aan YaMST struikelt de schoonmaakster over de netwerkkabel waardoor YaMST niet bereikbaar is vanaf Meeki. Nadat de verbinding is hersteld weet YaMST binnen 30 minuten van de order en is de order binnen 1 minuut weggeschreven naar het backoffice. Er wordt verondersteld dat YaMST minimaal 120 bestellingen per 24 uur moet kunnen afhandelen. Dit komt neer op 1 bestelling per 12 minuten, wat ons haalbaar lijkt voor YaMST Cometmodule De cometmodule is eigenlijk een adapter voor Lightstreamer, de prestaties zijn dus voornamelijk afhankelijk van die van Lighstreamer. Dus over de prestaties (zoals hoeveelheid gebruikers die tegelijk gebruik kunnen maken van de module) kunnen we weinig zeggen. Wel nemen wij aan dat gewijzigde data die moet worden verstuurd met behulp van de Lightstreamer server binnen 10 seconden na een synchronisatie aan is gekomen bij de gebruiker van Meeki (de webpagina's). Voorbeeld: Neem de prijswijziging in de vorige paragraaf. Hooguit 10 seconden na het wegschrijven van de prijs kunnen gebruikers die toevallig een pagina bekijken met het product de prijs zien veranderen Foutafhandeling en extreme omstandigheden Voor elk van de volgende problemen dient in ieder geval een melding gemaakt te worden in het logbestand. De beheerder dient op de hoogte gesteld te worden van kritieke fouten in YaMST. In het algemeen geldt dat de data uit het backoffice-systeem altij de hoogste prioriteit h eeft. Waar ook goed op gelet moet worden is dat de databronnen door meerdere systemen tegelijkertijd gebruikt kunnen worden. Indien mogelijk moeten er mutal exclusion technieken worden toegepast om datacorruptie te voorkomen Backoffice-systeem kan geen update melding naar YaMST doorgeven Aangezien het backoffice-systeem elk half uur een complete export maakt van de data-objecten die in YaMST worden gebruikt maakt het niet uit als YaMST enkele update meldingen mist. Bij de volgende melding van een update zal YaMST zelf meerdere aanpassingen detecteren. Er gaan dus geen aanpassingen uit het backoffice-systeem verloren in YaMST, ze worden echter wel later gedetecteerd Meeki kan geen melding van een nieuwe order doorgeven naar YaMST YaMST mag in geen geval orders missen. Elke nieuwe order in Meeki moet weggeschreven worden HET TE BOUWEN SYSTEEM 7

27 YaMST Requirements Analysis Document naar het backoffice-systeem. Doordat Meeki direct na het aanmaken van een nieuwe order een melding naar YaMST zal doorsturen kan het voor komen dat zo n melding verloren gaat. Deze event-driven aanpak kan niet garanderen dat elke order ook daadwerkelijk door YaMST wordt gedetecteerd. YaMST zal daarom elk half uur een controle uit moeten voeren zodat er gekeken kan worden of er orders zijn die niet zijn gedetecteerd en deze alsnog te verwerken. Op deze manier kunnen orders die tijdens een storing in YaMST zijn aangemaakt maximaal een half uur na het oplossen van de storing alsnog worden verwerkt Meeki stuurt conflicterende meldingen naar YaMST Dit type fout kan optreden indien het mogelijk is om orders in Meeki aan te passen / annuleren. Stel er is een storing in YaMST op het moment dat er een order wordt aangemaakt. De melding van deze order wordt dus gemist. Als de storing in YaMST weer storingsvrij is en er gegevens worden aangepast in de order die zojuist is aangemaakt zal YaMST niks afweten van deze order aangezien deze nog niet in de mapping bestaat. De oplossing is update/annulerings m eldingen gewoon te negeren als er nog geen mapping bestaat voor de order. YaMST zal zelf na een half uur de bovengenoemde controle uitvoeren en de order alsnog (met aangepaste gegevens) verwerken. Voor de huidige implementatie is dit nog geen probleem aangezien het niet mogelijk is om orders aan te passen / annuleren Gedeeltelijk ontbreken van productinformatie van een nieuwe order in het backoffice-systeem Een voorbeeld hiervan is als er een order wordt gemaakt door een klant die niet meer bestaat in het backoffice-systeem of als er een product wordt besteld dat inmiddels is verwijderd uit het backoffice-systeem maar nog niet uit Meeki. Dit kan voor komen omdat wijzigingen in het backoffice-systeem elk half uur worden bijgewerkt. Als er in dat half uur een order wordt geplaatst die gebruik maakt van deze gegevens zal deze order niet meer consistent zijn met de gegevens in het backoffice-systeem. Deze order zal gewoon worden weggeschreven met de oude productinformatie, het oplossen van die probleem valt buiten YaMST. Er zal per geval gekeken moeten worden hoe dit het beste opgelost kan worden. Hier zal dus altijd een backofficemedewerker aan te pas komen. Wij verwachten dat dit probleem weinig zal voor komen Gedeeltelijk ontbreken van mapping-data van een nieuwe order in YaMST Dit probleem lijkt op het vorige probleem alleen nu zijn de wijzigingen al doorgevoerd in YaMST maar nog niet in Meeki. Ook hier geldt dat de order gewoon weggeschreven zal worden in het backoffice-systeem. Ook hier zal er per geval gekeken moeten worden hoe dit probleem het beste kan worden opgelost Prijsverlagingen / verhogingen in het backoffice-systeem na het plaatsen van een order In een order zelf worden altijd de prijzen en attributen van artikelen opgeslagen. Als er dus productgegevens of prijzen veranderen zal dat geen effect hebben op de prijzen van bestaande orders. Als er een order is geplaatst en er vervolgens een prijsverhoging volgt zal het product in de order de oude prijs behouden. Omgekeerd geldt hetzelfde, dat zou voor de klant vervelend kunnen zijn. Met zulke gevallen houden wij geen rekening, het backoffice-personeel dient dit zelf af te handelen door de order handmatig in het backoffice-systeem aan te passen en de klant hiervan op 8 HET TE BOUWEN SYSTEEM