Embedded Files
*** Funcţionalitate specifică de tip push data doar pentru anumite site-uri ***
Scopul sincronizării SocrateCloud -> Site este de a face vizibile anumite modificări din SocrateCloud în terţe sisteme informatice, în timp real (cu o întârziere variabilă, în funcţie de numărul de schimbări, reţea etc.), prin intermediul serviciilor web (definite în sistemul informatic terţ).
Dacă se doreşte sincronizarea de articole între un site şi SocrateCloud, de exemplu, metoda anterioară era de a interoga SocrateCloud la intervale regulate de timp. Pentru a elimina interogarea repetată (uneori fără a obţine date noi, de fapt), SocrateCloud poate să răspundă la modificările articolelor şi să apeleze servicii web din site.
Pentru exemplificarea opţiunilor de configurare se va porni de la următorul scenariu:
site-ul are activ un serviciu web pentru sincronizarea articolelor;
informaţiile necesare sunt denumirea articolului şi stocul acestuia;
Configurarea serviciilor
Configurarea se face din Data Exchange Interface -> Configurare sincronizare site:
Datele sunt trimise sub formă JSON, în POST[‘info’], apelând serviciul web disponibil indicat în URL. Numărul de coloane şi tipul de date este cel definit în tabela publicată. La fiecare apel poate fi trimisă o singură linie.
{
"data": [
{"row": [
<val col1>,
<val col2>,
...
<val colN>
]}],
"metadata": {
"column-count": <N>,
"column-definition": [
{
"column-index": 1,
"column-name": <Col Name>,
"column-type": <Col Type>,
"column-type-name": <Col Type Name>
},
{
"column-index": 2,
"column-name": <Col Name>,
"column-type": <Col Type>,
"column-type-name": <Col Type Name>
},
.....
{
"column-index": N,
"column-name": <Col Name>,
"column-type": <Col Type>,
"column-type-name": <Col Type Name>
}
]
}
}
După definirea serviciului web se trece la indicarea datelor care vor fi sincronizate. În taburile Tabele şi Coloane, se vor indica tabele şi coloanele declanşatoare ale apelurilor de servicii web. Codul de validare limitează schimbările procesate. Pentru scenariul prezentat la început vor fi necesare 2 înregistrari în tab-ul Tabele: una pentru schimbarea denumirii articolului şi cealaltă pentru schimbarea stării avizelor şi recepţiilor (ATENŢIE!!! acest model e simplificat). În prima imagine s-a indicat că serviciul web “Articole” va fi apelat la modificările din tabelul de articole, doar pentru cele cu bifa self service. În tab-ul Coloane se vor trece coloanele a căror modificare de valoare va declanşa apelul serviciului web (în cazul de faţă: denumirea)
Pentru a doua imagine, serviciul web va fi apelat la modificarea stării unui aviz / recepţie (în tabul Coloane fiind o singură înregistrare cu Stare document). Spre deosebire de primul exemplu, interogarea tabelei publicate nu va avea loc cu ID-ul livrării. Se vor aduce toate ID-urile de articole din detaliile de aviz legate de master-ul a cărui stare s-a schimbat (respectând şi condiţia de validare). Serviciul web va fi apelat separat pentru fiecare articol în parte.
Log-ul de sincronizare
În log-ul de sincronizare sunt înregistrate toate modificările care au declanşat apeluri de servicii web. În continuare sunt prezentaţi toţi paşii care conduc către crearea unei înregistrări în log şi procesarea acesteia:
din interfaţa SocrateCloud se modifică denumirea unui articol
înainte de salvare, pe baza coloanelor indicate pentru declanşarea sincronizarii, se verifică dacă a intervenit o modificare de procesat
după salvare, dacă există modificări de procesat, se aplică şi validarea definită în tab-ul Tabele (articol self service)
daca se trece de validare se salvează în log o înregistrare noua (indicând serviciul web şi ID-ul articolului - coloana cheie)
este adăugată în lista de aşteptare o cerere de sincronizare
sincronizarea este executată după commit
Interpretarea log-ului
La crearea înregistrării câmpurile Data şi Răspuns sunt necompletate, iar Activ, Procesat şi Sincronizat fără bifă. Când se execută cererea de sincronizare (care primeşte ca parametrii serviciul web de apelat şi ID înregistrare pentru interogare tabelă publicată), se selectează toate log-urile cu parametrii de mai sus şi fără bifa de sincronizat. Pentru că utilizatorul apasă o singură dată pe salvare, dar intern înregistrarea poate fi salvată de mai multe ori, se creează mai multe intrări în log. Cum există o singură modificare, nu are rost să se apeleze serviciul web pentru fiecare salvare în parte. Apelul are loc doar pentru o înregistrare de log (cea activă). Celălalte devin inactive (sunt considerate şi procesate/sincronizate).
Log-ul activ devine şi procesat dacă a primit răspuns de la serviciul web apelat (indiferent care ar fi acesta). Dacă răspunsul este {“status”:”OK”}, log-ul este marcat ca fiind sincronizat. Toate intrările din log trebuie să fie sincronizate. În caz contrar, va porni un job de sincronizare din minut în minut. Câmpul Nr. istoric indică numărul de încercări de sincronizare. În mod normal, acesta trebuie să fie 1. Pentru a vedea cauza nesincronizării se poate consulta tabu-ul de istoric al log-ului. ThreadCount indică câte sincronizări erau active (în modulul care a procesat sincronizarea) la momentul procesării log-ului în cauză.
Câmpul Data este completat cu datele primite de la interogarea tabelei temporare, cu filtrare după ID Înregistrare. OBSERVAŢIE!!! În cazul modificării stării avizului, ID Înregistrare nu este ID-ul avizului, ci al unui articol din avizul respectiv (fiecare articol cu log-ul său).
Pentru a păstra ordinea salvărilor din baza de date şi în site, nu pot rula în acelaşi timp mai multe sincronizări cu acelaşi serviciu web şi ID Înregistrare. Toate log-urile în cauză vor fi procesate secvenţial.
Scheduler
Procesele “Șterge log sincronizare site” şi “Verificare log site nesincronizat” trebuie adăugate în scheduler. Primul va şterge log-ul mai vechi de numărul de zile specificat în parametri şi cel inactiv. Al doilea verifică dacă există log nesincronizat mai vechi de numărul de minute specificat în parametri. În caz afirmativ va trimite şi mail-uri de atenţionare către adresele specificate.
Page updated
Report abuse