Ручная блокировка работы транспортной системы в SAP

Про транспортную систему я писал уже несколько раз. Смотрите статьи по тегу TMS. А если ничего про это ещё не знаете, то рекомендую начать с поста "Почему SAP рекомендует 3-х системный ландшафт?". 

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

Оба способа работают через файлы в транспортной директории. Вы, наверное, знаете, что в основе транспортной системы лежит файловая система /usr/sap/trans, которая состоит из ряда поддиректорий (рис. 1). Вот некоторые из них:

• /usr/sap/trans/cofiles - содержит управляющие файлы транспортных запросов,
• /usr/sap/trans/data - содержит файлы транспортных запросов с данными,
• /usr/sap/trans/EPS/in - используется при обновлении SAP системы, хранит файлы пакетов поддержки,
• /usr/sap/trans/buffer - хранит файлы-очереди систем, входящих в ландшафт,
• /usr/sap/trans/log - содержит журналы экспорта/импорта транспортных запросов,
• /usr/sap/trans/bin - хранит конфигурацию транспортной системы.

В исходной системе транспортного ландшафта, часто это система разработки (DEV), мы создаём и деблокируем транспортные запросы. В процессе деблокирования в файловую систему транспортной системы экспортируются данные, образуются файлы транспортного запроса. Затем мы, используя данные файлы, можем импортировать транспортные запросы в целевые системы транспортного ландшафта. Чаще всего целевые системы это система тестирования (QAS) и продуктивная (PRD).

Рис. 1. Пример списка поддиректорий файловой системы /usr/sap/trans.

Чтобы запретить деблокирование запросов и экспорт данных в файлы, можно воспользоваться первым хинтом. Для этого необходимо в поддиректории /usr/sap/trans/bin создать файл с именем T_OFF.<SID>. Здесь <SID> - системный идентификатор той системы, из которой мы запрещаем экспорт транспортных запросов. Причем, внутри файла может быть текст, который система будет отображать пользователю при попытке деблокировать транспортный запрос через транзакции SE01/SE09/SE10 (рис. 2 и 3).

Рис. 2. Создание файла для запрета процесса деблокирования запросов.

Рис. 3. Диалоговое окно с сообщением о запрете деблокирования запросов в системе.

Пока файл не удалён, деблокирование в данной системе запрещено.

Второй хинт касается процесса импорта транспортных запросов в систему. Для его выполнения необходимо в поддиректории /usr/sap/trans/tmp создать пустой файл с именем NOIMPORT.<SID>. Здесь <SID> - системный идентификатор уже целевой системы, в которую мы запрещаем импорт транспортных запросов. После этого при попытке импорта любого транспортного запроса в данную систему в транзакции STMS будет выдаваться сообщение об ошибке, в детальном выводе которого можно увидеть информацию о блокировке очереди через файл NOIMPORT.<SID> (рис. 4).

Рис. 4. Блокировка импорта транспортных запросов в систему.

Пока файл в поддиректории существует, импорт в систему невозможен.

Данные возможности могут быть полезны при блокировке систем во время обновления или миграции. 

Автор: Шиболов Вячеслав Анатольевич

Саповские секретики - IV

Секретик 1.

При импорте транспортного запроса в систему через транзакцию STMS можно выбрать 2 режима: синхронный и асинхронный. В первом случае режим SAP GUI будет блокирован до окончания выполнения всех шагов импорта. Во втором случае режим SAP GUI будет сразу освобожден, а импорт транспортного запроса будет происходить в фоне. Выбор режимов происходит в диалоговом окне после выбора пункта меню "Запрос -> Импортировать" во вкладке "Выполнение" (рис. 1).

Рис. 1. Выбор режима импорта транспортного запроса.

Так же можно запланировать импорт транспортного запроса на определенное время. Для этого в диалоговом окне на вкладке "Срок" необходимо указать дату и время выполнения. Рекомендую так же установить время, после которого уже не пытаться запустить процесс импорта. (рис. 2). Данное время необходимо установить на случай недоступности системы или ресурсов (в данном случае фоновых процессов), чтобы импорт не запустился в неподходящее время.

Рис. 2. Планирование импорта транспортного запроса по времени.

После планирования времени импорта в системе будет сформировано фоновое задание (транзакция SM37), которое выполнится в указанное время (рис. 3). У транспортного запроса будет установлен статус "Запланировано" (рис. 4). Данный тип планирования удобен при импорте запросов в нерабочее время, чтобы изменения не коснулись работающих в текущий момент в системе пользователей.

Рис. 3. Фоновое задание по импорту транспортного запроса в систему.

Рис. 4. Статус транспортного запроса после планирования импорта по времени.

Секретик 2.

Еще один нюанс про транспортную систему. Любой транспортный запрос можно переадресовать из очереди одной системы в очередь любой другой системы в рамках транспортного ландшафта вручную. Данное действие можно выполнить вне зависимости от настроенных путей переноса, главное условие: чтобы система была известна в данном ландшафте. Для этого необходимо установить курсор на номер транспортного запроса в очереди на перенос и выбрать пункт меню "Запрос -> Переадресовать -> Система" (рис. 5).

Рис. 5. Переадресация транспортного запроса в другую систему.

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

Рис. 6. Выбор системы для переадресации транспортного запроса.

Секретик 3.

В посте "Стандартные пользователи системы SAP" я писал, что в SAP системе после инсталляции всегда присутствует 000 мандант, который является эталоном. Изменения проводить в нём не рекомендуется. Он используется при создании новых мандантов в системе и для некоторых базисных работ, таких как, обновление системы, установка SAP notes и так далее. Обычно работы, которые проводят в 000 манданте рекомендуют проводить, войдя в систему на английском (EN) языке. Чтобы каждый раз в окне логина не указывать язык EN (что, кстати, легко забывается, так как обычно мы его не указываем, прописав в настройках для всех язык RU, по-умолчанию), я рекомендую в настройках основной записи своего пользователя (транзакция SU01) в 000 манданте сразу указать язык логина EN на вкладке "ПостЗначения" (рис. 7). И входить в 000 мандант всегда на языке EN.

Рис. 7. Установка языка входа для пользователя по умолчанию.

Предыдущие выпуски:
- Саповские секретики - I,
- Саповские секретики - II,
- Саповские секретики - III.


Автор: Шиболов Вячеслав Анатольевич.

Саповские секретики - III

Секретик 1.

Для того, чтобы в транзакциях SE09/SE01/SE10 быстро открыть запрос, зная его номер, достаточно выбрать пункт меню "Запрос/задача -> Просмотр по отдельности..." или просто нажать функциональную клавишу F5 на клавиатуре (рис. 1).

Рис. 1. Просмотр транспортного запроса по отдельности.

В появившемся диалоговом окне ввести номер запроса и перейти в просмотр его содержимого (рис. 2 и 3).

Рис. 2. Ввод номера запроса для просмотра.

Рис. 3. Просмотр запроса по отдельности.

Знание "горячих клавиш" в часто-используемых транзакциях облегчает и ускоряет выполнение производственных задач. :)


Секретик 2.

Помните, я рассказывал как перенести содержимое таблицы между системами. Для включения записей в транспортный запрос необходимо было добавить объект типа TABU, означающий содержимое таблицы, в запрос. Иногда бывает необходимо включить объекты одного транспортного запроса в другой.  Для этого необходимо в транзакции SE01/SE10/SE09 создать новый или открыть существующий целевой запрос (можно способом из первого секретика). Курсор мыши установить на запрос, а в меню выбрать пункт "Запрос/задача -> Список объектов -> Включить объекты..." (рис. 4).

Рис. 4. Включение объектов в текущий запрос.

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

Рис. 5. Включение объектов транспортного запроса в другой запрос.

Здесь стоит помнить, что включить объекты можно только в запрос, который еще не деблокирован, то есть открыт на изменения. А вот на запрос-источник объектов ограничений нет: он может быть как деблокирован, так и открыт на изменения.


Секретик 3.

В посте "Запись каталога объекта: изменение системы оригинала" я писал, что система оригинала для объекта является защитным механизмом для его перезаписи из другой системы. Но иногда необходимо перенести объект из системы не оригинала в другую. Например, восстановить объект в системе разработки из системы контроля качества. В этом случае можно не менять систему оригинала для объекта, как это было описано в посте, а включить объект в запрос типа "Перенос копий". Создать такой запрос можно в транзакции SE09/SE01/SE10 (рис. 6).

Рис. 6. Создание запроса для переноса объектов из системы не оригинала.

После этого включить в запрос объекты, указать целевую систему и деблокировать.

Если попробовать перенести такие объекты в обычном транспортном запросе (типа инструментальных средств), в противоток основным потокам транспортной системы, то система выдаст ошибку при попытке деблокировать запрос. А запроса типа "Перенос копий" поможет решить эту проблему.

Предыдущие выпуски:
- Саповские секретики - I,
- Саповские секретики - II.


Автор: Шиболов Вячеслав Анатольевич

Как узнать кто импортировал транспортный запрос

Если в SAP системе настроен ручной импорт транспортных запросов на изменения, то импорт (или перенос) запросов осуществляется вручную в транзакции STMS. При "доверительных" отношениях внутри группы внедрения запросы на изменения, например, в тестовую систему могут переносить многие члены проектной группы. Чтобы выяснить кто случайно или не случайно выполнил импорт/перенос нужно сделать следующее.

Войти в транзакцию STMS и выбрать очередь необходимой системы. В меню выбрать пункт "Перейти к -> Импорт: история" (рис. 1).

Рис. 1. Переход в историю импорта.

По-умолчанию, окно истории выглядит так, как это показано на рис. 2. Можно задать фильтры по дате/времени, владельцу или номеру запроса.

Рис. 2. История импорта в систему.

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

Чтобы посмотреть кто перенёс запрос, необходимо выбрать пункт меню "Обработать -> Показать больше" (рис. 3).

Рис. 3. Отображение больше информации в истории импорта.

После этого на экране истории импорта появится поле "Пользователь", в котором отображено имя пользователя, который запустил импорт запроса в систему (рис. 4).

Рис. 4. Отображение пользователя, который импортировал запрос в систему.

Таким образом, можно выяснить кто и в какое время импортировал транспортный запрос.


Автор: Шиболов Вячеслав Анатольевич

Хватит ли номеров для транспортных запросов?

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

SAP система не исключение. Для изменений объектов репозитария и настроек используется система разработки (DEV), для тестирования - система контроля качества (QAS), а после тестирования изменения переносятся в систему промышленной эксплуатации или продуктивную систему (PRD). Типичный ландшафт представлен на рисунке 1.

Рис. 1. Типовой транспортный ландшафт SAP системы. 

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

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

Каждый транспортный запрос имеет свой уникальный идентификатор или номер, вида:

<SID>K9<номер запроса>

Интервалы номеров запросов имеют длину 5 символов и изменяются от '00001' до '99999'. 

Как я уже упоминал в посте "Решение проблем с транспортной системой", текущий номер запроса хранится в таблице E070L. Новый присваивается путём увеличения текущего на единицу.

На проектах, которые существуют давно и активно разрабатываются, высока вероятность достижения максимального номера, равного '99999'. Многие переживают, что дальше всё остановится. Спешу развеять опасения. :) Дальше автоматически будут использованы буквы латинского алфавита. Для расширения используются диапазоны от 'A0000' до 'ZZZZZ' или от 'AAAAA' до 'Z9999' (рис. 2). В результате, существует порядка 40 миллионов номеров для транспортных запросов.  

Рис. 2. Пример расширенной нумерации транспортных запросов.

Так же можно использовать отчет RSWBO301, который находит свободные непрерывные интервалы выбранной длины. Например, вводим длину 5000 и получаем интервал, который можно использовать (рис. 3 и 4) - с '74262' до '79261'. При этом в данном примере последний активный номер в системе уже '9A00FY'. 

Рис. 3. Пример использования программы RSWBO301.

Рис. 4. Результаты работы отчета RSWBO301.

Если интервал подходит, то нажимаем кнопку "Интервал" для сохранения и после этого запросам будут присваиваться номера в рамках заданного интервала, по достижении верхней границы которого, нужно будет снова воспользоваться этим отчетом.

Самостоятельно поменять номер текущего запроса в таблице E070L можно собственной ABAP-программой, через уровень базы данных или через режим отладки (хинт).

Подробности можно найти в SAP нотах:

• 1674286 - How to modify CTS transport number range (ABAP),
• 106911 - Transport system: number range filled for requests.

Автор: Шиболов Вячеслав Анатольевич

Как убрать кнопку "Импортировать все запросы"

При настройке транспортной системы в транспортном ландшафте SAP систем есть возможность выбора из трех стратегий импорта транспортных запросов:

• массовый импорт запросов (или контролируемый очередью),
• одиночный импорт,
• импорт контролируемые через workflow.

При массовом импорте запросов (queue-controlled mass transports) основной стратегией является импорт запросов очередью, определенной каким-то проектом, пользователем или периодичностью. Данная стратегия позволяет получить максимальную синхронизацию и консистентность систем, входящих в транспортный ландшафт. При этом не исключается импорт одиночных запросов.

При выборе стратегии одиночного импорта (single transports) импорт возможен только одиночными запросами. При этом запросы импортируются только один раз. Стратегия требует особого контроля со стороны системного администратора и разработчиков. Данный случай подходит для систем и проектов, на которых генерируется относительно небольшое количество транспортных запросов.

Последняя стратегия (workflow-controlled transports) подразумевает организацию специальной процедуры (QA Approval Procedure), где определяются ответственные, которые могут давать "добро" на импорт запросов. Импорт запросов осуществляется автоматически.

Посмотреть/переключить стратегию можно в утилите настройки транспортных маршрутов (транзакция STMS, пункт меню "Overview -> Transport Routes"), если дважды щелкнуть мышью на системе-контроллере транспортного домена (рис. 1 и 2).

Рис. 1. Экран настройки транспортных маршрутов.

Рис. 2. Экран изменения атрибутов системы.

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

Рис. 3. Панель управления очередью транспортных запросов.

Как видно из снимка экрана, процесс планирования и запуска импорта транспортных запросов представлен двумя кнопками:

• импортировать все запросы,
• импортировать запрос.

Первая кнопка часто является проблемой и головной болью для администраторов. Если полномочиями на импорт транспортных запросов в системе обладает большое количество специалистов, то существует вероятность того, что кто нибудь когда нибудь нажмёт на эту кнопку. В результате нажатия происходит импорт всех транспортных запросов, находящихся в данный момент в очереди. А так как часто, идя на поводу у консультантов, специалист по BASIS не удаляет уже импортированные запросы на перенос (оставляя их для истории или повторного импорта в систему), то система в результате операции очень сильно изменяется. :) Как вы знаете, откатить транспортный запрос назад невозможно, поэтому решение возникшей проблемы, вопрос не из легких.

Но есть возможность эту кнопку с панели убрать. Для этого достаточно в параметрах утилиты tp нужной системы прописать параметр "NO_IMPORT_ALL" со значением 1. Сделать это можно, вызвав в транзакции STMS пункт меню "Overview -> Systems" и дважды щелкнув левой клавишей мыши на нужной системе. А затем в закладке "Transport Tool" в режиме редактирования добавить вышеуказанный параметр (рис. 4).

Рис. 4. Редактирование параметров утилиты tp.

После сохранения настройки панель управления очередью импорта измененной системы будет содержать только кнопку "Импортировать запрос" (рис. 5).

Рис. 5.  Панель управления очередью импорта без кнопки.

Надеюсь, что этот небольшой момент позволит кому-то из вас избежать лишней работы и головной боли.

Еще раз напомню, что вопросы касающиеся транспортной системы освещены в учебном курсе SAP ADM325.

Автор: Шиболов Вячеслав Анатольевич

Копирование манданта SAP системы

Как вы знаете, в SAP системе есть такое понятие как мандант. Мандант системы, с одной стороны, это набор таких данных как: манданто-зависимые настройки (customizing), основные записи пользователей (users) и основные данные или данные приложений (application data, master data) (рис. 1).

Рис. 1. Структура данных в SAP системе.

С другой стороны, с технического ракурса, мандант это набор записей таблиц, у которых поле MANDT = <номер манданта>. На уровне бизнеса же, мандант - это автономная единица в SAP системе для работы предприятия и хранения данных. В теории, два предприятия могут работать в разных мандантах одной системы без какого-либо нарушения целостности и безопасности данных.

Учтите что, в англоязычной литературе, мандант это client.

Мандант имеет номер из трех цифр и, в системе может быть до 1000 мандантов (от 000 до 999).

После установки SAP системы, в зависимости от типа и версии продукта, в ней могут присутствовать несколько стандартных мандантов, таких как, 000, 001 и 066.

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

Существует три вида процедуры копирования:

• локальная копия манданта,
• удаленная копия манданта,
• экспорт/импорт манданта.

Локальная копия манданта подразумевает, что копирование производится внутри одной SAP системы.

Процедура выполнения локальной копии следующая:

1. В транзакции BD54 создать логическую систему для нового манданта.
2. В транзакции SCC4 создать запись о новом манданте.
3. Войти в новый мандант системы под псевдо-пользователем SAP* с паролем PASS.
4. В транзакции SCCL запустить копирование с выбранным профилем для копирования.
5. Для мониторинга процесса использовать транзакцию SCC3.

Полезные SAP notes:

• 550894 - CC-ADMIN: Setting up a new client - описана процедура создания первого манданта из эталонного 000 манданта,
• 446485 - CC-ADMIN: Special copying options - специальные дополнительные опции, которые можно активировать при копировании манданта.

Удаленная копия манданта (remote client copy) выполняется между двумя системами. Копия выполняется "на лету", то есть физической копии манданта не создается, место на жестком диске не используется. В качестве механизма используется RFC.

Процедура удаленного копирования манданта:

1. В целевой системе войти в транзакцию BD54 и создать логическую систему для нового манданта.
2. В целевой системе в транзакции SCC4 создать запись о новом манданте.
3. В транзакции SM59 создать RFC-соединение до исходного манданта/системы.
4. Войти в новый мандант системы под псевдо-пользователем SAP* с паролем PASS.
5. В транзакции SCC9 запустить копирование с выбранным профилем.
6. Для мониторинга использовать транзакцию SCC3 в целевой системе.

Полезные SAP notes:

• 99284 - RFC exception: RESOURCE_FAILURE - описаны решения проблем с RFC,
• 557132 - CC-TOPIC: Remote client copy - общая нота про нюансы удаленного копирования манданта,
• 47502 - CC-REMOTE: Messages of the Remote Clientcopy - сообщения об ошибках во время удаленного копирования и что с ними делать.

И при локальном, и при удаленном копировании можно включать параллелизм. Для этого в транзакциях копирования при планировании следует выбрать пункт меню "Перейти к -> Параллельные процессы" (рис. 2).

Рис. 2. Планирование параллельных процессов при копировании манданта.

При выполнении копирования манданта через экспорт/импорт процедура состоит из двух частей: экспорта из исходной системы и импорта в целевую систему. Для проведения процедуры рекомендуется чтобы системы находились в одном транспортном ландшафте. При экспорте создается физическая копия исходного манданта, которая занимает место в транспортной директории.

Процедура экспорта манданта следующая:

1. В исходной системе/манданте войти в транзакцию SCC8 и запланировать экспорт в транспортные запросы с выбранным профилем.
2. Мониторинг производится в транзакции SCC3.

Процедура импорта манданта следующая:

1. В целевой системе в транзакции BD54 создать логическую систему для нового манданта.
2. В целевой системе в транзакции SCC4 создать запись о новом манданте.
3. Войти в новый мандант системы под псевдо-пользователем SAP* с паролем PASS.
4. Войти в транзакцию STMS, найти запросы с экспортом, запустить импорт запросов.
5. После окончания импорта войти в транзакцию SCC7 и выполнить шаги пост-импорта манданта.
6. Мониторинг последнего шага в транзакции SCC3.

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

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

При копировании манданта репозитарий не копируется (рис. 1). При удаленном копировании можно (выбрав соответствующий профиль копирования) скопировать манданто-независимые настройки. Объединить два манданта в один при копировании нельзя.

Если обновляется/замещается существующий мандант, то перед копированием данные из него удаляются (можно это выполнить предварительно вручную).  

При удаленном копировании и экспорте/импорте необходимо чтобы структура таблиц исходной и целевой системы совпадали. Сравнение можно выполнить на предварительном этапе через кнопку "RFC/сравнение систем" (рис. 3).

Рис. 3. Сравнение структуры таблиц перед удаленным копированием.

Еще полезные SAP notes:

• 489690 - CC INFO: Copying large production clients,
• 22514 - CC-INFO: Error analysis for client copy.

Автор: Шиболов Вячеслав Анатольевич

Механизм импорта транспортных запросов. Решение проблем

В этом посте рассказывая про транспортную систему (TMS), я уже упоминал, что она используется не только для импорта транспортных запросов, но и для обновления системы пакетами поддержки (SAP Support Packages), и при установке дополнений в систему (add-ons).

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

• tp - утилита на уровне операционной системы, которая управляет всем процессом импорта, согласовывая работу всех инструментов;
• R3trans - утилита на уровне операционной системы, которая умеет выгружать и загружать данные в любую базу данных, поддерживаемую компанией SAP AG;
• RDDIMPDP - диспетчер импорта в SAP системе, запускающий фоновые RDD*-задания;
• RDD*-задания - набор фоновых ABAP-отчетов, которые выполняют различные фазы импорта в SAP системе. 

Утилита tp согласовывает работу фоновых заданий через таблицы базы данных TRBAT и TRJOB. В первую из них утилита tp добавляет задания для диспетчера импорта (RDDIMPDP) в виде списка запросов на импорт с обозначением текущих фаз импорта. Во второй фиксируются номера и ID фоновых RDD*-заданий во время выполнения. После окончания импорта утилита tp удаляет записи из таблиц, считывая коды возврата. Таким образом, если в данный момент не происходит импорт запросов на перенос, то данные таблицы не должны содержать записи.

Основные шаги импорта перечислены в таблице на рисунке 1.

Рис. 1. Шаги по импорту транспортных запросов/пакетов поддержки в SAP систему.

Как вы наверное знаете, при импорте нескольких запросов каждый шаг выполняется для всех запросов на импорт одновременно. Это приводит к тому, что на этапе, например, активации, если какой-то объект существует в нескольких запросах, то выбирается и активируется только самая последняя (можно считать самая корректная) версия объекта.

Но вернемся к таблице. Для каждого шага утилитой tp вызывается своя утилита (поле "Инструмент"). Каждый инструмент в поддиректории /usr/sap/trans/tmp генерирует журнал выполнения (поле "Вид журнала"), который после завершения этапа переносится в поддиректорию /usr/sap/trans/log.

