Cum funcționează Deploymentul SharePoint

Schema generală

  • Pachetul WSP intră mai întâi în baza de date de configurare
  • Când instalați fișiere din pachet pe computerele fermei, aceasta se aplică funcțiilor, ansamblurilor și fișierelor de aplicații.
  • Când caracteristica este activată pe baza manifestului din baza de date de conținut, sunt create înregistrări care fac referire la fișierele de pe disc.

Această schemă a fost inventată în versiuni anterioare de SharePoint pentru a economisi spațiu în baza de date, dacă aceleași funcționalități sunt utilizate în multe site-uri. În plus, este atât de convenabil să actualizați, este suficient să implementați o nouă versiune a pachetului și toate site-urile vor primi modificări.







În practică, această schemă funcționează prost.

Problemele pornesc când se schimbă fișierele \ fields \ types \ types. Când se întâmplă acest lucru, o schemă (definiție XML) este scrisă în baza de date sau în fișierul actualizat în sine, iar legătura cu fișierul de pe disc este pierdută. Această stare este numită nehotărâtă sau personalizată. O nouă actualizare prin actualizarea fișierelor de pe disc deja nu mai funcționează.

Situația este exacerbată de faptul că dezactivarea nu șterge liste și fișiere și nu șterge tipurile de conținut și câmpurile la care se face referire în liste. Reactivarea caracteristicilor, în prezența unor artefacte în baza de date cu conținut, funcționează destul de imprevizibil.

Desigur, puteți crea toate artefactele utilizând XML, evitând codul care provoacă personalizarea. Dar nu toate soluțiile pot fi făcute în acest fel. Multe lucruri, cum ar fi taxonomia, vizarea publicului și mavigația metadatelor în XML, sunt foarte dificil de descris. Dar cel mai important lucru este că personalizarea poate fi apelată de utilizator. Și dacă capacitatea de a personaliza blocarea, atunci flexibilitatea care dă SharePoint.

O altă problemă este legată de liste și șabloane (definiții) ale listelor. Dacă lista este creată de șablon și nu este personalizată, dar șablonul nu este pe disc, atunci există o mulțime de erori confuze atunci când se utilizează API-ul și unele funcții standard.

Din cauza acestor probleme, mulți au abandonat complet implementarea de artefacte folosind definiții XML și au început să facă artefacte folosind cod. Această abordare este mult mai detaliată și crește probabilitatea erorilor, dar în același timp oferă controlul procesului atunci când se creează, și cel mai important, atunci când se actualizează artefacte.







Prima modificare este adăugarea semnalizatoarelor Overwrite în definițiile câmpurilor și tipurilor de conținut. Cu acest steguleț, câmpurile și tipurile atunci când caracteristica este activată sunt scrise în baza de date a conținutului, fără a crea legături la fișierele de pe disc. În plus, a devenit posibilă reactivarea caracteristicilor cu prezența unor artefacte în baza de date cu conținut. Acest lucru rezolvă parțial problema, dar numai parțial, deoarece problema cu listele create de șabloane nu este rezolvată.

A doua modificare este adăugarea opțiunii de upgrade. Acum nu puteți șterge soluția și nu reactivați funcțiile pentru a obține funcționalități noi.

Cea de-a treia schimbare este apariția soluțiilor Sandbox care nu utilizează fișiere în sistemul de fișiere și să creeze imediat toate artefactele în baza de date cu conținut. În acest caz, retragerea soluției Sandbox determină dezactivarea tuturor funcțiilor, însă pentru FullTrust acest lucru nu se întâmplă.

Pare acum posibil să faci ceea ce este necesar, folosind oportunitățile potrivite. Dar a existat și o altă greșeală - toate schimbările nu au fost documentate în nici un fel și procesul de desfășurare a devenit chiar mai imprevizibil și, în general, a existat o situație în care nimeni nu știe cum să o facă corect.

Ce să faceți

Prima opțiune este de a face totul cu codul. Din păcate, codul se dovedește foarte mult și scrierea este foarte deranjantă. Unele lucruri fac dificil codul, unele imposibile.

A doua opțiune este implementarea în XML, nu dezactivați funcțiile (mai ales dacă duce la pierderea de date sau la întreruperea performanței), nu reluați soluția, utilizați actualizarea caracteristicilor. Acest lucru necesită și scrierea unui cod, dar într-o cantitate mult mai mică.

Apropo de a utiliza activarea de caracteristici pentru livrarea de funcțional la utilizator - nu este, de asemenea, cea mai bună opțiune. Mult mai bine:

  1. Crearea site-urilor după șablon.
  2. Creați liste în funcție de șablon.
  3. Elemente suplimentare din meniul de administrare (pentru site-uri, liste, tipuri de conținut).
  4. Extinderea funcției existente.

Caracteristica însăși este cel mai bine ascunsă, activată automat atunci când soluția este implementată sau scriptul de instalare.

Dacă faceți această funcție vizibilă, trebuie să testați întotdeauna posibilitatea activării / dezactivării sale multiple, inclusiv pe site-uri diferite și colecții de site-uri.

concluzie

Dacă lucrați cu SharePoint, ar trebui în orice caz să știți cum funcționează implementarea artefactelor. Puteți învăța acest lucru într-un mod tipic pentru ansamblurile de colectare SharePoint din ILSpy sau Reflector. Cele mai multe dintre ceea ce am descris în acest post am învățat de la ansamblul Microsoft.SharePoint.

Data viitoare vă voi spune cum să utilizați actualizarea de funcții și cum să creați rapid soluții în SharePoint.

Cum funcționează Deploymentul SharePoint

Stas Vyshchepan

Compania mea







Articole similare

Trimiteți-le prietenilor: