Cuprins

Introducere ......................................................................................................................................................... 6
1 Sisteme informaionale de sincronizare i organizare a fiierelor ................................................................... 8
1.1 Necesitatea sistemelor de sincronizare a fisierelor ................................................................................... 8
1.2 Sincronizarea datelor ................................................................................................................................ 8
1.3 Resursele partajate.................................................................................................................................. 10
1.4 Documentum Foundation Classes (DFC) ............................................................................................... 14
1.5 Documentum D2 .................................................................................................................................... 17
2 Descrierea funcional a aplicaiei, principalele module ............................................................................... 21
2.1 Descrierea modelului existent ................................................................................................................ 21
2.2 Necesitatea sistemului de sincronizare ................................................................................................... 21
2.3 Termeni specifici sincronizatorului ........................................................................................................ 22
2.4 Exportul entitilor ................................................................................................................................. 24
2.5 Importul entitilor ................................................................................................................................. 26
2.6 Gestionarea tergerile locale .................................................................................................................. 28
2.7 Gestionarea tergerile externe ................................................................................................................ 30
2.8 Procesul de sincronizare ......................................................................................................................... 32
2.9 Arhitectura agentului de sincronizare..................................................................................................... 33
3 Implementarea sistemului informaional de sincronizare a entitilor .......................................................... 36
3.1 Sync setul HR (Human Resources) ........................................................................................................ 36
3.1.1 Structura de foldere ......................................................................................................................... 36
3.1.2 Securitatea (grupurile i permisiunile) ............................................................................................ 37
3.1.3 Modele de date ................................................................................................................................ 38
3.1.4 Cutarea ........................................................................................................................................... 40
3.2 Strategii de implementare ....................................................................................................................... 40
3.2.1 Puncte de extindere ......................................................................................................................... 41
3.3 Adugarea unui sync set job nou la Spring Quartz ................................................................................ 46
3.4 Configurarea i implementarea sistemului informational ...................................................................... 48
3.5 Testarea produsului ................................................................................................................................ 53
3.5.1 Cutarea ........................................................................................................................................... 57
3.5.2 Cutarea avansat ............................................................................................................................ 57
3.5.3 Compararea sistemelor de sincronizare ........................................................................................... 57
3.6 Problemele aprute n timpul implementrii i soluionarea acestora .................................................... 58
3.6.1 Factori subiectivi ............................................................................................................................. 58
3.6.2 Factorii obiectivi.............................................................................................................................. 60
Concluzie.......................................................................................................................................................... 62
Bibliografie....................................................................................................................................................... 63

Introducere
Locuim ntr-o socieate n permanenta evoluie i n plin proces de adaptare i integrare n
mediul internaional. Extinderea planurilor de comunicare datorat tehnologiei avansate ne pune n
postura de a interaciona cu un volum informaional sporit, lucru care poate conduce foarte uor la
focalizarea eforturilor unei instituii aproape exclusiv pe gestionarea corecta a resurselor.
Informaia parcurge un traseu complex n interiorul societii, fiind de fapt cea mai variat
forma de schimb, ea nglobnd multiple sensuri, cu impact diferit, n funcie de perspectiva din care
este asimilat.
Competitivitatea n mediul de afaceri contemporan nseamn a controla informaia. Procesul
de comunicare a unei imagini, brand, serviciu, implic selectarea informaiei relevante, prelucrarea
i transformarea acesteia n forma finala, cea care va fi comunicat societii. Amploarea utilizrii
sistemelor informatice n mediul de afaceri contemporan se datoreaz multiplelor beneficii pe care
acestea le ofer.
Sistemele de tipul ERP (Enterprise Resource Planning), construite pe structura modulara,
integreaz o gama variata de indicatori necesari n evaluarea resurselor reale ale companiilor, cum
ar fi: gestiunea materiilor prime, a furnizorilor, dar i a aspectelor legislative, economico-financiare
i a celor de marketing.
Controlul tuturor proceselor implicate n activitatea unei firme amplific ansele de
poziionare optim n piaa de consum vizat, contribuind activ la dezvoltarea companiei. Punctul
central al demersurilor de mbuntire permanent a produselor i serviciilor l constituie
satisfacerea clientului, anticiparea dorinelor acestuia. Societatea actuala determina o ampl
diversitate n opiuni, determinat de un ritm accelerat al schimbrii. De aceea, adaptarea la
schimbare este o calitate numai n condiiile n care se realizeaz n timp util. Din considerente
induse de ritmul competiional susinut, companiile utilizeaz n prezent sisteme informatice de
tipul CRM (Customer Relationship Management). Cu ajutorul acestora putem realiza o comunicare
mult mai eficienta cu segmentul de consumatori crora ne adresam direct.
In prezent, tehnologia este factorul decisiv pentru consolidarea relaiilor inter umane datorita
atributelor sale incontestabile: circuitul informaional se integreaz intr-un mediu extrem de flexibil,
ce permite interaciunea pe multiple planuri, n timp foarte scurt.
Impactul este msurabil n definirea a doua dintre cele mai utilizate strategii de abordare a
afacerilor: B2B (Business to Business) i B2C (Business to Customer).
n era informaiei, utilizarea sistemelor de file sharing se impune deja ca un element de baz
iar pastrarea documentelor n cloud este ceva firesc. Pentru acestea, devine important s gseasc

soluii eficiente de reducere a timpului alocat unor activiti consumatoare de timp, dar lipsite de
valoare adugat.
Pstrarea n siguran a documentelor confideniale i eliminarea riscului de pierdere a
acestora sunt considerate cele mai importante beneficii asociate utilizrii documentelor n format
electronic. Alturi de acestea, accesul simultan la documentele originale reprezint, n concepia
companiilor respondente, un alt argument semnificativ n favoarea utilizrii unei arhive electronice.
Un sistem de management a coninutului ofer ordine asupra informaiei nestructurat. Un
asemenea sistem gestioneaz crearea, gestionarea, procesarea, distribuirea i arhivarea oricrui tip
de coninut n legtur cu business logica definit de utilizator. Sistemul stabilete legaturile dintre
buci de coninut, permind aceluiai coninut s fie utilizat n diferite contexte i rendiii. El
adaug inteligen, scheme categorizate la creare, i metadate care fac cutarea i extragerea mai
rapid i mai eficient. Poate automatiza procesarea contentului prin cicluri de via. Poate facilita
publicarea coninutului prin mai multe canale cum ar fi publicarea pe un site Web, transfer la fax,
printarea ca document text sau transfer ctre un dispozitiv fr cablu. Sistemele de acest tip
promoveaz integrarea ntre sisteme sau departamente care conlucreaz.
Aplicaiile pentru lucru cu coninutul sunt acele aplicaii care utilizeaz coninutul n-e
structurat cum ar fi documente, imagini, email-uri, pagini web. Rangul aplicaiilor care utilizeaz
coninut n-e structurat este foarte mare n comparaie cu aplicaiile care utilizeaz baze de date
pentru managementul datelor structurate.

1 Sisteme informaionale de sincronizare i organizare a fiierelor

1.1 Necesitatea sistemelor de sincronizare a fisierelor

Sincronizarea fiierelor electronice, este procesul care asigura ca fiierele n dou i mai
multe locatii sunt updatate prin anumite reguli. n anumite cazuri sincronizarea de fiiere mai este
numit i mirroring, fiierele updatate sunt copiate dintr-o locaie surs ctre o alta locaie
destinatie fara a fi copiate careva fiiere napoi la surs. O alt definiie pentru sincronizarea de
fiiere este c fiierele sunt copiate n ambele direcii deobicei cu scopul de a tine ambele locaii
identice unul cu cellalt.
Sincronizarea de fiiere este utilizat de multe ori pentru crearea de backup-uri pe un hard
disk extern sau updatarea unui USB flash drive. Procesul automat previne copierea multipl a
fiierelor deja existente identice i astfel poate fi mult mai rapid i poate evita pierderile de timp n
comparaie cu copierea manual, care poate produce o multime de erori. Fiierele pot suferi
modificri i astfel trebuie creat o noua versiune a fiierului dar trebuie s tinem cont c copierea
multipl a versiunilor ar putea s nu mai ncap ntr-un dispozitiv portabil. Aici apare necesitatea
unor software-uri care s memoreze doar lista de fisiere i lista de modificri fcute sau lista de
fisiere sterse. O astfel de abordare este util n cazul lucrului pe dispozitive mobile sau pe mai multe
calculatoare, facnd posibil sincronizarea multipl a locaiilor prin sincronizarea fiierelor n
perechi i n acelai timp.[1]

1.2 Sincronizarea datelor

Sincronizarea datelor este procesul de stabilire a consistenei ntre datele de la surs la
destinaia de stocare a datelor i invers, pentru a crea o armonie continu ntre date n timp.
Sincronizarea datelor este fundamental pentru o varietate larg de aplicaii, inclusiv sinchronizarea
de fiiere i sincronizarea dintre dispozitivele mobil.[2]
1.2.1 Soluii bazate pe fiier
Exist instrumente disponibile pentru sincronizarea fiierelor, control al versiunilor (CVS,
Subversion, etc.), sisteme de fisiere distribuite (Coda, etc. ), i de mirroring (rsync, etc. ), n care
toate acestea ncearc s pstreze seturi de fiiere sincronizate. Cu toate acestea, doar controlul de
versiuni i instrumente de sincronizare a fisierelor pot gestiona modificrile la mai mult de o copie a
fiierelor.
a) Sincronizarea de fiiere este frecvent utilizat pentru a crea backup pe hard disk-uri externe
sau actualizarea pentru transport pe memorii flash USB. Procesul automat previne copierea
8

fiierelor deja identice, astfel se economiseste timp considerabil n raport cu o copie manual,
de asemenea, fiind mai rapid i mai puin predispus la erori.
b) Instrumentele de control a versiunii sunt destinate pentru a face fa situaiilor n care mai
mult de un utilizator ncearc s modifice simultan acelai fiier, n timp ce sincronizatoarele
de fiiere sunt optimizate pentru situaii n cazul n care doar o singura copie a fiierului va
fi editat ntr-un moment. Din acest motiv, dei instrumentele de control a versiunii pot fi
folosit pentru sincronizarea de fiiere, pentru astfel de operaiuni se utilizeaz instrumente
dedicate.
c) Sistemele de fiiere distribuite de asemenea, pot fi utilizate deasemenea pentru a asigura
sincronizarea mai multor versiuni a unui fiier sincronizat. Acest lucru necesit n mod
normal ca dispozitivele de stocare a fiierelor s fie ntotdeauna conectate, dar unele sisteme
de fiiere distribuite ca Coda permit operarea deconectat urmat de reconcilieri. Facilitile
care fuzioneaz un sistem de fiiere distribuite sunt de obicei mai limitate dect cele ale unui
sistem de control al versiunilor, deoarece majoritatea sistemelor de fiiere nu ine un grafic
de versiunea.
d) Mirroring este o copie exact a unui set de date. Pe internet, un site oglind este o copie
exact a unui alt site de pe internet. Oglinda site-urilor sunt cel mai frecvent utilizate pentru
a oferi mai multe surse de aceeai informaie, i au o valoare deosebit ca o modalitate de a
furniza acces fiabil la volume mari de descrcri.
Sincronizarea poate fi de asemenea util n criptare pentru sincronizare ntre servere a cheilor
publice.[2]

1.2.2 Modele teoretice

Exist mai multe modele teoretice de sincronizare a datelor n literatura de specialitate, iar
problema este, legat de problema Slepian-Wolf codificare n teoria informaiei. Modelele sunt
clasificate n funcie de cum ele considera datele de a fi sincronizate.[2]
a) Date neordonate
Problema de sincronizare a datelor neordonate (de asemenea cunoscut ca set reconciliation
problem) este modelat prin formula (1.1) ca o ncercare de a calcula diferena simetric
(1.1)
dintre dou seturi la distana

a unui numar de b-bit. Unele soluii a aceastei probleme este

caracterizat prin:
1. Transferul masiv n acest caz toate datele sunt transferate gramad pentru o comparaie
local.
9

2. Sincronizarea cu timestamp n acest caz toate modificrile datelor sunt marcate cu

timestamp. Sincronizare incepe prin transferul datelor cu un timestamp urmtor.
3. Sincronizarea matematica n acest caz, datele sunt tratate ca obiecte matematice i
sincronizare corespunde unui proces matematic
b) Date ordonate

