Kalendersynkronisering med Microsoft Sync
Framework
Goran Pavicic
EXAMENSARBETE 2010
DATATEKNIK
Kalendersynkronisering med Microsoft Sync
Framework
Calendar synchronization With Microsoft Sync
Framework
Goran Pavicic
Detta examensarbete är utfört vid Tekniska Högskolan i Jönköping inom ämnesområdet informationsteknik. Arbetet är ett led i den treåriga
högskoleingenjörsutbildningen. Författaren svarar själv för framförda åsikter, slutsatser och resultat.
Handledare: Christer Thörn Omfattning: 15 poäng Datum:
Abstract
The main aim of this project is to implement an application that synchronizes a calendar in Outlook with a certain calendar on a SharePoint server. The goal is to enable calendar sharing through one interface amongst users in different corporations. Microsoft Sync Framework was selected as the environment in which the synchronisation algorithm was to be developed. The main task lies in developing the two synchronisation providers, which represent each data
source during a synchronisation session. They build a layer that separates Microsoft Sync Framework from the complexity of the data sources. Methods for transferring data amongst the two data sources and keeping metadata up to date are two additional tasks that the synchronisation providers are responsible for. The solution is deployed as an “add in” in Outlook.
Sammanfattning
Huvuduppgiften med detta projekt är att skapa en applikation som
synkroniserar Outlooks kalender med SharePoint server. Målet är att kunna se flera användares Outlook kalender i ett och samma gränssnitt trots att de är organisatoriskt åtskilda och från olika företag. För att lösa synkronisering används Microsoft Sync Framework. Huvuddelen av arbetsbördan består i att utveckla två leverantörer som representerar respektive datakälla under en synkroniseringssession. Leverantörerna utgör ett lager mellan Microsoft Sync Framework och datakällorna. De tillhandahåller metoder för att överföra objekt mellan datakällorna, samt ser till att metadatat reflekterar ändringarna i
datakällan. Applikationen levereras i form av ett tillägg till Outlook.
Nyckelord
Innehållsförteckning
Figurförteckning ... 5
1
Inledning ... 6
1.1 BAKGRUND ... 6 1.2 SYFTE OCH MÅL ... 6 1.3 AVGRÄNSNINGAR ... 7 1.4 DISPOSITION ... 72
Teoretisk bakgrund ... 8
2.1 .NET ... 8 2.1.1 CLR ... 9 2.1.2 Garbage Collector ... 11 2.1.3 Klassbibliotek ... 11 2.1.4 C# ... 11 2.2 OBJEKTORIENTERAD PROGRAMUTVECKLING ... 122.2.1 Objekt och Klasser ... 12
2.2.2 Arv ... 13 2.3 XML ... 14 2.3.1 Element ... 14 2.3.2 XML-attribut ... 14 2.4 SHAREPOINT ... 15 2.4.1 Vad är Sharepoint ... 15
2.4.2 Sharepoint Web Services ... 16
2.5 CAML ... 16
2.5.1 CAML Queries ... 17
2.5.2 CAML Query Builder ... 18
2.6 MICROSOFT SYNC FRAMEWORK [12] ... 19
2.6.1 Komponenter [19] ... 20 2.6.2 Metadata ... 20 2.6.3 Exempel ... 21 2.7 UTVECKLINGSMODELL ... 24
3
Genomförande ... 26
3.1 INLEDNING ... 26 3.2 UTVECKLINGSMILJÖ ... 26 3.3 UTVECKLING... 28 3.3.1 Övergripande bild ... 28 3.3.2 Exempel – Filsynkronisering ... 303.3.3 Sharepoint och Outlook Provider ... 31
3.3.4 Inline vs. Asynkron... 32
3.3.5 Metoder för asynkron uppdatering av metadata ... 33
3.3.6 ID ... 35
3.3.7 Outlook och Calendar ... 35
3.3.8 OutlookAddin4 ... 37
3.4 DATAFLÖDE ... 41
4
Resultat ... 42
4.1 INSTALLATION ... 42
5
Slutsats och diskussion ... 46
5.1 FRAMTIDA ARBETE ... 47
6
Referenser ... 48
7
Sökord ... 50
Figurförteckning
FIGUR 1:HUVUDDELAR I SYSTEMET ... 7
FIGUR 2:C# KOMPILERING [7] ... 10
FIGUR 3:OBJEKTORIENTERINGENS TRE HÖRNPELARE ... 12
FIGUR 4:KLASSEN FORDON OCH TVÅ INSTANSER ... 13
FIGUR 5:ARV AV KLASSEN FORDON ... 13
FIGUR 6:EXEMPEL PÅ SITE COLLECTION [17] ... 15
FIGUR 7:EXEMPEL PÅ EN SITE ... 15
FIGUR 8:CAMLQUERY BUILDER [22] ... 18
FIGUR 9:VERSIONER ÄR METADATA FÖR VARJE OBJEKT SOM DELTAR I SYNKRONISERINGEN ... 21
FIGUR 10:SYNKRONISERING MELLAN DATAA OCH DATAB ... 21
FIGUR 11:DATABASER MED TILLHÖRANDE METADATA INNAN SYNKRONISERING ... 22
FIGUR 12:DATABASERNA OCH METADATA EFTER SYNKRONISERING ... 22
FIGUR 13:DATABASER OCH METADATA EFTER EN KONFLIKT.KNOWLEDGE FÖR DATAA ÄR (A5,B3) OCH (A4,B6) FÖR DATAB... 23
FIGUR 14:UTVECKLINGSMILJÖN OCH DE VIRTUELLA DATORERNA ... 28
FIGUR 15:ITERATIV UTVECKLING [21] ... 25
FIGUR 16:ÖVERSIKTSBILD SOM VISAR HUVUDKOMPONENTERNA I APPLIKATIONEN ... 29
FIGUR 17:METODER SOM ANROPAS AV MSF ... 32
FIGUR 18:OUTLOOK MENY ... 38
FIGUR 19:FORMULÄRET DÄR ANVÄNDAREN ANGER INSTÄLLNINGAR FÖR SYNKRONISERING ... 39
FIGUR 20:EXEMPEL PÅ UTSKRIFT UNDER EN SYNKRONISERINGSSESSION ... 41
FIGUR 21:INSTALLATIONSFILERNA ... 43
FIGUR 22:EN OMSTART KRÄVS ... 43
FIGUR 23:TILLÄGGET INSTALLERAT ... 44
FIGUR 24:LYCKAD INLOGGNING ... 45
1 Inledning
1.1 Bakgrund
Denna examensrapport handlar om implementeringen av en
synkroniseringslösning. Examensarbetet är det slutliga arbete som utförs inom det treåriga högskoleingenjörprogrammet Datateknik med inriktning
informationsteknik på Jönköping Tekniska Högskola.
Detta arbete utförs i samarbete med Webdivision AB. Webdivision AB är ett ungt företag som jobbar med programvara som tjänst med internet som
leveransplattform. De jobbar med Microsoft Sharepoint som bas för många av deras lösningar. Webdivision AB finns i Nässjö och Linköping.
Examensarbetet har utförts i samarbete med Nässjö-kontoret.
Outlook är ett välbekant verktyg som används av många företag för mail, kalenderplanering och som samarbetsverktyg. Sharepoint är ett relativt nytt verktyg från Microsoft som vuxit kraftigt på senare tid och som syftar till att underlätta informationshanteringen och samarbete inom företag. Sharepoint erbjuder möjligheten att skapa gemensamma arbetsytor inom en grupp för att samla information på ett och samma ställe. Det är ett kraftfullt verktyg med vilket man på kort tid kan skapa avancerade funktioner, såsom dokumentarkiv, forum och bloggar. Uppdraget bestod i att implementera en skräddarsydd applikation som synkroniserade Outlooks huvudkalender med en kalender i Sharepoint. Målet är att kunna se flera användares Outlook-kalender i ett och samma gränssnitt trots att de är organisatoriskt åtskilda och från olika företag. Detta för att kunna ha tillgång till en projektgrupps medlemmars kalendrar på en projekt-plats. Figur 1 visar en övergripande bild över de olika delarna i system.
1.2 Syfte och mål
Målet med detta examensarbete är att utveckla en prototyp som synkroniserar Outlooks huvudkalender med en bestämd kalender i SharePoint. Applikationen ska uppfylla följande krav:
1. Tvåvägs synkronisering med Sharepoint
2. Kompatibelt med Outlook 2003/2007 och äldre versioner 3. Flexibel hantering av användaruppgifter
Figur 1: Huvuddelar i systemet
1.3 Avgränsningar
Projektet baserar sig på Microsofts .Net-ramverk och applikationen skrivs i C#. Huvudsyftet med projektet är inte att utveckla en fullfjädrad
synkroniseringslösning mellan Sharepoint och Outlook utan att skapa en stabil prototyp som därefter kan byggas på med ytterligare funktionalitet efter
önskemål. Efter samråd med uppdragsgivaren bestämdes att ingen
programmering skulle ske direkt på Sharepoint-servern då risken fanns att eventuella buggar påverkade prestandan på hela servern. Därmed ska all kommunikation mellan Outlook-klienten och Sharepoint endast ske via de fördefinierade Webservices som finns i Sharepoint.
1.4 Disposition
Teoretisk bakgrund
I detta avsnitt behandlas kort de tekniker och verktyg som används i projektet för att även den oinvigde ska ha möjlighet att förstå de övriga delarna i
rapporten.
Genomförande
Under detta avsnitt redovisas metoderna som använts för att lösa problemen. Här tas nackdelarna och fördelarna upp med den valda metoden.
Resultat
I detta kapitel ges övergripande bild av slutprodukten och hur applikationen används.
Slutsats och diskussion
I detta avsnitt görs en allmän reflektion kring uppdraget. Här resoneras kring förbättringar som göras i framtida versioner av programmet.
Microsoft Sync Framework
2 Teoretisk bakgrund
I detta avsnitt behandlas de mest väsentliga tekniker som använts i
utvecklingsarbetet. Ämnena behandlas endast ytligt och avsnittet är avsett att kort informera läsaren om de verktyg och tekniker som legat till grund för utvecklingsarbetet. Följande ämnen kommer att behandlas i kapitlet:
.Net
Objektorienterad utveckling
Sharepoint
XML
Microsoft Sync Framework
.NET är den utvecklingsplattform som används i det här projektet och som egentligen hela projektet bygger på. För arbete mot .Net valdes
programmeringsspråket C#. Eftersom C# är ett objektorienterat
programmeringsspråk kommer även applikationen implementeras enligt den objektorienterade utvecklingsmodellen. Sharepoint är en av huvuddelarna i projektet. Det är en av de två datakällor som ska synkroniseras. All
kommunikation med Sharepointservern sker via Webservices. För
informationsöverföring mellan Sharepoint och applikationen används CAML och XML. Microsoft Sync Framework används för att realisera
synkroniseringsalgoritmen.
2.1 .NET
.Net lanserades år 2000 och är Microsofts ramverk som möjliggör utveckling av Windows applikationer, Web applikationer och Webservices med en uppsjö olika programmeringsspråk och tekniker utan att programmeraren behöva ta hänsyn till detaljer såsom minneshantering och andra lågnivådelar. [20] En av huvudpunkterna med .Net är att ramverket är oberoende av
programmeringsspråk. C# och VB.Net är de två vanligaste
programmeringsspråken för programmering mot .Net, även om andra tekniker kan användas är de inte lika vanliga. På senare tid har ett stort antal språk anpassats för att fungera ihop med .Net, däribland Python och COBOL1.
.Net ramverket består av två huvudkomponenter [5] : 1. Common Language Runtime (CLR)
2. Class Library
2.1.1 CLR
CLR (Common Language Runtime) är grunden i .Net ramverket och ansvarar för att ladda och exekvera programmet. CLR hanterar:
1. Minnet 2. Trådar 3. Undantag 4. Skräpinsamling
samtidigt som det eftersträvar stabilitet och säkerhet. CLR gör det möjligt för komponenter utvecklade i olika språk att interagera. Exempelvis kan en klass utvecklad i ett visst programmeringsspråk anropas och härledas från en applikation skriven i ett annat språk. [6] Detta är möjligt då kompilatorn använder CTS (Commontype system) för att definiera typer. CTS definierar datatypernas struktur, hur de används i minnet samt deras beteende. Syftet med CTS är att uppnå portabilitet mellan olika programmeringsspråk.
Språkoberoendet i .Net möjliggörs av att den kod som är skriven i till exempel C# eller VB.net inte direkt omvandlas till maskinkod (kod som exekveras av CPU:n) utan konverteras i ett mellanled till ett s.k. generiskt högnivåspråk vid namn CIL (Common Intermediate Language) och lagras i en .NET assembly.
CLI kompileras till plattformsspecifik kod först när den används. Förutom själva koden lagrar en .Net assembly även den metadata som beskriver
datatyperna som finns i CLI-koden. Exempelvis kan metadata beskriva vilka metoder och vilka typer som är implementerade i en klass. CLR behöver enbart tolka CIL-koden och behöver inte ta hänsyn till den ursprungliga koden. När filen sedan används på en viss dator kompileras den av JIT (Just-In-Time) kompilatorn som är en del av CLR. [8]Detta innebär att den slutgiltiga koden kan vara olika beroende på vilken dator den exekveras. När JIT-kompilatorn översätter CLI-instruktioner till maskinkod cachas2 dessa i minnet. Första gången en metod anropas till exempel PrintText(), kompileras CLI-koden till maskinkod. När samma metod anropas igen behöver den då inte kompileras utan körs direkt från cachen. [10] .Net ramverket finns även tillgängligt för handhållna enheter, om än med något färre funktioner som kör en JIT-kompilator anpassad för enheter med begränsade resurser.
2 Cache innebär att saker som används ofta, lagras på en lättåtkomlig plats, för att underlätta åtkomsten
.Net tillhandahåller även ett verktyg (NGEN) som möjliggör kompilering till maskinkod innan programmet exekveras. Detta steg utförs endast på den dator som slutligen kommer exekvera programmet eftersom datorns egenskaper (minne, processor) tas till hänsyn vid kompileringen. Fördelen med att använda NGEN är att starten vid exekvering tar mindre tid. [9]
Under exekveringen kompileras enbart de metoder som anropas och inte hela filen. Nästa gång samma metod anropas behöver den inte återigen kompileras. Även efter exekveringen fortsätter CLI kontrollera programmet. Figur 2 visar ett exempel på hur C# kod konverteras till maskinkod.
Figur 2: C# kompilering [7]
2.1.2 Garbage Collector
En av fördelarna med .Net är minneshanteringen. Felaktig hantering av minne är en av de främsta orsakerna till buggar och säkerhetshål i program. .Net befriar programmeraren från ansvaret att manuellt hantera minnet. Detta sköts per automatik av skräpinsamlaren (Garbage Collector) som håller alla öppna objekt under uppsikt och avgör vilka som inte behövs. En viktig anmärkning är att skräpinsamlaren enbart hanterar minnet. Om programmet använder andra resurser måste detta tas till hänsyn och resurserna frigöras av programmeraren. Skräpinsamlaren samlar inte heller objekt som refereras av pekare förrän de har frigjorts.
2.1.3 Klassbibliotek
Klassbiblioteket som är den andra huvuddelen i .Net ramverket är en omfattande objektorienterad samling återanvändbara
klasser/funktioner/metoder som .Net-kompatibla språk kan dra nytta av. Den innehåller metoder för att hantera trådar, I/O, grafiska objekt, interaktion med andra externa enheter. Till exempel finns det metoder för att underlätta arbete mot databaser, hantering av XML-dokument och webbprogrammering.
Biblioteket är uppdelat i hierarkiskt uppbyggda namnrymder (Namespaces) där
System är överst.
2.1.4 C#
C# är ett programmeringsspråk som är baserat på C++ och Java. Det har utvecklats av två Microsoft-ingenjörer, Andreas Hjelsberg och Scott Wiltamuth3 [20]. C# innehåller stöd för strukturerad, objektorienterad, och komponentbaserad programmering. C# innehåller nyckelord för att deklarera nya klasser, metoder och egenskaper samt stöd för att tillämpa inkapsling, arv och polymorfism vilket man kan förvänta sig av ett modernt objektorienterat programmeringsspråk. Klassdefinitioner kräver inte separata headerfiler. C# innehåller också stöd för delegater vilket gör det möjligt att anropa metoder indirekt. Liknande funktionalitet finns i C++ där man har möjlighet att anropa medlemsfunktioner med hjälp av pekare. Delegater används ofta i Windows-programmering för att knyta metoder till händelser.
3
2.2 Objektorienterad programutveckling
Objektorientering har på senare tid blivit en allt vanligare utvecklingsmodell som stöds av de flesta större programmeringsspråk däribland C#, C++ och Java. Den objektorienterade modellen utgår från de objekt som ingår i ett system snarare än de funktioner som ska utföras. Den traditionella synen på datorprogram brukar kallas för det funktionsorienterade synsättet medan den objektorienterade modellen uppfattar ett datorprogram som en modell av verkligheten. Objektorienterad programutveckling består i huvudsak av tre hörnpelare vilka visas i nedanstående figur.
Figur 3: Objektorienteringens tre hörnpelare
2.2.1 Objekt och Klasser
Objekt är de modeller som representerar verkligheten vilka programmet manipulerar för att utföra en viss uppgift. Objekten har en unik identitet och kan nås via deras namn eller pekare som hänvisar till objektet. Objekt har två typer av egenskaper, attribut och operationer.
Attribut anger objektets tillstånd som kan förändras under exekveringen. Vanligen kapslas attributen in och är inte åtkomliga utifrån och kan enbart ändras av objektets metoder. Detta sätt att dölja information för utomstående är utmärkande för objektorienterad programmering.
Den andra egenskapen, operationer även kallade metoder, är procedurer som objektet använder för att hantera attributen eller utföra andra funktioner. Precis som med attribut är det vanligt att metoder kapslas in.
Metoder och attribut kan deklareras som private, public eller protected. Dessa nyckelord anger hur öppna klassens egenskaper är för omgivningen.
En klass är en mall som beskriver hur objekt med samma uppbyggnad och
Figur 4: Klassen Fordon och två instanser
I ovanstående figur visas en UML-representation av klassen Fordon med attributen Längd, Bredd, Vikt samt metoderna Kör(), Bromsa(), Sväng(). Bil och
Buss är instanser/objekt av klassen Fordon.
2.2.2 Arv
Arv innebär att man använder en redan definierad klass när en ny klass skapas. Man utgår från den tidigare klassens egenskaper och lägger till nya egenskaper. Därmed är det möjligt att återanvända tidigare konstruerade objekt modifiera dess egenskaper och anpassa dem till den aktuella klassen. Den härledda
klassen ärver alla basklassens attribut och metoder. Genom arv bygger man upp en logisk hierarki mellan klasserna. Vissa programmeringsspråk som
exempelvis C++ tillåter multipelt arv vilket innebär att en klass kan härledas från flera basklasser.
Figur 5: Arv av klassen Fordon
I figur 5 visas ett UML-diagram över en arvshierarki. De lägst stående klasserna i arvshierarkin (Personbil, Lastbil) ärver alla egenskaper från Fordon-klassen.
2.3 XML
XML (eXtensible Markup Language) är regelverk för strukturering av data. XML-kodad data innehåller förutom själva datat även beskrivning av data vilket möjliggör för externa program att tolka och behandla data. XML
skapades och underhålls av W3C och är ett svar på de begränsningar som finns i HTML och SGML vid överföring av dokument med avancerad struktur över nätet [1]. Styrkan med XML som uppmärkningsspråk är dess utbyggbarhet (eng. extensible) vilket innebär att användaren själv kan skapa nya element och egenskaper vilket inte är möjligt i HTML. XML kan ses som ett metadata-språk för att beskriva uppmärkningsspråk [1]. I grund och botten är XML
strukturerade textdokument och kan skapas med ett enkelt textverktyg som exempelvis Notepad. .Net erbjuder ett antal klasser och verktyg som underlättar arbetet med XML bl.a. klasserna XmlReader och XmlWriter för hantering av XML-strömmar.
2.3.1 Element
XML-dokument är uppbyggda av element i hierarkisk ordning. Element definieras av en start- och en sluttagg. Starttaggen består av ett namn omgivet av vinkelparanteser medan sluttaggen utöver detta även innehåller ett
snedstreck. I nedanstående exempel är Namn ett element.
Den text som står mellan start och sluttagen är själva datat. I det här fallet en enkel textsträng men det kan även bestå av andra element s.k. underelement. I följande exempel är Student ett rotelement som har tre underelement
2.3.2 XML-attribut
Ett XML-attribut är ett värde som anges i XML-elementets starttagg och det innehåller ytterligare information om elementet.
<Namn>Adam</Namn>
<Student>
<Namn>Adam</Namn>
<Adress>Storgatan 17</Adress> <Mail>adam@gmail.com</Mail> </Student>
2.4 Sharepoint
2.4.1 Vad är Sharepoint
Sharepoint är ett samlingsnamn på en lösning utvecklade av Microsoft som syftar till att underlätta informationsdelning inom organisationer. Sharepoint är som utvecklingsplattform öppen för tredjepartslösningar. Utvecklare har
möjlighet att förbättra redan existerande funktioner eller skapa egna
skräddarsydda lösningar. Sharepoint bygger på Internet information Services.
Den förlitar sig på IIS4 att ta hand om HTTP anrop till port 80. Sharepoint kräver dessutom en SQL-server. Varje Sharepointserver antas vara del av en
farm, bestående av en eller flera servrar som tillhandahåller
Sharepoint-funktionalitet till användarna. I dess enklaste form består en farm av en server med IIS och en SQL-databas. Sharepoint består av hierarkiskt uppbyggda siter
(figur 7). En site är en behållare för information som lagras i form av listor eller dokumentbibliotek. Siten är dessutom en webbapplikation med ett
anpassningsbart UI. Alla siter är en del av en ”site collection” (figur 6).
Figur 6: Exempel på site collection [17]
Figur 7: Exempel på en site
4 IIS är en serverkomponent från Microsoft som erbjuder internetbaserade tjänster såsom HTTP-server
2.4.2 Sharepoint Web Services
Sharepoint erbjuder ett stort utbud av webservices vilka används för att få åtkomst till Sharepoint-information från fjärrklienter.
Sharepoints webservices anropas på samma vis som vanliga webservices[18]. En referens skapas till Sharepointservern, därefter används referensen som vilken annan namnrymd. För att kunna anropa webservicemetoder måste
användaren vara inloggad. En webservice som använts i det här projektet är List
webservice. Det används för göra insättningar eller hämta data från listor. En
lista kan t.ex. vara en kalender.
När en referens skapats till Webservice anges sedan användaruppgifterna
GetList metoden används för att hämta data från en lista vars GUID anges som
parameter när metoden anropas.
Metoden returnerar ett CAML-fragment.
2.5 CAML
CAML (Collaborative Application Markup Language) är ett XML-baserat språk som används för att bygga och anpassa webbsidor som baseras på
Sharepoint [2]. Dess funktionalitet kan i vissa avseenden även liknas vid SQL. CAML består av ett antal scheman som används för olika ändamål. View
Schemat används för layout och utformning av en sida medan Query Schemat
används för att skicka förfrågningar till Sharepoint och hämta data. CAML-schemat definieras och beskrivs i ett XML-dokument som lagras på Sharepoint servern och finns i:
Local_Drive:\Program Files\Common Files\microsoft shared\Web Server Extensions\12\TEMPLATE\XML [3]
CAML används:
I programkod, där CAML queries, skickas till de metoder som anropas i antingen Objektmodellen eller via Webservices
Bygga upp Sharepoint Webbsidor
lService.Credentials = newNetworkCredential(“username”,”password”);
2.5.1 CAML Queries
Sharepoint erbjuder ett antal olika sätt att hämta data från SharePoint listor till exempel via SharePoint Objektmodell, SharePoint WebServices och
Powershell [4]. I det här projektet används enbart de metoder som erbjuds via Webservices. Därmed kommer alla förfrågningar och datahämtning ske via Webservices. En CAML- förfrågan innehåller precis som andra XML-baserade språk ett rotelement, Query. Utöver detta kan även två andra element anges,
OrderBy och Where, men dessa kan utelämnas. OrderBy anger att de data som
returneras på en viss förfrågan ska sorteras i angiven ordning. Här anges vilka fält som ska sorteras och i vilken ordning.
I ovanstående exempel sorteras fälten först i stigande ordning enligt ”Adress”. Därefter avtagande enlig ”Years” och slutligen i avtagande ordning enligt
”Location”. Fieldref-elementetsyftar på det fält i listan för vilket förfrågan är
avsedd att exekveras. Name-attributet anger fältets namn, men det skulle likväl fungera att använda ID-attributet för att specificera ett fält enligt dess GUID.
Where-elementeti en CAML query kan liknas vid en ”SQL SELECT” förfrågan
och fungerar precis som en sådan, d.v.s. det används för att filtrera data enligt vissa kriterier. I nedanstående Where-förfrågan anges en Geq (Greater or equal) operator, fältnamnet som förfrågan avser, och värdet. (En sammanfattning av operatorerna finns i bilaga 1)
Value-elementet anger värdet för kriteriet. I elementets attribut markeras vilken
typ av data värdet hanteras som. I det här exemplet är det ett nummer. Fler än ett filtervärde kan anges genom att använda And och Or element.
<Query> <Where> <Geq>
<FieldRef Name="Age"/>
<Value Type="Number">25</Value> </Geq>
</Where> </Query>
<OrderBy>
<FieldRef Name="Adress"/>
<FieldRef Name="Years" Ascending="FALSE"/> <FieldRef Name="Location"/>
</OrderBy>
<Query> <Where> <Or> <Neq>
<FieldRef Name="Status"></FieldRef> <Value Type="Text"></Value>
</Neq> <IsNull>
<FieldRef Name="Status"></FieldRef> </IsNull>
</Or> </Where> </Query>
2.5.2 CAML Query Builder
CAML Query Builder är ett verktyg som är till stor hjälp då man skapar och
testar CAML Queries. Den ger användaren möjlighet att ansluta till Sharepoint-servern antigen via objekt modellen eller Webservices och skapa queries enligt WYSIWYG. Nedanstående bild visar enkelheten i att använda CAML Query Builder
2.6 Microsoft Sync Framework [12]
Microsoft Sync Framework (härefter MSF) är en synkroniseringsplattform från
Microsoft som möjliggör koordinering av data från olika källor. Med MSF har utvecklare möjlighet att bygga fullständiga ekosystem som integrerar
applikationer och datakällor oberoende av nätverksprotokoll eller datatyp. MSF
är utbyggbart för att hantera alla typer av data, såsom SQL-databaser, filer, nätverksresurser och mobila enheter, oberoende av protokoll över vilket data överförs. Utöver detta erbjuds verktyg för roaming och hantering av data i offline-miljö vilket gör det möjligt för användare att arbeta mot en lokal kopia under den tid de inte är uppkopplade.
MSF har inbyggd funktionalitet för att hantera:
Fel i applikationen – Om applikationen eller datakällan havererar under en synkroniseringssession eller om det uppstår andra hinder som
nätverksfördröjningar, finns det risk att data korrumperas. MSF kan återhämta sig från dessa missöden.
Nätverksavbrott – MSF hanterar eventuella nätverksavbrott som kan tänkas uppstå under en synkroniseringssession.
Konflikthantering – Om ett och samma objekt ändras ”samtidigt” på två eller fler källor uppstår en konflikt (mer om konflikthantering i avsnitt 2.6.4.1)
En av de viktigaste aspekterna med MSF är möjligheten att använda
egenutvecklade synkroniseringsleverantörer (eng. synchronizationprovider). En leverantör är en komponent som ingår i synkroniseringssessionen och
representerar datakällan som synkroniseras. Leverantören fastställer vilka
ändringa som skett i data samt applicerar ändringar från de andra datakällorna.
2.6.1 Komponenter [19]
MSF består av följande komponenter:
MSF Runtime – SDK, tillåter utvecklare att använda de existerande leverantörer som följer med MSF eller skapa egna.
Metadata verktyg – MSF skeppas med en inbyggd Microsoft CE SQL server samt de verktyg som krävs för att lagra och hantera metadata.
Inbyggda leverantörer – Följande datakällor har inbyggt synkroniseringsstöd i MSF:
o ADO.NET - För synkronisering av databaser o Filer – För synkronisering av filer och kataloger o FeedSync – För synkronisering av RSS-strömmar.
2.6.2 Metadata
Metadata beskrivs ofta som ”data om data”. Metadata kan exempelvis vara det
senaste ändringsdatumet för en fil eller datumet då filen skapades. Om filen innehåller data så är de två ovan nämnda egenskaperna just ”data om data” d.v.s. metadata. MSF använder metadata för att hålla reda på tillståndet för varje objekt som synkroniseras. Plattformen erbjuder en fulländad lösning för
hantering av metadata. Om så krävs finns möjlighet att utveckla en egen metadatastruktur som kan användas i MSF. Metadata kan delas in i tre kategorier:
Versioner (eng. versions) – versioner är information som associeras med varje enskilt objekt som deltar i synkroniseringen. Versionsdata
markerar var och när ett objekt skapats eller när det senast ändrades. Det innehåller även ett unikt ID för varje objekt. Ett objekt kan t.ex. vara en rad i en databas eller som i det här projektet en bokning i en kalender där varje objekt måste ha ett unikt ID. En ”version” består av två
egenskaper, ”creation version”, som anger var och när objektet skapades samt en ”update version” som anger var och när objektet ändrats. Var och
en av dessa två egenskaper innehåller två komponenter:
o Tick Count - Ett värde som identifierar varje enskild ändring Detta värde ökas för varje gång ett nytt objekt skapas eller ändras. o Replica ID – Identifierar den datakälla där ändringen genomfördes. En sammanfattning av en versions olika komponenter visas i Figur 9.
Figur 9: Versioner är metadata för varje objekt som deltar i synkroniseringen
Kunskap (eng. knowledge) - Är en sammanfattning av de ändringar som
skett i en datakälla. Knowledge består av datakällans ID samt det senaste
”Tick count”-värdet. ”Knowledge” används av MSF för att upptäcka
ändringar och konflikter.
Gravstenar (eng. tombstones) - Innehåller information om objekt som
raderats från datakällan. De innehåller ett ID, deletion version, och
creation version.
2.6.3 Exempel
Detta avsnitt är tänkt att ge en generell bild över hur MSF ”tolkar” metadata för att avgöra vilka ändringar som ska appliceras på datakällorna. Nedanstående figur visar de komponenter som ingår i ett system som ska synkroniseras.
Figur 10: Synkronisering mellan DataA och DataB
MSF DataA-Provider DataB-Provider DataA Metadata DataB Metadata DataA DataB Destination Källa Update version Creation version ID Tick Count Replica ID Tick Count Replica ID
I följande exempel beskrivs hur synkronisering går till. För enkelhetens skull antar vi att två databaser (DataA och DataB) ska synkroniseras. DataA initierar synkroniseringen vilket innebär att DataA är källan och DataB är destinationen. Objekten som synkroniseras är raderna i tabellen vilket illustreras i figur 11. Varje rad har ett unikt ID-nummer i databasen.
Figur 11: Databaser med tillhörande metadata innan synkronisering
Knowledge (en sammanfattning av de ändringar som en datakälla är medveten
om) är för DataA = A4, där A är ett unikt ID för datakällan och 4 är ”tick count”-värdet. DataB=B3. Under synkroniseringen skickar DataB sin knowledge
till DataA. Med hjälp av denna information upptäcks de ändringar som
destinationen inte är medveten om och därefter skickas ändringarna från källan till destinationen. Destinationen använder metadata för att avgöra vilka objekt i DataA som den själv inte är känner till. Här upptäcks också eventuella
konflikter. Därefter begär destinationen de faktiska objekten (raderna) från källan. I det här fallet begärs raderna med ID-nummer 1 och 2. Destinationen sätter in ändringarna i databasen och uppdaterar metadatat. För att uppdatera DataA med ändringar är tillvägagångssättet detsamma fast då byter destination och källa plats. Efter en fullständig synkronisering har både DataA och DataB Knowledge = A4B3, d.v.s. de är synkroniserade. Se figur 12.
2.6.3.1 Konflikter
Om vi fortsätter på föregående exempel där båda databaserna är synkroniserade och antar att en och samma rad (rad 1) uppdateras i båda databaserna då uppstår en konflikt. Figur 13 visar databaserna och metadatat vid en konflikt.
1. DataB skickar knowledge till DataA.
2. Källan (DataA) behandlar informationen och beräknar de ändringar som ska skickas till destinationen. Den märker även att destinationen inte är medveten om den ändring som skett vid ”tick count” 5 på rad 1.
3. DataB behandlar informationen som skickats från källan och numrerar dess egna ändringar. Nu framgår det att samma rad även uppdaterats i den lokala databasen och det existerar två ändringsversioner för samma rad, A5 och B6. Konflikten har upptäckts.
4. Följande metoder erbjuds för att lösa konflikter a. Källan vinner
b. Destinationen vinner c. Hoppa över ändring d. Slå samman ändringarna e. Spara konflikten
Figur 13: Databaser och metadata efter en konflikt. Knowledge för DataA är (A5, B3) och (A4,B6) för DataB.
2.7 Utvecklingsmodell
Utvecklingsprocessen i det här projektet påminner närmast om den s.k. Iterativa
utvecklingsmodellen [15].
Den iterativa utvecklingsmodellen bygger på att endast en del av
funktionaliteten implementeras och testas för varje iteration. Varje iteration går igenom hela utvecklingsprocessen, till skillnad från den traditionella
vattenfallsmodellen där varje steg i utvecklingsmodellen endast utförs en gång.
Figur 15 visar den iterativa utvecklingsmodellen.
Nackdelen med vattenfallsmodellen är att förstudien definierar hur slutresultatet kommer bli [13]. Även om noga förstudier görs är det omöjligt att förutse vilka problem som kan uppstå under utvecklingen. Vattenfallsmodellen är helt enkelt för stel för att hantera förändringar.
Vattenfallsmodellen var direkt olämplig i det här projektet då jag vid projektets början varken var fullt insatt i Outlook-programmering eller Sharepoint.
Projektet var mer av ett utforskande slag och revideringar i planeringen och design förekom under hela utvecklingsprocessen. De främsta fördelarna med iterativ utveckling:
Möjliggör ändringar av krav under projektets gång - utökningar av kravspecifikationen under utvecklingen kan vara frustrerande och tidskrävande. Vid iterativ utveckling kan tillägg av funktionalitet ske på ett tidigt stadium.
Designfel upptäcks och korrigeras lättare – fel i applikationen upptäcks i ett tidigt skede eftersom de är enklare att hitta och åtgärda.
Feedback från uppdragsgivaren – uppdragsgivaren har möjlighet att testa lösningens delar under utvecklingen och komma med feedback.
Integration av funktionalitet sker löpande – att integrera de olika komponenterna först i slutet av projektet kan innebära att delar av applikationen måste skivas om. Detta kan i vissa fall motsvara upp till 40 % av det totala arbetet [14].
Projektets karaktär gjorde det möjligt att skapa och testa funktionalitet utanför huvudprogrammet. Till exempel skapades en klass för hantering av
kalenderinformation i Outlook separat och efter omfattande tester av klassens metoder kunde den inkorporeras i huvudprogrammet. På så vis byggdes programmets funktionalitet ut för varje iteration.
3 Genomförande
Det här avsnittet beskriver hur arbetet utförts, hur jag gått tillväga för att uppfylla kraven som ställts på applikationen och lösa de problem som uppstått under utvecklingsarbetet.
3.1 Inledning
De första kontakterna med uppdragsgivaren togs via mail. Här diskuterades projektet i allmänna drag, vad som skulle utföras och vilka förutsättningarna var. Uppdragsgivaren förklarade företagets nisch samt deras målsättningar med projektet. Uppdragsgivaren gav även en allmän introduktion i Sharepoint, vilket var till mycket nytta vid tidpunkten då Sharepoint var för mig ett helt obekant och outforskat område.
Vid ett senare tillfälle bestämdes en första träff där det i detalj diskuterades vad som skulle utföras samt vilka verktyg som fanns till förfogande. Vid det här tillfället erhölls en klar bild av uppdraget. Därefter följde en mer teknisk diskussion där tänkbara designmodeller behandlades . Uppdragsgivaren var mycket väl insatt i ämnet och var till stor hjälp vid de större designdragen. Efter det första mötet sammanställdes en preliminär kravspecifikation som godkändes av uppdragsgivaren och handledaren och som låg till grund för anmälan om examensarbete.
Vid slutet av projektet bestämdes ytterligare en träff. Här diskuterades den senaste versionen av programmet samt ändringar och tillägg som skulle göras. Huvuduppgiften med projektet var att bygga en stabil prototyp för
synkronisering mellan Outlook och Sharepoint, funktionalitet skulle därefter läggas till efter behov. Utveckling och förbättring av programmet kommer fortsätta även efter examensarbetets slut.
3.2 Utvecklingsmiljö
Under utvecklingsarbetet krävdes en Sharepointserver mot vilken applikationen kunde designas och testas. Uppdragsgivaren erbjöd en avskild domän mot deras Sharepointserver mot vilken applikationen kunde testas. Tillräcklig behörighet lämnades för åtkomst till servern via webbgränssnittet för att kunna utföra alla de funktioner som egentligen behövdes, skapa listor, hämta data och sätta in data. Av förklarliga skäl begränsades åtkomst till de allra känsligaste
funktionerna på servern. Detta och faktumet att jag inte hade direkt åtkomst till huvudservern för att genomföra eventuella ändringar var avgörande för beslutet att sätta upp en egen virtuell Sharepointserver.
Vmware Workstation 6.5.1 valdes som virtualiseringslösning då detta för tillfället är ett av de främsta programmen inom området. VMware kan emulera hårdvara för att exempelvis montera ISO-filer som CD-ROM enheter i den virtuella miljön eller .vmk-filer för hårddiskar. VMware gör det möjligt för de virtuella datorerna att få åtkomst till nätverket, antigen genom NAT men de kan även konfigureras för att erhålla egna IP-adresser. Office 2007 installerades på en av de virtuella maskinerna som skulle fungera som testdator för exekvering av applikationen. Efter installationen av de komponenter som krävdes för att exekvera Outlook applikationen i den virtuella testdatorn, togs en s.k.
”Snapshot” av datorn. ”Snapshot” i VMware gör det möjligt att återgå till ett
tidigare stadium i en virtuell dator. Detta verktyg var till stor hjälp då de första versionerna av programmet testades vilka bl.a. hade ett antal buggar som medförde att programmet var svårt att radera från systemet. Med hjälp av ”Snapshots” återställdes den virtuella datorn till skedet då datorn var
nyinstallerad. På så vis kunde varje version av applikationen testas utan att de gamla versionerna inverkande. Sammanlagt skapades tre virtuella datorer:
1. Windows 2003, Sharepoint, MS SQL-server 2. Windows XP – MS SQL-server
3. XP – klient
Detta gav full tillgång till Sharepointservern för att utföra eventuella ändringar, fullständiga användarrättigheter och extremt korta svarstider. Installation av SP och annan nödvändig mjukvara fungerade problemfritt. Figur 14 visar
utvecklingsmiljön.
Visual Studio 2008, var det självklara valet av utvecklingsmiljö. Det är ett av de smidigaste verktygen för utveckling i .Net miljö. Den senaste versionen innehåller dessutom VSTO5 (Visual Studio Tools for Office).
5
3.3 Utveckling
I detta avsnitt behandlas de tekniska aspekterna av projektet, de problem som uppstått samt hur dessa har lösts.
Min huvuduppgift har varit att utveckla metoder som MSF använder för att sätta in, uppdatera och radera objekt i Outlook respektive Sharepoint samt upprätthålla metadatabaser som representerar objekten i datakällorna.
3.3.1 Övergripande bild
I nedanstående bild, figur 16, presenteras huvudkomponenterna som ingår i programmet samt deras respektive ändamål. I efterföljande avsnitt kommer delar av huvudkomponenterna behandlas mer ingående.
2,8 GHz 1 GB Windows Server 2003 SP MS SQL 2005 IIS 192.168.0.109 2,8 GHz 512 MB Windows XP MS SQL 2005 Office 2007 192.168.0.110 2,8 GHz 512 MB Windows XP 192.168.0.111
Intel Core 2 Quad 2,8 GHz 4GB RAM
Windows Vista Visual studio 2008 VMware Workstation 6.5.1
OutlookAddin4 – Sköter interaktionen med användaren, presenterar ett formulär för användaren, tar emot och behandlar indata från användaren. Den innehåller två hjälpklasser som sparar användaruppgifter till registret och överför metadatafilerna till Sharepointservern.
MySyncProviderOU/ MySyncProviderSP – De två leverantörer (eng.
providers) som representerar respektive datakälla (Outlook och Sharepoint) i
en synkroniseringssession.
Outlook/Calendar – Två hjälpklasser som representerar en bokning i
respektive kalender. De innehåller metoder för att skapa, hämta, uppdatera och radera bokningar i Outlook och Sharepoint-kalendern.
Outlook - Den ena datakällan som ska synkroniseras. Sharepoint – Den andra datakällan.
OU Metadata/ SP Metadata – Metadata för varje datakälla som ingår i synkroniseringen sparas i form av två filer. Metadatat representerar objekten som finns i datakällorna. MSF använder metadata för att avgöra vilka objekt som ska skapas, uppdateras och raderas.
OutlookAddin4 Sync Agent MySyncProviderOU MSF Runtime MSF Runtime MySyncProviderSP Sync Session OU Metadata SP Metadata Outlook Share-point Outlook Calendar
De två synkroniseringsleverantörerna ”kommunicerar” med varandra under en synkroniseringssession. De är anslutna till en ”Sync agent” som dirigerar
synkroniseringen.”Sync agent” är ansvarig för att initiera och upprätthålla sessionen. I agenten definieras även vilken datakälla som är källan respektive destinationen. I det här projektet är Outlook-kalendern alltid källan och Sharepoint-kalendern
destinationen. Under en synkroniseringssession är dataflödet alltid enkelriktat d.v.s. de två leverantörerna kan inte arbeta samtidigt. En leverantör (källan) skickar ändringar och den andra leverantören (destinationen) applicerar ändringarna.
3.3.2 Exempel – Filsynkronisering
Vi ska först se ett exempel på hur synkronisering av två kataloger fungerar med hjälp av den inbyggda leverantören för filsynkronisering. Den inbyggda leverantören möjliggör med enbart ett par rader kod synkronisering av filer, kataloger, underkataloger på NTFS, FAT och SMB filsystem.
Ovanstående exempel innehåller de komponenter som illustreras i figur 16 och som behövs för en lyckad synkronisering
static void Main(string[] args) {
// FilesyncProvidern initieras
FileSyncProvider kalla = new FileSyncProvider(Guid.NewGuid(), "c:\\katalog1"); FileSyncProvider destination = new FileSyncProvider(Guid.NewGuid(), "c:\\katalog2");
//SynckAgenten skapas
SyncOrchestrator SyncAgent = new SyncOrchestrator();
//I SyncAgenten anges vilken datakälla som är källan och vilken som är destinationen
SyncAgent.LocalProvider = kalla; SyncAgent.RemoteProvider = destination; //Synkronisering Initieras SyncAgent.Synchronize(); }
3.3.3 Sharepoint och Outlook Provider
Det som gör MSF flexibelt och utbyggbart är möjligheten att skapa egna leverantörer (providers). Leverantörerna fungerar som ett interface för att dölja den underliggande datakällans komplexitet för MSF. För att kunna
synkronisera andra datakällor, förutom de tre som har inbyggt stöd i MSF, krävs en specialanpassad provider.
En leverantörs uppgifter beror på dess tillstånd under synkroniseringen: Destination:
1. Tillhandahåller den lokala datakällans knowledge
2. Ta emot en förteckning av ändringar från källan 3. Upptäcka konflikter
4. Applicera ändringar på den lokala datakällan Källa:
1. Avgör med hjälp av destinationens knowledge de ändringar som behöver skickas till destinationen
2. Skickar förteckning över ändringarna till destinationen
3.3.3.1 Implementering
Det rekommenderade sättet att skiva en egen provider är att implementera
(override) metoder från tre klasser i MSF [16].
1. KnowledgeSyncProvider
2. IChangeDataRetriever (interface)
3. INotifyingChangeApplierTarget (interface)
Ovanstående exempel visar klassdefinitionerna för leverantörerna.
publicclassMySyncProviderSP : KnowledgeSyncProvider, IChangeDataRetrieverINotifyingChangeApplierTarget
{…
publicclassMySyncProviderOU : KnowledgeSyncProvider, IChangeDataRetriever,INotifyingChangeApplierTarget
Under en vanlig synkroniseringssession anropar MSF följande metoder som ska finnas tillgängliga i den egenutvecklade providern:
Metodnamn Anropas
på Uppgift
BeginSession
Båda Informerar providern om att en synkroniseringssession startar
GetSyncBatchParameters
Destination Returnerar knowledge
GetChangeBatch
Källan Avgör med hjälp av destinationen knowledge de ändringar som behöver skickas till destinationen
ProcessChangeBatch
Destination Upptäcker konflikter och applicerar ändringar
LoadChangeData
Källan Skickar de faktiska objekten
SaveItemChange
Destination Objekten sparas i datakällan
StoreKnowledgeForScope
Destination Sparar den nuvarande knowledge
EndSession
Båda Informerar providern om att en synkroniseringssession avslutas
Figur 17: Metoder som anropas av MSF
3.3.4 Inline vs. Asynkron
Innan en synkroniseringssession påbörjas måste vi fastställa att de ändringar som gjorts i datakällan även reflekteras i dess metadata. Det finns två sätt att spåra ändringar och applicera dessa på metadatat.
Inline: Används i de tillämpningar där det är smidigt att lägga till funktionalitet
som uppdaterar metadatat samtidigt som ändringar görs i själva datakällan. Detta kan t.ex. göras i databaser där det är möjligt att med hjälp av ”triggers”
uppdatera metadatat i samma skede som en rad ändras. Detta är det enklaste och säkraste sättet att spåra ändringar, däremot är det sällan implementerbart.
Asynkron: I den här metoden sker uppdateringar i metadata skilt från
ändringarna i datakällan. En separat funktion söker igenom datakällan efter ändringar och uppdaterar metadatat därefter innan synkroniseringssessionen initieras. Metoden används i de fall där det inte är möjligt att uppdatera
metadatat samtidigt som objektet ändras. Det enklaste sättet att spåra ändringar asynkront är att spara tillståndet för ett objekt efter varje synkronisering och sedan jämföra det med objektet innan nästa synkroniseringssession påbörjas Denna metod tillämpas i projektet för att spåra ändringar i Outlook-kalendern och Sharepoint-kalendern. Även om inline-metoden skulle kunna tillämpas i Outlook med events är det omöjligt att implementera något liknande i
Sharepoint med enbart Webservices. Därmed bestämdes att asynkron-uppdatering av metadata skulle användas.
Det har funnits idéer om att använda en funktion som med korta mellanrum kontrollerar om det skett några ändringar i Sharepoint-kalendern. Med denna funktion skulle en inline-liknande metod för uppdatering av metadat kunna tillämpas. För tillfället används enbart den asynkrona metoden vilket kan komma att ändras i framtida versioner av programmet.
3.3.5 Metoder för asynkron uppdatering av metadata
Utöver de metoder som MSF kräver (Figur 17), har de två leverantörerna som implementerats ytterligare tre metoder för att hantera asynkron-uppdatering av metadata.
SaveLastSyncTime() - Sparar tidpunkten då den senaste synkroniseringen genomfördes
GetLastSyncTime() – Hämtar tidpunkten då den senaste synkroniseringen genomfördes
UpdateMetadataStoreWithChanges() – Uppdaterar metadatat
3.3.5.1 UpdateMetadataStoreWithChanges()
Metoden anropas innan varje synkroniseringssession initieras och den
upptäcker om ändringar skett i datakällan efter den senaste synkroniseringen. Exempelvis kan nya bokningar ha lagts till i kalendern, bokningar kan ha ändrats eller tagits bort och dessa ändringar ska även representeras i metadatat. Metoden går efter följande steg:
1. En extern hjälpmetod anropas och hämtar en lista (Dictionary) bestående av ID nummer och det senaste
uppdateringsdatumet för bokningar i kalendern som är högst
en vecka gamla (vi synkroniserar endast den senaste veckans bokningar och framåt).
2. Alla objekt i metadatabasen markeras som raderade.
3. Om ett ID nummer finns i listan men inte i metadatabasen innebär det att en ny bokning skapats i kalendern. Detta måste då markeras i metadatabasen.
4. Om ett ID nummer finns i listan och i metadatabasen och dess senaste ändringsdatum är efter senaste synkroniseringen innebär det att en uppdatering skett. Därmed måste metadatats
changeversion ändras.
5. Om ett ID nummer finns i listan och i metadatabasen men dess senaste ändringsdatum är äldre än den senaste synkroniseringen innebär det att inga ändringar skett efter senaste
synkroniseringen. Rapportera att objektet fortfarande ”lever”.
6. Alla återstående objekt i metadatabasen kvarstår som raderade (se steg 1).
Det uppstår ett problem när absoluta tidsstämplar används i ovanstående metod. Vi tar för givet att den lokala datorns och Sharepointserverns systemklockor är synkroniserade vilket i de flesta fall inte är riktigt. Detta kan medföra
förödande konsekvenser för synkroniseringen. Problemet löstes genom att ta hänsyn till den tidsskillnad som finns mellan den lokala datorn och Sharepoint-servern när SaveLastSyncTime()anropas.
ItemMetadata MetaDataObjekt = _metadata.FindItemMetadataById(ID); if (MetaDataObjekt == null)
{
MetaDataObjekt = _metadata.CreateItemMetadata(ID, newSyncVersion(0, _metadata.GetNextTickCount())); MetaDataObjekt.ChangeVersion = MetaDataObjekt.CreationVersion;
_metadata.SaveItemMetadata(MetaDataObjekt); }
if (_calendarId.Value.CompareTo(GetLastSyncTime()) > 0) {
MetaDataObjekt.ChangeVersion = newSyncVersion(0, _metadata.GetNextTickCount()); _metadata.SaveItemMetadata(MetaDataObjekt);
}
_ metadata.DeleteDetector.ReportLiveItemById(ID); _metadata.DeleteDetector.MarkAllItemsUnreported();
3.3.6 ID
För att kunna spåra ett objekt som deltar i synkronisering mellan två datakällor måste objektet kunna identifieras med ett unikt globalt ID-nummer. Det innebär att vi vid insättning av en ny rad i en Sharepoint lista ska kunna ange ID numret för raden. Detta är dock inte möjligt då Sharepoint för varje ny rad automatisk skapar ett ID nummer. Vi har därmed ingen möjlighet att själva bestämma ID-numret. Problemet löstes genom att skapa ett gömt fält (SQLID) i kalenderlistan som används för att lagra det globala ID-numret. Varje rad i kalendern består därmed av två ID-nummer, det som används internt av Sharepoint och det globala som används vid synkronisering.
Vid första synkroniseringen kontrolleras om SQLID finns, annars skapas det automatisk.
På samma vis skapas en ”Itemproperty” vid namn SQLID2 för varje bokning som finns i Outlook kalendern. Varje objekt i kalendern innehåller de vanliga egenskaperna såsom ”Ämne”, ”Beskrivning”och ”Starttid”. Outlook erbjuder möjlighet att lägga till ytterligare egenskaper med hjälp av Add-metoden för varje objekt.
3.3.7 Outlook och Calendar
Outlook och Calendar är två hjälpklasser till MySyncProviderOU respektive
MySyncProviderSP och ansvarar för all informationsöverföring mellan datakällorna. Klasserna fungerar som ett lager mellan leverantörerna och datakällornas komplexitet. De utför grundläggande operationer såsom skapa, hämta, uppdatera och ta bort bokningar från Outlook respektive Sharepoint kalendern. (I bilaga 2 visas en sammanfattning av klassernas egenskaper)
ndNewFields.InnerXml = "<Method ID='1'>
<Field Type='Text' Hidden='TRUE' DisplayName='SQLID' FromBaseType='TRUE'/> </Method>";
lService.UpdateList(listName, ndProperties, ndNewFields, null, null, null);
3.3.7.1 Outlook
Create() – Skapar en ny bokning i Outlooks huvudkalender. Klassens
egenskaper överförs till den nya bokningens motsvarigheter.
dsffsdfsdfdshgjghjghjghj
Update() – Uppdaterar en bokning med ett visst ID-nummer. Här används den
inbyggda funktionen Find() för att hitta bokningen baserat på ID-numret.
Delete() – Raderar en bokning från Outlooks kalender baserat på SQLID. publicvoid Create()
{
AppointmentItem oAppointment= null;
oAppointment = (AppointmentItem)MyApplicationInstance.CreateItem(OlItemType.olAppointmentItem); oAppointment.ItemProperties.Add("SQLID2", OlUserPropertyType.olNumber, true, true);
oAppointment.ItemProperties["SQLID2"].Value = m_SQLID; oAppointment.Subject = m_Title; oAppointment.Body = m_Description; oAppointment.Location = m_Location; oAppointment.Start = m_EventDate; oAppointment.End = m_EndDate; oAppointment.Location = m_Location;
oAppointment.Sensitivity = OlSensitivity.olNormal;
oAppointment.ReminderMinutesBeforeStart = ReminderMinutesBeforeStart; oAppointment.Save();
oAppointment = null; }
publicvoid Update() {
AppointmentItem oAppointment2 = (AppointmentItem)oItems.Find("[SQLID2] = '" + m_SQLID + "'"); if (oAppointment2 != null) { oAppointment2.Subject = m_Title; oAppointment2.Body = m_Description; oAppointment2.Location = m_Location; oAppointment2.Start = m_EventDate; oAppointment2.End = m_EndDate; oAppointment2.Location = m_Location; oAppointment2.ReminderSet = false;
oAppointment2.Sensitivity = OlSensitivity.olNormal;
oAppointment2.ReminderMinutesBeforeStart = ReminderMinutesBeforeStart; oAppointment2.Save(); } oItems = null; oAppointment2 = null; }
publicvoid Delete() {
Items oItems = MyCalendarItem.Items;
AppointmentItem oAppointment2 = (AppointmentItem)oItems.Find("[SQLID2] = '" + m_SQLID + "'"); oAppointment2.Delete();
oItems = null; oAppointment2 = null; }
3.3.7.2 Calendar
Create() – Skapar en bokning i Sharepointkalendern. Webservicemetoden,
UpdateListItems tar emot ett XML-dokument med instruktioner.
Delete() – Raderar en bokning från Sharepointkalendern. Här anropas en
hjälpmetod för att konvertera objektets SQLID till ID numret som används i Sharepoint kalendern.
3.3.8 OutlookAddin4
OutlookAddin4 är den del av applikationen som binder samman alla
komponenter. OutlookAddin4 initierar synkroniseringen och interagerar med användaren. Dess huvuduppgifter är:
Presentera UI för användaren och hantera input.
Ladda/Spara inloggningsuppgifter
publicvoid Create() {
StringBuilder sb = newStringBuilder();
sb.Append("<Method ID=\"1\" Cmd=\"New\">"); sb.Append("<Field Name=\"ID\">New</Field>");
sb.Append("<Field Name=\"SQLID\">"+m_SQLID+"</Field>"); sb.Append("<Field Name=\"Title\">" + m_Title + "</Field>");
sb.Append("<Field Name=\"EventDate\">" + m_EventDate + "</Field>"); sb.Append("<Field Name=\"EndDate\">" + m_EndDate + "</Field>"); sb.Append("<Field Name=\"Description\">" + m_Description + "</Field>"); sb.Append("<Field Name=\"Location\">" + m_Location + "</Field>");
sb.Append("<Field Name=\"Reminder\">" + ReminderMinutesBeforeStart.ToString() + "</Field>"); sb.Append("</Method>");
XmlDocument xDoc = newXmlDocument(); XmlElement xBatch = xDoc.CreateElement("Batch"); xBatch.InnerXml = sb.ToString();
lService.UpdateListItems(listName, xBatch);
}
publicvoid Delete() {
StringBuilder sb = newStringBuilder();
sb.Append("<Method ID=\"1\" Cmd=\"Delete\">"); sb.Append("<Field Name=\"ID\">");
sb.Append(this.SQLIDtoID()); sb.Append("</Field>"); sb.Append("</Method>");
XmlDocument xDoc = newXmlDocument(); XmlElement xBatch = xDoc.CreateElement("Batch"); xBatch.InnerXml = sb.ToString();
lService.UpdateListItems(listName, xBatch);
Kontrollera inloggningsuppgifter
Ladda upp/ner metadata
Initiera synkroniseringsloopen
3.3.8.1 UI
Under det första mötet med uppdragsgivaren diskuterades i vilket form applikationen skulle tillämpas. Alternativen som granskades var att
programmet skulle köras som ett separat program, en tjänst i Windows eller ett tillägg (Addin) i Outlook. Men efter att utvärderat alternativen ansågs det lämpligast att implementera programmet i form av ett tillägg till Outlook då tanken är att programmet ska uppfattas som en utökning av Outlooks
funktionalitet snarare än ett separat program.
För att underlätta åtkomsten till applikationen placerades en knapp (Sync) i Outlooks menyrad. Se figur 18.
Figur 18: Outlook Meny
Då programmet startas anropas följande funktion som skapar knappen i menyn. Knappen binds till ett event som anropar en funktion för att visa Formuläret som visas i figur 19.
privatevoid CreateButton() {
firstButton = (Office.CommandBarButton)commandBar.Controls.Add(1, missing, missing, missing, missing); firstButton.Style = Office.MsoButtonStyle.msoButtonIconAndCaption;
firstButton.Caption = "Sync"; firstButton.Tag = "Sync";
firstButton.Click += new Office._CommandBarButtonEvents_ClickEventHandler(ButtonClick); }
Figur 19: Formuläret där användaren anger inställningar för synkronisering
I formuläret som visas anger användaren adressen till Sharepointservern, inloggningsuppgifterna och andra inställningar gällande synkroniseringen. Ett önskemål från uppdragsgivaren var att implementera en ”kom ihåg mig”-funktion som sparar inloggningsuppgifterna efter att användaren loggat in. Det ansågs lämpligast att spara användaruppgifterna i registret och det var
uppenbart att uppgifterna behövde krypteras. Ett problem som uppstår vid kryptering och dekryptering av data är att det behövs en krypteringsnyckel vilket urholkar själva syftet med ”kom ihåg mig”-funktionen.
Ovanstående funktion krypterar känsligt data. Som krypteringsnyckel används den inloggade användarens ”Användarprofil”. På så vis försäkras att enbart denna användare sedan kan dekryptera det sparade datat från registret, dessutom behöver användaren inte hålla reda på en krypteringsnyckel.
byte[] encryptedData =
3.3.8.2 Synkronisering
Användaruppgifterna kontrolleras mot Sharepointservern och om dessa stämmer anropas en metod som laddar ner metadatafilerna från
Sharepointservern till C:\. Därefter skapas en ny tråd i vilken
synkroniseringsloopen körs. I nedanstående exempel ser vi hur leverantörerna MySyncProviderOU, och MySyncProviderSP används. UpdateMetadataStoreWithChanges() anropas
för respektive leverantör för att uppdatera metadatabaserna med de senaste ändringarna innan synkroniseringssessionen startar. För att loopen inte ska blockera hela programmet körs den i en egen tråd.
MySyncProviderOU outlookP = newMySyncProviderOU("OutlookP", OUMetadata);
MySyncProviderSP sharepointP = newMySyncProviderSP(lService, listName, "sharepointP", SPMetadata); while (!_shouldStop)
{
outlookP.UpdateMetadataStoreWithChanges(); sharepointP.UpdateMetadataStoreWithChanges(); SyncOrchestrator agent = newSyncOrchestrator(); agent.LocalProvider = outlookP;
agent.RemoteProvider = sharepointP;
agent.Direction = SyncDirectionOrder.DownloadAndUpload; agent.Synchronize();
Thread.Sleep(Sleeptime); }
3.4 Dataflöde
Ett besvärande och hämmande problem för förståelsen för hur MSF samverkar med de egenimplementerade metoderna är att inte kunna följa dataflödet
genom hela programmet. I de flesta egenutvecklade applikationer är det möjligt att med hjälp av Visual Studios Debug-verktyg ”stega sig igenom”
applikationen och följa exekveringen från start till slut men i det här fallet är det inte möjligt att ”debugga” och följa exekveringen i MSF-Runtime. För att överkomma detta hinder har utskrifter placerats i klassernas metoder för att på så vis någorlunda kunna följa exekveringen. Nedanstående figur visar exempel på utskrifter under synkroniseringen.
4 Resultat
Utvecklingsarbetet har resulterat i en stabil och lätthanterlig ”Addin” i Outlook som möjliggör tvåvägs synkronisering mellan Outlooks huvudkalender med en angiven kalender i Sharepoint. All interaktion med programmet sker direkt från Outlook då det ansågs viktigt att applikationen uppfattades som en utökning av Outlooks funktionalitet snarare än ett separat program.
Applikationen är uppbyggd av olika delar som samarbetar för att utföra uppgiften. Huvudidén med det nuvarande programmet är att den ska fungera som en stabil och utbyggbar plattform för att i framtiden kunna lägga till nya komponenter och utöka synkroniseringsalgoritmen till att även inkludera andra delar av Outlook, t.ex. ”Kontakter”.
Under utvecklingen har ett antal verktyg används. För att kunna installera och köra programmet på en dator krävs att de komponenter som används i
applikationen finns tillgängliga på värddatorn. Följande komponenter krävs för att kunna installera och köra programmet:
Windows Installer 3.1
.Net Framework 3.5
2007 Microsoft Office Primary Interop Assemblies
SQL Server Compact 3.5
Visual Studio Tools for the Office 3.0 Runtime
MSF – Services / Runtime
4.1 Installation
För att förenkla installationsprocessen för slutanvändaren används Microsofts
ClickOnce-teknik som smidigt installerar programmet och de komponenter som
krävs. Det slutgiltiga programmet levereras i form av en installationsfil ihop med ett par kataloger som visas i figur 21. ”2007 Microsoft Office Primary Interop Assemblies” och ” MSF – Services/Runtime” är de två filer som levereras tillsamman med installationsprogrammet. De övriga komponenterna laddas ner från nätet vilket gör att installationsfilerna har en sammanlagd storlek på strax under 10 MB.
Figur 21:Installationsfilerna
När användaren startar ”setup.exe” påbörjas installationen,
Installationsprocessen är enkel och intuitiv och användaren klickar sig fram genom installationen som i vilket annat program som helst.
En del av de komponenter som krävs laddas ner automatiskt.
”Windows Installer 3.1” kräver en omstart av dator. Efter omstart fortsätter installationen automatiskt vilket visas i nedanstående bild.
4.2 Användning av tjänsten
När Outlook startar så startas även tilläget automatiskt (figur 23).
Figur 23: Tillägget installerat
Användaren anger adressen till Sharepointservern, användarnamnet och lösenordet. Dessa uppgifter behöver endast anges en gång därefter sparas de i registret om användaren önskar så. Enligt överenskommelse med
uppdragsgivaren synkroniserar Outlook-kalendern med en kalender i Sharepoint vars namn baseras på användarnamnet. I ovanstående exempel kommer applikationen synkronisera mot en kalender i Sharepoint vid namn ”goran”.
Om felaktiga användaruppgifter anges eller det saknas en kalender som heter ”goran” i Sharepoint underrättas användaren.
Användaren anger hur ofta synkroniseringen ska ske, vart 5,10,20 eller 30 minut. Här anges också hur konflikter ska hanteras. Vid en konflikt kan
användaren välja att behålla den ändring som skett i Sharepointkalendern eller Outlookkalender. Ett tredje alternativ är att behålla båda ändringarna.
Efter inloggning och lyckad synkronisering visas tidsskillnaden mellan den lokala datorn och Sharepointservern samt när den senaste synkroniseringen genomfördes i det nedersta vänstra hörnet. I figur 24 visas formuläret efter inloggning.
Figur 24: Lyckad inloggning
Efter att ha loggat in har användaren möjlighet att spara inloggningsuppgifterna i krypterad form i registret (figur 25). De laddas in automatiskt nästa gång programmet startas.
