Статьи и публикации

Периодические задания на платформе SAP Portal

Антонов Д.А.

Антонов Д.А.

Руководитель отдела разработки Департамента практики SAP ООО «ЭнергоДата

Введение

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

В SAP Portal 7.0 механизм периодических заданий был составляющей частью модуля SAP Knowledge Management и назывался Sheduler Tasks. Для создания такого задания в NetWeaver Development Studio был предусмотрен специальный мастер. На основании реализации программного интерфейса com.sapportals.portal.prt.service.IService необходимо было создать новый, унаследованный интерфейс и его реализацию. Кроме того, мастер автоматически создавал комплект файлов конфигурации в поддиректории src.config проекта. Однако при использовании распределенной инфраструктуры разработки (NWDI) и реализации всех программных компонентов в виде Development Component-ов (как это и рекомендовано SAP) данный мастер был недоступен, поэтому реализацию комплекта файлов конфигурации приходилось создавать вручную. Однако это было не единственное неудобство. Во-первых, каждый подобный сервис мог существовать в портале в единственном экземпляре, а во-вторых, в кластеризованных порталах с числом нод более одной развертывание новой версии приложения, реализованного как Sheduler Task, в большинстве случаев приводило к остановке работы Knowledge Management и временной неработоспособности портала. Проблема решалась только перезагрузкой.

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

Данный механизм в целях совместимости функционирует и в новых версиях, консоль настроек сохранена в разделе «Системное администрирование → Knowledge Management → Управление контентом» (Рис.1).

схема работы решения на примере процесса согласования заявки на платеж

Рис.1 Консоль настроек

В долгожданной новой версии портала SAP 7.3 консультантам предложили новый инструмент реализации периодических заданий – с использованием стандартных средств J2EE, управляемых сообщениями EJB-компонентов (Message-Driven Beans). Кроме того, приятным дополнением стала возможность создавать несколько заданий на основе одного шаблона, меняя расписание и конфигурационные настройки задач.

Подготовка к реализации периодического задания

Перед началом реализации периодического задания новым методом необходимо определить ответы на следующие вопросы:

  • Какие конфигурационные параметры потребуются для исполнения создаваемого задания?
  • Нужно ли будет в будущем использовать несколько экземпляров задания с различными настройками конфигурации?
  • Какой вариант запуска предпочтителен – запуск по таймеру через определенные промежутки времени, запуск по расписанию (раз в сутки, раз в месяц) или использование внешних планировщиков?

Реализация периодического задания. Программные классы и конфигурация

Шаг 1. Реализация периодического задания начинается с создания компонента разработки (Development Component) с типом Java EE/EJB Module (Рис.2).

схема работы решения на примере процесса согласования заявки на платеж

Рис.2 Создание компонента разработки

Для демонстрационных целей назовем его sample~ejb. После создания компонента среда разработки автоматически переключит перспективу на Java EE. Дополнительно к стандартным зависимостям надо добавить компоненты tc/je/scheduler/api и tc/bl/logging/api из стандартного пакета SAP NetWeaver ENGFACADE (Рис.3). Далее необходимо создать Message-Driven Bean. Суперклассом для создаваемого MDB должен быть предоставляемый SAP класс MDBJobImplementation, в остальном используются настройки создания по умолчанию, в том числе тип сообщений JMS и Queue. Демонстрационный MDB назовем TaskSample.

схема работы решения на примере процесса согласования заявки на платеж

Рис.3 Добавление компонент

Шаг 2. Теперь надо указать источник сообщений, который будет использоваться компонентом. Это можно сделать как путём создания компонента с помощью мастера, так и вручную. Укажем источник сообщений вручную, добавив аннотацию вида:

@ActivationConfigProperty(propertyName = "messageSelector", propertyValue = "JobDefinition='TaskSampleJob'")

После создания класса необходимо реализовать обязательный метод onJob(JobContext). На этом шаге будет достаточно просто создать пустой метод с помощью средств автозавершения кода NWDS.

Дополнительное действие, которое требуется для нормальной работы задания – модификация дескриптора ejb-j2ee-engine.xml в каталоге /ejbModule/META-INF. Необходимо добавить в дескриптор описание созданного MDB-компонента. В данном случае оно выглядит так:

<enterprise-beans>
    <enterprise-bean>
      <ejb-name>TaskSample</ejb-name>
      <jndi-name>TaskSample</jndi-name>
      <message-props>
        <destination-name>JobQueue</destination-name>
        <connection-factory-name>JobQueueFactory</connection-factory-name>
      </message-props>
    </enterprise-bean>
  </enterprise-beans>

Шаг 3. Следующий шаг по реализации периодического задания – создание специального служебного файла-конфигурации. Для этой цели в стандартный каталог /ejbModule/META-INF надо поместить файл с зарезервированным названием job-definition.xml со следующим содержимым:

<?xml version="1.0" encoding="UTF-8"?>
<job-definitions xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="job-definition.dtd">
            <job-definition name="TaskSampleJob" description="Task sample" >
                        <job-definition-parameter name="customer" data-type="String"  direction="IN" data-default="World" description="Customer name" />
            </job-definition>
</job-definitions>

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

Второй интересный фрагмент – тэг job-definition-parameter. К возможностям нового механизма периодических заданий относится в том числе создание произвольных параметров разных типов (строка, целое число и так далее). В данном случае, у задачи есть единственный параметр – имя пользователя, приветствие которому будет выводиться в системный журнал. По умолчанию параметр имеет значение «World».

Шаг 4. Осталось написать программный код метода, вызываемого при выполнении периодического задания – onJob. Так как целью является демонстрация, то внутри данного метода будет просто выводиться приветствие с добавлением имени пользователя (читается из параметра задания) в системный журнал. (Рис.4)

 @Override
     public void onJob(JobContext ctx) throws Exception {
         String customerName = ctx.getJobParameter("customer").getStringValue();
         ctx.getLogger().info("Hello " + customerName);
     }

Рис.4 Программный код метода

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

Шаг 5. Завершающий шаг – создание EAR-компонента и включение в него созданного EJB-компонента. Выполняется он с использованием мастера. Сначала создается компонент (по аналогии с модулем EJB, он назван sample~ear) (Рис.5).

схема работы решения на примере процесса согласования заявки на платеж

Рис.5 Создание EAR-компонента

На третьем этапе создания компонента мастер автоматически предложит включить в состав приложения ранее созданный EJB-модуль (Рис.6):

схема работы решения на примере процесса согласования заявки на платеж

Рис.6 Включение EJB-модуля

После завершения создания EAR-компонента и его сборки можно устанавливать собранное периодическое задание на портал.

Установка и настройка

Установку собранного EAR-файла можно провести любым доступным способом, в том числе стандартной установкой из NWDS. После установки для дальнейшей настройки необходимо перейти на портал в SAP NetWeaver Administration в раздел «Java Scheduler». На закладке «Определения заданий» обнаруживается установленное задание (Рис.7):

схема работы решения на примере процесса согласования заявки на платеж

Рис.7 Результат установки EAR-файла

Как видно из иллюстрации (Рис.7), средства портала позволяют также просматривать доступные для управления параметры периодического задания.

На основании установленного определения заданий можно создать неограниченное число задач с различными настройками периодичности исполнения и разнообразными параметрами. Для того, чтобы запустить задачу, необходимо перейти на закладку «Задачи» (Рис.8) и нажать кнопку «Добавить», запустив мастер настройки периодических задач.

схема работы решения на примере процесса согласования заявки на платеж

Рис.8 Закладка «Задачи»

Первым шагом работы мастера является выбор определения – в данном случае, разумеется, TaskSampleJob:

схема работы решения на примере процесса согласования заявки на платеж

Второй шаг – настройка описания создаваемой задачи. Это позволит в дальнейшем отличить несколько задач, созданных на основании одного определения.

схема работы решения на примере процесса согласования заявки на платеж

Третий шаг мастера – установка параметров задачи. В тестовом задании был определен всего один параметр, имя пользователя, приветствие которому периодически выводится. Значение по умолчанию – «World», заменим его на «Ivanov» (Рис.9).

схема работы решения на примере процесса согласования заявки на платеж

Рис.9 Определение параметра задачи

Четвёртый, завершающий шаг – установка расписания запуска. Система предлагает несколько видов расписания, для иллюстрации выбрано простое периодическое. Потребовалось установить дату первого запуска, периодичность (каждые 5 минут) и дату последнего запуска. После установки данных по нажатию кнопки «Добавить» расписание добавляется в задачу (Рис.10)

схема работы решения на примере процесса согласования заявки на платеж

Рис.10 Установка расписания запуска

На этом создание задачи завершено, она появляется в списке активных задач (Рис.11).

схема работы решения на примере процесса согласования заявки на платеж

Рис.11 Список активных задач

Для контроля исполнения созданной задачи и просмотра результата предназначена первая закладка, «Задания» (Рис.12).

схема работы решения на примере процесса согласования заявки на платеж

Рис.12 Закладка «Задания»

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

Заключение

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

Источник: http://sapland.ru/articles/stats/ispolizovanie-i-modiphikatsiya-sistemi-reitingov-pri-sozdanii-korporativnih-phor.html