Перенос запросов файлами sap
В этом посте рассказывая про транспортную систему (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*-задания выполняются
Многие консультанты знакомы с функциональностью стандартных текстов, создаваемых с помощью транзакции SO10. Довольно часто их используют при реализации различных программ/отчетов и т.д. Помимо частоты использования, возникает вопрос о том, как переносить созданные тексты между системами? Рассмотрим же этот простой, как три копейки, процесс.
Сам текст, как уже было сказано, создается в транзакции SO10:
Переходим к самой важной части, подготовке к переносу данного текста. Открываем транзакцию SE10, жмем на «Создать», создаем новый инструментальный запрос:
Тип задачи созданного запроса изменяем с «Не классифицированного» на «Разработка/Корректура»:
Затем запускаем программу RSTXTRAN, вводим номер созданной задачи из нашего запроса, и запускаем:
На следующем экране консультанту нужно выбрать идентификатор текста, который необходимо перенести. Для этого, необходимо убрать, выделенные по умолчанию идентификаторы текстов, нажав на кнопку «Отменить выбор всех»:
С помощью комбинации клавиш Ctrl + F вводим наименование идентификатора текста, который мы создали, и отмечаем галкой:
Обязательно нажимаем на клавишу Enter, и на открывшемся экране жмем кнопку «Тексты в корректуру».
Порой, русский перевод заставляет шевелиться волосы на всех местах. Если перевести фразу «тексты в корректуру» на «нормальный человеческий» язык, то смысл будет примерно таким: найденный идентификатор текста Z-MY-DEMO-TEXT необходимо добавить в созданный ранее запрос на перенос. Но и наименование для такой кнопки будет сложно придумать.
В этой заметке из серии «для общего развития», представлены варианты выполнения переноса ролей из одной системы в другую.
Решение вопроса
Вариант 1. Создание транспортного запроса
Классический вариант, который должен применяться на каждом проекте. Думаю, что каждому из вас знакомо словосочетание «консистентность систем». Эта самая консистентность достигается при следовании простому правилу: выполняемые настройки производятся в системе разработки с последующим переносом транспортного запроса по всему ландшафту (Dev -> Q/A -> Prod)
Чтобы выполнить перенос роли из одной системы в другую(ие), необходимо создать транспортный запрос, находясь в транзакции PFCG и нажать на кнопку
На следующем экране отметьте необходимые опции, и нажмите на кнопку
Дальше все просто
Созданный запрос готов к импорту в другие системы после его деблокирования (тут возможны варианты, если у вас, к примеру, используется Solution Manager).
N.B. Если вам требуется выполнить перенос роли в пределах одной системы в другой ее клиент, выполнить импорт можно через транзакцию SCC1. Запрос при этом может быть не деблокирован, а запуск импорта следует производить в целевом клиенте
Важно
После импорта роли в целевую систему не забудьте присвоить ей авторизационный профиль, и выполнить его генерацию, находясь на вкладке Authorizations. Содержимое профиля будет перенесено в целевую систему сразу после выполнения импорта запроса/файла, а от вас потребуется только активировать его. На следующем видеофрагменте представлена следующая последовательность действий:
- Импорт роли в систему-источник посредством файла
- Генерация авторизационного профиля после успешно выполненного импорта
Вариант 2. Перенос роли через файл
Не очень хороший способ (по крайней мере лучше, чем прямое выполнение изменений ролей в каждой из систем, да еще в ручном режиме), о котором, тем не менее, следует упомянуть. Выполнение переноса роли можно осуществить через файл, выбрав в контекстном меню транзакции PFCGопцию Role -> Download
Выберите место на локальной машине, куда нужно выполнить сохранение
Заходите в систему, куда требуется перенести скачанную ранее роль, и, находясь в транзакции PFCG, выберите в меню Role -> Upload
Выберите файл для импорта
Дальше все интуитивно и просто
Вариант 3. Перенос роли через RFC
Вариант, увеличивающий вашу крутость на 0,5 пункта. Выполнение импорта роли посредством RFC. В качестве примера рассмотрю вариант импорта роли по RFC из одного клиента (800) в другой (810).
Находясь в клиенте куда необходимо выполнить импорт (810 клиент) в контекстном меню транзакции PFCG выберите Role -> Read from other system by RFC
Выберите RFC соединение для подключения к системе-источнику
Выберите роль из системы-источника, которую необходимо импортировать
Дальше опять все интуитивно и понятно
N.B. При выполнении импорта роли через RFC в целевую систему не будет выполнен импорт авториазионного профиля роли, что делает этот способ не очень привлекательным.
To specify whether you want to use an RFC destination or a variable, use the input help on the Mass Import of Roles screen.
For RFC Destination, use the input help to select the RFC destinations of the system from which you want to import the role, and choose Execute
The Select Roles (No Composite Roles) dialog box appears.Select the roles to be imported. The program imports the selected roles including menu and description into the current system, but does not import the authorization data.
You can also use transaction SM30_SSM_RFC to enter the RFC destination as a variable.
N.B. Используя RFC возможно выполнить удаление роли из систем, куда она была импортирована. Для этого, находясь в транзакции PFCG, выберите в контекстном меню Role -> Distribute Deletion
Укажите RFC соединение
Система предупредит вас об исполняемой операции
В результате, роль будет удалена из системы-получателя.
Массовый экспорт/экспорт ролей
Приведенные опции, а также некоторые другие, доступны через транзакцию PFCG
Иногда бывает необходимо решить задачу по переносу записей одной или нескольких таблиц из одной SAP системы в другую.
- запрос на настройку (customizing request),
- запрос инструментальных средств (workbench request).
Для этого входим в транзакцию SE10 (SE09 или SE01, кому что нравится) и создаем новый запрос, выбрав пункт меню "Запрос/Задача -> Создать". Выбираем нужный тип транспортного запроса (рис. 1).
![]() |
Рис. 1. Создание запроса инструментальных средств. |
Создаем описание для запроса и сохраняем. Обратите внимание, что задачу можно не создавать (рис. 2).
![]() |
Рис. 2. Описание запроса инструментальных средств. |
После этого необходимо встать на номер созданного запроса и нажать кнопку "Просмотр списка объектов" (рис. 3).
![]() |
Рис. 3. Просмотр содержимого транспортного запроса. |
На следующем экране необходимо перейти в режим редактирования и нажать на панели кнопку "Вставить строку" (рис. 4).
![]() |
Рис. 4. Добавление объектов в транспортный запрос. |
Теперь необходимо вписать строку вида: R3TR:TABU: . Здесь TABU - это тип объекта, обозначающий содержимое таблицы (рис. 5).
![]() |
Рис. 5. Добавление записей таблицы в запрос на перенос. |
Если вы добавляете таблицу с данными, то есть типа "А", то система выдаст предупреждение (рис. 6).
![]() |
Рис. 6. Предупреждение при включении записей таблицы в запрос на перенос. |
Чтобы его проигнорировать, необходимо на клавиатуре нажать клавишу "Enter".
После этого следует определить ключ SQL-запроса, по которому будут выбраны записи таблицы для переноса. Для этого необходимо дважды щелкнуть левой клавишей мыши на добавленную запись с таблицей. Для добавления ключа на следующем экране необходимо нажать кнопку "Вставить строку" (рис. 7).
![]() |
Рис. 7. Добавления ключа для выбора записей таблицы в транспортный запрос. |
Для просмотра ключевых полей таблицы можно дважды щелкнуть левой клавишей мыши на строку с ключом (рис. 8).
![]() |
Рис. 8. Просмотр списка ключевых полей таблицы. |
- "*" - включить все записи всех мандантов,
- "300*" - включить записи только манданта 300,
- "30010000001*" - включить записи из манданта 300 для табельного номера 10000001,
- и т.д.
Итак, задать ключ, после чего нажать кнопку "Сохранить" (рис. 9).
![]() |
Рис. 9. Сохранение ключа для выборки записей таблицы. |
Есть возможность просмотреть какие записи будут включены в запрос на перенос, если использовать тот ключ, который был задан. Для этого в экране с отображением ключа необходимо выбрать пункт меню "Перейти к -> Просмотр содержимого таблицы -> Определено через ключ" (рис. 10).
![]() |
Рис. 10. Просмотр содержимого таблицы, определенного через ключ. |
Если все в порядке, то сохранить ключ и запись о таблице. В один запрос можно добавить в несколько таблиц и для каждой определить несколько ключей для выборки. Выйти на экран отображения информации о запросе и деблокировать его, выделив курсором мыши и нажав соответствующую кнопку на панели (рис. 11).
![]() |
Рис. 11. Деблокирование запроса с записями таблицы. |
Чем больше записей таблицы или таблиц включены в запрос, тем дольше будет процесс деблокирования и тем больше будет дата-файл транспортного запроса.
При переносе нескольких, выбранных записей эти записи просто добавляются/модифицируются в целевой системе. Однако SAP система предупреждает, что если переносить все записи с ключом "*", то в целевой системе все записи будут удалены, даже те, которых нет в исходной системе. То есть таблица будет предварительно очищена. Поэтому в данном случае, для ускорения процесса импорта рекомендую, с большой осторожностью, воспользоваться транзакцией SE14, о которой я писал в одноименном посте.
В этом посте рассказывая про транспортную систему (TMS), я уже упоминал, что она используется не только для импорта транспортных запросов, но и для обновления системы пакетами поддержки (SAP Support Packages), и при установке дополнений в систему (add-ons).
- tp - утилита на уровне операционной системы, которая управляет всем процессом импорта, согласовывая работу всех инструментов;
- R3trans - утилита на уровне операционной системы, которая умеет выгружать и загружать данные в любую базу данных, поддерживаемую компанией SAP AG;
- RDDIMPDP - диспетчер импорта в SAP системе, запускающий фоновые RDD*-задания;
- RDD*-задания - набор фоновых ABAP-отчетов, которые выполняют различные фазы импорта в SAP системе.
Основные шаги импорта перечислены в таблице на рисунке 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.
Ситуаций приводящих к сбою во время импорта очень много, но я надеюсь, что знание механизма и фаз импорта, которые я описал, поможет вам локализовать проблему.
Читайте также: