Распутывая узлы интеграции: Построение архитектуры слабосвязанных систем, или Кролики наступают

О чем будем говорить?

• О типичных проблемах интеграции в проектах 1С и о том, как их решать.
• Я постараюсь донести до вас концепцию событийной интеграции и рассказать о том, насколько это хорошо и правильно.
• Мы рассмотрим паттерны решений различных проблем с помощью очередей.
• Я расскажу о нашей подсистеме Yellow RabbitMQ («Желтый кролик») – что это и как это «дружит» с 1С.

Как выглядит типовой корпоративный ландшафт?

Типовой корпоративный ландшафт сегодня – это зоопарк систем, где есть:

• База для ведения бухгалтерии;
• База НСИ;
• База для склада;
• Свой сайт;
• Все, что угодно.

Пример из жизни (торговая организация):

• В системе продаж продажники заводят контрагентов;
• В складской системе регистрируется запуск фур по каким-то заявкам;
• На сайте принимаются заказы клиентов;
• Работает своя система для учета звонков call-центра;
• Типовая база для ведения бухгалтерии;
• И тут же еще рядом «Зарплата и управление персоналом», куда сотрудникам падают премии за продажи.

Множество различных систем, и все это между собой интегрировано.

Когда на вход поступает задача все это разобрать и привести в какой-то «божеский» вид, чтобы все работало хорошо, – возникает каша в голове: кто, что, кому отправляет, в какой момент времени это возникает и т.д. Поэтому сначала этот клубок интеграций нужно распутать.

Типичные проблемы при интеграции множества систем

Какие типичные проблемы возникают при интеграции множества систем?

• Это – сильная связанность смежных систем между собой, обусловленная взаимозависимостью их компонентов. Она влияет:
  • На работоспособность этих систем;
  • На их реализацию.

Такое состояние, когда изменения в одной системе «ломают» другую систему, из-за чего в нее также приходится вносить изменения, как раз и называется «сильной связанностью».

• Кроме того, несобытийная интеграция с использованием «вытягивающего» интерфейса – это медленно. Нам приходится ждать, когда случится обмен, поэтому актуальные данные неизбежно запаздывают.
• И еще одна проблема – это непрозрачность потоков данных. Сложно однозначно сказать кто, когда, кому и что посылает.

Привычные средства интеграции в мире 1С

В мире 1С приняты следующие классические средства интеграции:

• Обмен файлами, который все любят – в одной системе кнопочку нажали, документы выгрузили, в другой – загрузили. Перепутали, загрузили какой-то не тот файл, поудаляли документы – все как обычно.
• Более «продвинутые пацаны» используют удаленные вызовы процедур (некие вызовы из системы в систему). Сюда относятся:
  • Веб-сервисы;
  • HTTP-сервисы;
  • COM/OLE.
• Некоторые используют прямой доступ к базе данных 1С – способ не очень красивый, но также распространенный. Залезают на SQL-сервер и что-нибудь из базы 1С вычитывают, или даже, не дай бог, туда пишут, притворяясь сервером 1С – такое тоже бывает.

Два типа интерфейсов

Существует два типа взаимодействия, два типа интерфейсов.

• Первый тип – это pull-интерфейсы, вытягивающие или «сосущие» интерфейсы. Это когда мы обращаемся в некую систему с целью забрать оттуда какие-то данные. Или опросить ее, нет ли у нее для нас каких-либо новостей, каких-либо изменений.
• И второй тип – это уведомляющие интерфейсы. Здесь ситуация полностью обратная: когда в какой-нибудь системе происходит событие (некий акт ввода данных), эта система уведомляет всех заинтересованных о том, что в ней что-то произошло.

Использовать «сосущий» вариант интерфейса – это неправильно, поскольку:

• В реальной жизни все события расположены на оси времени, поэтому подход к интеграции, основанный на том, что мы по таймеру опрашиваем какую-то систему, есть ли в ней что-нибудь для загрузки – заведомо противоестественный.
• В реальной жизни машина заезжает на склад, бухгалтер проводит документ и т.д. – все эти события происходят на оси времени, а не по опросу.
• Любая интеграция, построенная по вытягивающему, «сосущему» принципу – это неправильно, это – источник проблем.
  • Понятно, что иногда без этого не обойтись, но лучше стараться так не делать.

Интегрирующая среда

Когда систем становится много, обязательно возникает потребность в интегрирующей среде.

• Конечно, если у вас две системы, которые обмениваются по механизму «точка-точка», вам интегрирующая среда, скорее всего, не нужна, потому что особых проблем у вас пока что нет.
• Но если систем становится пять и более, вы неизбежно придете к тому, что все начнут обмениваться со всеми, и вы никогда не разберетесь, кто, кому, когда и что посылает. Поэтому наличие интегрирующей среды (специального отдельного программного компонента, который управляет взаимодействиями) – это суровая необходимость. Те, у кого такого компонента нет – живут неправильно.

Наличие интегрирующей среды обеспечивает:

• Слабую связанность систем. Мы можем вообще заменить одну систему на другую (например, убрать SAP и поставить 1С), а остальные клиенты этого даже не заметят.
• А также прозрачность. Например, когда вам нужно «распутать клубок», вы, глядя на административный интерфейс интегрирующего ядра, сможете понять:
  • Кто;
  • С кем интегрируется;
  • В каком формате;
  • Как часто;
  • А также измерить нагрузку на системы, возникающую в процессе обмена.

