Введение

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

В 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 – в дальнейшем он используется для селекции сообщений, инициирующих выполнение задачи, поэтому его значение должно совпадать с указанным в параметре