Přehled:

Ladění je obtížné při vývoji vlastních funkcí pro službu Windows SharePoint Services 3.0 (WSS) nebo Microsoft Office SharePoint Server (MECH). Hlavním viníkem je, že SharePoint obvykle povrchy velmi málo diagnostické informace o webovém prohlížeči dojde-li k chybě. Tato položka blogu popisuje, jak najít další generované systémem diagnostické informace, které mohou často poskytnout to extra kousek detailu, že potřebuje zjistit příčiny. To může vést k řešení problému.

Použil jsem tuto techniku s velkým úspěchem řešit jinak záhadné chyby.

Přístup:

SharePoint ukládá velké množství informací do diagnostického protokolu v souboru protokolu v 12 podregistr.

"12 Podregistru" je obvykle umístěna v "C:\Program FilesCommon FilesMicrosoft SharedWeb Server Extensions12 ". (Nejsem si jistý, jestli je to možné, 12 podregistr žít nikde jinde, Vlastně).

Myšlenka je k nalezení aktuální soubor protokolu, Vynutit chybu a pak rychle otevřít soubor protokolu. Tyto soubory protokolu jsou charakterizovány:

• Velkým množstvím informací. SharePoint generuje velké množství diagnostických informací a zapíše jej do tohoto souboru protokolu velmi rychle. Musíte být rychlý prsty zachytit to.
• Násobnost. SharePoint nelze zapisovat do jediného souboru protokolu, ale spíše vytváří několik souborů protokolů v posloupnosti.
• Zkopírujte a vložte pěkně do MS Excel.

Můj oblíbený způsob:

1. Otevřete Průzkumníka windows, přejděte 12 hivelogs.
2. Řazení zobrazení podle data změny (poslední první).
3. Zvýraznit aktuální soubor protokolu.
4. V okně webového prohlížeče, síla chybě dochází.
5. Rychle otevřít aktuální soubor protokolu a zkopírujte jeho obsah do MS Excel.
6. Přeskočit na konec a analyzovat příslušné údaje.

Jiné poznámky:

Ve výchozím nastavení, na diagnostický protokol se nachází v 12 hiveLOGS adresář.

MS Best practices (podle Mike T. Microsoft) stát, že by měly být soubory protokolů ukládány na samostatný pevný disk. Jeden je realizováno prostřednictvím centrální správy. Správce systému může udělat, v takovém případě by samozřejmě potřebujete najít soubor namísto výchozího protokolu 12 umístění úlu).

Tato položka řeší problémy jako například:

• Pracovní postup služby SharePoint se nepodařilo spustit z důvodu vnitřní chyby.
• (více přidáno postupem času)
• Tato položka byla užitečná, diagnostikování chyby pracovního postupu. (např.. "Pracovní postup se nepodařilo spustit z důvodu vnitřní chyby").