n acest caz, dou iruri de la distan

trebuie s fie reconciliate. De obicei, se

presupune c aceste iruri de caractere difer cu un anumit numr de modificri (caracterul inserri,
tergeri sau modificrii). Sincronizarea datelor const n procesul de reducere i edita distana ntre
i

, la distana ideal de zero. Acest lucru se aplic n toate sincronizrile pe baz de fiiere

(n cazul n care datele sunt comandate). Multe aplicaii practice n acest sens sunt discutate sau
menionat mai sus.
Uneori este posibil de a transforma problema la una dintre datele neordonate printr-un
proces cunoscut sub numele de shingling (impartirea sirurilor de caractere n zona zoster).[2]

1.3 Resursele partajate

n calcul, o resurs partajat sau partajarea pe reea poate fi un dispozitiv sau o careva
informaie de pe un computer care pot fi accesate la distan de pe alt computer, de obicei printr-o
reea local sau Intranet, transparent ca n cazul n care ar fi fost o resurs pe maina local.
Exemple ar fi accesul la fiiere partajate (cunoscut ca schimbul de foldere sau disc partajat),
acces la imprimant partajat (partajarea imprimantei), acces la scanerul partajat, etc. Resurs
partajat este numit un disc partajat (de asemenea cunoscut sub numele de disc montat), drive
volum partajat, folder partajat, document partajat, printer partajat sau scaner partajat.
Termenul de partajare a fiierelor n mod tradiional nseamn acces la fiiere, n special n
contextul sistemelor de operare i servicii LAN sau Intranet, de exemplu n documentaia Microsoft
Windows. Cum ar fi BitTorrent i aplicaii similare au devenit disponibile la nceputul anilor 2000,
termenul de fiier partajat a devenit asociat cu partajarea de fiiere peer-to-peer de pe Internet.[3]
1.3.1 Sisteme de fiiere i protocoale
Fiierele partajate i accesul la printer necesit un sistem de operare pe client care suporta
accesul la resursele de pe un server, un sistem de operare de pe server care accept accesul la
resursele sale la un client, i o aplicatie de interactiune (n patru sau cinci nivele modelul TCP/IP)
protocol de partajare a fiierelor i protocolul de transport s se ofere acces. Sistemele moderne de
operare pentru calculatoare personale includ sisteme de distribuie a fiierelor care accept

10

partajarea de fiiere, n timp ce dispozitive de calcul necesit uneori software suplimentare pentru
accesul la fiiere partajate.[3]
Cele mai frecvente sisteme de operare i protocoalele utilzate sunt prezentate n tabelul 1.1:
Tabelul 1.1: Sistemele de operare i protocoalele utilizate.[3]
Sistemul de operare de baza

Protocolul de aplicaie

Protocolul de transport
TCP,

Mac OS

Apple Filing Protocol

UDP or
AppleTalk

Unix-like systems

Network File System (NFS)

TCP or
UDP
TCP,

MS-DOS, Windows

SMB, also known as CIFS

NBT (includes UDP),

NBF, or
other NetBIOS transports

Novell NetWare (server)

NCP and

SPX (over IPX), or

MS-DOS, Windows (client)

SAP

TCP

Un pool de resurse este mai uor de a administra persoanele sau echipamentele atribuite
sarcinilor n mai multe fiiere ale proiectului. Resursele disponibile centralizeaz informaii despre
resurse, precum numele resursei, calendarul folosit, uniti de resurse, i tabele a ratei de cost.
"Sistemul de operare de baz" este sistemul de operare pe care protocolul de partajare a
fiierelor este cel mai frecvent utilizate.
Pe sistemul de operare Microsoft Windows, partajarea pe reea este oferita de componenta
de reea Windows "File and Printer Sharing for Microsoft Networks", utiliznd protocolul
Microsoft SMB (Server Message Block). Alte sisteme de operare, de asemenea, ar putea pune n
aplicare acest protocol; de exemplu, Samba este un server SMB care ruleaz pe sisteme de operare
Unix-like i alte sisteme de operare non-MS-DOS/non-Windows cum ar fi OpenVMS. Samba poate
fi folosit pentru a crea partajri pe retea care pot fi accesate folosind SMB, la computere care
ruleaza Microsoft Windows. O abordare alternativ este un sistem de fiiere partajate pe disc, n
cazul n care fiecare computer are acces la sistemul de fiiere "nativ" pe un disk partajat.
Acces la resursele partajate, de asemenea, pot fi implementate pe baza a Web-based
Distributed Authoring and Versioning (WebDAV).[3]
11

1.3.2 Convenie de nume i maparea

Partajarea poate fi accesat de ctre client prin anumite convenii de nume, precum UNC
(Universal Naming Convention) utilizat pe DOS i pe calculatoarele Windows PC. Acest lucru
implic faptul c o partajare de reea poate fi abordate n funcie de urmtoarea structur:
\\ServerComputerName\ShareName
unde ServerComputerName este numele de WINS, numele DNS sau adresa IP a
computerului server, i ShareName care poate fi un folder sau fisier sau calea sa. Folderul partajat,
de asemenea poate fi dat de un SharedName care este diferit de numele folderului local pe partea
de server. De exemplu \\server\c$, de obicei, indic o unitate cu C: pe o main Windows.
Un drive partajat sau un folder este adesea mapat la client pe calculator, ceea ce nseamn c
se atribuie o liter de unitate pe computerul local PC. De exemplu, litera de unitate H: este de obicei
folosit pentru directorul home al utilizatorului pe un server de fiiere central.[3]

1.3.3 Probleme de securitate

O partajare de reea poate deveni o obligaie de securitate atunci cnd accesul la fiierele
partajate este primit (de multe ori prin devieri) de ctre cei care nu ar trebui s aib acces la ele. Mai
muli viermi de calculator s-au rspndit prin retea. Partajarile prin reea ar consuma capacitai
extinse mai mari la comunicare prin reteaua de non-broadband network. Din aceasta cauza, este
interzis accesul partajat la imprimant i fiiere de acces n firewall-uri la calculatoare din afara
reelei local sau Intreprinderii. Cu toate acestea, prin reele private virtuale (VPN), resursele
partajate pot fi facute disponibile pentru utilizatorii cu certificate n afara reelei locale.
O partajare de reea este de obicei accesibile altor utilizatori pentru a marca orice folder sau
fiier ca partajate sau de a schimba permisiunile de sistem la fiiere sau drepturi de acces n
proprietile folderului. De exemplu, un fiier sau un folder poate fi accesibile numai unui utilizator
(proprietarul), pentru administratorii de sistem, la un anumit grup de utilizatori sau publice pentru
toi utilizatorii autentificai. Procedura exact variaz n funcie de platforma.
n sistemul de operare ediii home si small office, exista un folder special pre-shared folder
care este accesibil pentru toti utilizatorii cu un cont de utilizator i o parol pe computerul local.
Acces la dosarul de pre-shared folder poate fi pornit. n sistemul de operare Windows XP Home
Edition, versiunea n limba englez, dosarul pre-shared folder este numit Shared Documents, de
obicei cu calea C:\Documents and Settings\All users\Shared documents. n Windows Vista i
Windows 7, dosarul pre-shared folder este numit public documents, de obicei cu calea
C:\Users\Public\Public documents.[3]

12

1.3.4 Topologia de work group sau server centralizat

n reelele home sau small ofice, o abordare descentralizat este adesea folosit, n cazul n
care fiecare utilizator poate face foldere locale i imprimante disponibile altora. Aceast abordare
este uneori, notat ca un work group sau topologia de reea peer-to-peer, deoarece acelai computer
poate fi utilizat ca client, ct i server.
n reelele de ntreprindere mari este de obicei folosit un fiier centralizat server sau server
de imprimare, client-server, uneori notate cu paradigma. Un proces al clientului pe computerul
utilizatorilor locali ia iniiativa de a ncepe comunicarea, n timp ce un proces de server de pe server
de fiiere sau server de imprimare remote, calculator pasiv asteapta cererile pentru a ncepe o
sesiune de comunicare n reele foarte mari. Stocare online pe un server n afara reelei locale n
prezent este o opiune, mai ales pentru home sau small office.[3]
1.3.5 Diferene ntre transferurile de fiiere
Accesul la fiiere partajate nu trebuie confundat cu transfer de fiiere folosind protocolul de
transfer fiier (FTP), sau protocolul Bluetooth sau IRDA de obiect (OBEX). Acces partajat implic
sincronizarea automat de dosar informaii ori de cte ori un folder este schimbat pe server, i poate
oferi partea de server fiier cutarea, n timp ce transferul de fiiere este un serviciu mai rudimentar.
Accesul la fiiere partajate n mod normal, este considerat ca un serviciu de reea local
(LAN), n timp ce FTP este un serviciu Internet.
Accesul la fiiere partajate este transparent pentru utilizator, ca n cazul n care acesta a fost
o resurs n sistemul de fiiere local, i sprijin un mediu multi-utilizator. Aceasta include controlul
concurenei sau de blocare a unui fiier la distan n timp ce un utilizator este de editare, i de
permisiunile de sistem de fiiere.[3]
1.3.6 Diferene ntre sincronizri
Accesul la fiiere partajate implic dar nu trebuie sa fie confundat cu sincronizarea de fiiere
i alte sincronizari de informaie. Sincronizrile de informatii bazate pe Internet de exemplu
limbajul SyncML. Accesul la fiiere partajate se bazeaz pe pushing de informaii pliant e la server,
i este utilizat de obicei prin un socket Internet "always on". Sincronizare fiierelor permite
utilizatorului de a fi deconectat din cnd n cnd, i n mod normal, se bazeaz pe un agent software
care interogheaz mainile la reconectare, i, uneori, n mod repetat cu un anumit interval de timp,
s descopere diferenele. Sistemele de operare moderne includ adesea un cache local de fiiere la
distan, care permite acces offline i sincronizare atunci cnd se face reconectarea.[3]

13

1.4 Documentum Foundation Classes (DFC)

1.4.1 Ce este DFC?
DFC este o parte esenial a platformei software Documentum. O dat ce utilizatorul de
baz a DFC este un alt software Documentum, DFC poate fi utilizat n oricare dintre urmtoarele
cazuri:
a) Pentru a accesa funcionalitatea Documentum din una din aplicaiile enterprise ale
companiei.
De exemplu, o aplicaie corporativ de cumprare poate extrage un contract din sistemul
Documentum.
b) Pentru a personaliza sau extinde produse cum ar fi Documentum Desktop sau Webtop.
De exemplu, avnd posibilitatea de a modifica funcionalitile Webtop pentru a implementa
una din bussines regulile compania.
c) Pentru a scrie o metod sau o procedur pentru Content Server ca s execute o parte dintr-un
workflow sau lifecycle a unui document
De exemplu, procedura care se execut atunci cnd se nainteaz un document XML ar
putea accepta o transformare pentru a porni un workflow la subiectul documentului transformat la
un bussines process predefinit.[4]
Funcionalitile Documentum pot fi vazute avnd elementele din tabela 1.2:
Tabela 1.2: Elementele Documentum necesare funcionarii.
Repositories

Unul sau mai multe locaii unde poate fi pstrat coninutul i metadatele asociate
unei companii. Metadatele se pastreaz ntr-o baz de date relaional, i
coninutul se afl pe diverse elemente de stocare.

Content

Software-ul care gestioneaz, protejeaz i impune o structura obiect orientat

Server

asupra informaiei din repozitoriu. Acesta ofer instrumente intrinseci pentru

gestionarea ciclurilor de via a informaiei i automatizarea proceselor de
manipularea.

Client

Software-ul care ofer interfee ntre Content Server i utilizatorii finali. Cei mai

programs

muli clieni lucreaza pe application server (de exemplu, Webtop) sau pe

computerele personale (de exemplu, Desktop).

End Users

Oameni care controleaza, contribuie, sau utilizeaz informatia dintr-o

organizatie. Ei folosesc un browser pentru a accesa programele client care
ruleaz pe servere de aplicaii, sau utilizeaz interfaia utilizatorilor, integrant a
unui program de client care ruleaz pe computerul lor personale
14

