Разлики

Тук са показани разликите между избраната и текущата версия на страницата.

--- sluzebni:zashtita_nesinhronizirane [2017/10/09 11:06] – [Възможност за получаване на автоматично съобщение (e-mail) при грешка в синхронизацията] t.lalova
+++ sluzebni:zashtita_nesinhronizirane [2024/04/26 11:27] (текуща) – [Защита да не може да се стартират два синхронизационни сървиса в една база] t.lalova
@@ Ред 1: / Ред 1: @@
 ====== Синхронизация ======
-[[vavedenie:kakvo_novo|релийз 2015.8]]
+/* [[vavedenie:kakvo_novo|релийз 2015.8]] */
-Стандартно, за да бъде синхронизиран даден документ с друг ком модул, различен от този, в който е създаден, трябва в конфигурацията на общите обекти за синхронизиране, да е настроена **поне една от двойките обект/контрагент за източник/посредник/получател** от документа **да съвпада с настройката на синхронизацията**.
+Стандартно, за да бъде синхронизиран даден документ с друг ком модул, различен от този, в който е създаден, трябва в конфигурацията на общите обекти за синхронизиране, да е настроена **поне една от двойките обект/контрагент за източник/посредник/получател** от документа **да съвпада с настройката на синхронизацията**. \\
-Когато се работи с много обекти, включително клиентски и т.н., поддържането на тази конфигурация е много трудно. В резултат, може да се окаже, че централната база не съдържа всичко, което се съдържа по ком модулите и това би могло да е предпоставка за загуба на данни.
+Когато се работи с много обекти, включително клиентски и т.н., поддържането на тази конфигурация е много трудно. В резултат, може да се окаже, че централната база не съдържа всичко, което се съдържа по ком модулите и това би могло да е предпоставка за загуба на данни. \\
-До момента в таблицата за настройки кой ком модул от кои обекти се интересува беше задължително да се задават собственик и обект. Т.е. ако трябва ком модул да се интересува от всички собственици/обекти, то в тази таблица е необходимо да се въведат много редове.
+/*До момента в таблицата за настройки кой ком модул от кои обекти се интересува беше задължително да се задават собственик и обект. Т.е. ако трябва ком модул да се интересува от всички собственици/обекти, то в тази таблица е необходимо да се въведат много редове.*/
-С цел оптимизиране начина на работа е направено  така, че **въвеждането на Собственик и Обект вече да НЕ е задължително**. В този случай се приема, че **ком модула се интересува от всички собственици и техните обекти**. За да може те да се синхронизират в таблицата за настройки на ком модулите е достатъчно да се въведе един ред за ком модула, без да се задава собственик и обект.
+**Въвеждането на Собственик и Обект НЕ е задължително**. В този случай се приема, че **ком модула се интересува от всички собственици и техните обекти**. За да може те да се синхронизират в таблицата за настройки на ком модулите е достатъчно да се въведе един ред за ком модула, без да се задава собственик и обект. \\
-Възможно е да попълните и **само Собственик**, тогава пак ще се имат предвид **всички обекти на собственика**. При наличие на съществуващи записи, ако се създават нови обекти, към съществуващите редове в таблицата за настройки на ком модулите се добавя един ред с посочен ком модула и той вече ще се интересува и от новите обекти.
+Възможно е да попълните и **само Собственик**, тогава пак ще се имат предвид **всички обекти на собственика**. При наличие на съществуващи записи, ако се създават нови обекти, към съществуващите редове в таблицата за настройки на ком модулите се добавя един ред с посочен ком модула, който ще се интересува и от новите обекти.
 При свързване към базата данни на ЕРП системата се извършва проверка в ехе-то, **дали има създадени връзки за осъществяване на синхронизация**, съответно и синхронизационни тригери. При **липса** на такива тригери свързването към базата данни **не е разрешено**. Тази ситуация налага намеса на отдел Поддръжка.
