Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
28.04.2010, 11:39
|
|||
|---|---|---|---|
|
|||
Интеграция - захват изменений |
|||
|
#18+
Здравствуйте.Спасибо всем за обсуждение моего топика по Вопросам интеграции - он решен. Это будет SOA обмен общими данными между распределенными модулями (единая база как я понял из обсуждения требует мощного сервака который всю ее прокрутить без лагов от нагрузки). У нас такого нет, потому придется что-то в хранилище датацентра выносить, что-то у себя крутить.(MS Dynamics CRm все равно в своей базе вертится и нужно как то с ней меняться данными, а раз тут сервисами меняться будем, то и везде тогда так же). В чем проблема. Есть в црм клиент. Мы его выгрузили в другие системы. Он поменялся в црм, теперь нужно эти его изменения реплицировать на "подписчиков". это для примера - сущностей, которые нужно синхронизировать - несколько. Причем нужна трансформация данных - тут клиента с такими полями ждут, тут с другими. Вопрос: какие подходы есть по отслеживанию версионности и переносу данных ? Кто как делает такие штуки? Что думаете на по поводу этого и этого . >>Не грози Владимирскому Централу, попивая виски у себя в Лондоне ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.04.2010, 12:03
|
|||
|---|---|---|---|
Интеграция - захват изменений |
|||
|
#18+
Sysobjectsединая база как я понял из обсуждения требует мощного сервака который всю ее прокрутить без лагов от нагрузки такого вывода не слышал ни от кого. Вопросы по поводу нагрузки, оставшиеся без ответа, были. Речь идет о тысячах пользователей? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.04.2010, 12:15
|
|||
|---|---|---|---|
|
|||
Интеграция - захват изменений |
|||
|
#18+
iscrafmSysobjectsединая база как я понял из обсуждения требует мощного сервака который всю ее прокрутить без лагов от нагрузки такого вывода не слышал ни от кого. Вопросы по поводу нагрузки, оставшиеся без ответа, были. Речь идет о тысячах пользователей? Да. Пользователей ожидается несколько тысяч. Причем они будут неравномерно распределены по модулям - один будут использовать тысячи, второй - сотни. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.04.2010, 12:16
|
|||
|---|---|---|---|
Интеграция - захват изменений |
|||
|
#18+
Sysobjects тут клиента с такими полями ждут, тут с другими. :) вот и выходит, что ввязавшись в SOA вы не пропустите: - ключевого этапа при создании сервис-ориентированной системы - описания бизнес-процессов предприятия на языке BPEL . Руководство точно готово? :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.04.2010, 12:31
|
|||
|---|---|---|---|
Интеграция - захват изменений |
|||
|
#18+
Petro123, Ну по хорошему бизнес-процессы по любому необходимо описывать т.е. независимо от архитектуры, мы вот при построении DWH тоже их описываем + еще диаграммы потоков данных рисуем. Иначе нельзя, без этого потом никаких костей не собирешь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.04.2010, 12:40
|
|||
|---|---|---|---|
Интеграция - захват изменений |
|||
|
#18+
ПолковникPetro123, Ну по хорошему бизнес-процессы по любому необходимо описывать т.е. независимо от архитектуры, мы вот при построении DWH тоже их описываем + еще диаграммы потоков данных рисуем. Иначе нельзя, без этого потом никаких костей не собирешь. без SOA можно упростить, т.к. есть только учёт данных, но не бизнес-процессов. Сервисы - это прежде всего не данные, а БП. И делать их в НЕфилиально-распределённой фирме - нонсенс. Он хочет делать сервис без WSDL\BPEL\.... - смешно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.04.2010, 12:59
|
|||
|---|---|---|---|
Интеграция - захват изменений |
|||
|
#18+
WSDL,BPEL и т.п. - это варианты реализации. Возможно у ТС есть свой вариант реализации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.04.2010, 13:01
|
|||
|---|---|---|---|
Интеграция - захват изменений |
|||
|
#18+
Sysobjects, если есть возможность, то изменения лучше публиковать для определенного круга подписчиков. Сканирование логов и т.п. получается накладней и оправдано, имхо, если уж совсем нет никакой возможности вклинится в систему. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.04.2010, 13:04
|
|||
|---|---|---|---|
Интеграция - захват изменений |
|||
|
#18+
iscrafmWSDL,BPEL и т.п. - это варианты реализации. Возможно у ТС есть свой вариант реализации. ну да, есть ГОСТ, метрическая резьба, дюймовая, ... Главное чтобы не велосипедная. А то как твои Web-сервисы (К ПРИМЕРУ) будут другие использовать? Без контрактов - описаний? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.04.2010, 13:12
|
|||
|---|---|---|---|
Интеграция - захват изменений |
|||
|
#18+
Petro123А то как твои Web-сервисы (К ПРИМЕРУ) будут другие использовать? Без контрактов - описаний? об использовании другими речи не было. О вебе тоже. Зачем ТС городить огород, если без него можно обойтись. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.04.2010, 13:16
|
|||
|---|---|---|---|
|
|||
Интеграция - захват изменений |
|||
|
#18+
Система своя - коннектится со своей же. Разработка сейчас пока на уровне прототипа. Схемы бизнес процессов конечно же будут как и утвержденный контракт сервисов. В чем задача - сделать прототип, который синхронизирует некого коня в вакууме и другого некоего коня, отржающих один выбранный конкретный бизнес процесс, потому как обмены будут типовыми и прототип покрывает основную идею обмена. Потом конечно он будет допиливаться. будут умные схемы взаимодействия и описания контрактов, так что все нормально идет. Так что к сути - как организовываете обновление? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.04.2010, 13:25
|
|||
|---|---|---|---|
Интеграция - захват изменений |
|||
|
#18+
Sysobjects, все справочники должны вестись только в одном месте. Опытным путем доказано. Немного о синхронизации справочников есть в этой заметке . pi/\gr ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.04.2010, 13:37
|
|||
|---|---|---|---|
|
|||
Интеграция - захват изменений |
|||
|
#18+
Прочитал. Я и делаю - мастер система заведения клиентов, которая должна передать данные заинтересованным подписчикам для их работы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.04.2010, 13:52
|
|||
|---|---|---|---|
|
|||
Интеграция - захват изменений |
|||
|
#18+
Топология сети какая? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.04.2010, 14:23
|
|||
|---|---|---|---|
Интеграция - захват изменений |
|||
|
#18+
Кто как делает такие штуки? Со стороны мастер-системы генерируются события. Товарчик.Создался или Товарчик.Изменился , образно. Указывается в событии ключик, чтобы выцепить всю информацию об объекте. Событие обрабатывается интеграционной платформой. Запускается сценарий обработки, который трансформирует исходных объект и отправляет в те системы, которым он нужен. На пальцах - так. 1. Есть табличка events, в БД мастер-системы. Поля object_name, object_verb, object_key и прочие. При создании и изменении элемента справочника в эту табличку вставляется запись типа (Item, Update, 123456). 2. Эта табличка опрашивается на предмет новых записей раз в 10 сек. В зависимости от содержимого в object_name, выполняется набор селектов, формирующих образ Java-объекта. 3. Java-объект проверяется по набору правил и маршрутизируется в нуждающиеся системы. 4. Преобразовывается в соответствие с требованиями системы получателя, выполняются инсерты в БД получателя. Как-то так. Без SOA в чистом виде, веб-сервисов и прочего. Зато просто. Всю грязную работу делает инетгарционная платформа (IBM-овская). Это-же реализуется с Apache Camel в два счета. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.04.2010, 14:44
|
|||
|---|---|---|---|
|
|||
Интеграция - захват изменений |
|||
|
#18+
Для начала все сущности придется описать в терминах одной системы. Это может быть либо схема данных в случае обмена сообщениями, если использовать старый добрый SQL - можно ограничится набором вьюх и хранимых процедур, выходные данные которых стандартных для всех баз :). Далее на стороне мастер-базы и подписчиков либо рисуется маппинг полей по перекладыванию типовой схемы с специфическую для данного приложения и (или) пишутся (генерятся) обработчики на каждый тип взаимодействия. Это скажем так обязательная подготовительная часть. Далее определяемся - нужно ли нам синхронизировать изменения сразу и при ошибке на любом из подписчиков откатывать изменения везде (1), или синхронизацию можно провести позже - либо по требованию подписчика (2), либо принудительно с мастер-базы (3). Если нам нужен п. 1 - пишем заявление об увольнении или идем требовать повышения зарплаты раза этак в три звоним семье с просьбой не ждать домой месяцев этак шесть. Всем sql.ru дружно помогаем Вам в этом нелегком деле. Чур прототип на тестирование в первую очередь мне :). В случае п.2 и 3 все не так страшно. ЗП просим поднять всего то раза в полтора и приступаем к делу. Для начала нужно определится как будем понимать - изменилась запись или нет. Это может быть либо триггер, который записывает в лог, можно также ограничится полем "дата последнего изменения" и функцией, возвращающей хэш от всех значимых полей записи. Далее либо при запросе с подписчика (2), либо централизованно (3) обрабатываем все непереданные с определенной даты изменения. PS. Механизм передачи вообщем-то неважен, однако как человек ленивый и имеющий возможность работать через вьюхи и хранимые процедуры ни в жисть бы не стал писать такие вещи на SOA. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.04.2010, 14:59
|
|||
|---|---|---|---|
Интеграция - захват изменений |
|||
|
#18+
АгаМеханизм передачи вообщем-то неважен, однако как человек ленивый и имеющий возможность работать через вьюхи и хранимые процедуры ни в жисть бы не стал писать такие вещи на SOA. ну если все в одной БД или СУБД, то действительно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.04.2010, 15:01
|
|||
|---|---|---|---|
Интеграция - захват изменений |
|||
|
#18+
pilgr Как-то так. Без SOA в чистом виде, веб-сервисов и прочего. Зато просто. :) Назад в будущее. Скриншот покажи. Пользователи в чём выиграли? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.04.2010, 15:05
|
|||
|---|---|---|---|
Интеграция - захват изменений |
|||
|
#18+
iscrafmPetro123А то как твои Web-сервисы (К ПРИМЕРУ) будут другие использовать? Без контрактов - описаний? об использовании другими речи не было. О вебе тоже. Зачем ТС городить огород, если без него можно обойтись. то-то и оно что при такой широкой постановке вопроса (мркетинговый ход): WikiАрхитектура не привязана к какой-то определённой технологии. Она может быть реализована с использованием широкого спектра технологий, включая такие технологии как REST, RPC, DCOM, CORBA или веб-сервисы. SOA может быть реализована используя один из этих протоколов и, например, может использовать, дополнительно, механизм файловой системы, для обмена данными. у меня сегодня - SOA (REST) :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
28.04.2010, 15:07
|
|||
|---|---|---|---|
|
|||
Интеграция - захват изменений |
|||
|
#18+
iscrafmАгаМеханизм передачи вообщем-то неважен, однако как человек ленивый и имеющий возможность работать через вьюхи и хранимые процедуры ни в жисть бы не стал писать такие вещи на SOA. ну если все в одной БД или СУБД, то действительно. БД и сервера разные, а вот СУБД действительно одна - MS SQL. Впрочем не вижу никак препятствий для реализации того же функционала скажем в связке MS SQL - My SQL. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
start [/forum/topic.php?fid=33&mobile=1&tid=1548316]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
59ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
55ms |
get tp. blocked users: |
2ms |
| others: | 301ms |
| total: | 461ms |
| 0 / 0 |