Sub aceast forma funcionalitile Documentum Foundation Classes (DFC) fac legatura
ntre Content Server i clieni. Documentum Foundation Services sunt interfeele client de baza ale
platformei Documentum. Documentum Foundation Classes sunt folosite pentru server side bussines
logic i costumizri.
DFC este bazat pe Java. Prin urmare, programele clientului care sunt bazate pe Java pot
interera direct cu DFC.
Cnd dezvoltatorii de aplicaii utilizeaz DFC, de obicei se face n cadrul modelului de
personalizare a clientului Documentum, dei este posibil de a utiliza DFC pentru a dezvolta metode
asociate cu funcionalitate a Content cum ar fi ciclurile de via al documentelor.
n mediul de aplicaii server Java, software-ul client Documentum se st la temelia oferit[ de
Web Development Kit (WDK). n mediul calculatoarelor personale Microsoft, multi clienti folosesc
Documentum Desktop, o integrare cu Windows Explorer. Fiecare dintre acesti clienti are un model
de personalizare, care permite de a fi modificat interfaa cu utilizatorul i, de asemenea, pune n
aplicare logica de afaceri. Cu toate acestea, instrumentul principal pentru adugarea de logica de
afaceri personalizate pentru un sistem de Documentum este de a utiliza Business Object Framework
(BOF).[4]
BOF permite de a incorpora regulile de afaceri i modele n elemente reutilizabile, numit
module. Cele mai importante module pentru dezvoltatorii de aplicaii sunt obiecte de tip pe baza
(TBOs) i servicii bazate pe obiecte (SBOs). BOF face posibil s se extind unele dintre clasele de
implementare DFC. Ca rezultat, poatefi introdus o nou funcionalitate n aa fel nct programele
existente sa ramna ne modificate ncepnd imediat s ofere noua funcionalitate. Aspect modulele
sunt similare cu TBO-urile, dar v permite s ataai proprietile i comportamentul pe o baz
instancebyinstance, independent de tipul de obiect.
DFC ofer un framework pentru accesarea a acestor capaciti. Folosind acest framework
codul este mult mai probabil ca sa fie utilizat pe viitor pentru si n alte arhitecturi si sisteme
Documentum.[4]

1.4.2 Unde este DFC?

DFC ruleaza pe Java virtual machine (JVM), care poate fi pe:
a) main care ruleaz Content Serveru-ul.
De exemplu, poate fi chemat dintr-o metoda ca parte a unui workflow sau ciclu de via a
unui document.
b) Un sistem middletier.

15

De exemplu, pe un server de aplicaie pentru a suporta WDK sau pentru a executa metode
de la server.
Pentru maini de client, Documentum 6 acum ofer Documentum Foundation Services
(DFS) ca suport principal pentru aplicaiile ce comunic cu platforma Documentum.
Referitor la lansare DFC pentru versiuni de suport a JVM, acestea se pot schimba de la o
versiune minor la urmtoarea.[4]

1.4.3 Modelul client-server

Arhitectura Documentum este de tip client/server. Programele DFC de baz sunt programele
client, chiar dac acestea ruleaz pe aceeai main ca un Documentum server. DFC ncapsuleaz
funcionalitile de client n interfaa IDfClient, care servete ca punct de intrare pentru codul DFC.
IDfClient se ocup de detaliile de baz pentru conectare la serverele Documentum.
Un obiect IDfClient poate fi obinut prin chemarea metodei statice a DfClientX.
getLocalClient(). Un obiect IDfSession reprezint o conexiune cu serverul Documentum si
furnizeaza servicii legate de aceast sesiune. Programatorii DFC creeaz obiecte noi Documentum
sau obin referine la obiectele deja existente n Documentum prin metodele IDfSession.
Pentru a obine o sesiune, trebuie de creat un obiect IDfSessionManager prin IDfClient.
newSessionManager(). Apoi, se ia sesiunea de la managerul de sesiune.[4]
1.4.4 Fiierul de configurare dfc.properties
Comportamentul DFC poate fi modificat prin modificarea proprietilor din fiierul
dfc.properties care conine proprieti compatibile cu clasa java.util.Properties.
Fiierul dfc.properties permite de a seta proprietile de gestionare cu DFC n timpul
execuiei. Fiierul dfcfull.properties conine documentaie pentru toate proprietile recunoscute de
DFC i modificrile care pot fi fcute asupra acestora. Fiierul dfcfull.properties nu trebuie
modificat, este posibil doar de a copia pri din acesta de care avem nevoie [4]
Instalare DFC creeaz un fiier simplu dfc.properties i l plaseaz n classpath. Alte
instalatori EMC pentru produsele cu pachete DFC, de asemenea, creaz fiierul dfc.properties n
class path-ul corespunztor. Fi;ierul dfc.properties trebuie s includ obligator urmtoarele entiti:
dfc.docbroker.host[0]
dfc.globalregistry.repository
dfc.globalregistry.username
dfc.globalregistry.password

16

1.5 Documentum D2
1.5.1 D2 Client Architecture
Acest paragraf descrie arhitectura D2 UI, configurare UI-ului, componentele server
instalatepe un Documentum Content Server. Aplicaiile D2 poate fi descriese prin 3 niveluri, aa
cum este n figura 1.1.

Figura 1.1. Arhitectura clientului D2.[5]

Browser Layer
D2 este o aplicaie browser web 2.0 ca i alte aplicaii client web-based, utilizatorii finali D2
interacioneaz cu produsul prin pornirea browser-ului de dorina lor, navigarea ctre URL-ul
aplicaiei D2 i logare n aplicaie.
Cu toate acestea, exist cteva caracteristici distinctive logicii clientului D2ce trebuie
remarcate:
a) GWT/GXT based: D2 utilizeaz Sencha GXT i Google Web Toolkit (GWT) pentru a
gestiona client JavaScript. Ca urmare, marea majoritate a codului clientului este scris n Java, i
compilate n JavaScript "permutare", care este livrat la browser-ul ntr-un singur fiier mare. Ca un
rezultat, clientul JavaScript este livrat obfuscat, i nu este uor extensibil sau debuggable fr codul
surs original.
b) Single Page: ca i muli ali clienti web 2.0, D2 este ncrcat ntr-o singur pagin
HTML, i nu se pleac de la aceast pagin pn cnd nu nchidem aplicaia. Motivul principal este
faptul c de fiecare dat cnd pagina se ncrc, tot client JavaScript, de asemenea, trebuie s fie
17

interpretat i ncrcat n memoria browser-ului. Pentru o aplicatie complexa, precum D2, aceasta ia
o cantitate semnificativ de timp pentru procesor. Dar este mult mai rapid dect trecerea de la o
pagina HTML la alta, D2 manipuleaza HTML DOM pentru a elimina pri ale UI-ului i nlocuii-le
cu piese noi. Rezultatul final este c se poate menine o aplicaie mai bogat, pentru c nu este nevoie
de a reconstrui ntregul UI la fiecare navigare.
c) GWT RPC comunication: orice comunicare ntre clientul browser-ului i aplicaia D2 este
realizat prin intermediul standard-ului de cereri HTTP, i unele dintre aceste cereri sunt cereri
simple pentru resurse statice (eg. imagini, script-uri statice, CSS, etc. ). Majoritatea schimburilor
ntre client i aplicarea, sunt prin apeluri GWT RPC pentru a prelua date dinamice, de obicei,
susinute de stratul de servicii D2FS. GWT RPC este un strat triaj GWT care permite codului
generat de clientul JavaScript sa fac apeluri de procedur la distan la codul Java care ruleaz pe
server. Clienii care monitorizeaz traficul web ntre browser i serverul de aplicaii vor observa c
ncrctura util de date pentru aceste apeluri nu este nici XML nici JSON, ci mai degrab o
legtur de protocol specific pentru GWT RPC care sunt greu de analizat.[5]

Application Server layer (D2.war)

D2 este mpachetat ntr-un fiier war, i pot fi deploy-ate pe mai multe servere de aplicaii
J2EE (Apache Tomcat, Oracle Weblogic, etc.) Dei este mpachetat ntr-o singur aplicaie web, D2
este mprit n 2 pri majore:
a) The D2 web application include mai mult logica de prezentare, inclusiv bibliotecile
GWT i GXT, controale UI personalizate, resurse web statice i servicii directe pentru a permite
browser-ului client s invoce servicii D2FS prin intermediul GWT RPC. Acest nivel nu are legtur
cu bibliotecile client Documentum DFC sau DFS de comunicare ntre D2 i repozitoriul
Documentum ce comunic prin interfaa D2FS.
b) The D2FS library include toat bussines logica pentru aplicaia D2. Aceasta include toat
comunicare cu Documentum Content Server-ul (prin DFS i DFC), i toat logica pentru a
interpreta configurrile D2 i aplicarea lor la regulile de la server. D2FS este, de asemenea, expus
ca un set de servicii SOAP n aplicaia D2.[5]

Content Server Layer

D2 instalarea include trei fiiere DAR:
a) D2-DAR.dar include majoritatea tipurilor Documentum necesare pentru a stoca obiecte de
configurare n repozitoriu Documentum. Toate tipurile de configurare sunt subtipuri de
d2_module_config sau d2_moduledoc_config, n funcie dac configuraia este stocat ca obiect de
18

metadate sau ca xml content. Tipul acesta din urm este utilizat n principal pentru a reprezenta
formele, dialoguri, e-mail template-uri sau alt continut structurat, n cazul n care un set de atribute
se repet nu este suficient pentru a reprezenta configurare.
b) D2Widget-DAR.dar include noi tipuri de configurare legate de generaie 4.x a D2 UI. De
exemplu, tipuri de configurare pentru widget-uri, machete pentru spaiu de lucru i teme, toate
acestea sunt incluse n D2Widget-DAR.dar.
c) Collaboration_Services.dar ofer tipuri i BOF module pentru capabilitile de colaborare
Documentum. D2 necesit acest fiier DAR pentru a activa capaciti comentate n clientul D2.[5]

File Transfer D2 Java applet and D2-Bocs

Transferul de coninut a fiierului ntre clientul browser i aplicaia D2 este oarecum mai
complex dect conexiunile obinuite pe care le facem la serverul de aplicaie. Pentru transferul de
coninut, D2 se bazeaz pe un applet Java. Acest lucru ofer mai multe avantaje fa de standardul
HTML4 <fileinput> controlul de formulare, i include incrcarea de fiiere multipl, ncrcarea
folderului intreg, drag-in sau fiiere de pe desktop i compresie datelor nainte de a fi ncrcate.
n instalaiile de baz, n cazul n care majoritatea utilizatorilor sunt n imediata propiere
geografic, D2 applet-ul se conecteaza direct napoi la cererea D2 utiliznd o conexiune HTTP
standard. Cu toate acestea, atunci este necesar de a face cache la Documentum BOCS pentru a
accelera transferul de fiiere mari pentru utilizatorii ce se afl n locuri ndeprtate. D2-BOCS
servete pentru dou scopuri principale:
a) Faciliteaz comunicarea dintre D2 applet-ul i cache-ul BOCS
b) D2 ofer o oportunitate de a manipula coninutul de pe direct din repozitoriu. Acest lucru
este necesar, de exemplu, cnd C2 plug-in-ul este folosit pentru a plasa configurare de baz, sau
plug-in-ul O2 care este utilizat pentru a seta proprietile document MS Office bazate pe atributele
obiectului Documentum.[5]

1.5.2 D2-Config
Arhitectura pentru D2-Config client-ul de configurare care difer n mod semnificativ de cea
a clientului D2 UI. n timp ce D2-Config este, de asemenea, un client web 2.0 care ruleaz pe un
browser i un server de aplicaii, este bazat pe arhitectura mai veche D2 3.x. Mai degrab dect s
foloseasc GXT pentru a genera UI ntr-un HTML, UI este distribuit catre browser n form de
XML, iar runtime-ul D2-Config utilizeaz transformrii XSL ca s transforma acel XML n
HTML/JavaScript UI.[5]

19

n figura 1.2 este reprezentat arhitectura clientului D2-config.

Figura 1.2. Arhitectura D2-Config.[5]

O alta diferenta remarcabil dintre D2-Config i clientul D2 3.1 se bazeaza pe un control
ActiveX asupra browser-ulul de la client, i astfel poate fi lansat doar din browser-ul Internet
Explorer.[5]

20

