Здравствуйте, BillyBoy, Вы писали:

BB>ИМХО сама интеграционная шина должна следить за согласованностью. Вопрос — как?
Это невозможно. Шина не в состоянии определить, какие данных считаются согласованными.

BB>Шина отправила данные, получила подтверждение и забыла?
Да.

Проверять согласованность нужно в приемнике, в данном случае в 1С.
Только я бы сделал не "раз в сутки", а при записи каждого объекта. Если есть битые ссылки, не принимать, отправлять ошибку. Или, как вариант, ставить в очередь запрос на загрузку недостающих объектов. Но это будет маскировка ошибок. Лучше сигнализировать ошибки и напрягать ответственных, чтобы исправляли.

Добрый день!
Имеется мастер система, создающая DTOшки (упрощенные представления сущностей в мастер системе) и передающая их в интеграционную шину, которая в свою очередь передает данные в 1С и другие подсистемы.
В 1С для этих DTOшек создана staging area (по сути копия справочников интеграционной шины), из которой уже берутся необходимые данные и копируются в базу 1С.
Как видите, цепочка довольно длинная. Периодически возникают ошибки в каждом из звеньев этой цепочки.
Разработчики правят ошибки, но потом появляются новые.
Пока удалось выкрутиться с помощью костылей:
1) на стороне 1С раз в сутки запускается процесс, который ищет в staging area ссылки на несуществующие записи в связанных справочниках; после этого делаются запросы к интеграционной с uid'ами недостающих записей;
2) т.к. есть "корневые" справочники в иерархии справочников без указания на них ссылок, то для них придумана "витрина данных" на стороне мастер системы, отдающая uid записи и ее дату обновления; соответственно, на стороне 1С процесс, запускающийся раз в сутки, лезет в "витрину данных" и ищет расхождения, восстанавливая целостность данных.
Мне подобная схема не нравится (но реакция со стороны бухгалтерии и руководства мне не нравится еще больше ), хотелось бы каких-то внутренних механизмов проверки целостности без костылей. Разработчики ничего предложить не могут.
Поэтому обращаюсь к сообществу: как в указанной архитектуре снизить процент потери данных от мастер системы в подсистему и уменьшить время рассогласованности данных?
Примечание: для увеличения скорости обмена, он производится в асинхронном режиме, поэтому допускается небольшой интервал времени, в течение которого данные могут быть рассогласованы.

Здравствуйте, BillyBoy, Вы писали:

BB>Поэтому обращаюсь к сообществу: как в указанной архитектуре снизить процент потери данных от мастер системы в подсистему и уменьшить время рассогласованности данных?

Одно из грубых решений — при передаче какого-либо объекта в шину, передавать также и все объекты, на которые он ссылается, что-то вроде deep copy. Передавать, разумеется, в обратном порядке. Получаем согласованность ценой избыточности данных.

Если же подходить более серьезно, то нужно исправлять те самые "ошибки", из-за которых зависимый объект попадает в выгрузку раньше, чем тот, на который он ссылается. И не допускать новых.
Например, добавить к нужным сущностям флаг "выгружен в 1С" и ориентироваться на него.

Как радикальный вариант — избавиться от всех промежуточных звеньев (шина и т.п.)
Сделать read (slave) реплику основной базы, а 1С дать "интерфейс" в виде хранимок/вьюшек над этой репликой и пусть сама вычитывает с нужной периодичностью.

Другой вариант — перейти на push модель, вместо publish/subscribe.
Т.е. пусть не 1С слушает изменения в основной системе, а основная система пушит в 1С при возникновении изменений (исправлении ошибок и т.п.)

И еще мысль.
Если считать, что данные в основной базе всегда согласованы,
то не очень понятно, в какой момент возникает возможность для рассогласовывания в 1С:
в момент зачитки данных для выгрузки в шину, при трансформации в DTO, при обработке/записи на стороне 1С?
В чем источник проблемы: временной лаг на propagation изменений по шине, необходимость параллельной обработки потока изменений на 1С или у нас просто неудачная DTO-модель?

Здравствуйте, wildwind, Вы писали:

W>Здравствуйте, BillyBoy, Вы писали:

BB>>Поэтому обращаюсь к сообществу: как в указанной архитектуре снизить процент потери данных от мастер системы в подсистему и уменьшить время рассогласованности данных?

W>Одно из грубых решений — при передаче какого-либо объекта в шину, передавать также и все объекты, на которые он ссылается, что-то вроде deep copy. Передавать, разумеется, в обратном порядке. Получаем согласованность ценой избыточности данных.

Так уже пробовали, получается очень медленно, особенно это сказывается при высоких нагрузках.

Здравствуйте, RushDevion, Вы писали:

RD>Как радикальный вариант — избавиться от всех промежуточных звеньев (шина и т.п.)
RD>Сделать read (slave) реплику основной базы, а 1С дать "интерфейс" в виде хранимок/вьюшек над этой репликой и пусть сама вычитывает с нужной периодичностью.

Это действительно радикально. Но помимо 1С есть и другие подсистемы. Плюс 1С сама пушит данные в мастер систему.

RD>Другой вариант — перейти на push модель, вместо publish/subscribe.
RD>Т.е. пусть не 1С слушает изменения в основной системе, а основная система пушит в 1С при возникновении изменений (исправлении ошибок и т.п.)
Сейчас именно пушит мастер система.

RD>И еще мысль.
RD>Если считать, что данные в основной базе всегда согласованы,
Да, в основной всегда согласованы
RD>то не очень понятно, в какой момент возникает возможность для рассогласовывания в 1С:
RD>в момент зачитки данных для выгрузки в шину, при трансформации в DTO, при обработке/записи на стороне 1С?
RD>В чем источник проблемы: временной лаг на propagation изменений по шине, необходимость параллельной обработки потока изменений на 1С или у нас просто неудачная DTO-модель?
ошибки были при формировании дтошек, при отправке шиной, при приеме 1С...
ИМХО сама интеграционная шина должна следить за согласованностью. Вопрос — как?
Шина отправила данные, получила подтверждение и забыла?
Шина периодически опрашивает подсистемы и например на основании чексуммы находит расхождения?