Диспетчер импорта (RDDIMPDP) запускается по событию SAP_TRIGGER_RDDIMPDP, которое инициализирует tp с уровня операционной системы через утилиту sapevt (рис. 2). Все RDD*-задания выполняются из под пользователя DDIC (рис. 3).

Рис. 2. Настройки задания RDDIMPDP.

Рис. 3. Пример выполненных фоновых RDD*-заданий при импорте запросов.

Планирование диспетчера импорта производится через отчет RDDNEWPP (000 мандант, пользователь DDIC, транзакция SE38 -> отчет RDDNEWPP -> Выполнить) (рис. 4).

Рис. 4. Планирование фонового задания RDDIMPDP.

Итак, если по какой-то причине импорт запросов/пакетов поддержки не происходит, то проверяем следующее:

• журнал утилиты tp, который доступен по следующему пути "транзакция STMS -> Обзор -> Импорты -> Перейти к -> ПрогрУпрПереносом (TP): системный журнал (выбрать систему)" (или на уровне операционной системы файл /usr/sap/trans/log/SLOG*.SID);
• не блокирован ли пользователь DDIC в 000 манданте;
• в транзакции SM37 анализ запуска диспетчера импорта (RDDIMPDP) и RDD*-заданий;
• на уровне операционной системы в поддиректориях /usr/sap/trans/tmp и
  /usr/sap/trans/log анализ журналов (рис. 1), определение сбойного шага импорта;
• в транзакции SE16 проверка записей таблиц TRBAT и TRJOB.

Если перенос запроса завис на одном из этапов, за который отвечает одно из RDD*-заданий, то можно попробовать, войдя в 000 мандант под пользователем DDIC, выполнить программу RDDIMPDP через транзакцию SE38 вручную.

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

Дополнительная информация по данной теме:

• материалы учебного курса SAP ADM325 (Unit 4: Importing Transport Requests);
• SAP ноты из раздела BC-CTS, например:
  - 11677 - Transports with event-controlled RDDIMPDP,
  - 358813 - Job class of background jobs during import,
  - 1702079 - Background jobs cannot be started, exit code 7 in SLOG during Support Package/transport import,
  - 1712442 - Transport request hung during import. Background job RDDIMPDP is not scheduled.

Автор: Шиболов Вячеслав Анатольевич

Решение проблем с транспортной системой

Самое гениальное, что есть в системе SAP и что кочует практически неизменным из версии в версию, это транспортная система (TMS). И действительно, зачем менять прозрачный и отлаженный механизм? :)
Но время от времени и в такой идеальной системе возникают проблемы. Как у меня сегодня утром. Перестали импортироваться запросы в тестовую систему. Перелопатил всё что можно, пока докопался до причины. Решил написать памятку для коллег. И так,

• Транзакция STMS. Входите в очередь нужной системы и там изучаете пункты меню "Перейти к". Особенно пункты "Монитор импорта" и системный журнал программы tp.
• Таблица E070L. Содержит номер последнего запроса в системе. Можно сделать скачок в будущее :) Подробности в SAP Note # 12799.
• Таблица TMSTLOCKR. Хранит блокировки импортируемых в данный момент запросов.
• Таблицы TRBAT и TRJOB. Временные записи во время импорта.
• Фоновые задания RDDIMPDP. Смотреть выполняются или нет, почему. Планирование заданием RDDNEWPP в 000 манданте. Подробности в SAP Note # 26966.
• На уровне ОС файловая система /usr/sap/trans и поддиректории. Полномочия, права, свободное место.
• Процессы tp на уровне ОС.

Есть хороший курс по транспортной системе (TMS) - ADM325. Рекомендуется минимум прочитать самостоятельно.

P.S. А моя проблема была в старой записи в табличке TRJOB. Кстати, очистить такую рабочую табличку от всех записей можно через транзакцию SE14. Вписываете имя объекта. Нажимаете кнопку "Edit" и, выбрав "Delete data", жмёте "Activate and adjust database". Опля! И табличка пустая.


Автор: Шиболов Вячеслав Анатольевич