2 Descrierea funcional a aplicaiei, principalele module

2.1 Descrierea modelului existent

n prezent arhitectura pe care o are compania Saipem ECM (Enterprise Content Management)
este ca n figura 2.1. Putem vedea c are o topologie distribuit global, care include repozitorii
ndeprtate unul de altul. Se pot ntmpla cazuri de pierdere a legturii una cu alta din motive
climaterice, tehnice sau oricare obstacol ce ar putea aprea n calea comunicrii externe.

Figura 2.1. Reprezentarea distribuit a repozitoriilor.

O data cu existena unei astfel de topologii apare necesitate de a interaciona i de a face
schimb de informatii prin intermediul unei reele corporative WAN. O astfel de arhitectur necesit
un instrument care s fac legtur ntre acestea i s sincronizeze anumite business obiecte.

2.2 Necesitatea sistemului de sincronizare

Indiferent de tipul de informaie care trebuie sincronizat, apare necesitatea ca anumite
business obiecte dintr-un repozitoriu s fie copiate i n altele. n caz c dintr-un repozitoriu sunt
terse careva business obiecte trebuie s fie terse i din celelalte.
Acest proces poate fi fcut manual prin nserarea documentelor de ctre o persoan n fiecare
baz de documente dar desigur acest lucru nu este eficient i nu asigur nimeni integritatea i
autenticitatea datelor. Astfel apare necesitatea unui serviciu de sincronizarea care ar monitoriza
toate modificarile din repozitoriu i n cazul apariiei locale a unor business obiecte care se includ
intr-un anumit sync set s se exporte atit metadatele care descriu cmpurile i business logica unui
business obiect ct i coninutul cel mai recent al documentelor sau rendiiile fiecrui document.
21

Este necesar ca sistemul informaional s aiba grija de un set de operaiuni asupra business
obiectelor din repozitoriu:
a) Detectarea datelor noi care trebuie sa fie transferate la sistemele ndepartate;
b) Prepararea datelor pentru transfer;
c) Transferarea datelor la sistemele ndeprtate;
d) Importarea datelor n sistemele ndeprtate, aplicarea oricrei business logici necesara;
Principalele funcionaliti de care trebuie s rspund sincronizatorul sunt prezentate n
figura 2.2.

Figura 2.2. Principalele responsabiliti ale sincronizatorului.

2.3 Termeni specifici sincronizatorului

2.3.1 Business obiect
Sistemul de sincronizare trebuie s lucreze cu business obiecte Documentum. Un business
obiect este un set de obiecte compus din obiecte Documentum simple, care au o business logic
bine definit i care trebuie tratate ca o entitate atomic.
Fiecare caz de business obiect va descrie propria business logic, va avea propria structur
de date i propria compoziie.

2.3.2 OfflineCopy
Pentru a sincroniza mai multe sisteme Documentum, business obiectele din baza de
documente vor fi transformate n obiecte file system pentru a fi mai comod de transferat prin
reeaua internet. Dupa aceasta urmeaz a fi importate n bazele de documente din aceste systeme.
22

Reprezentarea file system a business obiectelor poate fi implementat n urmtoarele doua

modaliti:
a) Pachete: un pachet ZIP care conine toate documentele i XML descriptorul din care
business obiectul va fi reconstruit;
b) XML-ul i documentele separate: un XML descriptor care are referin la fiierele cu
coninut. Abordarea este similar procesului anterior cu excepia c nu exist compresie ZIP
iar transferul se petrece separat pentru fiecare document. Acest mod permite optimizri ale
transferului atunci cnd business obiectul este alctuit din mai multe documente iar
modificrile sunt necesare doar pentru a updata metadatele sau unul din documente;
Soluia de sincronizare trebuie s implementeze ambele abordri iar sync setul s fie
configurabil de a defini care metoda este preferabil. Un singur sync set nu poate utiliza ambele
metode n acelai timp.
Un folder offline este reprezentarea file system a tuturor business obiectelor definite pe un
sync set. Fiecare sync set va avea propriul folder offline.
Folderul offline are nevoie de o tabel ntr-o baz de date care va fi numit pe viitor
registru. Acest tabel va conine o nregistrare pentru fiecare business obiect prezent pe folderul
offline. O relaie unu la unu ntre registru i reprezentarea file system trebuie s fie asigurat. Tabela
poate fi o tabel standard creat n instana local a bazei de documente.

2.3.3 Sync Set

Pentru fiecare caz, sync setul va defini criterii de a identifica care business obiecte trebuie
sincronizate. Un sync set va fi implementat ca un obiect configurabil i va specifica urmatoarele
informaii:
a) Un nume i o descriere pentru a putea fi identificat;
b) Criterii de a identifica business obiecte cum ar (TBD - care trebuie s includ cel puin DQL
format, versiune, filtre);
c) Unul sau mai multe plugin-uri de filtre care pot fi folosite pentru a costumiza
comportamentul la starea de identifiacare;
d) O locatie de sincronizare (Folderul Syncplicity);
e) Un cont de sincronizare (n cazul Syncplicity, un set de credeniale valide pentru logare);

2.3.4 GUID
Un business obiect care este sincronizat pe baze de documente diferite i care trebuie s
menin o proprietate pentru a evita ambiguitile.
23

Un identificator business care este unic (GUID globally unique identifier) poate fi creat
prin a face hashing la atributele care l identific unic pe un business obiect (eg. Nume, Prenume,
Cod personal al angajatului).

2.4 Exportul entitilor

Procesul de export a entitilor din repozitoriu include un set de operatiuni. n figura 2.3 este
reprezentat diagrama use case care explic procesul de export a business obiectelor din baza de
documente i toate etapele dependente ce alctuiesc acest proces. Din diagram poate fi observat c
exportul depinde de cteva operaiuni cum ar fi scanarea repozitoriului pentru a obine lista
obiectelor existente n acesta. Paralele acestui proces se scaneaz i registrul local pentru a obtine o
list de entii exportate deja. n urma unei comparri simple ntre aceste liste vom gsi obiectele
care trebuie exportate.

Figura 2.3. Diagrama use case a procesului de export.

Exportul presupune extragerea n fiierul metadata.xml proprietile, relaiile i structura
business obiectelor din baza de date. Coninutul documentelor se extrage ntr-un folder cu numele
contents, iar rendiiile n folderul renditions. La etapa urmtoare se face arhivarea acestor date
i plasarea lor n folderul pentru sincronizare exterioara.

24

n figura 2.4 este prezentat diagrama de secven pentru cazul de extragere a entitilor din
repozitoriul local.

Figura 2.4. Extragerea entitilor din baza de documente.

Raportnd la cele reprezentate n figura 2.4 procesul de extragere este condus de un modul
care este numit entity puller i care cere la rndul su de la out entity provider s interogheze baza
de documente pentru a detecta entitile care corespund sync set-ului respectiv. Dupa detectarea
acestor entiti tot entity puller este rspunztor de nregistrarea entitilor n registrul local.
n figura 2.5 este reprezentat diagrama de secven pentru cazul mpachetrii entitilor de pe
repozitoriul local. Aceast etap din procesul de export se executa dupa ce a fost finisat cu succes
procesul de extragere i doar n cazul cnd sunt depistate entiti noi care trebuie exportate.

Figura 2.5. mpachetarea entitilor.

25

La mpachetarea entitilor procesul este gestionat de ctre un modul numit local packager
acesta este raspunztor de a cere de la alt modul numit local entity provider s returneze din
registrul local ID-urile entitilor ce trebuie mpachetate i exportate. Tot local packager are
responsabilitatea de a chema modulul de mpachetare iar dupa finisarea procesului s copie pachetul
nou creat pe folder-ul de Syncplicity care la rndul lui va face sincronizarea cu toi userii care au
dreptul de a descrca aceste obiecte i de a le sincroniza cu repozitoriul local.

2.5 Importul entitilor

Procesul de import a entitilor de pe file system include un set de operatiuni. n figura 2.6
este reprezentat diagrama use case care explic procesul de import a business obiectelor din
pachetul ce este reprezentarea file system a acestuia. Din diagram poate fi observat c importul
depinde de cteva operaiuni cum ar fi scanarea folderului offline pentru a obine lista obiectelor
existente pe file system. Paralele acestui proces se scaneaz i registrul local pentru a obtine o list
de entiti importate deja. n urma unei comparri simple ntre aceste liste vom gsi obiectele care
trebuie importate.

Fugura 2.6. Diagrama use case a procesului de import.

Importul presupune dezarhivarea fiierului ZIP i citirea fiierului metadata.xml pentru a
reconstrui business obiectul care a fost descris n acesta. Coninutul documentelor se extrage din
folder cu numele contents, iar rendiiile din folderul renditions. La etapa urmtoare se face
ncrcarea acestor date n baza de documente i nregistrarea lui n registru.
n figura 2.7 este reprezentat diagrama de secven pentru cazul de plasarea a evenimentelor
n baza de date local SQLite. Raportnd la cele reprezentate n aceast figur, procesul de plasare
26

este condus de un modul care este numit entity pusher i care cere la rndul su de la input entity
provider s interogheze baza de documente pentru a detecta entitile care au aprut ultimile pe
folderul de Syncplicity. Dupa detectarea acestor entii tot entity pusher este rspunztor de
nregistrarea entitilor n registrul local.

Figura 2.7. Plasarea evntitilor n baza de date local SQLite.

n figura 2.8 este reprezentat diagrama de secvent pentru cazul de despachetare a entitilor
din folderul Syncplicity. Aceast etap din procesul de import se execut dupa ce a fost executat cu
succes procesul de identificare a pachetelor venite din exterior i despachetarea lor pentru a
reconstrui business obiectul.

Figura 2.8. Despachetarea pachetelor din folderul de Syncplicity.

La despachetarea entitilor procesul este gestionat de ctre un modul numit local
unpackager acesta este raspunztor de a cere de la alt modul numit local entity provider s
27

returneze din registrul local ID-urile entitilor strine care au fost nregistrate i care trebuie
despachetate. Tot local unpackager are responsabilitatea de a chema modulul de despachetare iar
dupa finisarea procesului, s importe datele care au fost preluate din reprezentarea file system n
baza de documente ca un business obiect pentru sync setului respectiv.
2.6 Gestionarea tergerile locale
Procesul de tergere local a entitilor din repozitoriu include un set de operatiuni. n figura
2.9 este reprezentat diagrama use case care explic procesul de identificare i tergere a business
obiectelor din baza de documente. Din diagram poate fi observat c tergerile locale implic cteva
operaiuni cum ar fi scanarea repozitoriului pentru a obine lista obiectelor existente n acesta.
Paralele acestui proces se scaneaz i registrul local pentru a obtine o list de entiti exportate deja.
Dup o comparare simpl a acestor liste vom gsi obiectele file system care trebuie terse din
folderul de Syncplicity.

Figura 2.9. Diagrama use case a procesului de tergere local.

tergerea business obiectelor de pe repozitoriul local presupune identificarea obiectului care a
fost ters pentru a trece aceast informaie n registrul local. Acest procedur este necesar pentru a
evita ambiguitile la urmtoarele sincronizri. Un exemplu ar fi dac un utilizator este offline n
timp ce sa facut tergerea i dupa aceasta se conecteaz, vaznd ca pachetul respectiv nu exista ar
putea s il sincronizeze din nou i sl ncarce n toate repozitoriile. nsa avnd informaia salvat n
registru el va fi ters i de pe acest repozitoriu.

28

n figura 2.10 este prezentat diagrama de secven pentru cazul de tergere a entitilor din
repozitoriul local.

Figura 2.10. tergerea entitilor din baza de documente local.

Raportnd la cele reprezentate n figura 2.10 procesul de tergere local este gestionat de un
modul care este numit entity puller i care cere la rndul su de la out entity provider s interogheze
baza de documente pentru a detecta entitile care corespund sync set-ului respectiv. Dup
detectarea acestor entii tot entity puller este rspunztor de nregistrarea entitilor care au fost
terse n registrul local.
n figura 2.11 este reprezentat diagrama de secven pentru cazul tergerii pachetelor de pe
repozitoriul local. Aceast etap din procesul de tergere se executa dupa ce a fost executat cu
succes procesul de nregistrare a obiectelor terse dn registrul local.

Figura 2.11. tergere pachetelor de pe file system.

29

