Исправление ошибочной пересылки объектов в обменах на EnterpriseData
Коллеги добрый день! Прошу консультации
Реализую однонаправленный обмен EnterpriseData между несколькими базами БП3 актуальных релизов
Одна из баз названа Центральной (ЦБ) несколько баз названы периферийными (ПБ), из ЦБ в ПБ1-2-3-N переходят объекты при создании нового/модификации.
Есть ряд объектов которые имеют условную адресацию в обмене по Организации те при изменении в ЦБ эти объекты во все ПБ не идут а идут только в те где ведется требуемая Организация.
Отрабатываем Ситуацию :
1) Пользователь в ЦБ создал документ или справочник с Организацией1, Регистрация прошла на узел ПБ1.
2) Прошел обмен и Объект/Объекты пришли в ПБ1.
3) Пользователь сказал «Батюшки!» и резко изменил в ЦБ у объекта Организацию1 на Организацию2. Регистрация прошла на узел ПБ2.
4) Прошел очередной обмен и Объект/Объекты пришли в ПБ2.
Мы имеем технический инцидент когда в ПБ1 эти объекты лишние а в ПБ2 они нужны.
Первая мысль это ручной анализ самодельным отчетом собирающим данные по COM и ручная/ полуручная чистка в ПБ .
возможный вариант автоматизации этих ручных исправлялок – это сделать рег. задание которое раз в сутки ищет во всех ПБ модифицированные объекты из ЦБ (теоретически перенесенные) и если найден - сверяет на соответствие реквизита «Организация» , не соответствует – пишем в комментарий объекта/ журнал регистрации что объект тут лишний и помечаем на удаление.
Можно ли корректировку этой ситуации заложить в правила КД3 , есть ли типовые механизмы в EnterpriseData которые следят за этим?
Например в п.3 это будет повторная модификация элемента который уже недавно был отправлен в ПБ1, есть ли встроенные инструменты в EnterpriseData (или реализуемые в КД3) отслеживающие излишнюю «Динамику» объекта по обменам и позволяющие помечать на удаление объект в базе в которой он не нужен ?
Реализую однонаправленный обмен EnterpriseData между несколькими базами БП3 актуальных релизов
Одна из баз названа Центральной (ЦБ) несколько баз названы периферийными (ПБ), из ЦБ в ПБ1-2-3-N переходят объекты при создании нового/модификации.
Есть ряд объектов которые имеют условную адресацию в обмене по Организации те при изменении в ЦБ эти объекты во все ПБ не идут а идут только в те где ведется требуемая Организация.
Отрабатываем Ситуацию :
1) Пользователь в ЦБ создал документ или справочник с Организацией1, Регистрация прошла на узел ПБ1.
2) Прошел обмен и Объект/Объекты пришли в ПБ1.
3) Пользователь сказал «Батюшки!» и резко изменил в ЦБ у объекта Организацию1 на Организацию2. Регистрация прошла на узел ПБ2.
4) Прошел очередной обмен и Объект/Объекты пришли в ПБ2.
Мы имеем технический инцидент когда в ПБ1 эти объекты лишние а в ПБ2 они нужны.
Первая мысль это ручной анализ самодельным отчетом собирающим данные по COM и ручная/ полуручная чистка в ПБ .
возможный вариант автоматизации этих ручных исправлялок – это сделать рег. задание которое раз в сутки ищет во всех ПБ модифицированные объекты из ЦБ (теоретически перенесенные) и если найден - сверяет на соответствие реквизита «Организация» , не соответствует – пишем в комментарий объекта/ журнал регистрации что объект тут лишний и помечаем на удаление.
Можно ли корректировку этой ситуации заложить в правила КД3 , есть ли типовые механизмы в EnterpriseData которые следят за этим?
Например в п.3 это будет повторная модификация элемента который уже недавно был отправлен в ПБ1, есть ли встроенные инструменты в EnterpriseData (или реализуемые в КД3) отслеживающие излишнюю «Динамику» объекта по обменам и позволяющие помечать на удаление объект в базе в которой он не нужен ?
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
это 2 разных обмена, первый обмен ЦБ -> ПБ, второй если надо ПБ->ЦБ, если например обьекты создаются в ПБ и как раз в этом обмене должен быть анализ нужно ли переносить это в ЦБ или нет, вообще суть вопроса не раскрыта, в чем содержание разработки, разрабатываются собственные правила обмена или речь идет о попытки разрулить это через типовые правила, регистрацией объектов к обмену например, вариантов куча, без всяких костылей типа удалялок или com
(2) Добрый день!
обмен однонаправленный из ЦБ в несколько ПБ.
Объекты созданные в ПБ не будут переноситься в ЦБ.
Разрабатываются собственные правила обмена EnterpriseData для решения задачи из ТЗ .
В ТЗ много текста , я старался описать все моменты , если коротко то это задача
1) Организовать единое место ввода справочников в ЦБ , часть справочников будет переноситься только в те базы ПБ где они нужны
часть - безусловно во все с какими настроен обмен.
2)Организовать пересылку документов банковской выписки из ЦБ в целевые ПБ.
портировать 2 типовых документа банковской выписки из ЦБ в несколько ПБ , задача охватывает 2 документа и 15 справочников.
единого пространства НСИ для всех баз не предполагается. поэтому условная адресация (регистрация на нужном узле обмена) важна для ряда объектов.
в периферийных базах запретили записывать ряд справочников( контрагенты, договоры, банковские счета, физческие лица) и изменения делаются только в ЦБ.
например
Сделали в ЦБ Контрагента он никуда не переносится, но как только Контрагенту сделали Договор с организацией в базе ПБ1 то регистрируется на узле обмена с ПБ1 набор справочников Контрагент, Договор, банковские счета контрагента.
потом сказали "Ой" а организация то была не та .......
а Контрагент, Договор, Банковские счета уже в базе ПБ1.
я в этом вопросе пытаюсь для себя раскрыть как мне толковее бороться с последствиями этого "Ой" ,
как работает механизм очистки данныхКД3 (если таковой есть)?
как мне ошибочно переданные объекты удалять /метить на удаление в ПБ ?
обмен однонаправленный из ЦБ в несколько ПБ.
Объекты созданные в ПБ не будут переноситься в ЦБ.
Разрабатываются собственные правила обмена EnterpriseData для решения задачи из ТЗ .
В ТЗ много текста , я старался описать все моменты , если коротко то это задача
1) Организовать единое место ввода справочников в ЦБ , часть справочников будет переноситься только в те базы ПБ где они нужны
часть - безусловно во все с какими настроен обмен.
2)Организовать пересылку документов банковской выписки из ЦБ в целевые ПБ.
портировать 2 типовых документа банковской выписки из ЦБ в несколько ПБ , задача охватывает 2 документа и 15 справочников.
единого пространства НСИ для всех баз не предполагается. поэтому условная адресация (регистрация на нужном узле обмена) важна для ряда объектов.
в периферийных базах запретили записывать ряд справочников( контрагенты, договоры, банковские счета, физческие лица) и изменения делаются только в ЦБ.
например
Сделали в ЦБ Контрагента он никуда не переносится, но как только Контрагенту сделали Договор с организацией в базе ПБ1 то регистрируется на узле обмена с ПБ1 набор справочников Контрагент, Договор, банковские счета контрагента.
потом сказали "Ой" а организация то была не та .......
а Контрагент, Договор, Банковские счета уже в базе ПБ1.
я в этом вопросе пытаюсь для себя раскрыть как мне толковее бороться с последствиями этого "Ой" ,
как работает механизм очистки данныхКД3 (если таковой есть)?
как мне ошибочно переданные объекты удалять /метить на удаление в ПБ ?
Прикрепленные файлы:
ТЗ.docx
(3) А можно сделать регистрацию с каким то параметром чтобы в базу назначения объект пришел помеченным на удаление сразу?
мы нигде не хранили и не запоминали куда ошибочно прошлый раз отправили объект по ошибке.
те эту рассылку "удаления" сделать по всем кроме целевой?
суть моего вопроса - как эту задачу решать средствами и инструментами обмена EnterpriseData .
регламентное задание - это полностью самодельный велосипед, мне он понятен, но может быть велик то и не нужен?
мы нигде не хранили и не запоминали куда ошибочно прошлый раз отправили объект по ошибке.
те эту рассылку "удаления" сделать по всем кроме целевой?
суть моего вопроса - как эту задачу решать средствами и инструментами обмена EnterpriseData .
регламентное задание - это полностью самодельный велосипед, мне он понятен, но может быть велик то и не нужен?
Разрабатываются правила для КД3, но механизм очистки данных я не закладывал в них .
в КД2 есть ПравилаОчисткиДанных - это довольно редко востребованный механизм я его никогда не использовал.
если я точно понял рекомендацию от коллеги с Лансера то чтобы не городить велосипед мне сейчас надо использовать аналогичный механизм на КД3.
если были для этой цели в КД2 ПравилаОчисткиДанных то наверное КД3 не менее функциональна и лучше эту задачу действительно решать правилами а не городить свои "Корявки" на регламентных заданиях через COM.
Посоветуйте материалы по КД3.
в КД2 есть ПравилаОчисткиДанных - это довольно редко востребованный механизм я его никогда не использовал.
если я точно понял рекомендацию от коллеги с Лансера то чтобы не городить велосипед мне сейчас надо использовать аналогичный механизм на КД3.
если были для этой цели в КД2 ПравилаОчисткиДанных то наверное КД3 не менее функциональна и лучше эту задачу действительно решать правилами а не городить свои "Корявки" на регламентных заданиях через COM.
Посоветуйте материалы по КД3.
Добрый день. Вы можете регистрировать объекты для выгрузки сразу во все базы, а принадлежность к организации проверять в событиях правил обработки данных. Тогда в случае, если объект не должен выгружаться, будет послано удаление объекта.
Надо смоделировть, что отправляется в переферийную, при обычной пометке на удаление.
(если я правильно помню. Объект так-же регистрируется и при обмене, в плане обмена.
считывается его реквизит пометка удаления, от этого отправляется в составе xml "Удаление документа", +- возможно называется по другому.
Соответственно нужно, продублировать этот механизм не для пометки удаления, а для того документа где меняется реквизит.
В случае загрузки, если этот документ, не будет найден в переферийных базах он будет пропущен, а не вылетит с ошибкой. А удалится только из тех баз, где он существует пользователи бывают ошибаются дважды и трижды и возможно этот документ существует в других базах. Для базы же где он должен присутсвовать эту логику отключить. И при выгрузке "удаление данных не будет отправлено"
В общем мое предложение заключается в том, чтобы прописать в правилах из центральной базы, служебный реквизит, отправить удаление во все базы. и заполнять его при смене организации например. Затем в правилах оттолкнуться от этого реквизита, и продублировать бизнес логику генерации записи "удаление объекта во всех переферийных базах".
ну или такой вопрос решается управленчески.
Ошибся. (запрет редактирования кроме пометки удаления) генерация нового
(если я правильно помню. Объект так-же регистрируется и при обмене, в плане обмена.
считывается его реквизит пометка удаления, от этого отправляется в составе xml "Удаление документа", +- возможно называется по другому.
Соответственно нужно, продублировать этот механизм не для пометки удаления, а для того документа где меняется реквизит.
В случае загрузки, если этот документ, не будет найден в переферийных базах он будет пропущен, а не вылетит с ошибкой. А удалится только из тех баз, где он существует пользователи бывают ошибаются дважды и трижды и возможно этот документ существует в других базах. Для базы же где он должен присутсвовать эту логику отключить. И при выгрузке "удаление данных не будет отправлено"
В общем мое предложение заключается в том, чтобы прописать в правилах из центральной базы, служебный реквизит, отправить удаление во все базы. и заполнять его при смене организации например. Затем в правилах оттолкнуться от этого реквизита, и продублировать бизнес логику генерации записи "удаление объекта во всех переферийных базах".
ну или такой вопрос решается управленчески.
Ошибся. (запрет редактирования кроме пометки удаления) генерация нового
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот