К примеру, переносимая программа использует новые таблицы (либо новые версии старых таблиц), а целевая система об этим изменениях ещё «не знает», т.к. измененные/созданные объекты разработки отсутствуют в переносимом вместе с программой запросе, и ранее ещё не переносились.

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

Особенно это ощутимо, когда авторы изменений (программисты) компании-подрядчика не могут (не имеют полномочий) самостоятельно переносить сделанные изменения в целевую систему Заказчика, а вынуждены, ввиду имеющихся регламентов, обращаться к базисникам Заказчика по этим вопросам. Таким образом, осуществляется жёсткий контроль над переносом изменений.

Это чревато не только потерями времени и денег (затягивание сроков сдачи-приемки работ и соответственно сроков оплаты сделанных работ), но и репутационными рисками. К примеру, недружелюбно настроенные сотрудники Заказчика получают лишний повод заявить, что уровень квалификации программистов Подрядчика вызывает сомнения – мол, они настолько бестолковые, что даже не могут грамотно составить транспортный запрос на перенос. Тогда так как по условиям договора было заявлено участие программистов высочайшей квалификации.

Тогда как любой программист знает, что на самом деле от подобных ошибок не защищён даже самый профессиональный, умудренный опытом, программист. Всегда есть риск допустить подобные ошибки из-за спешки и/или невнимательности либо в силу объективных причин (давность сделанных изменений, сложные переплетения зависимостей…). Штатные инструменты SAP не дают достаточной защиты.

Всё это может в конечном итоге привести к реальным финансовым потерям. Таким образом, проблематика выходит за рамки эргономики работы программистов.

Между тем, если подойти к вопросу совсем чуть-чуть более творчески, вполне реально создать технический инструмент, которые поможет управлять этими рисками.

Общая концепция реализации

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

1.)    Выбрать все объекты разработок, содержащиеся в переносимом запросе и его подзапросах.

2.)    Выбрать по цепочке все объекты разработок, которые используются, прямо или косвенно, объектами разработок, содержащимися в запросе и его подзапросах. Тема взаимного использования объектов разработки слишком объемная, чтобы целиком осветить её в этой статье. Поэтому сейчас мы ограничимся вопросами использования объектов разработки программными объектами разработок, т.е. объектами разработок, состоящими из АВАР-кода – АВАР-отчетами, АВАР-инклудами, классами. Мы не будем здесь анализировать использование элементов данных в полях таблиц, доменов в элементах данных и т.п. Также мы ограничим виды используемых видов разработки. Это будут только АВАР-инклуды и глобальные типы: объекты словаря (таблицы БД, структуры, типы таблиц, пулы типов, а также их компоненты, элементы данных), АВАР-классы (с их компонентами). Это, конечно, ограничение, но когда вы реализуете свой анализатор и начнете его использование, то обнаружите, что даже в таком ограниченном варианте он «закрывает» процентов 80-90% возникающих проблем. А даже если возможности данного анализатора не будут покрывать ваших потребностей, вы без особо труда сможете нарастить круг анализируемых зависимостей «по образу и подобию».

3.)    Для тех объектов разработки, которые используются, но отсутствуют в транспортном запросе, выполним удаленное сравнение версий между системами (проверим на предмет различий). Разумеется, сравнивать будем исходную систему и целевую систему.

4.)    Если объект имеет различия между системами и отсутствует в переносимом запросе – просигнализируем о проблеме.

Реализация

Анализатор выполним в виде обычного выполняемого АВАР-отчета.

При выводе результатов анализа на экран не будем использовать сложных элементов интерфейса наподобие ALV – для наших целей вполне подойдёт обычный «листинговый» вывод.

Мы осознанно будем использовать устаревший стиль АВАР-кода (с использованием HEADER-LINE и пр.) – просто для лаконичности и наглядности (просто чтобы убрать несущественные конструкции, требующиеся для обслуживания АВАР-кода в современном стиле). При самостоятельной реализации рекомендуем вам следовать рекомендациям SAP’а относительно устаревших и рекомендуемых конструкций.

В качестве входных параметров нам нужен только № запроса и имя SAP-системы, совместимость с которой мы хотим проверить. Можно было бы брать имя целевой SAP-системы из атрибутов запроса, но обычно ландшафт SAP-систем трёхуровневый («Разработка»->«Тест»->«Продуктив»), и часто требуется определить целостность запроса на всех этапах переноса.

PARAMETERS: p_trkorr TYPE e070-trkorr    OBLIGATORY MEMORY ID trkorr " Что  несём

          , p_system TYPE e070-tarsystem OBLIGATORY MEMORY ID tarsys " Куда несём

          .

