Månedlige Arkiver: September 2007

Hvordan du feilsøker mystiske SharePoint-feil.

Oversikt:

Feilsøking er vanskelig når du utvikler egendefinerte funksjonaliteten for Windows SharePoint Services 3.0 (WSS) eller Microsoft Office SharePoint Server (MOSS). Den viktigste årsaken er at SharePoint normalt overflater lite diagnostisk informasjon på web-leseren når en feil oppstår. Dette blogginnlegget beskriver hvordan du finner flere systemgenererte diagnoseinformasjon som kan ofte gi det ekstra bit av detaljer som man trenger for å identifisere årsakene. Dette kan deretter føre til løse problemet.

Jeg har brukt denne teknikken med stor suksess for å løse ellers mystisk feil.

Tilnærming:

SharePoint sparer mye informasjon til en diagnostisk logg i en loggfil i den 12 struktur.

"12 strukturen" ligger vanligvis på "C:\Programmet FilesCommon FilesMicrosoft SharedWeb Server Extensions12 ". (Jeg er ikke sikker på om det er mulig for den 12 struktur for å leve alt annet, faktisk).

Ideen er å finne gjeldende loggfil, tvinge feilen og raskt åpne loggfilen. Disse loggfilene er preget av:

  • Store mengder informasjon. SharePoint genererer en stor mengde diagnoseinformasjon og skriver det til at loggfilen svært raskt. Du må være rask til å fange den.
  • Mangfold. SharePoint skriver ikke til en enkelt loggfil men heller genererer flere loggfiler i rekkefølge.
  • Kopiere og lime pent inn i MS Excel.

Min favoritt metode:

  1. Åpne et windows Utforsker peker til den 12 hivelogs.
  2. Sortere visningen Vis etter endringsdato (siste første).
  3. Markere mest gjeldende loggfil.
  4. I et webleservindu, tvinge feilen oppstår.
  5. Raskt åpne gjeldende loggfil og kopiere innholdet til Excel.
  6. Hoppe til slutten og analysere de aktuelle postene.

Andre notater:

Som standard, diagnoseloggen som er plassert i den 12 hiveLOGS mappe.

MS beste praksis (Ifølge Mike T. Microsoft) staten der loggfilene skal lagres til en egen harddisk. Man gjør dette via Sentraladministrasjon. Systemansvarlig kan ha gjort dette, i så fall ville du åpenbart trenger å finne loggfilen det for standard 12 strukturen plassering).

Denne oppføringen løser problemer som:

  • SharePoint-arbeidsflyt kan ikke starte på grunn av en intern feil.
  • (flere skal legges over tid)
  • Denne oppføringen har vært nyttig diagnostisere arbeidsflytfeil (f.eks. "Arbeidsflyten kan ikke starte på grunn av en intern feil").

MOSS: Effektiv introduksjon til en organisasjon

