Ive endte dagen 2 HURTIG træning i solrige Needham, MA, og jeg sprængfyldt med ideer (som alle de gode uddannelse klasser gør mig). Et særligt aspekt af har hurtigt mig tænkning og jeg ønskede at skrive det, mens det var stadig frisk og normale daglige "ting" skubbet det ud af mit hoved.
Vi SharePoint WSS 3.0 / MOSS iværksætteren ofte står over for en hård problem med enhver rimelig størrelse SharePoint projekt: Hvordan får vi alle de ukodede data indlæses i SharePoint, sådan at det hele passer i vores perfekt designet informationsarkitektur?
Ofte nok, Det er ikke sådan et svært problem, fordi vi anvendelsesområde os ude af problemer: "Vi er ligeglade om noget mere end 3 måneder gamle." "Vi vil håndtere alt det gamle ting med søgeordssøgning og gå frem vi vil gøre det rigtigt…" Osv.
Men, Hvad sker der, hvis vi ikke anvendelsesområde os ud af problemer, og vi ser på 10 tusinder eller 100 's af tusindvis (eller endda millioner) af dokumenter — lastning og tagging af som er vores fromme ønske?
HURTIGT kan være svaret.
FASTS søgning proces omfatter en masse bevægelige dele, men et forenklet synspunkt er dette:
- En webcrawler proces ser for indhold.
- Det finder indhold og hænder det til en mægler-processen, der administrerer en pulje af dokument-processorer.
- Mægler proces hænder det ned til en af dokument-processorer.
- Dokument processor analyserer dokumentet og via en rørledning, analyserer bejeezus ud af dokumentet og hænder det ned til et indeks builder type proces.
På starship FAST, Vi har en masse kontrol over pipeline til dokumentbehandling. Vi kan mikse og matche om 100 pipeline-komponenter og, mest interessant, Vi kan skrive vores egne komponenter. Ligesom jeg siger, HURTIGE analyserer dokumenter alle hvilket måde men søndag og den samler en masse nyttige oplysninger om disse dokumenter. Disse skøre hurtig mennesker er tydeligvis sindssyg og tvangspræget om dokumentet analyse fordi de værktøjer og/eller strategier til at virkelig kategorisere dokumenter.
Så … ved hjælp af hurtigt i kombination med vores egne brugerdefinerede pipeline-komponent, Vi kan få fat i alle sammenhæng oplysningerne fra FAST og fodre den tilbage til MOSS. Det kan gå noget som dette:
- Dokument tilføres hurtigt fra MOSS.
- Normal crazy-obsessiv hurtigt dokument parsing og kategorisering sker.
- Vores egne brugerdefinerede pipeline-komponent falder nogle af kontekstoplysninger ud til en database.
- En proces med vores eget design læser oplysninger om cellekontekst, gør nogle beslutninger om, hvordan man passer MOSS dokumentet inden for vores IA og markerer det ved hjælp af en webtjeneste og objektmodellen.
Selvfølgelig, Ingen sådan automatiseret proces kan være perfekt, men takket være tvangspræget (og eventuelt insane-but-in-a-good-way hurtige folk), Vi kan have en reel bekæmpelse skud på en virkelig effektiv masse belastning proces, der er mere end bare fylde op en SQL database med en masse knap søgbare dokumenter.
</slutningen>
