SharePoint og rask — Reese's Peanut Butter Cups av Enterprise-programmer?

Jeg har avsluttet dagen 2 RASK opplæring i solfylte Needham, MA, og jeg er fullstappet med ideer (som alle gode trening klasser gjøre meg). En spesiell del av har fort meg tenke og jeg ønsket å skrive det ned mens det var fortsatt friskt og normale daglige "ting" dyttet den ut av hodet mitt.

Vi SharePoint WSS 3.0 / MOSS implementers ofte står overfor problemer med noen rimelig størrelse SharePoint-prosjekt: Hvordan får vi alle ukodede data lastet inn SharePoint slik at det passer innenfor våre perfekt designet informasjonsarkitektur?

Ofte nok, Dette er ikke et vanskelig problem fordi vi begrense oss ut av trøbbel: «Vi bryr meg ikke om noe mer enn 3 måneder gamle." "Vi skal håndtere alt det gamle ting med søkeord og går fremover vi vil gjøre det riktig vei…" Etc.

men, Hva skjer hvis vi ikke kan begrense oss ut av problemer og vi ser på 10 's tusenvis eller 100 tusen (eller millioner) av dokumenter — lasting og merking som er våre from ønske?

RASK være svaret.

FAST er prosessen inneholder mange bevegelige deler, men et forenklet syn er dette:

  • En robotsøkeprogrammet prosess ser etter innhold.
  • Det finner innhold og hender det av til en megler prosessen som administrerer en pool av dokumentet prosessorer.
  • Megleren prosessen hender det av en dokument-prosessorer.
  • Dokumentet prosessoren analyserer dokumentet og via en rørledning prosess, analyserer bejeezus ut av dokumentet, og hender det av til en indeks builder typen prosess.

På starship FAST, Vi har mye kontroll over rørledningen for dokumentbehandling. Vi kan mikse og matche om 100 pipelinekomponenter og, mest interessant, Vi kan skrive egne komponenter. Som jeg sier, FAST analyserer dokumenter hver hvilken vei, men søndag og samler mye nyttig informasjon om disse dokumentene. De gale raske menneskene er åpenbart sinnssyk og obsessive om dokumentanalyse fordi de har verktøy og/eller strategier for å virkelig kategorisere dokumenter.

Så … bruke FAST i kombinasjon med egne egendefinerte pipelinekomponenter, Vi kan ta all denne konteksten informasjonen fra FAST og mate den tilbake til MOSS. Det kunne gå noe slikt:

  • Dokumentet blir matet inn fort fra MOSS.
  • Vanlig gal-obsessive rask dokument analyse og kategorisering skjer.
  • Egne egendefinerte pipelinekomponenter drops noen sammenheng informasjonen av til en database.
  • En prosess med vår egen design leser konteksten informasjonen, gjør noen beslutninger på hvordan å passe MOSS dokumentet innenfor våre IA og merker den ved hjelp av en webtjeneste og objektmodellen.

selvfølgelig, ingen slik automatiserte prosessen kan være perfekt, men takket være obsessive (og muligens insane-but-in-a-good-way rask folk), Vi kan ha en ekte slåss sjanse til en virkelig effektiv masse Last prosess som mer enn bare fyller opp en SQL-database med en haug med knapt søkbare dokumenter.

</slutten>

Abonner på bloggen min.

Technorati Merkelapper: , ,

legg igjen et svar

e-postadressen din vil ikke offentliggjøres. Obligatoriske felt er merket *