Кстати, о картинках. Хотелось бы показать вам их в статье, но все картинки, имеющие отношение к делу, под NDA, поэтому будет много букв. Итак, поехали.

С чего всё началось

Довелось мне тут делать интересный проект. Интересно в нём было всё, начиная с того, откуда он вообще появился. Как вам такая математическая задачка:

Из состава некоего холдинга Х выходит группа компаний Y со скоростью 1000 км/сек...

То есть задача была обособить все процессы и структуры группы компаний Y от холдинга Х в максимально сжатые сроки. В том числе и все ИТ-решения. В том числе, само собой, и все системы 1С.

И, казалось бы – ну обособить и обособить, чего сложного? Найдем мы на своих серверах место под ваши базы 1С и всё остальное. А, нет. Базы 1С то находятся у холдинга Х. И доступ к ним он предоставляет по SaaS модели. Ну то есть: заходите в 1С в режиме предприятия, смотрите – это пожалуйста. Но в конфигуратор мы вас не пустим и архивы баз передать не сможем.

Кроме того, в числе баз, которые нужно было обособить, числилось несколько самописных систем (вот прямо натурально с нуля), которыми активно пользовался фронт-офис. Это, так называемые, системы биллинга (и по совместительству оперативного бюджетирования) фронт-офиса. Отключение их, даже на короткий промежуток времени (особенно в периоды закрытия месяца) чревато откатом в каменный век бесконечных ручных сверок, ручных выставлений счетов и огромными потерями в рублевом эквиваленте, т.к. все данные биллинга нужны в оперативном режиме. Вместе с этим предстояло забрать классический «посмертный» бухучет, ЗУП и еще пару мелочей вроде вялотекущего документооборота и бюджетов бэк-офиса.

Есть ли у нас план?

Было решено разделить проект переноса на три последовательных спринта: 

• документооборот, бюджеты бэк-офиса

• бухгалтерия, зарплаты и казначейство

• биллинг, бюджеты фронт-офиса

Первый спринт преодолели относительно без проблем. Не буду тут про него писать, ибо к теме статьи не относится.

Когда мы планировали второй спринт – пришло понимание, что какое-то время (4-6 месяцев) группа компаний Y будет жить по принципу «одна нога здесь, другая там». То есть весь бэк-офис (бухгалтерия, зарплаты и казначейство) переходит к нам, а весь фронт-офис со своим оперативным биллингом пока остается на облаке у холдинга Х. Между этими двумя частями есть связь – фронт отдает бэку данные о полученных и выставленных счетах для отражения этих операций в бух учете. Тогда и родилась идея реализовать решение с незатейливым кодовым названием «временная интеграция».

Тому, что интеграция будет временной, способствовали следующие факторы:

• Нужно было сделать быстро, т.к время на перенос всех сервисов было очень ограниченно.

• Не было возможности самостоятельно проводить работы на поляне холдинга Х. Но была договоренность с их ИТ-службой о предоставлении нам помощи в виде консультаций и возможно даже о проведении каких-то небольших доработок систем холдинга Х.

• В конце концов, это решение должно прожить 6-8 месяцев, пока мы не завершим перенос полностью.

Сложности и успехи коммуникаций

Я до сих пор помню, с каким видом на меня смотрели коллеги из ИТ-службы холдинга Х, когда я в первый раз заговорил о том, что нам совместно в рамках проекта таки придется делать интеграцию. По реакции было видно - коллеги рассчитывали на то, что мы быстренько сгрузим всё своё из их систем в ексель и уйдем. Беда была в том, что фронт-офису холдинга Y было некуда уходить – системы-то самописные.

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

В следующую пару недель мы разбирались с тем, что где лежит в их системе. Благо коллеги из холдинга не игнорировали наши вопросы и действительно помогали с пояснениями. В общем, к концу второй недели у меня на руках был текст запроса из консоли, который выбирает нужные нам данные в одну таблицу (124 колонки, между прочим – на момент первой версии запроса). Вместе с этим у меня было понимание, что мы даже с помощью адм. ресурса не сможем продавить решение, чтобы холдинг Х в своей системе делал механизм регистрации изменений и всю остальную красивую типовую его обвязку ради группы компаний Y, которая уже одной ногой вышла из контура.

Любая проблема решается просто. Если простое решение не проходит, ищи еще более простое (С) Джейсон Стэтхэм

Мы договорились о том, что холдинг Х в своей системе делает:

1. Константу, которая хранит текст нужного нам запроса,

2. В консоли запросов три дополнительных кнопки:

• получить текст запроса из константы

• сохранить текст запроса в константу

• выгрузить результат запроса в файл (функция ЗначениеВФайл)

3. Регл задание, которое раз в час выполняет запрос из константы и сохраняет его на SFTP ресурсе.

Это всё, что нам оказалось нужно от коллег из холдинга Х, чтобы реализовать нашу временную интеграцию.

Как всё устроено

Далее на своей стороне мы написали обработку, которая по расписанию забирает текстовый файл с SFTP ресурса холдинга. Благодаря использованию ЗначениеИзФайла никакого дополнительного парсинга писать не потребовалось. Плюс к этому на своей стороне написали логику создания комплектов справочников и документов на основании полученных данных.

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

Все синтетические тесты были пройдены, помарки устранены и предстоял запуск нашего уродца в прод. Ожидания мои были самыми пессимистичными. Из головы на регулярной основе выгонялась мысль о том, что эта вся авантюра не взлетит и придется в итоге экстренно сажать отдельного человека на “интеграцию”, методом ctrl+c, ctrl+v.

Где то когда то прочитал, что человеческое счастье – это величина не абсолютная, а относительная. То есть мы позитивно реагируем не на само хорошее событие, а на то, что хорошее оно по сравнению с нашими ожиданиями. Нам может быть хорошо просто от того, что перестало быть плохо.

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

• Механизм приема-передачи файлов через sftp работал без сбоев, как часы (знаю,вы скажете, что так не бывает, но это правда)

• Было обеспечено необходимое быстродействие – глубина выборки данных в источнике 50 дней от текущей даты закрывала все бизнес требования к механизму и не нагружала систему избыточными запросами

• В случае изменения бизнес логики у меня была возможность самостоятельно поменять через консоль текст запроса в источнике – мне не приходилось беспокоить коллег из холдинга Х и подолгу ждать от них реакции

• Также была возможность оперативно изменить логику формирования пакета данных в приемнике, т.к. это была внешняя обработка

• Если случится какой то сбой в регл. задании, то я всегда могу сделать загрузку/выгрузку вручную (из консоли через файл) – я думал это будет основной канал передачи, но нет.

Итоги эксплуатации

На сегодняшний день наша временная интеграция работает уже 4 месяца и проблем от неё существенно меньше, чем ожидалось на старте. А мы через 3 месяца планируем закончить проект по обособлению ИТ-сервисов группы компаний Y. И даже как то грустенько осознавать, что придется её таки отключить.

На этом у меня всё.

Интересно было бы почитать ваши комментарии и ответить на вопросы.