Народ, покритикуйте идею интеграции

[ziva]

Цитата:

Сообщение от imir

Исходная задача стоит так ....

У меня было подобное решение с работающим прототипом в логистическом контуре.
Вкратце (для знатоков 1С - прослеживается прямая аналогия с УРБД ):
Каждая инсталляция имеет свой диапазон RecId.
Все используемые таблицы разделяются на три типа:
1) master - суть документы/операции (LedgerJournalTable, SalesTable, ...). Их вводит пользователь на каждой из инсталляций Ах. Весьма подходят таблицы с TableGroup = WorksheetHeader
2) slave (строки документов, порожденные мастером записи - документы и проводки - LedgerJournalTrans, SalesLine, CustInvoiceJour, CustInvoiceTrans, MarkupTrans, LedgerTrans ….). Весьма подходят таблицы с TableGroup = WorksheetLine, Transaction
3) setup - настроечные (параметры модулей, группы, и прочее). Весьма подходят таблицы с TableGroup = Miscellaneous, Parameter, Group, Main.

Итак, приложения должны на всех инсталляциях быть идентичными.
Таблицы с типом ‘setup’ идут только из центра по всем периферийным инсталляциям. Никаких изменений их на периферии. Таким образом получаем централизованное управление настройками и правами.

Остальное может "гулять" в соответствии с настроенными правилами – каждая периф.инсталляция имеет свой диапазон значений RecId (по RecId master записи всегда можно понять откуда свалился документ). По мере выполнения транзакций в инсталляциях ведётся лог тех записей которые были изменены (например был создан, изменен, и разнесен SalesTable) – из него выцепляются master-записи, и уже потом определяются те slave которые нужно с ними тянуть. Дальше транспорт решает куда этот пакет данных девать и как. Кроме того, чтобы были целостные inventSum и прочие, по сути возникает log shipping – ненарушаемая последовательность документов которые необходимо вставить из одной инсталляции в другую (например для неотрицательно физ склада закупка должна прийти раньше чем заказ). Но это уже опционально

Конечно возникает ряд вопросов – например с сопоставлением, закрытием склада. Но они решаемые при должном административном ресурсе и определенном количестве серого вещества.

Прототип где-то пылится - разработка велась года 4 назад. Там была Ах3 и соответственно диапазонов RecId не хватало чтобы сделать масштабное решение. Кроме того не было возможности повесить триггер на изменение (создание\удаление) любой записи - приходилось выкручиваться средствами БД. В АХ2009й проблемы с диапазоном RecId и перехватыванием событий нет – так что решение вполне жизнеспособно.

Примерный срок реализации такого решения - 3-4 месяца (*2 чела), с учётом того что есть безглючный транспорт (.NET Remoting).

Вообщем вот вам ещё один вариант реализации этой задачи. Остальное сами додумывайте.