Vi bruger tilsammen megen tid på at tænke om SharePoint-løsninger — hvordan du opretter dem, som værktøj til at bruge, Hvad sker der, når de undlader at installere, timerjob, Scopes, osv. Vi bruger så meget tid på at tænke om up-front bits, at det er nemt at glemme, at vi skal trække dem samt. Tilbagetrækningskraften løsninger er sandsynligvis mere besværligt, fra et konceptuelt design perspektiv, end installation af dem. Installation er dybest set en kogebog affære. Typisk, installere en funktion, måske har en funktion modtager indlæse nogle data i en liste, slags ting. Dog, tilbagetrækningskraften er potentielt mere komplekse.

En given løsning kan skabe artefakter som disse:

• Indholdstype
• Listen Definition
• Webstedsdefinitionen
• Data i en liste
• Selv modtagere
• InfoPath-formularer

Listen fortsætter.

Det er naturligvis vigtigt at designe en løsning instantierer der disse artefakter korrekt, Det er lige så vigtigt at overveje opdateringen og slette tilfælde. Hvis din løsning opretter en ny liste og udfylder listen med data, Hvad sker der, når løsningen er trukket tilbage? I nogle tilfælde, listen bør udgå. I andre tilfælde, Det bør være overladt intakt for historiske formål. Virksomhedens behov vil guide dig til den rigtige beslutning.

At hjælpe med dette, oprette en matrix, der viser hver artefakt din løsning udruller til SharePoint. Tre listekolonner pr. genstand, en for at skabe, Update og delete. For hvert enkelt tilfælde, bestemme det korrekte resultat for den pågældende operation.

Denne form for analyse er naturligvis bedst gøres før løsningen implementeres nogensinde til en SharePoint-farm. Dog, som rygning, Det er aldrig for sent for at begynde at gøre tingene rigtigt. Oprette denne matrix og udvikle en plan for at løse de manglende opdatering/sletning scenarier. Det kan være et svært problem at løse, men i det mindste du har sætte en kasse rundt om problemet.

</slutningen>

Abonner på min blog.

Følg mig på kvidre på http://www.twitter.com/pagalvin