Jeg er på et projekt, hvor vi har brug for at indsamle statistikker i en funktion med navnet "lod en historie." Idéen er meget enkel — Hvis du kigger på en interessant artikel på intranettet og ønsker at dele den med en person, Klik på et hyperlink, mærket "del denne historie" e-mail til din ven.

Vi spillede rundt med en brugerdefineret formular til dette formål, men i sidste ende, fornuften vandt dag og vi bruge bare velkendte <en href = mailto:…> teknik. (<en href mailto:…> er en overraskende robust lille smule HTML; som en bonus, Dette link fører mig tilbage til min gamle UNIX mand sider dage; Det var dagene!).

Denne teknik giver en stor brugerflade til slutbrugere, da de får at bruge deres velkendte MS Outlook-klienten (Uanset hvilken email klient de har installeret eller).

Det gør tingene sværere for os fattige udvikler typer siden de klient * også * ønsker at køre en rapport i fremtiden, der viser hvor ofte brugerne deler historier og endda hvilke historier deles oftest.

Vi whiteboarded et par mulige løsninger. Min favorit er til carbon copy (CC) en SharePoint-liste. På den måde, slutbrugeren får stadig outlook-klienten, mens vi får til at fange begivenheden, fordi vi får en kopi af emailen os. Der er nogle indlysende ulemper. Det største problem er, at brugeren kunne simpelthen blanktegn ud eller på anden måde mangle CC adresse. Og, Vi har brug at administrere at begivenhedsbiblioteket af e-mails. Vi har et planlagt job på den ansvarlige for denne oprydning skrivetavle.

Hvis du har nogle kloge tilgang til at løse dette problem, Fortæl.

</slutningen>

Abonner på min blog.

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

Som anmodede og lovede, Jeg har uploadet min præsentation om, hvordan man opnå "meget" krav fra slutbrugere for SharePoint projekter og implementeringer. Det er her: http://CID-1cc1edb3daa9b8aa.SkyDrive.live.com/Self.aspx/SharePoint/Paul Galvin Great Requirements.zip

Jeg præsenterede dette SharePoint bedste praksis-konferencen i februar 2009 (www.sharepointbestpractices.com). Hvis du deltog i konferencen, du vil også få det på konferencen DVD.

Præsentationen indeholder en masse noter med de fleste dias. Det er ikke bare punkttegn.

