Månedligt arkiv: September 2007

Sådan foretages fejlfinding af mystiske SharePoint fejl.

Oversigt:

Debugging er vanskeligt, når udvikle brugerdefineret funktionalitet til Windows SharePoint Services 3.0 (WSS) eller Microsoft Office SharePoint Server (MOSS). Den største synder er, at SharePoint normalt overflader meget lidt diagnostiske oplysninger på webbrowseren, når der opstår en fejl. Dette blogindlæg beskriver, hvordan du finde yderligere systemgenererede diagnostiske oplysninger, som ofte kan give ekstra detaljer, at man har brug for at identificere årsagerne. Dette kan så føre til at løse problemet.

Jeg har brugt denne teknik med stor succes for at løse ellers mystisk fejl.

Tilgang:

SharePoint sparer en hel del oplysninger til en diagnosticeringslogfil i en logfil i den 12 hive.

"12-bikuben" er normalt placeret i "C:\Programmere fælles filer FilesMicrosoft SharedWeb Server Extensions12 ". (Jeg er ikke sikker på om det er muligt for den 12 bikuben for at bo hvor som helst ellers, Faktisk).

Ideen er at finde den aktuelle logfil, tvinge fejlen og derefter hurtigt åbne logfilen. Disse logfiler er karakteriseret ved:

  • Rigelige mængder af oplysninger. SharePoint genererer en meget stor mængde af diagnosticeringsoplysninger og skriver det til denne logfil meget hurtigt. Du skal være hurtig med fingrene til at fange det.
  • Mangfoldighed. SharePoint kan ikke skrive til en enkelt logfil, men snarere genererer flere logfiler i rækkefølge.
  • Kopiere og indsætte pænt i MS Excel.

Min foretrukne metode:

  1. Åbn et windows explorer peger på den 12 hivelogs.
  2. Sortere visningen til at vise efter ændringsdato (Seneste første).
  3. Fremhæve den mest aktuelle logfil.
  4. I et webbrowservindue, tvinge fejlen at forekomme.
  5. Hurtigt åbne den aktuelle logfil og kopiere dens indhold til MS Excel.
  6. Springe til slutningen og analysere de relevante poster.

Andre noter:

Som standard, den diagnosticeringslogfil ligger i den 12 hiveLOGS bibliotek.

MS Best practices (Ifølge Mike T. af Microsoft) stat, log-filer skal gemmes på en separat harddisk. Man gør dette via central administration. Systemadministratoren kan have gjort det, i så fald skal du naturligvis finde logfil der i stedet for standarden 12 hive placering).

Denne post omhandler spørgsmål som:

  • SharePoint-arbejdsproces undladt at starte på grund af en intern fejl.
  • (mere tilføjes over tid)
  • Denne løsning har været hjælpsom diagnosticering arbejdsproces fejl (strømsparetilstand. "Arbejdsprocessen kunne ikke starte på grund af en intern fejl").

MOSS: Effektiv Introduktion til en organisation

