Översikt:

Felsökning är svårt när de utvecklar anpassade funktioner för Windows SharePoint Services 3.0 (WSS) eller Microsoft Office SharePoint Server (MOSS). Den största boven är att SharePoint normalt ytbehandlar mycket lite diagnostisk information på webbläsaren när ett fel uppstår. Denna bloggpost beskriver hur att hitta ytterligare systemgenererade diagnostisk information som ofta kan ge det extra bit av detalj som man behöver för att identifiera grundorsaker. Detta kan sedan leda till att lösa problemet.

Jag har använt denna teknik med stor framgång för att lösa annars mystiska fel.

Tillvägagångssätt:

SharePoint sparar en hel del information till en diagnostiklogg i en loggfil i den 12 kupan.

"12-kupan" ligger oftast på "C:\Programmera delade filerMicrosoft SharedWeb Server Extensions12 ". (Jag är inte säker på om det är möjligt för den 12 kupan för att bo var som helst annars, I själva verket).

Tanken är att leta upp den aktuella loggfilen, tvinga felet och sedan snabbt öppna loggfilen. Dessa loggfiler kännetecknas av:

• Rikligt med information. SharePoint genererar en mycket stor mängd diagnostisk information och skriver det till att loggfilen mycket snabbt. Du måste vara snabb med fingrarna att fånga den.
• Multiplicity. SharePoint skriva inte till samma fil men ganska genererar flera loggfiler i sekvens.
• Kopiera och klistra in fint i MS Excel.

Min favorit metod:

1. Öppna upp en Utforskaren som pekar på den 12 hivelogs.
2. Sortera vyn Visa ändrade datum (senaste första).
3. Markera den mest aktuella loggfilen.
4. I ett webbläsarfönster, tvinga felet inträffar.
5. Snabbt öppna den aktuella loggfilen och kopiera innehållet till MS Excel.
6. Hoppa till slutet och analysera uppgifterna.

Andra anteckningar:

Som standard, diagnostiklogg ligger i den 12 hiveLOGS katalog.

MS Best practices (enligt Mike T. av Microsoft) staten som loggfilerna ska sparas till en separat hårddisk. Man gör detta via central admin. Systemadministratören kan ha gjort detta, i vilket fall du skulle naturligtvis behöva hitta loggfilen där istället för standard 12 kupan läge).

Den här intrade tar upp frågor som:

• SharePoint-arbetsflöde som kunde inte startas på grund av ett internt fel.
• (mer att läggas över tid)
• Detta inlägg har varit hjälpsamma diagnostisera arbetsflödesfel (t.ex. "Arbetsflödet misslyckades att starta på grund av ett internt fel").