Выбрать по цепочке все объекты разработок, содержащиеся в переносимом запросе и его подзапросах

Заголовок транспортного запроса и иерархия его подзапросов хранится в таблице E070. № запроса/задачи – поле E070-TRKORR. № вышестоящего запроса для задачи (подзапроса) – поле E071-STRKORR .

*Сформируем из № запроса и его задач RANGES и получим список всех содержащихся в запросе объектов, по полю E071- TRKORR .

 

DATA: ltr_korr TYPE RANGE OF e070-trkorr WITH HEADER LINE,

      BEGIN OF ltd_objk OCCURS 0,

        object TYPE e071-object,

        obj_name TYPE e071-obj_name,

      END OF ltd_objk.

 

ltr_korr-sign = 'I' .

ltr_korr-option = 'EQ' .

 

SELECT trkorr INTO ltr_korr-low

  FROM e070

 WHERE trkorr  EQ p_trkorr

    OR strkorr EQ p_trkorr .

  APPEND ltr_korr .

ENDSELECT .

 

SELECT DISTINCT

        object

        obj_name INTO TABLE ltd_objk

  FROM e071

 WHERE

       trkorr IN ltr_korr

   AND pgmid IN ('LIMU', 'R3TR')

В таблице LTD_OBJK имеем теперь список всех объектов разработки, включенных в запрос и его подзапросы.

В данной статье ограничимся следующими типами объектов разработок:

1.  АВАР-программы;
2.  Инклуды АВАР-кода;
3.  Структуры словаря, являющиеся глобальными типами: таблицы БД, структуры, типы таблиц, элементы данных. А также их компоненты.
4.  Глобальные АВАР-классы (построенные в SE24), и их методы;

Значение поля OBJECT	Какого типа объект
PROG	АВАР-программы и АВАР-инклуды
TABL	Определения таблиц и структур словаря данных
TYPE	Пулы (группы) типов
FUGR	Группы функций
CLAS	АВАР-класс
METH	Отдельный метод АВАР-класса

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

Поскольку в данной статье мы ограничимся лишь использованием объектов разработок АВАР-программами (и не рассматриваем другие использования – к примеру, элементов данных в таблицах), нам нужны источники данных, из которых мы могли бы получить информацию об использовании объектов разработок АВАР-программами.

В  SAP-е есть неплохой инструмент для выполнения этой задачи: «Журнал использования».

Данные об использовании объектов программами хранятся в таблицах *CROSS*.

Название таблицы	Назначение
WBCROSSI	Использование АВАР-инклудов в программах.
WBCROSSGT	Использование глобальных типов в программах. В т.ч. использование компонентов таблиц, структур. Включая использование АВАР-классов, их полей и методов.
CROSS	Использование функциональных модулей в программах. Также в этой таблице найдем информацию об использовании пулов (групп) типов. Кроме того, в этой таблице содержатся данные об использовании ещё множества различных типов объектов (например, сообщений), но мы в рамках данной статьи это не рассматриваем.

Из этих таблиц, таблица WBCROSSGT является самое интересной и многообразной.

В SAP’е понятие «глобальный тип» - понятие достаточно широкое. Это и объекты словаря (таблицы, структуры, элементы данных…), и их компоненты. АВАР-классы тоже являются глобальными типами.

Каждая строка АВАР-кода, где выполняется доступ к какому-либо глобальному типу или его компоненту, даёт в WBCROSSGT строчку

АВАР-код	OTYPE	WBCROSSGT- NAME
IF sy-subrc = 0 .	SY	SY\DA:SUBRC
DATA: BEGIN OF ltd_objk OCCURS 0,         object TYPE e071-object,         obj_name TYPE e071-obj_name,       END OF ltd_objk.	TY	E071\TY:OBJECT
		E071\TY:OBJ_NAME
CALL METHOD o_grid-> set_table_for_first_display	ME	CL_GUI_ALV_GRID\ME:SET_TABLE_FOR_FIRST_DISPLAY

 

При этом в поле WBCROSSGT- INCLUDE содержится имя инклуда или программы, где происходит обращение к глобальному типу или его компоненту. Обратите внимание: там прописывается не имя главной программы, а имя непосредственно того куска АВАР-кода, где происходит обращение.

Таким образом, мы можем получить список всех глобальных типов, задействованных прямо или косвенно при работе АВАР-программы, если перед этим выполним поиск всех инклудов, задействованных в работе программы.