(Tato položka Kříž vyslaných mezi http://paulgalvin.spaces.live.com/blog/ a http://blogs.conchango.com)

Příspěvky na tomto webu jsou mé vlastní a nejsou nutně reprezentovat si Conchango pozice, strategie či názory.

Přehled:

Tato položka popisuje některé základní informace o velké (3,000 Uživatelé) Server Microsoft Office SharePoint Server (MECH) zavádění a co jsme udělali, aby si projekt tak, že klient je šťastný a pevně se cesty, končí s plnou přijetím sadu funkcí MOSS. O psaní vstupu, jsme přibližně 50% dokončení první fáze projektu. Jako věci pokrok, Budu aktualizovat tento záznam nebo zapsat nové položky.

V tomto konkrétním případě, Společnost se již nainstalován server SharePoint Portal Server 2003. Skupina nainstalován produkt v jakési "Uvidíme, jestli někdo stará" móda. To byl rychle přijat mnoho firemních uživatelů a stal se docela populární v podniku na svobodě. Jak si dokážete představit, to není nejlepší strategie zavádění (které klient ochotně připouští) a když mech dorazil na scénu, klient se rozhodl "to pravé" a najal abychom jim pomoci.

Jedním z centrální otázek, které před námi stojí, když jsme začali, realizaci tohoto projektu byla: Jak jsme se zavést MOSS na tohoto klienta? Vzhledem k tomu, že klient již měl zkušenosti se službou SharePoint, Říkali jsme si — Potřebujeme udělat "diferenciální" školení nebo si začneme od základu se? Po práci s klíčových uživatelů, zjistili jsme, že to brát jako zelené pole projekt vše dávalo větší smysl.

Toto rozhodnutí dal výchozí bod, ale stále nás opustila s hlavním požadavkem přemýšlením, dobrou strategii pro MOSS se připravujou na Enterprise. MOSS je velké zvíře … To zahrnuje správu obsahu, Správa dokumentů, Hledat, bezpečnost, zaměření na cílovou skupinu, řízení projektu, "báječný čtyřicet" šablony, pracovní postup, obchodní datový konektor, atd. Pár toto s tím, že je to velké organizace, může skutečně využívat prakticky všech významných MOSS funkce a máte předpoklady velký projekt s enterprise dosah a mnoho dobrých věcí se děje.

Jsme jsme konfrontováni s touto otázkou znovu a znovu … MOSS má podnik dosáhnout s jeho organizace sada funkcí, Přesto i poněkud sofistikované klienti mají těžké psychicky absorbovat tyto funkce, Ať sám nezanedbatelný zlomek jejich začlenění do jejich každodenní rutiny.

Já nemám magické řešení problému. Místo toho řeší jen první kroky, které jsme s klientem, aby je vedl na cestě k úspěšné dlouhodobé přijetí.

Rozsah:

Stejně jako jsem chtěl tým sestavit plán projektu, která zahrnovala takové milníky jako "PoepleSoft integrace prostřednictvím služby BDC dokončení", "Nový Cross oddělení produktu spustit pracovní postup kompletní" a "výkonné řízení KPI", Musel jsem se spokojit s něčím méně. To ovšem neznamená, že "méně" je špatné. Vlastně, "méně" že jsme se rozhodli pro první skutečně neměla kde byli, než jsme začali. V našem případě, "méně" proměnil:

• Správa jednoduchých dokumentů pomocí knihovny dokumentů, typy ovládání a obsahu verze.
• Efektivní hledání založené na typy obsahu a přizpůsobit předem vyhledávání (Via spravovaných vlastností, XSLT krásné výsledky, atd).

Kromě výše uvedených vlastností rozlehlé (což znamená, že aby se vyválí na všechna oddělení a uživatelů), Přidali jsme následující singleton v oboru mini projekty:

• Důkaz konceptu integrace služby BDC.
• Vícekrokové a víceoborová pracovní postup vytvořený pomocí SPD.
• Komplexní formulář aplikace InfoPath.
• Navařování KPI pro některé obchodního procesu (pravděpodobně HR talent pořízení v našem případě, i když to se může změnit).

Zde není 100% přesné, ale zástupce našeho přístupu a dostačující pro můj účel, což je vysvětlit, co považuji za "efektivní" Úvod mechu, který nastaví klienta pevně po Zlaté stezce plné přijetí MOSS.

Nebudu psát mnohem více o singleton v této položce. Chci poukázat na to, že tyto jsou součástí naší zastřešující strategie. Myšlenka je k provádění základní správy a vyhledávací funkce dokumentů všem uživatelům, ale poskytují vysoce funkční, vysoká viditelná a vysoce reprezentativní příklady jiných MOSS základních funkcí, které jsou prostě mimo schopnost absorbovat v této rané fázi většina uživatelů. Avšak, "tam bude" a člověk doufá, že ostatní účetní jednotky bude vědět o nebo se o nich dozvědět a chcete tyto funkce pro sebe, vedoucí k větší přijetí. Tyto ojedinělý úspěch příběhy také sloužit poskytnout náš prodejní tým "munice" pro úspěšné získání druhé, třetí a n fáze projektů.

Co jsme zavést a proč?

Mají usadil na správu dokumentů a vyhledávání jako základní požadavek podniková, Potřebovali jsme začít shromažďovat detaily. Jako praktická záležitost, To se točí kolem pochopení své dokumenty a nakonec mapována na pochopení typů obsahu.

Zjistil jsem, že je to těžké vysvětlit typy obsahu bez vizuální pomocníci. Další technické folk může unikat diskuse o typech obsahu, když CT jsou popsány v termínech z oblasti databází. "A CT se podobá tabulce databáze, to má sloupce a sloupce jsou definovány na základě datové typy, ale CT datové typy zahrnují více než jednoduché číslo/datum, ale také "choice" a "vyhledávání" a podobně." Můžeme hovořit o "rozšíření" typy obsahu, stejně jako člověk může dědit funkčnost od základní třídy v objektově orientovaných jazycích. Nicméně to není očividně užitečné pro uživatele admin oddělení dopravy, který nemá žádné technické zázemí. Tj, téměř všichni, že záleží v MOSS rollout.

Použití na bílé tabuli je ošemetný. Předložil jsem představu o typu obsahu a nakreslené geniální (a tak se zdá, že) fotky z typů obsahu a co dělají pro vás z hlediska hledání a jak lze rozšířit, atd. Na konci, to pocit, že některé žárovky zapnuli, ale výsledný obraz tabule je nepořádek.

To nás vedlo k současné a tak daleko nejúčinnější přístaviště: MOSS pískoviště web nakonfigurován tak, aby tyto funkce.

Pomocí izolovaného prostoru, demonstrujeme:

• Typy obsahu:
  • Vytvoření CT s více datovými typy (text, Datum, volba, logická hodnota, vyhledávání, atd).
  • Rozšíření CT vytvořením nového CT, založené na rodiče.
  • Hledání dokumentů pomocí CT metadata.
• Knihovny dokumentů:
  • Přidružení jednoho CT s knihovnou.
  • Co se stane, když jsme uložení dokumentu do knihovny?
  • Přiřazení více CT s knihovnou doc.
  • Co se stane, když jsme uložení dokumentu do knihovny?
  • Filtrování a řazení přes záhlaví sloupců v knihovna dokumentů.
  • Zobrazení knihovny dokumentů:
    • Řazení
    • Seskupování
    • "Rychlý vstup" (zobrazení dat listu)
    • "Netagované údaje" (pomoc s migrací do MECHU z jiných zdrojů obsahu; více o tom níže).

Sandbox server:

Navrhli naše stránky pískoviště se trvalým rysem ve vývojovém prostředí, lze pro účely školení dlouho poté, co jsme dokončit projekt jsme a zahrnuto několik artefaktů, jak je popsáno:

Typy obsahu:

Stanovili jsme následující typy obsahu: Faktura, Nákupní objednávka, Faktura za služby.

Vybrali jsme faktur a nákupních objednávek, protože jsou více či méně všeobecně pod
stála entity. Všichni v podnikání chápe, že faktura je požadavek na platbu Zákazník pro částka vydáno na určité Datum k úhradě dle některých platební podmínky. To vede k přirozené definici CT, který jsme nazvali "školení faktury" (odlišit od jakékoli jiné faktury). Podobně snadno definovat nákupní objednávka. Jsme také vytvořili "školení služby fakturu" vytvořením nového CT, založené na "školení faktury" CT a přidané pouze jeden sloupec, "poskytnuté služby".

S výše uvedenými, Nyní můžeme prokázat některé klíčové rysy CT aniž by zapadl snaží vysvětlit abstraktní pojem, první; Všichni už chápe, co máme na mysli "faktura" a "nákupní objednávka" a místo toho schopni zaměřit na mechanice CT sama.

Vlastní seznamy:

CT s sloupce typu "vyhledávání" Přejděte vlastní seznam nebo knihovnu dokumentů. Používáme rozsáhle a pískoviště, vytvořili jsme jednu podpoře vlastní seznam, který obsahuje zákazníky. Vybrali jsme zákazníky, protože je to jednoduchý koncept pochopit a snadné prokázat. Na faktuře CT má sloupec, "zákazník" To je definice typu "vyhledávání" To ukazuje na tomto seznamu.

Vytvořili jsme podobné vlastní seznam pro správu dodavatelů"" pro nákupní objednávku"" CT.

Knihovny dokumentů:

Vytvořili jsme dvě knihovny dokumentů: "Faktury" a "Smíšené dokumenty".

Jsme nakonfigurovali faktury knihovny dokumentů můžete spravovat pouze dokumenty CT typu "Faktura".

Jsme nakonfigurovali "smíšené dokumenty" Knihovna spravovat všechny tři CT.

Vytvořit několik pohledů, které ukazují, třídění, filtrování, datový list a seskupování.

Hledat:

Definovány dvě nové spravované vlastnosti a je namapován číslo faktury a zákazníků.

Jsme vytvořili nový web hledání vlastní pokrok a upravil umožnit uživatelům vyhledávání pro "faktury" pomocí těchto dvou mapovaných vlastností.

Upravit soubor XSLT tak, aby číslo faktury a zákazníků, Když představují, se objeví v tabulce HTML ve světlé barvě. Cílem je prokázat, že je možné takové formátování.

Dát to všechno dohromady:

Pořádáme pro klíčové uživatele k účasti v demo.

Sledujeme tento jednoduchý skript:

1. Popsat význam a účel CT, jako příklady pomocí faktur a nákupních objednávek.
2. Zobrazit definici CT faktury, když současně ujistili je, že není třeba používat tyto obrazovky, samy o sobě, jen vyzvednout pojmy.
3. Přejděte do knihovny dokumentů faktury.
4. Uložit dokument.
5. Prokázat, že zákazník drop dolů opravdu pocházejí z vlastního seznamu.
6. Přidat nového zákazníka do seznamu zákazníků a pak aktualizovat poslední odeslané faktuře meta data pomocí nově vytvořené zákazníkem.
7. Přepněte na "smíšené dokumenty" Knihovna a uložení dokumentu. Vysvětlete, jak systém zobrazí výzvu pro typ dokumentu.
8. Přejít zpět do knihovny dokumentů faktury a Ukázat, jak kliknutím na název sloupce se změní pořadí řazení.
9. Prokázat, sloupec úroveň filtrování.
10. Zobrazit různá zobrazení, které ukazují, víceúrovňové řazení, filtrování a seskupování.
11. Otevře zobrazení datového listu.
12. Uveďte účel "netagovaných dokumentů" pohled.
13. Přepněte do upravené rozšířené hledání.
14. Nyní, nedávno uloženým dokumentem byla by měl procházet a indexovat, tak proveďte hledání, které ukazuje schopnost najít tuto fakturu prostřednictvím mapované vlastnosti.
15. Ukazujeme, že rozdíl mezi hledání pomocí mapované vlastnosti vs. jen textové vyhledávání.

V tomto okamžiku, více či méně jsme hotovi s demo. Zdá se, že se o 30 do 45 minuty, lidé se ptají, podle toho, kolik otázek.

Pak je pošlete zpět na jejich stoly s "domácí". To se skládá z jednoduchého excelové tabulky, kde žádáme je, aby definovat pro nás, co si myslí, že potřebují co CT, na vysoké úrovni (jen jméno a účel) sloupce a typ dat by ukládat ve sloupci. Neptáme se definovat typy dat sloupců v MOSS termínů, ale obchodní podmínky.

V souhrnu:

Vytvořili jsme prostředí sandbox, které můžeme použít demonstrovat některé základní MOSS funkce, jehož odvolání jsou rozlehlé.

Jsme vymodelovali snadno srozumitelné a společné obchodní entity tak, aby uživatelé mohli soustředit na MECHU a ne zabřednout na entity / příklady, samy o sobě.

Obchodní uživatelé odejít prací sessions s "domácí úkoly" v podobě dokumentů aplikace excel, které jsou nyní kompetentní k vyplnění a používat pro navrhování jejich vlastní typy obsahu první řez.

Konečně, Jak provádíme ukázky v průběhu času, sami členové týmu klienta stát více schopen přenášet vpřed, demo na sebe, a obecně uvolnit zbytek nás pracovat na složitější problémy, jako globální taxonomie, složité pracovní postupy, BDC a podobně.