Создание отказоустойчивых композитных приложений путем внедрения механизмов обработки ошибок с защитой от неумелого обращения в SAP MII

Ключевое понятие
В новых версиях SAP Manufacturing Integration and Intelligence (MII) пользователям доступны две важные опции: обработка особых ситуаций и поддержка транзакций SQL. Они не только используются для обработки ошибок, но и обеспечивают отказоустойчивость бизнес-логики или транзакции.

Аннотация

Статья посвящена обработке различных сценариев появления ошибок при разработке композитных приложений в системе SAP Manufacturing Integration and Intelligence (SAP MII). Читатели узнают о новых способах обработки особых ситуаций и транзакций в SAP MII.

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

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

Развитие механизмов обработки ошибок в SAP MII

В большинстве случаев SAP Manufacturing Integration and Intelligence (SAP MII) используется для сценариев интеграции и разработки пользовательского интерфейса. В этих областях применения надлежащая обработка ошибок имеет первостепенное значение. Например, при переносе данных посредством интерфейса через несколько разрозненных систем необходимо регистрировать данные, не перенесенные из одной системы в другую для того, чтобы можно было просмотреть эти данные, исправить ошибки и повторить попытку переноса в целевую систему. В отношении пользовательских интерфейсов корректная обработка ошибок повышает эффективность работы пользователей посредством вывода информационных сообщений в случае ввода данных в некорректном формате, неподходящем для их обработки системой.

Примечание
Периодически в статье я указываю версии SAP MII, в которых описанные методы и функции появились впервые. Последней версией системы является SAP MII 15.0, но некоторые рассматриваемые здесь функции были представлены в версиях SAP MII 12.1, 12.2 и 14.0.

Проектирование отказоустойчивых транзакций и приложений SAP MII часто оказывалось для разработчиков MII непростой задачей. До выхода версии SAP MII 12.1 проверить наличие особой ситуации в транзакции SAP MII Business Logic Services (BLS) можно было только путем добавления блоков условных действий с подтверждением успешного выполнения предыдущего действия. Далее логика выполняется или обходится в зависимости от результата проверки. Однако не для каждого сценария достаточно обработки с блоками условных действий. Например, логическая ошибка (деление на ноль, например) может возникнуть где угодно и вызвать преждевременное завершение транзакции в случае присвоения ссылке на блок действий.

Чтобы помочь компаниям преодолеть это затруднение, в SAP MII 12.1 и выше были добавлены следующие различные блоки действий:

• Блоки действий для обработки особых ситуаций и поддержки транзакций: Обработка особых ситуаций впервые появилась в версии SAP MII 12.2, а поддержка транзакций – в SAP MII 14.0. Эти два блока позволяют не только фиксировать и отбрасывать ошибки, но и обрабатывать множественные операции создания, чтения, обновления и удаления (CRUD) для базы данных в одной транзакции SQL.
• Отладчик BLS: С появлением отладчика BLS в SAP MII 12.2 расширились возможности эффективной отладки транзакций разработчиком.
• Буфер данных: Эта уже хорошо знакомая пользователям функция SAP MII обеспечивает гарантированную доставку сообщений в случае сбоя целевой системы. Однако здесь действует ряд ограничений, которые иногда приходится обходить с помощью пользовательских решений.
• Мониторинг производительности BLS: В SAP MII 12.1 появился флаг LogStatisticsToDB, который позволяет получить ценную внутреннюю информацию о производительности транзакции BLS.

В следующих разделах рассматриваются функции указанных выше блоков действий и другие функциональные возможности SAP MII:

• Создание отказоустойчивых транзакций BLS
• Отладка транзакций BLS с помощью отладчика SAP MII
• Концепция гарантированной доставки в SAP MII
• Мониторинг производительности транзакций BLS

Создание отказоустойчивых транзакций BLS

Рассмотрим использование блоков действий Exception Enabler, Catch и Throw, предназначенных для всесторонней обработки аварийных ситуаций, которые могут возникнуть в ходе выполнения транзакции BLS. Вы увидите, как важно обеспечить обработку транзакции в базах данных и как повысить ее эффективность с помощью группы блоков действий для поддержки транзакций SQL.

Обработка особых ситуаций в транзакциях BLS

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

Чтобы наглядно представить себе процесс появления особых ситуаций в SAP MII, рассмотрим процедуру создания простой транзакции, см. Рис. 1.

Рис. 1. Транзакция BLS для изучения обработки особых ситуаций

В этой транзакции с помощью Tracer_1 и Tracer_2 выполняется трассировка простого сообщения при выполнении. Однако блок действий AssignCharToFloat Assignment пытается присвоить символьное значение Hello локальной переменной DivValue типа «значение с плавающей десятичной запятой». Поскольку строку невозможно имплицитно преобразовать в значение с плавающей десятичной запятой, возникает особая ситуация. Обратимся к выводу транзакции во время выполнения: Рис. 2.

Рис. 2. Вывод транзакции, показанной на Рис. 1

На Рис. 2 видно, что выполняется Tracer_1 (строка в красном квадрате). При попытке выполнить блок действий AssignCharToFloat возникает особая ситуация, а транзакция завершается без выполнения Tracer_2. Это вариант по умолчанию для транзакций SAP MII. В случае особой ситуации транзакция пропускает все блоки действий до блока действий Catch или завершается. Блок действий Catch будет описан ниже. Но что произойдет, если согласно бизнес-логике при появлении особой ситуации она игнорируется и вместо завершения транзакции выполняется переход к следующему логическому блоку действий?

Рассмотрим случай, когда согласно бизнес-логике требуется вставить определенное число записей в таблицу базы данных. При появлении ошибок необходимо зарегистрировать ошибку и перейти к следующей записи. Как обработать такое условие? Именно здесь нам поможет блок действий Exception Enabler. Несмотря на свое название, Exception Enabler используется не только для активации, но и для дезактивации особых ситуаций для ссылок и блоков действий, определяя значения true или false для атрибутов ThrowOnActionError и ThrowOnLinkError транзакции. В следующем разделе рассмотрим принципы работы Exception Enabler.

Блок действий Exception Enabler

Транзакция на Рис. 3 зацикливает переменную списка NumberList и пытается пройти по списку и присвоить значение локальной переменной FloatValue типа «значение с плавающей десятичной запятой». Трассировщик PrintCurrentValue выводит на печать значение, итерируемое до присвоения FloatValue. Далее трассировщик PrintFloatValue выводит на печать значение FloatValue после присвоения. Такой случай использования аналогичен описанной выше ситуации, когда требуется присвоить все значения локальной переменной и вывести на печать значения, генерирующие ошибку.

Рис. 3. Транзакция для выполнения цикла и присвоения значений локальной переменной

На Рис. 4 представлен вывод транзакции, показанной на Рис. 3. Обратите внимание, поведение точно соответствует моему описанию попыток транзакции присвоить значение 3 переменной FloatValue.

Рис. 4. Вывод транзакции, показанной на Рис. 3

Теперь изменим транзакцию с помощью блока действий Exception Enabler для итерации по всем значениям без остановки в точке возникновения особой ситуации, присвоения значений FloatValue (если возможно) и печати значений, присвоить которые невозможно, отдельно в виде ошибок. На Рис. 5 показана измененная транзакция.

Рис. 5. Модифицированная версия транзакции, показанной на Рис. 3

Как видно на Рис. 5, добавлен блок действий Exception Enabler (Disable_Exceptions). Для настройки опций конфигурации этого блока щелкните правой кнопкой мыши по блоку Disable_Exceptions. Это действие открывает экран конфигурирования Exception Enabler. Как видно на этом экране, независимые кнопки «Enable Action Exceptions» (Активировать особые ситуации для действия) и «Enable Link Exceptions» (Активировать особые ситуации для ссылки) не выбраны. В результате транзакция не выдает особую ситуацию, которая прервала бы дальнейшую обработку транзакции, если в логической позиции для присвоения блока действий или ссылки существует условие особой ситуации, наступающее после блока действий Exception Enabler.

Я также добавил блок условных действий CheckSuccess, который проверяет равенство текущего значения локальной переменной FloatValue и значения текущего объекта в списке, по которому выполняется итерация. Это косвенная проверка успешного выполнения присвоения. Блок действий PrintError печатает значение в списке, вызвавшем ошибку. Однако почему нельзя просто проверить свойство Success блока действий AssignFloatValue, чтобы узнать, выполнено ли присвоение? Ответ можно найти в выводе транзакции, показанном на Рис. 6.

Рис. 6. Вывод транзакции, показанной на Рис. 5

Обратите внимание на желтую строку, которая начинается с [WARN]. При сбое на ссылке блок действий AssignFloatValue заменяет значение локальной переменной FloatValue на ее последнее значение и устанавливает для флага «Success» значение true. Таким образом, простая проверка флага «Success» (Успешное выполнение) в данном случае не работает. Блок действий Exception Enabler также используется для выборочной активации или дезактивации особых ситуаций в определенных частях транзакции. Это может потребоваться в транзакциях с комплексной бизнес-логикой, когда сбой в одной части транзакции может привести к сбою всей транзакции, при этом сбой в другой части таким катастрофичным не будет.

Обратимся к примеру. В результате вызова BAPI_ALM_NOTIF_LIST_FUNCLOC, который составляет список уведомлений в функциональном местоположении в SAP ERP Central Component (ECC), переносится множество записей, предназначенных для вставки в базу данных. Сбой при вызове RFC или Business Application Programming Interface (BAPI) ведет к завершению работы всей транзакции. При этом в случае сбоя при вставке записи в базу данных можно просто зарегистрировать ошибку и перейти к обработке следующей записи.

Для наглядности на Рис. 7 представлена несколько измененная версия транзакции, показанной на Рис. 1.

Рис. 7. Модифицированная версия транзакции, показанной на Рис. 1

Особые ситуации дезактивируются здесь до блока действий AssignCharToFloat, и выполнение логики продолжается до Tracer_2. При этом особые ситуации снова активируются до блока действий AssignCharToFloatAgain, поэтому транзакция генерирует особую ситуацию и до Tracer_3 не доходит. Это подтверждает вывод транзакции на Рис. 8.

Рис. 8. Вывод транзакции, показанной на Рис. 7

Блок действий Catch

Блок действий Catch вызывается только в случае появления в транзакции особой ситуации. Этот блок делится на два этапа: желтый этап Exception и этап Finally, см. Рис. 9.

Рис. 9. Блок действий Catch с этапами Exception и Finally

Этап Exception выполняется только в случае появления блока действий Catch в результате генерации транзакцией особой ситуации. Этап Finally выполняется всегда независимо от этапа Exception. Как правило, этап Finally используется для очистки в случае особой ситуации или для выполнения логики иным образом, если в транзакции она была пропущена по причине особой ситуации.