La tergerea packetelor procesul este gestionat de ctre un modul numit local handler acesta
este raspunztor de cererea de la alt modul numit local entity provider s returneze din registrul
local ID-urile entitilor strine care au fost nregistrate i care trebuie terse. Tot local handler are
responsabilitatea de a chema modulul de tergere a pachetelor de pe file system.
2.7 Gestionarea tergerile externe
Procesul de tergere a entitilor externe de pe file system include un set de operatiuni. n
figura 2.12 este reprezentat diagrama use case care explic procesul de tergere a business
obiectelor care au fost terse din alte repozitorii. Din diagram poate fi observat c tergerea
depinde de cteva operaiuni cum ar fi scanarea folderului offline pentru a obine lista obiectelor
existente pe file system. Paralele acestui proces se scaneaz i registrul local pentru a obtine o list
de entii importate deja. n urma unei comparri simple ntre aceste liste vom gsi obiectele care
trebuie terse.

Figura 2.12. Diagrama use case pentru procesul de tergere extern.

tergerea extern presupune identificarea obiectelor care au fost terse din alte repozitorii
pentru a trece aceast informaie n registrul local. Acest procedur este necesar pentru a evita
ambiguitile la urmtoarele sincronizri. Un exemplu ar fi dac un utilizator este offline n timp ce
se face tergerea iar dupa aceasta se conecteaz, vaznd ca pachetul respectiv nu exista ar putea s il
sincronizeze din nou i s l ncarce n toate repozitoriile. nsa avnd informatia salvat n registru,
c acest pachet a fost ters, el va fi sters i de pe acest repozitoriu.
n figura 2.13 este reprezentat diagrama de secvent pentru cazul de nregistrare a tergerilor
externe n baza de date local SQLite. Raportnd la cele reprezentate n aceast figur, procesul de
30

plasare este condus de un modul care este numit entity pusher i care cere la rndul su de la input
entity provider s interogheze baza de documente pentru a detecta entitile care au fost terse din
folderul de Syncplicity. Dupa detectarea acestor entiti tot entity pusher este rspunztor de
nregistrarea entitilor n registrul local.

Figura 2.13. nregistrarea tergerilor externe n registru.

n figura 2.14 este reprezentat diagrama de secvent pentru cazul de terger din docbase a
entitilor ce au fost eliminate extern. Aceast etap din procesul de tergere se execut dupa ce a
fost executat cu succes procesul de identificare a pachetelor terse din exterior.

Figura 2.14. tergerea din docbase a entitilor eliminate extern.

La tergerea entitilor externe procesul este gestionat de ctre un modul numit local
handler acesta este raspunztor de a cere de la alt modul numit local entity provider s returneze
din registrul local ID-urile entitilor strine care au fost nregistrate i care trebuie terse. Tot local
31

handler are responsabilitatea de a chema modulul de tergere iar dupa finisarea procesului s
verifice dac business obiectele au fost terse.

2.8 Procesul de sincronizare

Fiecare docbase are o component software numit sync agent care este responsabil de
gestionarea business obiectelor prin elaborarea urmtoarelor sarcini:
a) Exportarea business obiectelor ca un packet i adaugarea lor n registrul local;
b) Importarea business obiectelor noi venite din exterior;
c) Detectarea i procesarea tergerilor locale;
d) Detectarea i procesarea tergerilor externe;
Fiecare sync set rspunde de business obiecte diferite, agentul de syncronizare nu poate
gestiona cu toate business obiectele care exista. Deci pentru fiecare sync set va trebui de
implementat un plugin care ofera business logic pentru fiecare task de sincronizare.
n figura 2.15 sunt reprezentate activitile care se petrec ntrun ciclu de vi a
sincronizatorului. Dupa pornirea aplicaiei i iniializarea modulelor urmeazl procesul de detectare
a pachetelor venite din exterior apoi se prelucreaz aceste packete. Urmtorul pas este detectarea i
prelucrarea packetelor noi din repozitoriul local. Apoi se detecteaz i se prelucreaz tergerile mai
nti cele venite din exterior apoi cele locale.

Figura 2.15. Diagrama de activitati a agentului de sincronizare.

32

2.9 Arhitectura agentului de sincronizare

Agentul de sincronizare este sistem informaional care ruleaz permanent pe fiecare instan
a bazelor de documente care particip la protocolul de sincronizare i care implementeaz urmtorul
process pentru fiecare sync set configurat:
a) Detectarea business obiectelor (prezente ca obiecte file system) n folderul offline. Un
business obiect apare n folderul offline atunci cnd el a fost creat pe un alt docbase care
particip la procesul de sincronizarea. Acest business obiect va exista sub n folderul offline
pe file system dar nu i n registrul local fiindca el a fost creat ntrun alt docbase;
b) Importarea fiecrui business obiect nou detectat la etapa precedent n instana de
Documentum local. Business obiectele sunt adugate n registru la aceast etap;
c) Detectarea business obiectelor noi pe instana de Documentum local. Obiectele noi pot fi
detectate sau prin utilizarea unei date stabilite (toate obiectele noi create dup o anumit data
concret) sau prin compararea tuturor business obiectelor existente cu datele din registru;
d) Exportarea fiecrui business obiect nou detectat la etapa precedent. Business obiectele noi
sunt exportate n folderul offline ntr-o reprezentare file system i se adaug n registru;
e) Detectarea business obiectelor care au fost terse de pe folderul offline. Acesta este cazul
cnd business obiectele au fost terse de pe alte docbaseuri;
f) tergerea fiecrui business obiect ce corespunde reprezentri file system care a fost detectat
ca ters la etapa precedent. Business obiectul deasemenea va fi ters i din registru;
g) Detectarea business obiectelor care au fost detectare ca terse din docbaseul local. Obiectele
terse trebuie s fie detectate prin interogarea a acelor business obiecte prezente n registru i
nu sunt n docbase;
h) tergerea reprezentrii file system a business obiectelor detectate ca terse n pasul
precedent. Business obiectele vor fi deasemenea terse i din registru;
Acest model de proiectare presupune c sincronizarea complet a unui sync set (de exemplu,
toate repozitoriile care particip la un sync set sunt sincronizate n mod corespunztor) poate fi
realizat prin:
a) pstrarea copiilor offline sincronizate ntre repozitoriile participante la un caz de
sincronizare;
b) asigurnd c agentul lucreaz n acelai mod pe fiecare docbase;
Copiile de sincronizare offline pot fi obinute cu o soluie de sincronizare la nivel de file
system. Syncplicity este un exemplu de astfel de tehnologie. Diagrama din figura 2.16 reprezint o
topologie sumar a sincronizatorului cu un sync set i patru docbaseuri participante (Logoul
Syncplicity reprezint tehnologia de sincronizare la nivel file system). Fiecare sistem care intr n
33

componena agentului de sincronizare trebuie s conin mediul configurat i agentul de

sincronizare instalat.

Figura 2.16. Topologie sumar a sincronizatorului.

2.9.1 Arhitectura plugin-ului

Procesul de sincronizare necesit capacitatea de a gestiona foarte rapid business obiectele i
reprezentarea file system a lor. Se cere ca fiecare sync set s defineasc business obiectele proprii.
Trebuie ca agentul de sincronizare sa fie capabil de a gestiona mai multe tipuri de business obiecte
i business reguli aplicate asupra lor.
n scopul de a reduce complexitatea de ansamblu, operaiunile care sunt specifice unui
anumit tip de business obiect vor fi delegat unor agent plugins.
Un plugin agent trebuie sa implementeze urmtoarele capaciti:
a) S transforme business obiectele n reprezentri file system, i invers;
b) S identifice i s enumere noi business obiecte n docbase-ul local;
c) S tearg n mod corespunztor business obiectele din docbase-ul local;
d) S identifice i s enumere business obiectele care au fost terse dn docbase-ul local;
Fiecare sync set va specifica un plugin agent pentru a fi folosite pentru a executa
operaiunile. Agentului sincronizri va invoca metode ale plugin-ului pentru a executa operaiuni
fr a fi cazul utilizrii specifice, i contractului ncheiat ntre agent i plugin-uri vor fi definite
printr-o interfata de plugin agent.
34

Implementare necesar este:

a) Una sau mai multe plugin-uri generice, puse n aplicare ca o clas abstract;
b) O interfa, definirea contractului (metode) ntre agent i plugin-uri;
c) Sincronizare plugin-urilor sync setului, extinderea a unu dintre plugin-urile generice,
implementarea business logicii necesare i interfaa plugin agent.
Plugin-uri pot fi ncrcate prin reflecia agentului de sincronizare. Transformarea unui fiier
file system n instan de business obiecte corespunztoare n docbase ar trebui s fie tranzacional.
Acest lucru este necesar pentru a evita inconsistena n datele importate.

2.9.2 Integrarea cu Syncplicity

Pentru a face interaciunea ntre sistemele partajate va fi nevoie de un instrument de
sincronizare pentru fiierele file system pentru a sincroniza toate sistemele care particip la un use
case de sincronizare. Syncplicity ofer aceast funcionalitate prin integrarea cu agent de
sincronizare.
Integrarea se poate face n dou moduri diferite:
a) integrarea "slab". Folderul de sistem dosarpe file system, reprezentnd copia neconectat
pentru un anumit docbase este configurat n agent Syncplicity. Sincronizarea ntre copii offline se
ntmpl ca n cazul n care exist un folder de administrare de Syncplicity.
b) integrarea "strns". Copii offline exist numai pe Syncplicity, i file systemul de baz
(Citeste coninut dosarului, citire/scriere fiier) se nlocuiesc cu apeluri la API-ul Syncplicity.
2.9.3 Constrngeri
Securitate sincronizarea ACL-uri ntre docbases nu este recomandat, din cauza complexitii
implicate. Avnd n vedere c D2 este frontend de alegere pentru aplicatii distribuite n arhitectura
NEA, practica de conducere vor fi ca prghie abloane de securitate D2. Acest lucru nseamn c
valorile de atribute a business obiectelor va conduce la aplicarea de abloane de securitate D2, astfel
nu altele dect business obiectele n sine sunt informaii necesare pentru a aplica n mod
corespunztor pe securitate.
Auto naming denumire automat va fi aplicabil n cazuri de utilizare a sincronizrii numai n
cazul n care sunt valabile urmtoarele:
doar un docbase este permis pentru a genera numele documentului (scenariu Master-Slave);
exist un serviciu centralizat de denumire (acest lucru va necesita conecsiunea n timpul
importului sau crearerii de documente care impune aplicarea normelor de auto naming).

35

3 Implementarea sistemului informaional de sincronizare a entitilor

3.1 Sync setul HR (Human Resources)
Departamentul resurse umane necesit crearea unui spaiu de lucru care permite o gestionare
mai uoar a CAR-uri i a ataamentele lor, att din sediul central Saipem ct i de pe vasele care
au configurat agentul.
Trebuie s se asigure urmtoarele cerine generale:
a) arhiva de documente trebuie s fie disponibil pe toate navele care au configurat
agentul;
b) de pe vase utilizatorii trebui s poat ncrca documente;
c) "link-ul" intre GHRS i D2, care permite accesul la CAR-uri i la ataamentele acestora
direct din GHRS;
d) crearea unei structuri de foldere simple pentru stocarea documentelor;
e) modul de securitate pentru a modula accesul la profiluri diferite pentru a arhiva
documente;
f)

cutare i filtrarea rapid a atributelor pentru CAR-uri: numele i prenumele ar trebui s

fie suficient pentru a obine toate documentaia unui angajat;

3.1.1 Structura de foldere

Cerinele clientului impun o structur de folder pentru sync setul destinat departamentului
resurse umane. n figura 3.1 este prezentat ablonul pentru structura de fiiere care trebuie
respectat i care permite pentru fiecare angajat o list cu documentaia personal.

Figura 3.1. ablonul structurii de foldere.

Din figura 3.1 observm ca primele dou ramificaii ale structurii de foldere sunt costante. Pe
prima poziie este numele cabinetului n care se vor pstra angajaii. Folderul Employees va
conine cte un folder pentru fiecare angajat. Numele folderului pentru fiecare angajat trebuie sa fie
alctuit dupa schema din figur, unde trebuie sa fie numele i prenuele angajatului desprtite prin
36

