SelMatic ERP документация

Страницата е само за четене. Може да разглеждате кода, но не и да го променяте. Обърнете се съм администратора, ако смятате, че това не е редно.
====== Синхронизация ======
/* [[vavedenie:kakvo_novo|релийз 2015.8]] */

Стандартно, за да бъде синхронизиран даден документ с друг ком модул, различен от този, в който е създаден, трябва в конфигурацията на общите обекти за синхронизиране, да е настроена **поне една от двойките обект/контрагент за източник/посредник/получател** от документа **да съвпада с настройката на синхронизацията**. \\
Когато се работи с много обекти, включително клиентски и т.н., поддържането на тази конфигурация е много трудно. В резултат, може да се окаже, че централната база не съдържа всичко, което се съдържа по ком модулите и това би могло да е предпоставка за загуба на данни. \\
/*До момента в таблицата за настройки кой ком модул от кои обекти се интересува беше задължително да се задават собственик и обект. Т.е. ако трябва ком модул да се интересува от всички собственици/обекти, то в тази таблица е необходимо да се въведат много редове.*/

**Въвеждането на Собственик и Обект НЕ е задължително**. В този случай се приема, че **ком модула се интересува от всички собственици и техните обекти**. За да може те да се синхронизират в таблицата за настройки на ком модулите е достатъчно да се въведе един ред за ком модула, без да се задава собственик и обект. \\
Възможно е да попълните и **само Собственик**, тогава пак ще се имат предвид **всички обекти на собственика**. При наличие на съществуващи записи, ако се създават нови обекти, към съществуващите редове в таблицата за настройки на ком модулите се добавя един ред с посочен ком модула, който ще се интересува и от новите обекти.

При свързване към базата данни на ЕРП системата се извършва проверка в ехе-то, **дали има създадени връзки за осъществяване на синхронизация**, съответно и синхронизационни тригери. При **липса** на такива тригери свързването към базата данни **не е разрешено**. Тази ситуация налага намеса на отдел Поддръжка.

/* От [[vavedenie:kakvo_novo|релийз 2016.1]] стартирането на синхронизацията от главната форма е коригирана, така че да не е през POSTEVENT, а както Мониторинга за синхронизация. Ако в [[sluzebni:potrebiteli_i_prava:grupovi_politiki:grupi_dostavchici|груповите политики]] са попълнени Други/Мониторинг на синхронизацията/URL и порт - тогава чрез TCPClient се извиква метода на сървиса за стартиране на синхронизация. */ 

Ако в [[sluzebni:potrebiteli_i_prava:grupovi_politiki:grupi_dostavchici|груповите политики]] са попълнени Други/Мониторинг на синхронизацията/URL и порт - тогава чрез TCPClient се извиква метода на сървиса за стартиране на синхронизация. 

/* С излизане на [[vavedenie:kakvo_novo|релийз 2016.12]] е **премахнато показването на статуса на нишките за евенти**, тъй като визуализирането им беше причина в синхронизационния клиент статусът им да не се обновява, ако при изпълнение на синхронизацията някои ком модули са били спрени или с грешка при стартиране на синхронизационния сървис. \\
**Промяната изисква смяна на синхронизационния сървис.** */

**Статусът на нишките за евенти не се показва**, тъй като визуализирането им причинява не обновяване на статуса им в синхронизационния клиент, ако при изпълнение на синхронизацията някои ком модули са били спрени или с грешка при стартиране на синхронизационния сървис. \\
**Това изисква смяна на синхронизационния сървис в релийзи след 2016.12 включително.**

==== Защита да не може да се стартират два синхронизационни сървиса в една база ====
/*[[vavedenie:kakvo_novo|релийз 2017.?]]*/

При работа със синхронизация е важно да се осигури правилното й функциониране, което включва и защита от това, да се изпълни един лог два пъти.

Ако се стартират два сървиса върху една и съща база и има настройка за "онлайн" синхронизация, е възможно и двата сървиса да се опитат по едно и също време да изпълнят един и същ лог, което може да доведе до множество грешки. \\
Поради тази причина е реализирана защита **да не може да се стартират два синхронизационни сървиса в една база**.

В приложението за настройка на синхронизацията (**Конфигурация на синхронизацията/Конфигурация**) е има поле **"Hash на синхр.сървис"**. Ако има стартиран сървис това поле се попълва и при втори опит за пускане на друг сървис се прави проверка има ли данни в него. Ако то в попълнено не се разрешава стартирането на втори сървис.

