Согласование данных в синхронизированных системах

У меня есть ситуация, когда одна система Oracle является мастером данных для двух отдельных систем CRM (PeopleSoft и Siebel). Система Oracle отправляет сообщения CRUD в BizTalk для получения данных о клиентах, данных о запасах, информации о продуктах и ​​ценах на продукты. BizTalk форматирует и пересылает сообщения в интерфейсы веб-служб PeopelSoft и Siebel для выполнения действий. После первоначальной синхронизации данных текущая операция создала ситуацию, когда данные в удаленных системах Siebel и PeopleSoft неточны, несмотря на успешную доставку данных (это еще один разговор о том, что эти системы имеют в виду, когда возвращают «Успех»). ' для BizTalk).

Что делают другие подобные реализации для согласования системных данных в этом подходе, ориентированном на распределенные службы? Делают ли они периодический дамп со всех систем для сравнения? Существуют ли какие-либо другие методы или методологии для обнаружения неудачных обновлений и обеспечения синхронизации?

Ваши мысли и опыт ценятся. Спасибо!

Дополнительная информация

Так почему же системы не синхронизированы? Всякий раз, когда целевая система подтверждает BizTalk, что она получила сообщение, это означает многое. Иногда HTTP 200 означает, что я получил его, поместил в промежуточную таблицу и через некоторое время зафиксирую. Иногда это удается, иногда нет из-за различных проблем с данными. Иногда HTTP 200 означает... да, я получил и передал данные. При использовании HTTP могут возникнуть проблемы с доставкой заказа. Все эти проблемы могли быть решены с помощью тщательного архитектурного планирования. Этого не было сделано. Отметки времени обновления/создания отсутствуют, чтобы не допустить, чтобы неупорядоченная доставка наступала на данные. Отсутствует полное двустороннее подтверждение приема данных из систем назначения. Все это приводит к тому, что вещи выходят из строя.


person Christian Loris    schedule 08.04.2009    source источник
comment
Можете ли вы объяснить, почему данные не синхронизируются? Я не уверен, что понимаю причину этого. -Брайан   -  person Bryan Corazza    schedule 16.04.2009
comment
Брайан – больше информации в посте. Спасибо за ответ.   -  person Christian Loris    schedule 17.04.2009


Ответы (1)


(извините, это ответ, а не комментарий, работающий до 50 баллов).

Можно ли обновлять данные в других системах или они по существу доступны только для чтения?
Не могли бы вы реализовать дополнительную проверку на уровне BizTalk, чтобы убедиться, что обновления не завершатся сбоем из-за проблем с данными? Можете ли вы получить какое-либо уведомление о сбое обновления от целевых систем, которое позволит вам компенсировать это на уровне BizTalk?

FWIW в таких ситуациях я обычно получаю центральное хранилище данных, которое содержит как минимум ключи данных из 3 систем, которые действуют как новый золотой репозиторий для данных, однако обычно это компенсирует несколько источников обновлений. Похоже, мы также обычно используем какую-то ручную очередь ошибок, которую должны поддерживать пользователи.

Что касается вашей идеи пакетного согласования, я видел, что это довольно распространено для компенсации транзакционных ошибок, особенно в сфере финансовых услуг.

person yieldvs    schedule 02.06.2009
comment
Без проблем. Весь смысл использования шины сообщений для отправки сообщений синхронизации заключался в том, чтобы избавиться от хлопот, связанных с еще одной системой для хранения основных записей. Даже если бы мы использовали подход с одним мастером, мы застряли бы на пакетном обновлении по ночам. Отсутствие ответов, кажется, действительно предполагает, что все части, участвующие в системе обмена сообщениями, должны соблюдать свои контракты, и это реальная проблема. На большом предприятии трудно заставить всех игроков делать это, особенно если у них ограниченный опыт работы с сервисно-ориентированными интерфейсами корпоративных приложений. - person Christian Loris; 04.06.2009