Разработка программного обеспечения на заказ

пн-пт с 09:00 до 18:00

Модуль обработки телексов стандартов AHM и Cargo IMP

Введение

Взаимодействие участников бизнес-процессов перевозки грузов авиационным транспортом определяется документами международной ассоциации воздушного транспорта, IATA (International Air Transport Association). Как правило, информационный обмен осуществляется с помощью формализованных сообщений (телексов). Наиболее важные из них описаны в документах «Airport Handling Manual (AHM)» и «Cargo Interchange Message Procedures Manual (CIMP)». Каждый телекс имеет определенный тип, а телексы CIMP еще и версию, которая может быть изменена при выпуске очередной редакции CIMP.

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

Телексы имеют достаточно сложную иерархическую структуру, состоящую из обязательных, условных и опциональных полей. Фрагмент описания одного из телексов приведен в первой колонке Табл. 1 . Обязательные поля (группы полей) имеют метку опциональные — . В спецификации указаны требования к формату (Character Format) и к содержанию (Data Element No.). Многочисленные примечания содержат дополнительные требования к разрешенным сочетаниям элементов данных, числу повторений и т.д.


Табл. 1

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

Шаблоны телексов

Основная идея, которая заложена в основу решения, состоит в использовании шаблонов телексов в расширенной форме Бэкуса — Наура (БНФ). Фрагмент шаблона, описывающий тот же фрагмент сообщения приведен в колонке 2 Табл. 1. Расширение позволяет указать наименования таблиц (выделено синим цветом) и полей (выделено красным цветом), в которых будут располагаться результаты разбора. Кроме того, терминальные элементы должны иметь референс на справочник описания формата и содержания полей.

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

Версионирование телексов

Как было отмечено выше, телексы CIMP в заголовке имеют описание типа и версии формата телекса. Так, запись в заголовке телекса FFM/3 определяет третью версию формата телекса для передачи грузового манифеста авиационного рейса. Соответственно, в системе предусмотрено хранение отдельных шаблонов для каждой версии телекса.

Адресация исходящих телексов

Архитектура модуля обработки телексов

Архитектура модуля обработки телексов приведена на Рис. 1.

Рис. 1 Структурная схема модуля обработки телексов AHM и Cargo IMP

Центральным компонентом модуля является парсер и генератор телексов. Телексы поступают на вход модуля в виде файла определенного формата во входной каталог «IN» или через WEB API от внешних систем.

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

Специализированное приложение (GUI) позволяет создавать основные типы телексов в экранных формах.

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

Интерфейс с каналами передачи данных

Модуль принимает входящие телексы в каталоге «IN» и выдает сгенерированные телексы в каталог «OUT». Расширения имени файлов должны быть .RCV и .SND. Файловая структура отправленных и полученных сообщений идентична. Она основана на наборе ключевых слов, идентифицирующих поля, за которыми следуют их значения.

Ключевые слова и их значение представлены в следующей таблице

Ключевое слово Обязательное Значение
=HEADER Нет Для исходящих телексов:
 SND, <UTC time, YYYY/MM/DD HH:MM>
 Для входящих:
 RCV, <UTC time, YYYY/MM/DD HH:MM>
=PRIORITY Нет Приоритет сообщения:
 высокий QU, обычный QN, низкий QD
=DESTINATION TYPE B Да Список до 32 адресов назначения
 Каждый адрес на отдельной строке:
 STX, адрес SITA
 INTERNET, ,Email
=ORIGIN Нет Адрес отправителя
=DBLSIG Нет Двойная подпись сообщения (только для SITA)
=MSGID Нет Идентификатор сообщения
=SUBJECT Нет Тема сообщения
=SMI Нет Стандартный идентификатор типа сообщения (3 символа)
=TEXT Yes Со следующей строки начинается текст телекса
Табл. 2 Структура файлов приема/передачи телексов для внешних систем

После обработки входящего телекса модуль удаляет его. В случае ошибки – создается файл с расширением .ERR, содержащий описание ошибки. На внешнее приложение, отвечающее за отправку телексов лежит ответственность за обеспечение аналогичной логики в отношении исходящих телексов.

Заключение

Модуль обработки телексов позволяет реализовать двусторонний обмен телексами с внешними системами их парсинг и генерацию из БД модуля.

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

Консультация

Если у Вас возник вопрос или Вы хотите связаться для расчёта проекта, оставьте заявку или свяжитесь с нами. Будем рады сотрудничеству

Расскажите нашему ведущему IT-специалисту задачи, которые стоят перед Вами, мы подготовим самые эффективные пути решения.

Выберите планируемый бюджет на разработку, руб:

Файл не выбран
Политики конфиденциальности