(Se her for andre præsentationen på en regeringsførelse case study: http://paulgalvin.spaces.live.com/blog/cns!1CC1EDB3DAA9B8AA!3099.entry

</slutningen>

Abonner på min blog.

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

Ligesom mange SharePoint konsulent typer, Jeg har været udsat for en masse SharePoint funktionalitet. Nogle gange, Jeg dykke ret dybt. Andre gange jeg bare mærke det som jeg flyver af til et andet sæt af menupunkter. En af dem er "self service site skabelse." Jeg har ikke haft behov for det indtil denne uge.

Denne uge, Jeg har brug at løse et business problem, som jeg tror vil blive mere almindelige som virksomheder løsne op og omfavne mere direkte slutbrugeren kontrol over SharePoint. I dette tilfælde, Jeg har designet en webstedsskabelon til at støtte en bestemt slutbruger Fællesskabet. Folk i dette fællesskab bør være i stand til at oprette deres egne websteder efter behag ved hjælp af denne skabelon, når trangen slår dem.

Jeg mindes at se "selvbetjening site skabelse" før og jeg har altid gemt det væk i ryggen af mit hoved, tænker at "self service site skabelse" er SharePoint lingo betydning, naturligvis nok, noget lignende "slå mig hvis du vil slutbrugere at oprette websteder, når de ønsker at."

Så, Jeg tænder den, Prøv det ud og for mig, Det er ikke at skabe websteder. Det er at oprette webstedet Samlinger. Temmelig stor forskel. Det er ikke, hvad jeg vil, Overhovedet ikke.

Det er muligt at lade brugerne oprette nye sub steder via en brugerdefineret tilladelsesniveau. Dette er præcis, hvor jeg ville have gået i første omgang bortset fra, at etiketten "self service site skabelse" Label bedraget mig. Via twitter, Jeg lærer, at det også er bedraget andre 🙂

Jeg arbejder stadig ud af at give en lille smule af en mere strømlinet proces mens opholder sig rent ud af boksen, men der er en konkret vej at følge. Bare ikke blive distraheret af etiketten.

</slutningen>

Abonner på min blog.

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

Jeg var en af 20 eller 30 (eller måske 100?) Paneldeltagerne sidste nat på den New York SharePoint brugere Group møde. I stedet for den sædvanlige præsentationsformat, Det var alt om Q&A mellem publikum og panelmedlemmer. Tidligt, Michael Lotter introducerede mig til en ny idé, og jeg ønskede at dele.

Et publikum medlem beskrev, hvordan hans firma havde betalt en konsulent til at skrive en ansøgning til hans selskab. Konsulenten skrev det som et konsolprogram, der bruger SharePoint-objektmodel. Som et resultat, Dette betød at programmet skulle køres på en server i farmen. Dette betød, at enhver, der ønskede at bruge app ville have til at logge på serveren, gøre arbejdet og logge af. I første omgang, Dette var ikke et problem, men snart, flere og flere (ikke-tekniske) brugernes behov at bruge hjælpeprogrammet. Hans spørgsmål var (omskrive):

"Hvad er mine muligheder? Jeg ønsker ikke at holde lade brugere logge direkte på serveren, men de har brug for denne funktionalitet."

Michael Lotter foreslog at han konfigurerer en ny virtual machine, slutte det til gården som en hele Fiskeækvivalenter og lade brugere køre programmet derfra.

Dette er en temmelig fantastisk idé for mig. Generalisere denne løsning kommer til at tænke tanken om det væsentlige midlertidig, næsten engangs hele Fiskeækvivalenter. Jeg synes det er en temmelig pæn koncept. Denne midlertidige hele Fiskeækvivalenter kan køre et konsolprogram, der bruger SharePoint-objektmodel. Du kunne også bruge det til at køre stsadm-kommandoer. Det behøver ikke at være en del af regelmæssige lokale balancering. Hvis det går ned eller bliver ødelagt, Du kan blot spin op en ny. Jeg gentager mig selv, men jeg nødt bare til at sige, at jeg synes det er en virkelig pæn idé.

</slutningen>

Abonner på min blog.

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

Denne sidste uge, nogen stillede et spørgsmål om at oprette et SharePoint-miljø, der vil håndtere en temmelig stor mængde af nye dokumenter (10,000 +/- i dette tilfælde). Jeg ved ikke meget om dette, Men Takket være denne hvidbog, Jeg føler mig meget bedre informeret.

For mig, denne hvidbog er stort set bare bogen mærke i øjeblikket, men jeg begynde at læse gennem det og troede, jeg ville fremhæve min vigtigste take-away. SharePoint kan skaleres til at håndtere, på et minimum, denne belastning:

• 50k nye dokumenter pr. dag.
• 10 millioner dokumenter samlede.

Jeg skriver 50k / 10MM tal, fordi de er nemme nok at huske. Så længe du ved er de minimum, du vil ikke få ind i problemer. Beløbsgrænser er mindst 10 procent højere end og med ekstrem tuning, muligvis meget højere.

Tak, Mike Walsh, endnu en gang for hans ugentlige WSS FAQ opdateringer og rettelser post. Hvis du ikke er tilmeldt til det, Du bør seriøst overveje gør det.

</slutningen>

Abonner på min blog.

Under den forløbne uge, min kollega og jeg lavede nogle arbejde for en klient i NYC. Vi testede forskellige aspekter af en Mos gennemførelse ved hjælp af deres "standard" arbejdsstation bygge (i modsætning til vores bærbare computere). Mens du gør det, Vi løb ind i et par fejl ved at følge disse trin:

• Lukke sig op en MS word dokument via windows explorer (som bruger WebDAV).
• Foretage en ændring.
• Gem det.

Vi kom til at indse, at nogle gange (normalt den første gang) Vi gemte dokumentet, Gem holde ikke"." Gem blev ikke gemt. Vi ville trække dette dokument op igen og vores ændringer simpelthen var ikke der.

Vi forstod ikke roden spørgsmålet på dette punkt, men vi regnede med, at vi skal sørge for at den nyeste MS Office service pack havde været installeret på at arbejde station. IT-folk gik og gjorde det. Vi gik igennem testen igen og vi opdagede et nyt problem. Når vi gemt den, Vi har nu fået denne fejl:

Denne gang, det virkede som hver eneste ændring var, Faktisk, gemt, om vi svarede ja eller nej til scripts spørgsmål.

Endelig havde vi et kig på den selve gengivelse i kontor og det viser sig, at arbejdsstationen kørte MS Office 2000 med service pack 3 der dukker op under hjælp-> Om som "Office 2002".

Moralen af historien: Jeg vil altid bruge Office 2003 som min minimum baseline office-version, når du bruger WebDAV og mos.

</slutningen>

Abonner på min blog.

(Henblik på search engine, Dette er den fejl tekst):

Linje: 11807

Char: 2

Fejl: Objektet understøtter ikke denne egenskab eller metode

Kode; 0

URL-ADRESSE: http://sharepoint01/DocumentReview/_vti_bin/owssvr.dll?location=Documents/1210/testworddocument.doc&dialogview=SaveForm

Vil du fortsætte med at køre scripts på denne side?

I en eller min allerførste blogindlæg, Jeg beskrev den overordnede proces vi følges for at migrere en kunde fra SPS 2003 til MOSS. En læser har skrevet en kommentar, beder om flere detaljer og her er det.

For at migreringsprojekt, Vi var nødt til at finde en god måde at flytte en masse SPS 2003 dokumenter over til MOSS. Den oprindelige last var nemt nok. Opret et nyt mål-dokumentbibliotek i MOSS og bruge windows Stifinder til at flytte dokumenter.

Dette er det nye dokumentbibliotek:

Åbne to windows opdagelsesrejsende. Først punkt på SPS 2003 og andet på det nye dokumentbibliotek i MOSS. De følgende skærmbillede viser det. Bemærk, at den øverste browser faktisk peger på min c:\Temp-drev, men du kan forestille dig det peger på en SPS 2003 dokumentbibliotek:

Efter dette træk og slip-handling, mit mål ligner dette:

Nu er det tid til at beskæftige sig med metadata. Antage vi har kun én kolonne af metadata for disse dokumenter hedder "placering." Vi kan se fra de ovennævnte "alle dokumenter" Se, at placeringen er tom. Det er let nok at bruge en visning af data til at angive placeringen, eller endda gå ind i egenskaber for hvert dokument én efter én til at tilføje en placering. Lad os antage, at der er ingen praktisk måde at tildele kolonnen placering en værdi automatisk og at slutbrugerne skal gøre dette i hånden. Desuden, Lad os antage der er hundredvis af dokumenter (måske tusinder) og at det vil tage mange mange dage at opdatere metadataene. Som vi alle kender, ingen igangværende hen til sidde og arbejde for fire af fem dage lige opdatere metadata for dokumenter. I stedet, de vil bryde, over en periode på uger eller måske længere. At lette denne proces, Vi kan oprette en "ukodede data" Se som vist:

Nu, Når en person sidder ned for at tilbringe deres tildelte daglige time eller to at mærke overførte dokumenter, de kan bruge de "ukodede dokumenter" View til at fokusere deres indsats:

Som brugere tag dokumenter, de aflevere denne liste.

Begrebet en ukodede datavisning kan også hjælpe med en klasse af data validering problem folk spørge om på fora. Ud af boksen, der er ingen måde at forhindre, at en bruger uploade et dokument til mos og derefter indtaste ikke metadata. Vi kan angive at et bestemt webstedskolonne er obligatorisk, og brugeren vil ikke være tilladt at skubbe Gem knappen. Dog, Hvis brugeren uploads og derefter lukker browseren (eller bruger windows explorer til at uploade dokumentet), Vi kan ikke tvinge brugeren til at indtaste metadata (igen, ud af boksen).

Denne fremgangsmåde kan bruges til at hjælpe med denne situation. Vi kan bruge en "dårligt mærket data" Se let identificere disse dokumenter og rette dem. Par dette med en KPI og du har god synlighed til data med drill-down til at styre disse usædvanlige omstændigheder.

</slutningen>

Abonner på min blog.

Denne uge, Jeg har kæmpet lidt med mit hold til at få mos installeret i en simpel to-serverfarm. Efter at have gået igennem det, Jeg har en større forståelse for slags problemer folk rapport på MSDN fora og andre steder.

Den endelige farmkonfiguration:

• SQL/Index/Intranet hele Fiskeækvivalenter inden for firewall'en.
• Hele Fiskeækvivalenter i DMZ.
• En slags firewall mellem DMZ og den interne server.

Før vi startede projektet, vi lade kunden vide, hvilke porte skal være åbne. Under give og tage, frem og tilbage over det, vi sagt aldrig udtrykkeligt to vigtige ting:

1. SSL betyder, at du skal bruge et certifikat.
2. DMZ server skal være en del af et domæne.

Dag ét, Vi dukkede op for at installere MOSS og lært at domænekonti for databasen og mos ikke havde været lavet. At flytte ting, Vi gik videre og installeret alt med en lokal konto på serveren, intranet.

På dette punkt, vi opdagede forvirringen over SSL-certifikat og, Desværre, besluttede at have vores infrastruktur fyr kommer tilbage senere i denne uge til at fortsætte med at installere DMZ server. I mellemtiden, Vi løsning arkitekter flyttede videre med business ting.

En weekend går og som klienten henter certifikatet.

Vores infrastruktur fyr dukker op og opdager, at DMZ server ikke er tilsluttet noget domæne (enten en perimeter domæne med begrænset tillid eller domænet intranet). Vi spildte næsten en 1/2 dag på at. Hvis vi havde lade mangler SSL-certifikatet Mose os ned, Vi ville have opdaget det tidligere. Åh godt….

En anden endagsbilletter og de forskellige udvalg, sikkerhed, interesserede parter og (ikke så) uskyldige tilskuere alle er enige om at det er OK at deltage DMZ server med domænet intranet (Dette er en POC, Efter alt, ikke en produktion løsning).

Infrastruktur fyr kommer til wrap ting op. Denne gang vi med held passerer gennem den moderne spidsrod kærligt kendt som "konfigurationsguiden af SharePoint." Vi har et kig i central administration og … Yee haw! … DMZ server er opført i gården. Vi ser lidt nærmere og indser vi brød åben Champaign lidt mide tidligt. WSS tjenester sidder fast i en "starter" status.

Lang historie kort, Det viser sig, at vi glemte at ændre identiteten af tjenestekonto via central administration fra den oprindelige lokale konto til det nye domæne-konto. Vi gjorde det, re-løb konfigurationsguiden og voila! Vi var i erhvervslivet.

</slutningen>

Abonner på min blog.

Selv om det ikke er bogstaveligt talt sandt, som et praktisk spørgsmål, en internet-facing Webfrontend i en DMZ skal være i et domæne (dvs. ikke en enkeltstående server i sin egen lille arbejdsgruppe). Det behøver ikke at være i det samme domæne som den indre hele Fiskeækvivalenter(s) og andre servere (og sandsynligvis bør ikke), men det skal være et domæne.

Mine kolleger og jeg tilbragte en uforholdsmæssig meget tid på et forslag, som omfattede SharePoint forudsætninger. Dette omfattede en omfattende liste af firewall-konfigurationer, der ville sætte DMZ serveren til at deltage i gården og så videre. Desværre, Vi kunne ikke tilføjes en sætning et sted, sagde, at effekten, "det helt blodig punkt af denne konfiguration er at lade din DMZ hele Fiskeækvivalenter server, i et domæne, at slutte sig til den indre gård."

En perfekt storm af begivenheder, hvor vi dybest set kiggede venstre når vi måske har set ret, sammensværgelse om at skjule problemet fra os forholdsvis sent i processen, dermed forhindrer mig i at påberåbe sig min "fortælle dårlige nyhed tidligt" regel.

Suk.

Abonner på min blog.

Forum brugere ofte som spørgsmål som dette:

> Hej,
>
> Venligst fortælle mig, hvis der er nogen muligheder for at opbygge en brugerdefineret liste med
> Master og detaljeret type (ligesom fakturaer) uden at bruge InfoPath.
>

SharePoint giver nogle af de boks funktioner, der understøtter typer forretningskrav like that.

Generelt, man forbinder to lister sammen ved hjælp af en opslagskolonne. Liste A indeholder headeren fakturaoplysninger og liste B indeholder Fakturadetaljer.

Bruge yderligere lister til at vedligeholde kundenumre, produktnumre, osv.

Bruge webdelen indholdsforespørgsel (i MOSS kun) og/eller en data Se webdel til at oprette flettede visninger af lister. SQL Server Reporting Services (SRS) er også tilgængelig for rapportering side af det.

Dog, der er nogle vigtige begrænsninger, der vil gøre det vanskeligt at bruge ren out-of-the-box funktioner til noget, der er selv moderat komplicerede. Disse omfatter:

• Størrelsen af relaterede opslag viser vs. "smartness" af typen opslag kolonne. Et opslag kolonnetype præsenterer sig selv på UI forskelligt afhængigt af om du har aktiveret flere valg eller ej. I begge tilfælde, out-of-the-box-kontrol viser alle tilgængelige elementer fra kildelisten. Hvis kildelisten har 1,000 elementer, der vil være et problem. Kontrolelementet opslag bladre ikke gennem disse elementer. I stedet, det trækker dem alle i kontrolelementet. Det gør for en meget akavet brugergrænseflade både med hensyn til indtastning af data og resultater.
• Opslag "pull tilbage" én kolonne med oplysninger. Du kan aldrig trække tilbage mere end én kolonne med oplysninger fra kildelisten. For eksempel, Du kan ikke vælge en kunde "12345" og vise antal samt kundens navn og adresse på samme tid. Opslaget viser kun kunden nummer og intet andet. Dette gør for en akavet og vanskelige brugergrænseflade.
• Ingen intra-form kommunikation. Jeg har skrevet om denne her. Du kan ikke implementere overlappende drop-downs, betinget aktiverer/deaktiverer felter, osv.
• Ingen kaskadevise sletninger eller indbygget referentiel integritet. SharePoint behandler brugerdefinerede lister som uafhængige enheder og tillader ikke dig at linke dem til hinanden i en traditionel ERD forstand. For eksempel, SharePoint kan du oprette to brugerdefinerede lister, "kunde" og "fakturahovedet". Du kan oprette et fakturahoved der linker tilbage til en kunde på listen debitor. Derefter, Du kan slette kunden fra listen. Ud af boksen, der er ingen måde at forhindre dette. Til at løse slags problemer, du vil normalt bruge hændelseshandlere.

Det kan synes dystre, men jeg vil stadig bruge SharePoint som udgangspunkt for at opbygge denne form for funktionalitet. Selvom der er huller mellem hvad du har brug for i en løsning, SharePoint gør det muligt for os at udfylde disse huller ved hjælp af værktøjer som:

• Hændelseshandlere. Brug dem til at gennemtvinge referentiel integritet.
• Brugerdefinerede kolonner: Opret brugerdefinerede kolonnetyper og bruge dem i stedet for standard opslagskolonne. Tilføje personsøgning, buffering og AJAX funktioner at gøre dem lydhør.
• BDC. Kun mos-funktionen giver os mulighed for at forespørgsel andre SharePoint-lister med en overlegen brugergrænseflade til den sædvanlige opslagskolonne. BDC kan også nå ud til en back-end-serverprogram. Bruge BDC for at undgå replikering. I stedet for at replikere kundeoplysninger fra back-end ERP system, bruge BDC i stedet. BDC-funktioner giver en nice brugergrænseflade for at trække disse oplysninger direkte fra ERP-systemet, hvor det hører hjemme og undgår besværet med at opretholde en replikering løsning.

  BDC er en funktion, MOSS (ikke tilgængelig i WSS) og er udfordrende for at konfigurere.

• ASP.NET-webformular: Oprette en komplet AJAX-aktiveret formular, der bruger SharePoint-objekt model og/eller web services til at udnytte SharePoint lister samtidig en meget lydhør brugergrænseflade.

Den sidste mulighed kan føle som om du starter fra bunden, men overveje det faktum, at SharePoint-platformen starter du ud med de følgende vigtigste funktioner:

• Sikkerhedsmodellen med vedligeholdelse.
• Menusystemet med vedligeholdelse.
• "Overordnet tabel" (dvs. brugerdefinerede lister) med sikkerhed, indbygget vedligeholdelse og auditering.
• Søg.
• Backend integrationsværktøjer (BDC).

Hvis du starter med et nyt tomt projekt i visual studio, du har en masse infrastruktur og VVS til at bygge før du komme tæt på SharePoint tilbyder.

Jeg mener, at Microsoft har til hensigt at udvide SharePoint i denne retning af applikationsudvikling. Det virker som en naturlig forlængelse af den eksisterende SharePoint base. Microsofts CRM ansøgning giver stor mulighed for udvidelse af de typer, der er nødvendige for at understøtte header/detaljeret applikationsudvikling. Selv om disse funktioner i CRM, teknologien er naturligvis tilgængelige til SharePoint udviklingsteam og jeg forventer, at det vil gøre sin vej ind i SharePoint produktet ved udgangen af 2008. Hvis nogen har en viden eller indsigt i dette, venligst efterlade en kommentar.

</slutningen>