(den här intrade postat cross mellan http://paulgalvin.spaces.live.com/blog/ och http://blogs.conchango.com)

Inlägg på denna webbplats är mina egna och nödvändigtvis representerar inte Conchangos positioner, strategier eller åsikter.

Översikt:

Detta inlägg beskriver lite bakgrundsinformation på en stor (3,000 användare) Microsoft Office SharePoint Server (MOSS) utbyggnaden och vad vi gjorde för att få projektet rullande så att kunden är nöjd och bestämt ner en väg som slutar med full antagandet av funktionsuppsättningen MOSS. När skriften i posten, Vi är cirka 50% komplett med den första fasen av projektet. Som saker framsteg, Jag kommer uppdatera detta inlägg och/eller skriva nya poster.

I detta specifika fall, företaget hade redan installerat SharePoint Portal Server 2003. IT-gruppen har installerat produkten i en slags "Låt oss se om någon bryr sig" Fashion. Det antogs snabbt av många affärsanvändare och blev ganska populärt i företaget i stort. Som ni kan föreställa er, Detta var inte den bästa strategin för utbyggnaden (som klienten lätt erkänner) och när MOSS kom till platsen, klienten är beslutna att "göra det rätt" och anlitade oss att hjälpa dem..

En av de centrala frågor som vi står inför när vi började genomförandet av detta projekt var: Hur vi införa MOSS till den här klienten? Med tanke på att klienten hade redan erfarenhet av SharePoint, Vi undrade — behöver vi göra "differential" utbildning eller gör vi startar från grunden? Efter att ha arbetat med viktiga användare, vi konstaterat att behandla detta som ett grönt fält projekt mera logiskt.

Det beslutet gav en utgångspunkt men fortfarande lämnade oss med stor kravet att räkna ut en bra strategi för rullande MOSS till företaget. MOSS är en stor djur … den innehåller innehållshantering, dokumenthantering, Sök, säkerhet, målgruppsanpassning, projektledning, "fantastiska fyrtio" mallar, arbetsflöde, Business dataanslutning, m.m.. Par detta med det faktum att det är en stor organisation som kan verkligen utnyttja praktiskt taget varje större MOSS funktionen och du har förutsättningar att bli ett stort projekt med en enterprise räckvidd och många bra saker händer.

Vi är inför denna fråga gång på gång … MOSS har företaget når med dess företag huvudnummer-set, men har även något sofistikerade klienter svårt att mentalt absorbera dessa funktioner, Låt ensam införliva en märkbar del av dem i deras dagliga rutin.

Jag har inte en magisk lösning på problemet. I stället vänder jag bara de första steg som vi har tagit med klienten för att leda dem på väg till framgångsrika långsiktiga antagandet.

Omfattning:

Så mycket som jag ville laget att farkosten en projektplan som ingår sådana milstolpar som "PoepleSoft-Integration via BDC slutförd", "Nya Cross-avdelnings produkt lanseringen arbetsflödet komplett" och "Verkställande ledningen KPI accepteras", Jag var tvungen att nöja sig med något mindre. Detta är inte att säga att "mindre" är dåligt. I själva verket, "mindre" att vi bestämde oss för den första utbyggnaden var miles före där de var innan vi började. I vårt fall, "mindre" förvandlas till:

• Enkel Dokumenthantering använda dokumentbibliotek, version control och innehåll typer.
• Effektiv sökning baserat på innehållstyper och anpassade avancerad sökning (via hanterade egenskaper, XSLT för att skapa vackra resultat, m.m.).

Utöver ovanstående företagsomfattande egenskaper (vilket betyder att de var att rullas ut för alla avdelningar och användare), Vi lade till följande singleton i-scope mini-projekt:

• Bevis av begreppen BDC-integration.
• Flera steg och flera gren arbetsflödesprocess skapas via SPD.
• Komplexa InfoPath-formulär.
• Beläggningsarbeten KPI för vissa affärsprocess (förmodligen HR talang förvärv i vårt fall, dock får ändra).

Det här är inte 100% korrekt men representant i vårt synsätt och tillräckligt för mitt syfte här, vilket är att förklara vad jag anser vara en "effektiv" införandet av MOSS som kommer att ställa kunden bestämt ner den gyllene vägen till full MOSS antagande.

Jag kommer inte skriva mycket mer om singleton i detta inlägg. Jag vill påpeka att dessa är del av vår övergripande strategi. Tanken är att genomföra core dokument hantering och sökning funktioner för alla användare och ändå ge mycket funktionella, hög synligt och mycket representativa exempel på andra core MOSS funktioner som är helt enkelt bortom de flesta användare förmåga att absorbera på detta tidiga stadium. Men, de kommer att vara "där ute" och hoppas att andra affärsenheter kommer vet eller lära sig om dem och vill ha de funktionerna för sig själva, leder till större antagandet. Dessa singleton framgångssagor också tjäna till att ge våra säljare "ammunition" för att lyckas vinna andra, tredje och n-fas-projekt.

Vad gjorde vi inför och varför?

Att ha bosatte sig på dokumenthantering och Sök som en baslinje företagsomfattande krav, Vi behövde för att börja samla Detaljer. Som en praktisk fråga, Detta kretsade kring att förstå sina handlingar och slutligen mappat till förståelse innehållstyper.

Jag har hittat det är svårt att förklara innehållstyper utan visuella medhjälpare. Mer teknisk folk kan gå ifrån en diskussion om innehållstyper när CTS beskrivs i databasen termer. "A CT liknar en databastabell, Det har kolumner och kolumner definieras datatyper, men CT datatyper är mer än enkla heltal/datum, men också "val" och "lookup" och liknande." Vi kan tala om "sträcker sig" innehållstyper, ungefär som man kan ärva funktionalitet från en basklass i objektorienterade språk. Men detta är naturligtvis inte bra för den transport avdelning admin som har ingen teknisk bakgrund. Dvs., nästan alla som är viktigt i en MOSS utbyggnad.

Med hjälp av en whiteboard är diffust. Jag har lagt fram idén om en innehållstyp och ritade briljant (eller så de verkar) bilder av innehållstyper och vad de gör för dig i Sök och hur de kan utökas, m.m.. I slutet, Det känns som några glödlampor har aktiverat, men den resulterande vit tavla bilden är en enda röra.

Detta ledde oss till våra nuvarande och så långt mest effektiva landningsplats: en MOSS sandlåda webbplats konfigurerad för att visa dessa funktioner.

Webbplatsen för sandlåda, Vi visar:

• Innehållstyper:
  • Skapa en CT med flera datatyper (texten, datum, Val, Booleskt värde, sökning, m.m.).
  • Utvidga en CT genom att skapa en ny CT baserat på en förälder.
  • Söka efter dokument med hjälp av CT metadata.
• Dokumentbibliotek:
  • Associera en enda CT med ett bibliotek.
  • Vad händer när vi överför ett dokument till biblioteket?
  • Associera flera CT med doc bibliotek.
  • Vad händer när vi överför ett dokument till biblioteket?
  • Filtrering och sortering via kolumnrubrikerna i en doc-lib.
  • Biblioteket dokumentvyer:
    • Sortering
    • Gruppering
    • "Snabba entry" (data listvy)
    • "Otaggade data" (att hjälpa till med migration till MOSS från andra innehållskällor; mer om detta nedan).

Webbplatsen sandlåda:

Vi utformade vår sandlåda webbplats vara ett permanent inslag i utvecklingsmiljön som ska användas för utbildningsändamål lång efter att vi avslutar projektet och ingår flera artefakter som beskrivs:

Innehållstyper:

Vi har definierat följande innehållstyper: Faktura, Inköpsorder, Tjänster faktura.

Vi valde faktura och inköpsorder eftersom de är mer eller mindre allmänt under
stod enheter. Alla i branschen förstår att en faktura är ett krav på betalning till en kunden för en belopp utfärdat på ett visst datum betalas enligt vissa betalningsvillkor. Detta leder till en naturlig definition av en CT som vi kallade "utbildning faktura" (att skilja den från någon annan typ av faktura). Inköpsordern definieras på motsvarande sätt enkelt. Vi har också skapat en "utbildning tjänster faktura" genom att skapa en ny CT baserat på "utbildning fakturan" CT och La bara en kolumn, "tjänster".

Med ovanstående, Vi kan nu visa några viktiga funktioner i CT utan att få gräva ner försöker förklara ett abstrakt begrepp först; alla förstår redan vad vi menar med "faktura" och "inköpsorder" och istället kan fokusera på mekaniken i CT sig.

Anpassade listor:

CT med kolumner av typen "lookup" Peka på en anpassad lista eller ett dokumentbibliotek. Vi använder detta utförligt och för sandlådan, Vi har skapat en stödja anpassade lista med kunder. Vi plockade kunder eftersom det är ett enkelt begrepp att förstå och lätt att Visa. Faktura-CT har en kolumn, "kunden" som definieras av typen "lookup" som pekar på denna lista.

Vi skapade en liknande anpassad lista för att hantera "leverantörer" för inköpsordern"" CT.

Dokumentbibliotek:

Vi skapade två dokumentbibliotek: "Fakturor" och "Blandat dokument".

Vi konfigurerat fakturor dokumentbiblioteket om du vill hantera endast dokument av CT typ "Faktura".

Vi konfigurerat "blandade dokument" bibliotek för att hantera alla tre CT.

Skapa flera vyer som visar sortering, filtrering, datablad och gruppering.

Sök:

Vi definierade två nya hanterade egenskaper och mappade dem fakturanummer och kund.

Vi skapade en ny anpassad advance webbplats och modifierade den för att möjliggöra förbrukaren till söka för "fakturor" använda de två mappade egenskaperna.

Ändra XSLT så att faktura- och antalet, När närvarande, visas i en HTML-tabell i en ljus färg. Målet är att visa att sådana formatering är möjligt.

Att sätta allt ihop:

Vi arrangerar för viktiga användare att delta i en demo.

Vi följer detta enkla skript:

1. Beskriv innebörden och syftet med en CT, med fakturor och inköpsorder som exempel.
2. Visa faktura CT definitionen medan samtidigt försäkra dem att de inte behöver använda de skärmarna sig, bara plocka upp begreppen.
3. Gå till dokumentbiblioteket med fakturor.
4. Ladda upp ett dokument.
5. Visa att kunden nedrullningsbara verkligen anskaffas från en anpassad lista.
6. Lägga till en ny kund i kundlistan och uppdatera sedan nyligen uppladdade fakturans metadata med nyligen skapade kunden.
7. Växla till "blandade dokument" bibliotek och ladda upp ett dokument. Förklara hur systemet frågar efter en dokumenttyp.
8. Gå tillbaka till fakturor dokumentbibliotek och visa hur du klickar på ett kolumnnamn ändrar sorteringsordning.
9. Visa kolumnnivå filtrering.
10. Visa olika vyer som visar multi-level sortering, filtrering och gruppering.
11. Visa datavyn blad.
12. Förklara syftet med ett "otaggade dokument" Visa.
13. Växla till den anpassade avancerad sökningen.
14. Nu, Det nyligen uppladdade dokumentet bör ha krypande och katalogiserat, så gör en sökning som visar förmåga att lokalisera denna faktura via egenskapen mappade.
15. Vi visar skillnaden mellan söka via mappade egenskaper vs. bara en textsökning.

Vid denna punkt, Vi är mer eller mindre klar med demo. Det verkar ta om 30 till 45 minuter, beroende på hur många frågor som be.

Vi sedan skicka dem tillbaka till deras skrivbord med "läxor". Denna består av en enkel excel-kalkylblad där vi ber dem att definiera för oss vad de tycker de behöver i form av CT'S, både på hög nivå (bara namn och syfte) kolumner och typ av data skulle lagras i kolumnen. Vi ber inte dem att definiera data kolumntyper i MOSS termer, men affärsmässiga villkor.

I Sammanfattning:

Vi har skapat en sandlåda miljö som vi kan använda för att visa några core MOSS funktioner vars överklagande är företagsomfattande.

Vi har modelleras lätt förstås och gemensamma affärsentiteter så att användare kan fokusera på MOSS och inte gräva ner på enheterna som / exempel på sig.

Företagsanvändare promenad från avhandlingar sessioner med "läxor" i form av excel-dokument som de nu är behöriga att fylla och använda för att utforma sina egna första-cut innehållstyper.

Slutligen, vi utföra demonstrationer över tid, klientens gruppmedlemmarna själva bli mer kunna föra, demo själva och allmänhet frigöra upp resten av oss för att arbeta med mer komplexa frågor, som global taxonomy, komplexa arbetsflöden, BDC- och liknande.