Продолжаем движение по ключевым результатам 1-го этапа внедрения. Сегодня о детализации задач по интеграции ИС.

Итак, ещё до старта проекта должны быть определены технологии интеграции, содержание и приблизительные объемы. Передать данные из одной ИС в другую можно весьма разными способами (файл, промежуточная БД, API, брокеры, ESB).

Кроме того, помимо непосредственной передачи, в задачи интеграции могут входить и другие задачи (трансформация данных, "склейка" данных, обогащение данных). Одно дело настроить передачу данных парочки справочников, другое дело - выстроить систему мастер-данных (строго говоря, в последнем случае - это отдельный крупный проект).

В рамках текущего этапа необходимо: - определить пакеты передаваемых данных;

- определить инициирующее событие;

- описать передаваемые данные в системе-источнике и системе назначения;

- описать логику промежуточных операций;

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

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

Передаваемые данные. Соответственно, указывать нужно не только сам реквизит, но и объект, и тип данных (и в источнике, и в системе назначения). Кроме того, в источнике надо перечислять не только те поля, значения которых будут передаваться в систему назначения, но и поля, участвующие в расчетах (когда передавать нужно не значение, а результат вычисления).

Логика промежуточных операций. Простейший пример - в систему назначения нужно передать возраст покупателя, например, из ИС, где находится программа лояльности, в систему, где отражаются покупки клиента. Допустим, в ИС "программа лояльности" есть дата рождения, а в справочнике ИС "Управления продажами" есть только возраст. Соответственно, при сохранении анкеты участника нужно передать не дату рождения, а "количество месяцев(текущая дата минус дата рождения) делить без остатка на 12".

По окончании описания - проанализировать на наличие логических ошибок (например, на отсутствие зацикленности, когда данные вносятся в ИС1, по событию внесения эти данные передаются в ИС2, далее по событию внесения данных попадают в ИС 3, а из нее - в ИС1). Или, например, передача статистики оформления заказов за сутки в интернет-магазине в 22:00. Да, можно договориться, что полная статистика грузится не на следующий день, а через день. Но если нет никаких помех, почему не настроить передачу данных после 00:00? Поэтому, когда уже подготовлено полное описание, крайне нелишним будет ещё раз проверить все в комплексе.

Вторая часть статьи также не уместилась в лимиты. Поэтому опубликую отдельным постом.

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