Согласование данных в синхронизированных системах - PullRequest
0 голосов
/ 09 апреля 2009

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

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

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

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

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

1 Ответ

1 голос
/ 02 июня 2009

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

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

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

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

...