Комментарии по теме

«Как не по­те­ря­ться в различных SAP-си­сте­мах»
Дмитрий Коберник:
Продуктив - синий (оригинал) Тест - фиолетовый Разработка - зеленый
«Создание ярлыка для со­е­ди­не­ния с SAP системой без пароля»
Вячеслав Шиболов:
Кирилл, спасибо за комментарий. Согласен, отличное решение для индивидуального рабочего места.
«Создание ярлыка для со­е­ди­не­ния с SAP системой без пароля»
Кирилл Сатарин:
Оптимальный вариант хранения паролей к системам SAP для меня keepass (подробнее keepass.info) как его использовать описано здесь blogs.sap.com/2012/01 (на английском) От себя добавлю, чтобы...

База знаний

Проверка запросов перед переносом по ландшафту

1079
13

Оглавление

Аннотация

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

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

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

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

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

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

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

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

Заключение

Об авторе

Аннотация

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

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

При написании 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               

Ограниченный доступ

Для прочтения полной версии статьи необходимо зайти как зарегистрированный пользователь.

Комментарии:

Сергей Чаплыгин (Рейтинг: 99) 10:12, 25 сентября 2018

Так есть же стандартное решение, транзакция SCI, зачем что то писать.
11:03, 25 сентября 2018

Евгений Лапшин (Рейтинг: 200)

Добрый день, Сергей! для того чтобы ответить на Ваш вопрос прошу подробнее расписать как SCI решает проблемы, затронутые в статье.
15:25, 25 сентября 2018

Сергей Чаплыгин (Рейтинг: 99)

Для того чтобы проверить будут ли проблемы с переносом, например в продуктивную систему необходимо сделать следующее:
 
1. Запускаем инспектор кода тр. SCI
2. Создаем набор объектов, в примере набор объектов называется TEST

На следующем экране указываем только дату удаления все остальное оставляем по умолчанию.
3. Далее создаем инспекцию.

Где указываем номер запроса(он может быть не деблокированным) и устанавливаем радибаттон напротив Запрос/Задача.

Далее в разделе вариант проверки оставляем галку только на «Проверка синт./Генерация», раскрываем и устанавливаем галки напротив всех пунктов этого раздела.
Дополняем пункт Syntax Check in Remote System используя кнопку, удаленной системой и указываем набор объектов сделанный в предыдущем шаге.

 
4.   Инспектор кода готов к тестированию объектов нашего запроса, нажимаем выполнить и ждем результата, где мы ясно видим что запрос будет перенесен с ошибками, если есть возможность исправляем ошибки дополняя свой запрос, если он у вас был не деблокирован, и заново проверяем объекты запроса описанным способом.
15:25, 25 сентября 2018

Сергей Чаплыгин (Рейтинг: 99)

15:27, 25 сентября 2018

Сергей Чаплыгин (Рейтинг: 99)

Результат:
16:41, 25 сентября 2018

Евгений Лапшин (Рейтинг: 200)

Сергей, спасибо за инструкцию!
(при создании "Инспекции" у меня нет возможности выбрать "Временное определение". возможно, из-за ограниченности полномочий. некритично, решается созданием "Варианта проверки")
В итоге получил вот это

SCI запускал по одному запросу, в котором содержится только программа из примера.
Отчет, представленный в статье, выдает следующий результат:, то есть выводит весь список объектов из Рис.1 текущей статьи. То есть SCI нашел не все объекты.
Также из преимуществ:
1. позволяет анализировать сразу несколько запросов.
2. удобство запуска и представления результата.
3. тестировал SCI на других запросах: заметил, что пропускает некоторые объекты
4. отрабатывает значительно быстрее
5. последняя редакция отчета позволяет отключать реализации точек расширения из списка объектов проверки.
14:11, 27 сентября 2018

Антон Сорокин (Рейтинг: 353)

1. Так ведь в SCI можно даже пакет указать. Проверит все объекты во всех запросах.
3. Например? Очень любопытно.
5. Поясните пожалуйста, в чем польза отключения проверки?
18:08, 27 сентября 2018

Евгений Лапшин (Рейтинг: 200)

1. А указать конкретные объекты можно?
3. На примере выше видно, что SCI увидел отсутствие только ZREPORT1_INCLUDE, но пропустил вызов метода класса ZCLASS1. кроме того, остальные элементы дерева из рис.1 он тоже пропустил (возможно, проблема в том, что операция поиска недостающих объектов не итеративна, то есть нужно сначала включить найденные объекты в список для анализа и запустить анализ снова).
5. Представим, что у нас есть z-enhacement spot. для него создана z-enhacement implementation. Отчет определяет, что необходимо также включить в запрос на перенос enhacement spot. enhacement spot потянет за собой реализацию. Реализация может тянуть за собой множество других объектов. Но сама реализация для текущего релиза может быть не нужна (она лежит в другом запросе). Исключение из анализа реализаций точек расширения отрезает целую "ветку" объектов из анализа. Запрос без реализации доедет успешно, а это, обычно, самая главная цель при подобном анализе.

Константин Локшин (Рейтинг: 112) 09:02, 27 сентября 2018

Евгений, добрый день.
Очень хорошая статья.
Предлагаю вам сравнить вашу программу со стандартной программой для этой цели: /SDF/CMO_TR_CHECK.
Насколько я могу судить на текущий момент у стандартной программы есть полезная возможность, которой пока нет в вашей: она также показывает в каком другом запросе есть недостающий вам объект.
09:58, 27 сентября 2018

Евгений Лапшин (Рейтинг: 200)

Добрый день, Константин!
спасибо, за приятную оценку.
одним глазом посмотрел Вашу программу. при анализе моего тестового запроса она выдала не все объекты.
Да, действительно моя программа не выдает запросы, в которых находятся недостающие объекты (такой цели не ставилось). Насколько я понял, также данная программа умеет составлять последовательность переноса связанных объектов. Спасибо, возможно, чтото из фукнционала я добавлю к себе, когда будет возможность.
p.s. также, ранее я находил программу RSSYSCOMP. но она не умеет работать с несколькими запросами (приходилось ее копировать и расширять под свои нужны), и ракурс представления выходных данных для моих нужд неприемлем.
10:25, 27 сентября 2018

Константин Локшин (Рейтинг: 112)

Евгений, если я правильно понял, в отличие от вашей, стандартная /SDF/CMO_TR_CHECK не нашла недостающие объекты, которые находятся на втором уровне вложенности (на них ссылаются недостающие объекты первого уровня).
 
Итого, с /SDF/CMO_TR_CHECK надо работать итерационно - добавить в запрос всё чего не хватает и прогнать еще раз, чтобы убедиться, что все объекты следующего уровня в запросе есть.
А вот ваша программа показывает всё чего не хватает сразу.
Получается, у вас в этом отношении преимущество.
18:14, 27 сентября 2018

Евгений Лапшин (Рейтинг: 200)

Да, всё верно.

Олег Табулович (Рейтинг: 52) 11:46, 28 сентября 2018

Спасибо Женя, актуальная тема, полезная статья.

Любое воспроизведение запрещено.
Копирайт © «Издательство ООО «Эксперт РП»