Jeg er på et prosjekt der vi trenger å samle beregninger rundt en funksjon kalt «del en historie." Ideen er veldig enkel — Hvis du ser på en interessant artikkel på intranettet og vil dele den med noen, Klikk en lenke merket "dele denne historien" sende den til vennen din.

Vi spilte rundt med et egendefinert skjema til dette formålet, men til slutt, sunn fornuft vant dagen og vi bruke bare kjent <a href = mailto:…> teknikk. (<et href-mailto:…> er litt overraskende robust av HTML; som en bonus, at koblingen bringer meg tilbake til min gamle UNIX mann sider dager; Det var tider!).

Denne teknikken gir et flott grensesnitt for sluttbrukere, siden de kommer til å bruke deres kjent MS Outlook-klienten (eller hva email klienten de har installert).

Det gjør ting vanskeligere på oss dårlig utvikler typer siden de klient * også * ønsker å kjøre en rapport i fremtiden som viser hvor ofte brukere dele historier og også hvilke artikler er felles oftest.

Vi whiteboarded noen potensielle løsninger. Min favoritt er å kopi (CC) en SharePoint-liste. Sånn, sluttbrukeren får fortsatt outlook-klienten mens vi kommer til å fange inn hendelsen fordi vi får en kopi av e-post oss. Det er noen mangler. Hovedproblemet er at brukeren kan bare fjerne ut eller på annen måte mangle CC adresse. Og, Vi trenger å administrere hendelsesbiblioteket av e-post. Vi har en planlagt jobb på den hvite bordet ansvarlig for at opprydding.

Hvis du har noen smarte tilnærming for å løse dette problemet, vennligst fortell.

</slutten>

Abonner på bloggen min.

Følg meg på Twitter på http://www.twitter.com/pagalvin

Som forespurt og lovet, Jeg har lastet opp min presentasjon på hvor å få "store" krav fra sluttbrukere for SharePoint prosjekter og implementeringer. Det er her: http://Cid-1cc1edb3daa9b8aa.SkyDrive.live.com/Self.aspx/SharePoint/Paul Galvin Great Requirements.zip

Jeg presenterte dette på SharePoint beste praksis-konferansen i februar 2009 (www.sharepointbestpractices.com). Hvis du deltok konferansen, du får også dette på konferansen DVD.

Presentasjonen inneholder mange notater med de fleste lysbilder. Det er ikke bare punkter.

(Se her for andre presentasjonen på en case-studie for styring: http://paulgalvin.spaces.live.com/blog/cns!1CC1EDB3DAA9B8AA!3099.entry

</slutten>

Abonner på bloggen min.

Følg meg på Twitter på http://www.twitter.com/pagalvin

Som mange SharePoint konsulent typer, Jeg har vært utsatt for mange SharePoint-funksjoner. Noen ganger, Jeg dykke ganske dypt. Andre ganger jeg bare merker det som jeg flyr av til et annet sett med alternativer. En av disse er "selvbetjent områdeoppretting." Jeg har ikke hatt behov for det til denne uken.

Denne uken, Jeg trenger å løse en virksomhet problem som jeg tror vil bli mer vanlig som løsne opp og omfavne mer direkte sluttbrukeren kontroll over SharePoint. I dette tilfellet, Jeg har laget en mal for å støtte en bestemte samfunnet. Folk i dette fellesskapet skal kunne opprette egne områder på vil bruke denne malen når trangen slår dem.

Jeg husket å se "selvbetjent områdeoppretting" før og jeg har alltid bortgjemt som bakhodet mitt tenker at "selvbetjent områdeoppretting" er SharePoint lingo betyr, åpenbart nok, noe sånt som "slå meg på hvis du vil at brukere skal kunne opprette områder når de skal."

Så, Jeg slår den på, Prøv det ut og for meg, Det er ikke å skape nettsteder. Det skaper området samlinger. Ganske stor forskjell. Det er ikke hva jeg vil, ikke i det hele tatt.

Det er mulig å la brukere opprette nye sub nettsteder via et egendefinert tillatelsesnivå. Dette er akkurat der jeg ville ha gått i første omgang bortsett fra at etiketten "selvbetjent områdeoppretting" etiketten bedratt meg. Via twitter, Jeg lærer at det også er lurt andre 🙂

Jeg er fremdeles arbeider ut hvordan du kan gi litt av en raskere prosess samtidig rent ut av boksen, men det er en klar bane til følge. Bare ikke bli distrahert av at etiketten.

</slutten>

Abonner på bloggen min.

Følg meg på Twitter på http://www.twitter.com/pagalvin

Jeg var en av 20 eller 30 (eller kanskje 100?) dommerne går kveld på den New York SharePoint brukere-gruppen møte. I stedet for den vanlige presentasjonsformat, Dette var alt om Q&A mellom publikum og panel-medlemmer. Tidlig, Michael Lotter introduserte meg til en ny idé, og jeg ønsket å dele.

En publikummer beskrevet hvordan selskapet hadde betalt konsulent skrive en søknad for hans selskap. Konsulenten skrev den som et konsollprogram som bruker SharePoint-objektmodellen. Som et resultat, Dette betydde at programmet hadde skal kjøres på en server i farmen. Dette betydde at alle som ønsket å bruke app måtte logge på serveren, gjøre arbeidet og avlogging. Først, Dette var ikke et problem, men snart, mer og mer (ikke-tekniske) brukere måtte bruke verktøyet. Hans spørsmål var (parafraser):

"Hva er mine alternativer? Jeg ønsker ikke å holde lar brukere logge direkte på serveren, men de trenger det funksjonaliteten."

Michael Lotter foreslo at han konfigurerer en ny virtuell maskin, delta i farmen som en WFE og lar brukere kjøre programmet derfra.

Dette er en ganske fantastisk idé for meg. Generalisere denne løsningen bringer tankene oppfatningen av egentlig midlertidig, nesten disponibel WFE. Jeg tror det er et ganske godt konsept. Denne midlertidige WFE kan kjøre et konsollprogram som bruker objektmodellen SharePoint. Du kan også bruke den til å kjøre stsadm-kommandoer. Det trenger ikke å være en del av vanlig lokale balansering. Hvis det går ned eller blir ødelagt, Du kan bare starte opp en ny. Jeg gjentar meg selv, men jeg må bare si at jeg tror det er en veldig pen idé.

</slutten>

Abonner på bloggen min.

Følg meg på Twitter på http://www.twitter.com/pagalvin

Denne siste uken, noen spurt et spørsmål om hvordan du oppretter et SharePoint miljø som vil håndtere et ganske stort antall nye dokumenter (10,000 +/- i dette tilfellet). Jeg vet ikke mye om dette, men takket være denne hvitboken, Jeg føler meg mye bedre informert.

For meg, Dette skrivet er ganske mye bare boken mark i øyeblikket, men jeg gjorde starte leser gjennom det og trodde jeg ville markere min viktigste take-away. SharePoint kan skaleres for å håndtere, som et minimum, denne belastningen:

• 50k nye dokumenter per dag.
• 10 millioner dokumenter totalt.

Jeg skriver 50k / 10MM tallene fordi de er enkle nok til å huske. Så lenge du vet de er minimumskrav, du får i trøbbel. Maksimumsgrensene som er minst 10 prosent høyere enn og ekstreme tuning, muligens mye høyere.

takk, Mike Walsh, igjen for hans Ukentlig WSS FAQ oppdateringer og rettelser post. Hvis du ikke abonnerer på den, du bør seriøst tenke om å gjøre det..

</slutten>

Abonner på bloggen min.

Under siste uken, min kollega og jeg gjorde noe arbeid for en klient i NYC. Vi var teste en ulike aspekter av en MOSS gjennomføring bruker sine "standard" Workstation bygger (i motsetning til våre bærbare datamaskiner). Mens du gjør det, Vi løp inn noen feil på følgende måte:

• Åpne opp et MS word-dokument via windows Utforsker (som bruker WebDAV).
• Endre.
• Lagre den.

Vi kom til å innse at noen ganger (vanligvis første gang) Vi lagret dokumentet, Lagre stikke ikke"." Lagre lagret ikke. Vi skulle dra dokumentet tilbake opp og endringer bare var ikke det.

Vi forstå ikke roten problemet på dette punktet, men vi skjønte at vi bør gjøre at den siste oppdateringspakken for MS Office hadde blitt installert på at arbeidsstedet. IT folk gikk og gjorde som. Vi gikk gjennom testen igjen og vi oppdaget et nytt problem. Når vi lagret, vi nå fikk denne feilen:

denne gangen, Det virket som hver endring var, faktisk, lagret, om vi svarte ja eller nei til skript spørsmålet.

Vi endelig hadde en titt på den faktiske versjonen av Office og det viser seg at arbeidsstasjonen kjører MS Office 2000 oppdateringspakker 3 som vises under hjelp-> Om som "Office 2002".

Moralen i historien: Jeg vil alltid bruke Office 2003 som min minimum baseline office versjon når du bruker WebDAV og MOSE.

</slutten>

Abonner på bloggen min.

(Søkemotor forbindelse, Dette er den feilen tekst):

Linje: 11807

Røye: 2

Feil: Objektet støtter ikke denne egenskapen eller metoden

Kode; 0

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

Vil du fortsette å kjøre skript på denne siden?

I en eller min første blogginnlegg, Jeg beskrevet hele prosessen vi fulgte for å overføre en kunde fra SPS 2003 til MOSS. En leser igjen en kommentar ber om flere detaljer og her er det.

For overføring prosjektet, Vi måtte finne en god måte å flytte en masse SPS 2003 dokumenter over MOSS. Den første lasten var lett nok. Opprette en ny måldokumentbiblioteket i MOSS og bruk windows Utforsker til å flytte dokumentene.

Dette er det nye dokumentbiblioteket:

Åpne to Vinduer oppdagelsesreisende. Punktet første SPS 2003 og andre på det nye dokumentbiblioteket i MOSS. Følgende skjermbilde viser dette. Merk at den beste nettleseren faktisk peker på min c:\temp-stasjonen, men du kan forestille deg den peker til en SPS 2003 dokumentbibliotek:

Etter at dra og slipp-operasjon, min mål ser slik ut:

Nå er det tid til å håndtere metadata. Anta vi har bare én kolonne med metadata for dokumentene kalt "sted." Vi kan se fra ovenfor "alle dokumenter" vise at plasseringen er tomt. Det er lett nok å bruke tabellvisning data til å angi plasseringen, eller gå til hver dokumentegenskapene én etter én til en. La oss anta at det er ingen praktisk måte å tildele plassering-kolonnen en verdi automatisk og at sluttbrukere må gjøre dette for hånd. Videre, La oss anta at det finnes hundrevis av dokumenter (kanskje tusenvis) og at det vil ta mange mange dager oppdatere metadata. Som vi vet alle, ingen kommer til å sitte ned og arbeide for fire av fem dager rett oppdatere metadata for dokumenter. I stedet, de vil bryte det over en periode på uker eller muligens lenger. Til denne prosessen, Vi kan lage en "umerkede data" visningen som vist:

Nå, Når noen sitter ned for å tilbringe sine tildelte daglig time eller to å merke overførte dokumenter, de kan bruke "ukodede dokumenter" å fokusere sin innsats:

Som brukere kode dokumenter, de faller denne listen.

Denne oppfatningen av en ukodede datavisning kan også hjelpe med en klasse av data validering problemet folk spørre om på forumet. Esken, Det er ingen måte å forhindre at brukerne laste opp et dokument til MOSS og deretter ikke inn metadata. Vi kan angi at en bestemt områdekolonne er obligatorisk og brukeren vil ikke kunne trykke lagre knappen. Men, Hvis brukeren laster opp og deretter lukker nettleseren (eller bruker windows Utforsker til å laste opp dokumentet), Vi kan ikke tvinge brukeren om å oppgi metadata (på nytt, esken).

Denne fremgangsmåten kan brukes til å hjelpe med situasjon. Vi kan bruke en "dårlig merket data" Vis å lett identifisere dokumentene og rette dem. Par dette med en KPI og du har god sikt til dataene med drilldown-administrere disse eksepsjonelle omstendigheter.

</slutten>

Abonner på bloggen min.

Denne uken, Jeg har slitt litt med mitt lag å få MOSS installert i en enkel to-serverfarm. Etter å ha gått gjennom den, Jeg har en større forståelse for slags problemer folk rapport på MSDN-foraene og andre steder.

Den endelige farmkonfigurasjonen:

• SQL/Index/intranett WFE innenfor brannmuren.
• WFE i DMZ.
• En slags brannmuren mellom DMZ og den interne serveren.

Før vi startet prosjektet, Vi lar klienten vet hvilke porter måtte være åpne. Under gi og ta, frem og tilbake over som, vi sa aldri uttrykkelig to viktige ting:

1. SSL betyr at du trenger et sertifikat.
2. DMZ server må være del av et domene.

Dag én, Vi møtte opp for å installere MOSS og lært at domenekontoene for database og MOSS hadde opprettet. Å flytte ting sammen, Vi gikk foran og installert alt med en lokal konto på intranett-server.

På dette punktet, Vi oppdaget forvirring over SSL-sertifikatet og, Dessverre, besluttet å ha vår infrastruktur fyr komme tilbake senere denne uken fortsette installasjonen DMZ server. I mellomtiden, Vi løsning arkitekter flyttet frem med forretningsområder ting.

En helg går, og klienten får sertifikatet.

Vår infrastruktur fyr dukker opp og oppdager at DMZ server ikke er med i noe domene (enten en perimeterdomenekontrolleren med begrenset tillit eller intranett-domene). Vi kastet bort nesten en 1/2 dag på som. Hvis vi ikke hadde lar mangler SSL-sertifikatet knele oss, Vi hadde oppdaget dette tidligere. Nåvel….

En annen dag, passerer og de ulike sikkerhet-komiteene, interesserte parter og (ikke så) uskyldige tilskuere alle enige om at det er OK å delta DMZ server med intranett-domene (Dette er en POC, når alt kommer til alt, ikke en produksjon-løsning).

Infrastruktur fyr kommer inn å bryte ting opp.. Denne gangen vi kunne passere gjennom den moderne gapestokk kjærlig kjent som "konfigurasjonsveiviseren for SharePoint." Vi har en titt i Sentraladministrasjon og … Yee haw! … DMZ-serveren er oppført i farmen. Vi se litt nærmere og innser vi brøt åpen Champaign litt midd tidlig. WSS tjenester er fast i en "starter" status.

Lang historie kort, Det viser seg at vi glemte å endre identiteten til tjenestekontoen via Sentraladministrasjon fra den opprinnelige lokale kontoen til nye domenekontoen. Vi gjorde det, re-løp konfigurasjonsveiviseren og voila! Vi var i virksomhet.

</slutten>

Abonner på bloggen min.

Selv om det ikke er bokstavelig oppfylt, som en praktisk materie, en Internett-rettet webfront i en DMZ må være i et domene (dvs.. ikke en frittstående server i sin egen lille arbeidsgruppe). Det trenger ikke å være i samme domene som den interne WFE(s) og andre servere (og burde ikke), men det må være et domene.

Mine kolleger og jeg tilbrakte en overdreven mengde tid på et forslag som inkluderte SharePoint forutsetninger. Dette inkluderte en omfattende liste over brannmurkonfigurasjoner som vil gi DMZ server til gården og så videre. Dessverre, Vi kan ikke legge til setningen et sted som sa, effekt, "hele blodig poenget med denne konfigurasjonen er å la serveren din DMZ WFE, i et domene, bli med interne gården."

En perfekt storm av hendelser, hvor vi i utgangspunktet så venstre når vi kan ha sett rett, konspirerte for å skjule problemet fra oss til ganske sent i prosessen, dermed hindrer meg fra å starte min "fortelle dårlige nyheter tidlig" regel.

Sukk.

Abonner på bloggen min.

Forum brukere ofte som spørsmål som dette:

> hallo,
>
> Behage fortelle meg hvis det er noen muligheter til å bygge en egendefinert liste med
> overordnet og detaljert type (som fakturaer) uten å bruke InfoPath.
>

SharePoint gir litt ut av boksen-funksjoner som støtte typer forretningskrav sånn.

Generelt, en kobler to listene sammen med en oppslagskolonne. Liste A inneholder fakturaen meldingshodeinformasjonen og liste B inneholder Fakturaopplysninger.

Bruk flere lister til å vedlikeholde kundenumre, produktnumre, osv..

Bruke en webdel for innholdsspørring (i MOSS bare) og/eller en vise webdelen for å opprette flettede visninger av lister. SQLServer Reporting Services (SRS) er også tilgjengelig for rapportering siden av det.

Men, Det er noen viktige begrensninger som kan gjøre det vanskelig å bruke ren ut-av-esken funksjonene for noe som er selv moderat kompleks. Disse inkluderer:

• Størrelsen på relaterte søk viser vs. "smartness" av kolonnetypen oppslag. Kolonnetypen oppslag presenterer seg på Grensesnittet forskjellig avhengig av om du har aktivert merker eller ikke. I begge tilfeller, out-of-the-box kontrollen viser alle tilgjengelige elementer fra listen. Hvis kildelisten inneholder 1,000 elementer, det skal være et problem. Kontrollen oppslag ikke bla gjennom elementene. I stedet, det trekker dem alle i kontrollen. Det gjør for en svært vanskelig brukergrensesnitt både dataregistrering og ytelse.
• Oppslag "Trekk tilbake" én kolonne med informasjon. Du kan aldri trekke tilbake mer enn én kolonne med informasjon fra listen. For eksempel, Du kan ikke velge en kunde "12345" og vise nummeret som kundens navn og adresse samtidig. Oppslag bare viser antall og ingenting annet. Dette gjør for et vanskelig og vanskelig brukergrensesnitt.
• Ingen intra-skjemaet kommunikasjon. Jeg har skrevet om dette her. Du kan ikke implementere gjennomgripende rullegardinlister, betinget aktivere/deaktivere felt, osv..
• Ingen gjennomgripende sletting eller innebygd referanseintegritet. SharePoint behandler egendefinerte lister som uavhengige enheter og kan du koble dem til hverandre i en tradisjonell ERD forstand ikke. For eksempel, SharePoint kan du lage to egendefinerte lister, "kunde" og "fakturahodet". Du kan opprette et fakturahode som kobler til en kunde i kundelisten. Deretter, Du kan slette kunden fra listen. Esken, Det er ikke mulig å hindre dette. Å løse denne type problem, du bruker vanligvis hendelsesbehandling.

Det kan virke dystre, men jeg ville fortsatt bruke SharePoint som utgangspunkt for å bygge denne typen funksjonalitet. Selv om det er mellomrom mellom det du trenger i en løsning, SharePoint gjør det mulig for oss å fylle disse hullene med verktøy som:

• Hendelsesbehandling. Bruk dem til å fremtvinge referanseintegritet.
• Egendefinerte kolonner: Opprette egendefinerte kolonnen og bruke dem i stedet for standard oppslagskolonnen. Legge til personsøker, bufring og AJAX funksjoner for å gjøre dem mottakelig.
• BDC. Denne MOSS-bare funksjonen kan vi spørre andre SharePoint-lister med overlegen brukergrensesnitt for vanlige oppslagskolonnen. BDC kan også nå ut til et serverprogram for bakenden. Bruk BDC for å unngå replikering. I stedet for å replikere kundeinformasjon fra bakdatabase forretningssystem, Bruk BDC i stedet. BDC funksjoner gir en hyggelig bruker grenseflate å rykk informasjonen direkte fra ERP-systemet der det hører og unngår å måtte opprettholde en replikering løsning.

  BDC er en MOSS-funksjon (ikke tilgjengelig i WSS) og er utfordrende for å konfigurere.

• ASP.NET-webskjema: Opprette en fullfunksjons AJAX-aktivert skjema som bruker SharePoint-objekt modell og/eller tjenestene for å utnytte SharePoint-lister samtidig som det gir en svært forståelsesfull brukergrensesnitt.

Det siste alternativet kan føle som om du starter fra scratch, men vurdere det faktum at SharePoint-plattformen starter du med følgende nøkkelfunksjoner:

• Sikkerhetsmodellen med vedlikehold.
• Menysystem med vedlikehold.
• "Master tabell" (dvs.. egendefinerte lister) med sikkerhet, innebygd vedlikehold og overvåking.
• Søk.
• Bakenden integrasjonsverktøy (BDC).

Hvis du starter med et nytt tomt prosjekt i visual studio, du har mye infrastructure og avløp å bygge før du nærmer hva SharePoint tilbyr.

Jeg tror at Microsoft har til hensikt å utvide SharePoint i denne retningen programutvikling. Det virker som en naturlig utvidelse til eksisterende SharePoint base. Microsoft CRM-programmet gir en stor utvidelse av måtte topptekst/detaljert programutvikling. Selv om disse funksjonene i CRM, teknologien er åpenbart tilgjengelig for SharePoint-utviklingsteam og jeg forventer at det vil gjøre sin vei til SharePoint-produktet slutten av 2008. Hvis noen har en kunnskap eller innsikt i dette, Legg igjen en kommentar.

</slutten>