cratim de GHRS_ID-ul angajatului. n interior sunt documentele angajatului care pot fi de tip CAR
sau CAR attachment.
n figura 3.2 este prezentat un exemplu de cum ar trebui s arate o structur de foldere cu date
reale.

Figura 3.2. Un exemplu de structur de foldere.

3.1.2 Securitatea (grupurile i permisiunile)
Pentru fiecare obiect de tip Employee frolder, CARs i CARs attachment trebuie aplicat un
singur ACL care se numete " hr_employee_acl " care trebuie sa extind ACL-ul standart
Documentum.
Sync setul pentru resursele umane trebuie s permit urmtoarele profiluri de securitate pentru
accesul la lucru cu documentele angajatilor:
Tabela 3.1: Grupurile ce au acces la informaie.
Name

Permision

dm_world

None

dm_owner

Delete

hr_admins

Delete

hr_writers

Write

hr_readers

Read

a) "hr_admins" acest profil este destinat pentru a acorda utilizatorilor drepturi de "Delete" pe
toate obiectele i de s permite operaiuni de ntreinere i tergere;
b) "hr_writers" acest profil permite utilizatorilor drepturile de a efectua operaiuni de ncrca
documente, de a efectua pe ntreg spaiu de lucru;

37

c) "hr_readers" acest profil acord utilizatorilor drepturi de "citire" pe oricare dintre folderele
aflate n spaiu de lucru;

3.1.3 Modele de date

Pentru sync setul resurselor umane este necesar de a crea cteva tipuri de date, care s posede
anumite proprieti ce vor favoriza procesele de cutare i gestionare a business obiectelor.

Employee folder
Atunci cnd un CAR este ncrcat n D2, sistemul trebuie s creeze directoriul angajatului cu
urmtoarele proprieti recuperate n timpul importului:
Numele obiectului: spm_hr_employee
Motenete de la : dm_folder
i are urmtoarele atribute custom:
Tabela 3.2: Atributele pentru employee folder.
Name

Type

Size

Repeating

Requied

Comments

employee_code

String

32

GHRS ID

employee_name

String

100

a) " employee_name " este un string, ne null, care permite repetri cu o lungime maxim de
100 de caractere care stocheaz informaii despre numele i prenumele angajatului;
b) " employee_code " este un string, ne null, unic cu o lungime maxim de 32 de caractere care
este un identificator unic a angajatului ;
c) "Folder name" este un string, ne null, care se completeaz automat de ctre D2 dupa
modelul "employee_name employee_code");

CAR (Competence Assessment Record)

Tipul de date CAR este destinat importrii documentelor de baz i trebuie s corespund
urmtorului model.
Numele obiectului: spm_hr_car
Motenete de la : dm_document
Pentru documentele de tip CAR este necesar de a avea urmtoarele atribute:

38

Tabela 3.3: Atributele pentru documentele CAR.

Name

Type

Size

Repeating

Required

Comments

employee_code

String

32

GHRS ID

car_id

String

32

Generated by D2?

employee_name

String

100

Set automatically from GHRS

job_title

String

50

Set automatically from GHRS

job_role

String

50

Set automatically from GHRS

company_role

String

50

Set automatically from GHRS

creation_date

Time

operator_name

String

32

a) "employee_name " este un string, ne null, care permite repetri cu o lungime maxim de
100 de caractere care stocheaz informaii despre numele i prenumele angajatului;
d) employee_code este un string, ne null, unic cu o lungime maxim de 32 de caractere
care este un identificator unic a angajatului;
b) job_title este un string read only ne null care are o lungime maxim de 50 de carcatere
i este destinat pstrrii titlului angajatul;
c) car_ideste un string, ne null, unic care nu poate s se repete i cu o lungime nu mai
mare de 32 de caractere care se seteaz automat de ctre sistem i specific un
identificator pentru documentul asociat unui angajat;
d) job_role este un string read only ne null care are o lungime maxim de 50 de carcatere
i este destinat pstrrii rolului pe care l are angajatul;
e) company_role
f) creation_date este o variabil de tip dat care automat se seteaz la importarea
documentelor;
g) operator_name este un string cu o lungime maxim de 32 de caractere i este setat
automat cu numele utilizatorului care a incrcat CAR-ul;
Un document CAR va fi importat automat i salvat sub folderul angajatului dorit dup
valoarea employee_code care este setat de ctre utilizatori n timpul procesului de import.

CAR (Competence Assessment Record) attachments

Utilizatorii care au cel putin dreptul write au dreptul de a aduga ataamente la documentele
CAR deja existente. Tipul de date CAR attachment are urmtoarele proprieti:
Numele obiectului: spm_hr_car_attachment
39

Motenete de la : spm_hr_car
Documentele de tip CAR attachment au nevoie doar de proprietile pe care le mostentes de la
super clas, ele nu au atribute proprii costumizate:
Un document CAR attachment va fi automat importat n docbase i salvat sub folderul
angajatului cruia i corespunde, raportnd la valorea car_id care este setat n timpul procedurii de
import. Deasemenea aceste documente trebuie s fie relaionate cu documentele de baz CAR prin
atributul car_id.
3.1.4 Cutarea
CAR-urile i documentele anexate trebuie s fie cutate prin intermediul instrumentelor de
cutare oferite de D2, n funcie de formele de cutare predefinite, n special sistemul trebuie s
ofere posibilitatea de a cuta rapid toate documentele pentru un anumit angajat. De asemenea,
utilizatorii ar trebui s poat cuta un document CAR specificnd numele angajatului sau codul
personal.

3.2 Strategii de implementare

La baza aplicaiei va fi core-ul acesteia care va activa ca un framework i care va permite
adugarea de plugin-uri care alctuiesc sync seturile preferate de client. Fiecare plugin va oferi un
set de puncte de extindere pe care plugin-urile le vor utiliza pentru a aduga business logica proprie.
Pentru a face lucrul mai uor i mai calitativ au fost alese un set de librrii care uureaz att
lucru developerilor ct i procesul de configurare a sistemului pe partea de client.
Spring
Pentru configurare sistemului i pentru definirea de bean-uri a fost alese bibliotecile spring.
Acestea ofer modaliti eficiente de lucru pentru a micora timpul pierdut n scopul elaborrii unor
solutii asemnatoare care cu iguran nu vor fi mai eficiente. Deasemenea spring este utilizat i
pentru dependency injection.
Quartz
Pentru rularea job-urilor de sincronizare se va utiliza biblioteca quartz care permite
implementarea business logicii ce permite ca un plugin s ruleze mai multe joburi de sincronizare.
JAXB
Pentru citirea documentelor XML se vor utiliza bibliotecile JAXB. Care vor fi utilizare pentru
marshaling i unmarshaling a packetelor ce conin business obiectele care se exporta din docbase
pentru a fi transferate la alte sisteme distribuite i pentru import n cazul despachetrii i ncrcrii
n docbase.
40

DFC
Pentru executarea interogrilor i a lucrului cu baza de documente a fost utilizat Documentum
Foundation Classes. Acestea includ un set de biblioteci destinate lucrului cu bazele de date
documentum.
Java SE
Codul core-ului este scris n Java SE i n rezultat se obine o aplicaie consol.

3.2.1 Puncte de extindere

Dei au fost implementate o mulime de puncte de extensie pentru a face aplicaia ct mai
posibil abstract i mai uor de extins, pentru a aduga un plugin nou este destul ca s fie extinse
urmtoarele puncte de extensie:
1. Sync set scanner
n figura 3.3 este reprezentat diagrama de clase pentru modulul Sync set scanner. Acest
modul este responsabil de scanarea atit a repozitoriului ct i a folderului offline pentru a detecta
business obiectele care au fost modificate sau terse. Pentru a extinde acest modul este necesar de a
implementa interfaa IsyncSetScanner sau de extins clasa AbstractSyncSetScanner.

Figura 3.3. Diagrama de clase pentru modulul sync set scanner.

41

2. Docbase Entity Service

n figura 3.4 este reprezentat diagrama de clase pentru modulul docbase entity service. Acest
modul este destinat lucrului cu baza de date pentru a gestiona entitile atribuite sync setului.
Modulul este raspunztor pentru efectuarea operaiilor de Creare, Citire, Modificare, tergere.
Pentru a extinde acest modul trebuie de utilizat clasa AbstractDocbaseEntityService pentru
entitile care nu au rendiii i AbstractDocbaseSysObjectEntityService pentru cele care au rendiii.

Figura 3.4. Diagrama de clase pentru modulul docbase entity service.

42

3. Offline entity service

n figura 3.5 este reprezentat diagrama de clase pentru modulul offline entity service. Acest
modul este destinat gestionrii entitile de pe offline. Modulul este raspunztor pentru efectuarea
operaiilor de Creare, Citire, Modificare, tergere asupra business obiectelor importate.
Pentru a extinde acest modul trebuie de utilizat clasa AbstractOfflineEntityService.

Figura 3.5. Diagrama de clase pentru modulul offline entity service.

4. Marshal service
n figura 3.6 este reprezentat diagrama de clase pentru modulul marshal service. Acest modul
este destinat pentru conversia pachetelor offline n business obiecte i a business obiectelor n
pachete offline. Pentru a face aceast lucru, serviciul de marshaling parseaz fiierul xml pentru a
restabili business obiectele utiliznd JAXB sau creaz fiierul xml dintr-un business obiect existent.
Pentru a extinde acest modul putem s implementm interfaa IEntityMarshalService sau s
extindem clasa abstract AbstractMarshalService.

43

Figura 3.6. Diagrama de clase pentru modulul marshal service.

5. Rendition registry service

n figura 3.7 este reprezentat diagrama de clase pentru modulul rendition registry service.
Acest modul este responsabil de gestionarea unui registru cu rendiii a documentelor. Datele despre
rendiii vor fi utilizate pe viitor pentru a detecta care rendiii au fost modificate.
Pentru a extinde acest modul trebuie de implementat interfaa IRenditionRegistryService.

Figura 3.7. Diagrama de clase pentru modulul rendition registry service.

44

n figura 3.8 este prezentat diagrama de clase a sincronizatorului cu toate modulele de baz
i punctele de extindere. Diagrama respectiv este destinat prezentrii dependenelor ntre module.
Clasele prezentate cu alb sunt clase de baz alctuite din interfee i clase abstracte. Clasele
colorate cu sur sunt implementri de baz a modulelor definite. Cu culoare albastr sunt
implementrile concrete pentru plugin-ul HR.

Figura 3.8. Diagrama de clase a sincronizatorului.

45

n figura 3.9 este prezentat diagrama de componente a sistemului informaional. Aici sunt
artate cele componentele de baz pe care le utilizeaz sistemul i dependea ntre acestea. Dup
cum se vede din imagine aplicaia este separat n dou pari. Una este D2 care constituie o interfa
de lucru cu utilizatorul unde documentele pot fi create, citite sau modificate i partea a doua care
este serviciul de sincronizare ce se ocup de detectarea obiectelor create de utilizator sau a celor
venite din exterior. Acest lucru se face prin scanarea bazei de documente i a folderului offline de
syncplicity

Figura 3.9. Dependena componentelor n sistemul informaional.

3.3 Adugarea unui sync set job nou la Spring Quartz
Fiecare Sync set este independent i ruleaz ntr-un job propriu. Pentru configurarea acestor
procese la adugarea unui sync set nou trebuie de configurat fiierele de configurare spring pentru a
porni aceste joburi. Deci, trebuie de deschis fiierul config\quartz-context.xml i de adugat
urmtoarele tag-uri n fiierul xml.
n figura 3.10 este reprezentat tag-ul pentru definirea jobului quartz.
<bean id="testJob" class="com.saipem.framework.nea.core.jobs.DefaultSyncJob">
<property name="task">
<ref bean="testTask" />
</property>
</bean>

Figura 3.10. Definirea tag-ului pentru job.

46

n figura 3.11 este reprezentat tag-ul pentru task-ul quartz.

<bean id="testTask" class="com.saipem.framework.nea.core.jobs.DefaultSyncTask">
<constructor-arg index="0">
<ref bean="testSyncWorker" />
</constructor-arg>
<constructor-arg index="1">
<value>D:\\NEA\\OfflineCopy\\spm_hr_employee</value>
</constructor-arg>
<constructor-arg index="2">
<value>spm_hr_employee</value>
</constructor-arg>
</bean>

