Разлики

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

--- sluzebni:zashtita_nesinhronizirane [2017/12/06 09:24] – k.kyurkchieva
+++ sluzebni:zashtita_nesinhronizirane [2024/04/26 11:27] (текуща) – [Защита да не може да се стартират два синхронизационни сървиса в една база] t.lalova
@@ Ред 33: / Ред 33: @@
 {{: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.?]]*/
@@ Ред 50: / Ред 59: @@
 При изпращане на 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 документация

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

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

Разлики

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