Una din problemele curente ale implementării formularelor personalizate de introducere a datelor în SharePoint este legată de suportul multi-lingvistic. SharePoint-ul on-premises ca și cel on-line are un pachet lingvistic preinstalat, dar nu are funcționalități asemănătoare pentru formularele listelor personalizate.
Scopul acestui articol care conține două filmulețe scurte este de a prezenta un mod propriu de implementare a suportului multi-lingvistic pentru formularele personalizate în InfoPath pentru listele custom. Menționez că personalizarea formularelor în InfoPath nu este disponibilă decât în versiunile Enterprise din on-premises și anumite planuri din Office 365.
Primul lucru este definirea unei liste personalizate cu traducerile care trebuie să conțină cuvântul sau expresia, limba condificată din două caractere și ordinea câmpului sau mai bine spus a etichetei pe formular. Toate coloanele sunt de tip text și puteți identifica câteva exemple din filmulețe.
Primul film prezintă modul în care percepe utilizatorul formularul respectiv, modul în care sunt legate de lista de traduceri valorile echivalente fiecărei limbi și modul simplu în care este implementat în formular.
Al doilea filmuleț prezintă o variantă extinsă a acestui model de implementare multi-lingvistică cu aplicabilitate asupra câmprilor de tip drop-down list.
Pentru ISACA Student Group Iași și mentorul lor. ;)
Cineva respectabil îmi spunea de mult: Nimeni nu este de neînlocuit. Foarte multă dreptate în aceste vorbe. Dar mai ales în timp. J
Conjunctura
Am învățat în timp, din business-urile private, adevărata valoare aplicată a axiomei: Nimic nu se pierde. Totul se transformă. Asta se traduce în cuvinte simple că un conținut informațional construit în timp nu se șterge niciodată. Niciodată până nu se întâmplă concret.
Să lăsăm trecutul în urmă și să discutăm concret despre tema acestui articol.
Conceptul de disaster recovery nu vine niciodată în momente de liniște în activitatea profesională, ci se suprapune de cele mai multe ori cu alte momente de criză, care se acutizează odată cu indisponibilitatea unor servicii IT adresate componentei economico-financiare. Fiecare companie dispune de planuri de continuitate cunoscute sub numele de Business Continuity Plan sau Disaster Recovery Plan, dar fiecare responsabil de planurile de acțiune, cred că merge (aici sunt ironic), pe față sau mai pe ascuns, din când în când, la Biserică pentru a aprinde o lumânare în „sănătatea” și continuitatea serverelor J. De la a se întâmpla cu caracter de excepție până la a șterge just like this un întreg pachet informațional nu poate fi susținut decât printr-o decizie fermă de management cu scopul de a demonstra spusele de demult. Nu condamn pe nimeni și nimic prin acest articol. Chiar sper să vin în ajutorul celor care ajung din întâmplare la cazuri de acest gen.
În acele planuri de continuitate a afacerii există documentate proceduri clare de realizare a copiilor de siguranță și a modului de restaurare a acestora. Se spune chiar că, backup-urile trebuie testate la perioade regulate de timp.
Teoria
În SharePoint 2013 există mai multe metode de backup utile și una inutilă. Cea inutilă este să copii din Windows Explorer conținutul unui SharePoint. Da poate fi bună pentru anumite librării de documente și chiar liste cu fișiere atașate, dar este stupidă pentru pagini sau pentru conținutul listelor și alte aplicații dezvoltate.
Dintre metodele utile, amintim:
Farm backup – folosind Central Administration sau powershell.
SQL Database backup – folosit cel mai frecvent datorită mecanismelor puternice de automatizare puse la dispoziție de SQL Server.
Granular backup (articolul este pe 2010 dar funcționează și în 2013)- care presupune creare de fișiere CMP pentru site-uri, subsite-uri, până la nivel de liste.
Third-party Backup tools – care pun la dispoziția administratorilor de SharePoint o gamă largă de instrumente și facilități. Am lucrat din lista respectivă cu DocAve, Quest și Metalogix, acesta din urmă fiind cel care mi-a plăcut cel mai mult. Din păcate sunt produse foarte scumpe.
Metodele de recovery sunt și ele destul de diferite și diferă de la caz la caz. În prezentul articol ne propunem să luăm cazul maxim, acela în care nu avem decât un MDF, de pe o anumită versiune de SQL Server, din care trebuie să recuperăm un site dintr-o fostă fermă de SharePoint, despre care știm că este un SharePoint 2013 Enterprise. Noua fermă se află într-un alt domeniu Active Directory.
Puțin dramatism aplicat
Pentru cei care cunosc puțin SQL Server, o bază de date este formată la nivel fizic pe disc din cel puțin două fișiere: MDF – în care sunt stocate datele și LOG în care sunt păstrate tranzacțiile. LOG-urile devin mari în timp în SharePoint dar există metode de a le diminua. În momentul în care se realizează backup-ul unei baze de date SQL Server se poate crea ori un fișier BAK sau unul TRN. Aceste copii de siguranță se pot restaura aproape pe oricare alt server de SQL, chiar dacă mai pot apărea probleme de versiune a bazei de date, de compatibility level sau Collation.
Presupunând că dintr-o eroare rămâi doar cu un MDF (fișierul cu date), există mai multe proceduri de restaurare a acestuia, din păcate unele dintre ele fără un rezultat pozitiv. Cel mai concludent articol de restaurare doar dintr-un MDF mi s-a părut acesta: http://www.sqlskills.com/blogs/paul/checkdb-from-every-angle-emergency-mode-repair-the-very-very-last-resort/. Chiar dacă este un articol excelent este exemplificat pe o bază de date cu o tabelă și totul se desfășoară în același mediu de test, ignorând permisiuni din domenii de autentificare diferite cu certificate de criptare diferite și altele.
Un recovery (aproape) normal
În cazul în care avem un backup de SharePoint Farm suficient de bine calibrat în timp pentru a putea fi utilizat la un restore, putem alege din lista de restore să selectăm doar un content database specific unui webapp.
Această operațiune va avea drept rezultat crearea și restaurarea unei baze de date în serverul de SQL dar care nu va fi montată automat pe un anumit site în cazul în care ferma este la o altă versiune decât cea a fermei din care se încearcă restaurarea.
Mesajul de eroare: Object P_Research_Content failed in event OnPostRestore. For more information, see the spbackup.log or sprestore.log file located in the backup directory. SPException: Cannot attach database to Web application. Use the command line tool or Central Administration pages to attach the database manually to the proper Web Application.
Să nu mai spună linuxiștii că numai ei au comenzi J
Presupunând că am reușit să restaurăm baza de date, pasul următor este acela al creării unei web-app sau content site nou în care să montam baza de date de recuperat. Montarea unei baze de date se poate face vizual sau din PowerShell cu comanda Mount-SPContentDatabase.
Principalele comenzi pentru bazele de date sunt:
New-SPContentDatabase
Remove-SPContentDatabase
Mount-SPContentDatabase
Dismount-SPContentDatabase
Get-SPContentDatabase
Set-SPContentDatabase
Upgrade-SPContentDatabase
Test-SPContentDatabase
Pentru montarea unei baze de date și testarea conținutului avem nevoie de un nou webapp.
Observăm din cele două comenzi că există o diferență de versiune între baza de date și ferma de restore. Microsoft recomandă pentru această situație actualizarea fermei la același nivel cu cel al bazei de date prin aplicarea service packs-urilor și a Cumulative update-urilor necesare.
Pe de altă parte un articol, pe care l-aș cataloga drept The Most Microsoft Not Recommended Article J, este cel prin care ni se sugerează să modificăm versiunile direct în baza de date, asemănător cu ceea ce există într-o bază de date similară din acea fermă. Repet! Se recomandă editarea directă a înregistrărilor din tabela Versions. Microsoft spune foarte clar în documentele oficiale de suport pentru SharePoint că, orice modificare la nivel de baze de date va aduce cu sine pierderea suportului pe produsul respectiv. Și de aici apar o serie de interpretări și rumori: Modific structura sau datele?
Presupunând faptul că vrem doar să recuperăm ceva din acea bază de date defunctă trebuie să știm că SharePoint 2013 permite recuperarea datelor din baze de date nemontate pe webapp, dar orice tentativă de restore s-ar solda cu același mesaj de eroare legat de versiuni.
În politicile IT din organizații se specifică destul de clar faptul că orice fermă de SharePoint trebuie să aibă o fermă paralelă de test și una de dezvoltare. Pe toate aceste ferme trebuie să existe instalate aceleași pachete de tip update sau service pack pentru a asigura compatibilitatea. Nu știu câte firme din cele care au SharePoint țin la rigoarea acestei proceduri.
În cazul în care nu reușim să montăm baza de date și vrem să facem o restaurare fără montare, folosind Central Administration, vom primi mesajul de eroare: Sorry, something went wrong SharePoint object [SPContentDatabase Name=p_research_Content] is in an unsupported state, and could not be used by the current farm.
Some final action – Exportul
După modificarea valorilor din tabela Versions montarea merge cu succes așa că o să exemplificăm mai departe restaurarea granulară a unui subsite.
Din Central Administration se accesează secțiunea Backup and Restore și apoi Recover data from an unattached content database.
Se specifică numele serverului de baze de date și numele bazei de date pe care reușit să o restaurăm.
La modul de operare putem alege:
Browse content
Backup site collection
Export site or list
Pentru a ști ce restaurăm ar fi recomandat să explorăm conținutul bazei de date înainte de operațiunea efectivă așa că în acest exemplu am ales opțiunea Browse Content și navigăm până la site-ul dorit.
Operațiunea recomandată este aceea de Export site or list pentru a putea importa apoi fișierele CMP într-un alt subsite. Partea faină a metodei este că exportă inclusiv subsite-urile și există și bifă pentru Export full security.
În pasul următor trebuie să specificăm numele fișierului CMP de pe disc în care dorim să exportăm acest site și Start Backup
Operațiunea următoare este de a crea un subsite în cadrul unei infrastructuri existente și restaurarea cu suprascriere a fișierului CMP exportat în pasul anterior.
Unul din dezavantajele acestei metode poate fi legată de pierderea metadatelor de creare a activului informațional (Data, Autorul, Editor) fiind înlocuite cu numele restauratorului și data la care s-a produs operațiunea. Dacă o restaurare s-ar produce în același domeniu Active Directory atunci există opțiuni de export Full Security. Dacă și domeniul a fost afectat atunci întreaga ierarhie de securitate este compromisă.
Restaurarea
Scriptul meu complet pentru restaurare:
<# Adaugare Snapin SharePoint in PowerShell context #>
Add-PSSnapin Microsoft.SharePoint.Powershell
<# Creare site nou intr-un webapp existent pentru restaurare
Foarte important este ca site-ul sa aiba acelasi template si pachet linvistic ca site-ul original.
Eh… cam așa ceva mi-ar fi plăcut să prezint la IT Camp-ul de luna aceasta de la Cluj. Succes tuturor prietenilor și profesioniștilor care se vor întâlni acolo. Sunt convins că va fi ceva foarte fain!
Și ca să închei în aceiași notă pașnică: Da! Poți înlocui salariații, dar este greu de acceptat să înlocuiești rigoarea, pasiunea și determinarea cu ambiție superficială. J
La finalizarea unui ciclu de studii, absolventul universității este pus în situația de a parcurge o serie de etape și procese în vederea eliberării documentelor care confirmă finalitatea studiilor.
Procesul clasic este descris schematic în figura următoare, poate provoca un zâmbet ilar, dar aceasta este doar realitatea simplificată.
Pe scurt, studentul preia de la Secretariat fișa, o completează după care se deplasează la diferite instituții din cadrul Universității, sau afiliate, pentru semnarea documentului. Văzut de cele mai multe ca o formalitate de toți actorii implicați în proces, plimbarea fișei are un aspect ironic de finețe: studentul află care ar fi fost instituțiile pe care ar fi fost bine să le viziteze în timpul studiilor.
Provocarea acestui articol este de a demonstra prin diferite metode și proceduri simple cum s-ar putea automatiza acest proces folosind tehnologia SharePoint, descriind neajunsurile fiecărei metode dar și care ar fi posibilele soluții.
Trebuie să stabilim de la început principalele limitări ale sistemului informatic universitar în care activez. Aceasta este opinie proprie și personală, asumându-mi faptul că din punct de vedere profesional pot greși în această evaluare. Ca majoritatea sistemelor informaționale mari, orice dezvoltare de fluxuri interdepartamentale este aproape imposibil de realizat în lipsa unui sistem de autentificare centralizată, în care utilizatorii să poată folosi același nume de utilizator și parolă pentru accesul la conținutul informațional instituțional.
Variantele de lucru și scurte explicații
Exclud din start varianta de a completa un template și trimiterea lui la o anumită adresă de e-mail. Se vehiculează în Universitate o formă de admitere on-line în Excel, dar pe moment prefer să nu comentez mai mult. Pentru cei care au cunoștințe mai avansate de SharePoint, nu mă refer aici la funcția de Incoming email din SharePoint configurată pe biblioteci de documente, care ar permite salvarea fișierelor atașate în acea librărie, pentru că: (1) utilizatorii externi vor ignora constant convențiile de notare ale numelor fișierelor și (2) va fi destul de greu să-i informezi despre progresul sau măcar finalitatea fluxului de semnare a documentului. (3) Nu exclud nici varianta în care unii dintre ei vor trimite mai multe emailuri pentru că nu au un feedback din sistem și nici cea în care unii nu au instalat pe calculator aplicații dedicate, gen Excel sau Word, sau nu știu să completeze într-un document Word care are câmpuri.
Varianta ideală ar fi aceea a unui formular electronic completat pe web, care să suporte semnătura electronică și să circule într-un timp relativ scurt între departamentele din cadrul instituției. Soluția ar fi utilizarea InfoPath Services cu publicare, acces și semnare direct din browser, plus un flux de notificare a utilizatorilor cu rol de semnare și verificare. Limita acestei variante, dincolo de componenta autentificării centralizate este dată de faptul că absolvenții care doresc să-și ridice actele de studii după o perioadă mai îndelungată de timp (peste 3-6 luni) nu vor mai avea active conturile de utilizator în utopicul sistem de autentificare centralizată. Mai există și problema că sistemul SharePoint, chiar cu acces anonim de Add items, nu permite adăugarea/crearea anonimă a documentelor în librăriile din site-urile publice, ci doar adăugarea de înregistrări în liste. Marele avantaj al metodei cu formularele este acea că permit semnarea electronică a formularelor, UAIC fiind una din puținele instituții de învățământ din România care pune la dispoziția utilizatorilor (profesori și administrativ) certificare digitale calificate (citiți mai multe pe pagina Departamentului de Comunicații Digitale).
Varianta cea mai plauzibilă, în contextul accesului anonim este acea a utilizării entităților de tip listă particularizată în InfoPath și cu același flux de aprobare ca la varianta cu formulare, numai că nu mai este necesară semnare ci doar feedback-ul utilizatorului consultat. S-ar putea suspecta o problemă aici, legată de securitatea procesului pentru că lipsesc semnăturile digitale. Atât timp însă cât datele de autentificare ale responsabililor nu sunt divulgate securitatea rămâne la nivelul de acceptanță al tranzacțiilor legate de acea fișă.
O scurtă analiză cu privire la definirea rolurilor
La nivelul fiecărei facultăți, în funcție de organizarea internă și de dimensiunea acesteia, pot exista secretari pentru fiecare nivel de studii, sau pe fiecare specializare, un secretar pe mai multe specializări sau un singur secretar pentru toată facultatea responsabil cu fișele de lichidare. De asemenea, pot exista mai mulți secretari pe aceeași specializare.
Tendința pare a fi aceea de a crea mai multe roluri de secretar pentru fiecare nivel, dar aceasta ar crește complexitatea gestiunii ulterioare. Având în vedere că fluxul de verificare/aprobare/semnare trebuie să facă o legătură între rolul de facultate și cel de reprezentant al acelei facultăți atunci este clar că trebuie să extindem lista de facultăți cu rolul respectiv.
Lista de facultăți este sursă de date pentru formular și în funcție de selecțiile inițiale pe care le realizează absolventul sunt preluate datele corespunzătoare în formular.
Exemplu pe lista de facultăți:
Câmpurile de secretar și bibliotecar sunt de tip People cu corespondență directă în Active Directory. Am încercat să realizez o separare pe diferite niveluri de studii la secretari pentru a nu complica foarte mult acest Demo.
O problemă specifică în fluxurile electronice este legată de inițiatorul unui flux și cine semnează ultimul. În rularea paralelă (specifică acestui flux clasic) orice din roluri poate începe semnarea, dar credem că în mod corect secretarul este responsabil de verificarea corectitudinii datelor și semnează primul, după care la final tot el este cel care ar trebui să finalizeze fluxul prin eliberarea documentelor specifice solicitate de absolvent.
Fluxul de lucru
Având în vedere că veleitățile mele de programator se rezumă la un IF-THEN-ELSE în Excel am preferat o variantă simplă a implementării prin construirea unui flux generic în mod vizual în Visio după care l-am exportat în format utilizabil în SharePoint Designer.
Pentru cunoscătorii domeniului, schema de flux nu respectă în mod fidel modelul BPMN dar permite generarea pseudocodului care va fi folosit ulterior pe partea de acțiune a procesului de semnare și validare.
Pseudocod flux generat în SharePoint Designer și particularizat după specificul activității și rolurilor definite.
Procesul de colectare feedback
Istoricul fluxului de feedback și semnare în timp real
Același flux de lucru este utilizat și în procesul de colectare feedback bazat pe liste.
Varianta cu InfoPath Services
Știu că Microsoft a anunțat că din anul 2023 (sau 2020) InfoPath nu va mai fi continuat ca produs. Dar va fi înlocuit probabil tot de aplicații de creare end-user a formularelor. Nu avem încă astfel de informații cu toate că se vehiculează tot felul de variante HTML5 cu CSS3 și JS.
Pentru a putea fi recunoscută și identificată semnătura electronică trebuie să respecte cele trei criterii de valabilitate: emis pentru, valid ca dată, emis de o autoritate de certificare autorizată. În lucrul cu departamente externe sau dacă documentul ar fi necesar să fie prezentat în afara instituției, semnăturile electronice generate de o autoritate de certificare internă nu sunt valabile.
Proces de semnare în browser este disponibil, din păcate pentru unii, doar în ultimele versiuni de Internet Explorer. Formularul se poate deschide în Chrome dar nu poate fi semnat.
Semnătura calificată aplicată pe documentul respectiv asigură din punct de vedere legal autenticitatea acelui document nemaifiind necesară aplicarea de semnături sau ștampile suplimentare.
Pentru cei care ”nu suportă” Internet Explorer pot apela la varianta de deschidere a formularului în aplicația InfoPath care face parte din anumite pachete Office.
Pentru personalizarea și filtrarea unei surse de date în InfoPath puteți consulta filmulețul:
După cum aminteam în paragrafele anterioare, varianta actuală cu șanse cât de cât de implementare, este cea a accesului anonim la completarea fișei. Fiindcă utilizatorii anonimi nu pot crea sau încărca documente pe o bibliotecă de documente, ne rămâne la dispoziție varianta listelor.
Formularul cu acces anonim:
În momentul completării se creează un nou element în lista de fișe care ar trebui să intre în procesul de verificare și aprobare asemănător fluxului prezentat anterior.
Accesul anonim la un sistem informatic și postarea unor elemente pentru declanșarea unor procese automate de aprobare, poate constitui un risc major de securitate. Lansarea unui flux de lucru presupune pe lângă drepturile de scriere a înregistrărilor în lista de bază, crearea de înregistrări în lista de task-uri asociate fluxului de lucru precum și în istoricul de execuție a acestuia. Riscul principal în acest model este dat de faptul că cineva rău intenționat ar încerca să depună un număr mare de cereri în sistem, care ar genera un flux masiv de e-mailuri către responsabilii cu verificarea și aprobarea. În același timp configurarea posibilității de adăugare a înregistrărilor în secțiunea de task-uri destinate responsabililor de verificare și aprobare ar genera de asemenea nemulțumire și încărcarea nejustificată a operațiunilor de execuție.
Tratarea acestui risc are la bază introducerea de elemente de unicitate pe formular: numărul matricol și adresa de e-mail.
Dacă am dori totuși ca utilizatorii anonimi să inițieze un flux de lucru automat, în diferite surse de pe Internet se specifică faptul că aceștia ar trebui să primească drepturi de editare pe elementele de listă, fapt care poate provoca alte probleme de securitate.
Fiind utilizatori total anonimi nu putem acorda astfel de permisiuni, chiar dacă am face limitarea accesului la vizualizarea default a elementelor. Pentru utilizatorii care intră cu user și parolă putem activa opțiunea avansată: Creare și editare pentru elementele create de utilizator, inaplicabilă anonimilor. Malformarea URL-ului unei element de listă prin modificarea ID-ului unei înregistrări oferă utilizatorului anonim acces la editarea oricărei fișe ceea ce ar compromite integritatea înregistrărilor.
Sigur, că se poate modifica din InfoPath conținutul formularului în așa fel încât datele să nu mai poată fi modificate, dar poate exista posibilitatea de a intra în Datasheet view și a depăși limitările unui form personalizat. Se poate dezactiva și această opțiune, dar rămâne deschis riscul major de a putea vedea datele personale (Nume Prenume, Data și locul nașterii, adresa de e-mail) ale tuturor celor care au depus fișe.
Verificând totuși posibilitatea de inițiere anonimă a unui flux de lucru, cu drepturi de editare pe lista inițială și drepturi de creare elemente în lista de Task-uri și cea de istoric Workflow, am constatat că SharePoint nu permite inițierea fluxurilor de semnare. Varianta de creare a fluxurilor de lucru de tip SharePoint 2010 cu funcția de impersonate activată, ar permite rularea acestor fluxuri în numele celor care le-au creat.
Singura variantă funcțională care să ofere un minim de securitate este acela de a seta fluxul de lucru pe rulare manuală și inițierea acestuia de către secretarul de facultate după ce în prealabil a verificat datele.
Alte funcționalități și configurări sunt legate de filtrarea pe listelor în așa fel încât să nu se permită vizualizarea elementelor din exterior iar fiecare secretar sau bibliotecar să poată vedea doar fișele sale.
În loc de concluzii
Vă cer părerea legată de beneficiile pe care le-ar aduce un astfel de proces automatizat, atât pentru instituție cât și pentru absolvenți.
Credeți că principalii actori instituționali vor lucra mai mult sau mai puțin pentru verificarea și semnarea documentelor?
Puteți partaja experința dumneavoastră legată de procesul clasic?
La alte universități există un astfel de proces al fișei de lichidare, offline sau automatizat?
Valy Greavu - Live Blog 