*Выполним поиск всех инклудов, задействованных в работе программ

  DATA: BEGIN OF ltb_crossi OCCURS 0,

          name TYPE wbcrossi-include,

        END OF ltb_crossi,

        ltd_wbcrossi TYPE TABLE OF wbcrossi WITH HEADER LINE .

 

  LOOP AT ltd_objk .

    ltb_crossi-name = ltd_objk-obj_name .

    COLLECT ltb_crossi .

  ENDLOOP .

  SELECT DISTINCT * INTO TABLE ltd_wbcrossi

    FROM wbcrossi

         FOR ALL ENTRIES IN ltb_crossi

   WHERE

         include EQ ltb_crossi-name

      OR master  EQ ltb_crossi-name .

 

* Для всех найденных инклудов выполним поиск всех используемых в этих инклудах глобальных типах

  DATA: ltd_wbcrossgt TYPE TABLE OF wbcrossi WITH HEADER LINE .

  SELECT * INTO TABLE ltd_wbcrossgt

    FROM wbcrossgt

                   FOR ALL ENTRIES IN ltd_wbcrossi

   WHERE include EQ ltd_wbcrossi-include .

* Для всех найденных инклудов выполним поиск всех задействованных функциональных модулей

  DATA: ltd_cross TYPE TABLE OF cross WITH HEADER LINE .

  SELECT * INTO TABLE ltd_cross

    FROM cross

                   FOR ALL ENTRIES IN ltd_wbcrossi

Подведем промежуточный итог.

Мы получили списки:

1. Всех объектов разработки, включенных в анализируемый запрос и его подзапросы (задачи);
2. Задействованных при работе данных объектов связанных объектов разработки.

Далее, мы должны руководствоваться следующей логикой:

1. Если используемый объект находится в том же запросе – всё хорошо, его актуальная версия перенесется вместе с объектами, его использующими;
2. Если объект не найден в том же запросе - нужно проверить, должен ли он быть в этом запросе, для того чтобы перенос запроса прошёл без ошибок. Очевидно, что если версии данного объекта в исходной и целевой системе идентичны, переносить его необязательно.
3. Если же используемый объект отсутствует в запросе и его версии между системами различаются –просигнализируем о наличии потенциальных проблем при переносе такого запроса. Необходимо либо включить эти объекты в запрос, либо вначале перенести их в целевую систему в другом запросе.

Сравнение версий объектов между системами

Для выполнения этой задачи в SAP’е есть стандартное средство – система управления версиями с функцией удаленного сравнения версий между системами.

Проверка на наличие различий между версиями делается с помощью вызова ФМ

SVRS_CHECK_VERSION_REMOTE_INT

Заполнение параметров:

Параметр	Описание
E071_ENTRY	Параметр со структурой таблицы E071, но реально значение имеют только поля  PGMI, OBJE, OBJ_NAME. Можем получить значения полей, сделав выборку из E071 по имени объекта (получим заполнение этих полей в любом запросе, в котором он когда-либо присутствовал).
DESTINATION	Имя RFC-соединения для связи с удаленной системой. Это RFC-соединение создаётся системой автоматически, при настройке транспортной системы. Его имя складывается по правилу ‘TMSADM@’ + ИмяСистемы + ‘.’ + ИмяДоменаПереноса . Имя домена переноса можно узнать по имени целевой системы с помощью вызова ФМа TMS_CI_GET_SYSTEMLIST Либо можно использовать вызов ФМа SVRS_GET_RFC_DESTINATION для получения готового RFC адреса.
Результат	Если различий версий не обнаружено, ФМ отработает без ошибок. Если обнаружены различия, произойдёт EXCEPTION NOT_EQUAL  – если версии не идентичны NO_VERSION – если объект в целевую систему вообще пока ещё не переносился.

 

Однако данный ФМ имеет странную особенность: по задумке, если в целевой системе объект ещё отсутствует, он должен бы выдавать EXCEPTION NO_VERSION . Тем не менее, он отработает без ошибок, как будто объект присутствует в целевой системе и различий не найдено.

Поэтому перед вызовом SVRS_CHECK_VERSION_REMOTE_INT произведем сначала вызов ФМа FIND_OBJECT_40, который вначале проверит существование в целевой системе проверяемого объекта:

CALL FUNCTION 'FIND_OBJECT_40'

 EXPORTING

   DESTINATION                 = ‘TMSADM@’ + ИмяСистемы + ‘.’ + ИмяДоменаПереноса

   OBJNAME                     = Техническое имя объекта

   OBJTYPE                     = Тип объекта из поля E071-OBJECT (FUNC, METH, и т.п.)

 IMPORTING

   OBJECT_NOT_FOUND            = Флаг: объект в целевой системе не найден

А уже после этого, если OBJECT_NOT_FOUND окажется пустой – вызываем SVRS_CHECK_VERSION_REMOTE_INT .