Без имени – нет предмета

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

Казалось бы, причем здесь интеграция?

Выделение потоков данных

А интеграция здесь вот причем. Перед ее реализацией нам обязательно нужно:

• Выделить все бизнес-процессы на своем предприятии (все их задокументировать).
• В каждом бизнес-процессе выделить потоки данных – что в бизнес-процесс приходит и что из него выходит.
• Каждому бизнес-процессу и каждому потоку данных дать четкое понятное имя:
  • Например, если у вас есть «Счета-фактуры» и «Счета-фактуры на аванс» – то это два разных потока данных, два разных имени, даже если сами документы совпадают между собой с точностью до атрибута.
• Все эти имена нужно тщательно задокументировать.

Распутываем клубок

После выделения потоков данных переходим к «распутыванию клубка»:

• Пытаемся отсортировать потоки данных – их все, как правило, можно отнести к трем категориям.
  • Нормативно-справочная информация.
  • Оперативные данные, «первичка» (то, что приходит из реального мира).
  • И порождаемые данные – это то, что выходит из бизнес-процесса.
• Итак, мы выделили все эти бизнес-потоки, дали им отдельные имена, написали их на бумажках и прикололи на доску. Дальше начинаем растаскивать эти бумажки по категориям – здесь у нас НСИ, здесь «первичка», здесь порождаемые данные. И следующим шагом определяем взаимосвязи между потоками. Чтобы это было легче делать, лучше рисовать диаграммы.
  • Data-Flow-диаграммы;
  • Или диаграммы сущность-связь, которые все знают.

Это – очень полезно, особенно с учетом того, что есть много бесплатных инструментов, которые позволяют удобно делать все эти диаграммы. Их можно хранить в том же GIT, как и другую документацию по проекту.

Уникальность НСИ

Отдельно хотелось бы остановиться на НСИ, потому что это – самая большая часть задачи, которая требует наведения порядка.

Существует масса подходов к наведению порядка в нормативно-справочной информации.

• Можно делать одну единую большую базу НСИ или много разных маленьких баз, в которых возникают факты – это не имеет большого значения.
• Самое главное, что вы должны делать, управляя нормативно-справочной информацией, – это обеспечить уникальность идентификации сущностей.
  • Вы должны четко понимать, что контрагент «Иванов» здесь и контрагент «Иванов Иван Иванович» здесь – это одно и то же.
  • А товар «Метла» здесь и товар «Метла» здесь – это два разных объекта, даже если кто-то назвал их одинаково.

То есть, система должна обеспечивать однозначную идентификацию объектов. По этому поводу есть замечательная статья Александра Масляева на Инфостарте Mom and Dad`s Misery. Если у вас проблемы с интеграцией по справочникам – обязательно ее прочитайте. Это прямо must read.

Инвертировать хранение

Следующее, на что нужно осмелиться – это реализовать инвертирование хранения. Это значит, что:

• Нужно хранить у себя собственную копию данных для каждой системы.
• Например, если вам нужно забирать из какой-то системы справочники, не надо постоянно к ней обращаться за этими данными, скопируйте эти справочники себе и обновляйте их по событию, когда в источнике они поменяются.
• Вы так развязываете системы между собой – когда вторая система «сломается», у вас не «встанет» обмен, первая система продолжит работать.
• Для этого нужно обеспечить обособленное хранение данных для обеих этих систем у себя и событийную интеграцию их между собой (обновление).
• Там, где это сделать нельзя, нужно использовать резервирование системы, чтобы бизнес-процессы не останавливались при сбоях.

Все есть событие

И последний момент из теории – «Все есть событие»:

• Ось времени реального мира – это ваш ориентир. Разбираясь с бизнес-процессом, разбираясь с интеграцией, которая потребуется для этого бизнес-процесса, всегда рисуйте себе таймлайн реального времени и отмечайте на нем:
  • Что;
  • В какой момент;
  • И в какой из систем происходит (или в каком-то отделе или корпорации).
• Задним числом ничего не бывает – машины времени не существует.
  • Попытки строить интеграцию, которая разрешает проведение задним числом – это выкапывание ямы самому себе. Даже перепроведение документов задним числом происходит сейчас – в прошлое бухгалтер не улетал.
  • Поэтому намного дешевле организационно запретить любые операции «задним числом», чем потом пытаться построить такую интеграцию, которая бы при изменении в прошлых периодах автоматически деактуализировала данные во всех смежных системах.
  • Лучше просто это запретить и сказать «Сторнируйте и все». Это будет реально дешевле, хотя и неизбежно встретит сопротивление.
• После того как мы выделили эти бизнес-события, происходящие в системе, мы должны разослать их всем заинтересованным.
• И по большому счету, нам больше ничего делать не нужно – задача интеграции на этом заканчивается.

Если бы все было так просто… на самом деле, здесь все только начинается.

Captain Rabbit to the Rescue!

Как же все-таки рассылать все эти события и как обеспечивать слабую связанность и быструю интеграцию между системами?

Существует высокопроизводительный промышленный сервер очередей, который называется RabbitMQ. В переводе, если кто не знает, это значит «кролик».

Этот сервер очередей позволяет организовать самые разные схемы взаимодействия систем между собой. Он:

• Высокопроизводительный;
• Отказоустойчивый;