-От [[vavedenie:kakvo_novo|релийз 2016.1]] стартирането на синхронизацията от главната форма е коригирана, така че да не е през POSTEVENT, а както Мониторинга за синхронизация. Ако в [[sluzebni:potrebiteli_i_prava:grupovi_politiki:grupi_dostavchici|груповите политики]] са попълнени Други/Мониторинг на синхронизацията/URL и порт - тогава чрез TCPClient се извиква метода на сървиса за стартиране на синхронизация.
+/* От [[vavedenie:kakvo_novo|релийз 2016.1]] стартирането на синхронизацията от главната форма е коригирана, така че да не е през POSTEVENT, а както Мониторинга за синхронизация. Ако в [[sluzebni:potrebiteli_i_prava:grupovi_politiki:grupi_dostavchici|груповите политики]] са попълнени Други/Мониторинг на синхронизацията/URL и порт - тогава чрез TCPClient се извиква метода на сървиса за стартиране на синхронизация. */
-С излизане на [[vavedenie:kakvo_novo|релийз 2016.12]] е **премахнато показването на статуса на нишките за евенти**, тъй като визуализирането им беше причина в синхронизационния клиент статусът им да не се обновява, ако при изпълнение на синхронизацията някои ком модули са били спрени или с грешка при стартиране на синхронизационния сървис. \\
+Ако в [[sluzebni:potrebiteli_i_prava:grupovi_politiki:grupi_dostavchici|груповите политики]] са попълнени Други/Мониторинг на синхронизацията/URL и порт - тогава чрез TCPClient се извиква метода на сървиса за стартиране на синхронизация.
-**Промяната изисква смяна на синхронизационния сървис.**
+/* С излизане на [[vavedenie:kakvo_novo|релийз 2016.12]] е **премахнато показването на статуса на нишките за евенти**, тъй като визуализирането им беше причина в синхронизационния клиент статусът им да не се обновява, ако при изпълнение на синхронизацията някои ком модули са били спрени или с грешка при стартиране на синхронизационния сървис. \\
+**Промяната изисква смяна на синхронизационния сървис.** */
+**Статусът на нишките за евенти не се показва**, тъй като визуализирането им причинява не обновяване на статуса им в синхронизационния клиент, ако при изпълнение на синхронизацията някои ком модули са били спрени или с грешка при стартиране на синхронизационния сървис. \\
+**Това изисква смяна на синхронизационния сървис в релийзи след 2016.12 включително.**
 ==== Защита да не може да се стартират два синхронизационни сървиса в една база ====
-/[[vavedenie:kakvo_novo|релийз 2017.?]]/
+/*[[vavedenie:kakvo_novo|релийз 2017.?]]*/
 При работа със синхронизация е важно да се осигури правилното й функциониране, което включва и защита от това, да се изпълни един лог два пъти.
@@ Ред 24: / Ред 29: @@
 Поради тази причина е реализирана защита **да не може да се стартират два синхронизационни сървиса в една база**.
-В приложението за настройка на синхронизацията (**Конфигурация на синхронизацията/Конфигурация**) е добавено ново поле **"Hash на синхр.сървис"**. Ако има стартиран сървис това поле се попълва и при втори опит за пускане на друг сървис се прави проверка има ли данни в него. Ако то в попълнено не се разрешава стартирането на втори сървис.
+В приложението за настройка на синхронизацията (**Конфигурация на синхронизацията/Конфигурация**) е има поле **"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.?]]/
+/*[[vavedenie:kakvo_novo|релийз 2017.?]]*/
 В практиката при наличие на синхронизация се случва да се получават грешки (изключение са ситуациите, когато няма връзка с дадена база) и тъй като от страна на клиента никой не наблюдава постоянно дали всичко се синхронизира успешно, обикновено те се разбират на по-късен етап, когато е необходима спешно намеса на отдел Поддръжка.
 Поради тази причина, за да може да се оправя синхронизацията своевременно без намесата на потребителя и още преди той да е разбрал, че има някакъв проблем, е реализирана **възможност за автоматично известяване за проблем чрез изпращане на e-mail**. \\
-На база e-mail -а директно се създава задача в JIRA за грешката в изпълнението на лога.
+На база e-mail-а директно се създава задача в JIRA за грешката в изпълнението на лога.
-За прилагане на e-mail известяването в **конфигуриращото екзе на синхронизационния сървис** (ERPSyncServiceConfig.exe) са добавени **полета за пощенски сървър, порт, адреси (e-mail -и) на изпращача (с парола) и получателя/ите**.
+За прилагане на e-mail известяването в **конфигуриращото екзе на синхронизационния сървис** (ERPSyncServiceConfig.exe) са налични **полета за пощенски сървър, порт, адреси (e-mail -и) на изпращача (с парола) и получателя/ите**.
 {{:sluzebni:konfiguracia_na_sinhr.usluga-postenski_server.png?500|}}
@@ Ред 43: / Ред 57: @@
-Съобразено е при изпращане на e-mail-ите да не се дублират съобщенията за една и съща грешка. Сървисът създава до себе си файл с име като неговото и разширение .log и в него записва за кои номера на лог е изпратил писма. \\
+При изпращане на 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 документация

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

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

Разлики

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