(Denne oppføringen kors postet mellom http://paulgalvin.spaces.live.com/blog/ og http://blogs.conchango.com)

The innlegg på dette nettstedet er mine egne og nødvendigvis representerer ikke Conchangos posisjoner, strategier eller meninger.

Oversikt:

Denne oppføringen beskriver noen bakgrunnsinformasjon om en stor (3,000 brukere) Microsoft Office SharePoint Server (MOSS) utrulling og hva vi gjorde for å få prosjektet slik at kunden er fornøyd og godt ned en bane som slutter med full adopsjon av MOSS angi. Som skrevet posten, Vi er ca 50% komplett med første fase av prosjektet. Som ting fremgang, Jeg vil oppdatere denne oppføringen og/eller skrive nye oppføringer.

I dette konkrete tilfellet, selskapet hadde installert SharePoint Portal Server 2003. Gruppen IT installert produktet i en slags "La oss se hvis noen bryr seg" mote. Det ble raskt adoptert av mange forretningsbrukere og ble ganske populær i bedriften generelt. Som du kan forestille, Dette var ikke den beste strategien for distribusjon (som klienten innrømmer lett) og når MOSS kom på scenen, klienten besluttet å "gjøre det riktig" og engasjerte oss for å hjelpe dem.

En av de sentrale spørsmålene overfor når vi begynte å implementere dette prosjektet var: Hvordan introduserer vi MOSS denne klienten? Gitt at klienten allerede hatt erfaring med SharePoint, vi lurte på — trenger vi å gjøre "differensial" opplæring eller gjør vi starte fra grunnen? Etter å ha jobbet med viktige brukere, Vi bestemte at behandler dette som en grønn feltet prosjekt mer fornuftig.

Denne beslutningen ga utgangspunkt, men fortsatt forlatt oss med store behovet for å finne ut en god strategi for introduserer MOSS i virksomheten. MOSS er slik en stor dyr … Det inkluderer innholdsbehandling, Dokumentbehandling, Søk, sikkerhet, målgruppeangivelse, prosjektledelse, "fantastisk førti" maler, arbeidsflyt, Business datatilkobling, osv.. Par dette med at det er en stor organisasjon som kan virkelig gjøre bruk av nesten alle store MOSS funksjonen og du har makings av et stort prosjekt med en enterprise rekkevidde og mange gode ting skjer.

Vi er konfrontert med dette problemet igjen og igjen … MOSS har en bedrift nå med sin enterprise funksjonssett, ennå har enda litt avanserte klienter en hard tid mentalt absorbere disse funksjonene, La alene innlemme en merkbar brøkdel av dem i deres daglige rutine.

Jeg har ikke en magisk løsning på problemet. Jeg i stedet ta bare den aller første skrittene vi har tatt med klienten å føre dem ned stien til vellykket langsiktig adopsjon.

Omfang:

Som jeg ønsket de å lage en prosjektplan som inkludert slike milepæler som "PoepleSoft integrasjon via BDC fullført", «Ny Cross-Departmental produkt lanseringen arbeidsflyt komplett" og "Ledelsen KPIS akseptert", Jeg måtte betale for noe mindre. Dette er ikke å si at "mindre" er dårlig. faktisk, "mindre" at bestemte vi oss for den første utbyggingen var miles foran der de var før vi startet. I vårt tilfelle, "mindre" omgjort til:

  • Enkel dokumenthåndtering bruke dokumentbiblioteker, versjon kontroll og innhold typer.
  • Effektive søk basert på innholdstyper og tilpasset forhånd søke (via forvaltede egenskaper, XSLT til å produsere vakre resultater, osv.).

I tillegg til ovennevnte bedriftsomfattende funksjoner (betyr at de skulle rulles til alle avdelinger og brukere), vi lagt følgende singleton gjennomgåtte mini-prosjekter:

  • Konseptbeviskode BDC integrering.
  • Flere trinn og multi-grenen arbeidsflytprosessen opprettet via SPD.
  • Komplekse InfoPath-skjema.
  • Overflaten KPI'S for noen forretningsprosess (sannsynligvis HR talent anskaffelse i vårt tilfelle, men som kan endres).

Her er ikke 100% nøyaktig men representant vår tilnærming og tilstrekkelig for min hensikt her, som er å forklare hva jeg anser for å være en "effektiv" innføring av MOSS som vil sette klienten fast ned golden path til full MOSS adopsjon.

Jeg vil ikke skrive mye mer om singleton i denne oppføringen. Jeg ønsker å påpeke at disse er en del av vår overordnede strategi. Ideen er å implementere dokumentet ledelse og søk kjernefunksjonene for alle brukere, men gir svært funksjonell, høy synlig og svært representative eksempler på andre kjernen MOSS funksjoner som bare utover muligheten for de fleste brukere å absorbere på dette tidlige Stadium. Men, de vil bli "der ute" og en håper at andre forretningsenheter vil vite eller lære om dem og ønsker disse funksjonene for seg selv, fører til større adopsjon. Disse singleton suksesshistorier også tjene til å gi salgsteamet "ammunisjon" for å kunne vinne andre, tredje og n-fase.

Hva gjorde vi presentere og hvorfor?

Har avgjort på dokumentbehandling og søk som planlagt bedriftsomfattende krav, Vi måtte begynne å samle inn informasjon. Som en praktisk materie, Dette dreide seg om sine dokumenter og som til slutt tilordnet forstå innholdstyper.

Jeg har funnet det er vanskelig å forklare innholdstyper uten visuelle hjelpere. Mer teknisk folk kan gå fra en diskusjon om innholdstyper når CTS er beskrevet i databasen vilkår. "En CT er lik en databasetabell, den har kolonner og kolonner defineres datatyper, men CT datatyper inkluderer mer enn enkel heltall/dato, men også "valg" og "oppslag" og lignende." Vi kan snakke om "utvide" innholdstyper, mye som en kan arve funksjonalitet fra en grunnklasse objektorientert språk. Men dette er åpenbart ikke nyttig for transport avdeling admin personen som har ingen teknisk bakgrunn. Dvs., nesten alle som teller i en MOSS utrulling.

Bruke en hvit bord er iffy. Jeg har presentert ideen om en innholdstype og trukket strålende (eller så de synes) bilder av innholdstyper og hva de gjør for deg i Søk og hvordan de kan utvides, osv.. Til slutt, det føles som noen lyspærer har aktivert, men det hvite bord bildet er et rot.

Dette førte oss til våre nåværende og det mest effektive landingsplass: en MOSS sandkasse området konfigurert til å vise disse funksjonene.

Bruke sandkasse nettstedet, Vi viser:

  • Innholdstyper:
    • Opprette en CT med flere datatyper (tekst, dato, valg, Boolsk, oppslag, osv.).
    • Utvide en CT ved å opprette en ny CT basert på en forelder.
    • Søker etter dokumenter ved hjelp av CT metadata.
  • Dokumentbiblioteker:
    • Knytte en enkelt CT til et bibliotek.
    • Hva skjer når vi laster opp et dokument til biblioteket?
    • Knytte flere CT med en doc-bibliotek.
    • Hva skjer når vi laster opp et dokument til biblioteket?
    • Filtrere og sortere via kolonneoverskriftene i et doc lib.
    • Dokumentbiblioteksvisning:
      • Sortering
      • Gruppering
      • "Hastig komme inn" (datavisningen ark)
      • "Umerkede data" (å hjelpe til med migrasjon til MOSS fra andre innholdskilder; mer om dette nedenfor).

Webområdet Sandbox:

Vi laget vår sandkasse siden å bli en fast funksjon i utviklingsmiljøet som skal brukes for opplæringsformål lenge etter at vi prosjektet og inkludert flere gjenstander som beskrevet:

Innholdstyper:

Vi definert følgende innholdstyper: Faktura, Bestilling, Tjenestefaktura.

Vi valgte faktura og Kjøp fordi de er mer eller mindre universelt under
stod enheter. Alle i bransjen forstår at en faktura er et behov for betaling til en kunden for en beløp utstedt på en bestemt dato betales i noen betalingsbetingelser. Dette fører til en naturlig definisjon av en CT som vi kalte "trening faktura" (å skille den fra andre typer faktura). Bestillingen er likeledes lett definert. Vi har også laget en "trening Tjenestefaktura" ved å opprette en ny CT basert på "trening fakturaen" CT og lagt til bare én kolonne, "tjenesteytelser".

Med de ovennevnte, Vi kan nå vise noen viktige funksjoner i CTS uten å overbelastes ned prøver å forklare et abstrakt begrep først; alle forstår allerede hva vi mener med "faktura" og "bestillingen" og er i stedet å fokusere på mekanikken i CT selv.

Egendefinerte lister:

CT med kolonner av typen "oppslag" Velg en egendefinert liste eller dokumentbibliotek. Vi bruker dette mye og for sandkasse, Vi har opprettet en støtte egendefinert liste som inneholder kunder. Vi plukket kunder fordi det er et enkelt konsept å forstå og enkle å demonstrere. Faktura CT har en kolonne, "kunde" som er definert av typen "oppslag" som peker på denne listen.

Vi laget en lignende egendefinert liste for å behandle "leverandører" for bestilling"" CT.

Dokumentbiblioteker:

Vi laget to dokumentbiblioteker: "Fakturaer" og "Blandede dokumenter".

Vi konfigurert fakturaer dokumentbiblioteket for å behandle bare dokumenter av CT type "Faktura".

Vi konfigurert "blandet dokumenter" bibliotek for å administrere alle tre CT.

Opprette flere visninger som viser sortering, filtrering, datablad og gruppering.

Søk:

Vi definert to nye forvaltede egenskaper og tilordnet dem fakturanummer og kunde.

Vi laget en ny tilpasset forskudd søkeside og modifisert den å sette i stand brukernes å søke for "fakturaer" bruke de to tilordnede egenskapene.

Endre XSLT-filen slik at fakturaen og kunden antallet, Når presenterer, vises i en HTML-tabell i en lys farge. Målet her er å vise at slik formatering er mulig.

Sette alt sammen:

Vi arrangere viktige brukere til å delta i en demo.

Vi følger dette enkelt skript:

  1. Beskrive meningen og hensikten med en CT, bruker fakturaer og bestillinger som eksempler.
  2. Vis fakturaen CT definisjonen mens samtidig sikre dem at de ikke trenger å bruke disse skjermene seg, bare plukke opp konsepter.
  3. Gå til dokumentbiblioteket fakturaer.
  4. Last opp et dokument.
  5. Vise at kunden rullegardinlisten er egentlig Hentet fra en egendefinert liste.
  6. Legge til en ny kunde i kundelisten og deretter oppdatere nylig opplastede fakturaens metadata med nyopprettede kunden.
  7. Bytt til "blandet dokumenter" bibliotek og laste opp et dokument. Forklare hvordan systemet ber for en dokumenttype.
  8. Gå tilbake til dokumentbiblioteket for fakturaer og viser hvordan å klikke på et kolonnenavn endrer sorteringsrekkefølgen.
  9. Demonstrere kolonnenivå filtrering.
  10. Vis forskjellige visninger som viser multi-level sortering, filtrering og gruppering.
  11. Vis arket datavisningen.
  12. Forklar formålet med en "ukodede dokumenter" Vis.
  13. Bytte til den tilpassede Avansert søk.
  14. Nå, nylig opplastede dokumentet skal ha blitt kravlet og indekseret, så utføre et søk som demonstrerer evne til å finne denne fakturaen tilordnet egenskapen.
  15. Vi viser forskjellen mellom forskende via tilordnede egenskaper vs. bare tekstsøk.

På dette punktet, Vi er mer eller mindre ferdig med demo. Det synes å ta om 30 til 45 minutter, avhengig av hvor mange spørsmål spør.

Vi deretter sende dem tilbake til sine pulter med "hjemmelekse". Dette består av en enkel excel regneark der vi be dem om å definere for oss hva de tror de trenger i CT'S, både på et høyt nivå (bare navn og forretningsmessige formål) kolonner og typen data vil de lagre i kolonnen. Vi spør ikke dem å definere kolonnedatatyper i MOSS vilkår, men forretningsbetingelser.

I Sammendrag:

Vi har laget en sandkasse miljø som vi kan bruke til å vise noen kjernefunksjoner for MOSS hvis klage er bedriftsomfattende.

Vi har modellert lett forstått og felles foretak slik at brukere kan fokusere på MOSS og ikke overbelastes på enheter / eksempler seg.

Forretningsbrukere unna teser økter med "hjemmearbeid" i form av excel-dokumenter som de er kompetente til å fylle og bruke til å utforme egne første-kutt innholdstyper.

Endelig, Vi utfører demoer over tid, klientens gruppemedlemmer seg bli til å videreføre, demoen 's selv og generelt frigjøre opp resten av oss for å arbeide med mer kompliserte problemer, som global taksonomi, komplekse arbeidsflyter, BDC og lignende.

Læring smidig // Scrum

Jeg spurte om noen råd i dag på gode ressurser for får begynte med Agile og Scrum. Her er en oppsummering av respons. Jeg stoler kilder, men jeg vet at dette er omfattende (Jeg er at det ikke).

Jeg kan ha transkribert noen av dette feil.

Flere personer svar og smidig prosjektledelse av Ken Scwaber er det konsekvente "første dykket" anbefaling.

Personligheter:

  • Ken Schwaber
  • Mike Cohn

Bøker:

  • Smidig prosjektledelse med Scrum av Ken Schwaber.
  • Len programvareutvikling: En smidig verktøykasse for programvare utvikling ledere Mary og Tom Poppendieck.
  • "noe av Mike Cohn"
  • Smidig Retrospectives av Ken Schwaber, Diana Larsen, Esther Derby.

Koblinger: