Pārskats:

Atkļūdošana ir grūti, izstrādājot pielāgotus funkcionalitāti Windows SharePoint Services 3.0 (WSS) vai Microsoft Office SharePoint Server (SŪNA). Galvenais vaininieks ir ka SharePoint parasti virsmas ļoti maz diagnostikas informāciju par web pārlūku, kad rodas kļūda. Šī bloga ieraksts ir aprakstīts, kā atrast papildu sistēma ģenerē diagnostikas informācija, kas bieži vien sniedz papildu mazliet sīkāk, ka viens, kas vajadzīga, lai identificētu cēloņus. Pēc tam tas var radīt problēmas risināšana.

Ir izmantot šo tehniku ar lieliem panākumiem atrisināt citādi noslēpumaino kļūdas.

Pieeja:

SharePoint saglabā informācijas lielu diagnostikas žurnāla žurnāla failā 12 strops.

"12 Stropu" parasti atrodas "C:\Program FilesCommon FilesMicrosoft SharedWeb Server Extensions12 ". (Es neesmu pārliecināts, ja tas ir iespējams, 12 stropu dzīvot nekur citur, patiesībā).

Ideja ir, lai atrastu pašreizējais reģistrācijas fails, spēkā esošo kļūdu un tad ātri atvērt žurnālfailu. Šie žurnālfaili raksturojas ar:

• Lielu informācijas apjomu. SharePoint rada ļoti lielu daudzumu informācijas diagnostikas un ieraksta to, ka žurnāla failu ļoti ātri. Jums ir ātri ar pirkstiem, lai attēlotu to.
• Daudzveidība. SharePoint vienā žurnāla failā nevar rakstīt, bet drīzāk rada vairākus log failus pēc kārtas.
• Nokopējiet un ielīmējiet labi MS Excel.

Manu iecienītāko metodi:

1. Atvērt programmu windows explorer, norādīdams uz 12 hivelogs.
2. Kārtot skatu, lai parādītu pēc modifikācijas datuma (Jaunākās pirmās).
3. Izcelt visvairāk pašreizējais reģistrācijas fails.
4. Web pārlūkprogrammas logā, spēks rodas kļūda.
5. Ātri atvērtu pašreizējais reģistrācijas fails un kopēt tā saturu uz MS Excel.
6. Pārlēkt uz beigām un analizēt attiecīgos ierakstus.

Citas piezīmes:

Pēc noklusējuma, diagnostikas žurnālā, kas atrodas 12 hiveLOGS katalogs.

MS Best prakse (saskaņā ar Mike T. Microsoft) norāda, ka jāsaglabā log failus atsevišķā cietajā diskā. Viens tas, izmantojot centrālās administrēšanas. Sistēmas administrators var izdarīt šo, tādā gadījumā acīmredzot vajadzēs atrast žurnālfails pastāv nevis noklusējuma 12 stropu atrašanās vieta).

Šis ieraksts atrisina problēmu, piemēram:

• SharePoint darbplūsmu nevar startēt, jo radusies iekšēja kļūda.
• (vairāk laika gaitā jāpievieno)
• Šis ieraksts ir bijusi noderīga, diagnosticējot darbplūsmu kļūdas (piem.. "Darbplūsmas neizdevās startēt iekšējas kļūdas dēļ").

(Šis ieraksts publicēts šķērsot starp http://paulgalvin.spaces.live.com/blog/ un http://blogs.conchango.com)

Ziņojumus šajā vietnē ir mans, un ne vienmēr atspoguļo Conchango ir pozīcijas, stratēģijās vai atzinumus.

Pārskats:

Šī ievadne apraksta pamatinformāciju par lielu (3,000 lietotāji) Microsoft Office SharePoint Server (SŪNA) izvēršana un tas, ko mēs iegūt projekta ritošā tādā veidā, ka klients ir apmierināts un stingri pa taku, kas beidzas ar pilnīgu pieņemšanu kopa MOSS. Kā rakstīt ierakstu, mēs esam aptuveni 50% ar projekta pirmo fāzi pabeigt. Kā lietas notiek, Es ņemšu atjaunināt šo ierakstu un/vai rakstīt jaunus ierakstus.

Šajā konkrētajā gadījumā, uzņēmums jau bija uzstādīta SharePoint Portal Server 2003. IT grupa instalēts šis produkts ir sava veida "Let's redzēt, ja kāds rūpējas" modes. Daudzi biznesa lietotāji ātri pieņēma un kļuva diezgan populārs uzņēmumā kopumā. Kā jūs varat iedomāties, tas nebija labākais ieviešanas stratēģija (kas klientam viegli uzņem) kad notikuma vietā ieradās MOSS, klients nolēma "visu izdarīt pareizi" un nolīga, mums jāpalīdz viņiem.

Viens no centrālā jautājumiem saskaras ar mums, kad mēs sākām šo projektu īstenošanā bija: Kā mēs ieviest SŪNA šim klientam? Ņemot vērā to, ka klients jau bija pieredze ar SharePoint, mēs prātoju — mums jādara "diferenciāļa" apmācības, vai mēs sākam no zemes uz augšu? Pēc darba ar galvenajiem lietotājiem, mēs noteicām, ka apstrādājot to kā zaļo meža klajumiņu projekts ieguva lielāku jēgu.

Šis lēmums deva sākumpunktu, bet joprojām paliek mums galvenās prasības norādītas, labu stratēģiju, izplatot MOSS enterprise. MOSS ir tik liels dzīvnieks … Tas ietver satura pārvaldības, dokumentu pārvaldība, meklēšanas, drošības, adresēšana auditorijai, projektu vadība, "pasakains četrdesmit" veidnes, darbplūsmas, biznesa datu savienotājs, uc. Pāris to ar faktu, ka tā ir liela organizācija, kas var patiesi var izmantot praktiski visu lielāko MOSS funkciju un jums ir liels projekts ar uzņēmuma reach un daudzas labas lietas notiek dotības.

Mēs esam saskaras ar šo problēmu atkal un atkal … MOSS ir uzņēmumam sasniegt ar savu uzņēmumu līdzekļu kopa, vēl pat nedaudz sarežģītu klientiem ir grūti garīgi absorbē šos līdzekļus, Ļaujiet tikai iestrādājot ievērojamu daļu savu ikdienas rutīnas.

Man nav burvju risinājums problēmai. Tā vietā es sāku risināt tikai ļoti pirmajiem soļiem, ko mēs esam veikuši ar klientu un izveda pa taciņu veiksmīga ilgtermiņa pieņemšanu.

Darbības joma:

Cik gribēju amatniecības projekta plāns, kas iekļauti šādi pavērsieni, kā "PoepleSoft integrācija, izmantojot BDC Completed" komanda, "Jaunu krusta nodaļas produktu uzsākt darbplūsmu pilnīgu" un "Pieņēma izpildu vadības KPI", Man nācās samierināties ar kaut ko mazāk. Tas nenozīmē, ka "mazāk" ir slikti. patiesībā, "mazāk" ka mēs nolēmām par sākotnējās ieviešanas bija jūdžu priekšā, kur tie bija, pirms mēs sākām. Mūsu gadījumā, "mazāk" pārvērtās:

• Dokumentu bibliotēkām, izmantojot vienkāršu dokumentu pārvaldības, versiju kontroli un satura tipiem.
• Efektīva meklēšana, pamatojoties uz satura tipus un pielāgot avansa meklēšanas (izmantojot pārvaldīto rekvizītu, XSLT diezgan rezultātus, uc).

Papildus iepriekš uzņēmuma līdzekļi (nozīmē, ka viņi ir iepazīstinājusi visiem departamentiem un lietotājiem), mēs pievienojām šādi Vienīgajos paredzētajās mini-projekti:

• BDC integrācijas koncepcijas.
• Multi-step un multi-zars darbplūsmas procesu, kas izveidots ar VPD.
• Sarežģītas InfoPath veidlapu.
• Virsmas KPI dažas biznesa procesam (droši vien HR talantu pārņemšanas mūsu gadījumā, kaut kas var mainīties).

Joma šeit nav 100% precīza, bet pārstāvis mūsu pieeju un pietiekama, lai mans mērķis šeit, kas ir izskaidrot to, ko es uzskatu "efektīvs" MOSS, kas noteiks klienta stingri nosaka zelta ceļu uz SŪNĀM pilns pieņemšana ieviešanu.

Es ne rakstīt daudz vairāk par vienīgajiem šajā ierakstā. Gribu uzsvērt, ka tie ir daļa no mūsu izstrādāt stratēģiju. Ideja ir, lai īstenotu galveno dokumentu pārvaldības un meklēšanas līdzekļi visiem lietotājiem vēl sniegt augsti funkcionālu, augsts redzamu un augsti pārstāvis piemēri citu galveno MOSS funkcijas, kas ir vienkārši ārpus vairumam lietotāju spēja absorbēt šajā agrīnajā stadijā. Tomēr, tie būs ", kas tur" un viens cer, ka citu uzņēmējdarbības vienību zinās vai uzzināt par viņiem un šie līdzekļi vēlamies paši, ved uz lielāku pieņemšanas. Šo vienīgo veiksmes stāsti kalpo arī, lai nodrošinātu mūsu pārdošanas komanda "munīcija" sekmīgi uzvarēt otrajā, trešais un n-fāzes projektiem.

Ko mēs piedāvājam un kāpēc?

Kam norēķinās par dokumentu pārvaldību un meklēšanu kā bāzes uzņēmuma prasība, mums vajadzēja sākt apkopot informāciju. Kā praktisku jautājumu, tā revolved apkārt izprast savus dokumentus, un ka galu galā kartēts uz izpratni satura tipus.

Esam noskaidrojuši, ka to ir grūti izskaidrot, satura tipus, bez vizuālo padotajiem. Tehniskāka tautas var staigāt prom no diskusijas par satura tipiem, kad CT ir aprakstīti datu bāzes ziņā. "A CT ir līdzīgs datu bāzes tabulā, tas ir kolonnas un kolonnas ir definētas kā datu tipi, bet CT datu tipi ir vairāk nekā vienkārši veselais skaitlis/datums, taču arī "izvēle" un "uzmeklēšanas" un tamlīdzīgi." Mēs varam runāt par "paplašināšana" satura tipi, līdzīgi viens var mantot funkcionalitāti no pamatklases objektorientētā valodās. Tomēr tas acīmredzot nav transporta departaments admin personai, kas nav tehniskā pieredze ir noderīga. T.i., gandrīz visi, ka jautājumus MOSS izvēršana.

Izmantojot balta tāfele ir iffy. Esat parādījis ideja par satura tipu un iezīmēta spožajām (vai tik tie šķiet) attēlu satura veidiem un to, ko viņi jums attiecībā uz meklēšanas un kā tie var tikt paplašināta, uc. Beigās, Tas justies kā dažas spuldzes ir ieslēgta, balta tāfele attēlam ir haoss, bet.

Tas mūs atveda uz mūsu pašreizējo un tik daudz efektīvākās nolaišanās vieta: konfigurēts, lai parādītu šos līdzekļus MOSS smilšu vietā.

Izmantojot smilšu vietā, mēs pierādītu:

• Satura tipi:
  • Izveidojot CT ar vairākiem datu tipiem (teksts, datums, izvēle, Boolean, uzmeklēšanas, uc).
  • Paplašinot CT, izveidojot jaunu CT, pamatojoties uz vecāku.
  • Meklē dokumentus, izmantojot Datortomogrāfijas metadatus.
• Dokumentu bibliotēkas:
  • Apvienojas vienotā CT ar bibliotēku.
  • Kas notiek, kad mēs augšupielādēt dokumentu bibliotēkā?
  • Apvienojas vairākas CT ar doc bibliotēka.
  • Kas notiek, kad mēs augšupielādēt dokumentu bibliotēkā?
  • Filtrēšana un kārtošana, izmantojot kolonnu virsrakstus doc lib.
  • Dokumentu bibliotēkas skatiem:
    • Kārtošanas
    • Grupēšanas
    • "Quick ieraksts" (datu lapas skatā)
    • "Dati bez tagiem" (lai palīdzētu ar migrācijas sūnas no citos satura avotos; vairāk par šo zemāk).

Smilšu vietā:

Mēs paredzēti mūsu smilšu vietā ir pastāvīga iezīme ilgu apmācību nolūkos izmantot pēc tam, kad mēs pabeigtu projektu izstrādes vidē un iekļauti vairāki artefakti, kā aprakstīts:

Satura tipi:

Mēs noteikti tālāk minētie satura tipi: Rēķina, Pirkšanas pasūtījumu, Faktūrrēķins par sniegtajiem pakalpojumiem.

Rēķina un pirkuma pasūtījuma izvēlētas tāpēc, ka tie ir vairāk vai mazāk vispārēji zem
stāvēja entītijām. Ikvienam biznesa saprot, ka rēķins ir maksājuma pieprasījums klientu par summa izsniegts uz noteiktu datums jāmaksā kā par kādu apmaksas nosacījumi. Tas noved pie dabas CT, kuru mēs saucām par "izglītības rēķina noteikšana" (lai atšķirtu to no jebkura cita veida rēķina). Pirkšanas pasūtījums tiek definēta līdzīgi viegli. Mēs arī izveidojām "apmācību pakalpojumu rēķinu" izveidojot jaunu CT, pamatojoties uz izglītības rēķina"" CT un pievienota tikai viena kolonna, "sniegtajiem pakalpojumiem".

Ar iepriekšminētajiem, mēs tagad var pierādīt CT ir dažas galvenās iezīmes, bez kļūst bogged noteikti cenšas izskaidrot abstrakts jēdziens pirmo reizi; visi jau saprot, ko mēs saprotam ar "rēķinu" un "pirkšanas pasūtījuma" un tā vietā ir iespēja koncentrēties uz mehānikas CT pati.

Pielāgotiem sarakstiem:

CT ar tipa "uzmeklēšanas kolonnas" norādiet uz pielāgotu sarakstu vai dokumentu bibliotēku. Mēs izmantojam šo plaši un smilšu, mēs izveidojām vienu atbalsta pielāgotu sarakstu, kurā ietverti klientiem. Mēs noplūktiem klientiem, jo tas ir viegls jēdziens, lai saprastu un viegli pierādīt,. Kolonna ir rēķinu CT, "klientu" norādītā tipa "uzmeklēšanas" kas norāda uz šo sarakstu.

Mēs izveidojām līdzīgu pielāgotu sarakstu, lai pārvaldītu "kreditoriem" "pirkšanas pasūtījumam" CT.

Dokumentu bibliotēkas:

Mēs esam izveidojuši divas dokumentu bibliotēkas: "Rēķini" un "Jaukto dokumenti".

Mēs konfigurēt rēķinu dokumentu bibliotēku, lai pārvaldītu tikai dokumentus CT veids "Rēķins".

Mēs konfigurēt "jaukto dokumenti" bibliotēku, lai pārvaldītu visus trīs CT.

Izveidot vairākus skatus, kas parāda kārtošanai, filtrēšana, datu lapā un grupēšanu.

Meklēšanas:

Mēs noteikti divu jaunu pārvaldīto rekvizītu un kartēt tos rēķina numuru, gan debitora.

Mēs izveidoja jaunu pielāgotu avansa meklēšanas vietni un modificēt tā, lai lietotāji varētu meklēt "rēķini" izmantojot šos divus kartētajiem rekvizītiem.

Modificēt XSLT lai rēķina un debitora numuru, kad prezentāciju, parādās HTML tabulu, spilgtas krāsas. Šeit mērķis ir pierādīt, ka ir iespējama šāda formatēšana.

Nodot to visu kopā:

Mēs sakārtotu galvenajiem lietotājiem piedalīties demo.

Mēs ievērojam šo vienkāršu skriptu:

1. Aprakstiet jēgu un mērķi, CT, kā piemērus, izmantojot rēķinu un pirkšanas pasūtījumu.
2. Parādīt rēķinu CT definīciju, vienlaikus nodrošinot viņiem, ka viņi nav nepieciešams izmantot šiem ekrāniem, paši, vienkārši paņemiet jēdzieni.
3. Rēķinu dokumentu bibliotēku.
4. Augšupielādēt dokumentu.
5. Pierādīt, ka klients nolaižamo sarakstu patiešām iegūst pielāgotu sarakstu.
6. Pievienot jaunu klientu klientu saraksta un pēc tam atjauniniet nesen augšupielādēts rēķina meta dati ar jaunizveidoto klientu.
7. Pārslēgties uz "jauktas dokumenti" bibliotēku un augšupielādēt dokumentu. Izskaidrot, kā sistēma prasa dokumenta veidu.
8. Iet atpakaļ uz rēķinu dokumentu bibliotēku un parādīt, kā noklikšķinot uz kolonnas nosaukuma maina kārtošanas secību.
9. Parādīt kolonnu līmeņa filtrēšanu.
10. Rādīt dažādiem viedokļiem, kas pierāda vairāku līmeņu kārtošanas, filtrējot un grupējot.
11. Parādīt datu lapas skatā.
12. Paskaidrojiet "dokumentos bez tagiem" skats.
13. Pārslēdzieties uz pielāgoto Izvērstā meklēšana.
14. Ko tagad, nesen augšupielādēto dokumentu vajadzētu pārmeklēt un indeksēt, Tātad veiktu meklēšanu, kas demonstrē spēju atrast šo rēķinu caur Kartēto rekvizītu.
15. Mēs parādītu atšķirību starp meklēšanu izmantojot kartētajiem rekvizītiem vs. tikai teksta meklēšanu.

Šajā brīdī, mēs vairāk vai mazāk tiek darīts ar demo. Šķiet, ņemt par 30 lai 45 minūtes, atkarībā no tā, cik daudz jautājumu uzdot cilvēki.

Mēs pēc tam nosūtīt tos atpakaļ pie saviem rakstāmgaldiem, ar "mājasdarbu". Tas sastāv no vienkārša excel izklājlapa, ja mēs lūdzam tos, lai definētu mums to, ko viņi domā, ka viņiem ir nepieciešams saistībā ar CT ir, gan augstā līmenī (tikai vārds un biznesa mērķiem) kā arī kolonnu un datu tipu, tās varētu saglabāt šajā kolonnā. Mums nav lūgt tos definētu kolonnu datu tipu MOSS izteiksmē, bet biznesa nosacījumus.

Kopsavilkumā:

Mēs esam izveidojuši sandbox vidi, kuru izmantojam, lai demonstrētu dažas SŪNA pamatfunkcijas kuru apelācijas sūdzība ir uzņēmuma.

Mums ir modelēta, viegli saprotamiem un kopējas uzņēmējdarbības vienībām tā, lai lietotāji varētu koncentrēties uz SŪNĀM un nevar saņemt bogged leju juridiskajām personām / paši piemēri.

Biznesa lietotāji iet prom no tēzes sesijas ar mājasdarbu"" excel dokumenti, ko tie tagad ir kompetenti aizpildīt un izmantot izstrādājot savu pirmo griezumu satura tipi formā.

Beidzot, kā mēs veicam demonstrācijas laikā, klientu grupas dalībnieki paši kļūtu vairāk spēj pārnest, demo ir sevi un parasti atbrīvotu līdzi pārējo mums jāstrādā pie sarežģītākām problēmām, piemēram, pasaules taksonomiju, sarežģītās darbplūsmās, BDK un tamlīdzīgi.

Biznesa scenāriju:

Uzņēmuma mēroga ieviešanu ražošanas uzņēmums ar MOSS 30+ vietnes un pāris desmiti uzņēmumu struktūrvienību.

Biznesa mērķi:

Neskatoties uz virkni biznesa grupas (departamenti, atrašanās vietas, uc), daži dati ir jāsaglabā globālā līmenī. Piemēram, autoritatīvs pamatsarakstā visas fiziskās atrašanās vietas uzņēmuma (piem.. ražošanas iekārtas, noliktavu atrašanās vietas, pārdošanas biroji) jāsaglabā vienā centrālā atrašanās vietā.

Tehniska problēma:

Uzņēmuma taksonomijas tika īstenota, izmantojot vairākas vietņu kolekcijas. Mēs vēlētos, lai pielāgotu WSS sarakstu izveidot autoritatīvu fizisko atrašanās vietu sarakstu. Pēc tam, kad mums vajadzēja būt kolonnu satura tipu (vai kolonnas pievienot sarakstam vai doc bibliotēka) kas ietverts uzņēmuma atrašanās vietas, mēs radītu izmantojot "uzmeklēšanas kolonnu" datu tipu un norādiet uz šo šablonu saraksts.

Diemžēl, uzmeklēšanas datatypes drīkst piekļūt avota saraksta "lokāli" nozīmē, ka mūsu autoritatīvo sarakstu nevar aptvert vietņu kolekcijas.

Tehniskais risinājums:

Ieviest jaunu pielāgotu datu tipu īsteno, pamatojoties uz SPField un attēlots kā DropDownList UI, kura ListItems aizpildīt no WSS pamatsarakstā.

Mēs esam izveidojuši jaunu vietņu kolekciju sauc par "http://localhost/EnterpriseData". Tur, mēs esam izveidojuši tādu pielāgotu sarakstu ar nosaukumu "Uzņēmuma atrašanās vietas". Šo sarakstu izmanto tikai standarta "Title" lauks satur faktisko uzņēmuma atrašanās vietu sarakstu.

Viena šāda vairāku diskrētu soļus, lai izveidotu pielāgotu datu tipu komponentā Windows SharePoint Palkalpojumi. Tie ir:

1. Definētu klases, kas manto no SPField (viens var mantot no citiem laukiem vajadzības).

Šeit ir kods, kas:

valsts klase XYZZYCorporateLocationField : SPFieldText
{
valsts XYZZYCorporateLocationField
(SPFieldCollection lauki, virkne typeName, virkne displayName)
: Base(lauki, typeName, displayName) { }

valsts XYZZYCorporateLocationField
(SPFieldCollection lauki, virkne displayName)
: Base(lauki, displayName) { }

valsts ignorēt BaseFieldControl FieldRenderingControl
{
iegūt
{
BaseFieldControl kontrole = jaunā XYZZYCorporateLocationFieldControl();
kontroli. FieldName = tas.InternalName;
atgriešanās kontrole;
} //iegūt
} // fieldrenderingcontrol

valsts ignorēt virkne GetValidatedString(objekta vērtība)
{
Ja (tas.Nepieciešama || vērtību. ToString().Ir vienāds ar(Virkne.Tukšs))
{
mest jaunā SPFieldValidationException ("Departaments nav piešķirts.");
}
atgriešanās Base.GetValidatedString(vērtība);
} // getvalidatedstring

} // XYZZYCorporateLocation

1. Noteikt citas klases, kas manto no bāzes lauka vadīklu, kā:

valsts klase XYZZYCorporateLocationFieldControl : BaseFieldControl
{
aizsargāti DropDownList XYZZYCorporateLocationSelector;

aizsargāti ignorēt virkne DefaultTemplateName
{
iegūt
{
atgriešanās "XYZZYCorporateLocationFieldControl";
}
} // DefaultTemplateName

valsts ignorēt objekta Vērtība
{
iegūt
{
EnsureChildControls();
atgriešanās tas.XYZZYCorporateLocationSelector.SelectedValue;
} // iegūt
kopā
{
EnsureChildControls();
tas.XYZZYCorporateLocationSelector.SelectedValue = (virkne)tas.ItemFieldValue;
} // kopā
} // objekta vērtība ignorē

aizsargāti ignorēt anulēts CreateChildControls()
{

Ja (tas.Laukā = = nulle || tas.ControlMode = = SPControlMode.Displeja)
atgriešanās;

Base.CreateChildControls();

tas.XYZZYCorporateLocationSelector =
(DropDownList)TemplateContainer.FindControl("XYZZYCorporateLocationSelector");

Ja (tas.XYZZYCorporateLocationSelector = = nulle)
mest jaunā Izņēmums("KĻŪDA: Nevar ielādēt. ASCX failā!");

Ja (!tas.IsPostBack lapu.)
{

izmantojot (SPSite vieta = jaunā SPSite("http://localhost/enterprisedata"))
{
izmantojot (SPWeb Web vietas =. OpenWeb())
{

SPList currentList = interneta. Saraksti["Uzņēmuma atrašanās vietas"];

foreach (SPItem XYZZYCorporateLocation programmā currentList.Items)
{
Ja (XYZZYCorporateLocation["Title"] == nulle) «««;

virkne parādīts Title;
parādīts Title = XYZZYCorporateLocation["Title"].ToString();

tas.XYZZYCorporateLocationSelector.Items.Add
(jaunā ListItem(parādīts Title, parādīts Title));

} // foreach

} // izmantojot spweb web = site.openweb()
} // izmantojot spsite site = jaunu spsite("http://localhost/enterprisedata")

} // Ja ne atpakaļizlikšanas

} // CreateChildControls

} // XYZZYCorporateLocationFieldControl

Iepriekš kods būtībā ievieš loģika populating DropDownList ar vērtībām no WSS pielāgotu sarakstu, kas atrodas http://localhost/enterprisedata un nosaukta "uzņēmuma struktūrvienības".

Es noteikti abās klasēs vienu. CS failā, apkopo to un ielieciet to GAC (vajadzīgs spēcīgs, protams).

1. Ieviest vadības veidni (.ascx) kā parādīts:

<%@ Kontrole Valodas= "C#" Pārmanto="Microsoft.SharePoint.Portal.ServerAdmin.CreateSiteCollectionPanel1,Microsoft.SharePoint.Portal,Versija = 12.0.0.0 kultūras = neitrāla,PublicKeyToken = 71e9bce111e9429c" compilationMode= "Vienmēr" %>
<%@ Reģistrēties Tagprefix= "wssawc" Namespace="Microsoft.SharePoint.WebControls" Asambleja="Microsoft.SharePoint, Versija = 12.0.0.0, Kultūras = neitrāla, PublicKeyToken = 71e9bce111e9429c" %> <%@ Reģistrēties Tagprefix= "SharePoint" Namespace="Microsoft.SharePoint.WebControls" Asambleja="Microsoft.SharePoint, Versija = 12.0.0.0, Kultūras = neitrāla, PublicKeyToken = 71e9bce111e9429c" %>
<SharePoint:RenderingTemplate ID= "XYZZYCorporateLocationFieldControl" runat= "serveris">
<Veidne:>
<ASP:DropDownList ID= "XYZZYCorporateLocationSelector" runat= "servera" />
</Veidne:>
</SharePoint:RenderingTemplate>
Iepriekš tiek saglabāts c:\Program filescommon filesmicrosoft sharedweb server extensions12controltemplates.

1. Beidzot, mums jāizveido XML fails ietaupīt vērā... 12XML katalogs. Tas ir CAML, kas nosaka mūsu pielāgotu datu tipu un mans piemērs, izskatās šādi:

<?XML versija="1.0" kodējums="UTF-8" ?>
<FieldTypes>
<FieldType>
<Lauks vārds="TypeName">CorporateLocations</Lauks>
<Lauks vārds="ParentType">Teksts</Lauks>
<Lauks vārds="TypeDisplayName">Uzņēmuma atrašanās vietas</Lauks>
<Lauks vārds="TypeShortDescription">Visas XYZZY uzņēmumu atrašanās vietas, tai skaitā ražošanas vai citām iekārtām.</Lauks>
<Lauks vārds="UserCreatable">PATIESS</Lauks>
<Lauks vārds="ShowInListCreate">PATIESS</Lauks>
<Lauks vārds="ShowInDocumentLibraryCreate">PATIESS</Lauks>
<Lauks vārds="ShowInSurveyCreate">PATIESS</Lauks>
<Lauks vārds="ShowInColumnTemplateCreate">PATIESS</Lauks>
<Lauks vārds="FieldTypeClass">Conchango.XYZZYCorporateLocationField, XYZZYCorporateLocationField, Versija = diapazonā no 1.0.0.0, Kultūras = neitrāla, PublicKeyToken = b0b19e85410990c4</Lauks>
<RenderPattern vārds="DisplayPattern">
<Slēdzis>
<Izteiksme>
<Kolonnu />
</Izteiksme>

<Gadījumā Vērtība=""/>

<Noklusējuma>
<HTML>
<![CDATA[<span style = "krāsa:Red"><b>]]>
</HTML>

<Kolonnu SubColumnNumber="0" HTMLEncode="PATIESS"/>

<HTML><![CDATA[</b></laiduma>]]></HTML>

</Noklusējuma>
</Slēdzis>

</RenderPattern>
</FieldType>
</FieldTypes>
Šajā XML failā pievieno pielāgotu datu tipu WSS "bibliotēka" un vai tas atbilst pret GAC bija montāža.

Pēc šiem biti nonākšanu vieta, iisreset no servera, un tas būtu visas sākuma strādā labi.