{{:sluzebni:konfiguracia_na_sinhronizaciata_-_hash_service.png?600|}}


В настройките на синхронизацията в ERPSyncConfig.exe за TCP timeout е зададено по подразбиране 3 секунди.

{{:sluzebni:image_5_.png|}}

В случай, че има ком модули на други машини, тестването на връзката до тях отнема време, докато изтече timеout-a. Това обаче би довело до забавяне в отговора, ако няма връзка и това да забави тестването дали евентите работят (ползва се същия TCP timeout). Те всъщност работят, но това се разбира след повече от 3 секунди и това може да доведе до заблуда, че не работят.

За целта времето може да се увеличи на 10 сек и в този случай, вече не би имало подобно забавяне, тъй като има достатъчно време, за да се тестват и евентите и да се види, че работят. \\
Всичко все пак зависи и от самата мрежа и колко и кои са недостъпните ком модули. Възможно е да са достатъчни и 3 секунди, както е по подразбиране.
==== Възможност за получаване на автоматично съобщение (e-mail) при грешка в синхронизацията ====
/*[[vavedenie:kakvo_novo|релийз 2017.?]]*/

В практиката при наличие на синхронизация се случва да се получават грешки (изключение са ситуациите, когато няма връзка с дадена база) и тъй като от страна на клиента никой не наблюдава постоянно дали всичко се синхронизира успешно, обикновено те се разбират на по-късен етап, когато е необходима спешно намеса на отдел Поддръжка.

Поради тази причина, за да може да се оправя синхронизацията своевременно без намесата на потребителя и още преди той да е разбрал, че има някакъв проблем, е реализирана **възможност за автоматично известяване за проблем чрез изпращане на e-mail**. \\
На база e-mail-а директно се създава задача в JIRA за грешката в изпълнението на лога.

За прилагане на e-mail известяването в **конфигуриращото екзе на синхронизационния сървис** (ERPSyncServiceConfig.exe) са налични **полета за пощенски сървър, порт, адреси (e-mail -и) на изпращача (с парола) и получателя/ите**. 

{{:sluzebni:konfiguracia_na_sinhr.usluga-postenski_server.png?500|}}

<box round red|Важно:> За да се използва тази функционаност трябва **до екзето на сървиса** да се намират файловете **libeay32.dll** и **ssleay32.dll**. </box>


При изпращане на e-mail-ите не се дублират съобщенията за една и съща грешка. Сървисът създава до себе си файл с име като неговото и разширение .log и в него записва за кои номера на лог е изпратил писма. \\
По този начин се гарантира, че за дадена грешка се изпраща мейл само веднъж.

==== Подразбираща се стойност за Приоритет на лог при синхронизация ====

При наличие на синхронизация, е реализирана възможност да се задава подразбираща се стойност за **Приоритет на лог**. \\ Това не се прави ръчно, а автоматизирано с къстамизация.

Настройването на подобен приоритет се извършва много внимателно, особено на таблици, които зависят една от друга - трябва винаги да се задава еднакъв приоритет на всички таблици в логическата група, иначе може да се получи разместване на синхронизационния лог.\\
Например таблиците за себестойност и СДЦ трябва винаги да имат еднакъв приоритет, за да се попълват в правилния ред. Същото важи и за таблиците, които формират ТД също - хедър, детайли, серийни номера, снапшот и т.н.
==== Създаване на лог за GDPR и при вмъкване, и при ъпдейт на запис при наличие на синхронизация ====

Стандартно, при създаване на лог за GDPR от ком модулите се създава заявка за лога, която да се изпрати в централата, за да може целия GDPR да е налице само в централата.\\
Ако по време на синхронизацията обаче прекъсне връзката е възможно записът в лога да се запише и последствие да се опита отново да предаде лога, което води до грешка в синхронизацията.\\
За целта е направена промяна в процедурата за създаване на лог да не е само при вмъкване (insert into), а и при ъпдейт (update).


Вижте още: [[supto:sigurnost:synchronizacia|Синхронизация на данни - технология, конфигурация, мониторинг]]; [[sluzebni:monitoring_na_sinhronizacia|Мониторинг на синхронизация - основни положения]]; [[sluzebni:potrebiteli_i_prava:grupovi_politiki:tab_global#Мониторинг на синхронизацията|Групови политики/Други - при вграден Мониторинг на синхронизацията]];
SelMatic ERP документация

Инструменти за потребители

Инструменти за сайта

Инструменти за страници