(denne post cross bogført mellem http://paulgalvin.spaces.live.com/blog/ og http://blogs.conchango.com)

Opslag på dette site er mine egne og repræsenterer ikke nødvendigvis Conchangos holdninger, strategier eller udtalelser.

Oversigt:

Dette indlæg beskriver nogle baggrundsoplysninger om en stor (3,000 brugere) Microsoft Office SharePoint Server (MOSS) udrulningen, og hvad vi gjorde for at få projektet rullende på en sådan måde, at kunden er tilfreds og fast ned en sti der slutter med fuld vedtagelsen af MOSS feature sæt. Som for skrivning af posten, Vi er ca. 50% komplet med første fase af projektet. Som tingene skrider frem, Jeg vil opdatere denne post og/eller skrive nye poster.

I dette specifikke tilfælde, virksomheden havde allerede installeret SharePoint Portal Server 2003. IT gruppen har installeret produktet i en slags "Lad os se, hvis nogen bekymrer sig" mode. Det blev hurtigt vedtaget af mange professionelle brugere og blev ganske populær i virksomheden som helhed. Som du kan forestille dig, Dette var ikke den bedste udrulning strategi (som klienten let indrømmer) og når MOSS ankom på scenen, klienten er besluttet på at "gøre det rigtigt" og hyret os til at hjælpe dem.

Et af de centrale spørgsmål står over for os, da vi begyndte at gennemføre dette projekt blev: Hvordan vi introducere MOSS til denne klient? Givet at klienten allerede havde erfaring med SharePoint, vi spekulerede på — skal vi gøre "differentieret" træning eller skal vi starte fra jorden op? Efter at have arbejdet med vigtige brugere, Vi har besluttet at behandle dette som et grønt felt projekt givet mere mening.

Denne beslutning gav et udgangspunkt, men stadig efterlod os med det store krav at finde ud af en god strategi for rullende MOSS ud til virksomheden. MOSS er sådan en stor dyr … Det omfatter indholdsstyring, dokumentstyring, Søg, sikkerhed, målgrupper, projektledelse, "fabelagtig fyrre" skabeloner, arbejdsproces, Business data connector, osv. Par dette med, at det er en stor organisation, kan virkelig gøre brug af stort set alle større MOSS funktion, og du har makings af et stort projekt med en enterprise reach og mange gode ting sker.

Vi er konfronteret med dette spørgsmål igen og igen … MOSS har en enterprise nå med dets enterprise feature-sæt, endnu har engang noget sofistikeret klienter svært ved at mentalt absorbere disse funktioner, Lad alene indarbejde en mærkbar brøkdel af dem i deres daglige rutine.

Jeg har ikke en magisk løsning på problemet. I stedet henvender jeg bare de første skridt, som vi har taget med klienten til at føre dem ned stien til vellykket langsigtet vedtagelse.

Anvendelsesområde:

Så meget som jeg ønskede holdet til at udforme en projektplan, der indeholdt sådanne milepæle som "PoepleSoft Integration via BDC afsluttet", "Nye Cross-departementets produkt lancering arbejdsproces komplet" og "Direktionen KPI accepteret", Jeg måtte nøjes med noget mindre. Dette er ikke til at sige, at "under" er dårlig. Faktisk, "mindre" at vi besluttede for den indledende udrulningen var miles foran hvor de var før vi begyndte. I vores tilfælde, "mindre" forvandlet til:

  • Enkle dokumenthåndtering bruge dokumentbiblioteker, version kontrol og indhold, typer.
  • Effektiv søgning baseret på indholdstyper og tilpasset advance søgning (via administrerede egenskaber, XSLT til at producere smukke resultater, osv).

Ud over de ovennævnte virksomhedsdækkende funktioner (hvilket betyder, at de skulle blive rullet ud til alle afdelinger og brugere), vi tilføjet følgende singleton i anvendelsesområdet mini-projekter:

  • Påvisning i id BDC-integration.
  • Flere trin og flergrenet arbejdsgangsprocessen skabt via SPD.
  • Komplekse InfoPath-formular.
  • Surfacing Nøgletallene for nogle business proces (sandsynligvis HR talent erhvervelse i vores tilfælde, selv om der kan ændre).

Mulighederne her er ikke 100% præcis men repræsentant for vores tilgang og tilstrækkelige for mit formål her, som er at forklare, hvad jeg anser for at være en "effektiv" indførelsen af mos, som indstiller klienten fast den gyldne vej til fuld MOSS vedtagelse.

Jeg vil ikke skrive meget mere om singleton i denne post. Jeg ønsker at påpege, at disse er en del af vores overordnede strategi. Ideen er at gennemføre core dokument management og Søg funktioner til alle brugere endnu giver yderst funktionelt, høj synlige og meget repræsentative eksempler på andre MOSS kernefunktioner, som er simpelthen ud over de fleste brugere evne til at absorbere på dette tidlige stadium. Dog, de vil være "derude" og man håber at andre afdelinger vil vide af eller lære om dem og ønsker disse funktioner for sig selv, fører til større vedtagelse. Disse singleton succeshistorier også tjene til at give vores salgsteam "ammunition" for med held at vinde det andet, tredje og n-fase projekter.

Hvad gjorde vi introducere og hvorfor?

At have afgjort på dokumenthåndtering og Søg som en baseline virksomhedsdækkende krav, Vi havde brug at starte indsamling af oplysninger. Som et praktisk spørgsmål, det drejede sig om forståelse af deres dokumenter og, i sidste ende knyttet til forståelse indholdstyper.

Jeg har fundet det vanskeligt at forklare indholdstyper uden visuelle hjælpere. Mere tekniske folk kan gå væk fra en diskussion om indholdstyper, når CTS er beskrevet i databaseterminologi kaldes. "En CT er svarende til en databasetabel, Det har kolonner og kolonner defineres i form af datatyper, men CT datatyper omfatter mere end simple heltal/dato, men også "choice" og "opslag" og lignende." Vi kan tale om "strækker sig" indholdstyper, ligesom man kan arve funktionalitet fra en basisklasse i objektorienteret sprog. Men det er naturligvis ikke nyttigt for transport department admin person, der har ingen teknisk baggrund. Dvs., næsten alle, der betyder noget i en Mos udrulningen.

Ved hjælp af et hvidt bord er usikker. Jeg har præsenteret tanken om en indholdstype og trukket strålende (eller så de synes) billeder af indholdstyper og hvad de gør for dig med hensyn til søgning og hvordan de kan udvides, osv. I sidste ende, det føles som om nogle pærer har slået, men den resulterende skrivetavle billede er en rod.

Dette førte os til vores nuværende og så langt mest effektive landingspladsen: en Mos sandkasse websted er konfigureret til at vise disse funktioner.

Ved hjælp af sandbox-webstedet, Vi demonstrere:

  • Indholdstyper:
    • At skabe en CT med flere datatyper (tekst, dato, valg, Boolesk værdi, opslag, osv).
    • Udvide en CT ved at oprette en ny CT baseret på en overordnet.
    • Søger efter dokumenter ved hjælp af CT metadata.
  • Dokumentbiblioteker:
    • Knytte en enkelt CT med et bibliotek.
    • Hvad sker der når vi overfører et dokument til biblioteket?
    • Knytte flere CT med en doc bibliotek.
    • Hvad sker der når vi overfører et dokument til biblioteket?
    • Filtrering og sortering via kolonneoverskrifter i en doc lib.
    • Dokument bibliotek visninger:
      • Sortering
      • Gruppering
      • "Hurtig løsning" (visning af data)
      • "Ukodet data" (at hjælpe med migrationen til mos fra andre indholdskilder; mere om dette nedenfor).

Sandbox-webstedet:

Vi designet vores sandkasse site at være en fast bestanddel i udviklingsmiljøet bruges til træningsformål lang, når vi er færdig med projektet og inkluderet adskillige artefakter som beskrevet:

Indholdstyper:

Vi defineret følgende indholdstyperne: Faktura, Indkøbsordre, Tjenester faktura.

Vi valgte faktura og Køb orden, fordi de er mere eller mindre universelt under
stod enheder. Alle i virksomheden forstår at en faktura er en anmodning om betaling for en kunde for en beløb udstedt på en bestemt dato der skal betales ifølge nogle betalingsbetingelser. Dette fører til en naturlig definition af en CT, som vi kaldte "uddannelse faktura" (at skelne den fra andre former for faktura). Indkøbsordren er ligeledes let defineret. Vi skabte også en "uddannelse tjenester faktura" ved at oprette en ny CT baseret på "uddannelse fakturaen" CT og tilføjede bare én kolonne, "tjenesteydelser".

Med ovenstående, Vi kan nu påvise nogle nøglefunktioner i CTS uden at blive kørt ned forsøger at forklare et abstrakt begreb først; alle forstår allerede, hvad vi forstår ved "faktura" og "indkøbsordre" og er i stedet at fokusere på mekanik af CT selv.

Brugerdefinerede lister:

CT med kolonner af typen "opslag" Peg på en brugerdefineret liste eller et dokumentbibliotek. Vi bruger dette flittigt og for sandkassen, Vi har oprettet en støtte brugerdefinerede liste, der indeholder kunder. Vi tog kunder, fordi det er en let koncept til at forstå og let at påvise. Faktura CT har en kolonne, "kunde" der er defineret af typen "opslag" der peger på denne liste.

Vi lavet en tilsvarende brugerdefinerede liste for at administrere "leverandører" for indkøbsordren"" CT.

Dokumentbiblioteker:

Vi lavet to dokumentbiblioteker: "Fakturaer" og "Blandet dokumenter".

Vi konfigureret fakturaer dokumentbibliotek for at styre kun dokumenter af CT type "Faktura".

Vi konfigureret "blandet-dokumenter" biblioteket til at administrere alle tre CT.

Oprette flere visninger, der viser sortering, filtrering, på data-ark og gruppering.

Søg:

Vi defineret to nye administrerede egenskaber og knyttet dem til fakturanummer og kunde.

Vi lavet en ny tilpasset advance søgning site og forandret sig for at give brugerne mulighed at søge efter "fakturaer" ved hjælp af disse to tilknyttede egenskaber.

Ændre XSLT så faktura og kunde antallet, Når præsenterer, vises i en HTML-tabel i en lys farve. Målet her er at vise, at sådanne formatering er muligt.

At sætte det hele sammen:

Vi arrangere nøglebrugere til at deltage i en demo.

Vi følger denne simple script:

  1. Beskrive formålet af en CT, ved hjælp af fakturaer og indkøbsordrer som eksempler.
  2. Vis faktura CT definitionen samtidig samtidig sikrer dem, at de ikke behøver at bruge disse skærme, selv, bare afhente begreberne.
  3. Gå til dokumentbiblioteket fakturaer.
  4. Uploade et dokument.
  5. Påvise, at den kunde drop-down virkelig stammer fra en brugerdefineret liste.
  6. Tilføje en ny kunde til kundeliste og derefter opdatere den nyligt uploadet faktura metadata med de nyoprettede kunde.
  7. Skift til "blandet-dokumenter" bibliotek og uploade et dokument. Forklare hvordan systemet beder om for en dokumenttype.
  8. Gå tilbage til fakturaer dokumentbibliotek og viser hvordan at klikke på et kolonnenavn ændrer sorteringsrækkefølgen.
  9. Vise kolonnen-niveau filtrering.
  10. Vise forskellige visninger, der viser multi-level sortering, filtrering og gruppering.
  11. Vis ark datavisning.
  12. Forklare formålet med et "ukodede dokumenter" Se.
  13. Skifte til den tilpassede avanceret søgning.
  14. Nu, de nyligt uploadet dokument skal have gennemgået og indekseret, så udføre en søgning, der viser evne til at lokalisere denne faktura via egenskaben tilknyttede.
  15. Vi demonstrere forskellen mellem søgning via tilknyttede egenskaber vs. bare en tekstsøgning.

På dette punkt, Vi er mere eller mindre færdig med demo. Det synes at tage om 30 til 45 minutter, afhængigt af hvor mange spørgsmål spørger.

Derefter sender vi dem tilbage til deres skriveborde med "hjemmearbejde". Denne består af en simpel excel-regneark hvor vi bede dem om at definere for os hvad de tror, de har brug for med hensyn til CT'S, både på et højt niveau (kun navn og forretningsadresse formål) kolonner og datatype ville de gemme i kolonnen. Vi bede ikke dem om at definere kolonnedatatyper i MOSS vilkår, men forretningsbetingelser.

I Resumé:

Vi har oprettet en sandkasse miljø, som vi kan bruge til at vise nogle kernefunktioner til MOSS Hvis appellen er hele virksomheden.

Vi har modelleret let forståelig og fælles forretningsenheder, således at brugerne kan fokusere på MOSS og ikke forsumpe på enhederne / eksempler, selv.

Business-brugere gå væk fra afhandlinger sessioner med "hjemmearbejde" i form af excel-dokumenter, som de nu er kompetente til at udfylde og bruge til at designe deres egen første-cut indholdstyper.

Endelig, Når vi udfører demoer over tid, klientens teammedlemmer, selv blive bedre i stand til at videreføre, demo's selv og generelt gratis op resten af os op til at arbejde på mere komplekse problemstillinger, som global taksonomi, komplekse arbejdsprocesser, BDC- og lignende.

Lære adræt // Scrum

Jeg spurgte for nogle råd i dag på gode ressourcer for at komme i gang med at lære Agile og Scrum. Her er et sammendrag af svaret. Jeg har tillid til kilder, men jeg ved ikke, at dette er omfattende (Jeg er sikker på det ikke er).

Jeg kan have transskriberet nogle af dette forkert.

Flere mennesker svar og adræt projektledelse af Ken Scwaber er den konsekvente "første dyk" henstilling.

Personligheder:

  • Ken Schwaber
  • Mike Cohn

Bøger:

  • Agil projektledelse med Scrum af Ken Schwaber.
  • Lean Software-udvikling: En adræt Toolkit for Software udvikling projektledere af Mary og Tom Poppendieck.
  • "noget af Mike Cohn"
  • Agile Retrospectives af Ken Schwaber, Diana Larsen, Esther Derby.

Links: