Локальное подписание извещений о получении

*"----------------------------------------------------------------------
*"*"Локальный интерфейс:
*"  IMPORTING
*"     VALUE(IT_ID_OED) TYPE  /TRL/XDE_T_RANGE
*"     VALUE(IT_ID_BOX) TYPE  /TRL/XDE_T_RANGE
*"     VALUE(IS_CERT) TYPE  /TRL/XDE_S_SAP_DOC_TYPE_CERT OPTIONAL
*"  EXPORTING
*"     VALUE(ET_MSG) TYPE  BAL_T_MSG
*"  EXCEPTIONS
*"      ERROR
*"      USER_CANCEL
*"----------------------------------------------------------------------

Функциональный модуль /TRL/XDE_API_LOC_SIGN_REC_CONF предназначен для локалього подписания и отправки необработанных извещений о получении.

Таблица 145 Описание интерфейса функционального модуля /TRL/XDE_API_LOC_SIGN_REC_CONF

Параметр

Описание

IMPORTING

IT_ID_OED

Набор идентификаторов операторов для работы

IT_ID_BOX

Набор идентификаторов ящиков для работы

IS_CERT

Данные о сертификате

EXPORTING

ET_MSG

Набор сообщений о результатах выполнения

EXCEPTIONS

ERROR

Ошибка во время выполнения модуля

USER_CANCEL

Отмена операции пользователем

Операция выполняется внутри метода LOC_SIGN_REC_CONF класса /TRL/XDE_CL_IM_PROCESSING, функциональный модуль по сути является оберткой для данного метода. Внутри модуля создается объект класса и вызывается вышеупомянутый метод, куда передаются все параметры, которые имеются для функционального модуля.

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

Далее определяется класс для интеграции (REST/PI/SOAP) и создается его объект. Если объект не создан - вернется ошибка. Затем в настройках таблицы /TRL/XDE_CUST будет взято значение по имени настройки LOC_SIGN_REC_CONF_ITERATION, в которой содержится количество итераций, т.к. количество обрабатываемых за один раз извещений ограничено.

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

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