Figura 3.11. Definirea tag-ului pentru task.

Unde <ref bean="testSyncWorker" /> este o referin la a implementarea concret a
clasei com.saipem.framework.nea.core.agent.ISyncWorker interface.
Figura 3.12 reprezint tag-ul de definire a job-ului quartz.
<bean id="testQuartzJob"class="org.springframework.scheduling.quartz
.MethodInvokingJobDetailFactoryBean">
<property name="targetObject" ref="testJob " />
<property name="targetMethod" value="run" />
<property name="concurrent" value="false" />
</bean>

Figura 3.12. Definirea tag-ului pentru quartz job.

n figura 3.13 este reprezentat tag-ul de adugare a unui schedule pentru quartz job.
<bean id="testTrigger"
class="org.springframework.scheduling.quartz.SimpleTriggerBean">
<property name="jobDetail" ref="testQuartzJob " />
<property name="repeatInterval" value="60000" />
<property name="startDelay" value="0" />
</bean>

Figura 3.13. Definirea tag-ului pentru trigger.

n figura 3.14 este prezentat tag-un pentru nregistrare a job-ului la quartz. n bean-ul
SchedulerFactoryBean

adaug jot-ul i scheduler-ul:

<bean class="org.springframework.scheduling.quartz.SchedulerFactoryBean">
<property name="jobDetails">
<list> <ref bean="testQuartzJob" />
</list>
</property>
<property name="triggers">
<list> <ref bean="testTrigger " />
</list>
</property>
</bean>

Figura 3.14. Definirea tag-ului pentru trigger.

Elabornd aceti pai, ar trebui s fie suficient pentru a configura quartz-ul s ruleze jobul
pentru sync setul necesar.
47

3.4 Configurarea i implementarea sistemului informational

Pentru a putea executa unele aciuni n aplicaia Documentum D2, treubui mai nti s o
configurm. Pentru a face acest lucru trebuie pornit aplicaia D2-Config, n care n-e logm cu un
account de super user. Dup logarea cu succes n D2-Config trebuie de creat o aplicaie. Dup cum
se vede din figura 3.15 pentru a crea o aplicaie nou sau pentru a modifica una existent trebuie sa
mergem n meniul principal la Tools->Applications.

Figura 3.15. Crearea unei aplicaii noi n D2-Config.

Din figura 3.16 vedem c pentru a crea o aplicaie noua trebuie s apsm pe butonul New.
n caz c dorim sa modificm proprietile unei aplicaii deja existente, selectm aceast aplicaie
din meniu apoi facem modificrile necesare.

Figura 3.16. Configurarea aplicaiei noi create n D2-Config.

Pentru a crea matricea de configurare D2, este necesar de creat unu sau mai multe contexte.
Pentru aceasta selectm File->New->Context. n figura 3.17 putem vedea pagina de creare a unui
context nou. Pentru configurarea contextului este suficient de adugat un nume pentru acesta i tipul
asupra cruia se aplic, n cazul respectiv vom crea un context pentru tipul spm_hr_employee.
48

Figura 3.17. Crearea i configurarea unu context n D2-Config.

n figura 3.17 este prezentat contextul pentru crearea de tipuri. D2 mai permite crearea de
contexte i pentru grupuri. Pentru a crea un context pentru grupuri trebuie de selectat grupurile din
meniul respectiv.
n figura 3.18 este prezentat pagina de configurare a procesului de auto naming. Acest
proprietate D2 este utilizat pentru a seta anumite proprieti automat dupa o anumit regul. De
exemplu pentru documentele CAR se va atribui un proces de auto naming pentru setarea atributului
car_id care va avea forma descris n template. Dupa cum vedem n partea a doua a template-ului
este numr format din maximum 6 cifre i care se va incrementa automat la adugarea unu CAR
document nou.

Figura 3.18. Crearea i configurarea de auto naming n D2-Config.

49

n fugara 3.19 este prezentat pagina de auto linking pentru documentele CAR. n ablonul
descris se specific folderul n care va fi creat documentul. Aceast regula se aplica la importarea
documentului n docbase i nainte de a crea documentul, D2 va lua valorile de pe atributele
obiectului i va crea automat calea unde s il linkeze.

Figura 3.19. Crearea i configurarea auto linking-ului n D2-Config.

Pentru a efectua careva actiuni asupra documentelor ce se includ n cabinetul HR utilizatorii
drepbuie s aparin anumitor grupui care sunt configurate tot din D2-Config. n figura 3.20 este
prezentat pagina de creare i configurare a grupurilor de securitate.

Figura 3.20. Crearea i configurarea securitii n D2-Config.

50

n figura 3.21 este prezentat pagina de creare i configurare a procesului de checkin.

Aceast pagin descrie actiunile i regulile care trebuie efectuate actunci cnd un document este
creat i salvat n repozitoriu.

Figura 3.21. Crearea i configurarea checkin-ului n D2-Config.

n figura 3.22 este prezentat pagina de creare i configurare a matricelor de creare extinde.
Aceste matrici sunte destinate pentru a defini anumite valori implicite care se aplic documentelor
la import. Tot aici se pot aplica dicionare, pot fi asociate workflow-uri sau cicluri de via.

Figura 3.22. Crearea i configurarea matricelor de creare extinse n D2-Config.

n figura 3.23 este prezentat pagina de creare i configurare a interogarilor care sunt apelate
la cutarea unor documente care se includ n cabinetul HR.

51

Figura 3.23. Crearea i configurarea formelor de interogare n D2-Config.

n figura 3.24 este prezentat pagina de creare i configurare a spaiului de lucru pentru
utilizatorii human resurces. Acesta este necesar pentru a fi posibil de deschide aplicatia din D2.

Figura 3.24. Crearea i configurarea spatiului de lucru n D2-Config.

n figura 3.25 este prezentat pagina de creare i configurare a formelor de editare a
proprietilor. Atunci cnd se adaug un CAR document sau un ataament va aprea o form de
editare a proprietilor care este descris n figura de mai jos.

Figura 3.25. Crearea i configurarea paginilor de proprieti n D2-Config.

52

Dup crearea contextelor pe orizontal i a proprietilor pe vertical toate acestea se adauga la

matricea de configurare D2-Config. Pentru a aplica o proprietate pe un context n matricea de
configurare trebuie de selectat celula care este la intersecia acestorea. n figura 3.26 este prezentat
matricea de configurare D2 pentru aplicaia Human Resources.

Figura 3.26. Matricea de configurare D2-Config.

3.5 Testarea produsului

Dup configurarea sistemului i instalarea tuturor modulelor este timpul s elaborm ceva
teste. Pentru aceasta trebuie de deschis aplicaia Documentum D2 din Internet Explorer i dup cum
este reprezentat n figura 3.27 trebuie s n-e logm n D2. Pentru logare trebuie s utilizm un user
care are drepturi de a accesa aplicaia Dept. CMS Human Resources. Pentru efectuarea testelor am
creat un utilizator de test hr_test_user care are drepturile att de acces la business obiecte din
cabinetul Human Resources ct i permisiunea Delete asupra acestora.

Figura 3.27. Logarea n aplicaia D2.

53

Dup logare se va deschide interfaa aplicaiei D2 care este asemnatoare celei din figura 3.28
unde este deschis cabinetul Human Resources ce contine mai multe entiti de test care au fost create
pentru testarea rezistenei acesteia la volume mari de date.

Figura 3.28. Interfaa aplicaiei D2.

Pentru a prezenta procesul de adugare a unui angajat nou, i cteva documente CAR i CAR
ataamente n figura 3.29 este prezentat meniul de adugare a unui context nou.

Figura 3.29. Adugarea unui context nou.

Nu este necesar de adugat folderul angajatului dac acesta nu exist, la crearea unu
document CAR, dac angajatul asociat acestuia nu exista el se va crea automat de ctre D2 iar
atributele necesare vor fi luate de pe document. Deci dup cum este prezentat in figura 3.30 vom
54

ncepe cu selectarea din meniul cu tipuri a CAR documentelor. Dup selectare trebuie apsat
butonul Edit Properties pentru a trece la urmtorul pas unde se vor edita propriettile acestui
document.

Figura 3.20. Selectarea tipului pentru CAR document.

n figura 3.31 este prezentat forma de completare a propriettilor noului documet, care
necesit de a aduga numele pe care il va avea documentul, codul angajatului care este unic n tot
sistemul de sincronizare, numele angajatului i alte proprietti care aparin angajatului. Dup
completarea cmpurilor se creaz documentul i automat D2 va face check-in.

Figura 3.31. Completarea proprietilor pentru CAR document.

Pentru crearea unu CAR ataament procesul este asemntor cu cel pentru creare a CAR
documentelor cu exceptia c din lista de tipuri din figura 3.31 alegem CAR Attachment.
55

Dup crearea documentelor CAR revenim la cabinetul Human Resurces i vedem c n

folderul cu angajai a aprut angajatul pentru care am creat documente dupa cum este n figura 3.32.

Figura 3.32. Noul angajat a fost creat.

Dac deschidem acest folder figura 3.33, n interior vom vedea c documentele care au fost
create mai sus sunt n acest directoriu.

Figura 3.33. Verificarea existenei CAR-urilor.

Dup salvarea n docbase a documentelor noi create, cnd sincronizatorul i va ncepe lucrul
aceste date vor fi exportate sub forma unui ZIP file. Iar n tabela cu regitri figura 3.34, vom putea
vedea informatia despre cum a fost executat procesul.

Figura 3.34. nregistrare din tabela business_object_registry care confirm exportul.

n figura 3.35 este prezentat structura unu pachet exportat. Orice entitate care se va exporta
va avea n interiorul pachetului ZIP un folder pentru rendiii unul pentru coninuturi i un fiier xml
cu logica de restabilire i atributele de pe obiecte.

Figura 3.35. Structura unui pachet exportat

56

3.5.1 Cutarea
n modulul de cutare care poate fi gsit pe partea dreapt a interfeei cu utilizatorul din
aplicaia D2 selectm Public Searches de unde vom avea acces la urmtoarele optiuni:
a) Cutarea de CAR-uri: este posibil de a cuta CAR documente n legtur cu criteriile
definite, prin completarea unei forme de cutare cu cele mai importante atribute a CAR
documentelor.
b) Cutarea Documentelor pentru un angajat: este posibil de a cuta toate documentele
pentru un anumit angajat, prin completarea simpl a unei forme de interogare cu numele angajatului
sau cu GUID-ul personal.
3.5.2 Cutarea avansat
D2 ofer o funcionalitate de cutare avansat, acest instrument permite efectuarea cutrilor
pe atribute i pe coninut (cu excepia imaginilor i a pdf-urilor care nu sunt scanate) a tuturor
obiectelor salvate n sistem. Forma de cutare este foarte util pentru cutarea de definiii a
criteriilor care este mult mai complex i mai puternic dect cutarea predefinit prin forme de
interogare care au fost descrise mai nainte, sau dect cutarea standart. Figura 3.36 demostreaz
cum trebuie de lansat o cutare avansat.

Figura 3.36. Cutarea avansat.

3.5.3 Compararea sistemelor de sincronizare

Pentru a oferi posibilitatea alegerii instrumentului de sincronizare sa efectuat teste asupra
celor mai rspndite servicii de file sharing care exist la moment. Pentru a informa utilizatorul mai
jos au fost enumerate propriettile observate la fiecare dintre ele cu plusurile i minusurile lor:
a) Sistemul Box:
- sincronizare foarte inceat;
57

- clientul desktop nu permite modificarea path-ului ctre folderul de sincronizare;

- nu are fiiere care ar trebuie de ignorat;
- nu are fiiere pariale n folder;
b) Sistemul Dropbox:
- face sincronizarea foarte rapid;
- clientum permite costumizarea path-ului;
- trebuie de ignorat fiierele: .dropbox, desktop.ini;
- fiierele pariale nu se salveaz n folder;
c) Sistemul Google Drive:
- sincronizarea este lent;
- clientum permite costumizarea path-ului;
- trebuie de ignorat fiierele: desktop.ini;
- fiierele pariale nu se salveaz n folder;
d) Sistemul Microsoft Skydrive:
- sincronizarea este foarte lent, perioada ntre cererile de sincronizare este mare;
- clientum permite costumizarea path-ului;
- nu are fiiere care ar trebuie de ignorat;
- fiierele pariale nu se salveaz n folder;
- n cazul n care un dosar a fost mprtit cu utilizatorul X, utilizatorul X nu va fi capabil
de a sincroniza acel folder de pe PC-ul su. Dac un utilizator dorete s mprteasc un
folder ntre dou computere, trebuie s utilizai acelai cont.
3.6 Problemele aprute n timpul implementrii i soluionarea acestora
3.6.1 Factori subiectivi
Sistemele de sincronizare a documentelor au o oarecare particularitate: sistemul ori trebuie s
fie implementat la locurile de munc, legate cu crearea, redactarea i pstrarea informaiei, sau
eficiena folosirii ei va fi minim. O aa abordare a problemei scoate la iveal una din principalele
probleme de implementare: n orice instituie (organizaie) vor fi oameni care vor tinde s evite ceea
ce este nou. De obicei conservatismul personalului e alimentat de ne dorina de a nva i
perfeciona, de asemenea, posibilitatea nivelului slab de cunotine. Aceast problem poate duce n
impas ntregul proces de implementare. Aceasta se refer special la instituii, n care politica de
58

cadre este foarte conservativ, i nimeni, pn i managerul, nu e n drept de a efectua circulaia i

perfecionarea cadrelor.
Aceast problem poate fi rezolvat prin lucrul cu persoanele aceasta este politica la nivelul
ntregii instituii i psihologia la nivel de persoan. n majoritatea cazurilor este nevoie de o
abordare independent cu fiecare om, innd cont de calitile lui att a vrstei, profesionalismului
ct i a celor personale. Trebuie de neles, c oamenii n timp s-au obinuit cu un anumit mod de
lucru, iar dumneavoastr sugerai radical schimbarea lui cu altul, n totalitate neobinuit lor, dar n
acelai timp de a nu micora volumul. Ce se poate de fcut pentru a le uura oamenilor aceast
schimbare?
n primul rnd schimbarea poate fi efectuat treptat. De exemplu, pentru nceput de
implementat pota electronic. Modelul de lucru al potei electronice este pe nelesul tuturor,
oamenii se deprind uor cu el. Apoi poate fi implementat un sistem intranet accesibil i treptat de
nvat personalul instituiei s caute materialele informaionale de care au nevoie (numerele
telefonice interne, datele i anunurile edinelor, procese verbale, ordine, dispoziii acte normative
interne etc.) pe un server intranet intern. Datorit acestei modaliti oamenii se vor obinui s
citeasc actele la monitor, s lucreze cu documente electronice, s le tipreasc numai pe acelea de
care au nevoie. O aa abordare va micora volumul actelor tiprite i va uura la rennoirea lor. Este
de dorit (dar din pcate nu ntotdeauna posibil) pentru ca mijloacele potei electronice i accesul la
informeie de la bun nceput s devin pri componente ale viitorului sistem de gestiune a
documentelor.
n al doilea rnd, la etapa de pregtire a lucrului trebuie de ncercat de a gsi colegi entuziati
care vor ajuta la implementarea noilor tehnologii de lucru. Acetia trebuie s fie oameni prietenoi
care nu-i arat supremaia lor asupra celor din jur, dar din potriv, i manifest dorina de a ajuta
pe alii s asimileze mai uor ceea ce ei tiu deja. n concordan cu acest principiu trebuie
organizate cursuri de perfecionare. Este binevenit ca leciile iniial s fie pe baz de voluntariat.
Colaboratorii care vin la aceste cursuri din propria voin, n urma atrnrii corecte fa de instituie
vor fi atrai ca s fie persoanele dumneavoastr de ncredere. Apoi, dup implementarea n mas,
instruirea trebuie s devin obligatorie n acelai timp la oameni va aprea un interes i vor cpta o
anumit informaie, pe care au primit-o de la cei care au trecut primii instruirea.

Factor de conducere
Factorul de conducere - este cel mai important, lipsa de voin a conducerii instituiei poate
duce la urmri de diferit nivel de graviditate. De obicei n acest caz sistemul este implementat

59

numai n unele subdiviziuni, doar la unele niveluri, sau pentru unele clase de procese

de

administrare, n cel mai ru caz nu va fi implementat deloc.

Una din cauzele ascunse a legturii fa de implementarea sistemului de sincronizare n
conducerea instituiei i a conductorilor diferitor nivele n ierarhie este teama de transparen a
activitii proprii att pentru conducere ct i pentru subalterni care apare dup implementarea
sistemului electronic de gestiune a documentelor.
Un aa numit factor a directorului de tip sovietic dorina aprig de a lucra cu calculatorul,
de a vedea i redacta documente. Conductorii de acest tip prefer sa aib legtur direct cu
oamenii chemndu-i n faa sa, dar nu cu acte coninutul carora este necesar de a nelege. Anume
acest tip de conductori este tot mai puin ntlnit.
Una din acestea este de a convinge conductorul. Problema e cum, prin exemplificri, prin
situaii care iar arta avantajele implementrii sistemului de sincronizare.

3.6.2 Factorii obiectivi

Mai jos sunt prezentai pe larg factorii obiectivi spre deosebire de cei care de obicei sunt
inclui n ghilimele i la care se apeleaz n ncercarea de a justifica eecul. Aceti factori enumerai
mai jos trebuie luai n considerare la etapa de planificare a implimentrii, altfel n viitor ei pot
deveni de nenvins.
Structurare haotic
Unul din factorii greu de nvins sunt schimbrile structurale permanente n companie, i ca
urmare o formalizare neefectiv a bussiness-proceselor. Interesant este c sistemul deja existente de
sincronizare a fiierelor sunt capabile de a simplifica simitor realizarea acestor sincronizri n
interiorul companiei. Capacitile unui sistem de sinconizare permit de a evita greutile care apar la
transmiterea pachetelor de informaie referitoare la un angajat atunci cnd oficiile sunt repartizate
global de exemplu cnd este angajat o persoana noua pe un antier din alt ar pentru a duce o
eviden a angajailor informaia trebuie transmisa la oficiul central iar daca am lucra cu
documentele separate ar fi foarte greu ca fiecare s ncarce aceste documente n repozitoriul su,
nemaivorbind de pierderile de informaie i coninut.
Totui, nu nseamn c ptrunderea sistemei de sincronizare a entitilor n asemenea cazuri
este imposibila cu totul. Este doar nevoie de aplicat componentele sistemelor de de sincronizare a
entitilor, care corespund situaiei organizaiei la moment. De exemplu, chiar prin prezena destul
de neuniform a structurii organizaiei se poate de creat o arhiva care s conin coninutul i
metadatele business obiectului, care ar permite restabilirea acestuia, accesul la ele a diferitor
60

colaboratori din diferite locaii ale globului care s fie capabil s fac ca de exemplu: nlturarea sau
adugarea unor documente n interiorul business obiectului, economisirea locului pe disc din contul
migraiei documentelor nvechite pe alte suporturi mai ieftine etc. La etape mult mai avansate se
poate de nceput formalizarea circulaiei documentelor in acele desprituri, care sau utilizat
maximal. Prin calea indicat este foarte important de gsit compania partener pentru implementarea
sistemului, care s fie orientat spre lucru pe termen lung, dar nu pentru un contract de moment cu
pre maximal. n afar de aceasta, sistemul ales trebuie sa fie modular, care sa permit creterea
funcionalitii n procesul de exploatare.
Lipsa sistemului de sincronizare a entitilor
Ce e de fcut daca ntr-o organizaie lipsete sistemului de sincronizare a entitilor? n
aceast situaie sunt de asemenea avantaje. n primul rnd este lipsa necesitii de a instrui pe
cineva. n afar de asta, este o condiie prealabil obiectiv spre ceea de a convinge conducerea de a
utiliza un sistem de sincronizare a documentelor. Se nelege c, dac dumneavoastr propunei sa
aleag: s continue cu modelul nvechit pe hirtii, sau s utilizeze un sistem modern de sincronizare
a entitilor, cel mai mult probabil este c vor alege ultima variant. Problema cea mai important se
rezuma la aceea c, daca organizaia e mare i nu are nici un sistem de sincronizare a entitilor,
atunci n ea ntotdeauna apar o groaza de probleme, i conducerea nu ntotdeauna nelege, ca
rdcinile lor se gsesc n lipsa unei scheme de conducere a organizaiei. In rezultat asupra
conducerii ntotdeauna sunt ncrcai cu o mulime de probleme i lor nu le este de un oarecare
sistem de gestiune a documentelor. Aceast situaie este foarte grea, dar, dup cum arat
experiena, nu ntotdeauna fr speran.
Soluia n aceste cazuri este simpl. E nevoie de a crea un proiect pilot. Pentru aceasta este
nevoie de analizat lucrul organizaiei si de gsit problemele, care ndeosebi sufer din cauza lipsei
unui sistem de gestiune a documentelor. Apoi, dup ce proiectul pilot a fost cu succes implementat
i avei susinerea din partea conductorilor de departamente, problemele crora au fost soluionate
(fii ateni, nu dumneavoastr le-ai gsit, dar ei, datorit implementrii sistemului), se poate cu
siguran de insistat asupra petrecerii ntrunirilor la aceasta tem. Cnd este sigur cunoscut ce e de
fcut, este desigur satisfacie n lucrul cu sistema din partea efilor de departamente, i e fcut un
calcul rezonabil a cheltuielilor efectuate pentru implementarea sistemei n ntregime pentru
organizaie, chiar i o conducere foarte ocupat va gsi timp pentru luarea deciziilor. Conductorilor
le este ntotdeauna plcut sa participe la ntruniri care se petrec sub tema de raportare a succeselor,
i e simplu de susinut nceputul, care dup cum lor le pare au destui adepi, aceasta nsemn, ca se
va realiza fr eforturi prea mari din partea conductorului.
61

Concluzie

n mediul de afaceri actual, capacitatea de a utiliza informaia potrivit la momentul potrivit

reprezint o premis a succesului, ns pentru cele mai multe companii, identificarea de noi
modaliti de organizare, gestiune i depozitare a documentelor i a informaiilor reprezint nc o
problem.
n timpul de fa, n organizaii i ntreprinderi cu orice tip de activitate, compartimentul IT sa transformat din element auxiliar n component de baza, iar de funcionarea creia depinde
eficiena lucrului ntregii organizaii. Acest lucru se refera la toate domeniile de activitate.
Pentru lucrul eficient al unei companii care are oficii n mai multe ri apare necesitate unui
sistem informaional care s fac legtura ntre bazele de documente ale acestora i s funcioneze
stabil, n timp real i securizat n acelai timp. De funcionarea reuit a unui astfel de sistem
informaional depinde managementul reuit a resurselor care se sincronizeaz.
Implementarea unui sistem de sincronizare ntre repozitorii este o idee inovatoare i destul
de istea, pe care ar putea s o foloseasc orice tip de companie care are o structur topologic
distribuit. Utilizarea agentilor de file sharing n cadrul sistemului a simplificat considerabil lucru i
n acelai timp a sporit calitatea. Acest lucru se datoreaz att faptului c acestea ofer sisteme
foarte complexe de detectare a modificrilor ct i posibilitatea de stocare a datelor n cloud.
Prin extinderea acestui sistem este posibil de sincronizat orce tip de business obiecte asa c
indiferent de complexitatea lor sistemul va fi robust i va sincroniza repozitoriile fra a fi nevoie de
intervenit manual pentru a efectua careva lucru de import care necesit timp i personal calificat.

62

Bibliografie

1.

A. Tridgell (February 1999). Efficient algorithms for sorting and synchronization. The
Australian National University. [http://www.samba.org/~tridge/phd_thesis.pdf]

2.

Ari Trachtenberg; D. Starobinski and S. Agarwal. "Fast PDA Synchronization Using

Characteristic Polynomial Interpolation". [http://people.bu.edu/staro/infocom02pda.pdf]

3.

Pirkola,G. C., "A file system for a general-purpose time-sharing environment",

[http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=1451786]

4.

EMC Documentum Foundation Classes Development Guide

https://community.emc.com/servlet/JiveServlet/previewBody/3230-102-2-8563/DFC

5.

EMC Documentum D2 4.1 Architecture

http://www.emc.com/collateral/white-papers/h11494-wp-pdf-documentum-d2-

architecture.pdf

63