Проблемы интеграции данных различных информационных баз

Возможности доработки выгрузки из 1С в Битрикс

В статье собраны некоторые полезные и интересные примеры доработок выгрузки из 1С на сайты на платформе Битрикс (Возможно, что-то подойдёт и для WordPress и других платформ, принимающих типовую выгрузку на сайт из 1С). Доработки рассмотрены без привязки к конкретным конфигурациям, примеры кода взяты в основном из доработок УТ 10 и 11. Некоторые доработки требуют изменений на стороне Битрикса, некоторые укладываются в типовой функционал.
Примеры взяты из личного опыта, возможно, описание где-то не полное, т.к. доработки делались в разное время. Если материал будет интересен или будут аналогичные актуальные задачи, буду стараться дополнять статью более подробным описанием и примерами.

Как защитить проект на этапе контрактации

При контрактации самая распространенная схема — это Поставщик/Заказчик.

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

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

Для минимизации рисков обязательно нужно четко прописывать зону ответственности Заказчика в контракте (используйте пункт «Вклад Заказчика» в ТЗ). При этом прописывайте вклад как можно конкретнее. Заказчик должен:

Предоставить всю необходимую документацию для реализации интеграции.
Предоставить тестовые данные (про тестовые данные у нас есть отдельная статья.
Обеспечить сетевую связность.
Заключить договор субподряда с командой Разработчиком интеграции (это сложный пункт).

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

У нас был случай при разработке инфраструктурной ИС X. По замыслу, порядка 30 региональных информационных систем должны были подключиться к ИС X. При этом заказчик настаивал на ответственности разработчика X за подключение этих ИС, и очень настойчиво хотел вписать это требования в условия закрытия контракта

Кстати, иногда это бывает не так просто. У нас был случай при разработке инфраструктурной ИС X. По замыслу, порядка 30 региональных информационных систем должны были подключиться к ИС X. При этом заказчик настаивал на ответственности разработчика X за подключение этих ИС, и очень настойчиво хотел вписать это требования в условия закрытия контракта.

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

Также следует иметь в виду следующее (особенно это характерно при работе с гос. Заказчиками): часть работ вам придется делать в любом случае, даже если это не входит в контракт. По интеграциям это часто бывают различные проекты соглашений, которые дают юридическую основу для обмена данными между ИС, принадлежащим разным ведомствам.

Еще один важный момент. Если есть возможность, то всячески избегайте требований к сдаче проекта, связанных с конкретной реализацией интеграций, если это не типовые подключения к СМЭВ или хорошо известные вам системы из IT-ландшафта заказчика. Обязательно требуйте пункта, который говорит о том, что в случае недоступности внешней интеграции, система может быть сдана на эмуляторе интеграции внешней системы (проще говоря – на моках). Разумные заказчики включают это допущение.

Как работает серверный вызов в 1С Промо

Клиент-серверная архитектура заложена в платформе изначально — со времен «1С:Предприятие 8.0». Однако при разработке на 8.0 и 8.1 о разделении кода на клиентскую и серверную часть можно было не заботиться, поскольку на клиенте (на толстом клиенте) был доступен тот же функционал, что и на сервере. Всё изменилось с выходом платформы «1С:Предприятие 8.2», когда появился тонкий клиент. Теперь на клиенте доступен один функционал, на сервере — другой. Клиент и сервер «общаются» между собой с помощью серверного вызова. Конечно, это усложнило процесс разработки, но с другой стороны – можно создавать более оптимальные (быстрые) решения, поскольку все сложные задачи выполняются на сервере.

Выверка данных

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

·Совпадения итоговых сумм по остаткам, по документам;

·Количественные совпадения, например количество ОС;

·Корректность заполнения отдельных выборочных сущностей;

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

Например:

·Проверка на дубли по ключевым полям. Можно и нужно проводить еще на исходных данных;

·Приведение типов полей;

·Ссылочная целостность;

·Математические нестыковки. Например, проверка на незаполненные численные поля, на которые запланировано деление при трансформации;

·В целом, проверки обязательной заполненности полей;

·Замена некорректных символов. Например, английские символы в кириллических полях («о», «а», «е» и т.п.) Особенно актуально это для ключевых полей!

·Проверка значений строковых полей на соответствие типов системы-приемника (Ограничения по длине)

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

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

В некоторых случаях может происходить параллельная работа двух систем на время опытной эксплуатации (ОЭ) и даже более этого периода. Вопрос параллельной работы пользователей в двух системах тесно связан с вопросом возможности отката к старой системе, в случае если миграция (или же, в целом, работа новой системы!) будет признана неудовлетворительной.

Первый кейс – КД2 в SQL

Первый кейс – обмен с помощью xml.

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

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

Сделал так, чтобы источником или приемником могла быть не только база данных на 1С, но и некоторые SQL-базы данных в качестве объектов.
Добавил возможность выбора объекта «Таблица SQL».

С помощью измененной «Конвертации данных 2» настроил правила обмена между 1С и SQL-базой данных, которая используется сайтом.

И написал на С# веб-сервис, который получает данные от 1С и, опираясь на правила КД2, раскладывает эти данные в таблицу SQL.

Работа была интересной, мне было приятно этим заниматься. В этом решении были позитивные стороны:

изменения можно было вносить быстро;
с помощью КД2 я легко добавлял реквизиты, перенастраивал обработчики;
и в 1С это было легко отлаживать.

Но негативных сторон было больше:

получилось решение с высокой стоимостью владения, потому что исправлять сервис на C# – большая работа;
сложная отладка на стороне веб;
все это работало не очень быстро, потому что структура правил КД2 избыточная, а при каждом обращении к сервису они перечитывались;
получилось громоздкое решение, которое мы запускали очень долго: два месяца мы только его отлаживали.

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

Выдержки из книги Чистый код

Недавно я прочитал книгу «Чистый код» Роберта Мартина (Robert Cecil Martin). В ней описываются принципы организации и форматирование исходного кода программы так, чтобы в дальнейшем было легко поддерживать такой код.
Эта книга является библией для многих программистов, но вот в среде программистов 1С, к сожалению, не очень распространено чтение подобной фундаментальной литературы.
Книга более 400 страниц и так много порой лениво читать, да и времени всегда не хватает. По этому я решил выделить в виде цитирования по разделам самые важные моменты. А также снабдил текст своими примерами кода.

Как работает RPC на стороне сервиса?

Давайте рассмотрим гипотетический сервис, который отправляет SMS, получая на вход номер телефона абонента и текст сообщения. Как наладить работу такого сервиса в рамках подсистемы YRMQ?

Во-первых, на стороне сервиса вы точно так же пишете прикладной обработчик, который как-то отправляет SMS. Это ваш прикладной код, который пишет ваш программист.
А в переопределяемом модуле подсистемы YRMQ добавляете обработчик вызова (ДобавитьОбработчикВызова()), где указываете, что:
при вызове вот этого асинхронного сервиса должен быть запущен вот этот код.
И подсистема будет это делать.

На слайде приведен пример этого метода. Он получает параметры и кладет их в некий волшебный черный ящик, который уже взаимодействует с SMS-провайдером.

Определение

ИНТЕГРАЦИОННОЕ ТЕСТИРОВАНИЕ определяется как тип тестирования,
при котором программные модули интегрируются логически и тестируются как группа.

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

Целью данного уровня тестирования является выявление дефектов взаимодействия между этими
программными модулями при их интеграции.

Интеграционное тестирование фокусируется на проверке обмена данными между этими модулями.
Следовательно, его также называют «I & T» (интеграция и тестирование), «тестирование строк» и
иногда «тестирование потоков».

Ещё пара комментариев о том, что можно считать интеграционным тестированием:

Рассмотрим ситуацию в которой разработчик выполнил юнит-тест. В этом тесте
подразумевается
взаимодействие с базой данных. Вместо базы данных была использована заглушка.

Это по-прежнему юнит-тест, интеграционного тестирования здесь нет.

Разработчик выполнил тот же тест, но с реальной базой данных, пусть это даже какая-то тестовая БД.

Это уже можно считать интеграционным тестированием, так как было
проверено взамодействие с реальной БД а не с заглушкой.

Как работает интеграл

В природе практически не существует ничего прямого и постоянного: процессы изменяют свою скорость, а материальные объекты сплошь и рядом неправильной формы. Это сильно затрудняет вычисление и описание реальности, но математики научились с этим справляться.

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

Вы выехали из точки А в точку Б и два часа двигались со средней скоростью 12 км/ч. Так вам казалось, во всяком случае. То есть график вашего движения, по вашему мнению, выглядел как-то так:

Проделанное расстояние здесь посчитать просто: 120 минут — это 2 часа, 12 × 2 = 24 кмИзображение: Skillbox Media

Но в реальности всё было иначе. Сначала вы колесили не спеша, потом разогнались, потом замедлились на подъёме в горку, затем вообще встали на светофоре, после чего снова пришлось разогнаться. То есть реальный график вашего движения был таким:

А ну-ка, посчитайте: сколько километров вы проехали теперь?Изображение: Skillbox Media

Скорость менялась, и в разные периоды времени вы проделывали разный путь. Как же посчитать, сколько вы накрутили в итоге?

Очень просто: нужно поделить всё время на равные промежутки — и посчитать, с какой примерно скоростью вы ехали в каждый из них. Возьмём промежутки по 15 минут, умножим их на примерную среднюю скорость, получим расстояние — и представим всё это в таблице.

Время, мин	Скорость, км/ч	Расстояние, км
0–15	~7	~1,75
15–30	~13	~3,25
30–45	~12	~3
45–60	~8	~2
60–75	~4	~1
75–90	~7	~1,75
90–105	~12	~3
105–120	~11	~2,75

Теперь сложим все расстояния и получим приблизительно 18,5 км. Но это всё ещё не точный результат: скорость-то мы оценивали примерно.

Чтобы посчитать точнее, нужно взять как можно большее количество промежутков — по минуте, секунде, наносекунде и так далее. Чем короче будет каждый промежуток, тем ближе к реальности окажется результат.

В идеале наш график можно поделить на число промежутков, стремящееся к бесконечности, а размер каждого из них будет стремиться, соответственно, к нулю. Затем произвести умножение во всех промежутках и сложить результаты — в общем, сделать то же, что и раньше. Только табличка получится безразмерная. Это и есть интеграл нашей функции, который математически, если кто не помнит, записывается так:

Изображение: Skillbox Media

∫ — значок интеграла. Выбран неслучайно: так как интеграл представляет собой сумму, то и обозначается вытянутой буквой S.

f(x) — это функция, которую мы интегрируем. В нашем примере мы задали функцию вручную, а не формулой, но математики работают именно с формулами.

Что делать, когда интеграция пошла не по плану

Есть печальная новость: если интеграции зашли в тупик, то хороших вариантов действия уже нет.

Особенно, если вы разрабатываете в рамках госконтракта, и не предусмотрели пункт о сдаче на эмуляторах.

Есть пара возможных действий, с которыми можно пробовать продвигаться вперед:

Начинаем писать официальные заказные письма Заказчику с требованиями предоставить доступ, документацию и т.п. Здесь сильно помогает пункт контракта «Вклад Заказчика», на который и будем ссылаться. Эти письма помогут доказать, что не вы виноваты в проблеме сдачи контракта в полном объеме.
В соответствии с ФЗ-44 и Гражданским кодексом вы можете приостановить работы по контракту до получения нужной информации. Для этого сценария вам следует предварительно изучить вопрос.

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

Переключить разработчиков на неопределенный срок, а потом снова собирать и включать обратно в проект – это очень не просто. А уж про разрыв денежных потоков от такого ожидания и говорить не приходится, ведь команда не виновата, что другие не успели (или не захотели), а все должны зарплату получить в срок.

Минимизация рисков на этапе разработки

Независимо от того, как хорошо мы подстраховались в зоне ответственности заказчика, ещё остается вопрос времени. Время выполнения работ надо всегда держать на особом контроле.

Если не получилось составить ТЗ до контракта, или не удалось получить подробную документацию, то стартовать работы нужно сразу после заключения контракта.

Одновременно с этим следует запрашивать:

Тестовые данные (почему важно как можно скорее получить тестовые данные, мы подробно писали в статье «Информационная Система с данными и без»).
Доступы и сетевые связности.
Подготовку документов для юридического обоснования интеграции.

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

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

Зачастую могут всплыть неожиданные требования (часто – со стороны безопасников). Например, может потребоваться конкретный поставщик оборудования для обеспечения сетевой связности, как следствие для завершения контракта Заказчик будет вынужден купить себе новое оборудование.

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

Очень важно, чтобы ваша компания не участвовала в них, и оставалась нейтральной и благожелательной ко всем. Ваша главная цель – сделать качественную ИС и ввести ее промышленную эксплуатацию

А интриги оставьте другим.

В чем сложность интеграции?

С точки зрения аналитики проектирование каждого нового процесса будет отличаться от предыдущего, но во всем всегда есть нюансы. Для разработчиков и архитекторов существуют некие паттерны, которые в определенной степени их выручают. Для анализа таких шаблонов нет.
При реинжнириге процессов часто выясняется, что старые системы дают качественные показатели надежности, но с позиции аналитика, совершенно не упрощают интеграцию.
Данные с которыми необходимо работать беспорядочны и не сразу поддаются формализации, не говоря уже о структурировании. Сюда можно сразу отнести форматы данных.
Изменчивость требований «на ходу». Особенно если в интеграции участвует более двух систем.
Требования информационной безопасности. Интеграция, в первую очередь история про обмен данными и часто это персональная информация как клиента, так и компании, требующая соблюдения правил для ее защиты\

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

Важно помнить, что в каждом из кейсов будут свои особенности и каждый из них имеет способ решения

Будни автоматизации или «мне нужна программка для 3D упаковки» Промо

Автоматизация отечественных предприятий, которой приходиться заниматься, это нужная и высокооплачиваемая, но довольно нервная работа. Выручает юмор. Например, при общении с требовательным клиентом можно вспомнить анекдот: «Держась руками за стену, на ногах еле стоит мужик. К нему пристает ребенок: «Ну, папа, пожалуйста, сделай мне кораблик!», папа отвечает: «Ага! — Сейчас все брошу и пойду делать тебе кораблик!». Про один такой сделанный для клиента «кораблик» и хочется рассказать. Надеюсь, совместное погружение в теплое ламповое (то есть клиентоориентированное) программирование доставит Вам положительные эмоции, да и задача попалась интересная. Поплыли?

Подход Большой Взрыв

В подходе Большого взрыва большинство разработанных модулей соединяются вместе, образуя либо
всю необходимую систему либо её большую часть.

Затем начинается тестирование.

Недостатки

Однако если что-то пошло не так, будет сложно наити причину. Особенно тяжело разбираться в
результатах большого взрыва когда тесты и/или их результаты не записаны достаточно подробно.

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

Всё это может помешать достичь цели интеграционного тестирования в разумные сроки.

Из всего вышеперечисленного можно сделать вывод о том, что подход Большого взрыва это потенциально быстрый но
рискованный подход.

Организационные трудности

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

Если заинтересованных сторон в интеграции нет (а бывает и такое), то следует применять административный ресурс — назначать ответственного сверху. Конечно, наилучшего результата можно достичь только при коллективной работе. Бросаться в крайности и назначать одного ответственного за всё без предоставления ему соответствующих полномочий не нужно. При назначении ответственных следует помнить, что за качество данных должны отвечать все же бизнес-специалисты Заказчика и специалисты службы сопровождения тех информационных систем, в которых эти данных хранятся.

Еще одной сложностью, с которой приходится сталкиваться — это закрытость служб сопровождения и разработчиков информационных систем компании Заказчика. Например, при построении хранилища данных необходимо проводить анализ данных и их структуры, хранящихся в системах-источниках. Но зачастую изучить их не получается по причине того, что не предоставляется документация, запрещается доступ к системе-источнику, отсутствуют примеры данных и т.д. В таком случае специалистами Заказчика применяется следующий подход при взаимодействии с Разработчиком: “Скажите, что Вам нужно, а мы дадим только то, что из этого есть в системе”. Это приводит к тому, что у бизнес-аналитиков и специалиста по модели данных складывается неполная картина о имеющихся данных в компании. Как результат, неполное хранилище данных. Избежать этого можно только путем правильной ориентацией специалистов Заказчика на взаимодействие с консультантами Разработчика.

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

Резюмируя перечень организационных трудностей, можно сказать, что к ним относятся:

отсутствие ответственных за интеграционные процессы;
недостаточный административный ресурс или несвоевременное его применение;
отсутствие ответственных за качество данных;
закрытость служб сопровождения и разработчиков информационных систем компании Заказчика;
непривлечение к анализу данных и последующей разработке бизнес-правил преобразования предметных экспертов Заказчика.

Шаги проектирования процесса интеграции (обмена данными) бизнес-приложений

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

Например:

Модуль	Внешняя система	Эксплуати- рующая организация / Контактное лицо	Направление интеграции (прием / передача)	Описание передаваемых данных	Требования модуля
SD	АСУ Налива на эстакадах	уточнить у ФИО	SD -> АСУ Налива	Приказы на отгрузку	АСУ налива принимает приказ на отгрузку, формируется внутрисистемного документа приказа; передаются количество, продукт, грузополучатель, номера вагонов
АСУ Налива на эстакадах	уточнить у ФИО	АСУ Налива -> SD	Ведомости налива/погрузки	Формирование ведомостей налива/погрузки, передача фактических данных по налитому количеству

Также возможные точки интеграции могут быть определены из:

знаний функционального архитектора проекта;
могут быть определены ранее на этапах договора или предобследования.

Консультант по интеграции, для обследования возможной точки интеграции, контактирует с бизнес-пользователями и ИТ-специалистами по указанным в заявке системам. В ходе интервью более детально описывается бизнес-процесс работы с системой, с которой возможна интеграция (обмен данными). В частности:

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

Далее консультант по интеграции формирует рабочий документ «Концепция интеграции», в котором описываются следующие пункты в разрезе to-be (как это будет):

схематично потоки данных при интеграции (в виде кубиков системы и взаимосвязи между ними и подписями типов передаваемых данных);
временной регламент обмена данными;
описание предполагаемых интерфейсов обмена данными. Данные предполагаемые интерфейсы основываются на существующих интерфейсах или консультант сам предлагает их структуру, или ИТ-специалист по системе предлагает их структуру. Описание должно включать имя интерфейса, состав полей, описание полей, типы данных;

Далее данная «Концепция интеграции» в части общего описания потоков интеграции согласовывается с бизнес-пользователями в рамках документа «Эскизный проект / Технический проект» или «Концептуальный проект». А в части описания интерфейсов согласовывается с ИТ-специалистами информационных систем, с которыми будет осуществляться интеграции.

Схема взаимодействия с поставщиком интеграции

В книге Эванса приводятся варианты схем взаимодействия команд при интеграции контекстов, часть из которых можно рассматривать и для интеграции систем.

Конформист. Команда, которой нужна интеграция, (команда Потребитель) полностью адаптируется к реализации. Команда разработчик реализации (команда Разработчик) живет полностью независимо.
Заказчик/Поставщик. Команда Потребитель ставит задачу на разработку интеграции и команда Разработчика реализует требования.
Открытый протокол. Публичное API, которое доступно всем, опубликовано в открытых источниках и, как правило, имеет хорошую документацию.

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

Наша задача определить детали схемы взаимодействия как можно раньше чтобы выявить элементы скрытой схемы Конформиста. При предполагаемой схеме Поставщик/Заказчик на этапе предконтрактных работ должно насторожить следующее:

Заказчик не знакомит команду Потребитель с командой Разработчик.
Команда Разработчик не готова детально обсуждать схему взаимодействия и другие технические аспекты во время выполнения работ.
Есть информация, что отношения между Заказчиком ИС и командой Разработчик натянутые (интеграция с вами может стать предметом чужих торгов).
Вы не ощущаете у Заказчика сил продавливать необходимость реализации интеграции в команде Разработчик.

При предлагаемой схеме Публичного API могут насторожить такие факты:

API еще не готово, но «обязательно будет готово к окончанию вашего контракта». Это очень существенный риск, даже если API должно быть готово за полгода до окончания контракта.
API готово, но вы будете первыми, кто к нему подключится.
Заказчик ИС не готов предоставить описание интеграционного взаимодействия

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

Заглушки и драйверы

Инкрементный подход осуществляется с помощью фиктивных программ, называемых заглушками и драйверами. Заглушки и драйверы не реализуют всю логику программирования программного модуля, а просто имитируют передачу данных с вызывающим модулем.

Заглушка: вызывается тестируемым модулем.

Драйвер: вызывает модуль для тестирования.