ОГРН 1027735006991
ИНН 7735115890
1993-2024 © Компания Арсис. Все права защищены
Разработка программного обеспечения на заказ
Взаимодействие участников бизнес-процессов перевозки грузов авиационным транспортом определяется документами международной ассоциации воздушного транспорта, IATA (International Air Transport Association). Как правило, информационный обмен осуществляется с помощью формализованных сообщений (телексов). Наиболее важные из них описаны в документах «Airport Handling Manual (AHM)» и «Cargo Interchange Message Procedures Manual (CIMP)». Каждый телекс имеет определенный тип, а телексы CIMP еще и версию, которая может быть изменена при выпуске очередной редакции CIMP.
Перед разработчиком любой информационной системы в области авиационной логистики стоит сложная задача обеспечения корректного разбора телексов, поступающих на вход системы, а также генерация исходящих телексов в правильном формате. Дополнительно, желательно иметь механизм указания точного места входящего сообщения, в котором произошло нарушение спецификации.
Телексы имеют достаточно сложную иерархическую структуру, состоящую из обязательных, условных и опциональных полей. Фрагмент описания одного из телексов приведен в первой колонке Табл. 1 . Обязательные поля (группы полей) имеют метку опциональные — . В спецификации указаны требования к формату (Character Format) и к содержанию (Data Element No.). Многочисленные примечания содержат дополнительные требования к разрешенным сочетаниям элементов данных, числу повторений и т.д.
Ниже описано решение, которое находится в промышленной эксплуатации с 2004 года и постоянно совершенствуется на основе учета реальных ситуаций про разборе тысяч телексов и учета реальных потребностей производства.
Основная идея, которая заложена в основу решения, состоит в использовании шаблонов телексов в расширенной форме Бэкуса — Наура (БНФ). Фрагмент шаблона, описывающий тот же фрагмент сообщения приведен в колонке 2 Табл. 1. Расширение позволяет указать наименования таблиц (выделено синим цветом) и полей (выделено красным цветом), в которых будут располагаться результаты разбора. Кроме того, терминальные элементы должны иметь референс на справочник описания формата и содержания полей.
Разбор содержания телекса на основании шаблона и размещение его в указанные таблицы и поля базы данных (БД) является алгоритмически несложной задачей. В процессе разработки решения удалось решить гораздо более сложную задачу корректной генерации текста телекса на основании этого же шаблона из данных, размещенных в БД. Таким образом, были решены обе задачи: по тексту входящего телекса создать записи в заданных таблицах базы данных и обратная задача — из набора записей БД создать правильный формат телекса для отправки адресату информационного обмена.
Как было отмечено выше, телексы CIMP в заголовке имеют описание типа и версии формата телекса. Так, запись в заголовке телекса FFM/3 определяет третью версию формата телекса для передачи грузового манифеста авиационного рейса. Соответственно, в системе предусмотрено хранение отдельных шаблонов для каждой версии телекса.
Архитектура модуля обработки телексов приведена на Рис. 1.
Центральным компонентом модуля является парсер и генератор телексов. Телексы поступают на вход модуля в виде файла определенного формата во входной каталог «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 | Со следующей строки начинается текст телекса |
После обработки входящего телекса модуль удаляет его. В случае ошибки – создается файл с расширением .ERR, содержащий описание ошибки. На внешнее приложение, отвечающее за отправку телексов лежит ответственность за обеспечение аналогичной логики в отношении исходящих телексов.
Модуль обработки телексов позволяет реализовать двусторонний обмен телексами с внешними системами их парсинг и генерацию из БД модуля.
Структура и формат телексов описывается в виде шаблонов в расширенной БНФ, что позволяет добавлять типы обрабатываемых телексов по мере расширения информационного взаимодействия с внешними системами.
Если у Вас возник вопрос или Вы хотите связаться для расчёта проекта, оставьте заявку или свяжитесь с нами. Будем рады сотрудничеству
ОГРН 1027735006991
ИНН 7735115890
1993-2024 © Компания Арсис. Все права защищены
Выберите планируемый бюджет на разработку, руб: