Перенос запросов файлами sap
Обновлено: 07.07.2024
Сопровождающий файл и файл данных
Тип «К» означает сопровождающий файл, a «R» и «D» — файлы данных. В этом примере были созданы сопровождающий файл K903522.IE4 и файл данных R903522.IE4.
6.2.4. Организатор переносов Transport Organizer (расширенное представление)Расширенное представление Организатора переносов предлагает дополнительные функции переноса, кроме знакомых возможностей по управлению запросами пользовательской настройки (Customizing) и инструментальных средств (Workbench). Дополнительные возможности используют общий подход: они не следуют по предопределенному пути переноса.
Эти функции включают в себя:
По различным причинам может потребоваться перенести определенные объекты в другую систему. В зависимости от требований объекты могут также сохранять свою систему оригинала или присваивать новую систему. Ниже приводятся возможные сценарии:
- Простая копия объектов в другую систему; можно выбрать любую систему по желанию.
- Перемещение объектов без изменения класса или пакета разработки позволяет временно сохранить проекты разработки в другой системе. Система оригинала объектов изменяется на новую.
- Перемещение объектов с изменением пакета или класса разработки позволяет сохранять проекты разработки в другой системе постоянно. Система оригинала объектов изменяется на новую; пользователю не требуется настраивать свойства переноса, если выбран пакет с присвоенным уровнем переноса.
- Перемещение полных пакетов или классов разработки для постоянного хранения всего пакета на другой системе. Система оригинала объектов изменяется на новую систему, и настраивается уровень переноса.
За исключением перемещения полных пакетов, используемые объекты должны обрабатываться вручную.
В Организаторе переносов можно создать запросы для переносов копий и перемещения оригиналов.
Кроме возможностей предоставленных администрированием клиента (См. главу 7), здесь можно также просмотреть обзор выполненных переносов клиента.
Списки объектов представляют собой совокупности объектов, которые могут соединяться с запросами на перенос в качестве шаблонов.
Списки всех объектов класса разработки (или согласно другому набору общих свойств объектов) могут создаваться автоматически. Можно также создавать списки объектов вручную.
Корректировки и исправления (патчи, заплатки), выпущенные SAP и ее партнерами, требуют специального администрирования, так как они содержат объекты в области имен SAP. Этот тип запроса на перенос нетрудно распознать по его имени — SAPK<номер>.
Все функции подробно описываются со списком параметров и могут запускаться при выборе меню Tool • Execurte.
Например, с помощью меню Administration • Display/change request attributes можно выявить или изменить атрибуты запросов на изменения или установить принудительные атрибуты. Например, можно определить, является ли назначение проекта запросу на перенос предварительным условием для выполнения запроса.
После разблокирования запроса на изменение в инфраструктуре переноса данные не только экспортируются, новый запрос записывается также в очередь импорта целевых систем.
На рис. 6.16 показаны 11 запросов для системы обеспечения качества и 22 запроса для производственной системы в очереди для импорта. Можно вывести более подробную информацию о типе и области действия запросов, выбирая требуемую систему.
Рис. 6.15. Инструменты CTS
Рис. 6.16. Обзор импорта в трехсистемной инфраструктуре
На рис. 6.17 показана очередь импорта для примера системы «ER3». Начиная с этого экрана, администратор может координировать все предстоящие операции по импорту. Ниже описаны наиболее важные рабочие шаги при обычной работе.
Последовательность запросов в очереди импорта
Последовательность запросов в очереди импорта зависит от времени их экспорта из исходной системы. Запросы будут импортироваться в той же последовательности. Разблокированные запросы на перенос той же группы переноса (см. главу 5) автоматически поступают в очередь импорта в целевую систему. Если целевая система присвоена другой группе переноса и поэтому использует другой каталог переноса, то нужно сначала найти ожидающие запросы с помощью команды Extras • Other Requests • Find In Other Groups. Такая же последовательность действий применяется, когда домены переноса соединяются связями доменов. Если найдены дополнительные запросы для данной системы, то они включаются в очередь импорта выбранной системы.
Открытие и закрытие очереди импорта
Завершенные задачи разработки должны импортироваться в соответствии с планом, заранее согласованным разработчиками. Импорт выполняется через фиксированные интервалы времени. Для предотвращения несогласованности и достижения определенного состояния промежуточной системы SAP R/3 на этот период необходимо временно закрыть очередь импорта, установив конечный маркер. Все запросы, поступившие после этого времени, откладываются до следующего импорта. Чтобы вставить конечный маркер в очередь импорта, выберите команду Queue • Close, а чтобы установить его перед конкретным запросом — Queue • Move End Mark. Команда Queue • Open позволяет открыть закрытую очередь импорта.
Импорт
Можно начать импорт в систему для подмножества ожидающих запросов. Можно также объединять отдельные запросы с помощью Edit • Select • Select/Deselect request или Edit • Select • Select block, обработать всю очередь до конечного маркера (Queue • Start Import) или импортировать избранные переносы (Request • Import). В зависимости от настроек ранее импортированные отдельные запросы могут оставаться в очереди.
Многие консультанты знакомы с функциональностью стандартных текстов, создаваемых с помощью транзакции SO10. Довольно часто их используют при реализации различных программ/отчетов и т.д. Помимо частоты использования, возникает вопрос о том, как переносить созданные тексты между системами? Рассмотрим же этот простой, как три копейки, процесс.
Сам текст, как уже было сказано, создается в транзакции SO10:
Переходим к самой важной части, подготовке к переносу данного текста. Открываем транзакцию SE10, жмем на «Создать», создаем новый инструментальный запрос:
Тип задачи созданного запроса изменяем с «Не классифицированного» на «Разработка/Корректура»:
Затем запускаем программу RSTXTRAN, вводим номер созданной задачи из нашего запроса, и запускаем:
На следующем экране консультанту нужно выбрать идентификатор текста, который необходимо перенести. Для этого, необходимо убрать, выделенные по умолчанию идентификаторы текстов, нажав на кнопку «Отменить выбор всех»:
С помощью комбинации клавиш Ctrl + F вводим наименование идентификатора текста, который мы создали, и отмечаем галкой:
Обязательно нажимаем на клавишу Enter, и на открывшемся экране жмем кнопку «Тексты в корректуру».
Порой, русский перевод заставляет шевелиться волосы на всех местах. Если перевести фразу «тексты в корректуру» на «нормальный человеческий» язык, то смысл будет примерно таким: найденный идентификатор текста Z-MY-DEMO-TEXT необходимо добавить в созданный ранее запрос на перенос. Но и наименование для такой кнопки будет сложно придумать.
Про транспортную систему я писал уже не раз (прочитать можно тут). Типичная картина: в системе настройки/разработки создаётся транспортный запрос, который содержит изменения (записи таблиц с настройками или объекты ABAP-словаря). Затем этот запрос деблокируется (released) и отправляется дальше по системам для тестирования и промышленной эксплуатации. Это все, наверное, знают.
Так же вы знаете, что ABAP-словарь системы является общим для всех мандантов системы, а настройки могут быть двух видов - манданто-зависимые (большинство) и манданто-независимые. Манданто-независимые объекты доступны для всех мандантов системы сразу после создания. А манданто-зависимые оказывают влияние только на текущий мандант.
Часто бывает ситуация, когда в системе настройки создано несколько мандантов: чистая разработка-настройка, первичный тест, "песочница" и так далее. Первый сегодняшний секретик заключается в том, что есть возможность перенести запрос с манданто-зависимыми настройками внутри одной системы - из одного манданта в другой. Причем, запрос даже не нужно деблокировать - он может оставаться открытым для изменения. Для этого, после создания запроса с настройками в исходном манданте, необходимо войти в целевой мандант той же системы и запустить транзакцию SCC1. На основном экране необходимо указать номер транспортного запроса и исходный мандант, в котором запрос был создан. После этого поставить галочку напротив пункта "Включ. нижестоящие задачи запроса" и нажать кнопку "Немедленный запуск" (рис. 1).
Рис. 1. Основной экран транзакции SCC1
Подтвердить перенос данных, нажав "Да" в диалоговом окне (рис. 2).
Рис. 2. Запрос на копирование данных между мандантами
После выполнения переноса, при возврате на шаг назад в транзакции, система выдаст журнал переноса запроса (рис. 3).
Рис. 3. Журнал переноса запроса между мандантами одной системы
Отдельно журнал доступен в транзакции SCC3. Для отображения журналов переносов запросов между мандантами необходимо на панели нажать кнопку "Все запросы на перенос" (рис. 4 и 5).
Рис. 4. Начальный экран транзакции SCC3
Рис. 5. Просмотр журнала в транзакции SCC3
В данном примере, ошибка словаря связана с тем, что запрос содержал манданто-независимые данные, копировать которые нет необходимости.
Секретик 2.
Как-то я писал пост про такой полезный инструмент, как "User Information System", к которому можно получить доступ через транзакцию SUIM. В транзакции представлен набор отчетов по пользователям/ролям/полномочиям в системе. Инструмент хороший, но очень объемный.
Поэтому второй секретик будет о том, как посмотреть документы изменений для пользователя ABAP системы. Необходимо войти в транзакцию SU01 (Ведение пользователей), ввести имя пользователя, а в меню выбрать пункт "Инфо
Здесь создадим пакет и транспортный запрос, что это такое и для чего нужно рассказывается дальше в этой статье. Выполнив все установки и запустив сервер разработки логинимся в систему, используя SAP GUI.
Графический интерфейс пользователя — клиент в трехуровневой архитектуре SAP R/3. Интерфейс SAP GUI реализован на основе Windows Style Guide, стандартов EG 90/270 и ISO9241, определяющих эргономику интерфейсов. SAP GUI является универсальным клиентом SAP для доступа к функциям SAP приложений, таких как SAP - SAP ERP, SAP Business Suite (SAP CRM, SAP SCM и SAP PLM), SAP Business Intelligence и так далее. SAP GUI функционирует как браузер. Он получает информацию с сервера, чтобы отобразить содержимое в своем окне. Все члены семейства SAP GUI имеют уникальные свойства, которые делают их особенно подходящими для различных пользовательских сред. На данный момент реализованы интерфейсы для Windows, Unix, MacOS. В настоящий момент очень широкое распространение получает технология Web Dynpro, позволяющая для отображения информации использовать обычный браузер.
Появляется окно входа. Для входа в систему используем стандартного пользователя BCUSER и пароль который установили во время установки, а также Clien (Мандант) 001
Система R/3 является системой, поддерживающей концепцию мандантов. Концепция мандантов позволяет нескольким разным, не зависящим друг от друга предприятиям выполнять совместные операции в одной системе. При каждом пользовательском сеансе возможен доступ только к данным манданта, выбранного при регистрации в системе. Таким образом, SAP R/3 позволяет вести учет нескольким разным предприятиям в одной системе R/3.
Мандант - это организационно независимая часть в системе R/3. Каждый мандант имеет собственную среду данных, т.е. собственные основные и переменные данные, присвоенные основные записи пользователей, планы счетов и специфические параметры настройки. Номер манданта находится в диапазоне от 000 до 999.
Технически мандант организован как дополнительное ключевое поле в таблицах базы данных.
Кроме параметров настройки для определенного манданта, т.н. мандантозависимые настройки, существуют также мандантонезависимые настройки, устанавливаемые один раз для всех активных мандантов. К таким общим для всех мандантов параметрам настройки относятся, например, настройки принтеров.
Репозитарий также является независящим от манданта объектом. Он содержит все объекты словаря (таблицы, элементы данных и домены), а также ABAP-программы, меню, экраны и т.п.
Вследствие того, что объекты репозитария являются общими для всех мандантов, разработанный в каком-либо манданте объект будет идентичным во всех мандантах этой системы.
Для обеспечения системной целостности при разработке рекомендуется сформировать системный ландшафт, состоящий из трех систем:
1. Система для разработки и настройки. В этой системе ведется разработка программ, специфичных для предприятия, а также выполнение необходимой пользовательской настройки. Поскольку объекты репозитария являются общими для всех мандантов, система разработок не может одновременно использоваться для продуктивной эксплуатации. Это был бы слишком большой риск в плане нарушения целостности данных.
2. Система для тестирования разработок. Все параметры пользовательской настройки, а также изменения репозитария (разработки, корректировки или модификации) переносятся в систему обеспечения качества (или "тестовую систему") для их проверки без связи с продуктивной эксплуатацией.
3. "Продуктивная" система для производственной эксплуатации. Все объекты и настройки, импортированные в тестовую систему и прошедшие тестирование, могут быть затем перенесены в одну или несколько продуктивных систем.
Трехсистемный ландшафт позволяет также тестировать обновления и помогает минимизировать время простоя во время обновления продуктивной системы
С началом нового проекта разработок в рамках проекта внедрения, руководитель проекта создает запрос на изменение и назначает разработчиков - членов проектной группы. Организатор переносов присваивает запросу на изменение определенный номер (например, C11K900001). Запрос на изменение должен содержать логически взаимосвязанные изменяемые объекты, так как в дальнейшем в тестовую и затем в продуктивную систему будет переноситься запрос целиком вместе со всеми разработками, содержащимися в запросе. Таким образом, запросы на изменение позволяют осуществлять перенос и управление логически завершенными разработками.
Каждый раз, когда разработчик изменяет или добавляет объект репозитария, необходимо выбрать для этого изменяемого объекта класс разработок. Класс разработок представляет собой укрупненную тему проекта и предназначен для объединения логически связанных разработок. Например, может быть класс разработок для объединения приложений по финансам, сбыту и т.д.
Далее система запрашивает номер запроса, в который следует поместить объект. Автоматически для данного разработчика создается задача в рамках выбранного запроса, в которую помещается ссылка на изменяемый объект. Таким образом, каждый разработчик собирает в своих задачах все объекты, которые он создал или которые подверглись с его стороны модификации.
Если какой либо другой разработчик выберет тот же запрос для своих объектов, для него в пределах этого запроса будет создана задача, в которую будут помещены ссылки на измененные или созданные им объекты.
Таким образом, запрос объединяет усилия нескольких разработчиков для решения какой либо логически законченной задачи. При завершении своей части проекта разработок каждый участник проектной группы деблокирует свою задачу, после чего объекты задачи передаются в запрос на изменение. Запрос на изменение объединяет все объекты репозитария, которые были созданы или изменены в ходе проекта разработок.
После деблокирования всеми участниками группы своих задач руководитель проекта может деблокировать запрос на изменение, который затем может быть импортирован в систему тестирования. Параметры пользовательской настройки регистрируются точно таким же образом.
Изменения в репозитарии разделяются на три большие группы: разработки, расширения и модификации.
Клиенты могут добавлять в репозитарий свои собственные разработки. Все разработки клиента выполняются с использованием области имен для клиента. Это значит, что все объекты, созданные клиентом, имеют имена, соответствующие определенной области имен. Например, ABAP-программы клиента должны начинаться с символов Y или Z, а функциональные модули – с символов Y_ или Z_.
Кроме того, клиенты могут добавлять так называемые "расширения клиента" - объекты клиента, добавляемые к существующим объектам в стандартной системе SAP. Клиенты добавляют свои расширения через так называемые customer exit'ы ("выходы в программы клиента").
Модификации изменяют такие объекты SAP, как отчеты и определения таблиц. Репозитарий, поставляемый SAP, может быть не только расширен, но и изменен. Именно поэтому модификации могут потребовать адаптации в соответствии с новым репозитарием, инсталлированным в ходе последнего обновления системы SAP.
Используя транзакцию SE80, перейдем в навигатор объектов Object Navigator . Название говорит само за себя, с помощью этой транзакции, мы получаем быстрый доступ ко всем объектам системы. Транзакция SE80 - основная транзакция для разработчика.
Попадаем в навигатор объектов.
Для группировки(структуризации) наших объектов разработки cоздадим пакет Package. В процессе создания различных объектов системы будем применять названия из определенной области имен-namespace ZKRE*. Пакет можно создать с помощью транзакции SE21 или через SE80(мы воспользуемся именно SE80) Из выпадающего списка выбираем Package, вводим название пакета ZKRE_PRO1 и нажимаем кнопку Dispaly.
Появилось диалоговое окно, где система предлагает создать пакет.
Нажимаем YES, после чего появляется следующее окно.
Вводим необходимые атрибуты и нажимаем Enter. Для полей Application Component, Software Component, Transport Layer доступно средство поиска - Search Help нажатием клавиши F4. В стандартном девелопменте SAP, когда он сам ведет разработку очень важно указывать Application Component (влияет на хелп, на поиск и т.д), в нашем случае Z-девелопменте можно было бы ничего не указывать, но по правилам хорошего тона приассайним что-то типа AP. Поле Software Component опять таки важно для стандартной разработки, в нашем случае укажем HOME, что означает, что этот объект не покинет эту систему. Transport Layer выбираем ZNSP. Для Package Type выбираем Not a Main Package. Нажимаем Ввод и переходим к следующему диалоговому окну, где нам необходимо ввести номер нашего транспортного запроса, который еще не создан.
Если воспользоваться средством поиска увидим экран на котором нет ни одного запроса для юзера BCUSER.
Запрос можно было создать заранее используя транзакцию SE10, но можно создать прямо сейчас нажав кнопку Create (F8).
Появляется окно, где необходимо ввести краткое описание для запроса.
Нажимаем Сохранить(Save). После того как запрос создан, система отобразит его техническое имя.
Где виден номер только что созданного запроса (может отличаться от вашего). Нажимаем Enter и на этом все - наш пакет создан(он отобразился в навигаторе объектов).
Используя транзакцию SE10 можно посмотреть что у нас получилось.
Нажимаем кнопку Display. И видим созданный нами запрос и пакет.
Раскрыв дерево увидим что там уже имеется наш пакет. В дальнейшем все наши создаваемые объекты мы будем помещать в только что созданный пакет и запрос.
Читайте также: