Оглавление

Аннотация

Описание проблемы

Входные параметры

Алгоритм проверки объектов

Выбор объектов запроса

Обход дерева используемых объектов

Проверка статуса переноса

Выходные данные

Дополнительные «контрольные»функции

Заключение

Об авторе

Аннотация

Целевая аудитория статьи - все разработчики, которым приходится сталкиваться с ошибками, возникающими при переносах запросов по ландшафту. В статье представлен алгоритм для поиска и проверки всех объектов системы, от которых зависят объекты в переносимом запросе.

Описание проблемы

При написании Z-кода разработчики часто используют чужие Z-объекты. В следствие этого часто возникают ошибки при переносах запросов в другие системы в виду отсутствия этих объектов.

Например, отчет ZREPORT1 использует include ZREPORT1_INCLUDE и структуру ZSTRUCTURE1. (Рисунок 1) Структура в свою очередь использует элементы данных, include использует таблицу. Такие связи бывают очень сложными и, порой, даже циклическими.

Рисунок 1. Дерево использования объектов

Если разработчик положил в свой запрос только ZREPORT1, а другие объекты не захватил и их нет в целевой системе, то при переносе будет ошибка в виду нехватки там include ZREPORT1_INCLUDE и структуры ZSTRUCTURE1. Разработчик судорожно собирает новый запрос, вложив в него структуру и include, и при переносе снова получает ошибки, но теперь из-за нехватки других объектов. С каждой итерацией количество объектов в запросе растет как снежный ком, и искать превентивно потенциальные ошибки переноса становится все сложнее.

Предлагаемая программа решает вышеописанную проблему путем обхода всего «дерева» используемых объектов с целью проверки переноса каждого из объектов в целевую систему.

Входные параметры

Входными параметрами для решения вышеописанной задачи являются идентификатор целевой системы и список запросов для переноса (для простоты в статье будем использовать только один запрос).

SELECT-OPTIONS:

      s_trkorr FOR e070-trkorr OBLIGATORY .   " запросы

PARAMETERS:

      p_targ TYPE rfcdes-rfcdest OBLIGATORY. " целевая система

В качестве идентификатора целевой системы нам понадобится ее RFC-адрес в формате «TMSADM@AB2.DOMAIN_ABC». Для получения этого адреса удобно использовать ФМ SVRS_GET_RFC_DESTINATION. Он выведет список всех доступных систем и вернет RFC-адрес в нужном нам формате.

Алгоритм проверки объектов

Алгоритм проверки объектов разбивается на 3 простых блока:

• Выбрать все объекты запроса.
• Обойти все дерево используемых объектов, собрав полный список.
• Проверить статус переноса  каждого объекта в целевую систему.

После отработки алгоритма остается только собрать выявленные (недостающих в структуре) объекты в общий список и вывести его на экран.

Выбор объектов запроса

Объекты запроса хранятся в таблице E071. Выбираем их обычным SELECT (тут можно использовать различные стандартные ФМ) и сохраняем в таблицу объектов для проверки TABLE1, пометив их как исходные.

Обход дерева используемых объектов

Чтобы найти используемые объекты воспользуемся ФМ REPOSITORY_ENVIRONMENT_SET_RFC.

ls_environment_types TYPE  envi_types VALUE 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX',

CALL FUNCTION 'REPOSITORY_ENVIRONMENT_SET_RFC'

      EXPORTING

        obj_type          = тип объекта(PROG/CLAS/METH и др. )

        environment_types = ls_environment_types

        object_name       = идентификатор объекта (название)

      TABLES

        environment       = lt_env.

Здесь отметим, что для объекта типа FUNC нужен объект типа FUGR. Вышеуказанный ФМ нам в данном вопросе не поможет, поэтому из таблицы БД TFDIR выбираем Группу Функций по названию ФМ и запоминаем эту ГФ в таблице lt_env для анализа.

Таблица lt_env содержит все объекты, которые используются анализируемым объектом. Но в поле TYPE лежат идентификаторы в «другой» кодировке. (Рисунок 2) Кроме того в поле ENCL_OBJ мы видим название класса для метода из поля OBJECT.

Рисунок 2. Список используемых объектов

Выполним мэппинг поля TYPE с помощью выборки из двух таблиц.

SELECT SINGLE type FROM euobj INTO lv_type
                   WHERE id   EQ <ls_env>-type.

SELECT SINGLE tadir FROM euobjedit INTO <ls_env>-type
                   WHERE type EQ lv_type.

Скопируем названия главных объектов из ENCL_OBJ OBJECT в OBJECT и удалим дубликаты.

Также удалим объекты по следующим критериям:

• Все стандартные объекты (например, ФМ POPUP_TO_CONFIRM). Для этого из таблицы TADIR выберем названия пакетов для каждого объекта и оставим все объекты, для которых пакет начинается на Z* или $TMP.
• Объекты, которые присутствуют в начальном списке объектов
• Объекты, которые уже были проверены на предыдущих итерациях обхода дерева объектов.
• Различные ZREUSE-объекты: например, класс работы с логом, класс исключений, класс считывания параметров и пр.

Проверка статуса переноса

Для «очищенного» списка объектов нужно проверить статус переноса. Для этого вызовем ФМ:

CALL FUNCTION 'SCTS_COMP_REPOS_COMPARE_REPOS'
      EXPORTING
        dest1                      = ''
        dest2                      = ms_params-targ