SAP R/3 Системное администрирование

постоянно соприкасается с данной областью при выполнении задач администрирования, таких как обновление R/3 (Upgrade) и исправление ошибок.

Каждый пользователь, желающий разработать в системе SAP R/3 новые объекты или внести изменения в объекты, поставляемые SAP, сначала должен зарегистрироваться как пользователь данной системы SAP R/3 (см. рис. 6.11). Требуемый ключ можно создать в OSS или SAP Service Marketplace (см. главу 3).

Рис. 6.11. Регистрация разработчика и объекта

В этом случае администраторы SAP R/3 и сама компания SAP имеют обзор, какие разработки происходят в системе SAP R/3. Следующие процедуры требуют принятия решения, будет ли объект SAP модифицироваться или должна происходить новая разработка (создание нового объекта).

Изменение объектов SAP

Каждое изменение в объекте SAP предусматривает регистрацию данного объекта. Ключ доступа можно получить через OSS или SAP Service Marketplace. Введите спецификации выбранного объекта (см. рис. 6.12) и полученный ключ доступа на экране, показанном на рис. 6.11.

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

Новые разработки

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

Рис. 6.12. Регистрация ключа объекта в SAP Service Marketplace

только в двух- или в трехсистемной инфраструктуре (последнее предпочтительнее). Всегда нужно избегать использования одной системы R/3 и для работы, и для разработки. Мы будем предполагать, что системная инфраструктура уже создана и ее конфигурация настроена (см. главу 5), а также считать, что пути переноса между системами определены.

Класс/пакет разработки

Класс разработки объединяет объекты, которые должны разрабатываться, сопровождаться и переноситься вместе. Перед созданием новых объектов необходимо создать в системе интеграции (где будет происходить разработка) класс разработки. Классы разработки являются также объектами и поэтому могут переноситься.

Присваивание классу разработки уровня переноса обеспечивает перенос всех объектов класса по одному пути (см. главу 5). Класс разработки $ТМР играет особую роль: он используется для всех локальных (непереносимых) объектов.

Усовершенствованная концепция пакетов заменяет классы разработки, начиная с Basis Release 6.10.

Рис. 6.13. Запись объектного каталога программы RSPARAM

Область имен клиента

Для создания объектов, включая класс разработки, SAP предоставляет отдельную область имен клиента. Это позволяет избежать конфликтов имен между объектами SAP и пользовательскими объектами. При создании имен классов разработки и объектов Workbench применяются следующие правила:

► Заказчики могут использовать области имен, начинающиеся с «Y» или «Z».

► В больших проектах разработки разрешается применять отдельную область имен. Область имен является префиксом (от пяти до десяти символов), помещенным между символами слэша (/); этот префикс добавляется перед именем объекта заказчика. Лицензионный ключ SAP предотвращает несанкционированный доступ к этим областям имен. Области имен заказчика предназначены для использования в сложных проектах разработки или проектах, реализуемых партнерами компании SAP.

Каталог объектов

Каждому объекту в системе SAP R/3 соответствует запись в каталоге объектов (см. рис. 6.13). Она содержит всю важную информацию о данном объекте. Кроме класса разработки объекта и присвоенного уровня переноса, для системной инфраструктуры важна также информация о системе-источнике объекта.

Оригинал

Объект является оригиналом только в той системе, где он был создан. Данный атрибут связан с различными механизмами защиты. В системной инфраструктуре объекты в системе интеграции являются оригиналами, если стратегии разработки и переноса были созданы правильно. Модификация оригинала объекта называется коррекцией. Копии объектов оригиналов передаются в другие системы для тестирования и затем для рабочего использования. Изменения, вносимые в копии объектов в этих системах, называются исправлениями. Если такие изменения не применяются к оригиналу объекта в системе интеграции, то они могут быть перезаписаны при новом переносе из нее.

Разблокирование и экспорт

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

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

6.2.3. Журналы переноса

Журнал операций

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

Для вывода на экран журналов сначала выделите запрос на перенос из всех запросов на перенос в ►Transport Organizer. Затем выберите Goto • Action Log для вывода всех выполненных до сих пор операций, связанных с запросом переноса. На рис. 6.14 показан журнал для запроса IE4K903522. Файлы журналов находится в подкаталоге log каталога переноса (см. главу 5).

Журналы переносов

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

□ <SID исходной системы><шаг><номер запроса на перенос>.<SID целевой или исходной системы>

<Шаг> обозначает выполненный шаг в соответствии с соглашениями по именам:

► А — активизация репозитория

Рис. 6.14. Журнал операций для запроса IE4K903522

► С — Перенос текста исходного кода С