SAP R/3 Системное администрирование [Сигрид Хагеман] (fb2) читать онлайн

Сигрид Хагеман, Лиане Вилл SAP^® R/3^® Системное администрирование

SAP® R/3® System Administration

Sigrid Hagermann, Liane Will

Copyright © 2003 Galileo Press All rights reserved

ISBN 1-59229-014-0

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

Сигрид Хагеман, Лиане Вилл

Переводчик О. Труфанов

© Издательство "Лори", 2007

Изд. № : OAI (03)

ЛР №: 07612 30.09.97 г.

ISBN 978-5-85582-272-4 (5-85582-272-9)

Предисловие к серии книг

Основная цель компании SAP состоит в том, чтобы решения, принимаемые на основе программного обеспечения SAP, работали успешно и с минимальными затратами. Эта «минимальная стоимость владения» достигается благодаря быстрой и эффективной реализации, а также оптимальной и надежной деятельности. Активная глобальная поддержка SAP обеспечивает необходимую помощь с помощью новой стратегии управления решениями SAP. В ходе всего жизненного цикла работы решения SAP предлагает заказчиками все необходимые службы, первоклассную поддержку, подходящую инфраструктуру и соответствующие знания. Новая стратегия опирается на три мощные программы поддержки: Safeguarding, или другими словами, управление рисками; Solution Management Optimization, которая направлена на оптимизацию информационного решения заказчика, а также Empowering, обеспечивающую целевой, эффективный перенос знаний от SAP заказчику.

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

Являетесь ли вы новичком в управлении системой SAP или хотите повысить свою квалификацию, вы извлечете огромную пользу из практического опыта и информации из первых рук, содержащихся в этих книгах. С помощью этой серии книг SAP надеется также помочь вам подготовиться к экзамену для получения квалификации «Сертифицированного технического консультанта». Однако помните, что эти книги не могут и далее не пытаются заменить личный опыт, полученный при работе с различными решениями SAP. Авторы предлагают рекомендации, чтобы помочь вам в повседневной работе с программным обеспечением. Нововведения в решениях SAP всегда приносят с собой новые проблемы и решения для управления системой. Увеличивается спрос на собственные организации заказчика или внешние организации поддержки. Опыт и знания этих организаций могут оказать существенную помощь, чтобы избежать проблем при использовании программного обеспечения. Поэтому одной из основных задач этой серии книг является обучение навыкам решения проблем. Даже в эру Интернета книги остаются идеальным средством для передачи знаний в компактной форме. Более того, их содержание дополняет новую службу и платформу поддержки SAP Solution Manager и другие новые службы, предлагаемые SAP. Эта серия предоставляет базовые знания по работе и функциям новых решений SAP и вносит свой вклад в удовлетворение потребностей заказчиков.

Герхард Освальд

Член исполнительного совета компании SAP AG

д-р Уве Хоммель

Старший вице-президент SAP AG

SAP Active Global Support

Рот, октябрь 2003 г.

Предисловие

С момента выхода первого издания книги Лиане Вилл по администрированию R/3, которое стало почти классическим, прошло почти ровно три года. Это много для мира информационных технологий. Данная книга повторяет структуру своей предшественницы, однако это не просто переиздание, потому что в нее внесены многочисленные новые разработки и усовершенствования.

Системный администратор SAP R/3, который уже вступил на эволюционный путь администрирования Basis от SAP R/3 4.0 к изменениям EnjoySAP в SAP R/3 4.5, должен заметить, что система SAP R/3 4.6C существенно улучшила многие подходы, например в системе управления переносами и в мониторинге. Тем не менее, конструкция систем Basis 4.6C и 6.x (SAP Web Application Server) несущественно отличаются в отношении классических административных задач, которые составляют содержание этой книги.

Все спецификации, утверждения, пути доступа меню и снимки с экрана в этой книге основываются на SAP R/3 4.6C и SAP Web Application Server 6.20 и 6.30. К сожалению, невозможно гарантировать, что это не изменится в будущих версиях, поэтому рекомендуется учитывать это в своей работе. Эта книга не существовала бы без поддержки Роланда Мэйра, который провел бесконечные часы в поисках ошибок и внес множество ценных советов, основываясь на своем опыте администрирования сложных инфраструктур, а также Карен Хагемен, иллюстрации которой облегчают понимание контекста и базовых понятий. Я хочу поблагодарить также Лиане Вилл и Флориан Цимниак за поддержку в работе и терпение. Кроме того, я хочу упомянуть Гюнтера Лемуэна за перевод, и Нэнси Этсковитц за редактирование книги на английском языке.

Сигрид Хагеманн

SAP System Integration AG

Алсбах-Хэнлайн, октябрь 2003 г.

Введение

SAP занимает ведущее положение на рынке средств управления бизнесом: более чем 60 000 ее установок программного обеспечения работают более чем в 120 странах. Система SAP R/3 стала чем-то вроде стандарта в программном обеспечении бизнеса.

Технология Basis SAP R/3 является частью этого развития. Она используется также в других компонентах палитры предложений SAP и является основой SAP Web Application Server; она формирует технологическое основание новой платформы SAP — SAP NetWeaver.

С целью упрощения эта книга рассматривает систему SAP R/3 с точки зрения системного администратора, даже когда обсуждаемая функция может использоваться в такой же или аналогичной форме в SAP Business Warehouse (SAP BW) или SAP Advanced Planner & Optimizer (SAP APO).

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

Особенности администрирования, связанные с добавлением рабочей среды Java в SAP Web Application Server, лишь упоминаются, но подробно не рассматриваются.

В главе 1 «Техническая реализация архитектуры клиент/сервер в системе SAP R/3», рассматриваются основы архитектуры SAP R/3. Здесь объясняется техническая реализация архитектуры клиент/сервер в SAP R/3 и вводятся важные для понимания термины SAP R/3.

В главе 2 «Первые шаги» представлены общие рабочие процессы, такие как запуск и остановка системы и регистрация. В ней также вводятся первые важные функции в системе SAP R/3.

В главе 3 «Обслуживание и поддержка» рассказывается о возможностях SAP Service Marketplace и SAPNet R/3 Frontend, возможно, более известных как Online Service System (OSS). В этой главе освещается также важная тема: соединение системы заказчика с SAProuter.

В главе 4 «Принципы инсталляции» обсуждаются основы всех решений mySAP — концепции и процедуры инсталляции, которые изменились на стыке между SAP R/3 4.6C и SAP Web Application Server. Хотя теории этих концепций инсталляции похожи, технические реализации разных инсталляций отличаются друг от друга. В этой главе также обсуждается ежедневная работа, которая требуется после инсталляции.

В главах 5 «Создание и настройка системной инфраструктуры» и 6 «Логистика программного обеспечения» описываются архитектура и использование Системы управления переносом (TMS). Задание системной инфраструктуры и центральной администрации настроек переноса являются основными вопросами, рассматриваемыми в главе 5. В главе 6 рассказывается о переносе логистики программного обеспечения; для обработки логистики требуется TMS. В этой главе описывается также Система изменений и переноса (CTS) как приложение, используемое каждой инсталляцией для импорта пакетов поддержки и дополнительных модулей.

В главе 7 «Администрирование клиента» обсуждается основание приложения. С точки зрения администрирования Basis здесь изучается обслуживание клиента, в частности различные возможности для копирования и переноса, а также настройки изменчивости.

В главе 8 «Пользователи и их полномочия в системе SAP R/3» подробно определяются пользователи R/3 и концепция полномочий. Кроме основ, таких как объект полномочий, индивидуальные полномочия и роли, в этой главе объясняются такие концепции, как Центральная администрация пользователей (CUA) и работа со службами каталога.

В главе 9 «Фоновая обработка» рассматривается возможность планирования и выполнения заданий в фоновом режиме, который предлагает SAP R/3 помимо диалоговой обработки.

В главе 10 «Служба обновления» обсуждаются задачи системного администратора SAP R/3 в контексте изменяющихся данных, в частности мониторинг обновлений и процедуры в случае ошибок. Данные обычно изменяют с помощью асинхронного обновления.

В главе 11 «Конфигурация и администрирование вывода» рассматриваются возможности для конфигурации вывода/печати и администрирования запросов вывода/печати.

В главе 12 «Архивирование данных» показано, как использовать и сохранять данные из базы данных SAP R/3, поскольку большие объемы данных устаревают очень быстро и больше не требуются для непосредственного доступа. Растущие объемы данных требуют дополнительных административных усилий.

В главе 13 «Распространение и перенос данных» описывается Удаленный вызов функции (RFC), как важная основа для коммуникации. RFC используется также как технология Basis для реализации распределенных бизнес-процессов с помощью Application Link Enabling (ALE). В этой главе также объясняются основы процедуры пакетного ввода для быстрого переноса данных в систему SAP R/3.

В главе 14 «Обслуживание инстанций» обсуждаются администрирование и обслуживание параметров в SAP R/3 (традиционно термин instance в русскоязычной технической литературе переводится как «экземпляр». В данной книге он переводится как «инстанция» согласно словарю SAP Terminology Database. — Прим. пер.). Здесь показано, как использование определений типов операций помогает администратору подстроить систему R/3 для удовлетворения изменяющихся требований пользователей. В этой главе также описано распределение нагрузки — выравнивание нагрузки между инстанциями с помощью групп регистрации.

В главе 15 «Мониторинг системы» вводятся инструменты, которые системный администратор может использовать для мониторинга системы и анализа ошибок. Здесь приводятся материалы, позволяющие углубить понимание знакомых инструментов. Глава завершается обзором рутинных задач администратора системы SAP R/3.

В главе 16 «Архитектура мониторинга» обсуждаются структура, конфигурация и возможные применения архитектуры мониторинга как важного компонента Системы управления вычислительным центром (CCMS) во всех системах SAP Basis.

Приложения включают ответы на все контрольные вопросы, все важные коды транзакций, список наиболее важных параметров R/3, схемы структур меню, а также глоссарий всех важных терминов в среде SAP R/3.

Типографские соглашения

Перейти к большинству действий или задач можно, следуя по пути доступа меню или вводя код транзакции. Текст указывает на такую возможность, например ►Event maintenance. В каждой главе есть раздел, посвященный путям доступа и кодам транзакций, где объясняются соглашения, используемые в главе:

Event maintenance: SAP Menu • Tools • CCMS • Jobs • Maintain Event (SM62)

Источники дополнительной информации предоставляются в разделах о быстрых ссылках и указаниях SAP Service Marketplace. Эти ссылки в SAP Service Marketplace можно найти в Интернете по адресу http://service.sap.com.

Системные свойства различаются на разных платформах операционных систем. Соответственно UNIX всегда включает все варианты UNIX, для которых был выпущен данный компонент. Windows NT указывает на текущую версию операционной системы Microsoft, используемую для решений SAP. Полный набор всех допустимых комбинаций операционной системы, базы данных и компонентов SAP можно найти в SAP Service Marketplace по быстрой ссылке /platforms.

ГЛАВА 1 ТЕХНИЧЕСКАЯ РЕАЛИЗАЦИЯ АРХИТЕКТУРЫ КЛИЕНТ/СЕРВЕР В СИСТЕМЕ SAP R/3

Базовая технология SAP, давно известная как SAP R/3 Basis, показала себя надежной платформой благодаря своей высокопроизводительной архитектуре. Сервер приложений Web SAP (Web AS - Web Application Server) является поэтому не только базовым компонентом текущей системы SAP R/3 Enterprise, но также технологической основой одинаково структурированных компонентов решений SAP, таких как SAP APO, SAP BW и SAP CRM.

Технология всех решений mySAP основывается на известной многозвенной архитектуре клиент/сервер. Использование такой концепции позволяет разрабатывать надежное и гибкое масштабируемое основание для работы сложных системах.

1.1. Архитектура клиент/сервер в системе SAP R/3

Трехзвенная технология клиент/сервер различает следующие уровни:

► Презентация

► Приложение

► База данных

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

Работа всех трех слоев клиент-серверной архитектуры на одном компьютере подходит только для целей демонстрации или тестирования.

Рис. 1.1. Варианты конфигурации

Двухслойная конфигурация

Небольшие системы SAP R/3 часто используют конфигурацию с отдельным уровнем презентации (см. рис. 1.1). База данных и приложение выполняются вместе на одной машине; ПК или другие компьютеры рабочих станций используются для внешних систем.

Трехслойная конфигурация

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

Одно из наиболее важных решений, которое должно быть принято на ранних этапах реализации SAP R/3, касается применяемой архитектуры и аппаратного обеспечения. Данная архитектура должна наилучшим образом удовлетворять требованиям пользователей. Если на этапе рабочей эксплуатации системы SAP R/3 окажется, что выбранная архитектура не отвечает данным требованиям, то в результате придется нести более высокие расходы и выполнять лишнюю организационную работу.

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

Уровень презентаций

Для пользователей, работающих с бизнес-функциями SAP R/3, основное значение имеет уровень презентаций. В системе R/3 он состоит из графического пользовательского интерфейса SAP (SAP GUI—Graphical User Interface). Интерфейс SAP GUI воспринимает то, что вводит пользователь, и передает эту информацию для дальнейшей обработки на следующий уровень — уровень приложений, где обрабатываются запросы. И наоборот: SAP GUI получает данные от уровня приложений и представляет их пользователю. Большинство сеансов SAP R/3 функционирует через SAP GUI. Технической реализацией SAP GUI является процесс, который осуществляется на уровне операционной системы клиента.

Уровень приложений

Пользовательские запросы передаются с уровня презентаций на уровень приложений SAP R/3. Именно здесь выполняются фактические вычисления, оценки и другие операции. Необходимые для этого сведения запрашиваются с уровня базы данных. Новые входные данные обрабатываются на уровне приложения и передаются в базу данных. Уровень приложений представляет собой центр управления системой SAP R/3, т. е. это один из центральных компонентов, на который может влиять администратор системы SAP R/3. В большинстве случаев применяемые администратором средства полностью интегрированы с системой SAP R/3.

Инстанция

Инстанция SAP R/3 является группой процессов, которые используют общую область памяти, управляются процессом диспетчера и обращаются к одной базе данных. Уровень приложений системы SAP R/3 может состоять из одной или нескольких инстанций. Термин «сервер приложений» используется как синоним термина «инстанция». Системный администратор настраивает число и типы процессов инстанции, чтобы оптимизировать производительность с наименьшим возможным объемом ресурсов.

Уровень базы данных

На уровне базы данных используется система управления реляционной базой данных (РСУБД). Обмен данными между РСУБД и процессами приложений осуществляется через интерфейс SQL. Почти во всех случаях данные в системе SAP R/3 хранятся в одной БД на одном компьютере. Тем не менее, можно реализовать также использование параллельных баз данных или одной базы данных для нескольких систем SAP (см. главу 4).

При работе с системой SAP R/3 администратор должен выполнять обычные задачи администрирования БД, которые включают в себя:

► Резервное копирование БД и восстановление в случае ошибки

► Настройку конфигурации

► Управление потоками данных и их оптимизацию

► Управление дисковой памятью

► Реорганизацию данных (табличных пространств, таблиц и т.д.)

► Установку и сопровождение программного обеспечения

Компания SAP предлагает администраторам БД интегрированные инструментальные средства SAP R/3. Для некоторых систем баз данных существуют специальные инструменты, применяемые на сервере БД.

При размещении уровней БД и приложений на двух и более компьютерах система SAP R/3 называется распределенной.

SID

За исключением систем MCOD (многокомпонентных с одной базой данных) имя базы данных одновременно определяет имя всей системы SAP R/3. Имя должно состоять из трех символов (буквы или букв и чисел); первая буква должна быть заглавной. Сокращение «SID» используется обычно в качестве метки-заполнителя для имени системы SAP R/3: оно обозначает идентификатор системы (system identifier). Иногда используется «SAPSID», что обозначает системный идентификатор SAP.

Сетевая технология

Для взаимодействия уровней, распределенных по нескольким компьютерным системам, используется стандартная сетевая технология. Она же применяется для коммуникаций системы SAP R/3 с внешним миром. Транспортным протоколом служит протокол TCP/IP. На каждом шаге в процессе диалога между клиентской системой (внешним интерфейсом) и уровнем презентаций передается очень мало данных. По этой причине для взаимодействия компьютеров уровня презентаций и серверов приложений можно без всяких проблем использовать соединения глобальной сети. При коммуникации серверов базы данных и приложения все по-другому.

Кроме того, систему R/3 можно связать с мэйнфреймом по протоколу IBM SNA (Systems Network Architecture) LU6.2.

1.2. Соединение с Интернетом

Текущая технология использует три способа соединения компонентов SAP с Интернетом. Сервер транзакций Интернета (ITS — Internet Transaction Server) и Менеджер коммуникаций Интернета (ICM — Internet Communication Manager) обеспечивают диалоговое взаимодействие. Business Connector поддерживает автоматизированный обмен бизнес-данными с помощью HTTP и XML между партнерскими системами.

1.2.1. Сервер транзакций Интернета

Сервер транзакций Интернета (ITS — Internet Transaction Server) выполняет следующие задачи:

► Автоматически преобразует представления экранов SAP, чтобы сделать возможным использование SAP GUI для HTML.

► Обеспечивает представление в Web бизнес-процессов посредством прикладных компонентов Интернета (IAC — Internet Application Components) на основе экрана, которые используют предопределенное представление HTML выбранных транзакций.

► Обеспечивает представление в Web бизнес-процессов посредством IAC на основе файла потока выполнения. Файлы потока выполнения осуществляют управление выполнением; форматирование для Интернета является дополнительной задачей.

Рис 1.2. Взаимодействие с Интернетом посредством ITS

ITS использует для выполнения этих задач следующие компоненты:

► WGate: для поддержки интерфейса сервера HTTP, для пересылки запросов AGate и для перемещения страниц HTTP, переданных AGate.

► Agate: основной компонент, отвечающий за управление сеансом, вывод изображений R/3 в HTML, администрирование соединений SAP R/3 и генерацию документов HTML.

ITS осуществляет коммуникацию с SAP R/3 через интерфейс DIAG или с помощью RFC (см. главу 13).

SAP планирует интегрировать функции ITS в будущий релиз сервера приложений Web SAP (SAP Web AS — Sap Web Application Server).

1.2.2. Менеджер коммуникации Интернета (ICM)

Менеджер коммуникаций Интернета (ICM — Internet Communication Manager) является дополнительным процессом. Он выполняется на уровне операционной системы и обрабатывает запросы HTTP, HTTPS и SMTP в SAP Web AS. Поэтому он создает прямые соединения между системами SAP и внешним миром.

Рис. 1.3. Использование ICM

Начиная с версии 6.10 SAP Basis, менеджер ICM может передавать совместимый с Web контент, созданный с помощью SAP Web Application Builder, прямо во внешний браузер, который его запросил.

1.2.3. Business Connector

С помощью Business Connector (ВС — Бизнес-соединитель) две системы SAP или система SAP и система, отличная от SAP, могут обмениваться сообщениями в формате данных XML, используя стандартный протокол Интернета HTTP. Можно использовать синхронный или асинхронный способ обмена данными.

Далее если бизнес-партнер не использует технологию SAP, соединение с помощью Business Connector все еще возможно в связи с открытым форматом данных.

Рис. 1.4. Соединения с помощью Business Connector

1.3. Уровень презентаций

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

► Простое и эргономичное использование

► Возможности специфических конфигураций для конкретных пользователей

► Простое управление

► Гибкий доступ, не зависящий от местоположения

► Поддержку нескольких языков

► Переносимость между разными аппаратными платформами и операционными системами (с сохранением функциональности и внешнего представления)

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

SAP GUI

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

SAPLOGON

Обычно пользователи, которые хотят иметь доступ к более чем одной системе SAP, не хотят размещать пиктограмму (значок) для каждой системы на своем рабочем столе. Программа SAPLOGON позволяет заранее определить все соединения SAP GUI, которые могут понадобиться пользователю, с помощью легко модифицируемого конфигурационного файла или непосредственной настройки SAPLOGON. Когда требуется запустить определенное соединение SAP GUI, пользователи просто выбирают подходящую системную запись из списка всех заданных соединений. Описание настройки и использования SAPLOGON для распределения нагрузки см. в главе 2.

Рис. 1.5. Варианты внешнего представления

Интерфейс SAP GUI реализован на основе Windows Style Guide, стандартов EG 90/270 и ISO 9241, определяющих эргономику интерфейсов.

SAP предлагает различные версии SAP GUI для поддержки различного оборудования взаимодействия с пользователем (см. рис. 1.5):

► SAP GUI для среды Windows Поддерживаемые платформы включают:

- Windows 98, Windows NT4, Windows 2000 и Windows XP

- Более старые версии Windows через терминальный сервер

► SAP GUI для среды Java Поддерживаемые платформы включают:

- Windows 98, Windows NT4 и Windows XP

- MacOS 9

- MacOS X

- Linux, HP-UX, Solaris, AIX и Tru64

- OS/2

► SAP GUI для среды HTML

Для взаимодействия с пользователем требуется только браузер Web; для преобразования представления в HTML требуется ITS (см. раздел 1.4.1).

Программное обеспечение внешнего представления спроектировано обратно совместимым, поэтому всегда можно использовать текущую версию. Как минимум уровень версии SAP GUI должен соответствовать версии Basic системы SAP.

Рис. 1.6. SAP GUI

Окно SAP GUI включает в себя несколько областей. Имя окна отображается в строке заголовка (см. рис. 1.6).

Строка меню

Строка меню находится под заголовком. Каждая строка содержит пункты System и Help. В меню System находится ряд важных функций, позволяющих, например, создавать или удалять сеанс, работать со списками, выполнять утилиты и получать информацию о состоянии системы. Меню Help предоставляет доступ к документации SAP R/3 и контекстно-зависимому справочнику.

Панель инструментов

Часто используемые функции можно выполнять с помощью стандартных пиктограмм. Пиктограмма справа от этой панели инструментов предоставляет пользователям доступ к функциям для настройки цвета, шрифта и размера шрифта SAP GUI. Наиболее важные пиктограммы показаны в таблице 1.1. Кроме пиктограмм, на экране могут отображаться также контекстно-зависимые кнопки.

Таблица 1.1. Важные пиктограммы SAP R/3 и их смысл

Таблица 1.1. (продолжение)

Список избранного и меню пользователя

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

Весь набор транзакций, которые могут использоваться через пути доступа меню, делается доступным с помощью изменения вывода через Menu • SAP Menu. Часто используемые транзакции можно сохранить и связать с Web-сайтами или документами в списке Favorites (Избранное). Например, на рис. 1.7 показан список Favorites, дополненный ссылкой Интернета на SAP Service Marketplace.

Код транзакции

Панель инструментов включает поле команды. Функции системы SAP R/3 очень сложны, поэтому дерево меню R/3 также имеет непростую и не всегда строго иерархическую структуру. В связи с этим всем информационным потокам в SAP R/3 присваивается краткое описание — код транзакции. Его можно вводить для непосредственного вызова функции R/3 без перемещения в системе меню. Код транзакции можно вводить также с добавлением /n или /о. При вводе /n текущий шаг работы заканчивается, а в текущем окне выполняется действие, назначенное коду транзакции. При вводе /о новое действие выполняется в новом окне сеанса. Данная процедура может показаться устаревшей, однако она имеет своих приверженцев особенно среди опытных пользователей SAP R/3.

Рис. 1.7. Меню пользователя и список избранного

Строка состояния

Нижняя строка в окне SAP GUI — это строка состояния. В ней выводятся важные сведения о системе SAP R/3, в которой зарегистрировался пользователь, а также информация и сообщения об ошибках.

Между верхней областью и нижней строкой окна SAP GUI расположена рабочая область пользователя SAP R/3. Структура и функции этой области зависят от выполняемой пользователем задачи.

Поддержка нескольких языков

Такая поддержка в SAP GUI реализуется за счет хранения всех текстовых элементов отдельно от изображения. Язык можно выбрать при регистрации (входе) в системе SAP R/3 или путем установки параметра в SAP R/3. При этом выбранный язык уже должен быть установлен, т. е. текстовые элементы для данного языка должны быть импортированы в базу данных SAP R/3. По умолчанию в каждой системе доступны английский и немецкий языки. В настоящее время можно установить более 20 различных языков; Basic Release 6.10 поддерживает Unicode.

1.4. Уровень приложений

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

► Служба диалога (D)

► Служба обновлений (Update, V)

► Служба обновлений V2 (Update2, V2)

► Служба управления блокировками (Enqueue, E)

► Служба фоновой обработки (Batch, В)

► Служба сообщений (М)

► Служба шлюза (G)

► Служба подкачки (Spool, S)

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

Имя инстанции содержит имя системы SAP R/3 и буквы, соответствующие службам. Центральная система SAP R/3 только с одной инстанцией, обеспечивающей все службы, будет иметь имя <SID>_DVEBMSG<номер инстанции>_<имя хоста>, где <SID> — это имя системы из трех букв, уникальное в каждой системной инфраструктуре, а <номер инстанции> — это последние две цифры порта TCP/IP, используемого для сетевого соединения. Однако этот метод именования является только соглашением об именовании — соглашением, которое не проверяется технически. При установке сервера диалога инстанция обычно устанавливается с именем <SID>_D<номер инстанции>_<имя хоста>, даже когда она предлагает дополнительные службы. Номер инстанции может находиться между 00 и 96: номера с 97 по 99 включительно зарезервированы для специальных целей.

Сервер сообщений

На уровне приложений для каждой инстанции есть один сервер сообщений. Эта служба предназначена для коммуникации между различными инстанциями системы SAP R/3. Сервер сообщений осуществляет мониторинг свободных ресурсов и их выделение в случае необходимости на уровне приложений. Инстанция, на которой работает сервер приложений, называется обычно центральной инстанцией системы SAP R/3. О задачах центральной инстанции см. ниже в данной главе. Все другие инстанции являются диалоговыми, даже если они предлагают дополнительные службы.

Процесс-планировщик и рабочие процессы

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

Рис. 1.8. Роль планировщика в инстанции SAP R/3

Если рассмотреть структуру рабочего процесса, то можно видеть, что он реализуется путем совместного выполнения обработчика задач, процессора обработки экранов, процессора АВАР и интерфейса SQL, которые используют специальные области основной памяти. Обработчик задач координирует операции в рабочих процессах. В зависимости от выполняемой задачи обработка передается процессору экранов, процессору АВАР (он отвечает за программы на АВАР — языке программирования SAP) или интерфейсу SQL для обмена данными с БД.

Служба диалога

Рабочие процессы различаются по своим задачам. Процессы диалога реализуют запросы активных пользовательских сеансов. Для выполнения необходимых внутренних процедур SAP R/3 каждая инстанция SAP R/3 должна иметь, по крайней мере, два процесса диалога. Планировщик не назначает процесс диалога только одному пользователю (SAP GUI). На самом деле планировщик инстанции назначает выполнение каждого шага диалога свободному процессу диалога. Данные пользователя, необходимые для выполняемой обработки (например, авторизации), сохраняются в контексте пользователя в оперативной памяти (в доступных для рабочих процессов областях). В системе R/3 шаг диалога рассматривается как обработка одного экрана. Процесс диалога обычно занят только во время обработки шага диалога одного пользователя. Этот механизм позволяет процессу диалога обслуживать нескольких пользователей.

Служба фоновой обработки

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

Служба обновления

Служба обновления вносит в БД изменения в асинхронном режиме. Она используется, когда изменения в данных не нужно вносить немедленно (синхронно). Пользователь системы SAP R/3 не влияет на применение службы обновления. Решение об использовании данной службы принимается на этапе разработки бизнес-приложения. Примером является ввод заказов. Каждый заказ должен вводиться быстро в диалоговом режиме (онлайн), однако фактическое обновление осуществляется в фоновом режиме с некоторой задержкой, и пользователю не нужно ждать, когда завершится транзакция. Для обработки асинхронных изменений данных в каждой инстанции системы R/3 должна быть, по крайней мере, одна служба обновления.

Служба обновления V2

По соображениям производительности служба обновления делится на подклассы. Для менее важных частей обновления существует отдельная служба обновления V2, которая может выполнять часть обновлений совместно. Настройка службы обновления V2 не является обязательной. Если этой службы нет, то служба обновлений продолжает решать ее задачи.

Служба вывода

Запросы вывода передаются службе вывода, часто называемой службой спула, которая временно сохраняет их в объектах TemSe (временный последовательный объект), пока они реально не выводятся. Администратор системы SAP R/3 должен решить, где следует хранить объекты TemSe: в БД с использованием механизмов защиты РСУБД или в файловой системе с помощью средств управления ОС.

В системе должен быть доступен, по крайней мере, один процесс спула. Каждая инстанция может иметь любое число таких процессов.

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

Служба блокировок

Управление блокировками занимает среди служб особое место. Аналогично серверу сообщений, эта служба действует в масштабе всей системы, т. е. обеспечивать данную службу для всей системы может только одна инстанция. Обычно для этого достаточно одного процесса. Если система работает с особенно большой нагрузкой, то допускаются несколько процессов службы блокировки, но они должны существовать в одной и той же инстанции, так как информация о блокировке хранится в основной памяти компьютера (память с общим доступом). Соответственно термин «сервер блокировок» (Enqueue Server) используется как синоним инстанции, которая обеспечивает такую службу и для самой службы.

Транзакция SAP R/3

Если это возможно, сервер блокировок (Enqueue Server) и сервер сообщений (Message Server) должны выполняться на одной инстанции, поскольку функционируют они в тесном «сотрудничестве». Сервер блокировок управляет логическими блокировками для транзакций SAP R/3. Такая транзакция состоит из последовательности функционально и логически согласованно связанных рабочих шагов. Обычно транзакция R/3 включает в себя несколько диалоговых шагов, которые могут выполняться различными процессами. С точки зрения БД каждый шаг диалога, составляющий физическую и логическую единицу, представляет собой транзакцию базы данных и закрывается после шага диалога. РСУБД может координировать только эти транзакции БД с помощью своих собственных процедур управления блокировками. С точки зрения системы SAP R/3 этого недостаточно, вся транзакция SAP R/3 должна выполняться или откатываться назад полностью. По данной причине в R/3 были введены логические единицы работы (LUW—Logical Units of Work). SAP R/3 придерживается принципов ACID (атомарность, непротиворечивость, изолированность, надежность) для логических единиц работы, как они определены для транзакций в РСУДБ. К логической единице работы применяются следующие правила:

► Атомарность (Atomic)

LUWs составляют элементарную единицу работы. LUW может выполняться только целиком.

► Непротиворечивость (Consistent)

LUW переводит непротиворечивую БД в новое непротиворечивое состояние, т. е. после выполнение LUW достигается корректное состояние.

► Изолированность (Isolated)

LUW выполняются независимо друг от друга. Они могут работать параллельно. Если несколько LUW пытаются работать с одними и теми же ресурсами, то они могут сделать это только при последовательном выполнении.

► Долговечность (Durable)

Результаты успешно выполненных LUW сохраняются и хранятся постоянно. Например, на результат не влияют возможные системные ошибки.

Для удовлетворения этих требований необходим сервер блокировок. Запросы блокировок, генерируемые в результате транзакций SAP R/3, передаются серверу сообщений, который, в свою очередь, передает их на выполнение серверу блокировок. Для снижения дополнительной нагрузки на сеть лучше размещать сервер сообщений и сервер блокировок на одной инстанции. Сервер блокировок работает с блокировками в специально выделенной области оперативной памяти. Таким образом, отказ сервера блокировок приводит к потере всех блокировок SAP R/3, а следовательно — к автоматическому откату (отмене) всех LUW, на которые они влияют. При таком отказе планировщик немедленно пытается запустить новый рабочий процесс сервера блокировок на этой инстанции.

Служба шлюза

Каждой инстанции SAP R/3 для выполнения задач вне локальной инстанции необходима также служба шлюза (Gateway Service). Она включает в себя:

► Коммуникации между разными системами SAP R/3

► Удаленный вызов функции (RFC — Remote Function Call)

► Интерфейс программирования коммуникаций (CPI-C — Common Programming Interface for Communications)

► Соединения с внешними системами, такими как серверы MAPI, системы электронного обмена данными EDI, внешние факсимильные устройства и службы телекса

Один процесс шлюза существует в каждой инстанции. Он активизируется автоматически при запуске инстанции. Помощь администратора в данном случае не нужна.

Таблица 1.2. Правила для типов и числа процессов SAP R/3 на уровне приложений

Служба	В масштабе системы R/3	Для каждой инстанции R/3
Диалог (Dialog)	>=2	>=2
Обновление (Update)	>=1	>=0
Блокировка (Enqueue)	1	0 или 1
Фоновое выполнение (Batch)	>=1	>=0
Сообщения (Message)	1	0 или 1
Шлюз (Gateway)	>=1	1
Спул (Spool)	>=1	>=0

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

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

1.5. Уровень базы данных

Уровень базы данных в системе SAP R/3 реализуется на центральном компьютере с использованием центральной РСУБД. В данном разделе уровень БД в системе SAP R/3 рассматривается подробнее. Здесь поясняется, как используется РСУБД для целей R/3 и с какими работами по администрированию это связано.

Рис. 1.9. Интерфейс базы данных

Native SQL и Open SQL

На рис. 1.9 показаны интерфейсы между РСУБД и рабочими процессами. Уровни приложений и БД взаимодействуют друг с другом исключительно через SQL. Несмотря на стандарты SQL, каждая поддерживаемая SAP R/3 РСУБД предлагает свой собственный диалект SQL. Для обеспечения максимальной независимости от специфических для каждой версии и производителя расширений и модификаций рабочие процессы SAP R/3 обычно поддерживают только интерфейс Open SQL. АВАР Open SQL соответствует стандарту SQL2 (Entry Level). При необходимости в интегрированном с рабочими процессами интерфейсе язык Open SQL преобразуется в Native SQL — собственный SQL РСУБД. Специальные средства языка SQL, реализованные в РСУБД, можно также использовать в программах АВАР. Средства языка зависят от конкретного производителя, а модули инкапсулируются в приложения SAP R/3. Их использование сводится к уровню «абсолютной необходимости». Между тем, существуют подходящие области для применения подобных средств. Это специальные приложения, такие как мониторы баз данных. Для инкапсуляции операторов Native SQL в программы АВАР используется следующая конструкция:

□ EXEC SQL.

<оператор Native SQL>

ENDEXEC.

Типы таблиц

Данные хранятся в таблицах РСУБД. Все данные приложения однозначно (1:1) отображаются в прозрачных таблицах. Теоретически к ним можно обращаться с помощью других инструментов SQL или инструментальных средств конкретного производителя. С технической точки зрения административные данные системы SAP R/3 также хранятся в таблицах. Хотя это таблицы других типов, для РСУБД они все равно остаются таблицами. Иногда несколько небольших таблиц группируются в SAP R/3 в одну таблицу РСУБД. Для SAP R/3 такая таблица-контейнер называется пулом таблиц. Таблицы в пуле видимы только для системы SAP R/3. Основное преимущество данных пулов состоит в уменьшении общего числа таблиц для РСУБД. Индивидуальные таблицы в табличном пуле идентифицируются по уникальным именам и специальным ключам записей. Поскольку в этих таблицах используются индивидуальные структуры и методы хранения, это осложняет доступ к ним без применения средств SAP R/3. Таблица АТАВ может служить примером типичного пула таблиц. Она содержит несколько управляющих таблиц SAP R/3, которые невелики по размеру, а их содержимое относительно постоянно. Это означает, что возможна буферизация всего пула таблиц.

Кластеры

Аналогичный случай представляют кластеры таблиц и логические таблицы кластера. Таблицы кластера не существуют в РСУБД как независимые таблицы. Несколько таблиц кластера группируются в кластер таблиц, который обычно называют просто кластером. Обычно несколько строк таблицы кластера группируются в запись кластера с общим ключом. В отличие от пула таблиц, где запись присваивается записи в пуле, здесь запись состоит из нескольких записей в таблице кластера. При этом осуществляется конкатенация записей, к которым добавляется ключ кластера. В основном, этот метод применяется для документирования.

Всего на уровне БД системы SAP R/3 версии 4.6B содержится порядка 21 600 таблиц и 25 000 индексов или примерно 23 700 таблиц для SAP R/3. Все программы АВАР, которые реализуют бизнес-функции SAP R/3, также хранятся в базе данных.

База данных и РСУБД играют в работе системы SAP R/3 ключевую роль. Здесь осуществляется управление всеми данными, которые вводит пользователь, включая данные администрирования SAP R/3. Администрирование также имеет очень важно особенно при резервном копировании данных. В широком смысле эти операции являются частью администрирования SAP R/3. В более крупных системах задачи администрирования БД иногда требуют, чтобы их выполнял специальный сотрудник или группа людей. Однако многие специальные особенности РСУБД характеризуют администрирование базы данных. В данной книге рассматриваются только универсально применимые процедуры. Более специальные вопросы требуют обращения к книгам, посвященным администрированию РСУБД.

1.6. Сеть

В архитектуре клиент/сервер сетевые службы используются для взаимодействия отдельных уровней. Коммуникации между компонентами SAP R/3 и другими системами основаны на протоколе TCP/IP.

CPI-C

Система SAP R/3 предусматривает различные службы, обеспечивающие коммуникацию. Для взаимодействия программ АВАР используется специальный интерфейс SAP R/3 под названием CPI-C (Common Programming Interface for Communication). Он выполняет функции стандартизованного и согласованного интерфейса коммуникации. Интерфейс CPI-C соответствует стандарту SAA (System Application Architecture), предложенному компанией IBM в 1987 г. Этот стандарт охватывает:

1. Методы установления коммуникации

2. Управление коммуникацией

3. Обмен информацией

4. Методы завершения коммуникации (закрытия соединения)

За преобразование вызовов CPI-C отвечает шлюз SAP Gateway. Интерфейс CPI-C всегда используется для коммуникации между разными системам SAP R/3 при взаимодействии систем SAP R/3 и SAP R/2, а также при выполнении программ вне системы. Короткие сообщения обрабатывает сервер сообщений (Message Server).

Шлюз SAP

При обмене большими объемами данных используется конкретная специальная служба шлюза SAP (SAP Gateway на базе TCP/IP или LU6.2). Язык CPI-C является в SAP R/3 составной частью языка программирования АВАР (Starter Set), который включает в себя дополнительные функции преобразования данных. Чтобы избавить пользователей от необходимости написания на СРТС собственных подпрограмм коммуникаций, SAP R/3 предлагает интерфейс RFC (Remote Function Call — Вызов удаленной функции). RFC использует отдельный протокол для вызова внутренних и внешних функций, обслуживаемых библиотекой функций SAP R/3. Для выполнения модуля функции на любом компьютере в той же системе SAP R/3 или в других системах R/3 и R/2 можно применять параметр Destination (назначение). RFC поддерживает асинхронную и синхронную коммуникации (см. главу 13).

Недостаток синхронной коммуникации состоит в том, что программа может вызывать другую удаленную программу, только если программа-«партнер» активна. К тому же, если получатель находится в малопроизводительной системе, это может вызвать задержки для отправителя. А если отправитель внезапно «потеряет» получателя, то нередко требуется восстановление обеих систем.

В то же время асинхронная коммуникация позволяет поддерживать высокую согласованность транзакций, для чего к вызову RFC добавляется ключевая фраза IN BACKGROUND TASK. Если выполнение на целевой системе инициируется вручную или целевой компьютер не может исполнить запрос, то данные сначала помещаются в очередь. В этом случае для администрирования используется интерфейс программирования QAPI (Queue-Application Programming Interface).

OLE

Более высоким уровнем по сравнению с RFC является механизм связывания и встраивания объектов (OLE — Object Linking and Embedding). OLE соединяет программы ПК с системой SAP R/3. Команды OLE в программах АВАР передаются в SAP GUI через механизм RFC и соответствующего ПО ПК. Это позволяет обмениваться данными с такими программами, как MS Word или MS Excel.

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

1.7. Операционная система

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

ПО SAP GUI и его компоненты инсталлируются типичным для ПК способом: сначала на клиентской системе (или удаленно) создается каталог, который затем поддерживается и обновляется (вручную или автоматически) для каждой новой версии SAP R/3. На уровне БД интеграция с операционной системой зависит от РСУБД и не является универсальной. Одна из основных задач администратора системы SAP R/3 — координация уровней приложений SAP R/3 (ядра R/3). Именно этим вопросам в данном разделе уделяется основное внимание.

1.7.1. Структура каталога

Структура дерева каталога SAP R/3 состоит из различных ветвей различных инстанций, независимо от того, где находятся отдельные инстанции — в операционных системах Windows NT или UNIX.

Системный идентификатор (<SID>) идентифицирует уникальное имя системы SAP R/3; он обычно включает имя базы данных. Идентификаторы SID всегда состоят из трех букв и/или цифр. Ниже дерево каталога разветвляется на каталоги SYS и каталоги с именами, соответствующими именам инстанций, например DVEBMGS00 (центральная инстанция с номером 00). В Windows NT в корневом каталоге \usi\sap есть два дополнительных общих каталога — sapmnt и saploc. В ОС UNIX такие подкаталоги

Рис. 1.10. Дерево каталогов

определяются только для каталога /sapmnt с помощью ссылок. Каталог SYS включает в себя следующие подкаталоги:

► profile

Профили экземпляра

► global

Данные и журналы, относящиеся ко всей системе SAP R/3

► ехе

Выполняемые программы

Каталог ехе содержит подкаталоги dbg, opt и run. Он содержит выполняемые программы среды времени выполнения системы SAP R/3; каждая из программ выполняется в подкаталоге run. По историческим причинам в системе UNIX каталог run отображается в каталог dbg. В данном каталоге находятся оптимизированные программы SAP R/3 и отлаживаемые программы с расширением dbg.

В более ранних версиях SAP R/3 каталог opt в системах UNIX содержал оптимизированное ядро SAP R/3, а каталог dbg— отлаживаемое ядро SAP R/3. Если возникает проблема, то можно переопределить ссылку с каталога run (куда она указывает обычно) на каталог opt с отлаживаемым и более медленным ядром SAP R/3.

С логической точки зрения узел /usr/sap/<SID> содержит каталог для каждой инстанции в системе SAP R/3; в нем находятся подкаталоги log, data и work. Каталог log содержит системный журнал инстанции SAP R/3. В каталоге work (рабочем) сохраняется информация об ошибках и данные трассировки. В каталоге data находятся файлы компонентов управления памятью для процессов SAP R/3 (Memory Management). Физически эти каталоги находятся на сервере приложений каждой инстанции. Логически они представляются в центральной инстанции с помощью средства NFS Mount. Кроме того, деревья каталогов /usr/sap/<SID>/SYS связываются с деревом каталога центральной инстанции.

1.7.2. Пользователи

На уровне операционной системы для пользователей SAP R/3 необходимы специальные пользователи. В процессе инсталляции SAP R/3 для этих пользователей создается требуемая рабочая среда, состоящая из авторизации, настроек по умолчанию и, в зависимости от РСУБД, пользователей базы данных.

UNIX

Для каждой системы SAP R/3 в операционной системе UNIX должны быть созданы пользователи <sid>adm и <RDBMS><sid>. Здесь <sid> означает идентификатор системы SAP R/3 (в нижнем регистре), a <RDBMS> — трехсимвольную аббревиатуру используемой РСУБД:

► sqd (SAPDB)

► db2 (DB2)

► inf (Informix)

► ora (Oracle)

На уровне операционной системы пользователи обычно различаются по соответствующим рабочим областям и поэтому — по их авторизации. Пользователь операционной системы <sid>adm предназначен для администрирования SAP R/3. Для задач администрирования в РСУБД предусматривается пользователь <RDBMS><sid>, однако в действительности эти обязанности возлагаются на нескольких пользователей.

В системах Windows NT все описанные задачи осуществляются пользователем <sid>adm. Сами процессы R/3 выполняются как службы, и для них определен пользователь SAPService<SID>.

Со стороны БД в системе SAP R/3 есть пользователь SAPR3, которому принадлежат все таблицы БД в системе R/3. Могут существовать и другие пользователи БД, однако они не имеют полномочий на доступ к этим таблицам.

1.8. Советы

► Пути доступа меню

При поиске пути доступа меню к транзакции можно использовать транзакцию search_sap_menu для стандартного меню или search_ user_menu для записей в меню пользователя.

► Транзакция

При поиске транзакции с помощью ключевого слова или групповых символов можно использовать ►Data Browser таблицы TSTCT.

1.9. Транзакции и пути доступа меню

Data Browser: SAP Menu • Tools • АВАР • Workbench • Overview Data Browser (SE16)

1.10. Дополнительная документация

Быстрые ссылки

► SAP Service Marketplace, псевдоним netweaver

► SAP Service Marketplace, псевдоним platforms

► SAP Service Marketplace, псевдоним sapgui

► SAP Service Marketplace, псевдоним sap-its

► SAP Service Marketplace, псевдоним releasestrategy

Указания SAP Service Marketplace

В следующей таблице представлен обзор наиболее важных указаний (Notes) в SAP Service Marketplace, которые имеют отношение к базовым вопросам архитектуры SAP R/3.

Таблица 1.3. Указания для архитектуры клиент/сервер в SAP R/3

Содержание	Указание
ITS Maintenance Strategy	197746
SAP GUI Resources	26417
SAP GUI Maintenance Strategy	147519
SAP GUI Limitations for Java	454939

1.11. Контрольные вопросы

1. Какие службы предлагает прикладной уровень?

a. Служба коммуникаций

b. Служба диалога

c. Служба спула

d. Служба обновления

e. Служба сообщений

f. Служба транспорта

g. Служба шлюза h. Служба сети

i. Служба блокировки

j. Служба фонового выполнения

к. Служба изменения

2. Какое из следующих утверждений правильно?

a. Планировщик и процессы диалога не следует выполнять в одной инстанции.

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

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

3. Для чего предназначен сервис шлюза?

a. Для коммуникаций между процессами SAP R/3.

b. Для коммуникаций между системами SAP R/3 и инстанциями системы SAP R/3.

c. Для коммуникаций со спулом операционной системы.

d. Для соединения с внешними программами, такими как MAPI, EDI и служба телекса.

e. Для коммуникаций с системами SAP R/3.

4. Сколько серверов сообщений активно в системе SAP R/3?

a. 0

b. 1

c. 2

5. Сколько служб обновления может быть активными в каждой инстанции?

a. 1

b. 2

c. Это число автоматически изменяется системой SAP R/3 в зависимости от требований.

d. Любое число, в зависимости от доступных ресурсов. Это число может заранее определяться администратором.

ГЛАВА 2 ПЕРВЫЕ ШАГИ

2.1. Запуск БД и инстанций SAP R/3

Запуск системы SAP R/3 осуществляется в несколько шагов. В UNIX или Windows NT запуск системы SAP R/3 является задачей пользователя операционной системы <sid>adm. Выполнение процедуры запуска предусматривает следующие этапы. Сначала для сбора статистической информации по загрузке компьютера и его операционной системы запускают специальную программу saposcol (SAP operating system collector), если она еще не активна. Для каждого сервера SAP запускается только одна программа saposcol, даже если несколько систем или инстанций SAP R/3 выполняются на одном компьютере. Затем начинаются основные операции процедуры запуска системы SAP R/3. Самый главный элемент системы SAP R/3 — это база данных, и, для того чтобы можно было выполнять какие-то задачи, ее нужно активизировать. После этого необходимо сделать то же самое с центральной инстанцией системы R/3. Другие инстанции могут запускаться только при активном сервере сообщений и сервере блокировок. На этом процедура запуска системы R/3 завершается. Для работы пользователей с SAP R/3 необходим также запуск клиентских систем. Они могут запускаться в любое время и независимо друг от друга. По этой причине запуск клиентских систем не считается частью процедуры запуска SAP R/3. За исключением запуска клиентов все остальные этапы запуска системы SAP R/3 обычно выполняются автоматически и совместно.

Windows NT

В Windows NT управление всеми доступными системами R/3 реализовано как встраиваемый модуль Управляющей консоли Microsoft (MMC — Microsoft Management Console). MMC использует древовидную структуру. Встраиваемый модуль SAP R/3 состоит из корневого узла SAP R/3 System; различные системы SAP R/3 и их инстанции выводятся ниже корня как подузлы. Также выводится информация о процессах, текущем статусе и открытых сигналах. Когда используется экспертный режим, вывод включает также дополнительные и более подробные данные. Отметив систему R/3 или экземпляр и выбирая Start, можно фактически запустить компоненты.

В более старых версиях SAP R/3 для запуска системы под Windows использовалась программа SAP Service Manager. Хотя сегодня рекомендуется использовать ММС, можно все еще использовать SAP Service Manager. При выборе в диалоговом окне Service Manager опции Start он сначала проверяет, активна РСУБД в R/3 или еще нет. Если БД SAP R/3 еще не активна, то она будет автоматически запущена. Далее запускаются процессы SAP R/3 центральной инстанции. Светофор показывает состояние двух самых важных процессов — сервера сообщений и планировщика. Планировщик управляет работой всех других рабочих процессов. Когда он будет активизирован, нужно подождать запуска планировщиком остальных процессов. Только после этого система SAP R/3 будет готова к работе. Светофор в SAP R/3 Service Manager использует цветовой код для указания статуса каждого процесса:

Серый	Процесс не работает
Желтый	Процесс запускается
Зеленый	Процесс активен
Красный	Процесс завершен после ошибки

UNIX

В системах UNIX для запуска SAP R/3 используется командный файл оболочки. Администратор SAP R/3, <sid>adm, может применять командный файл (программу командного процессора) startsap. Файл startsap включает в себя ссылку на фактический командный файл startsap_<имя_хоста><номер_инстанции> для запуска системы в домашнем каталоге этого пользователя.

В остальном же процедура запуска R/3 в UNIX практически идентична используемой в Windows. Вызов startsap [all] запускает следующую программу и системы (если они еще не работают) в следующем порядке:

1. Сборщик статистики saposcol

2. РСУБД с базой данных SAP R/3

3. Система SAP R/3

Кроме того, startsap предлагает следующие варианты:

► startsap db

Командный файл выполняется только до шага запуска БД.

► startsap r3

Предполагается, что БД уже активна.

Дополнительные инстанции

В распределенной инсталляции SAP R/3 можно запустить дополнительные инстанции. Для этого используются те же средства, что и для запуска центральной инстанции. Однако при использовании нескольких инстанций сервер сообщений и РСУБД не запускаются. Инструменты настраивают соответствующим образом.

Если на сервере БД нет активной инстанции R/3, то можно активизировать БД с помощью средств РСУБД или командой startsap db.

Использование журналов

Процедура запуска создает также журналы (в текстовом формате) на уровне файловой системы в домашнем каталоге пользователя <sid>adm. Если во время запуска возникают проблемы, то эти журналы могут предоставить ценную информацию (например, коды ошибок или описание проблемы). Журналы приходится анализировать вручную; однако в среде Windows можно также работать из ММС для просмотра журналов с помощью контекстного меню инстанции. Во время процедуры запуска создаются следующие журналы:

► startdb.log

► startsap_<имя_компьютера>_<имя_инстанции>.log

Журнал startdb.log содержит всю требуемую информацию о запуске каждой системы базы данных. Журнал startsap_< имя_компьютера >_< имя_экземпляра>.log регистрирует процедуру запуска системы SAP R/3. Следующий журнал запуска системы «SKP» на компьютере UNIX «prdsapr3» хорошо показывает отдельные фазы запуска инстанции SAP R/3.

Листинг 2.1. Журнал запуска R/3 startsap_prdsapr3_00.log

Trace of system startup/check of R/3 System SKP on Sun Oct 6 15:02:25 UTC 2002

Called command: /usr/sap/SKP/skpadm/startsap_prdsapr3_00r3

Starting SAP-Collector Daemon

------------------------------------------------

saposcol already running

Checking SAP R/3 SKP Database

------------------------------------------------

Database is running

Starting SAP R/3 Instance

------------------------------------------------

SAP-R/3-Startup Program V1.7 (92/10/21)

------------------------------------------------

Starting at 2002/10/06 15:02:29

Startup Profile: Startup Profile: "/usr/sap/SKP/SYS/profile/START_DVEBMGS00_prdsapr3"

Execute Pre-Startup Commands

------------------------------------------------

(24389) Local: /usr/sap/SKP/SYS/exe/run/sapmscsa -n

pf=/usr/sap/SKP/SYS/profile/SKP_DVEBMGS00_prdsapr3

/usr/sap/SKP/SYS/exe/run/sapmscsa: make new mode. SCSA

currently non existent.

sapcscsa: SCSA defined. sapscsald == 1283 == 00000503

sapcscsa: SCSA attached at address ffffffff7ee00000

sapcscsa: SCSA initialized.

rslgwrl(21): Searching for overlap point in pre-existing

SysLog file...

/usr/sap/SKP/SYS/exe/run/sapmscsa: finished.

(24389) Local: rm -f ms.sapSKP_DVEBMGS00

(24389) Local: ln -s -f /usr/sap/SKP/SYS/exe/run/msg_server ms.sapSKP_DVEBMGS00

(24389) Local: rm -f dw. sapSKP_DVEBMGS00

(24389) Local: ln -s -f /usr/sap/SKP/SYS/exe/run/disp+work dw.sapSKP_DVEBMGS00

(24389) Local: rm -f co.sapSKP_DVEBMGS00

(24389) Local: ln -s -f /usr/sap/SKP/SYS/exe/run/rslgco11 co.sapSKP_DVEBMGS00

(24389) Local: rm -f se.sapSKP_DVEBMGS00

(24389) Local: ln -s -f /usr/sap/SKP/SYS/exe/run/rslgsend se.sapSKP_DVEBMGS00

Starting Programs

------------------------------------------------

(24410) Starting: local.ms.sapSKP_DVEBMGS00 pf=/usr/sap/SKP/SYS/profile/SKP_DVEBMGS00_prdsapr3

(24411) Starting: local dw.sapSKP_DVEBMGS00 pf=/usr/sap/SKP/SYS/profile/SKP_DVEBMGS00_prdsapr3

(24412) Starting: local co.sapSKP_DVEBMGS00 -F pf=/usr/sap/SKP/SYS/profile/SKP_DVEBMGS00_prdsapr3

(24413) Starting: local se.sapSKP_DVEBMGS00 -F pf=/usr/sap/SKP/SYS/profile/SKP_DVEBMGS00_prdsapr3

(24389) Waiting for Child Processes to terminate.

Instance on host prdsapr3 started

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

Управление конфигурацией инстанции SAP R/3, например типом и числом процессов, размером оперативной памяти и различными параметрами, осуществляется с помощью профилей. Этот способ применяется в большинстве программных продуктов. В системе SAP R/3 есть три типа профилей:

► Системный профиль: DEFAULT.PFL

► Стартовый профиль: START_<инстанция><номер инстанции>_ <имя компьютера>

► Профиль инстанции: <SID>_<инстанция><номер инстанции>_ <имя компьютера>

Все профили сохраняются в каталоге профилей (см. главу 1), который определяется во время установки SAP R/3. Этот каталог доступен по чтению для всех инстанций системы SAP R/3 (как общий каталог Windows или монтируемый каталог UNIX).

DEFAULT.PFL

В системе SAP R/3 существует только одна копия профиля DEFAULT.PFL. Она содержит устанавливаемые параметры, применяемые ко всей системе. Эти параметры включают в себя, в частности, имя системы, компьютер БД и имя сервера блокировок. Данный профиль считывается каждой инстанцией системы SAP R/3 при запуске.

Запуск профилей инстанций

Другие профили (START_<инстанция><номер_инстанции>_<имя компьютера> и <SID>_<инстанция><номер_инстанции>_<имя компьютера>) — это специфические профили инстанции. Используемые по умолчанию имена присваиваются во время установки инстанции; имена создаются на основе выполняющихся на инстанции процессов. Например, имя центральной инстанции (см. главу 1) «DVEBMGS» указывает на то, что запущены следующие процессы:

► Диалог (D — Dialog)

► Обновление (U — Update)

► Блокирование (E — Enqueue)

► Фоновая обработка (В — Batch)

► Сообщения (M — Message)

► Шлюз (G — Gateway)

► Спулинг (S — Spool)

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

Рассмотрим профиль START_DVEBMGS00_prdsapr3. Первый сегмент этого выражения, START, сообщает о том, что мы имеем дело со стартовым профилем инстанции. Подчеркивание отделяет тип профиля от его имени. «DVEMGS» представляет сервисы инстанции и его имя. Эта инстанция является центральной, поскольку включает в себя сервис сообщений. Цифры «00» представляют последние две цифры номера порта TCP/IP, который использует на этом компьютере планировщик. Следующее далее подчеркивание отделяет имя инстанции от имени компьютера «prdsapr3», на котором эта инстанция выполняется. Стартовый профиль инстанции определяет, как, где и под какими именами запускаются отдельные сервисы или процессы системы SAP R/3. Например, приведенный ниже фрагмент профиля запускает в инстанции «DVEBMGS00_ prdsapr3» сервер сообщений и диспетчер.

Листинг 2.2. Фрагмент стартового профиля инстанции

Directory /usr/sap/SKP/SYS/profile

Name: START_DVEBMGS00_prdsapr3

#.*************************************************************

#.* Start profile START_DVEBMGS00_PRDSAPR3

#.* Version = 000003

#.* Generated by user = HAGEMANN

#.* Date of generation = 10/23/2002.

#.* 15:04:19

#.***********************************************************

SAPSYSTEMNAME = SKP

INSTANCE_NAME = DVEBMGS00

#

# Start SCSA administration

#

Execute_00 = local $(DIR_EXECUTABLE)/sapscsa -n pf=$(DIR_PR0FILE)/SKP_DVEBMGS00_prdsapr3

#

# start message server

#

_MS = ms.sapSKP_DVEBMGS00

Execute_01 = local rm -f $(_MS)

Execute_02 = local ln -s -f $(DIR_EXECUTABLE)/msg_server $(_MS)

Start_Program_01 = local $(_MS) pf=$(DIR_PR0FILE)/SKP_DVEBMGS00_prdsapr3

#

# start application server

#

_DW = dw.sapSKP_DVEBMGS00

Execute_03 = local rm -f $(_DW)

Execute_04 = local ln -s -f $(DIR_EXECUTABLE)disp+work $(_DW)

Start_Program_02 = local $(_DW) pf=$(DIR_PR0FILE)/SKP_DVEBMGS00_prdsapr3

Операции, указанные с помощью Execute_<номер> являются подготовкой к выполнению реальных команд, которые начинаются с Start_Program_ <номер>. Ключевое слово local (или альтернативно, спецификация имени сервера в том же месте) определяет компьютер, на котором должна выполняться команда.

Профиль инстанции

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

□ <SID>_<инстанция><номер_инстанции>_<имя компьютера>

В данном примере используется профиль SKP_DVEBMGS00_prdsapr3. Он определят, сколько будет запущено рабочих процессов конкретного типа. В приведенном ниже фрагменте можно видеть семь процессов диалога (параметр rdisp/wp_no_dia = 7). Важной частью данного профиля инстанции является определение размера областей основной памяти системы SAP R/3. Профиль содержит также параметры входа в систему (logon) и размеры журнала.

Листинг 2.3. Фрагмент профиля инстанции

#.* Instance profile SKP_DVEBMGS00_PRDSAPR3

#.* Version = 000003

#.* Generated by user = HAGEMANN

#.* Date of generation = 10/23/2002.

#.* 15:04:18

#.********************************************************************

# Instance Profile (CI, 1156 MB RAM)

# Fri Jul 5 11:51:17 2002

SAPSYSTEMNAME = SKP

INSTANCEJAME = DVEBMGS00

SAPSYSTEM = 00

rdisp/wp_no_dia=7

rdisp/wp_no_vb=2

rdisp/wp_no_vb2=1

rdisp/wp_no_enq=1

rdisp/wp_no_btc=3

rdisp/wp_no_spo=1

em/initial_size_MB=800

rdisp/PG_SHM=0

rdisp/ROLL_SHM=0

rdisp/ROLL_MAXFS=64000

rdisp/PG_MAXFS=65024

abap/buffersize=320000

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

Оценка профилей

Исходный код ядра SAP уже задает стандартные (используемые по умолчанию) значения для большинства системных параметров. Тем не менее необходимо определить в профилях специальные свойства системной среды, которая будет использоваться, такие как имя компьютера, имя системы, и распределение ресурсов. Сами профили считываются во время запуска инстанции. Чтобы какие-либо изменения в профиле инстанции вступили в силу, необходимо перезапустить соответствующую инстанцию.

Значения, определенные в системном профиле DEFAULT.PFL, переопределяют стандартные настройки исходного кода. Значения, представленные в профиле инстанции, переопределяют значения параметров DEFAULT.PLF для инстанции (см. рис. 2.1).

Рис. 2.1. Иерархия оценки определения параметра

2.2. Остановка БД и инстанций SAP R/3

Остановка системы SAP R/3 происходит в порядке, обратном для запуска: сначала останавливают диалоговые инстанции, затем центральную инстанцию SAP R/3 и, наконец, базу данных. В системе Windows используется подключаемый модуль R/3 Manager для ММС или пункт меню SAP Service Manager соответствующей функции (Stop вместо Start). База данных должна быть остановлена явно; используемая РСУБД определяет, какую процедуру необходимо для этого использовать.

stopsap

В UNIX необходимо использовать командный файл оболочки под названием stopsap. Его можно использовать следующим образом:

► stopsap [all]

Чтобы остановить инстанции SAP R/3 и базу данных.

► stopsap r3

Чтобы остановить инстанции системы SAP R/3.

► stopsap db

Чтобы остановить базу данных, когда система SAP R/3 уже выключена.

Процедура остановки записывается в журнал точно так же, как процедура запуска. Для этого используются следующие файлы журналов stopdb.log и stopsap_<имя_компьютера>_<имя_инстанции>.log. Они находятся в домашнем каталоге пользователя <sid>adm.

На этом этапе мы будем предполагать, что центральная инстанция системы SAP R/3 активна.

2.3. Запуск клиента

При инсталляции ПО для уровня презентаций запрашиваются данные в возможной целевой системе SAP R/3, и создаются пиктограммы для доступа к ним. Вызов SAP GUI «скрыт» в пиктограммах в следующей структуре вызова:

□ sapgui /Н/<имя компьютера>/S/sapdp<номер_инстанции>

Чтобы клиент мог установить соединение с инстанцией SAP R/3, ему должны быть переданы имя компьютера и номер инстанции. Для каждого вызова SAP GUI на рабочем столе клиентской машины можно создать пиктограмму. Однако в этом случае может оказаться, что работать с большим числом пиктограмм очень сложно, и эффективнее использовать программу SAPLOGON, которая позволяет создавать всевозможные соединения и выбирать их имена. Данные для SAPLOGON создаются только один раз и сохраняются в следующих файлах:

► saplogon.ini

► sapmsg.ini

► saproute.ini

Эти файлы конфигурации можно передать на другие клиентские машины, что значительно сокращает объем работы по сравнению с вводом данных вручную. Если заранее присвоить имена всем возможным соединениям, то не нужно будет создавать пиктограмму для каждого нового соединения. Легко обнаружить удобство такого «упреждающего» именования и при распределении нагрузки по всем инстанциям системы R/3. Если посмотреть на распределение нагрузки, то обнаружится, что подобный способ именования и сохранения информации в файле упрощает обслуживание, поскольку позволяет быстро идентифицировать все соединения. По этой причине имена серверов сообщений доступной системы R/3 сохраняются в файле sapmsg. ini:

□ <SID>=<имя_компьютера_с_сервером_сообщений>

Порт TCP/IP для коммуникации между клиентской системой и сервером сообщений сохраняется в файле служб (UNIX: /etc/services, Windows: %SYSTEMROOT%\system32\drivers\etc\services). Сервер сообщений содержит в системе SAP R/3 информацию о всех инстанциях. Администратор может создавать подгруппы инстанций для конкретных областей, например для управления складом или для финансового учета. Затем пользователи могут выбирать в SAPLOGON группы инстанций в соответствии со своими требованиями. На основе доступной статистической информации сервер сообщений выбирает в такой группе инстанцию с наименьшей нагрузкой. SAP GUI запускается на этой инстанции. Подробнее о процедурах определения групп регистрации см. в главе 14.

На рис. 2.2 показано добавление записей SAPLOGON для примера производственной системы «SKP» на компьютере (сервере приложений) «prdsapr3» с номером системы «00». Можно также вызвать SAP GUI на SKP непосредственно следующим образом:

□ sapgui /H/prdsapr3/S/sapdp00

Рис. 2.2. Создание новой группы в SAPLOGON

2.4. Общие задачи администрирования

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

2.4.1. Проверка состояния

В любой точке системы SAP R/3 можно получать на экране наиболее важную информацию о состоянии системы. Для этого достаточно выбрать команду System • Status. Кроме такой информации по системе SAP R/3, как номер версии, номер инсталляции и действительность лицензии, можно видеть имя сервера БД и используемой РСУБД, имя текущего пользователя и код транзакции, а также узнать о том, какая программа выполняет текущую активную транзакцию (см. рис. 2.3).

2.4.2. Мониторинг системы

Мониторинг системы — одна из наиболее важных задач, выполняемых системным администратором. Для этой цели можно использовать несколько мониторов. Начнем с краткого обзора всех инстанций и процессов, выполняющихся на уровне приложений. Выберите Server list, чтобы вывести список всех выполняющихся инстанций и их служб (см. рис. 2.4).

После выбора инстанции можно перейти к ряду обзоров, включая следующие:

► Goto • Processes

Обзор процессов (см. рис. 2.5)

► Goto • User

Зарегистрированный в данный момент пользователь

Рис 2.3. Состояние системы

Рис. 2.4. Список всех инстанций и их служб

► Goto • Release Information

Описание данных ядра SAP R/3 (версия, номер исправления программы, дата генерации, библиотека базы данных и поддерживаемая среда)

► Goto • Environment

Рабочая среда пользователя <sid>adm на уровне операционной системы

► Goto• Systemlog

Системный журнал (см. раздел 2.4.3)

Можно также использовать Goto • Remote Logon для удаленной регистрации на выбранной инстанции.

Обзор процессов (Process Overview) на рис. 2.5 показывает, что выбранная инстанция выполняет в данный момент 11 диалоговых процессов (DIA), 3 процесса обновления (UDP и UDP2), 1 процесс блокирования (ENQ), 3 фоновых процесса (BGD)h 1 процесс спулинга (SPO).

Рис. 2.5. Обзор процессов инстанции

В этом примере инстанция занята копированием клиента. Администратор может использовать просмотр процессов для оценки текущей активности в системе и балансирования нагрузки инстанции. Процесс просмотра является ключевой частью мониторинга системы. Системному администратору доступна самая разнообразная информация для вывода на экран (см. главу 15). Рабочий процесс можно отменить (если это необходимо), выбрав команду Process • Cancel with Core или without Core. Отмена рабочего процесса (принудительное прекращение его работы) не окажет серьезного влияния на функционирование инстанции. При отмене рабочего процесса выполняется откат открытых транзакций, а планировщик инстанции (Dispatcher) распознает принудительное завершение процесса и пытается немедленно запустить новый рабочий процесс того же типа. Процесс просмотра не показывает процессы самого планировщика или сервера сообщений. Просмотр пользователей (►User overview) предоставляет аналогичные функции, но на экран выводится информация по пользователям.

На уровне операционной системы администратор может применять средство, доступное пользователю ОС <sid>adm. Команда

□ dpmon pf = <профиль_инстанции>

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

Листинг 2.4. Вывод dpmon

Dispatcher Queue Statistics

===========================

+------+------+--------+-------+--------+---------+

| Тур  | now  | high   | max   | writes |   reads |

+------+------+--------+-------+--------+---------+

| NOWP | 0    | 18     | 2000  | 2349360| 2349360 |

+------+------+--------+-------+--------+---------+

| DIA  | 0    | 49     | 2000  | 1428784| 1428784 |

+------+------+--------+-------+--------+---------+

| UPD  | 0    | 2      | 2000  | 7587   | 7587    |

+------+------+--------+-------+--------+---------+

| ENQ  | 0    | 0      | 2000  | 0      | 0       |

+------+------+--------+-------+--------+---------+

| BTC  | 0    | 3      | 2000  | 15464  | 15464   |

+------+------+--------+-------+--------+---------+

| SPO  | 0    | 1      | 2000  | 25638  | 25638   |

+------+------+--------+-------+--------+---------+

| UP2  | 0    | 1      | 2000  | 612    | 612     |

+------+------+--------+-------+--------+---------+

max_rq_id 9351

wake_evt_udp_now 0

wake events total13102978, udp2954229

(95%), shm148749 ( 4%)

since last update total 0, udp 0 ( 0%)

shm 0 ( 0%)

q - quit

m - menu

Пользователи могут использовать m для выбора из следующих доступных мониторов

□ Dispatcher Monitor Menu

=========================

d – dispatcher queue statistics

p - work-process—admin-table

l – work-process—admin-table (long)

t – trace level / components for wp

w – wp_ca blocks

a – appc_ca blocks

m – mbuf status

v – tm_ad dump

q - quit

Пункт 1 по существу эквивалентен просмотру процессов в системе SAP R/3. Приведенный ниже листинг получен в системе UNIX. Когда он был получен, были активны процессы диалога 0,1 и 2 и четыре фоновых рабочих процесса. Процессы можно завершать в dpmon, так же, как в обзоре процессов системы SAP R/3.

Листинг 2.5. Список процессов

Work Process Table (long)

=========================

No Ту Pid Status Cause Start Err Sem CPU Time

Program C1 User Action Table

------------------------------------------------------------------

0  DIA 28577 Run  yes 0 0 37

SAPLEDI1 001 SCHAAK Insert EDI40

1  DIA 28578 Wait yes 0 0 0

2  DIA 28579 Run  yes 0 0 9

 001 SCHAAK Sequential Read DD01L

3  DIA 28580 Run  yes 0 0 33

SAPLEDIN 001 SCHAAK

4  DIA 28581 Run  yes 0 0 8

 001 SCHAAK

5  DIA 28582 Wait yes 0 0 0

6  DIA 28583 Wait yes 0 0 0

7  DIA 28584 Wait yes 0 0 0

…………………….

20 DIA 28597 Wait yes 0 0 0

21 UPD 28598 Wait yes 0 0 0

22 UPD 28599 Wait yes 0 0 0

23 UPD 28600 Wait yes 0 0 0

24 ENQ 28601 Wait yes 0 0 0

25 BTC 7176  Run  yes 0 0 158

/SAPAR0/ 001 SCHAAK DB-PROC "S

26 BTC 6590  Run  yes 0 0 439

/SAPAR0/ 001 SCHAAK Direct Read /SAPARO/MA

27 BTC 10238 Run  yes 0 0 7

 001 SCHAAK Delete RSDELPART

28 BTC 6823  Run  yes 0 0 17

 001 SCHAAK DB-PROC "S

29 SPO 28606 Wait yes 0 0 0

30 SPO 28607 Wait yes 0 0 0

31 BTC 28608 Wait yes 0 0 0

32 UP2 28609 Wait yes 0 0 0

s - stop work process

к - kill work process (with core)

r - enable restart flag (only possible in wp-status ended")

q - quit

m - menu

Для получения информации о процессах SAPR/3 можно использовать и другие средства операционной системы. В Windows основным средством будет диспетчер задач (Task manager) вместе со средствами мониторинга из ММС. Между тем, информация, получаемая с помощью данных средств, будет не столь полной, как сведения, предоставляемые самой системой SAP R/3.

Показанный ниже фрагмент (см. листинг 2.6) был создан с помощью команды ps -ef в среде UNIX, которая содержит распределенную инстанцию, выполняющую РСУБД Oracle. Чтобы сделать информацию более понятной, этот вывод был вручную отсортирован. В нем оставлены только процессы SAP R/3 и процессы Oracle. Первый процесс в списке — программа saposcol. Следующий процесс, sapstart, активизируется, когда начинается выполнение командного файла startup. Он запускает отдельные процессы SAP R/3 на центральной инстанции («01») и диалоговой инстанции ("64") . Процесс co.sap<SID>_<инстанция> собирает информацию для центрального системного журнала системы SAP R/3 и записывает ее в этот журнал. Он работает совместно с процессом se.sap<SID>_ <инстанция>, передающим информацию в системный журнал. Эти процессы активизируются непосредственно командным файлом запуска, в которомиспользуются номера процессов (столбец PID) программы sapstart и номера родительских процессов (столбец PID). Сервер сообщений обозначается идентификатором ms. Все рабочие процессы инстанции обозначены как dw, что означает disp+work. Планировщика среди рабочих процессов можно опознать по соглашению о номере порождающего процесса и номере процесса из командного файла запуска: только планировщик запускается непосредственно из командного файла запуска. Все другие рабочие процессы запускает планировщик, поэтому номера порождающих процессов логически согласуются с номером процесса планировщика.

Листинг 2.6. Обзор процессов с помощью средств операционной системы

UID PID PPID COMMAND

root 29710 1 saposcol

orahuy 13047 1 /oracle/HUY/817_64/bin/tnslsnr

huyadm 19080 1 /usr/sap/HUY/SYS/exe/run/sapstart

pf=/usr/sap/HUY/SYS/profile/START_DVEBMGS00_us7400

huyadm 24273 1 /usr/sap/HUY/SYS/exe/run/sapstart

pf=/usr/sap/HUY/SYS/profile/START_D64us7400

huyadm 19113 19080 co.sapHUY_DVEBMGS01

pf=/usr/sap/HUY/SYS/profile/HUY_DVEBMGS01_us7400

huyadm 19114 19080 se.sapHUY_DVEBMGS01

pf=/usr/sap/HUY/SYS/profile/HUY_DVEBMGS01_us7400

huyadm 19111 19080 ms.sapHUY_DVEBMGS01

pf=/usr/sap/HUY/SYS/profile/HUY_DVEBMGS01_us7400

huyadm 19112 19080 dw.sapHUY_DVEBMGS01

pf=/usr/sap/HUY/SYS/profile/HUY_DVEBMGS01_us7400

huyadm 5063 19112 dw.sapHUY_DVEBMGS01

pf=/usr/sap/HUY/SYS/profile/HUY_DVEBMGS01_us7400

huyadm 19117 19112 dw.sapHUY_DVEBMGS01

pf=/usr/sap/HUY/SYS/profile/HUY_DVEBMGS01_us7400

huyadm 19120 19112 dw.sapHUY_DVEBMGS01

pf=/usr/sap/HUY/SYS/profile/HUY_DVEBMGS01_us7400

huyadm 19121 19112 dw.sapHUY_DVEBMGS01

pf=/usr/sap/HUY/SYS/profile/HUY_DVEBMGS01_us7400

huyadm 19128 19112 dw.sapHUY_DVEBMGS01

pf=/usr/sap/HUY/SYS/profile/HUY_DVEBMGS01_us7400

huyadm 19131 19112 dw.sapHUY_DVEBMGS01

pf=/usr/sap/HUY/SYS/profile/HUY_DVEBMGS01_us7400

huvadm 19191 19112 dw.sapHUY_DVEBMGS01

pf=/usr/sap/HUY/SYS/profile/HUY_DVEBMGS01_us7400

………………………

huvadm 24290 24273 dw.sapHUY_D64

pf=/usr/sap/HUY/SYS/profile/HUY_D64_us7400

huvadm 24292 24290 dw.sapHUY_D64

pf=/usr/sap/HUY/SYS/profile/HUY_D64_us7400

huvadm 24293 24290 dw.sapHUY_D64

pf=/usr/sap/HUY/SYS/profile/HUY_D64_us7400

huvadm 24294 24290 dw.sapHUY_D64

pf=/usr/sap/HUY/SYS/profile/HUY_D64_us7400

huvadm 24295 24290 dw.sapHUY_D64

pf=/usr/sap/HUY/SYS/profile/HUY_D64_us7400

huvadm 24296 24290 dw.sapHUY_D64

pf=/usr/sap/HUY/SYS/profile/HUY_D64_us7400

huvadm 19115 19112 gwrd

pf=/usr/sap/HUY/SYS/profile/HUY_DVEBMGS01_us7400

huyadm 24291 24290 gwrd

pf=/usr/sap/HUY/SYS/profile/HUY_D64_us7400

orahuy 5067 1 oracleHUY

orahuy 7305 1 oracleHUY

orahuy 7307 1 oracleHUY

………………………….

orahuy 7237 1 ora_arc0_HUY

orahuy 7231 1 ora_ckpt_HUY

orahuy 7227 1 ora_dbw0_HUY

orahuy 7229 1 ora_lgwr_HUY

orahuy 7225 1 ora_pmon_HUY

orahuy 7235 1 ora_reco_HUY

orahuy 7233 1 ora_smon_HUY

Процессы шлюза (Gateway) обозначаются идентификатором gwrd. Эти процессы также запускается планировщиком. Идентификаторы процессов, представляемые на уровне операционной системы, назначаются самой ОС при запуске процесса инстанции (см. листинг 2.2). Более подробные сведения, такие как текущая задача процесса, в SAPR/3 получить нельзя. Это можно сделать только с помощью специальных средств SAP R/3.

2.4.3. Проверка системного журнала

Все важные события, происходящие во время работы, записываются в системном журнале системы SAP R/3 или инстанции. Анализ системного журнала - одна из задач администратора. Выберите ►System log в системе SAP R/3 для получения информации о сообщениях, которые имеются в системном журнале. Если в системе SAP R/3 происходит ошибка, то системный журнал является исходной точкой для выяснения причин ошибки (подробнее об этом журнале см. в главе 15).

2.4.4. Системные сообщения

Системному администратору полезно иметь возможность отправлять сообщения всем или отдельным пользователям SAP R/3. Например, такая ситуация возникает, если предстоящие работы по обслуживанию системы помешают ее обычному функционированию. Для отправки сообщения выберите команду ►Create system messages. Допускается отправка сообщений всем пользователям конкретной инстанции или всем пользователям системы SAP R/3, или всем пользователям определенного клиента. При этом можно ограничить время, в течение которого отправленное сообщение будет действительно: пользователи получат его только в том случае, если работают в системе в заданный период времени или находятся в конкретной инстанции. Когда пользователь начнет следующий шаг диалога, сообщение появится в отдельном окне. Полезно отправить системное сообщение, например при необходимости остановки одной из инстанций. Рекомендуется всегда давать пользователям такие предварительные предупреждения (см. рис. 2.6).

Рис. 2.6. Создание системного сообщения

2.4.5. Использование списков

Все, что выводится на экране, но не требует никакого интерактивного ввода от пользователей, называется списками. В системе SAP R/3 списки можно, распечатывать, сохранять в локальных файлах на компьютере уровня презентаций или посылать другим пользователям. Доступ к необходимым функциям можно получить с помощью команды System • List. Команды вводятся в командное поле.

► %sc используется для поиска символьных строк в списке и последующего позиционирования курсора. %sc+ ищет ту же строку.

► %pc сохраняет список в локальном файле на клиентской машине.

► %sl сохраняет список в SAP Office.

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

2.4.6. Использование средств обслуживания таблиц

Многие таблицы SAP R/3 можно (а иногда и нужно) модифицировать с помощью интегрированных в SAP R/3 средств обслуживания таблиц. Например, таблица Т000 содержит список всех клиентов системы SAP R/3. Если создается новый клиент, необходимо сначала создать новую запись в этой таблице. Для этого используются средства обслуживания таблиц и другие инструменты, предлагаемые SAP R/3:

► ►Data Browser в АВАР Workbench

Возможность обслуживания таблицы с помощью Data Browser должна быть закреплена в свойствах таблицы. До версии SAP R/3 4.6C можно было задать флажок, который разрешал обслуживание таблицы с помощью ►АВАР Dictionary: Start • Change • Attributes. В SAP Web Application Server используется ►АВАР Dictionary: Start • Change • Delivery and maintenance для выбора одного из следующих трех вариантов:

Display/maintenance Allowed with restriction (обслуживание с ограничениями)

Display/maintenance Allowed (обслуживание разрешено)

Display/maintenance Not allowed (обслуживание не разрешено)

► Расширенное обслуживание таблиц

К этому инструменту можно перейти из любого окна SAP R/3: System • Services • Table maintenance • Extended table maintenance

► Специальные объектно-зависимые транзакции

Примерами этого типа обслуживания являются ►Client maintenance или ►Transaction maintenance; последнюю можно использовать для внесения записей в таблицу TSTC.

Расширенные средства обслуживания таблиц полностью заменили стандартные средства, которые использовались в предыдущих версиях SAP R/3. Расширенные средства обслуживания таблиц можно использовать для работы с таблицей, если для них сгенерирован соответствующий интерфейс. Внешний вид средства обслуживания таблиц зависит от интерфейса, созданного для каждой таблицы. По умолчанию интерфейс обслуживания таблиц предлагается для всех таблиц SAP, которые могут потребовать модификации, включая таблицы Т000.

Чтобы добавить запись в таблицу Т000, выполните следующее (см. рис. 2.7):

1. Вызовите ►Table Maintenance.

2. Введите таблицу для модификации (в данном случае Т000).

3. Выберите Maintain.

4. Выберите New Entries.

Если выбрать Customizing (см. рис. 2.7), то будет показан обзор деятельности в Implementation Guide (IMG, см. главу 6), что требует обслуживания выбранной таблицы. К этим действиям можно перейти напрямую.

Рис. 2.7. Расширенное обслуживание таблиц

Средство обслуживания таблиц в АВАР Workbench не зависит от содержимого таблицы и ее назначения. Этот инструмент используется в основном для отображения содержимого таблицы.

С помощью средств SAP R/3 можно регистрировать изменения, вносимые в содержимое таблиц. Эту опцию нужно активизировать для каждой таблицы в словаре (Dictionary)системы SAP R/3.

2.5. Советы

► Проблемы при запуске

Если система не запускается, то лучше всего изолировать источник проблемы, запуская сначала только базу данных с инструментами базы данных. Если база данных запускается, то затем можно запустить систему SAP R/3 с помощью ММС или командного файла. Кроме специальных файлов журналов в домашнем каталоге пользователя <sid>adm, следует проверить записи деятельности разработчиков (см. главу 15) и область приложений в Event Viewer в системах Windows.

Проверка самих файлов профилей может быть особенно полезной после модификации параметров.

► Коммуникационные проблемы после добавления сервера приложений

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

► Анализ проблем без доступа к системе SAP R/3

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

2.6. Транзакции и пути доступа меню

АВАР dictionary: Start: SAP Menu • Tools • АВАР Workbench • Development ABAP Dictionary (SE11)

Client maintenance: SAP Menu • Tools • Administration • Administration • Client administration • Client Maintenance (SCC4)

Create system messages: SAP Menu • Tools • Administration • Administration • System messages (SM02)

Data Browser: SAP Menu • Tools • ABAP Workbench • Overview • Data Browser (SE16)

Process overview: SAP Menu • Tools • Administration • Monitor • System monitoring • Process overview (SM50)

Server list: SAP Menu • Tools • Administration • Monitor • System monitoring • Servers (SM51)

System log: SAP Menu • Tools • Administration • Monitor • System log (SM21)

Table maintenance: System • Services • Table maintenance • Enhanced table maintenance (SM31)

Transaction maintenance: недоступно в стандартном меню SAP (SM93)

User overview: SAP Menu • Tools • Administration • Monitor • System monitoring • User overview (SM04)

2.7. Дополнительная документация

Указания SAP Service Marketplace

Следующая таблица представляет обзор наиболее важных указаний в SAP Service Marketplace, которые имеют отношение к рассмотренным в этой главе вопросам.

Содержание	Указание
Table Maintenance in SAP R/3	28504
Using the dispatcher monitor: dpmon	42074
Test tool for the message server: lgtst	64015
Using the SAP Gateway Monitor: gwmon	64016

2.8. Контрольные вопросы

1. Какие профили используются для задания конфигурации SAP R/3?

a. R/3 Profile

b. Профиль инстанции

c. Профиль сервера приложений

d. DEFAULT.PFL

e. Профиль запуска

f. Профиль остановки

2. Система SAP R/3 не запускается. Где можно найти информацию о причинах проблемы?

a. startdb.log

b. startsap_<имя_компьютера>_<номер инстанции>.log

c. startsap.log

d. Записи деятельности разработчиков

e. Системный журнал

f. Записи деятельности SQL

3. Какие из следующих утверждений правильны?

a. Программа SAPLOGON позволяет определить доступ к различным системам SAP R/3.

b. Если используется SAPLOGON, то больше не требуется использовать SAP GUI.

c. Имена записей в SAPLOGON должны быть идентичны SID системы SAP R/3.

ГЛАВА 3 ОБСЛУЖИВАНИЕ И ПОДДЕРЖКА

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

Кроме обширной информационной поддержки, которую SAP делает доступной в Интернете на своем сайте www.sap.com, определенные средства, влияющие на работу системы и ее настройку, являются критически важными для системного администратора. Поддержку на различных уровнях предлагают SAP Service Marketplace, Online Service System (OSS, см. раздел 3.20) и sapserv[x].

Некоторые службы доступны через специальное соединение между SAP и средой клиента; другие службы доступны через Интернет.

3.1. Удаленное соединение

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

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

3.1.1. Общие замечания

Соединения между локальной сетью и внешним миром всегда могут снизить уровень безопасности. Доступ к локальной сети и ее компьютерам может быть предоставлен только для авторизованного персонала и приложений. Обычно используется брандмауэр, иногда даже не один, чтобы обеспечить безопасность доступа. Компания SAP предлагает Application Level Gateway (шлюз уровня приложений), использующий SAProuter, в качестве дополнения на уровне приложений для обеспечения безопасности коммуникации между удаленными системами SAP или между системой SAP и внешним миром. SAProuter можно использовать для мониторинга и протоколирования всех входящих и исходящих соединений с локальной системой SAP. Поэтому достаточно предоставить соединение между сервером, на котором выполняется SAProuter, и глобальной сетью (WAN). Все другие компьютеры, в частности сервер приложений SAP R/3 и сервер базы данных, не требуют отдельного доступа. Поэтому требуемая административная работа в сети концентрируется в центральном месте. SAProuter устанавливается на компьютере, который действует в качестве интерфейса между локальной сетью и внешним миром.

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

► ISDN

► Выделенная линия

► Интернет

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

SAP организует соединение с заказчиками аналогичным образом (см. рис. 3.1). Используемые системы брандмауэров SAP и SAProuter действуют на выделенных компьютерах. Все заказчики, которые хотят установить соединение со службой SAP, должны сначала предоставить IP-адреса своего сервера SAP R/3 и компьютеров SAProuter и запросить регистрацию систем в SAP. В ответ SAP сохраняет IP-адреса заказчиков в SAP и активирует доступ. В таблице 3.1 перечислены SAProuter, через которые SAP используется во всем мире.

Таблица 3.1. SAProuter, доступные для соединения с SAP

Компьютер	Расположение
sapserv1	Интернет-соединение (VPN)
sapserv2	Интернет-соединение (SNC)
sapserv3	Walldorf (Germany)
sapserv4	Foster City, California (USA)
sapserv5	Tokyo, Japan
sapserv6	Sydney, Australia
sapserv7	Singapore

В связи с растущим числом установок SAP будет продолжать увеличиваться число SAProuter. На рис. 3.1 показана общая процедура обработки соединений между системами заказчиков и SAP.

Рис. 3.1. Основные соединения через SAProuter

Соединение предполагает, что между SAProuter клиента и SAProuter (sapserv x) компании SAP можно установить физическое соединение. Можно использовать команду операционной системы ping для проверки соединения, прежде чем предпринимать дополнительные действия.

3.1.2. SAProuter

Стандартная установка SAP R/3 хранит исполняемый код SAProuter в корневом каталоге (см. главу 1). Текущую версию SAProuter можно найти в SAP Service Marketplace в разделе Quicklink /patches. Рекомендуется создать специальный каталог для SAProuter, его журнала и конфигурационных файлов. Можно скопировать программы из используемого по умолчанию каталога в созданный каталог. Для облегчения идентификации каталог часто называют /usr/sap/saprouter или <LW>:\usr\sap\saprouter.

Таблица разрешенных маршрутов

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

□ [P|S|D] <система_источник><целевая_система> [<служба><пароль>]

Ключи P, S и D обозначают следующее:

► P (Permit) — Разрешить

Описанное далее соединение явно разрешено.

► S (Secure) — Безопасный

Разрешены только соединения, которые используют протокол SAP, являющийся дополнением к протоколу TCP/IP. Его используют только компоненты SAP.

► D (Deny) — Отвергнуть

Описанное далее соединение явно отвергается.

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

Разрешенные записи в saprouttab включают:

□ D 194.3.*.* host1

Отказывает в доступе всем компьютерам в сети 194.3.*.* к локальному компьютеру «host1» независимо от запрошенной службы.

Следующая запись разрешает компьютеру с IP-адресом 195.7.8.102 доступ к ServiceX на «host2» с паролем «Schrat».

□ P 195.7.8.102 host2FServiceX Schrat

Если в таблице маршрутов появляется несколько записей, то используется первая правильная запись. В зависимости от потребностей вполне возможно использовать несколько таблиц маршрутизации и запускать SAProuter с определенной таблицей saprouttab.

SAProuter запускается с помощью saprouter -r, а останавливается с помощью saprouter -s.

В таблице 3.2 перечислены и описаны наиболее важные параметры для работы с этой программой.

Таблица 3.2. Параметры SAProuter

Параметр	Описание
-r	Запуск SAProuter с используемой по умолчанию таблицей разрешенных маршрутов.
-s	Остановка SAProuter.
-n	Повторное считывание таблицы разрешенных маршрутов без перезапуска SAProuter. Все изменения оказывают влияние только на новые соединения.
-l/-L	Вывод информации о маршрутах в кратком или расширенном виде.
-t	Изменить уровень маршрута 1 -> 2 -> 3 -> 1
-d	Запись подробной информации о соединении в файл dev_rout. Новая информация добавляется в существующий файл.
-T <файл>	Изменение имени файла журнала на <файл>
-p	Мягкое выключение SAProuter. SAProuter выключается, когда закрываются все соединения.
-R <saprouttab>	Присвоение таблицы маршрутизации, отличной от используемой по умолчанию.
-с <id>	Закрытие соединения <id>, которое уже было определено с помощью параметра -l.
-К	Запуск SAProuter в конфигурации Защищенной сетевой коммуникации (SNC). Аргументом параметра является имя SNC сервера SAProuter.
-G	Запуск параметра для определения файла журнала.
-V	Запуск параметра для определения уровня маршрута.
-S	Запуск параметра для определения порта (по умолчанию используется порт 3299).

3.1.3. Настройка соединения

Прежде чем можно будет воспользоваться соединением между локальной системой SAP R/3 и OSS, необходимо выполнить технические настройки. Для этого можно использовать ►OSS. Сначала необходимо задать SAProuter (как рекомендует SAP), для чего нужно использовать пункт меню SAProuter at SAP.

На стороне клиента необходимо ввести данные локального SAProuter. Технически можно реализовать два SAProuter, один после другого, в этом случае надо ввести оба. Для работы с OSS необходимо использовать SAP GUI. Определите, где можно найти эту программу на стороне клиента, используя для этого запись в нижней части экрана (см. рис. 3.2).

После сохранения этих записей можно воспользоваться кнопкой Logon to SAPNet, чтобы запустить соединение с ► OSS. Будет активировано соединение с локальным SAProuter, и запущен SAP GUI для OSS.

Строка маршрутизатора

Соединение SAProuter между двумя узлами коммуникации задается с помощью строки маршрутизатора (router string), которая состоит из подстрок следующего формата:

□ /Н/<хост/IР адрес>/S/<служба/номер_порта>/W/пароль

Рис. 3.2. Задание данных маршрутизатора

Спецификация службы и пароль являются необязательными: служба по умолчанию определяется с портом 3299.

Вызов SAP GUI для доступа к OSS происходит неявно следующим образом:

□ Sapgui /Н/<первый_локальный_SAProuter> [/Н/<второй_локальный_SAProuter>]

/H/<маршрутизатор_в_SAP>/H/<OSS>/S/<номер_инстанции_OSS>

Если в используемом saprouttab активируется маршрут между локальными системами и SAP, то соединение OSS можно вызывать напрямую, не вызывая регистрацию в системе SAP.

3.2. Службы SAP

Компания SAP предлагает большой набор служб и информации на следующих платформах:

► SAPNet R/3 Frontend

Эта специальная система SAP R/3 называлась ранее Online Service System (OSS — сетевая система обслуживания) и была доступна всем зарегистрированным заказчикам SAP через выделенное соединение (см. раздел 3.1). Для упрощения следующее описание также использует OSS в качестве сокращенного названия SAPNet R/3 Frontend.

► SAP Service Marketplace

SAP Service Marketplace является порталом Интернет-службы SAP. Он доступен вместе с дополнительной информацией о службах в OSS под заголовком Support.

Оба типа доступа предлагают заказчикам SAP почти одни и те же службы. Однако функции OSS будут в будущем еще более ограничены; новые предложения будут интегрироваться только в SAP Service Marketplace.

В таблице 3.3 перечислены основные службы, которые можно использовать; в разделе 3.4 эти службы рассматриваются более подробно.

Таблица 3.3. Основные службы

Служба	Путь доступа в меню в SAPNet R/3 Frontend	Быстрая ссылка в SAP Service Marketplace
Управление проблемами	Messages	message
База данных заметок	Gen. Function SAP notes	notes
Управление соединениями обслуживания	Service • Service connection	serviceconnection
Регистрация разработчиков и объектов (SSCR)	Registration • SSCR Registration	sscr
Регистрация пространства имен	Недоступно	namespaces
Запрос лицензионного ключа	Registration • System Request licence key	licensekeys
Запрос ключа миграции	Недоступно	migration-keys
Загрузка пакетов поддержки	Service • SAP Patch Service	patches
Администрирование пользователей	Administration • User administration	user-admin

SAPNet R/3 Frontend и SAP Service Marketplace являются различными способами доступа к одной и той нее базе данных, поэтому сообщения заказчиков, в частности, можно создавать с помощью одного инструмента, а анализировать с помощью другого.

Пользователь SAPNet

Для использования служб OSS и SAP Service Marketplace требуются специально созданные пользователи SAPNet; пользователь SAPNet с полными административными правами определяется для каждого номера заказчика. Этот пользователь может затем создать дополнительных пользователей для номера заказчика и присвоить требуемые авторизации. Эти функции доступны в SAPNet R/3 Frontend через ► OSS • Administration • User administration или в SAP Service Marketplace в Quicklink /user-admin. Определяя номер заказчика, можно также запросить дополнительного пользователя на начальной странице SAP Service Marketplace; однако, поскольку новый пользователь создается без какой-либо авторизации, пользователь-администратор должен модифицировать его на стороне заказчика.

Созданный таким образом ID всегда имеет вид S<десятизначное число>, поэтому обычно говорят S-пользователь.

3.3. Основные службы

3.3.1. Управление проблемами

С помощью SAPNet R/3 Frontend и SAP Service Marketplace можно создавать сообщения заказчика и посылать их на горячую линию SAP (Hotline). Эти сообщения автоматически пересылаются обслуживающему персоналу SAP, обрабатываются, а затем посылается ответ с рекомендованным решением. Можно просматривать, редактировать и завершать решения с помощью OSS или SAP Service Marketplace.

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

► Послано в SAP (To be sent to SAP)

► Новое в SAP (New at SAP)

► Обрабатывается в SAP (In process by SAP)

► Запрос от SAP (Inquiry from SAP)

► Предложенное SAP решение (Solution proposed by SAP)

► Подтверждено сегодня (Confirmed today)

На рис. 3.3 показан экран для ввода сообщения в OSS.

Рис. 3.3. Создание сообщения заказчика с помощью OSS

Для создания нового сообщения в SAP Service Marketplace можно использовать Quicklink /message. Мастер сообщений (Message Wizard) предложит ввести всю требуемую информацию. Данные регистрации в системе определяют заказчика, и эти данные автоматически вставляются в сообщение.

Подтверждение

Подтверждения зарегистрированных проблем можно найти в OSS в подменю Inquiry from SAP или Solution proposed by SAP. В SAP Service Marketplace можно найти эти документированные подтверждения через /message Search for messages (см. рис. 3.4).

3.3.2. База данных заметок SAP

SAP предоставляет своим заказчикам подборку известных проблем, решений и рекомендаций о том, как избежать этих проблем в области SAP Notes в OSS и в разделе Quicklink /notes. Каждая заметка SAP имеет уникальный номер и область применения, состоящую из задействованных компонентов SAP, вовлеченных релизов, операционной системы и версии РСУБД.

Рис. 3.4. Поиск сообщений заказчика в SAP Service Marketplace

Различные функции фильтрации помогают пользователям при поиске конкретной информации по их проблемам в базе данных по ключу. Соответственно многие пользователи находят решение проблем в базе данных (см. рис. 3.5).

3.3.3. Соединения обслуживания

Когда SAP работает над проблемой, часто требуется более точный анализ ситуации в конкретной системе SAP R/3. Чтобы сотрудники компании SAP и ее компаний-партнеров могли зарегистрироваться в такой системе, это соединение должно быть явно активировано авторизованным S-пользователем в OSS или SAP Service Marketplace (см. рис. 3.6). Сохраненные данные заказчика служат в качестве основы для настройки соединения; поэтому данные должны постоянно обновляться, что является необходимым условием для создания соединения обслуживания.

Чтобы открыть соединение обслуживания на определенный период, используйте путь доступа меню ►OSS • Service • Service connection • Select system • Edit • Open или Quicklink /serviceconnection в SAP Service Marketplace.

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

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

Рис. 3.5. Поиск заметок SAP в SAP Service Marketplace

Рис. 3.6. Иллюстрация соединения обслуживания в SAP Service Marketplace

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

Разработчики и объекты регистрируются как часть SAP Software Change Registration (см. главу 6) в OSS с помощью ►OSS • Registration • SSCR Registration, а в SAP Service Marketplace в разделе Quicklink /sscr (см. рис. 3.7).

Рис. 3.7. Регистрация разработчика в SAP Service Marketplace

3.3.5. Регистрация пространств имен

Заказчики могут использовать определенные ранее объекты системы SAP и при необходимости создавать, транспортировать и использовать в производственной деятельности свои собственные объекты, такие как отчеты, таблицы и т.д. Для различия во время обновления между этими объектами заказчика и исходными объектами SAP зарезервированы специальные пространства имен в среде имен. Объекты, чье имя начинается с Y или Z, считаются объектами заказчика.

Эти соглашения могут оказаться неэффективными для разработчиков партнерских фирм SAP или крупномасштабных разрабатываемых проектов заказчика. В этих случаях можно использовать SAP Service Marketplace в разделе Quicklink /namespacesдля запроса специального пространства имен (см. главу 6). Новые объекты будут распознаваться, так как их имена будут начинаться с идентификатора (ID) пространства имен. Чтобы гарантировать, что владельцы или другие авторизованные лица смогут изменить объекты, пространство имен должно быть обеспечено лицензией разработчика. После того как SAP создала пространство имен, лицензию разработчика можно создать через сеть.

Только SAP Service Marketplace поддерживает работу с пространствами имен, в OSS соответствующая возможность более не действует.

3.3.6. Лицензионный ключ

Если новая установка, реконфигурация или перемещение требуют нового лицензионного ключа, можно запросить этот ключ через сеть. В OSS используется ►OSS • Registration • System • Registration • Request license key; в SAP Service Marketplace используется Quicklink /licensekeys (см. рис. 3.8).

Рис. 3.8. Запрос лицензионного ключа

Процесс активации лицензионного ключа описывается в главе 4.

3.3.7. Миграционный ключ

Специальный миграционный ключ нужен для выполнения неоднородной копии системы. Неоднородная означает копию системы, при которой изменяются РСУБД или операционная система. Ключ можно сгенерировать в SAP Service Marketplace в разделе /migration-keys, определяя следующие параметры источника и цели:

► Идентификатор системы

► Релиз SAP R/3

► Операционную систему

► Систему базы данных

► Имя хоста сервера базы данных

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

3.3.8. Загрузка пакетов и программ поддержки

Можно загружать исправления, которые понадобятся для обеспечения правильной работы системы SAP, используя Quicklink /patches в SAP Service Marketplace. Пакеты поддержки можно найти также (см. главу 6) через ►OSS • Service • SAP Patch Service, а также найти дополнительные технологические компоненты, такие как SAProuter (см. раздел 3.2), двоичные исправления (программы среды времени выполнения) и исправления для SAP GUI или ITS (Internet Transaction Server).

3.4. Инструменты поддержки

3.4.1. EarlyWatch Alert

EarlyWatch Alert является бесплатной службой мониторинга производительности системы и администрирования. Необходимо выполнять ее раз в неделю. Системные данные, генерируемые во время этого процесса, посылаются в SAP, где они анализируются с помощью автоматических средств проверки и возвращаются заказчику в виде отчета. Отчеты можно найти в SAP Service Marketplace в раскрывающемся боксе Inbox • Status trace.

Чтобы подготовиться к сеансу EarlyWatch или GoingLive, необходимо загрузить дополнительные инструменты, находящиеся в разделе /supporttools.

3.4.2. Note Assistant

Начиная с Basic Release 6.10, стандартная поставка SAP R/3 включает Note Assistant. Этот инструмент обеспечивает поддержку системного администратора во время реализации решения. Ранее реализация этих решений требовала от пользователя изменения исходного кода вручную или ожидания следующего пакета поддержки.

Выбранные заметки SAP (SAP Notes) можно загрузить из OSS или SAP Service Marketplace и автоматически реализовать изменение кода с помощью Note Assistant. Note Assistant также автоматически проверяет, что текущий статус системы (пакеты поддержки, уже реализованные заметки и модификации) допускает предложенное изменение. Если описанные в других заметках SAP изменения являются предварительным условием планируемого изменения кода, то эти изменения также загружаются и вставляются в очередь SAP Notes (см. рис. 3.9).

Рис. 3.9. Рабочая очередь Note Assistant

Изменения записываются в запрос (см. главу 6) и поэтому могут переноситься на последующие системы. Используйте ►Note Assistant для управления очередью и загрузки изменений. Если реализация требует настройки параметров в дополнение к требуемым изменениям в исходном коде, необходимо включить эти модификации вручную, даже при использовании Note Assistant.

Использование Note Assistant не требует ключа SSCR. Сделанные с помощью Note Assistant изменения часто можно отменить.

Можно использовать перенос или транспортировку для загрузки функций Note Assistant в более ранние релизы Basis.

3.5. SAP Solution Manager: Обзор

SAP Solution Manager предлагает центральную платформу для реализации и работы системной среды.

SAP Solution Manager предоставляет инструменты и функции для следующих областей:

► Управление бизнес-процессами

► Управление технологией mySAP

► Управление изменением программного обеспечения

► Управление службой поддержки

Технически SAP Solution Manager действует как отдельная прикладная система mySAP на основе SAP Web Application Server; его использование включено в плату за сопровождение, поэтому не влечет за собой никаких дополнительных лицензионных расходов. Требуемое программное обеспечение можно заказать в SAP Service Marketplace: Quicklink /solutionmanager.

Хотя SAP Solution Manager можно установить на сервере, на котором уже выполняется система SAP, настоятельно рекомендуется использовать отдельный сервер, чтобы облегчить сопровождение.

Функциональная область действия

SAP Solution Manager функционирует как центральный узел для управления одной или несколькими системными средами. Он получает информацию, требуемую для своего функционирования, от каждой отдельной системы. Для поступления этой информации необходимо поддерживать соединения RFC (см. главу 13) со всеми системными средами и соответствующими управляемыми системами R/3. Все требуемые данные систем SAP будут вызываться или передаваться через интерфейсы RFC. Для каждой системной среды доступны следующие возможности:

► Scope (Область действия)

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

► Implementation (Реализация)

В этой области SAP Solution Manager предлагает Solution Management Roadmap (Дорожная карта управления решением) для поддержки реализации нового бизнес-процесса и систем SAP. Solution Management Roadmap структурирована согласно фазам реализации проекта.

► Operations(Операции)

Портал операций является платформой для выполнения и администрирования всеми службами, предлагаемыми SAP Active Global Support. Эти службы включают не только GoingLive Check или Early Watch, но также Self Services и Solution Management Optimization Services (SMO). Эти службы можно получить прямо в SAP Solution Manager через SAP Service Marketplace. Self Service можно выполнять самостоятельно, хотя это предполагает определенный уровень знаний. Консультанты или сетевая поддержка выполняют другие службы на сайте или удаленным образом. Документы Best Practice по выбранным темам управления решением являются ценным источником информации.

Рис. 3.10. Поддержание ключевых значений системной рабочей среды

► Monitoring (Мониторинг)

В отличие от большинства продуктов, которые контролируют работу программного обеспечения, область мониторинга в SAP Solution Manager использует подход на основе бизнес-процессов, что облегчает диагностику влияния, которое проблемы в системных операциях могут оказывать на бизнес-процессы. SAP Solution Manager поддерживает различные представления системной рабочей области.

Мониторинг бизнес-процессов

Представление, ориентированное на бизнес (Business Process Monitoring), выводит поток и шаги обработки бизнес-процесса вовлеченных систем (см. рис. 3.11).

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

Рис. 3.11. Представление шагов обработки базового бизнес-процесса

Мониторинг системы

Технически ориентированное представление (System Monitoring) выводит все системы и их соединения (см. рис. 3.12). Красная, желтая и зеленая пиктограммы на начальном экране указывают на общее состояние системы. Можно выбрать систему и автоматически перейти к ее контролирующей архитектуре. Эти мониторы созданы на основе мониторов сигналов, определенных в каждой системе (см. главу 16). Мониторинг в SAP Solution Manager выводит специальное представление мониторов сигналов, определенных в системе.

Отчеты уровня обслуживания

Область Solution Management and Reporting представляет интерес для производителей программных решений. Можно определить отчеты уровня обслуживания (service level reporting) для системной среды на основе автоматического и регулярного выполнения службы EarlyWatch Alert. Собранные о системе данные используются для создания отчета, который предоставляет информацию о соответствующих ключевых показателях, таких как рост объема данных, историческое изменение времени ответа, рабочая нагрузка, нагрузка на оборудование и доступность. Это средство можно использовать для создания регулярных отчетов о системной среде.

Рис. 3.12. Мониторинг системной рабочей среды

► Support Portal (Портал поддержки)

Портал Support Portal позволяет видеть действия канала обслуживания, такие как подготовка к обслуживанию или самообслуживание. Он также предлагает обзор всех сообщений о проблемах, открытых для системы. Можно просматривать и обрабатывать сообщения прямо из SAP Solution Manager. Кроме того, можно задать специальный вид пользователя и доступ к SAP Service Marketplace, который является центральным узлом инструментов поддержки и обслуживания.

3.6. Советы

► Документация в Интернете

Полную сетевую документацию по решениям mySAP и SAP для различных отраслей можно найти по адресу help.sap.com. Никакой идентификатор не требуется.

► Предложения SAP по обучению

Полный каталог курсов SAP можно найти и даже зарегистрироваться через сеть в разделе Quicklink /education в SAP Service Marketplace.

► Руководства по установке и обновлению

Руководства по установке и обновлению для всех поддерживаемых компонентов можно найти в SAP Service Marketplace по ссылке Quicklink /instguides.

► SSCR: Запрос ключей разработчика или объекта

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

► Уведомление по e-mail об изменении статуса сообщений заказчика

При использовании Message Wizard в SAP Service Marketplace для создания сообщений заказчика и задании адреса e-mail, заказчик будет уведомлен по e-mail, когда сообщение будет разрешено или представлено для действия заказчика.

3.7. Транзакции и пути доступа меню

Note Assistant: нет стандартного пункта меню (SNOTE)

OSS: System • Services • SAP Service (OSS1)

3.8. Дополнительная документация

Быстрые ссылки

► SAP Service Marketplace: псевдоним saprouter

► SAP Service Marketplace: псевдоним remoteconnection

► SAP Service Marketplace: псевдоним internetconnection

► SAP Service Marketplace: псевдоним supporttools

► SAP Service Marketplace: псевдоним solutionmanager

► SAP Service Marketplace: псевдоним dbosmigration

Указания SAP Service Marketplace

Таблица 3.4. Указания SAP, относящиеся к обслуживанию и поддержке

Содержание	Указание
Guide to OSS1	33135
Network suppliers for a connection to SAPNet R/3 Frontend	33953
Schedule connection to SAP extranet, OSS, and SAPNet	137342
Collective note on service connections	35010
OSS logon	17285
SAProuter documentation	30289
Schedule VPN connection to the SAP network	486688
Customer messages in SAPNet R/3 Frontend	74131
Customer Message Wizard	307037
User administration in SAPNet R/3 Frontend	103926
Activating SAP EarlyWatch Alert	207223
Service tools for ST-A/PI applications	69455 и 91488

3.9. Контрольные вопросы

1. Для чего используется программа SAProuter?

a. Она заменяет брандмауэр.

b. Она управляет настройкой удаленных соединений с сервером приложений системы SAP R/3.

c. Она задает соединения между клиентами и серверами приложений системы SAP R/3 в локальной сети.

2. Какой файл используется по умолчанию для поддержания данных маршрутизации SAProuter?

a. saprouttab

b. DEFAULT.PFL

c. autoexec.bat

3. Какие предварительные условия должны выполняться, чтобы SAP создал соединение обслуживания с системой SAP R/3 заказчика?

a. Система SAP R/3 должна быть зарегистрирована в OSS.

b. Данные соединения сервера приложений и SAProuter должны поддерживаться на стороне заказчика.

c. Заказчик должен открыть соединение.

ГЛАВА 4 ПРИНЦИПЫ ИНСТАЛЛЯЦИИ

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

4.1. Подготовка к инсталляции

Масштабирование

Прежде чем приступать к инсталляции, нужно принять решения относительно аппаратного и программного обеспечения. Факторы, определяющие эти решения, обсуждаются ниже. Один из наиболее важных моментов в планировании инсталляции — это определение ожидаемого масштаба будущей системы SAP R/3. На размер системы SAP R/3 существенно влияют следующие параметры:

► Число пользователей (как общее, так и количество одновременно работающих пользователей)

► Применяемые модули R/3 и число пользователей на каждый модуль

► Объем вводимых данных и время их хранения в системе

► Число и объем запросов для фоновой обработки

► Планируемый обмен данными через интерфейсы

► Число и размер запросов вывода/печати

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

Требования, предъявляемые к аппаратному обеспечению

Следующий шаг в подготовке к инсталляции — выбор соответствующего аппаратного обеспечения, операционной системы, РСУБД, периферийного оборудованиями т. д. К этапу планирования надо подходить серьезно, поскольку принятие неверных решений на данной стадии приведет позднее к дополнительным расходам и увеличению объема работы.

SAP Service Marketplace перечисляет допустимые комбинации операционной системы и базы данных для выполнения системы SAP R/3 на сайте http://service.sap.com/platforms. Установка может быть либо однородной (все физические компоненты используют одну операционную систему, либо неоднородной при:

► Использовании различных вариантов UNIX для серверов базы данных и приложений

► Использовании сервера UNIX для базы данных и серверов Windows для инстанций приложений

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

Предположим, что эти вопросы были успешно выяснены и что есть необходимое оборудование и программное обеспечение SAP R/3.

Контрольный список

Важным начальным шагом, предшествующим инсталляции, является использование контрольного списка, который поставляется в каждом комплекте продукта для проверки соответствия требованиям. В нем перечислены наиболее существенные требования для каждой РСУБД и операционной системы. Для SAP R/3 4.6C центральная инстанция требует примерно 25 Гбайт на диске (без данных приложений). Требования к дисковой памяти зависят от операционных систем и применяемых РСУБД. Компьютер, на котором выполняется центральная инстанция, должен иметь также достаточно места для «пространства свопинга» (области страничного обмена). Рекомендуемый объем пространства свопинга зависит от операционной системы и используемого ядра SAP (32- или 64-битное). Отметим следующие требования для каждого компонента (базы данных и сервера приложений).

► Windows NT

Пространство свопинга должно быть в четыре раза больше оперативной памяти компьютера: не менее 4 Гбайт и максимально полезный объем порядка 10 Гбайт.

► 32-битное ядро UNIX

Пространство свопинга должно быть в три раза больше оперативной памяти компьютера плюс 500 Мбайт: как минимум 3 Гбайт и максимально полезный объем порядка 20 Гбайт.

► 64-битное ядро UNIX

Пространство свопинга должно быть как минимум 20 Гбайт независимо от памяти компьютера.

Минимальный размер памяти для системы UNIX равен 256 Мбайт и 512 Мбайт для систем Windows NT. Использование процессора SAP J2EE требует дополнительно от 64 до 512 Мбайт оперативной памяти.

Выделенный для приложений сервер требует около 800 Мбайт дискового пространства исключительно для рабочей области программного обеспечения SAP R/3. Если центральный каталог переноса также создается на данном компьютере, то должно быть доступно еще больше пространства. Опыт показывает, что следующие релизы требуют больше памяти (Mem) и более мощный процессор (CPU) в связи с растущим спросом на производительность. В таблице 4.1 показано среднее увеличение ресурсов серверов базы данных и приложений для самых последних релизов SAP R/3.

Таблица 4.1. Средние дополнительные требования к ресурсам

Целевой релиз
Исходный релиз		4.08	4.58	4.6C	R/3 Enterprise
	3.1l	MemDB: +10% MemAPP: +30% CPUDB: +10% CPUAPP: +30%	MemDB: +10% MemAPP: +56% CPUDB: +10% CPUAPP: +56%	MemDB: +10% MemAPP: +100% CPUDB: +10% CPUAPP: +72%	MemDB: +10% МетАРР: +115% CPUDB: +10% CPUAPP: +80%
	4.0В	—	MemDB: +0% MemAPP: +20% CPUDB: +0% CPUAPP: +20%	MemDB: +0% MemAPP: +56% CPUDB: +0% CPUAPP: +32%	MemDB: +0% MemAPP: +64% CPUDB: +0% CPUAPP: +40%
	4.5В	—	—	MemDB: +0% MemAPP: +30% CPUDB: +0% CPUAPP: +10%	MemDB: +0% MemAPP: +37% CPUDB: + 0% CPUAPP: +16%
	4.6С	—	—	—	MemDB: + 0% MemAPP: +5% CPUDB: +0% CPUAPP: +5%

Требования для ПК клиента системы зависят от следующих факторов:

► Версии SAP GUI

► Области действия функций клиента

► Активации настроек SAP GUI для экономии ресурсов

► Уровня использования других приложений (Microsoft Office, почтовых программ и т.д.)

Рекомендуется как минимум 64 Мбайт памяти (согласно заметке OSS на эту тему), однако, желательно иметь 128 Мбайт памяти.

Требования, предъявляемые к ПО

Определенные требования предъявляются также к ПО, такому как NFS (Network File System), операционной системе соответствующей версии, поддержке языка (locales) и TCP/IP. Для SAP R/3 необходима англоязычная версия Windows NT и Windows 2000. Требования, предъявляемые к ПО, зависят от операционной системы и РСУБД, а потому существенно различаются. Зависят они и от конкретной версии SAP R/3, а потому следует внимательно проверить их по контрольному списку.

Конфигурация дисков

После проверки требований следующий шаг — это планирование распределения данных по отдельным дискам. Защита всегда имеет более высокий приоритет, чем производительность, и здесь существуют некоторые базовые правила в отношении производственной системы (см. рис. 4.1):

► Независимо от используемого ПО РСУБД фактическую область данных и область журнала следует размещать на разных дисках (если это возможно) с разными контроллерами. В этом случае отказ диска не будет влиять одновременно на области данных и журнала.

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

► Если данные будут храниться на диске сервера, где выполняется база данных системы SAP R/3, то диск архивирования должен отличаться от диска, на котором выполняется база данных.

Рис. 4.1. Хранение данных на нескольких дисках

Несоблюдение этих рекомендаций ведет к риску потери данных и к снижению производительности. Приведенные рекомендации имеют сложное обоснование и определяются особенностями архитектуры РСУБД (данная тема выходит за рамки этой книги).

В минимальной инсталляции SAP R/3 для целей тестирования потребуется как минимум три жестких диска.

Дисковые массивы RAID

Системы RAID (Redundant Array of Inexpensive Disks) эффективно используются в среде SAP R/3. Основными особенностями этой технологии являются безопасность, отказоустойчивость и производительность операций ввода/вывода.

Таблица 4.2. Raid Level, используемые при работе SAP R/3

RAID Level	Свойства	Избыточность	Эффективность использования дискового пространства	Чтение [случайное / последовательное]	Запись [случайная / последовательная]
Без RAID	Одно дисковое устройство	Нет	1	0/0	0/0
0	Чередование без контроля четности	Нет	1	++/+++	++/+++
1	Зеркалирование и дублирование	От очень высокой до крайне высокой	0.5	+/0	-/+
5	Блочное чередование с распределенным контролем четности	Высокая	(n-1)/n для n дисков	++/+	--/0
01/10	Зеркалирование и чередование без контроля четности	От очень высокой до крайне высокой	0.5	+++/+++	++/+++

Систему RAID1, RAID01 или RAID10 можно использовать для обеспечения высокой безопасности и хорошей производительности, если не забывать при этом о физическом разделении отдельных областей данных. Можно использовать также систему RAID5 для базы данных SAP R/3, чтобы использовать доступное дисковое пространство более эффективно. В связи с отсутствием избыточности RAID0 не подходит для работы системы SAP R/3.

Отказ диска

При правильной установке система SAP R/3 будет продолжать работать при отказе во время работы диска в конфигурации избыточного RAID.

В большинстве дисковых подсистем, которые используются для системы SAP R/3, неисправный диск можно заменить и подключить заново, не останавливая систему. Однако во время синхронизации необходимо ожидать снижения производительности.

SAP Service Marketplace предлагает ценные SAP Notes о последних изменениях и рекомендациях для проведения процедуры установки. В руководствах по установке можно также найти номера SAP Notes, имеющих отношение к установке. Даже опытные специалисты по установке должны ознакомиться с этими SAP Notes, прежде чем начинать эту процедуру.

До версии Basic Release 4.6D (см. главу 1) установка компонентов mySAP выполнялась с помощью утилиты R3setup; начиная с Basic Release 6.10, используется утилита SAPinst.

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

► UNIX

Создание файловых систем и «сырых» (raw) устройств

Конфигурация параметров ядра UNIX и пространства свопинга

► Windows NT

Установка Microsoft Management Console (MMC)

Конфигурация виртуальной памяти и файлового кэша

Для программ установки нужен собственный каталог установки, имеющий примерно от 50 до 150 Мбайт свободного дискового пространства для хранения файлов команд и журналов.

Интеграция LDAP

Если каталог LDAP (Lightweight Directory Access Protocol) уже используется в среде установки для управления системными данными, можно сконфигурировать устанавливаемую систему SAP R/3, чтобы использовать LDAP для хранения и получения данных. LDAP является основой для взаимодействия между системой SAP R/3 и каталогом LDAP. Этот интерфейс используется для определения коммуникаций между партнерами и для задания правил хранения и доступа к данным.

Хранящуюся в каталоге LDAP информацию можно анализировать с помощью следующих механизмов:

► Microsoft Management Console (MMC)

Проверяет данные, такие как статус и параметризацию серверов приложений.

► LDAP Connector

Это интерфейс АВАР, который приложения SAP могут использовать для доступа к информации в каталоге LDAP.

► SAPLOGON

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

Каталог LDAP необходимо сначала подготовить для хранения данных системы SAP R/3. Это можно сделать вручную или используя R3setup вместе со службой Active Directory из Windows 2000. R3setup и SAPinst используют специальные настройки в системе SAP R/3 для коммуникации с каталогом LDAP как часть установки центральной инстанции SAP R/3.

4.2. Архитектура программы инсталляции R3setup

Процедура инсталляции с помощью R3setup (см. рис. 4.2) успешно использует преимущества технологии клиент/сервер. Можно вызвать и работать с программой R3setup локально или через любой компьютер, имеющий соединение TCP/IP с целевым компьютером, используя средство InstGUI. Компонент InstGUI является сценарием Tcl/Tk, доступным для X Window (UNIX) и различных настольных систем Windows. В дополнение к программе InstGUI существует реальная программа установки R3Setup, которая находится на сервере. Инсталляция может выполняться в диалоговом режиме (при прямом локальном вызове или под контролем InstGUI) или в фоновом режиме с передачей ей всех параметров.

Рис. 4.2. Инсталляция с помощью R3setup

При применении InstGUI пользователю клиентской системы передаются генерируемые на каждом шаге подтверждающие сообщения.

Если происходит ошибка, то можно устранить проблему и продолжить процесс инсталляции с того места, где была допущена неточность.

Основное преимущество данной архитектуры состоит не только в единообразном интерфейсе для пользователя в форме InstGUI. Устранена такая проблема, как различия в процедурах инсталляции в среде UNTX, Windows NT и разных РСУБД. Все процессы инсталляции управляются через R3Setup. Разделение на клиентскую (InstGUI) и серверную (R3setup) части означает, что установщик больше не привязан к будущему серверу SAP R/3. Таким образом, при инсталляции R/3 после запуска R3setup на целевой машине можно войти в R3Setup с другого компьютера. Если сетевое соединение между InstGUI и R3setup обрывается во время установки, или если InstGUI останавливается, то процесс R3setup продолжает выполняться. Соединение можно восстановить в любое время.

Управление InstGUI

При запуске InstGUI на любом компьютере сначала определяется порт TCP/IP для коммуникации с R3setup (который будет запушен позже). Требуемая для запуска R3setup командная строка выводится на целевом компьютере (см. рис. 4.3).

Рис. 4.3. Запуск InstGUI

Если R3setup запускается с этими параметрами на целевом компьютере, то InstGUI устанавливает соединение с R3setup. Когда соединение успешно установлено, экран изменяется (см. рис. 4.4).

В InstGUI можно переключаться между двумя представлениями с помощью Switch view (см. рис. 4.4):

► Step view

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

► Log view

R3setup записывает специальный файл журнала выполнения, который можно просмотреть прямо из InstGUI. Этот журнал содержит текущий шаг инсталляции и все предупреждения или ошибки, которые произошли до данного момента (см. рис. 4.5).

Рис. 4.4. Успешное соединение InstGUI и R3setup

Рис. 4.5. Log View сообщения об ошибке, выведенного в InstGUI

4.3. Процедура инсталляции

Настройка рабочей системы SAP R/3 требует установки следующих компонентов.

► Инстанция базы данных и программное обеспечение РСУБД

► Центральная инстанция

► Дополнительные диалоговые инстанции (если требуется)

► Инстанции, действующие как автономные шлюзы для других систем SAP R/2 и R/3 (если требуется)

► Клиенты

Установка каждого компонента с помощью R3setup происходит в два этапа. На первом необходимо ввести специфические данные конфигурации пользователя, требуемые будущей системе SAP R/3. Второй этап состоит из реальной обработки — в идеале, без дополнительного ввода со стороны пользователя.

Когда устанавливается новая система SAP R/3, процесс инсталляции идет с сервера на клиентскую часть. На первом шаге устанавливают РСУБД и базу данных на будущем сервере базы данных. На следующем шаге устанавливают центральную инстанцию на выбранном сервере приложений. После этого можно будет установить дополнительные инстанции. Процедура R3setup не включает установку клиентов; их можно установить в любое время (см. раздел 4.5).

Управляющие файлы

R3setup проверяет и настраивает управляющие файлы, которые определяют последовательность установки (см. рис. 4.2). Готовые шаблоны управляющих файлов хранятся в каталоге установки во время установки R3setup. Управляющие файлы являются редактируемыми текстовыми файлами, их имена отражают тип установки (см. таблицу 4.3).

Таблица 4.3. Список стандартных управляющих файлов для R3setup

Управляющий файл	Содержание	Комментарии
CNTRDB.R35	Установка на одном сервере центральной инстанции и инстанции базы данных	Больше недоступен для SAP R/3 4.6C на UNIX
CENTRAL.R35	Установка центральной инстанции
DATABASE.R35	Установка инстанции базы данных
DIAL0G.R35	Установка дополнительной инстанции приложений
GATEWAY.R35	Установка инстанции шлюза
CDINST.R35	Установка R3setup	Недоступен в системе UNIX

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

Этап 1 - Ввод

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

Необходимо указать следующие записи:

► Имя системы SAP R/3

► Имя инстанции базы данных — идентично имени системы SAP R/3, за исключением систем нескольких компонентов на одной базе данных (MCOD) (см. раздел 4.4.2)

► Число инстанций R/3

► Сервер для каталога переноса

► Каталоги для временного хранения файлов экспорта базы данных

► Файловая структура базы данных

► Уровень параллельности обработки при загрузке базы данных

Могут потребоваться дополнительные данные в зависимости от используемой РСУБД и операционной системы.

Область [ЕХЕ] управляющего файла перечисляет пронумерованные шаги установки в порядке выполнения в виде блок-схемы.

Следующий раздел управляющего файла CENTRDB.R3S для установки центральной инстанции и базы данных показывает фрагмент блок-схемы установки вместе с выполняемыми здесь шагами (см. листинг 4.1)

Листинг 4.1. Фрагмент управляющего файла CENTRDB.R3S

[ЕХЕ]

10=CENTRDBINSTANCE_NT_ORA

20=DBCOMMONDBENV_NT_ORA

30=DBSAPDATAPATH_NT_IND

40=CALCRAM_IND_IND

50=CDSERVER46CSR2_NT_ORA

60=OSGROUPSAPLOCALADMIN_NT_IND

70=OSGROUPSAPLOCAL_NT_IND

………………………

610=DBCREATEDB_NT_ORA

620=DBPOSTBUILD_NT_ORA

630=DBCREATEROLLSEGSTART_NT_ORA

640=DBCREATETSP_NT_ORA

650=DBCREATEROLLSEG_NT_ORA

660=ORADBUSR_NT_ORA

………………………

890=RFCRSWBOINI_IND_IND

900=RFCRADDBDIF_IND_IND

910=R3CIFILEPERMISSIONS_NT_IND

920=QUERIESFINISHED_NT_IND

[CENTRDBINSTANCE_NT_ORA]

CLASS=CNTCommonParameters

CONFIRMATION=SAPSYSTEMNAME SAPSYSNR SAPLOG SAPNTDOMAIN

SAPTRANSHOST DB_SID

INSTALLATIONTYPE=CI

MSGID=RI_GIST_CENTRALINSTANCE_IND_IND

SAPLOG=(RI_GIKY_NA_COM_SAPLOG, entry { { label RI_GIKY_NA_COM_SAPMNT_LABEL }{ regexp [A-Z][:]?$} } )

SAPNTDOMAIN=(RI_GIKY_NA_COM_SAPNTDOMAIN, entry { { label "Domain of all SAP Users and Groups" } } )

SAPSYSNR=00 (RI_GIKY_NA_COM_SAPSYNR, entry { { label RI_GIKY_NA_COM_SAPSYNR_LABEL } { regexp (([0-8][0-9]) | (9[0-6]) )$ } } )

SAPSYSTEMNAME=C11 (RI_GIKY_NA_COM_SAPSYSTEMNAME, entry {{ label RI_GIKY_NA_COM_SAPSYSTEMNAME_LABEL } { regexp [A-Z][A-Z0-9][A-Z0-9]$} } )

SAPTRANSHOST=(RI_GIKY_NA_COM_SAPTRANSHOST, entry {{ label RI_GIKY_NA_COM_SAPTRANSHOST_LABEL}} )

[DBCOMMONDBENV_NT_ORA]

CLASS=COraDbIniDefKey

CONFIRMATION=NLS_CHARACTERSET SAPDATA_HOME DB_HOME_NAME

DB_HOME_NAME=(RI_GIKY_NA_COM_ORANT_DBHOMENAME)

INST_MODE=OLD (RI_GIKY_NA_QT_INSTMODE, radiobox {{ label "Install for Multi Schema?" } { OLD "No (old style)" } { NEW "Yes (new style)" }} )

MSGID=RI_GIST_DBCOMMONDBENV_IND_IND

NLS_CHARACTERSET=WE8DEC

SAPUSERPASSWD=(RI_GIKYJIA_COM_SAPUSERPASSWD)

SVRMGR=@DB_H0ME@\bin\svrmgr30.exe

[DBCREATEDB_NT_ORA]

CLASS=COraCreateDb

LIST=Z_ORACREATETSP

MSGID=RI_GIST_DBCREATEDB_IND_IND

STEP_ENV=DB_ENV

STEP_USER=@SAPNTDOMAIN@\@LOWER_SAPSYSTEMNAME@Adm

STEP_USERPASSWORD=@OSUSERSIDADMPASSWD_NT_IND=PASSWORD@

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

Этап 2 - Обработка

Когда до инсталляции планирование было выполнено полностью, проблем не возникнет и вся работа администратора, занимающегося установкой системы R/3, обычно ограничивается сменой в дисководе компакт-дисков и инсталляцией ПО РСУБД.

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

Если возникает такая ошибка, программа R3Setup завершает работу и записывает в управляющий файл следующую запись для отказавшего шага.

□ STATUS=ERROR

При каждом выполнении R3setup создает специальный файл журнала с именем <тип_установки>.log. Чтобы упростить анализ ошибок, для каждого законченного шага в файле делается отдельная запись. Пример в листинге 4.2 показывает проблему, которая возникла на шаге DBCOMMONDBENV_NT_ORA.

Листинг 4.2. Запись об ошибке в файле журнала CENTRDB.log

ERROR 2002-11-03 14:21:07 DBCOMMONDBENV_NT_ORA Internal - ColdKeyCheck:0

Please install Oracle before continuing the installation!

ERROR 2002-11-03 14:21:07 DBCOMMONDBENV_NT_ORA ColdKey - Check:0

Phase failed.

ERROR 2002-11-03 14:21:07 InstController Action:0

Step DBCOMMONDBENV_NT_ORA could not be performed.

ERROR 2002-11-03 14:21:08 Main :0

Installation failed.

ERROR 2002-11-03 14:21:08 Main :0

Installation aborted.

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

Весь пакет инсталляции SAP R/3 состоит из нескольких компакт-дисков. Это означает, что при инсталляции нужно будет менять диски (обычно их меняет вручную оператор). Однако, если имеется достаточное дисковое пространство, можно скопировать компакт-диски на жесткий диск и информировать R3setup о пути доступа на этапе 1.

Установка РСУБД

Установка программного обеспечения РСУБД зависит от используемых базы данных и операционной системы. Выполнение R3setup включает только установку БД SAP. Руководства по установке для других поддерживаемых РСУБД описывают процесс для этих продуктов.

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

Действия по установке, выполняемые R3setup, по большей части прозрачны для пользователя, если только неожиданные ошибки не потребуют исправления. В таблице 4.4 содержится обзор наиболее важных действий во время установки центральной инстанции, выполняющейся в системе UNIX с базой данных Oracle. Этот обзор хорошо показывает сложность выполняемых задач. В зависимости от используемых операционной системы и РСУБД последовательность этапов и используемых инструментов может меняться. Однако тип и число этапов остаются такими же. Звездочка (*) указывает этапы, которые выполняются автоматически и обычно не требуют вмешательства оператора.

Таблица 4.4. Этапы инсталляции центральной инстанции с базой данных

Этап	Что происходит на этом этапе
Проверка по контрольному списку	Позволяет убедиться в соответствии перечисленным требованиям аппаратного и программного обеспечения
Подготовка системы вручную	Настройка параметров ядра UNIX Создание файловых систем Конфигурирование области свопинга Создание требуемых каталогов данных согласно руководству по установке: ► Каталог установки ► Каталоги базы данных ► Каталоги для инстанции SAP R/3
Запуск программы R3Setup	Запуск командного файла: insttool.sh
Запрос определенных параметров	Имя системы SAP R/3 Номер инстанции Каталог переноса Имя базы данных Настройки языка Настройки памяти Монтирование компакт-диска Каталоги для копий компакт-дисков
Проверка*	Дисковое пространство Существование каталогов
Коммуникация*	Служебные записи для диспетчера, шлюза и сервера сообщений Существующие служебные записи не изменяются
Пользователи и группы*	Создание пользователей и групп на уровне UNIX для базы данных и системы SAP R/3 Существующие пользователи и группы не изменяются
Каталоги*	Создание требуемых каталогов и настройка прав доступа Существующие каталоги и права доступа не изменяются
Разархивирование ПО R/3*	Запись ПО в соответствующие каталоги.
Профиль по умолчанию*	Создание системного профиля DEFAULT.PFL
Создание и настройка рабочей среды для пользователей*	Определение файлов профилей для ora<sid> и <sid>adm
Профиль инстанции	Создание профиля инстанции
Разархивирование ПО Oracle*	Запись ПО в соответствующие каталоги
runinstaller	Инсталляция ПО Oracle
Создание БД SAP R/3*	Проверка размера ожидаемых файлов данных БД Создание пустой БД Oracle Создание пользователей БД Импорт данных
Генерация статистической информации*
Создание временной лицензии R/3*
Запуск систем R/3*
Настройка вручную

Установка дополнительных инстанций SAP R/3 следует той же процедуре. Однако, поскольку область действия дополнительных инстанций меньше, такие инсталляции проще и могут выполняться быстрее.

4.4. Изменения для Web-сервера приложений SAP

4.4.1. SAPinst

Когда был введен Web-сервер приложений SAP в качестве основы для всех решений mySAP, таких как SAP R/3 Enterprise в качестве наследника SAP R/3 4.6С, процедура установки компонентов mySAP была передана от R3setup программе SAPinst (System Landscape Implementation Manager). Эта технология позволяет упростить установку всей системной среды, так как конфигурационная утилита заранее определяет требуемые параметры, которые можно использовать для автоматической установки.

Подобно R3setup , утилиту SAPinst можно запустить локально на сервере, который будет выполнять установку. Возможна также удаленная установка, которую контролирует графический интерфейс SAPinst. Этот интерфейс основывается на технологии Java, его использование требует среды разработки Java (JDK) или среды времени выполнения Java(JRE).

Установка компонентов с помощью SAPinst выполняется так же, как установка с помощью RSsetup: последовательность заранее определенных, повторно используемых шагов (см. рис 4.6).

Файлы XML управляют потоком инсталляции (см. таблицу 4.5). Данные журнала хранятся централизованно в файле sapinst.log.

Рис. 4.6. Инсталляция с помощью SAPinst

Таблица 4.5. Список наиболее важных файлов управления и журналов для SAPinst

Файл	Содержание
CONTROL.XML	Инструкции по установке компонентов SAP
KEYDB.XML	Описание потоков и статуса текущей инсталляции
MESSAGES.XML	Каталог текстов сообщений и присвоение сообщений номерам сообщений
DIALOG.XML	Описание диалога с пользователем
PACKAGES.XML	Список меток компакт-дисков
SAPINST.LOG	Файл журнала выполнения инсталляции
SAPINST_DEV.LOG	Подробный файл журнала выполнения установки

Инсталляция с помощью SAPinst состоит из следующих этапов:

1. Этап ввода

Требуемые данные для типа инсталляции — SID, номера инстанции, имени хоста и т.д. — запрашиваются у пользователя и записываются в файл описания KEYDB.XML (см. рис. 4.7 и листинг 4.4).

2. Этап обработки

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

Рис. 4.7. Ввод параметров

Различия между R3setup и SAPinst являются техническими и связаны со способом, которым каждая программа работает в процедуре инсталляции:

► В отличие от R3setup утилита SAPinst не завершает работу, когда происходит ошибка. Вместо этого она создает всплывающее окно, которое предлагает пользователю решить проблему и попробовать снова.

► SAPinst позволяет пользователям вернуться назад во время этапа ввода

Листинг 4.3. Фрагмент файла KEYDB.XML

- <strval>

<![CDATA[ WAS ]]>

</strval>

</fld>

- <fId name="WapsInstanceNumber">

- <properties>

<property name="GUIENG_USER_INPUT" value="GUIENG_TRUE" />

<properties>

- <strval>

<![CDATA[ 00 ]]>

</strval>

</fld>

- <fld name="WapsInstanceName">

- <strval>

<![CDATA[ DVEBMGSOO ]]>

</strval>

</fld>

- <fld name="WapsInstanceHost">

- <properties>

<property name="CHANGEABLE" value="YES" />

<property name="CONTEXT_PARAM_CHANGEABLE" value="YES" />

<property name="GUIENG_USER_INPUT" value="GUIENG_TRUE" />

</properties>

- <strval>

<![CDATA[ P6020792 ]]>

</strval>

</fld>

Файл sapinst.logсодержит запись для каждого выполненного шага.

Листинг 4.4. Запись об ошибке в файле журнала sapinst.log (см. листинг 4.2)

TRACE

showing dialog with index 33

TRACE

The controller is about to execute the dialog step

WebAs|ind|ind|ora|WebAs|620|0|SAPComponent|ind|ind|ind|ind|ind|0|Data-baseSystem|

ind|ind|оrа|ind|ind|0|DatabaseCommonParameters|ind|ind|ora|ind|ind|0|

dialogGetCommonParamsPostprocess

TRACE

CALLING

COraCommonParameters::computeDependantParametersAfterDialog

***** Transaction begin ************************************

TRACE

CDomainObjectCache:: readFromKeyDb: Reading from tGlobalDbParameters

WHERE dbSid = 'WAS'

ERROR 2002-11-05 12:49:22

MOB-06169 The Oracle Home name ' ' is not the name of

an Oracle Home directory registered on this host.

***** Transaction end *************************************

TRACE

JS Callback has thrown exception

ERROR 2002-11-05 12:49:23

EJS-00012 Error when executing script.

4.4.2. MCOD: Несколько компонентов на одной базе данных

Web-сервер приложений SAP 6.20 предлагает полную поддержку для установки нескольких систем mySAP на одной общей базе данных. Эта процедура позволяет упростить администрирование базой данных, однако она не сокращает существенно объем необходимых системных ресурсов — сумма требований отдельных компонентов определяет требования к размеру сервера.

SSD

Инсталляция системы mySAP в конфигурации MGOD выполняется почти так же, как инсталляция системы с выделенной базой данных. Единственное различие состоит в соглашении об именах для системы SAP и общей базы данных. Имя базы данных будет одинаково для всех систем SAP, используемых в инсталляции MCAD, но SID компонентов SAP различны. Инсталляция MCOD является интегральной частью SAPinst. Начиная с версии SAP R/3 4.6C SR2, можно устанавливать инсталляцию MCOD с помощью R3setup, и это можно делать вручную.

SAP планирует сделать эту конфигурационную возможность доступной для всех компонентов mySAP Business Suite и всех основных баз данных.

4.5. Доработка

После завершения инсталляции ПО SAP R/3 с помощью программ R3Setup или SAPinst нужно настроить некоторые параметры системы SAP R/3 и РСУБД. Этот этап называется доработкой (postprocessing).

Лицензионный ключ SAP

Особую важность имеет запрос лицензионного ключа SAP для новой системы. Лицензионный ключ является 24-символьным идентификатором (ID), который хранится в базе данных системы SAP R/3. Это значение генерируется из различных специфических для системы и сервера данных, так что он является эффективным только для текущей инсталляции. Если используется аппаратный кластер или резервная система, которая поддерживается текущей с помощью пересылки журнала и активируется с помощью идентификатора исходной системы при аварийной ситуации, то необходимо установить параллельно несколько лицензий. Чтобы сгенерировать лицензионный ключ SAP требуется системный аппаратный ключ; его можно найти на уровне операционной системы на компьютере, на котором выполняется сервер сообщений, с помощью следующей команды:

□ saplicense -get

Этот ключ и дополнительные данные необходимо послать компании SAP, которая сгенерирует лицензионный ключ и перешлет ее пользователю. SAP Service Marketplace является самым удобным местом, где можно выполнить запрос лицензионного ключа.

Чтобы активировать лицензию SAP, используется команда: saplicense -install; программа попросит ввести требуемые параметры. Начиная с SAP R/3 4.6C, можно выполнять следующие действия в SAP R/3 с помощью ►Licence administration (см. рис. 4.8):

► Вывод загруженных лицензий

► Загрузка дополнительной (или временной) лицензии

Рис. 4.8. Управление лицензией в системе SAP R/3

► Удаление лицензии

► Определение ключа оборудования

Лицензия активна с момента реализации; перезапуск SAP R/3 не требуется.

Установка клиентского ПО

Установка клиентского ПО может происходить в любое время, она не зависит от установки системы SAP R/3. Каждый из следующих вариантов использует различную процедуру:

► SAP GUI для Windows

► SAP GUI для Java

► SAP GUI для HTML

Для типичной установки клиента на ПК с Windows можно использовать локальную или серверную установку либо работать с программным дистрибутивом.

Клиентская конфигурация SAPLOGON

Конфигурация SAPLOGON (см. главу 1) как часть доработки системной инсталляции требует, прежде всего, чтобы были добавлены следующие свойства новых систем:

► Описание, которое можно выбрать произвольно

► Сервер приложений как имя хоста или IP-адрес

► Строку маршрутизатора SAP

► Системный номер

► В позиции Additional command line arguments (Дополнительные аргументы командной строки) можно определить кодовую страницу языка клиента. Можно также определить настройки для SNC (Secure Network Communications — Защищенные сетевые коммуникации) и скорость соединения. Задание низкой скорости соединения влияет на объем передаваемых клиенту данных. Такая настройка улучшает время ответа в установках в глобальной сети, хотя и за счет удобства пользователя.

► SAPLOGON предоставляет возможность выбрать язык вывода SAPLOGON. Можно также перейти прямо к конфигурационному файлу sap*.ini и при необходимости активировать трассировку клиента (см. рис. 4.9).

Рис. 4.9. Конфигурационные параметры SAPLOGON

Проверка инсталляции

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

Кроме того, важным моментом является смена паролей используемых по умолчанию пользователей(см. главу 8) для защиты новой системы SAP R/3 от неавторизованного доступа. Это можно сделать сразу, регистрируясь в системе как один из этих пользователей. Одной из первых задач системных администраторов после установки системы является создание своего собственного пользователя SAP R/3. С помощью этой учетной записи затем можно выполнить все другие административные задачи.

Импорт языка

Стандартная инсталляция SAP R/3 полностью интегрирует все зависимые от языка элементы на английском и немецком языке. После регистрации в системе пользователи могут выбрать английский или немецкий язык. Если система SAP R/3 требует дополнительных языков, то необходимо выполнить импорт языка. При этом импортируются требуемые и доступные языковые элементы предпочтительного языка в таблицы базы данных SAP R/3, поэтому необходимо иметь достаточно свободного дискового пространства для новых данных. Из 28 доступных в SAP R/3 4.6C языков только английский и немецкий доведены до конца. Не все экраны, пункты меню или элементы справки (F1) полностью переведены на 26 других поддерживаемых языков, а только отдельные части текста. В связи с этой ситуацией вместе с импортом доступных языковых модулей необходимо определить язык по умолчанию (который появляется, когда текст недоступен на местном языке) для дополнения не переведенных на целевой язык частей.

Начиная с SAP R/3 4.6C, техническая процедура импорта дополнительных языков перешла в Систему коррекции и переноса (CTS — Correction and Transport System) (см. главу 6), так что дополнительный импорт происходит при запросах переноса. Выберите ►Language management (см. рис. 4.10), чтобы начать импорт и дополнение языков. Если в системе SAP R/3 планируется использование языков, выводимых с помощью других кодовых страниц (например, английский, русский и китайский), необходимо сделать специальные настройки и принять меры для некоторых ограничений. SAP R/3 обладает полной реализаций Unicode, которая поддерживает все комбинации языков.

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

Рис. 4.10. Начальный экран языковой поддержки

Копирование клиента

Доработка инсталляции включает копирование клиентов (см. главу 7), необходимых для продолжения работы, с любого из используемых по умолчанию клиентов: 000 или 001.

Резервное копирование

После завершения инсталляции и доработки необходимо выполнить полное автономное резервное копирование вновь установленной системы. В системах Windows NT необходимо также сохранить записи реестра, для чего можно использовать команду rdisk. Чтобы гарантировать высокую доступность системы Windows NT, рекомендуется установить вторую операционную систему Windows NT на отдельном жестком диске. Если диск с операционной системой откажет, можно будет использовать вторую инсталляцию для запуска компьютера. В зависимости от используемого ПО резервного копирования можно также скопировать операционную систему вместе с SAP и записями базы данных. По крайней мере, необходимо создать дискету для аварийного восстановления системы, с помощью которой при аварийной ситуации можно будет запустить компьютер без операционной системы. Для этого также можно использовать команду rdisk.

По соображениям производительности и безопасности ни сервер базы данных SAP R/3, ни сервер приложений в средах Windows NT не должны действовать как первичный контроллер домена или как резервный контроллер домена. Однако задание ограниченных прав для определений пользователей и групп, требуемых для работы SAP R/3, смягчает важность этого замечания.

Инсталляция справки

Справка доступна в формате HTML и может выводиться в Web-браузере. Чтобы получить доступ к справке непосредственно из системы SAP R/3, необходимо сохранить ее в требуемом формате (стандартном или компилированном HTML) и сделать некоторые настройки в системе SAP R/3. Начиная с SAP R/3 4.6C, больше не требуется определять системные параметры. Настройки делаются с помощью ►Setting options for help (SAP Library). Записи в конфигурационном файле sapdoccd.ini могут переопределять системные настройки для доступа к справке.

Этап доработки, кратко рассмотренный здесь, включает несколько дополнительных шагов. Руководства по инсталляции описывают наиболее важные шаги. Хотя система SAP R/3 может функционировать, после того как эта работа выполнена, теперь необходимо определить ее роль в системной среде, инициализировать CTS, задать пользователей и т.д. Эти задачи описаны в следующих главах.

4.6. Советы

► Лицензионный ключ

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

► Изменения в управляющих файлах R3setup

Для изменения записей в управляющих файлах R3setup можно использовать любой текстовый редактор. Системы Windows для этой задачи предоставляют также R3Sedit.

► Изменения в управляющих файлах SAPinst

Для изменения записей в управляющих файлах SAPinst можно использовать любой текстовый редактор, но редакторы XML упрощают задачу. Можно найти полезные ссылки для загрузки пробных версий в Quicklink /sapinstfeedback в SAP Service Marketplace.

► Шаблоны R3setup для других целей

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

► Длина имени хоста

До версии SAP R/3 4.5B имя хоста могло иметь в длину только 8 символов, начиная с версии SAP R/3 4.6C, имя хоста может быть длиной 13 символов.

► Установка нескольких инстанций на одном сервере

Обе платформы, Windows и UNIX, поддерживают установку нескольких инстанций системы SAP, нескольких компонентов систем SAP или нескольких систем SAP на одном сервере. Однако необходимо отметить ограничения в отношении совместимости версий баз данных. Нельзя использовать одновременно 32-битное и 64-битное ядро.

► Улучшенные функции управления языками

После фундаментальных изменений в управлении языками в SAP R/3 4.6C, эти функции были усовершенствованы еще в большей степени:

 - Начиная с Basis 4.6D, установка языка и дополнительных возможностей может выполняться параллельно.

 - Начиная с SAP Web Application Server 6.10, можно обрабатывать относящиеся к языкам изменения в пакете поддержке с помощью ►Language management.

 - SAP Web Application Server 6.20 интегрирует относящиеся к языку данные на клиентов, отличных от 000 (отчет RSREFILL) в ►Language management.

4.7. Транзакции и пути доступа меню

Installation check: SAP Menu Tools • Administration • Administration • Installation check (SM28)

Language management: SAP Menu Tools • Administration • Administration • Language administration (SMLT)

License administration: Недоступно через стандартное меню SAP (SLIC)

Setting options for help (SAP Library): SAP Menu Tools • Accelerated SAP • Customizing SAP Reference IMG • General settings • Setting options for help (SR13)

User maintenance: SAP Menu Tools • Administration • User maintenance Users (SU01)

4.8. Дополнительная документация

Быстрые ссылки

► SAP Service Marketplace: псевдоним installation

► SAP Service Marketplace: псевдоним platforms

► SAP Service Marketplace: псевдоним instguides

► SAP Service Marketplace: псевдоним sizing

► SAP Service Marketplace: псевдоним quicksizing

► SAP Service Marketplace: псевдоним network

► SAP Service Marketplace: псевдоним sapinstfeedback

► SAP Service Marketplace: псевдоним ti

► SAP Service Marketplace: псевдоним licensekey

► SAP Service Marketplace: псевдоним mcod

► SAP Service Marketplace: псевдоним language

Указания SAP Service Marketplace

В таблице 4.6 представлен обзор важных указаний SAP Service Marketplace, связанных с установкой среды SAP R/3:

Таблица 4.6. Указания SAP по установке

Содержание	Указание
Helpful log files for Installation problems	331082
Configuration of the LDAP Connectors	188371
Directory integrations	448360
Windows language versions and SAP server products	427452
How many work processes should be configured?	39412
improving the performance of SAPLOGON	559711
Installation of multiple components in one database	388866
Several instances or systems on one UNIX computer	21960
Two SAP R/3 systems on one Windows NT computer	28392
SAP GUI 6.10/6.20	402189
Requesting additional resources	89305, 113795, 323263, 517085
Requesting a license key	94998

4.9. Контрольные вопросы

1. Какое утверждение правильно?

Для минимальной инсталляции SAP R/3

a. достаточно установки РСУБД.

b. требуется установка инстанции базы данных и центральной инстанции.

c. инстанция базы данных и центральная инстанция могут располагаться на одной системе.

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

2. Какое утверждение правильно? Соглашения по именам R/3

a. можно изменить с помощью средств операционной системы.

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

c. помогают пользователю быстро находить журналы и сообщения.

3. Какое утверждение правильно?

a. Использование систем RAID повышает надежность в случае отказа системы R/3.

b. Выполнять БД R/3 в системе RAID не рекомендуется, поскольку это может вести к потере производительности.

c. Системы RAID рекомендуется применять только для хранения областей данных БД R/3. Из соображений производительности не следует хранить области журналов на системах RAID.

ГЛАВА 5 СОЗДАНИЕ И НАСТРОЙКА СИСТЕМНОЙ ИНФРАСТРУКТУРЫ

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

После инсталляции лицензии R/3 и проверки выполненной инсталляции систему SAP R/3 можно считать установленной. Это означает, что доступны все необходимые данные и программы. Следующий шаг — задание всех технических параметров, специфических для заказчика. До выполнения этой работы никто не должен работать с системой. В частности, не рекомендуется вносить изменения в пользовательские настройки (Customizing). При подготовке только что инсталлированной системы R/3 особенно важно инициализировать систему коррекции и транспортировки (CTS — Change and Transport System). Это подготовит основу для взаимодействия с другими системами.

CTS состоит из следующих трех блоков (см. рис. 5.1):

► Организатор переносов (и организатор переносов — расширенное представление)

► Система управления переносами

► Инструменты переноса

Организатор переносов (Transport Organizer) является одним из наиболее важных инструментов для людей, работающий над проектом, которые имеют дело с настройкой и разработкой, и для системных администраторов, которые отвечают за переносы (подробнее о характеристиках и параметрах организатора переносов см. в главе 6).

Рис. 5.1. Компоненты системы коррекции и транспортировки (CTS)

Переносы

Система управления переносами (TMS — Transport Management System) создает основы для управляемого распределения в системной инфраструктуре новых системных настроек, разработок и модификаций, упакованных в пакеты переноса. Системный администратор отвечает за создание инфраструктуры переноса, которая может оптимальным образом отразить требования приложения. После начальной конфигурации можно использовать TMS для планирования, выполнения и контроля всей деятельности по импорту.

Программы tp и R3trans работают на уровне операционной системы для экспорта запросов переноса в файлы и импорта их в целевую систему. Во время установки системы создается каталог переноса с фиксированным путем доступа; этот каталог содержит все файлы CTS.

5.1. Инициализация системы изменений и переноса

На последнем шаге инсталляции для каждой системы SAP R/3 инфраструктуры должен быть определен глобальный или специфический для класса объекта параметр изменения системы (system change option). Объекты SAP R/3, которые являются здесь существенными, включают кросс-клиентские данные, такие как программы, шаблоны экранов, меню, таблицы и структуры, а также независимый от клиента параметр Customizing (см. главу 7). Параметр изменения системы определяется вручную в каждой системе SAP R/3. Необходимо сначала рассмотреть, должны ли эти объекты вообще быть модифицируемыми в системе SAP R/3. Термин «модифицируемость» означает возможность создания и адаптации новых объектов или дополнительной разработки объектов, предоставленных SAP, чтобы удовлетворить специальные требования заказчиков. Эти данные не должны изменяться в производственной рабочей среде. Модификации, допустимые в разрабатываемой системе, зависят от типа и области действия разработок. Например, являются ли допустимыми модификации объектов, которые предоставила фирма SAP?

Есть две возможности для задания параметра изменения системы: с помощью ►installation postprocessing (до версии SAP R/3 4.6C) или ►Transport Organizer • Tools Administration • Set system change option. Сначала делаются глобальные настройки, чтобы определить, допустимы ли модификации или нет. Объекты хранилища группируются в программные компоненты и присваиваются пространству имен. Система, в которой был создан объект, называется исходной системой (см. главу 6) объекта. Можно использовать эти настройки для более детального задания настроек модифицируемости. Объект является модифицируемым, только если:

1. Глобальный параметр изменения системы задан как «modifiable» (изменяемый).

2. Программные компоненты, которым принадлежит объект, имеют значение «изменяемый».

3. Пространство имен, в котором находится объект, имеет значение «изменяемое».

Таблица 5.1. Параметр изменения системы на уровне пространства и программных компонентов

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

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

Система SAP R/3 распознает следующие программные компоненты:

► Разработки заказчика (НОМЕ)

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

► Локальные разработки (без автоматического переноса: LOCAL) Включает все специфические объекты заказчика, которые не являются переносимыми (локальные).

► Общие для всех приложений компоненты (SAP_ABA)

Этот вариант позволяет делать модификации с помощью инструментов АВАР Workbench (Development Workbench) во всех прикладных компонентах, поставляемых компанией SAP.

► Логистика и бухгалтерский учет (SAP_APPL)

► Компоненты SAP Basis (SAP_BASIC)

Позволяет изменять все компоненты Basis с помощью доступных инструментов. Допускаются все компоненты из Development Workbench, АВАР Query и использование Function Builder.

► Трудовые ресурсы (SAP_HR)

Наиболее важными пространствами и разделами имен являются:

► Пространство имен заказчика

Все объекты без префикса, имена которых начинаются с Y или Z.

► Общее пространство имен SAP

Все объекты без префикса, имена которых не начинаются на Y или Z.

► Инструменты АВАР и GUI: префикс /1ВСАВА/

Допускается обработка объектов SAP только с помощью АВАР Editor, Screen Painter, и Menu Painter. Модификации функций не допускаются.

► Инструментальные средства разработки: префикс /1BCDWB/

Включает обработку объектов SAP с помощью всех инструментов в Development Workbench (АВАР Editor, Screen Painter, и Menu Painter) и модификации объектов репозитория (Repository). Модификации функций недопустимы.

► Группы функций блокировки: префикс /1BCDBWEN/

Включает функции SAP, которые обслуживают управление блокировками в SAP R/3. Если желательно задать параметр изменения системы таким образом, чтобы можно было модифицировать только объекты заказчика, нужно задать программные компоненты НОМЕ и LOCAL и пользовательский раздел имен как «модифицируемый».

Инициализация

Если система SAP R/3 устанавливается с компакт-диска с помощью R3setup или SAPinst, то инициализации CTS не требуется. Если система была создана как копия существующей системы, необходимо использовать ►Installation Postprocessing для регенерации базовых настроек CTS и для закрытия любых внешних запросов и задач в системе.

Для этого нужно выбрать Database copy or migration в ►Installation Postprocessing и выполнить эту функцию. Можно вывести и проанализировать журнал выполненных действий с помощью Extras • Display logs.

Рис. 5.2. Дополнительная обработка при системном копировании или миграции

5.2. Задачи, выполняемые системной инфраструктурой

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

Причина такой рекомендации кроется в различных требованиях, например к тестовой и рабочей системе:

1. Все изменения в репозитории влияют на среду SAP R/3 этапа выполнения, а следовательно — на рабочую систему.

2. Разработчики имеют доступ ко всем таблицам SAP R/3. Следовательно, в односистемной инфраструктуре они могут обращаться к рабочим данным.

3. Операции, связанные с разработкой, отрицательно влияют на производительность. Например, если программы для целей тестирования выполняются в режиме отладки, то рабочий процесс диалога в это время не может быть назначен другому пользователю. Учебные работы в одной системе R/3 также будут отрицательно влиять на ее функционирование и применение в других задачах.

Таким образом, рекомендуется распределять задачи по разным системам и переносить их с тестовой системы в рабочую только после проверки на корректность функционирования. Это называется транспортировкой, или переносом изменений. CTS используется для управления всеми модификациями и для разработки ПО в системах R/3, а также для переноса его между системами (см. рис. 5.1).

Двухсистемные инфраструктуры

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

В двухсистемной инфраструктуре CTS рассматривает систему разработки и тестирования как систему интеграции, а производственную систему — как систему консолидации.

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

Рис. 5.3. Двухсистемная инфраструктура

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

Трехсистемные инфраструктуры

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

► Система интеграции, играющая роль системы для разработки и специфических для заказчика настроек (Customizing)

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

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

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

Рис. 5.4. Трехсистемная инфраструктура

Соответствие означает следование следующим базовым правилам:

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

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

► Только проверенные модификации переносятся из системы консолидации в производственную систему. Никакие модификации не выполняются на самой производственной системе.

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

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

Многосистемные инфраструктуры

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

На рис. 5.5 показан пример многосистемной инфраструктуры. Точкой входа является центральная система интеграции, которая используется для разработки «международного» ПО. Подключенные к ней независимые системные инфраструктуры применяются для разработки ПО для конкретной страны.

Рис. 5.5. Многосистемная инфраструктура

5.3. Конфигурации системы управлении переносами

Система управления переносами (TMS — Transport Management System) реализует центральное административное представление настроек и переносов в системной инфраструктуре SAP. Можно скомбинировать системы SAP, чьи свойства переноса должны централизованно администрироваться в доменах переноса. Обычно несколько систем группируются в транспортный домен, а эти домены соединяются через пути переноса. Однако с административной точки зрения можно управлять несколькими такими группами систем в одном транспортном домене.

Чтобы отобразить предпочтительную системную среду в среде переноса, необходимо выполнить следующие базовые действия:

1. Решить, какие системы будут объединены в транспортном домене, чтобы можно было централизовано управлять их свойствами переноса. Если эти системы не присутствуют физически, когда моделируется инфраструктура переноса и отражается в TMS, можно сконфигурировать виртуальные фиктивные системы.

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

3. Определить, какие системы или клиенты будут соединяться при переносе и какую роль (интеграции, консолидации или поставки) они будут играть в группе переноса.

5.3.1. Транспортные домены

Контроллер транспортного домена (TDC)

Все системы, которые должны управляться через центральный TDC, конфигурируются в один транспортный домен. По техническим причинам идентификаторы систем, участвующих в транспортном домене, должны быть уникальными. Контроллер транспортного домена (TDC — Transport Domain Controller) является специальной системой транспортного домена, которая управляет всеми настройками TMS. Для поддержания согласованного представления всех систем в домене TMS обращается к конфигурации, расположенной на TDC; копия этой конфигурации распространяется всем членам домена. Поэтому все требуемые настройки, такие как определение путей переноса (см. раздел 5.3.2), делаются на TDC.

Коммуникации между TDC и другими системами SAP в домене основаны на соединениях RFC (Remote Function Call) (см. главу 13). Конфигурация TMS автоматически создает требуемые соединения RFC.

Контроллером транспортного домена должна быть выбрана отказоустойчивая и хорошо защищенная система SAP в системной инфраструктуре. Желательно, чтобы на ней была установлена последняя версия системы R/3. Таким образом, рабочая система и система обеспечения качества обычно лучше подходят для TDC, чем системы тестирования. Нагрузка, создаваемая TMS в среде R/3, невысока и не будет влиять на производительность.

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

Создание транспортного домена

При создании транспортного домена и его контроллеров нужно действовать следующим образом:

1. Конфигурация домена выполняется с помощью ►Transport Management System на клиенте 000 системы SAP R/3, которая рассматривалась первоначально в качестве TDC.

2. Система уведомит, что TMS еще не определена, и предложит имя домена на следующем шаге. Именем по умолчанию является «DOMAIN_<SID>», где «<SID>» является идентификатором системы, которая используется для выполнения конфигурации.

3. Выберите New Domain (новый домен) и введите имя и описание домена. Имя не должно содержать пробелов. После выбора имени домена его можно будет модифицировать только тогда, когда TMS будет полностью реконфигурироваться.

4. Сохраните введенную информацию.

Система, из которой создается транспортный домен, определяется контроллером домена (Domain Controller). Вся дальнейшая работа по конфигурации должна выполняться из этой системы на клиенте 000.

Теперь домен и его контроллер определены. Это определение можно проверить с помощью команды ►Transport Management System • Overview • Systems. Во время определения TDC, и позже, во время интеграции в домен дополнительных систем, система автоматически выполняет в фоновом режиме некоторые задачи для подготовки функций TMS:

► Данные конфигурации сохраняются в БД, часть данных сохраняется также в файле DOMAIN.CFG b подкаталоге bin каталога переноса на уровне операционной системы.

► Для системы R/3 создается пользователь TMSADM с типом communication (см. главу 8). Этот пользователь авторизован только для задач TMS (см. рис. 5.6).

► Создаются все необходимые RFC-соединения с другими системами.

Рис. 5.6. Авторизация пользователя TMSADM

Интеграция дополнительных систем

Чтобы интегрировать в домен дополнительные системы SAP R/3, выполните следующее:

1. Войдите в интегрируемую систему с клиента 000 и вызвать ►Transport Management System. Добавляемая система автоматически распознает, что текущая система еще не принадлежит домену. Если используется тот же самый каталог переноса (см. раздел 5.4), система анализирует конфигурационный файл (DOMAIN.CFG) и предлагает предоставленный домен. Можно изменить это предложение, если будет выбран другой домен или создан новый. Согласитесь с предложением или введите имя нужного домена. После сохранение введенных данных новая система готова к интеграции в домен.

2. На втором шаге TDC должен подтвердить интеграцию новой системы, чтобы она полностью интегрировалась в домен. Для этого перезапустите ►Transport Management System на TDC с клиентом 000 и выберите Overview • Systems. Новая система появится в списке со статусом: System waiting for inclusion in the transport domain (Система ожидает включения в транспортный домен). Выберите систему и затем SAP System • Approve, чтобы записать ее в домен.

Модификация конфигурации в TDC теперь закончена. Чтобы обеспечить согласованное представление конфигурации TMS, это изменение должно быть распространено на все другие системы в домене. Распространение модификаций всегда возможно сразу после этого действия или как часть группы. Можно инициировать распространение TDC через клиента 000 с помощью ►Transport Management System • Overview • Systems • Extras • Distribute and activate configuration.

Будет выведена подробная информация о любых ошибках, которые могли произойти во время конфигурации. Кроме того, монитор сигналов TMS содержит историю всех ошибок, включая заметку о возможных причинах и исправлениях. К монитору сигналов можно обратиться из ►Transport Management System через Monitor • TMS Alerts • TMS Alert Viewer. Функции области систем управления переносом также связаны с мониторингом сигналов Системы управления вычислительным центром (CCMS — Computing Center Management System) (см. главу 16); к этому монитору можно обратиться непосредственно или из ►Transport Management System через Monitor • TMS Alerts • CCMS Alert Monitor.

Резервный контроллер домена

Контроллер транспортного домена всегда должен быть доступен для модификаций конфигурации, таких как интеграция дополнительной системы. Чтобы обеспечить продолжение работы в случае отказа TDC, можно использовать резервный контроллер домена (BDC — Backup Domain Controller). Использование BDC позволяет переносить функции TDC на другую систему в том же домене. Для этого определите систему как BDC следующим образом: ►Transport Management System • Overview • Systems; выберите систему SAP system • Change; введите системный идентификатор в поле резервного копирования на вкладке Communication. Если BDC должен принять на себя задачи TDC, необходимо активировать TDC из списка систем на BDC с помощью Extras • Activate Backup Controller. По очевидным причинам это единственное действие по конфигурированию, которое не выполняется на TDC.

Можно удалить всю конфигурацию TMS из обзора системы с помощью Extras • Delete TMS configuration; можно удалить одну систему из обзора системы на TDC с помощью SAP System • Delete. После удаления некоторые настройки все еще присутствуют в неактивной форме и должны быть перезаписаны новыми настройками, если необходимо.

SAP R/3 3.1Н является минимальной версией, требуемой для интеграции системы SAP в транспортный домен.

Виртуальные системы

Чтобы смоделировать инфраструктуру переноса, в которой не все системы физически присутствуют или доступны, можно определить виртуальные системы в качестве фиктивных. Переносы, предназначенные для этих систем, собираются и могут быть немедленно импортированы, когда виртуальные системы заменяются реальными. Виртуальные системы можно создать с помощью ►Transport Management System • Overview. Systems • SAP systems • Create • Virtual system и вводя дополнительно систему коммуникации. Система коммуникации необходима, чтобы сделать доступными требуемые соединения RFC. Когда реальная система будет готова, необходимо будет удалить виртуальную замену из конфигурации и интегрировать в домен новую систему. SID новой системы должен быть согласован с SID виртуальной системы, чтобы можно было использовать заданные настройки.

Внешние системы

Кроме виртуальных систем, можно определить внешние системы. Это особый тип виртуальных систем, не существующих физически в транспортном домене. Такие системы полезны, если нужно:

► Передавать данные между различными транспортными доменами, т. е. из одной системы в систему в другом транспортном домене.

► Импортировать данные со сменного носителя или экспортировать их на него.

Существенное различие между виртуальной и внешней системами состоит в используемом каталоге переноса. Виртуальные системы используют стандартный каталог переноса своей коммуникационной системы; для внешних систем можно определить любой каталог. Аналогично созданию виртуальной системы внешняя система создается с помощью ►Transport Management System • Overview • Systems • SAP System • Create • External system. Система SAP, из которой происходит управление внешней системой SAP, задается как коммуникационная система; когда создается внешняя система, TDC предлагается в качестве коммуникационной системы. Необходимо также определить каталог переноса, который будет использоваться. В этом каталоге будут храниться все данные и журналы, требуемые для обмена с внешними системами.

На рис. 5.7 показаны внешняя система «QAS» в DOMAIN_A, которая будет использоваться в качестве фиктивной для реальной системы «QAS» в DOMAIN_B, и внешняя система «DEV» в DOMAIN_B, которая будет использоваться в качестве фиктивной для реальной системы «DEV» в DOMAIN_A. Обмен данными происходит через каталог trans_ext, который должен быть доступен из системы коммуникации, назначенной обеим системам.

Рис. 5.7. Внешние системы в качестве фиктивных в других доменах

Соединение доменов

Соединение доменов предоставляет другой метод соединения транспортных доменов. Каждый из двух доменов с TDC, выполняющим Basis Release 4.6C (как минимум), можно соединить с помощью прямой связи. Для этого используется ►Transport Management System • Overview • Systems • SAP System • Create • Domain Link для соединения с TDC в удаленном домене, который может быть доступен через сетевое соединение. TDC удаленного домена должен подтвердить соединение: будут определены все требуемые соединения RFC, и можно будет обратиться к системам удаленного домена. Центральный каталог переноса, созданный во время установки, используется по умолчанию для хранения всех требуемых данных переноса и журналов. На рис. 5.8 приведена структура дерева каталогов.

Рис. 5.8. Дерево каталога переноса

Следующий список описывает содержимое подкаталогов:

► bin

Конфигурационный файл TP_<domain>.PFL программы переноса tp (см. раздел 5.4) и конфигурационный файл DOMAIN.CFG домена.

► data

Файлы данных запросов переноса (см. главу 6).

► sapnames

Файл журнала для каждого пользователя CTS. Содержит действия по переносу запросов переноса пользователя.

► buffer

Один буфер импорта для каждой системы. Буферы содержат запросы, спланированные для импорта в эту систему, включая все рабочие шаги, требуемые для импорта.

► tmp

Временные файлы журналов и семафоры.

► log

Общие и специфические для запроса файлы журналов.

► cofiles

Управляющие файлы для запросов переноса. В файлы записываются объектные классы, требуемые действия по импорту и возвращаемые значения. Особый интерес представляет статус импорта запросов переноса в различных системах группы переноса.

Не каждой системе SAP необходимо иметь свое собственное локальное дерево каталогов. Чтобы сделать дерево каталога переноса доступным глобально, в большей степени подходит использование средств уровня операционной системы (share, mount и NFS link). Однако системы, подчиненные специальным ограничениям безопасности, могут иметь свой собственный локальный каталог переноса с подходящими правами ограниченного доступа. На рис. 5.9 показан поток переноса в трехсистемной инфраструктуре с общим каталогом переноса.

Транспортные группы

Системы SAP R/3, использующие общее дерево каталога переноса, образуют транспортную группу. Транспортный домен может включать в себя несколько транспортных групп. Если экспортирующие и импортирующие системы расположены в различных транспортных группах, очереди импорта должны быть синхронизированы перед импортом, а данные и управляющие файлы, необходимые для импорта, нужно перенести в каталог переноса целевой системы. Перенос можно инициировать из TMS.

5.3.2. Пути переноса

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

Рис. 5.9. Трехсистемная инфраструктура с общим каталогом переноса

Редакторы

Записи в системных таблицах организуют управление путями переноса и роль каждой системы. Во время конфигурации путей переноса можно использовать редактор иерархического списка или графический редактор для генерации этих записей. Наиболее важным типом требуемой информации является спецификация роли каждой системы (конфигурация, консолидация или поставка). Центральная конфигурация TMS означает, что необходимо предоставить информацию только один раз: информация затем распространяется на все участвующие системы. Следующее описание определения путей переноса предполагает, что пользователь зарегистрировался в системе SAP контроллера транспортного домена на клиенте 000 с достаточными административными полномочиями.

Чтобы упростить конфигурацию путей переноса, выберите конфигурацию (одно-, двух- или трехсистемную инфраструктуру) и усовершенствуйте ее необходимым образом.

Редактор списков

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

1. Выберите ►Transport Management System • Overview • Transport routes для вывода иерархического дерева соединений. Вначале все определенные системы и их конфигурационный статус доступны только в режиме вывода.

2. Перейдите к изменению режима с помощью Configuration • Display Change и воспользуйтесь Configuration • Standard configuration для выбора предпочтительной модели из следующих вариантов:

- Одна система

- Система разработки и производственная система

- Три системы в группе

В этой конфигурации каждой системе присваивается роль (см. рис. 5.10).

Рис. 5.10. Назначение систем

3. Сохраните записи. Записи таблицы, описывающие связи между системами, генерируются автоматически. Сохраните новые настройки с помощью Configuration • Check • Transport routes.

4. Распространите настройки с помощью Configuration • Distribute and activate.

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

Уровень переноса

На рис. 5.11 также показано, что между системами интеграции и консолидации создается уровень переноса (transport layer), «Z<integration_system>». Уровень переноса всегда описывает путь переноса, которым должны следовать данные из системы разработки. Этот путь называется также путем консолидации. Путь переноса из системы консолидации или поставки в другую систему поставки называется путем поставки. Путь поставки может существовать только в системной инфраструктуре, которая состоит как минимум из трех систем. Этот путь всегда предполагает присутствие предшествующего пути консолидации.

Кроме уровня переноса между системами интеграции и консолидации, в этих системах автоматически создается также дополнительный уровень переноса «SAP». Этотуровень переноса гарантирует, что модификации, сделанные в поставленных SAP объектах, можно импортировать в системы.

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

Рис. 5.11. Конфигурация системы (Редактор списка)

Графический редактор

Теперь выполним ту же самую конфигурацию с помощью графического редактора:

1. Графический редактор можно вызвать при выводе или обслуживании путей переноса с помощью Goto • Graphical editor. Верхняя область экрана выводит все системы, объединенные в транспортном домене, которые еще не использовались в определении путей переноса.

2. Можно использовать Configuration • Standart configuration для выбора требуемой системной инфраструктуры и присвоения ролей отдельным системам.

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

На рис. 5.12 показана та же самая конфигурация, что и на рис. 5.11.

Рис. 5.12. Конфигурация системы (Графический редактор)

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

Теперь можно определить путь переноса между системами с помощью Edit • Transport route • Crerate. Неправильные пути переноса можно удалять с помощью пункта Delete в том же меню. Запуск этой функции изменяет указатель в области вывода в карандаш, который можно использовать для вычерчивания линии между нужными системами. Для каждого пути переноса, определенного таким образом, необходимо определить, идет ли речь о консолидации (о переносе из системы интеграции в систему консолидации с подходящим уровнем переноса) или о поставке.

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

5.3.3. Дополнительное управление переносом

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

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

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

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

Дополнительное управление переносом можно активировать, задавая параметр СТС равным 1 в Transport Management System • Overview • Systems • SAP System • Change • Transport tool. Смешанные операции на основе системы и дополнительного управления переносом в одной инфраструктуре не допускаются.

5.3.4. Процедура утверждения QA

В инфраструктуре переноса, которая состоит как минимум из трех систем, системы консолидации и пути поставки для технической поддержки базовых правил (см. раздел 5.3), можно реализовать процедуру утверждения QA.

Запросы в системе QA могут разрешаться для импорта в производственную систему только после выполнения определенного числа подтверждающих действий.

Выберите систему консолидации, которая будет сконфигурирована как система QA, из ►Transport Management System • Overview • Transport routes. Пункт меню Edit • System • Change предоставит доступ к системным атрибутам выбранной системы. Задайте подтверждение в поле обеспечения качества (QA), а затем можно определить процедуру утверждения (см. рис. 5.13).

Рис. 5.13. Определение процедуры утверждения

5.3.5. Стратегия переноса

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

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

В System Attributes (см. рис. 5.14) можно выбирать из следующих вариантов:

► Массовые переносы, управляемые очередью

► Одиночные переносы, управляемые очередью

► Переносы, управляемые потоком выполнения

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

Рис. 5.14. Системные атрибуты

5.4. Программа управления переносами — tp

Программа tp используется на уровне операционной системы для управления переносом между системами и для его осуществления. С помощью таких средств, как программа уровня ОС R3trans и других интегрированных с R/3 средств, tp экспортирует данные из системы R/3 и импортирует их из других систем. Чтобы сделать всю требуемую информацию системной инфраструктуры доступной для tp, в подкаталоге bin каталога переноса во время инициализации управления переносом сохранится конфигурационный файл TP_<domain>.PFL. В нем уже существуют значения по умолчанию для всех значений параметров. Можно изменить и улучшить параметры, делая изменения в ►Transport Management System • Overview • Systems • SAP System • Change • Transport tool.

Рис. 5.15. Обслуживание параметров tp

Запрещенные или неизвестные значения параметров не порождают сообщение об ошибке — они просто игнорируются. Можно вывести реальные текущие значения (см. рис. 5.15), используя Goto • TP parameters.

Все действия программы tp регистрируются в подкаталоге log каталога переноса. По умолчанию все записи для запросов на перенос, использующих программу tp, содержат файл ALOG. В файле SLOG регистрируется время запуска, шаги выполнения работы, продолжительность и время завершения каждого переноса. Если нужно использовать имена файлов, отличные от заданных по умолчанию, то можно определить параметры alllog и syslog программы tp. Например:

□ alllog = ALOG$(syear).$(yweek)

записывает для каждого года и недели новый файл журнала в формате ALOG<YY>.<WWW>.

Кроме того, система хранит файл журнала ULOG<год>_<номер>, в котором записывается каждый выполняемый вызов tp с параметрами и именем пользователя операционной системы. <Год> — это две последних цифры года, а <номер> — текущий квартал года.

5.5. Советы

► Не используйте дополнительное управление переносом с виртуальной системой консолидации

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

5.6. Транзакции и пути доступа меню

Installation postprocessing: нет записи стандартного меню (SE06)

Transport Management System: SAP Menu • Tools • Administration • Transports Transport Management System (STMS)

Transport Organizer Tools: нет записи стандартного меню (SE03)

5.7. Дополнительная документация

Быстрые ссылки

SAP Service Marketplace: псевдоним swchangemanagement

Указания SAP Service Marketplace

В следующей таблице представлен обзор важных указаний, имеющих отношение к настройке инфраструктур переноса.

Таблица 5.2. Указания SAP по системе управления переносом

Содержание	Указание
System changeability and client control	40672
R3trans: Logging table modifications	163694

5.8. Контрольные вопросы

1. Какие из следующих утверждений о конфигурации TMS являются правильными?

a. В транспортном домене может существовать несколько транспортных групп.

b. Все системы, которые имеют доступ к общему каталогу переноса /usr/sap/trans, присваиваются одной транспортной группе.

c. В любое данное время может быть определен только один уровень переноса.

d. Уровень переноса неявно определяет путь к целевой системе.

2. Какие из следующих утверждений справедливы?

В многосистемной инфраструктуре операциями переноса можно управлять:

a. Только с той системы, в которую импортируются или из которой экспортируются данные

b. Централизованно с контроллера транспортного домена.

с. На уровне операционной системы с помощью программы tp.

d. В транспортном домене с каждой входящей в этот домен системы SAP R/3.

3. Что из перечисленного является путями переноса?

a. Прямой путь переноса

b. Косвенный путь переноса

с. Путь консолидации

d. Путь поставки

e. Обход

4. Какая программа уровня операционной системы используется для выполнения переноса?

a. R3load

b. R3INST

c. tp

d. dpmon

e. sapdba

ГЛАВА 6 ЛОГИСТИКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

6.1. Руководство по внедрению

Пользовательская настройка

SAP R/3 содержит стандартные решения почти для любых корпоративных бизнес-процессов. Термин «стандартное решение» следует интерпретировать гибко. Система SAP R/3 нередко интегрирует несколько вариантов процессов. При реализации SAP R/3 важно адаптировать ее к конкретным требованиям заказчика, модифицировав соответствующие параметры и установки. Это называется пользовательской настройкой (customizing). При настройке выбирается один из возможных вариантов. Для настройки особенно важно руководство по внедрению — Implementation Guide (IMG). Это руководство будет полезно не только для настройки, но и во время работы с другими важными средствами при администрировании.

Справочное руководство по реализации

Вместе с системой SAP R/3 компания SAP поставляет полное «Руководство по реализации» (SAP Reference IMG) для всех прикладных модулей SAP R/3. Структура IMG отражает иерархию прикладных компонентов системы SAP R/3. SAP Reference IMG содержит также все требуемые для реализации рабочие шаги и документацию. Обратиться к IMG можно через ►Implementation Guide • SAP Reference IMG.

Одна из основных задач компании-заказчика при планировании реализации SAP R/3 — это определение прикладных областей, подходящих для ее конкретных целей. Чтобы создать структуру всего процесса настройки, группы проектирования в компании рассматривают различные критерии и создают индивидуальные проекты настройки. Критерии выбора включают:

► Ограничения для страны

► Ограничения для компонента

► Ограничения для выбора вручную отдельных видов деятельности

Рис. 6.1. Фрагмент из SAP Reference IMG (базовая область)

IMG проекта

Начиная с SAP Reference, IMG можно создать IMG проекта для этих задач. Выполнение всех задач, описанных в IMG проекта, также называется «проектом» (project): система использует термины «проект» и «IMG проекта» как синонимы. SAP R/3 предоставляет пользователям большую поддержку во время выполнения индивидуальных проектов. Например, предлагаются интегрированные функции для планирования, поддержания статуса и документирования.

В качестве примера проекта рассмотрим настройку Basis Customizing (см. рис. 6.2). Можно использовать ►Project creation для создания новых IMG проектов, модифицирования существующих проектов или удаления проектов.

1. Выберите ►Project creation • Create • Project для создания нового проекта.

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

3. Выберите для проекта соответствующие страны и прикладные компоненты или сделайте выбор вручную в SAP Reference IMG.

4. Сохраните настройки и сгенерируйте IMG проекта.

Представления

Можно также присвоить каждому проекту представления деятельности; представления предоставляют дополнительную структуру в проекты настройки. Определение представления фильтрует деятельности ранее созданного проекта. Явное присвоение членов проекта задачам позволяет вводить в распределение работ служащих только те задачи, за которые служащие непосредственно отвечают. Этот тип назначений особенно полезен в следующих случаях:

► Создание проектов реализации

► Обновления

► Реализация изменений законодательства

Рис. 6.2. Создание IMG проекта

При создании представлений применимы следующие критерии (см. рис. 6.3):

► Необходимость деятельности

Всем видам деятельности, перечисленным в SAP Reference IMG, для классификации присваиваются атрибуты следующим образом:

Рис. 6.3. Создание представления для проекта

«must» (полная настройка SAP по умолчанию невозможна), «can» (используемую по умолчанию настройку SAP необходимо проверить и модифицировать, если необходимо) и «not required» (используемая по умолчанию настройка SAP отображает стандартную систему SAP). Виды деятельности также оцениваются как «critical» и «not critical».

► Выбор вручную в IMG проекта

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

► Настройка версии

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

► Изменения законодательства

Если необходимо реализовать в системе изменения законодательства, нужно создать представление проекта всех видов деятельности по настройке, которые задеты этими изменениями. Такой выбор использует также специфические атрибуты версии (law keys).

► Рабочий пакет ASAP

Значения атрибутов можно использовать как последний критерий для группировки видов деятельности настройки в стратегию ASAP.

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

Присвоение запросов на изменения

Если при создании проекта с помощью Project Creation используется вкладка Transport Requests для активации для проекта функций CTS (Change and Transport System — система изменения и переноса), то можно присвоить запросы на изменение проекту CTS. Можно собрать сгруппированные таким образом запросы и импортировать их для проекта с помощью Transport Management System (TMS).

6.2. Редактирование объектов

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

6.2.1. Запросы на изменения

Запросы пользовательской настройки

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

Запросы к инструментальным средствам

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

Запросы к инструментальным средствам содержат объекты репозитория (Repository) и независимой от клиента настройки. Эти запросы можно также смешивать; могут также присутствовать зависимые от клиента настройки. Однако это применимо только с тем ограничением, что все специфические объекты пользователя должны поступать только из одного клиента — клиента-источника запроса. Возможность переноса запросов к инструментальным средствам в модернизированные системы зависит от настроек для пути переноса в TMS (см. главу 5).

Локальный запрос на изменение

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

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

Номер запроса

Все задачи и запросы имеют уникальный идентификатор, состоящий из трехсимвольного имени системы SAP R/3, идентификатора-ключа «К» и последовательного номера из 6 цифр, например «ЕА1К905975». Каждый запрос на изменение имеет одного только владельца — руководителя проекта, который отвечает за администрирование запроса. При необходимости владельца можно сменить. Запрос на изменение нередко состоит из нескольких задач, каждая из которых принадлежит одному пользователю. Запрос на изменение можно рассматривать как проект, в котором разные пользователи имеют разные задачи (см. рис. 6.4). Допускается передача задачи другому пользователю.

Завершение задач и запросов

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

Импорт должен запускаться явно (см. раздел 6.3); во время экспорта импортируется версия объектов. То же самое применяется, даже если объекты системы источника были снова модифицированы — между разблокированием и импортом.

Рис. 6.4. Управление проектом

6.2.2. Редактирование запросов с помощью Transport Organizer (Организатора переноса)

До версии SAP R/3 4.6B запросы пользовательской настройки и к инструментальным средствам (Customizing и Workbench) обрабатывались отдельными инструментами: Customizing Organizer и Workbench Organizer. Начиная с SAP R/3 4.6C все запросы изменения и содержащиеся в них задачи можно редактировать с помощью Организатора переносов (ТО — Transport Organizer). Практический пример является простейшим способом иллюстрации работы с ТО.

В архивной области должны быть сгенерированы поддающиеся проверке архивные файлы. Для этого необходимо выполнить модификацию пользовательской настройки всех объектов архивации данных. Подобные модификации являются типичными для пользовательской настройки.

Создание запроса пользовательской настройки

Создать запрос пользовательской настройки можно двумя способами:

1. Внести изменение и позволить системе SAP R/3 сгенерировать запрос пользовательской настройки и задачу для изменения.

2. Использовать Организатор переносов (ТО) для создания запроса пользовательской настройки с включенной в него задачей. Затем внести изменение и явным образом назначить созданной ранее задаче.

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

Неклассифицированные задачи

Организатор переносов можно использовать также для создания неклассифицированных задач. Неклассифицированным задачам присваивают тип только тогда, когда они назначаются модификации.

Для данного примера можно использовать второй способ, о котором говорилось выше:

1. Вызовите ►Transport Organizer.

2. Выберите Request/Task • Create или сначала Display, а затем Request/Task • Create.

3. В качестве типа запроса на изменение выберите из списка Customizing Request.

Рис. 6.5. Организатор переносов (начальный экран)

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

5. Сохраните введенную информацию (Save). Теперь запрос пользовательской настройки создан.

На рис. 6.6 показан экран ввода данных для запроса на изменение. Поле Source client представляет клиента, назначенного запросу пользовательской настройки. Поле Target содержит имя системы SAP, на которую будет перенесен запрос пользовательской настройки после его разблокирования. В рассматриваемом примере это поле пустое, назначение будет сделано позднее.

Рис. 6.6. Данные запроса пользовательской настройки созданы

Рис. 6.7. Вывод всех запросов изменения

На рис. 6.7 показан режим иерархического вывода ТО. Здесь можно видеть запрос пользовательской настройки IE4K903522, созданный на клиенте 100 с владельцем D036044. Этому пользователю была присвоена задача IE4K903523. При необходимости можно изменить владельца запроса или задачи. Для создания других доступных запросу задач выделите запрос и выберите Request/Task • Create.

Назначение запросу пользовательской настройки

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

В данном примере мы хотим модифицировать настройки архивации. Для этого нужно выполнить следующие шаги:

1. Начиная с ►Implementation Guide • SAP Reference IMG, пройдите по структуре IMG, пока не будет достигнут Cross-Object Customizing Data Archiving и активирован пункт меню Create verifiable files (см. рис. 6.8).

Рис. 6.8. Модификация пользовательского запроса

2. После сохранения введенной информации выведется приглашение для назначения или создания нового запроса на изменение (см. рис. 6.9).

3. Выберите созданный запрос IE4K903522 и подтвердите выбор. В результате изменение будет назначено запросу пользовательской настройки. Только теперь изменения сохранены физически. Это означает, что модификации объектов могут стать постоянными, только если они записываются в запросах на изменение.

Рис. 6.9. Назначение запроса на изменение

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

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

1. В ►Transport Organizer выберите нужную категорию запросов и их статусов для вывода только требуемых запросов. Выберите Display.

2. Все задачи выбранных запросов пользовательской настройки должны быть завершены, т. е. разблокированы их владельцами. Если задача не разблокирована (как в данном примере), выберите соответствующую задачу (в нашем случае IE4K903523) и разблокируйте ее с помощью Request/Task • Release.

3. Затем будет предложено задокументировать содержание модификаций.

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

5. Когда все задачи будут разблокированы, аналогичным образом может быть разблокирован запрос пользовательской настройки. Выберите этот запрос (Customizing request), а затем Request/Task • Release и зафиксируйте свои действия в документе.

При разблокировании запрос экспортируется. Запрос пользовательской настройки можно также разблокировать для преобразования в запрос инструментальных средств, который будет разблокироваться и передаваться дальше. Такой подход позволяет собрать несколько запросов пользовательской настройки и позднее экспортировать их как группу.

Рис. 6.10. Разблокированный запрос: IE4K903522

Разработки и модификации

В инструментальной среде АВАР (Workbench) есть следующие инструменты для разработчиков:

► Средство просмотра репозитория (Repository Browser и Dictionary) применяется для разработки таблиц, создания индексов, доменов, кодов сопоставления и т. д.

► Редактор программ и построитель функций (АВАР Editor и Function Builder) служит для разработки программ и функций

► Screen Painter — для разработки масок экрана

► Menu Painter — для создания деревьев меню

► Средства тестирования

Эти средства применяются для разработки или изменения функций системы SAP R/3. Разработка функций системы 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

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

► D — импорт объектов приложения

► Е — основной экспорт

► G — генерация программ и экранов

► Н — импорт репозитория

► I — основной импорт

► L — импорт командного файла

► М — активация блокированных модулей

► P — тестирование импорта

► R — сравнение версий во время обновления SAP R/3

► Т — импорт записей таблицы

► V — создание идентификаторов версий для импортированных объектов

► X — экспорт объектов приложения

Эти журналы сохраняются в доступной для чтения форме на уровне операционной системы, а просмотреть их можно с помощью инструментальных средств ОС. Однако наиболее распространенным (и самым легким) способом просмотра этих журналов является использование ►Transport Organizer, выбирая нужный запрос и используя затем Goto • Transport Logs. Сначала выполненные шаги представляются в сжатой форме, которую можно раскрывать на четыре уровня. В случае с одним экспортом был создан файл журнала IE4E903522.IE4. Комментарии в данном файле содержат самую подробную информацию для файлов журнала системы SAP R/3. В следующем примере показан фрагмент этого файла журнала. Важная информация выделена жирным шрифтом.

Листинг 6.1. Фрагмент журнала экспорта

Name: IE4E903522.IE4

1 ЕТР199Х#######################################

1 ЕТР182 CHECK WRITEABILITY OF BUFFERS

1 ЕТР101 transport order : "IE4K903522"

1 ETP102 system : "IE4"

1 ETP108 tp path : "tp"

1 ETP109 version and release : "305.12.57" "46D"

1 ETP198

4 ETP201 Check target systems buffer: \\psasb009\sapmnt\trans\buffer\DUM

3 ETP203 Buffer "\\psasb009\sapmnt\trans\buffer\DUM" is writeable

……………………………

1 ETP182 CHECK WRITEABILITY OF BUFFERS

1 ETP110 end date and time : "20030223133946"

1 ETP111 exit code : "0"

1 ETP199X#######################################

1 ETP150 MAIN EXPORT

1 ETP101 transport order : "IE4K903522"

1 ETP102 system : "IE4"

1 ETP108 tp path : "tp"

1 ETP109 version and release : "305.12.57" "46D"

1 ETP198

4 ETW000 R3trans.exe version 6.05 (release 46D - 17.07.02 - 14:00:00).

4 ETW000 control file: \\psasb009\sapmnt\trans\tmp\IE4KK903522.IE4

4 ETW000 > #pid 811 on psasb009 (APServiceIE4)

4 ETW000 > export

4 ETW000 > file='\\psasb009\sapmnt\trans\data\R903522.IE4'

4 ETW000 > client=100

4 ETW000 > buffersync=yes.

4 ETW000 >

4 ETW000 > use comm 'IE4K903522'

4 ETW000 > R3trans was called as follow: R3trans.exe -w

\\psasb009\sapmnt\trans\tmp\IE4E903522.IE4

\\psasb009\sapmnt\trans\tmp\IE4KK903522.IE4

4 ETW000 date&time : 23.02.2003 - 13:40:08

4 ETW000 Connection to DBMS = ORACLE --- dbs_ora_tnsname = 'IE4' --- SYSTEM = 'IE4'

4 ETW000 trace at level 1 opened for a given file pointer

4 ETW000 ================== STEP1 ==========================

4 ETW000 date&time : 23.02.2003 -- 13:40:15

4 ETW000 function : EXPORT

4 ETW000 data file : \\psasb009\sapmnt\trans\data\R903522.IE4

4 ETW000 buffersync : YES

4 ETW000 client : 100

4 ETW000 Language :

ABCDEFGHIJKLMN0PQRSTUVWXYZ0123456789abcdefghijklmnopqrstuvwxyz

4 ETW000 Compression : L

4 ETW000 l.s.m. : VECTOR

4 ETW000 commit : 100000

4 ETW000 table cache : dynamic

4 ETW000

3 ETW673XUse Commandfile "IE4K903522"

4 ETW000 /* Conversion of archiving parameters */

4 ETW000 trfunction : 'W' (customizing transport )

4 ETW000 trstatus : '0'

4 ETW000 tarsystem : /TEST/

4 ETW000 user : D036044

4 ETW000 date : 23.02.2003 - 13:39:51

4 ETW000 1 entry from E070 exported (IE4K903522).

……………………………

4 ETW000 1 entry from E07T exported (IE4K903522).

4 ETW000 [developertrace.0] Sun Feb 23 13:40:18 2003

2201862 2.201862

4 ETW000 [developertrace.0] dbrclu3.c : info : my major

identification is 387318425, minor one 262100.

4 ETW000 DOCUTD ТА Т IE4K903522 exported

……………………………

3 ETW678Xstart export of "R3TRTABUARCH_PARAM" ...

4 ETW000 1 entry from ARCH.PARAM exported (100).

4 ETW679 end export of "R3TRTABUARCH_PARAM".

4 ETW000 IE4K903522 touched.

4 ETW000 IE4K903522 released.

4 ETW000 1776 bytes written.

4 ETW000 Transport overhead 56.6 %.

4 ETW000 Data compressed to 13.1 %.

4 ETW000 Duration: 3 sec (592 bytes/sec).

4 ETW000 0 tables in P-buffer synchronized.

4 ETW000 0 tables in R-buffer synchronized.

4 ETW690 "512" "512"

4 ETW000 Commit (1776).

4 ETW000

4 ETW000 Summary:

4 ETW000

4 ETW000 1 COMML exported

4 ETW000 1 COMMT exported

4 ETW000 1 DOCUT exported

4 ETW000 Totally 4 Objects exported

4 ETW000 Totally 1 tabentry exported

4 ETW000

4 ETW000 [developertrace.0] Disconnecting from ALL connections:

……………………………

4 ETW000 End of Transport (0000).

4 ETW000 date@time: 23.02.2003 - 13:40:19

1 ETP150 MAIN EXPORT

1 ETP110 end date and time : "20030223134033"

1 ETP111 exit code : "0"

1 ETP199 ##################################################

Код возврата имеет особую важность для администратора. Код возврата «О» показывает, что ошибок при переносе не было. Предупреждения, встречающиеся в отдельных строках журнала, помечаются символом «W», и возвращается код «4». Серьезные ошибки, приводящие к неполному переносу, помечаются символом «Е». В этом случае код возврата будет больше или равен «8». Файлы журнала показывают, где искать причину ошибки. Нужно устранить причину ошибки, а затем повторить экспорт. Например, причиной может быть проблема в базе данных. В случае отмены запроса на перенос он выводится в Организаторе переносов со статусом export not completed (Экспорт не завершен).

Сопровождающий файл и файл данных

Кроме файлов журнала, при экспорте генерируются файл данных и сопровождающий файл (cofile), содержащий метаданные об объектах в запросе. Файл данных и сопровождающий файл составляют фактические данные, подлежащие переносу. Они включают в себя все данные для импорта. Сопровождающие файлы хранятся в подкаталоге сопровождающих файлов cofiles, а файлы данных — в подкаталоге данных data дерева каталогов переноса. Имена этих файлов формируются следующим образом: □ <тип файла><номер запроса на перенос>.<SID исходной системы>

Тип «К» означает сопровождающий файл, a «R» и «D» — файлы данных. В этом примере были созданы сопровождающий файл K903522.IE4 и файл данных R903522.IE4.

6.2.4. Организатор переносов Transport Organizer (расширенное представление)

Расширенное представление Организатора переносов предлагает дополнительные функции переноса, кроме знакомых возможностей по управлению запросами пользовательской настройки (Customizing) и инструментальных средств (Workbench). Дополнительные возможности используют общий подход: они не следуют по предопределенному пути переноса.

Эти функции включают в себя:

► Перенос копий и перемещение оригиналов

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

- Простая копия объектов в другую систему; можно выбрать любую систему по желанию.

- Перемещение объектов без изменения класса или пакета разработки позволяет временно сохранить проекты разработки в другой системе. Система оригинала объектов изменяется на новую.

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

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

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

В Организаторе переносов можно создать запросы для переносов копий и перемещения оригиналов.

► Функции для оценки переносов клиента

Кроме возможностей предоставленных администрированием клиента (См. главу 7), здесь можно также просмотреть обзор выполненных переносов клиента.

► Создание списков объектов

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

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

► Администрирование поставок заказчикам от компании SAP или ее партнеров

Корректировки и исправления (патчи, заплатки), выпущенные SAP и ее партнерами, требуют специального администрирования, так как они содержат объекты в области имен SAP. Этот тип запроса на перенос нетруднораспознать по его имени — SAPK<номер>.

6.2.5. Инструменты переноса

Весь набор инструментов для работы с системой изменений и переноса (Change and Transport System — CTS) можно найти в меню ►Transport Organizer • Goto • Transport Organizer • Tools. В зависимости от предоставленных пользователям полномочий можно получить доступ к инструментам, которые могут быть опасными в использовании.

Все функции подробно описываются со списком параметров и могут запускаться при выборе меню Tool • Execurte.

Например, с помощью меню Administration • Display/change request attributes можно выявить или изменить атрибуты запросов на изменения или установить принудительные атрибуты. Например, можно определить, является ли назначение проекта запросу на перенос предварительным условием для выполнения запроса.

6.3. Импорт запросов на перенос

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

Пользователь может управлять очередью импорта всех систем в домене переноса и анализировать ее (см. главу 5), а также начинать импорт из любой конкретной системы с помощью ►Transport Management System • Overview • Imports.

На рис. 6.16 показаны 11 запросов для системы обеспечения качества и 22 запроса для производственной системы в очереди для импорта. Можно вывести более подробную информацию о типе и области действия запросов, выбирая требуемую систему.

Рис. 6.15. Инструменты CTS

Рис. 6.16. Обзор импорта в трехсистемной инфраструктуре

На рис. 6.17 показана очередь импорта для примера системы «ER3». Начиная с этого экрана, администратор может координировать все предстоящие операции по импорту. Ниже описаны наиболее важные рабочие шаги при обычной работе.

Рис. 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). В зависимости от настроек ранее импортированные отдельные запросы могут оставаться в очереди.

Статус и журналы

Чтобы следить заходом выполнения импорта, нужно использовать монитор импорта (Import Monitor). Выберите Goto • Import Monitor. Для вывода на экран журнала выполняемой программы tp выберите команду Goto • TP System Log.

Кроме того, можно удалить запросы переноса в очереди импорта с помощью функции Delete (выбор меню Request) или перенаправить (запросы переноса) в другую систему SAP R/3. Как и в случае с ТО, можно вывести содержимое, журналы и размер выбранных запросов переноса.

RDDIMPDP

Реальная работа по импорту выполняется на уровне операционной системы программами tp и R3trans (которую неявно вызывает tp). Эти две программы взаимодействуют с программой RDDIMPDP, выполняемой в R/3. Программа RDDIMPDP должна быть включена в расписание выполнения целевой системы на клиенте 000, a RDDIMPDP_CLIENT_<номер_клиента> включена в расписание на всех клиентах, которые получают переносимую информацию. Программы RDDIMPDP* управляются событиями и выполняются в фоновом режиме (см. главу 9). Они ожидают уведомления от tp, что прибыла переносимая информация. Соответственно каждый импорт требует свободного пакетного процесса. Если перенос зависает по неочевидной причине, проверьте, правильно ли функционирует RDDIMPDP.

6.4. Работа с программой управления переносом вручную

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

Файл параметров ТР_<домен>.РFL (в более старых версиях SAP R/3 называемый ТРРАВАМ) в подкаталоге bin каталога переноса управляет программой переноса tp. Прежде, чем использовать tp в первый раз, было бы неплохо проверить, что возможно соединение с выбранной целевой системой. Для этого можно использовать следующую команду:

□ tp connect <целевая система> pf = <полный путь доступа файла параметров>

Суффикс pf = ... позволяет использовать любой файл параметров по выбору.

Для добавления запроса в очередь импорта системы SAP R/3 используйте команду:

□ tp addtobuffer <запрос> <целевая система> pf = <пoлный путь доступа файла параметров>

Чтобы эта команда была выполнена успешно, файл данных запроса должен находиться в подкаталоге /data, а сопровождающий файл — в подкаталоге cofiles каталога переноса.

Для импорта отдельного запроса используйте команду:

□ tp import <запрос> <целевая система> рf = <полный путь доступа файла параметров>

Чтобы импортировать всю очередь текущей последовательности, используйте суффикс all:

□ tp import all <целевая система> рf = <полный путь доступа файла параметров>

Синтаксис

□ client = <номер клиента>

позволяет указать конкретного клиента.

Если клиент не задан, то данные копируются на клиента с номером клиента-источника данных. Если клиент, для которого определен импорт, в целевой системе отсутствует, то импорт отменяется. Выводится сообщение об ошибке.

Удаление устаревших запросов

В течение длительного периода разработки в каталоге переноса могут накопиться старые запросы переноса. Может потребоваться большая ручная работа и использование Организатора переносов, чтобы найти каждый запрос и затем вручную удалить устаревшие запросы. Вместо этого можно воспользоваться tp checkall, чтобы найти устаревшие запросы переноса, а затем удалить их с помощью tp clearold all. Временем жизни (периодом сохранения) данных, сопровождающих файлов и файлов журналов можно управлять с помощью параметров datalifetime, olddatalifetime, cofilelifetime и logfilelifetime программы tp. Файлы данных старше datalifetime перемещаются сначала в каталог olddata и удаляются постоянно при следующем вызове программы, когда будет превышено значение olddatalifetime.

6.5. Импорт пакетов поддержки и отраслевых решений

Переносы из CTS осуществляют также импорт пакетов поддержки для исправления ошибок в различных программных компонентах (см. раздел 5.1), отраслевых решений и подключаемых модулей для коммуникации с другими системами SAP, такими как SAP Business Information Warehouse (SAP BW).

Импорт происходит в клиенте 000; все другие клиенты имеют только функцию вывода.

Обновление инструментов установки

Для установки пакетов поддержки и подключаемых модулей требуются текущие версии инструментов установки. Соответственно первый шаг в работе с пакетами поддержки или подключаемыми модулями состоит в обновлении этих инструментов; обновление интегрируется в ►Support Package Manager.

6.5.1. Импорт пакетов поддержки

SAP регулярно поставляет пакеты поддержки с исправлениями ошибок и улучшениями производительности для всех доступных в SAP R/3 программных компонентов. В зависимости от продукта и версии Basis существуют различные типы пакетов для установки. Пакеты компонентов (СОР) SAP_BASIS (Basis Support Package), и SAP_ABA (Application Interface SP) существуют в каждой системе.

Установка состоит из следующих действий:

► Загрузка пакетов

► Обновление инструментов установки

► Определение очереди

► Установка очереди

► Подтверждение

К процедуре импорта можно перейти через окно ►Support Package Manager (см. рис. 6.18).

Рис. 6.18. Support Package Manager

Загрузка пакетов поддержки

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

► Скопировать пакеты из SAP Service Marketplace или с одного из регулярно доставляемых компакт-дисков поддержки в каталог переноса. Необходимо также распаковать там файлы. Затем можно загрузить пакеты в систему с сервера приложений с помощью Support Package • Load packages • From application server.

► Скопировать пакеты из SAP Service Marketplace или с компакт-диска на локального клиента, а затем загрузить их с клиента с помощью Support Package • Load packages • From Frontend.

► Запросить пакеты поддержки на SAPNet R/3 Frontend и загрузить их с SAPNet R/3 Frontend с помощью Support Package • Load packages • From SAPNet R/3 Frontend. В связи с требованиями к сети эта возможность поддерживается только для пакетов поддержки меньшего размера.

Самая последняя версия Support Package Manager также должна быть загружена аналогичным образом. На первом шаге можно установить ее с помощью Support Package • Import SPAM/SAINT Update.

Импорт очереди

He требуется обрабатывать каждый пакет поддержки индивидуально. Вместо этого можно определить очередь, которую Support Package Manager будет импортировать как группу. Такой подход существенно сокращает требуемые усилия. Пакеты только одного типа (например, пакеты поддержки Basis) могут импортироваться в очередь. Очередь должна быть полной: нельзя исключить какие-либо отдельные пакеты поддержки. Поскольку при определении очереди могут возникать конфликты, необходимо всегда проверять текущие заметки SAP, чтобы знать, какие пакеты можно устанавливать вместе в очереди.

Затем на следующем шаге можно установить очередь. Для импорта инструмент использует механизмы логистики программного обеспечения. Технически запросы переноса, которые видны в Transport Management System (TMS), импортируются с помощью команды tp. При возникновении проблем можно проанализировать их, используя журналы системы переноса и пакеты поддержки.

Во время импорта пакетов поддержки могут возникать конфликты, когда импорт редактирует объекты Data Dictionary, которые были модифицированы в системе. В этом случае будет предложено использовать утилиту Data Dictionary Comparison, что часто называется настройкой модификации SPDD в связи с используемой транзакцией. Отдел разработки, который выполняет модификации, обычно осуществляет сравнение. Аналогично может понадобиться сравнить после импорта импортированные объекты репозитория с модификациями репозитория (настройка модификации SPAU).

После успешной установки необходимо еще подтвердить статус. Дополнительные пакеты поддержки можно импортировать только после подтверждения.

6.5.2. Импорт дополнительных модулей

Для импорта дополнительных модулей используется ►Add-On Installation Tool. В этой транзакции все, что не принадлежит стандарту SAP, рассматривается как дополнительный модуль. Дополнительные модули включают отраслевые решения (Industry Solutions), подключаемые модули и установку Note Assistant в системах с версией Basis до 6.10 (см. главу 3). Можно использовать ►Add-On Installation Tool для установки и обновления дополнительных модулей. На начальном экране (см. рис. 6,19) необходимо сначала загрузить требуемые пакеты с помощью пункта меню Installation Package с клиента или с сервера приложений так же, как пакеты поддержки.

Рис. 6.19. Инструмент установки дополнительных модулей

После загрузки инструмент установки дополнительных модулей (Add-On Installation Tool) создает очередь, которую можно установить с помощью кнопки Continue.

Импорт происходит аналогично тому, как он происходит для пакетов поддержки. Здесь также может потребоваться настройка модификации. После установки необходимо проверить журналы с помощью Goto • Import logs, а затем подтвердить установку на последнем экране (экран 4/4) утилиты установки. Новые дополнительные модули или пакеты поддержки можно импортировать только после подтверждения.

6.6. Советы

► Деактивация массового переноса

В программе tp можно задать для параметра NO_IMPORT_ALL значение «1», чтобы запретить массовую обработку всех ожидающих операций импорта. Это стандартное значение параметра в стратегии переноса для индивидуальных запросов.

► Управление версиями

Обычно управление версиями выполняется только в системе источнике запроса переноса. При управлении версиями (versioning) создается новая версия объекта, когда он сохраняется в запросе переноса. Все старые версии видимы в истории объекта и могут сравниваться или откатываться, если необходимо. По умолчанию сохраняется только самая последняя версия в системах консолидации и доставки, и эта версия видна в истории версии. Если желательно использовать управление версиями в сложной инфраструктуре для отслеживания истории модификаций, можно задать такой режим с помощью параметра VERS_AT_IMP программы tp.

► Окно со сведениями о проблемах переноса, всплывающее при регистрации в системе

Для автоматического уведомления о переносах, которые завершились с ошибками, можно сконфигурировать всплывающее окно для всех пользователей или отдельных пользователей. Для этого перейдите в ►Transport Organizer • Settings • Transport Organizer и активируйте настройки для Display transport errors at logon для специфических настроек пользователя. Можно использовать ►Transport Organizer Tools • Administration • Global Customizing (Transport Organizer) для глобальной активации настроек.

► Проверка объекта при разблокировании или запросе

Чтобы помешать разблокированию синтаксически некорректных объектов в запросах, можно задать глобальную проверку объектов или для определенных пользователей. При такой настройке объекты, в которых были обнаружены ошибки, не могут быть разблокированы. Эти настройки можно сделать с помощью ►Transport Organizer • Settings • Transport Organizer или ►Transport Organizer Tools • Administration • Global Customizing (Transport Organizer).

6.7. Пути доступа транзакций и меню

Add-On Installation Tool: нет записи в стандартном меню (SAINT)

Extended Transport Organizer: SAP Menu • Tools • Administration • Transports • Transport Organizer (SE01)

Implementation Guide: SAP Menu • Tools • AcceleratedSAP • Customizing • Edit Project (SPRO)

Project creation: SAP Menu • Tools • AcceleratedSAP • Customizing • Project management (SPRO_ADMIN)

SPAU modification adjustment: SAP Menu • Tools • АBАР Workbench • Utilities • Maintenance Upgrade Utilities • Dictionary • Compare (SPDD).

Support Package Manager: SAP Menu • Tools • ABAP Workbench • Utilities • Maintenance Support Packages (SPAM)

Transport Management System: SAP Menu • Tools • Administration • Transports • Transport Management System (STMS)

Transport Organizer: SAP Menu • Tools • ABAP Workbench • Overview • Transport Organizer (SE09)

Transport Organizer Tools: нет записи в стандартном меню (SE03)

6.8. Дополнительная документация

Быстрые ссылки:

► SAP Service Marketplace: псевдоним spmanager

► SAP Service Marketplace: псевдоним patches

► SAP Service Marketplace: псевдоним ocs

► SAP Service Marketplace: псевдоним ocs-schedules

Указания SAP Service Marketplace

Таблица 6.1. Важные указания SAP о логистике программных средств

Содержание	Указание
FAQs on the Change and Transport System (CTS)	556734
Inactive Import of reports	361735

6.9. Контрольные вопросы

1. Какое утверждение правильно?

Перенос системы SAP R/3:

a. эквивалентен копированию клиента.

b. используется для обмена разработанным ПО и данными пользовательской настройки между разными системами SAP R/3.

c. применяется для обмена данными между различными клиентами в одной системе SAP R/3.

2. Какое утверждение правильно?

Классом разработки является:

а. определенная группа разработчиков

b. независимая от клиента единица

c. присваивается при изменении оригинала объекта SAP

d. присваивается уровню переноса

3. Какое утверждение правильно?

Изменения в объектах SAP:

a. должны регистрироваться с помощью OSS

b. не допускаются

c. настоятельно рекомендуются для реализации процессов компании-заказчика

4. Какое утверждение правильно?

Объект репозитория в системе SAP R/3:

a. автоматически блокируется при внесении разработчиком изменений в объект. При сохранении изменений блокировка автоматически снимается.

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

c. может изменяться, только если он присвоен соответствующему запросу на изменение. Модифицировать объект разрешается только пользователям, указанным в запросе на изменение.

ГЛАВА 7 АДМИНИСТРИРОВАНИЕ КЛИЕНТА

Классы данных

Данные в БД системы R/3 разделяются на отдельные классы. Некоторые данные действуют в масштабе всей системы. Большинство этих данных находится в репозитории R/3 (Repository). Помимо всего прочего, репозиторий содержит программы АВАР, модули функций и объекты словаря данных АВАР (Data Dictionary). Вносимые в их конфигурацию изменения также действуют в масштабе всей системы. Такой тип настройки конфигурации называется независимой от клиента настройкой. Другие данные зависят от клиента, т. е. видимы только одним клиентом. Зависимые от клиента данные включают в себя данные пользовательской настройки, данные приложения и данные пользователя. Между зависимыми от клиента группами данных существует тесная связь. На данные приложения и данные пользователя влияют любые зависимые от клиента пользовательские настройки. Таким образом, данные приложения обычно согласованы только со своей пользовательской средой. На рис. 7.1 показано взаимодействие между разными классами данных.

Клиент

Клиент — это независимо учитываемая бизнес-единица компании. Данное понятие может включать в себя независимый бухгалтерский баланс. Установка отдельных параметров в соответствии с требованиями бизнеса компании называется пользовательской настройкой (Customizing). Ее можно использовать также для задания параметров, действующих в масштабе всей системы, таких как выбор производственного календаря, конфигурации ActiveLink и т.д. Почти все технические параметры R/3 являются независимыми от клиента. Это означает, что клиенты в системе R/3 подходят, например, для реализации относительно независимых зон производства, но не вполне соответствуют целям реализации бизнес-процессов полностью независимых компаний.

Техническая реализация

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

Рис. 7.1. Классы данных в базе данных R/3 Стандартные клиенты

В стандартной системе SAP предлагает следующих клиентов с заранее заданной конфигурацией:

► 000 для целей администрирования и как шаблон для создания дополнительных клиентов

► 001 для целей тестирования и как шаблон для создания дополнительных клиентов (до версии R/3 4.6C)

► 066 для удаленных служб SAP

Во время поставки клиенты 000 и 001 идентичны по содержанию. Ни один из этих клиентов не должен использоваться для реальной производственной работы. Клиент 000 уже содержит используемые по умолчанию настройки и образцы записей и поставляется с самым последним образцом настройки при обновлении версий, реализации пакетов поддержки и т.д. Если в дополнение к немецкому и английскому импортируются другие языки, то связанная с языком пользовательская настройка, такая как единицы измерения, доступна только в клиенте 000. Поэтому клиент 000 не может рассматриваться для производственной работы. Все эти специальные настройки должны явно переноситься в других клиентов.

Стандартные пользователи

Пользователи и их конфигурации (например, пароли) являются зависимыми от клиента, т. е. пользователь может работать только на клиенте, которому присвоена его конфигурация. В стандартной системе клиенты 000 и 001 выделяются пользователям SAP* и DDIC с паролями «06071992» и «19920706». Клиент 066 имеет пользователя EARLYWATCH с паролем SUPPORT (см. таблицу 8.2.) В целях безопасности настоятельно рекомендуется изменять пароли стандартных пользователей сразу после установки.

7.1. Создание новых клиентов

Для работы с системой R/3 нужно создать клиентов со специфическими для компании настройками. Обычно для этого копируется существующий клиент, чаще всего клиент 000 или клиент с заранее заданной конфигурацией с другой системы R/3. Клиентов можно копировать в пределах одной системы R/3 или из одной системы R/3 в другую. В последнем случае используется специальный запрос на перенос. Создание собственного клиента — это один из первых шагов в настройке системы, а следовательно, одна из базовых функций в IMG (Implementation Guide, см. главу 6). SAP рекомендует создать клиента в системе разработки для пользовательской настройки. Завершив пользовательскую настройку данной системы, можно скопировать все параметры и настройки на клиентов подчиненных систем R/3, включая рабочую систему, но сначала полезно протестировать эти настройки в системе консолидации, что обеспечит единообразие настроек систем R/3 в системной инфраструктуре. Это, в свою очередь, окажет очень хорошую помощь при тестировании системной среды. Копирование клиента следует рассматривать лишь как первый этап его инициализации. Если после завершения процесса копирования в исходного клиента вносятся дополнительные изменения, их также нужно скопировать на целевого клиента. Для этого используется Система изменений и переносов (CTS — Change and Transport System). Создание и копирование клиентов — это типичная задача при создании системной инфраструктуры на этапе реализации R/3. Рис. 7.2 иллюстрирует данный процесс для трехсистемной инфраструктуры в хронологическом порядке. После копирования клиента наступает этап проверки, в ходе которого для нового клиента могут потребоваться дополнительное обслуживание и корректировки.

Клиент создается в два этапа. Первый этап: новый клиент становится известен системе R/3, а также выполняются некоторые важные базовые настройки. Второй этап: заполнение клиента данными. Только после этого клиент может функционировать.

Роль клиента

При планировании инфраструктуры системы SAP R/3 с самого начала необходимо учитывать, как различные виды деятельности должны быть разделены между системами и клиентами.

При создании клиента это отражается в присваиваемых ему ролях. Эти роли отражают функции клиента и присвоенные ему атрибуты:

► Рабочий клиент

Рис. 7.2. Пример для трехсистемной инфраструктуры

► Клиент для тестирования

► Клиент для пользовательской настройки

► Клиент для демонстрации

► Клиент для обучения и подготовки

► Эталонный клиент SAP

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

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

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

Опции изменения

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

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

Поэтому в элементах управления клиента можно определить настройки для изменения и переноса зависимых от клиента и общих объектов клиентов пользовательской настройки.

Зависимые от клиента объекты

Для настройки клиентов по обслуживанию и переносу зависимых от клиента объектов существуют следующие возможности:

► Изменения без автоматической записи

► Автоматическая запись изменений

► Никакие изменения не допускаются

► Изменения без автоматической записи, никакой перенос не допускается

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

Общие объекты клиентов

Управление использованием общих объектов клиентов (репозиторий и пользовательская настройка для всех клиентов) выполняется отдельно:

► Разрешаются изменения в репозиторий и независимые от клиента пользовательские настройки

► Не допускаются пользовательские настройки независимых от клиентов объектов

► Не разрешаются изменения в объектах репозитория

► Не допускаются изменения в репозиторий и общих объектах пользовательской настройки клиентов.

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

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

► Уровень защиты 0: нет ограничений

► Уровень защиты 1: запрещена перезапись

► Уровень защиты 2: запрещена перезапись, нет доступа извне

Клиент с уровнем защиты 1 или 2 не может выполнять роль целевого клиента при копировании клиента. Уровень защиты 2 предотвращает также внешний доступ к клиенту для сравнения. Система R/3 предусматривает специальный инструмент сравнения клиентов. Его можно использовать, например, для проверки идентичности пользовательской настройки двух клиентов и выявления различий. В частности, такая информация имеет важное значение при тестировании, когда тестовая среда должна быть идентична рабочей. Уровень защиты 2 предотвращает применение средств сравнения ►Customizing Cross-System Viewer для рассматриваемых клиентов. Такая форма защиты исключает несанкционированный доступ к параметрам пользовательской настройки клиента и его пользовательским данным. При необходимости можно ограничить использование нового клиента следующими областями:

► Ограничения при запуске процессов САТТ и еСАТТ

САТТ (Computer Aided Test Tool) —это автоматизированное средство тестирования. При выполнении операций САТТ указанные наборы тестов можно повторить несколько раз. В некоторых случаях это приводит к массивным изменениям базы данных, которые недопустимы, по крайней мере, в рабочих клиентах.

► Защита от обновлений SAP

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

Дополнительные замечания

В системе R/3 Enterprise благодаря возможностям еСАТТ (Extended САТТ), начиная с Basis версии Web Application Server 6.20, ограничения при выполнении САТТ и еСАТТ можно настраивать более детально.

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

1. Выберите ►Client maintenance. На экран выводится перечень доступных в системе клиентов (см. рис. 7.3).

2. Создайте здесь новую запись и определите атрибуты нового клиента в шаблоне обслуживания технических атрибутов клиентов (см. рис. 7.4).

3. Присвойте клиенту роль.

4. Выберите уровень возможности изменения клиента.

5. Определите область действия возможных изменений в независимых от клиента объектах для этого клиента.

6. Если необходимо, защитите клиента от копирования и сравнения с другими клиентами.

7. Сохраните изменения.

Рис. 7.3. Начальный экран технического обслуживания клиента

Рис. 7.4. Данные технического обслуживания

Теперь выполнены все настройки для нового клиента. Показанные шаги сначала приводят только к включению записи в таблицу Т000, описывающую атрибуты нового клиента. Новый клиент не содержит специфических для клиента данных и в частности не содержит данных пользователя. В системе R/3 жестко зафиксирован только пользователь SAP* с паролем «pass». Этот пользователь понадобится для регистрации во вновь созданном клиенте в начале процесса копирования. В процессе копирования этот пользователь заменяется спецификацией пользователя SAP* в клиенте-источнике, если используется профиль копии с основными данными пользователя.

На втором шаге для обеспечения работоспособности клиента требуется скопировать необходимые данные.

Подготовка копирования

Копирование клиента в продолжающемся проекте разработки или во время работы производственной системы создает некоторые риски, которые можно минимизировать при надлежащей подготовке.

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

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

► Непосредственно перед выполнением копирования необходимо принудительно удалить из системы пользователей, которые были ранее предупреждены, но которые, тем не менее, зарегистрировались в системе. До версии SAP R/3 4.6C можно также использовать транзакцию из Euro conversion (EWZ5) для блокирования пользователей.

► Убедитесь в том, что фоновые задания в клиенте источнике отменены, а внешние интерфейсы не выполняются.

7.2. Локальное копирование

Есть несколько методов заполнения данными вновь созданного клиента. Клиента можно:

► Создать в той же системе путем копирования другого клиента (локальное копирование)

► Создать копированием клиента с удаленной системы (удаленное копирование)

► Переносить клиента с какой-либо системы на целевого клиента с помощью запроса переноса (перенос клиента)

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

Профиль копирования

В соответствии со структурами данных в БД R/3 можно выбирать типы данных для копирования. Для этого в R/3 предусматриваются профили копирования. На рис. 7.5 показаны доступные в данный момент профили для копирования клиентов.

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

Рис. 7.5. Профили копирования, поставляемые SAP

Таблица 7.1. Профили копирования для локальных копий

Имя профиля	Описание
SAP_ALL	Все специфические данные клиента копируются в целевого клиента (исключение: документы изменения и локальные данные)
SAP_APPL	Аналогично SAP_ALL, но без основных данных пользователя
SAP_CUST	Специфическая пользовательская настройка клиента (включая профили авторизации) копируется в целевого клиента. Данные приложения удаляются, данные пользователя остаются
SAP_CUSV	Аналогично SAP_CUST, но также копируются варианты
SAP_UAPP	Аналогично SAP_ALL (не используется, начиная с R/3 Enterprise)
SAP_UCUS	Аналогично SAP_CUST, но также копируются основные данные пользователя
SAP_UCSV	Аналогично SAP_UCUS, но также копируются варианты
SAP_USER	Копируются пользователи, роли и профили авторизации

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

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

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

Метод выполнения локального копирования

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

1. Войдите в систему на только что определенном клиенте как пользователь SAP* с паролем «pass».

2. Убедитесь в том, что ни один пользователь не зарегистрирован на клиенте-источнике или целевом клиенте, и пошлите системное сообщение, чтобы объявить о предстоящем копировании клиента.

3. Выберите ►Local Client Copy.

4. Для выбора копируемых данных с исходного клиента используйте профиль (см. рис. 7.6). Если есть сомнение насчет области действия доступных профилей, проверьте содержимое, выбрав Profile • Display.

Рис. 7.6. Локальное копирование клиента

5. Скопируйте клиента в фоновом режиме, выбрав Schedule as background job.

6. С помощью ►Client copy log analysis можно контролировать текущий статус копии в любое время и анализировать журналы после выполнения копирования. В процессе копирования создаются подробные журналы.

Рис. 7.7. Подробное описание профиля SAP_ALL

Теоретически можно также скопировать клиента в приоритетном режиме, выбирая Start immediately; однако процесс копирования будет тогда автоматически выполняться текущей инстанцией. В фоновом режиме можно выбрать любую инстанцию системы R/3, предусматривающую фоновое выполнение. В зависимости от объема копируемых данных и возможностей оборудования выполнение этого процесса может занять несколько часов. Если процесс копирования выполняется в приоритетном режиме, процесс диалога блокируется до окончания копирования. Параметр инстанции rdisp/max_wp_runtime ограничивает время обработки для процесса диалога. Если транзакция превышает заданное время, то она отменяется и происходит ее откат. Если копирование выполняется в фоновом режиме, то можно выбрать подходящее время начала копирования, которое определяется в команде Schedule as background job.

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

Чтобы предварительно протестировать выполнение всей процедуры, используйте опцию Test run. Также доступны опции Resource check (Проверка ресурсов) и Simulation (Моделирование) (см. рис. 7.8).

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

Рис. 7.8. Выполнение теста удаленного копирования клиента

Ниже приведены фрагменты файла журнала копирования локального клиента в фоновом режиме. Копирование выполнялось на производственной системе со своими собственными данными пользователей. Особенно важная информация выделена жирным шрифтом.

Листинг 7.1. Фрагмент журнала локального копирования клиента

Client copy from " 15.07.2002 " " 17:30:45"

SYSID..................................PLU

SAP Release............................46С

Host...................................SLUPLU

User...................................SAP*

Parameter

Source client...........................100

Source client user master data .........100

Target client...........................600

Copy profile............................SAP_ALL

Table selection

Customizing data.........................X

with application data....................X

Initialize and re-create.................X

Change documents not copied

ADDR_CLIENTCOPY_SELECT_TABLES executed 25(0)

Entries transferred

Runtime 0 seconds

Exit program ADDR_CLIENTCOPY_SELECT_TABLES

successfully executed

SCCB_VARIANT_

CLIENTCOPY executed 4( 9.324) Entries transferred

Runtime 200 seconds

Exit program SCCB_VARIANT_CLIENTCOPY successfully executed

CLIENTCOPY_SELECT_TEXTAB executed 3(0)

Entries transferred

Runtime 0 seconds

Exit program CLIENTCOPY_SELECT_

TEXTAB successfully executed

table Inserts Delete Total Function Kbyte

Exluded from copy: STXB

Exluded from copy: STXH

Exluded from copy: STXL

Table BSEC not copied explicitly, copied as a cluster table

Table BSED not copied explicitly, copied as a cluster table

…………………………………

A000 0 0 0 COPY 0 0

A002 6 0 6 COPY 0 0

A003 516 0 516 COPY 12 1

…………………………………

WYT5 0 0 0 DEL. 0 1

WYT6 0 0 0 COPY 0 0

25D11 86 0 86 COPY 6 0

…………………………………

Exit program RSSOURSCO_FOR_CC successfully executed

Selected objects : 18.398

Edited objects : 17.937

Tables deleted : 461

Storage required (KB) : 2.172.391

Program run successfully.

Runtime (seconds) : 4.797

End of processing: 06:50:35

7.3. Удаленное копирование

Каждая система R/3 в многосистемной инфраструктуре выполняет свои четко определенные задачи. Поэтому, например, пользовательская настройка, обеспечение качества и продуктивная работа должны выполняться на разных системах R/3. Чтобы обеспечить идентичность изменений, вносимых в настройки и параметры систем R/3, можно использовать копирование клиентов системы, в которой вы работаете. Один из возможных способов сделать этот перенос данных предоставляет «удаленное копирование».

Примечание

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

Для связи между системами R/3 используются удаленные вызовы функций (RFC), поэтому необходимо создать RFC-соединение целевой системы с исходной (см. главу 13). Однако передача данных черезинтерфейс RFC происходит медленнее, чем при локальном копировании или переносе клиента с одной системы на другую. Если принимать во внимание одно лишь быстродействие сетевых соединений, то удаленное копирование всегда выполняется медленнее локального. Причем во время этой операции ни исходный, ни целевой клиент не должны использоваться для других работ. Кроме того, процедура удаленного копирования должна выполняться в фоновом режиме. Это позволит предотвратить блокирование процесса диалога. Длительное выполнение приводит к тому, что время работы процедуры копирования несколько превышает время, определенное для процессов диалога в системе R/3. Если копирование прерывается, его можно возобновить с того же места (когда активизирована соответствующая опция рестарта). Необходимо также отметить, что даже при фоновой обработке процесс RFC захватывает процесс работы диалога во время чтения таблицы на системе-источнике. Поэтому необходимо задать максимальное время диалога в исходной системе в зависимости от размера наибольшей таблицы.

Метод выполнения удаленного копирования

Единственное различие между процедурами локального копирования и копирования клиента с другой системы R/3 состоит в том, что в последнем случае необходимо RFC-соединение с этой системой. Для удаленного копирования клиента выполните следующие шаги:

1. Создайте в целевой системе нового клиента (см. раздел 7.1).

2. Войдите в систему на целевом клиенте как пользователь SAP* с паролем PASS.

3. Для выполнения запланированного копирования нужно определить RFC-соединение между двумя системами R/3 на исходном клиенте (см. главу 13).

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

5. Наконец, можно начать копирование в целевой системе. Для вывода соответствующей программы копирования клиента можно выбрать команду ►Remote client сору (см. рис. 7.9).

6. Выберите копируемые данные, используя профиль.

7. Выберите RFC-соединение, определяя Source destination. Имя исходной системы и клиент-источник задаются автоматически после выбора соединения RFC.

Рис. 7.9. Удаленное копирование клиента

8. Перед фактическим копированием протестируйте соединение RFC с помощью средства RFC System check. Кроме тестирования соединения систем R/3, проверяются версии R/3 и совместимость словарей систем.

9. Запустите копирование в фоновом режиме.

10. Проверьте состояние копирования в целевой системе.

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

Примечание

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

Профили копирования

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

Таблица 7.2. Дополнительные профили копирования для удаленного копирования клиента

Имя профиля	Описание
SAP_RMBC	Аналогично SAP_UCSV с добавлением общей для клиентов пользовательской настройки
SAP_RMPA	Аналогично SAP_ALL с добавлением общей для клиентов пользовательской настройки
SAP_RMPC	Аналогично SAP_CUSV с добавлением общей для клиентов пользовательской настройки

7.4. Перенос клиента

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

Примечание

При применении данного метода важно, чтобы на исходной и целевой системах использовалась одна и та же версия системы R/3. Как и для удаленного копирования, для переноса клиента словари обеих систем также должны быть совместимы. Если целевая система уже известна и возможно соединение RFC, то это условие можно проверить с помощью RFC system check, как и для удаленного копирования.

Метод выполнения переноса данных клиента с помощью экспорта клиента несколько отличается от процедуры локального или удаленного копирования.

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

2. Затем зарегистрируйтесь на клиенте-источнике исходной системы как пользователь, имеющий полномочия на выполнение запроса на перенос (не SAP* или DDIC).

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

4. Запустите экспорт с помощью ►Client export.

5. Как и при локальном/удаленном копировании, данные для копирования выбираются с помощью профиля данных (см. рис. 7.10). Однако в отличие от локальных и удаленных копий экспорт клиента можно использовать также для копирования независимых от клиента данных. Для этого также предусмотрены профили (см. таблицу 7.3):

Таблица 7.3. Дополнительные профили копирования при экспорте клиента

Имя профиля	Описание
SAP_EXBC	Аналогично SAP_UCSV с добавлением общей для клиентов пользовательской настройки
SAP_EXPA	Аналогично SAP_ALL с добавлением общей для клиентов пользовательской настройки
SAP_EXPC	Аналогично SAP_CUSV с добавлением общей для клиентов пользовательской настройки

6. Любая система, определенная в системной инфраструктуре, включая виртуальные или внешние системы, может быть целевой. Предполагается лишь, что R/3 на исходной системе имеет ту же версию. Этот метод поддерживает и онлайновое, и фоновое выполнение со всеми их достоинствами и недостатками.

7. После подтверждения выбора выводится уведомление, сообщающее, какие запросы на перенос созданы для данной задачи (см. рис. 7.11).

8. Проверьте журналы, созданные для выполнения копирования.

Для такого типа копирования данных клиента также создаются журналы. Представленный ниже файл журнала — это копия журнала экспорта клиента с профилем SAP_CUST.

Рис. 7.10. Экспорт клиента

Рис. 7.11. Информация о созданных запросах

Листинг 7.2. Журнал копирования для экспорта клиента

Client export from "10/03/2002" "03:56:14"

System ID............................ "KLU"

R/3 Release.......................... "46C"

Host................................. "SLUQAS"

User................................. SHAGEM

Parameter

Source client......................... "600"

Copy Profile.......................... "SAP_CUST"

Table selection

Customizing data...................... "X"

with application data................. " "

Initialize and recreate.......... "X"

With cross-client tables..............." "

"ADDR_CLIENTCOPY_SELECT_TABLES" executed " 25"(" 0") entries copied

Runtime " 0" seconds

Exit program "ADDR_CLIENTCOPY_SELECT_TABLES" successfully executed

"RKE_CC_EXCLUDE_TABLES" executed " 0"(" 0") entries copied

Runtime " 10" seconds

Exit program "RKC_CC_EXCLUDE_TABLES" successfully executed

"RKC_CC_EXCLUDE_TABLES" executed " 4"(" 0") entries copied

Runtime " 12" seconds

Exit program RKE_CC_EXCLUDE_TABLES" successfully executed

"RV_COND_RECORDS_TRANS" executed " 4"(" 1.046") entries copied

Runtime " 11" seconds

Exit program "RV_COND_RECORDS_TRANS" successfully executed

"SCCB_VARIANT_CLIENTCOPY" executed " 4"(" 5.573") entries copied

Runtime " 121" seconds

Exit program "SCCB_VARIANT_CLIENTCOPY" successfully executed

"CLIENTCOPY_SELECT_TEXTID_STD" executed. " 1" entries found

Runtime " 0" seconds

Exit program "CLIENTC0PY_SELECT_TEXTID_STD" successfully executed

"CLIENTTTRA_SELECT_TEXTID_

FORM" executed. " 6" entries found

Runtime " 0" seconds

Exit program "CLIENTCOPY_SELECT_TEXTID_STD" successfully executed

"CLIENTTRA_SELECT_TEXTID_FORM" executed. " 0" entries found

Runtime " 0" seconds

Exit program "CLIENTTRA_SELECT_TEXTID_STYL" successfully executed

Command file for "tp" is written under: "KLUKT00116"

For client transport, " 12.508" entries entered in

command file

Command file for "RSTXR3TR" is written under: "KLUKX00116"

For client transport, " 7" entries entered in

command file

Selected objects : " 30.961"

Program ran successfully

Runtime (seconds) : " 352"

Кроме перечня обнаруженных ошибок, журнал содержит имена запросов на перенос, которые были созданы для экспорта клиента. Кроме возможности использования ►Client Copy Log Analysis для копии клиента для определения статуса и прогресса операции, в этом случае необходимо также использовать для оценки результатов функцию Client из ►Transport Organizer (extended view). Журнал программы копирования клиента описывает только создание командных файлов для программы переноса tp. Программа переноса выполняет реальный перенос клиента. Журнал самого выполнения экспорта можно найти с помощью Организатора переноса. В листинге 7.3 приведен пример такого журнала.

Листинг 7.3. Журнал экспорта клиента программы tp

Directory \\SLUQAS\sapmnt\trans\log

Name: KLUEX00116.KLU1

ЕТР199Х########################################

1 ЕТР183 EXPORT PREPARATION

1 ETP101 transport order : "KLUKX00116"

Рис. 7.12. Экспорт клиента в Организаторе переноса

1 ЕТР102 system : "KLU"

1 ЕТР108 tp path : "tp"

1 ЕТР109 version and release : "305.12.42" "46D"

1 ETP198

2 EPU230XExecution of the export preprocessing methods for request "KLUKX00116"

4 EPU111 on the application server: "SLUQAS"

4 EPU138 in client : "000"

………………………

2 EPU232 End: Adapting the object directory for the objects of the request "KLUKX00116"

1 ETP183 EXPORT PREPARATION

1 ETP110 end date and time : "20021003160206"

1 ETP111 exit code : "0"1

ETP199X#################################################

1 ETP150 MAIN EXPORT

1 ЕТР101 transport order : "KLUKX00116"

1 ЕТР102 system : "KLU"

1 ETP108 tp path : "tp"

1 ЕТР109 version and release : "305.12.42" "46D"

4 ETW000 R3trans.exe version 6.05 (release 46D -10/18/01 -11:30:00).

=================================================

4 ETW000 control file: \\SLUQAS\sapmnt\trans\tmp\KLUKKX00116.KLU

4 ETW000 > #pid 4380 on SLUQAS (APServiceKLU)

4 ETW000 > export

4 ETW000 > file='\\SLUQAS\sapmnt\trans\data\RX00116.KLU'

4 ETW000 > client=600

4 ETW000 > buffersync=yes

4 ETW000 >

4 ETW000 > use comm 'KLUKX00116'

4 ETW000 R3trans was called as follows: R3trans.exe -u 1 -

w \\SLUQAS\sapmnt\trans\tmp\KLUEX00116.KLU \\SLUQAS\sapmnt\trans\tmp\KLUKKX00116.KL

4 ETW000 data&time : 10/03/2002 — 04:02:14

4 ETW000 active unconditional modes: 1

4 ETW000 Connected to DBMS = MSSQL SERVER = 'SLUQAS\KLU' DBNAME = 'KLU' SYSTEM = 'KLU'

4 ETW000 trace at level 1 opened for a given file pointer

4 ETW000 ====================== STEP 1 =====================

4 ETW000 date&time : 10/03/2002 - 04:02:14

4 ETW000 function : EXPORT

4 ETW000 data file : \\SLUQAS\sapmnt\trans\data\RX00116.KLU

4 ETW000 buffersync : YES

4 ETW000 client : 600

4 ETW000 Language : ABCDEFGHIJKLMN0PQRSTUVWXYZ0123456789abcdefghijklmnopqrstuvwxyz

4 ETW000 Compression : L

4 ETW000 l.s.m. : VECTOR

4 ETW000 commit : 100000

4 ETW000 table cache : dynamic

4 ETW000

3WETW129 transport request "KLUKX00116" has trstatus "D"

3 ETW673XUse Commandfile "KLUKX00116"

4 ETW000 /* client export texts */

4 ETW000 trfunction: 'M' (client transport)

4 ETW000 trstatus : 'D'

4 ETW000 tarsystem : PLU.600

4 ETW000 user : SHAGEM

4 ETW000 date : 10/03/2002 - 04:01:52

4 ETW000 1 entry from E070 exported (KLUKX00116)

4 ETW000 7 enties from E071 exported (KLUKX00116*).

………………………

4 ETW000 Disconnected from database.

4 ETW000 End of Transport (0004).

4 ETW000 data&time: 10/03/2002 - 04:02:16

4 ETW000 1 warning occurred.

1 ETP150 MAIN EXPORT

1 ETP110 end date and time : "20021003160216"

1 ETP111 exit code : "4"

1 ETP199 #####################################################

Примечание

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

Файлы данных, созданные в процессе экспорта клиента, образуют основу для импорта данных в другую систему R/3. В таблице 7.4 показаны файлы, созданные в каталоге переноса при завершении экспорта клиента.

Таблица 7.4. Важные файлы данных для импорта

Подкаталог	Имя файла	Значение
\data	RO<номер запроса>.<SID>	Данные, независимые от клиента
\data	RT<номер запроса>.<SID>	Данные, зависимые от клиента
\data	RX<номер запроса>.<SID>	Текст и формы
\cofiles	КО<номер запроса>.<SID>	Метаданные, независимые от клиента
\cofiles	КТ<номер запроса>.<SID>	Метаданные, зависимые от клиента
\cofiles	КХ<номер запроса>.<SID>	Метаданные для текста и форм

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

Для импорта этих данных в другую систему R/3 действуйте следующим образом:

1. Если исходная и целевая системы находятся в одном домене переноса, то в ►Transport Management System можно выбрать любой запрос на перенос, который принадлежит экспорту клиента. Другие запросы, ассоциированные с ним, будут автоматически импортироваться в правильном порядке.

Рис. 7.13. Импорт с помощью системы управления переносами

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

3. На уровне ОС перейдите в подкаталог /bin локального каталога переноса целевой системы и выполните команды:

□ tp addtobuffer <запрос> <целевая система>

и

□ tp import <целевая система> client<целевой клиент >

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

4. После реального импорта и чтобы избежать проблем авторизации, используя Систему управления переносами или вручную с помощью программы tp, необходимо адаптировать рабочую среду R/3 к текущему состоянию данных, вызывая ►Import editing как пользователь SAP* или DDIC. Заключительная обработка после импорта должна выполняться всегда. Во время заключительной обработки импорта в целевом клиенте не должно быть работающих пользователей.

5. Журнал импорта можно найти с помощью ►Transport Management System далее если импорт был инициирован непосредственно с помощью tp. Выполненная заключительная обработка перечислена в разделе ►Client copy log analysis.

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

Заключительная обработка

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

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

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

► Составьте расписание специфических для клиента фоновых заданий.

► Если используются логические системы (см. главу 13), то в непроизводственных системах можно уточнить имена логических систем после копирования клиента с помощью ►Conversion of logical system names.

► Если используется SAP Workflow, то необходимо привести в рабочее состояние используемые по умолчанию инструменты.

► Проверьте соединения интерфейсов для специфических настроек клиента и приведите их в рабочее состояние, если необходимо.

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

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

7.5. Специальные функции

Средства администрирования клиента предлагают некоторые специальные функции:

► Copy as of Transport Request (копирование как запрос на перенос)

С помощью опции ►Copy as of Transport Request изменения пользовательской настройки, записанные в запросе на перенос, могут переноситься между двумя клиентами в системе. Помимо списка объектов самого запроса также могут копироваться списки объектов неразблокированных задач в запросе. Сам запрос не нужно разблокировать. Записи в целевом клиенте перезаписываются или удаляются в зависимости от ключевых записей в запросе на перенос.

► Delete Client (Удалить клиента)

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

► Client comparison (Сравнение клиентов)

R/3 предлагает различные функции для сравнения пользовательских настроек двух клиентов в одной системе или в различных системах R/3, которые будут требовать коммуникации RFC между двумя клиентами. С помощью ►Customizing Cross-System Viewer можно сравнивать сложные рабочие среды пользовательской настройки, управляемые различными критериями. Настройка клиента «Уровень защиты 2: без перезаписи, без внешней доступности» не позволяет использовать Customizing Cross-System Viewer. Две любые таблицы можно сравнить с помощью ►Object comparison.

7.6. Советы

Копирование клиентов представляет собой критическую операцию, связанную с перемещением больших объемов данных. Вероятно, наиболее частой ошибкой является недооценка степени увеличения объема данных при копировании клиента. Если БД окажется слишком мала, то это приведет не только к остановке процедуры копирования, но и к невозможности продолжения работы системы (пока БД не будет расширена). Сначала с помощью тестовой проверки следует определить объем добавляемых данных и убедиться в том, что в БД достаточно места.

► Размер клиента

Результаты выполнения теста основываются на оценках, в частности, при определении ожидаемых требований к ресурсам. Чтобы помочь получить более точные представления о размере клиента в версии Enterprise, система R/3 предлагает программы отчетов RSTABLESIZE (см. рис. 7.14 и 7.15) и RSSPACECHECK (см. рис. 7.16), которые можно использовать для более точного реального оценивания на уровне таблиц. В версии R/3 4.x можно использовать процедуры YSTABSIZ и YKSPACEC, как сообщается в SAP Note 118823. Они не включаются в стандартную поставку.

Рис. 7.14. Определение размера с помощью RSTABLESIZE

Рис. 7.15. Результат определения размера

Рис. 7.16. Определение требований к памяти с помощью RSSPACECHECK

► Индексы

Иногда в БД на целевой системе отсутствуют индексы. Это может привести к дублированию записей в таблицах при перезапуске копирования (обычно система предотвращает такое дублирование), а процедура копирования будет остановлена. Проверьте непротиворечивость объектов БД в целевой системе, в частности, ее индексы. Используйте для этого ►Database Performance: Tables and Indices (см. главу 15).

► Копирование базы данных

Если клиент очень большой и должны быть скопированы дополнительные независимые от клиента данные, необходимо рассмотреть возможность копирования всей базы данных. Для этого РСУБД и операционная система в исходной и целевых системах должны быть совместимыми, в то время как возможны удаленное копирование клиента и перенос клиента между различными системными конфигурациями.

► Настройка

Используя при копировании клиента параллельные процессы или выполняя удаление, можно добиться значительного ускорения. Если определены серверные группы RFC (см. главу 13), можно активировать серверную группу для локального или удаленного копирования клиента и для удаления клиентов из соответствующей транзакции запуска с помощью Goto • Parallel processes. Параллельные процессы будут затем использоваться во время фазы реального копирования. Необходимо отметить, что только основной процесс рассматриваемой конфигурации будет выполняться в фоновом режиме, в то время как все другие параллельные процессы занимают диалоговые рабочие процессы. Последовательное планирование отдельных копирований клиента с помощью параллельных процессов предпочтительнее параллельного планирования нескольких копирований клиента (с различными исходными клиентами), которые не используют параллельные процессы. Невозможно выполнять несколько одновременных копирований одного клиента.

► Копирование поверх

Если необходимо перезаписать существующего клиента с помощью новой копии, предлагается сначала удалить клиента и затем запустить копирование, хотя копирование неявно удаляет все данные. В частности, при удалении больших таблиц при использовании Oracle может возникать переполнение сегмента отката. Лучше иметь дело с этой проблемой при выполнении удаления и затем, в случае останова, по крайней мере, часть данных будет удалена.

► Перезапуск экспорта клиента

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

► Копирование больших таблиц

Для очень больших таблиц можно улучшить производительность, удаляя вторичные индексы перед копированием клиента, а затем создавая их заново, чтобы избежать необходимости изменять индекс для каждой копируемой записи данных. Начиная с Web AS 6.20, настройку параметров для копии клиента можно реализовать с помощью программы отчетов RSCCEXPT. Однако при использовании этих возможностей необходимо быть осторожным. В частности, необходимо не забыть отменить настройки после окончания копирования клиента.

7.7. Транзакции и пути доступа меню

Client copy log analysis: SAP Menu • Tools • Administration • Administration • Client Administration • Copy Logs (SCC3)

Client export: SAP Menu • Tools • Administration • Administration • Client Administration • Client Transport • Client Export (SCC8)

Client maintenance: SAP Menu • Tools Administration • Administration • Client Administration • Client Maintenance (SCC4)

Conversion of logical system names: недоступно через стандартное меню SAP (BDLS)

Copy as per transport request: SAP Menu • Tools • Administration • Administration • Client administration • Special functions • Copy transport request (SCC1)

Customizing Cross-System Viewer: SAP Menu • Tools • Customizing • Customizing Cross-System Viewer (SCU0)

Database performance: Tables and indices: SAP Menu • Tools • Administration • Monitor • Performance • Database • Tables/Indexes (DB02)

Import editing: SAP Menu • Tools • Administration • Administration • Client Administration • Client Transport • Import Editing (SCC7)

Local client copy: SAP Menu • Tools • Administration • Administration • Client Administration • Client Copy • Local Copy (SCCL)

Object comparison: SAP Menu • Tools • Administration • Administration • Client Administration • Customizing Objects • Object Comparison (SCMP)

Remote client copy: SAP Menu • Tools • Administration • Administration • Client Administration • Client Copy • Remote Copy (SCC9)

Transport Management System: SAP Menu • Tools • Administration • Transport • Transport Management System (STMS)

Transport Organizer (extended view): SAP Menu • Tools • Administration • Transport • Transport Organizer (SE01)

7.8. Дополнительная документация

Указания SAP Service Marketplace

Таблица 7.5. Указания SAP по обслуживанию клиентов

Содержание	Указание
R/3 multi-client capability	31557
Copying large and productive clients (from Web AS 6.10)	489690
Copying large and productive clients (up to R/3 4.6D)	67205
Size of a client	118823
Parallel processes (up to R/3 4.6D)	212727
Parallel processes (from Web AS 6.10)	541311

7.9. Вопросы для контроля

1. Какое из следующих утверждений о клиенте R/3 корректно?

а. Параметры пользовательской настройки по сути не зависят от клиента.

b. Клиент в R/3 System — это независимо учитываемая единица компании.

c. Каждый клиент имеет собственные данные приложения.

d. Каждый клиент имеет собственные технические данные, независимые от других клиентов.

e. Каждый клиент имеет собственные таблицы приложения.

2. Какой метод копирования клиента предлагает система R/3?

a. Локальное копирование

b. Удаленное копирование

c. Процедуру обмена данными

d. Экспорт клиента

e. Резервное копирование данных

3. Какие данные можно копировать с помощью процедуры удаленного копирования?

a. Зависимые от клиента данные приложения

b. Зависимые от клиента определения таблиц

c. Данные, независимые от клиента

d. Все данные в системе R/3

ГЛАВА 8 ПОЛЬЗОВАТЕЛИ И ИХ ПОЛНОМОЧИЯ В СИСТЕМЕ R/3

Концепция пользователя — одно из основных понятий в системе защиты R/3. Для достижения необходимого уровня защиты администратор системы R/3 должен быть знаком с возможностями, которые предлагает концепция пользователей и подготовленным к реализации этой концепции.

8.1. Основные понятия

Пользователь

С точки зрения системы SAP пользователь является техническим идентификатором, с помощью которого выполняется некоторое действие. Идентификатору пользователя присваиваются свойства, которые сохраняются в главной записи пользователя (user master record). Пользователь может быть реальным физическим пользователем или техническим пользователем, который используется только для фоновой обработки.

Имя пользователя

Пользователь идентифицируется уникальным образом с помощью имени пользователя (user name), одновременно являющегося строкой символов, которую реальный пользователь использует для регистрации в системе и идентификатором, используемым внутри системы.

Наиболее важные свойства пользователя включают полномочия этого пользователя, которые присваиваются как профили (profiles). Администрирование и присвоение этих профилей является еще одной темой, рассматриваемой в данной главе.

В системе R/3 применяется собственная концепция пользователей. После инсталляции системы R/3 вначале доступны только суперпользователи SAP* и DDIC (см. главу 7). Можно использовать одного из двух этих суперпользователей для создания других пользователей. В предыдущих главах предполагалось, что используемые пользователи R/3 имеют полный набор полномочий в R/3, в частности, все полномочия для выполнения описываемых операций. На начальном этапе такой подход является допустимым, однако при этом создается существенный пробел в защите рабочих операций, который мы теперь и устраним.

8.2. Ведение пользователей

Использование главных записей

После инсталляции в системе R/3 доступен ряд стандартных клиентов и пользователей (см. главу 7). Пользователи всегда являются зависимыми от клиента, т. е. действительными только для клиента, где они были определены. Другим важным свойством пользователя является пароль, который должен вводиться при входе в систему (регистрации), и который можно изменить в любое время, включая регистрацию в системе. Кроме того, при входе в систему можно выбрать предпочитаемый для работы язык. Имя пользователя и присвоенные ему свойства составляют главную запись пользователя (user master record). Она включает в себя следующие группы элементов, которые также появляются на вкладках (см. таблицу 8.1) для управления адресами:

Таблица 8.1. Вкладки управления адресами

Вкладка	Элементы данных
Address (Адрес)	Данные адреса
SNC	Настройки защищенной сетевой коммуникации (SNC — Secure Network Communications), которые видны только в случае активной SNC
Logon data (Данные регистрации)	Пароль и период действия пользователя
Defaults	Используемые по умолчанию настройки принтера, языка регистрации и т.д.
Parameters (Параметры)	Зависящие от пользователя значения стандартных полей
Roles (Роли)	Присвоенные пользователю роли (до Basic Release 4.6B: Activity groups)
Profiles (Профили)	Присвоенные пользователю профили
Groups (Группы)	Присвоение пользователей группам для массового обслуживания
Personalization (Индивидуализация)	Индивидуальные настройки для объектов индивидуализации
License data (Данные лицензии)	Классификация (до Basic Release 4.6C: возможно только в режиме изменения с кнопкой Measurement Data)

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

8.2.1. Создание пользователей

Администрирование пользователей начинается с ►User Maintenance (см. рис. 8.1). Это меню содержит все функции для создания, изменения и удаления пользователей, а также для управления их свойствами.

Рис. 8.1. User Maintenance: начальный экран

Для определения пользователя надо ввести уникальное имя пользователя в поле User. В Basic Release 4.6C и более поздних версиях можно использовать поле Alias (псевдоним) для выбора пользователей с помощью дополнительного идентификатора, которые пользователи создают, например, из транзакций Интернет в области самообслуживания. В этом месте нельзя создать псевдоним. В следующем примере предполагается, что пользователь MUSTERMANN создан с помощью User names • Create или с помощью соответствующей пиктограммы.

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

Адрес пользователя

При создании пользователя MUSTERMANN выводится экран, аналогичный показанному на рис. 8.2, на котором можно ввести данные адреса пользователя. Технически на странице закладки Logon data необходимо поддерживать хотя бы фамилию пользователя и пароль. Необходимо ввести все известные адресные данные на тот случай, если возникнет необходимость контакта с пользователем.

Рис. 8.2. Определения адреса пользователя

Не требуется вводить один и тот же адрес для каждого пользователя. Можно определить ►Company Addresses и присваивать их пользователям.

Данные регистрации в системе

На вкладке Logon Data нужно определить пароль и тип каждого пользователя. В Basic Release 4.6C и более новых версиях необходимо также определять группу пользователя для новых пользователей. На рис. 8.3 показаны настройки для создания пользователя MUSTERMANN.

Пароль при вводе отображается в замаскированной звездочками форме. Тип пользователя определяет, в каком из следующих режимов он работает в системе R/3:

Рис. 8.3. Данные регистрации пользователя

► Dialog (диалоговый)

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

► Communication (коммуникация)

Пользователь с типом Communication может использоваться для бездиалоговой коммуникации между системами, такой как вызов удаленной функции (RFC, см. главу 13). Такому пользователю не разрешается регистрироваться в системе R/3 или начинать диалоговую обработку.

► System (система)

Пользователь с типом System может использовать бездиалоговую коммуникацию в системе и для фоновой обработки. Общие настройки для периода действия пароля неприменимы для этого типа пользователей. Регистрация в диалоговом режиме невозможна.

► Service (служба)

Пользователь с типом Service является диалоговым пользователем, который доступен для большой анонимной группы пользователей, например для доступа через Интернет Transaction Server (ITS). Для этого типа пользователей не выполняется никакой проверки окончания срока действия или начальных паролей, и явно разрешена множественная регистрация. Однако по соображениям безопасности необходимо только назначать таких пользователей с большой осторожностью и с ограниченными полномочиями.

► Reference (ссылочный)

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

Пользователь MUSTERMANN определен как диалоговый пользователь. Соответственно не существует никаких ограничений на использование системы R/3, которые связаны с типом пользователя.

Группа пользователей

Группа пользователей служит для документирования и получения технической информации, помогает координировать назначение полномочий и обслуживать данные пользователей. Пользователь в одной группе может обслуживать данные пользователя в другой группе, только если имеет на это явные права. Необходимо ввести группу пользователей на вкладке Logon data (Данные регистрации); пользователь может добавить дополнительные группы пользователей на вкладке Groups. Кроме того, организация пользователей в группы облегчает массовые изменения пользователей (►Mass Change).

Группа пользователей SUPER вначале является единственной группой, уже определенной в системе R/3. Эту группа необходимо использовать для всех пользователей, которые имеют сходные полные полномочия в системе. Логическое назначение пользователя группе позволяет судить о его полномочиях и прикладных областях. Для создания и обслуживания групп пользователей с помощью инструментальных средств выберите команду Environment • User Group или используя ►User Group. Например, создайте группу MM, в которую можно будет позднее включить пользователей прикладной области Materials Management. Это позволяет определить администратора пользователей, который может управлять пользователями только в этой группе.

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

Вкладка Defaults

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

Вкладка Parameters

Вкладку Parameters можно использовать для определения зависящих от пользователя значений по умолчанию для часто используемых полей ввода. Пользователи могут настроить эти данные самостоятельно с помощью пункта меню ►Own Data (см. раздел 8.4).

SNC

Если используется защищенная сетевая коммуникация SNC (в противном случае вкладка не выводится), то можно использовать вкладку SNC для определения имени, которое используется для аутентификации пользователя во внешнем продукте системы безопасности.

Personalization

Пользователи могут вводить индивидуальные настройки для объектов персонализации на вкладке Personalization. Объекты персонализации должны быть предопределены и реализованы в прикладном компоненте, чтобы их можно было здесь выбрать. Вкладка и все интерфейсы доступны уже в Basic Release 4.6C, в то время как стандартные объекты персонализации, которые можно настраивать таким образом, включены в версию Release 6.10 и более новые.

Вкладки Roles (до Basic Release 4.6B: Activity groups) и Profiles используются для присвоения пользователю требуемых полномочий. Этот процесс более подробно описан ниже.

8.2.2. Лицензионные данные

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

Реальное измерение выполняется с помощью ►System Measurement или ►License Administration Workbench для более сложных системных инфраструктур (т.е. Service Data Control Center (SDCC) в SAP Web AS и более поздних версиях).

Правила классификации и измерения зависят от конкретной версии и контракта и описаны подробно во «Введении в измерение системы».

8.2.3. Изменения пользователей/массовые изменения

Все описанные в предыдущих разделах данные можно снова изменить позже в таких же транзакциях. Одновременное изменение нескольких пользователей может быть крайне трудоемким. К счастью, для этого существует специальная функция ►Mass Change, которая позволяет создавать и выполнять большинство изменений при администрировании пользователей для выбранного множества пользователей.

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

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

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

8.2.4. Защита имени входа и пароля

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

► Первые три символа имени пользователя не могут появляться в той же последовательности в любом позиции идентификатора пользователя.

► Пароль не может совпадать с PASS или SAP*.

► Пользователи могут изменять свои пароли только один раз в день.

Обзор возможных параметров профилей и рекомендуемых настроек представлен в «Руководстве по защите данных для SAP R/3» и «Руководстве по безопасности SAP». Некоторые из наиболее важных параметров профиля для защиты пароля описаны ниже:

► login/min_password_lng

Определяет минимальную длину пароля (минимум 3; максимум 8 символов)

► login/password_expiration_time

Определяет допустимый период действия паролей в днях

► login/disable_multi_gui_login

Управляет возможностью многократной регистрации одного и того пользователя

В качестве альтернативы регистрации с помощью пароля можно реализовать также регистрацию с помощью Single-Sign-On (SSO). С помощью этого метода пользователь регистрируется в системе безопасности, используя имя пользователя и пароль только один раз. Оттуда данные регистрации пересылаются как маркер регистрации или сертификат в другие системы, где регистрируется пользователь; дополнительная аутентификация больше не требуется. При использовании SSO требуется использование защищенной сетевой коммуникации (SNC).

8.2.5. Стандартные пользователи

Среди идентификаторов пользователей стандартные пользователи SAP* и DDIC (называемые также суперполъзователями) играют специальную роль. SAP* и DDIC создаются автоматически в каждом клиенте системы R/3 (см. таблицу 8.2). SAP* обладает всеми полномочиями в системе R/3. Пользователь DDIC обладает всеми полномочиями для управления репозиторием R/3 (см. главу 7). Для суперпользователей некоторые компоненты системы изменений и переноса (CTS) будут вызываться только в режиме вывода, чтобы избежать пользовательских разработок с этим идентификатором.

Таблица 8.2. Стандартные пользователи и их предопределённые пароли

Клиент	Пользователь	Стандартный пароль
000	SAP*	06071992
000	DDIC	19920706
001	SAP*	06071992
001	DDIC	19920706
066	EARLYWATCH	support

Одним из первых действий после инсталляции является защита этих пользователей и предотвращение неавторизованного доступа к системе с помощью изменения используемых по умолчанию паролей. Рекомендуется также изменить стандартный пароль «SUPPORT» пользователя EARLYWATCH клиента 066. Однако пользователь EARLYWATCH имеет полномочия вывода только для функций мониторинга производительности, поэтому он создает только небольшой риск для безопасности. В отличие от EARLYWATCH пароли пользователей SAP* и DDIC должны храниться с большими предостережениями; однако необходимо гарантировать, что они будут немедленно доступны в случае срочной необходимости.

8.3. Назначение полномочий

Распределение ответственности

Создание пользователя — это одна из задач системного администратора R/3 или администратора пользователей. Полномочия определяются, исходя из того, какие действия должен выполнять пользователь конкретного типа или группы. Иногда задачи назначения полномочий возлагают на другое лицо — администратора полномочий. Рекомендуется распределить эти обязанности хотя бы между двумя лицами, что позволит свести к минимуму риск защиты. Если пользователь имеет права на создание новых пользователей и полномочий, то он может предоставить себе все полномочия на системе R/3 и получить неограниченный доступ к данным. Этого можно избежать, если разделить эти обязанности между несколькими лицами. Обслуживание полномочий может быть обязанностью исключительно отделов пользователей или осуществляться в тесном сотрудничестве с ними. Относительно назначения полномочий существует две различные точки зрения. Для пользовательских отделов основным приоритетом является деловая активность — действия, разрешаемые или запрещаемые пользователю. Для администратора R/3 основной приоритет заключается в технических аспектах назначения полномочий и управления ими. Системный администратор не может решить, в каких полномочиях (в плане бизнеса) нуждается пользователь. Поэтому в следующих разделах рассказывается о технических аспектах назначения полномочий.

Полномочия пользователя — один из наиболее важных атрибутов, контролируемых администратором. Как и в любом другом ПО, назначение полномочий в R/3 имеет две стороны. Область деятельности пользователя следует максимально ограничить — она должна определяться исключительно выполняемыми им задачами. С другой стороны, пользователь должен обладать всеми правами, необходимыми ему для выполнения своих задач. Администратору нужно выбрать компромисс между тем и другим. Полномочия в R/3 — это сложная система индивидуальных прав и полномочий групп пользователей. Она допускает разные уровни настройки.

8.3.1. Обзор проверки полномочий

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

Концепция роли

Полномочия присваиваются пользователям как роли (до Basic Release 4.6B называвшиеся группами деятельности). Полномочия объединяются в группы как роли и вводятся в главные записи пользователей. В этом контексте роль является описанием задания, которое может быть присвоено различным пользователям. Кроме полномочий, роли содержат также определение меню пользователя (что описано подробнее в контексте обслуживания роли) и рабочие потоки.

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

Рис. 8.4. Двухэтапная проверка полномочий

В идеале администратор должен только выбрать одну из предопределенных ролей и присвоить ее пользователю. Затем во время сравнения пользователей (см. раздел 8.3.8) полномочия будут записаны в соответствующие контексты пользователя как профили.

8.3.2. Полномочия и объекты полномочий

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

Классы объектов

Число объектов авторизации в системе R/3 весьма значительно, что связано с диапазоном функций R/3. Чтобы лучше различать их, объекты разделяются на классы объектов. Чтобы просмотреть все доступные в системе SAP объекты полномочий можно использовать ►Object Classes. Например, MM_E — класс объектов Materials Management-Purchasing (управление материалами-закупками). Выбрав эту область, можно получить все доступные для нее объекты полномочий. Небольшой текст дает описание объекта полномочий. Например, выберите M_BEST_EKG для заказа детали. Такой объект полномочий включает в себя поле полномочий ACTVT, содержащееся в каждом объекте полномочий по умолчанию, и специальное поле EKGRP (см. рис. 8.5). Назначение данных полей и значений, которые они могут содержать, описываются в документации по R/3.

Рис. 8.5. Объект полномочий M_BEST_EKG

В данном примере в поле EKGRP можно задать имя или диапазон имен определенных групп закупки. Щелкните на кнопке Permitted activities, чтобы определить все возможные значения для деятельности.

Таблица 8.3. Возможные значения в поле ACTVT и их описания

Значение	Описание
1	Создание или генерация
2	Изменение
3	Вывод
…	Другие значения для других специфических видов деятельности можно определить здесь в зависимости от используемого конкретного объекта полномочий.
*	Все возможные виды деятельности.

Большинство полномочий уже определены с помощью значения «*», поэтому нужно ввести для компании только необходимые специфические значения. Можно использовать ►Role Maintenance • Environment • Auth.Objects для вывода всех существующих полномочий для объекта полномочий, изменения существующих полномочий или добавления новых.

Если принять во внимание сложность системы R/3, станет очевидно, что, хотя можно определить и присвоить все необходимые полномочия каждому отдельному пользователю, требуемые громадные усилия не оправдывают такой подход. Это является причиной того, почему полномочия могут группироваться вместе. Для поддержания всех наборов полномочий одновременно можно использовать роли. Более ранние версии Basis используют для этой цели профили полномочий; система R/3 продолжает использовать эти профили полномочий в качестве технического инструмента.

8.3.3. Профили полномочий

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

Эти профили затем автоматически генерируются во время обслуживания роли, как описано ниже. Это одновременно простейшая и наиболее рекомендуемая процедура. Однако в исключительных случаях, таких как пользовательские разработки, может понадобиться изменить существующие профили вручную или создать новые. Обслуживание профилей вручную возможно в ►User Maintenance с помощью Environment • Profiles • Maintain profiles (в Basis Release 6.10 и более поздних выводится предупреждающее сообщение, указывающее, что для обслуживания полномочий необходимо использовать роли).

Профили в R/3 могут иметь разные состояния:

► Активный/неактивный

► Обслуженный (т. е. адаптированный к текущим условиям) или оставленный без изменений (стандартный)

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

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

Составные профили

Можно также создать новые профили путем слияния определенных заказчиком или стандартных полномочий или профилей полномочий. Эти профили называют составными профилями. Чтобы вручную присвоить полученные профили пользователю, используйте при создании пользователя вкладку Profiles. На рис. 8.6 показаны профили, присвоенные пользователю SAP*. Ему присвоен профиль SAP_ALL, охватывающий все возможные операции в системе R/3.

Рис. 8.6. Профиль полномочий пользователя SAP*

Рис. 8.7. Иерархическая организация полномочий и профилей

Поля полномочий

Объекты полномочий (которые логически делятся на классы объектов) состоят из стандартного поля Activity и дополнительных полей полномочий. Полномочие определяется на основе значений для полей объекта полномочий, которые представляют разрешение для действия. Определяя различные значения можно создать разные полномочия для объекта полномочий.

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

8.3.4. Профили, имеющие важное значение в системном администрировании

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

Таблица 8.4. Наиболее важные для администрирования профили полномочий

Имя профиля	Назначение
SAP_ALL	Все полномочия в системе R/3
SAP_NEW	Профиль полномочий для всех новых объектов полномочий существующих функций, добавленных в ходе обновления версии R/3
S_A.ADMIN	Оператор без прав на внесение изменений в конфигурацию системы R/3
S_A.CUSTOMIZ	Пользовательская настройка (для всех системных операций конфигурации)
S_A.DEVELOP	Разработчики со всеми полномочиями на АВАР Workbench
S_A.DOCU	Технические писатели
S_A.SHOW	Базовые полномочия — только отображение на экране
S_A.SYSTEM	Системный администратор (суперпользователь)
S_A.USER	Пользователь (базовые полномочия)
S_ABAP_ALL	Все полномочия для АВАР
S_ADDR_ALL	Все полномочия на центральное администрирование адресов
S_ADMI_SPO_A	Спул: все полномочия администрирования
S_ADMI_SPO_D	Спул: администрирование устройств
S_ADMI_SPO_E	Спул: расширенное администрирование
S_ADMI_SPO_J	Спул: администрирование заданий для всех клиентов
S_ADMI_SPO_T	Спул: администрирование типов устройств
S_LANG_ALL	Все полномочия на администрирование языков
S_SPOOL_ALL	Спул: все полномочия на администрирование запросов спула, включая чтение всех поступающих запросов на вывод
S_SPOOL_LOC	Спул: все полномочия на администрирование запросов спула, кроме общего чтения
A_SPO_ATTR_A	Спул: изменение всех атрибутов
S_SPO_AUTH_A	Спул: изменение всех запросов спула
S_SPO_BASE_A	Спул: возможность просмотра и единовременная печать
S_SPO_DELE_A	Спул: удаление очередей спула
S_SPO_DEV_A	Спул: администрирование всех устройств вывода
S_SPO_DISP_A	Спул: вывод на экран содержимого очередей спула
S_SPO_FEP	Спул: печать с клиентской системы
S_SPO_PAG_AL	Спул: неограниченное число страниц на всех устройствах
S_SPO_PRNT_A	Спул: единовременная печать
S_SPO_REDI_A	Спул: переадресация всех запросов
S_SPO_REPR_A	Спул: многократная печать всех запросов

8.3.5. Управление ролями

Роли

Роль (до Basis Release 4.6B: группа деятельности) является описанием рабочей среды, которое можно присвоить пользователю. Определение ролей существенно облегчает администрирование пользователей. Если нужно изменить полномочия, то необходимо только изменить роли. После генерации измененных ролей можно выполнить сравнение пользователей, чтобы изменения автоматически вступили в силу для всех соответствующих пользователей. Роль содержит следующую информацию:

► Имя роли

► Текстовое описание роли

► Рабочие операции роли

► Профили полномочий

► Пользователи, которым присвоена роль

► Данные индивидуализации

► MiniApps (в Basis Release 6.10 и более поздних версиях)

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

Подготовка к обслуживанию роли

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

□ auth/no_check_in_some_cases = Y

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

SAP values

Следующий шаг в подготовке к использованию Profile Generator состоит в копировании индикаторной проверки для объектов полномочий транзакции и значений полей полномочий для Profile Generator, предоставленных SAP (значений SAP) в таблицы заказчика. Чтобы скопировать индикаторы проверки, используйте утилиты из ►SAP values (см. рис. 8.8).

Рис. 8.8. Интеграция значений SAP

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

Затем можно вручную изменить объекты полномочий или составных профилей для отдельных транзакций. Для этого используется ►Check Indicators в Customizing (см. рис. 8.9).

Рис. 8.9. Работа с присвоением транзакциям объектов полномочий

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

Чтобы сделать эти изменения переносимыми, необходимо присвоить их классу разработки заказчика (в Basis Rerlease 6.10 и позже — пакету). Поэтому сначала необходимо определить как минимум один класс разработки заказчика.

На рис. 8.10, например, показаны индикаторы проверки для всех объектов полномочий, используемых для транзакции AL09 (Download Monitoring Data). Индикатор проверки может иметь одно из следующих значений статуса:

► U — Индикатор проверки не определен, аналогично проверке для N

► N — Объект полномочий не проверяется для транзакции

► С — Объект полномочий проверяется для транзакции

► CM — Объект полномочий проверяется для транзакции и в Profile Generator предлагаются значения указанных полей

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

Рис. 8.10. Объекты полномочий и индикаторы проверки для транзакции AL09

Стандартные роли

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

Можно вызвать обзор предоставленных ролей в информационной системе (см. раздел 8.6) или с помощью отчета RSUSR070. Если эти роли удовлетворяют требованиям, то можно присвоить их пользователям непосредственно (см. раздел 8.3.8); не требуется создавать роли самостоятельно.

Обслуживание ролей

Транзакция ►Role Maintenance (обслуживание ролей) позволяет копировать, создавать, изменять, присваивать, сравнивать и переносить роли. Обслуживание роли заказчика сострит в основном из двух шагов:

1. Присвоение меню пользователя

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

Для иллюстрации этой процедуры используется относительно простой пример: требуется создать и отредактировать роль для системных администраторов R/3.

На первом шаге требуется создать роль или скопировать ее с существующей роли.

1. Выберите ►Role maintenance для создания ролей и обслуживания существующих. На рис. 8.11 показан начальный экран; в данном примере создается роль с именем zadmin.

2. Введите затребованное имя роли, такое как zadmin. Имена ролей, которые начинаются с «SAP_*», зарезервированы для стандартных ролей.

3. Выберите представление Basic maintenance.

Рис. 8.11. Создание ролей

Базовое обслуживание и полное представление

Для обработки ролей доступны три режима. При простом обслуживании обрабатывается только меню пользователя (например, для рабочего места). Базовое обслуживание включает меню, профили и персонализированные объекты. Описанная роль присваивается реальным пользователям R/3 позже. Полное представление, однако, значительно сложнее и непосредственно связано с HR Organizational Management. Вместо присваивания существующих пользователей R/3 по имени можно присваивать должности, рабочие места или организационные единицы, которые предоставляют большую гибкость. Этот подход имеет смысл только в том случае, если в R/3 используется HR Organizational Management. Соответственно следующий пример ограничен базовым обслуживанием.

4. Выберите Create.

5. Каждая вкладка при обслуживании роли (см. рис. 8.12) имеет цвет, который указывает на статус соответствующей части обслуживания роли:

- Еще не обслужено (красный)

- Устаревший (желтый)

- Обслужен и является текущим (зеленый)

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

6. Теперь можно создать меню пользователя на вкладке Menu. Можно использовать меню из меню SAP, из других ролей, из меню области приложений и импортировать из файла. Можно также добавлять отдельные транзакции, запросы и другие объекты, такие как адреса Web. Выберите из этих вариантов подходящие виды деятельности для роли.

Рис. 8.12. Базовое обслуживание ролей

7. Для данного примера выберите раздел Tools CCMS из меню SAP и добавьте транзакцию SM21 (оперативный анализ системного журнала) и адрес Web SAP Service Marketplace (см. рис. 8.13).

8. Сохраните результаты работы.

9. Вернитесь к базовому обслуживанию. После завершения деятельности по обслуживанию статус пункта Menu изменится на зеленый.

Рис. 8.13. Выбор видов деятельности

Меню пользователя

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

10. Далее для выбранных операций генерируется профиль полномочий. При обслуживании роли выберите вкладку Authorizations (см. рис. 8.14) и введите имя нового профиля полномочий. Все имена с «_» в качестве второго символа зарезервированы для стандартных профилей SAP. Можно позволить системе предложить значение, но оно состоит из трудно запоминаемой строки символов (см. рис. 8.17). Для упрощения последующего анализа рекомендуется использовать свое собственное имя или описательный короткий текст.

Рис. 8.14. Обслуживание полномочий

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

► Зеленый — все полномочия имеют значения, но нужно их проверить.

► Желтый — по крайней мере, одно поле требует ввода значения (например, имя пользователя или устройства), которое необходимо задать вручную.

► Красный — существует поле, для которого не заданы организационные уровни.

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

► Standard(стандартное) — во всех подчиненных узлах стандарты SAP не изменялись.

► Changed (измененное) — по крайней мере, в одном подчиненном узле стандарты SAP изменены.

► Maintained (обслуживаемое) — по крайней мере, в одно подчиненное поле, не заполненное SAP, были введены пользовательские значения.

► Manually (добавлено вручную) — по крайней мере, одно полномочие было вручную добавлено к подчиненным узлам.

► Old (старое) — после обновления R/3 сравниваются значения существовавших ранее и новых объектов и значений. Если все подчиненные значения идентичны, то узлу (хотя он все еще является текущим) присваивается состояние «старый».

► New (новое) — при сравнении обнаружилось, что были добавлены новые значения.

Теперь можно вручную внести изменения в выбранные полномочия и при необходимости присвоить значения. Можно также добавить или удалить полный набор полномочий. На рис. 8.14 показаны полномочия, выбранные для данного примера. Для этого нужно выполнить следующие шаги:

1. Выбрать узел и открыть его.

2. Теперь можно:

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

- Создать новые полные или отдельные полномочия с помощью команды Edit • Insert • Authorizations.

- Создать или изменить значения объекта полномочий, выбрав соответствующий символ в строке. Например, если обратиться к рис. 8.14, то рекомендуется создать значения полномочий на устройства в системе спула R/3. Эти значения описывают имена устройств, на которые распространяются полномочия. Например, D* означает все имена устройств, начинающиеся с D.

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

3. После внесения изменений на всех светофорах должен быть зеленый свет. Сохраните изменения.

4. Выберите значок Generate Authorizations.

5. Создается профиль с присвоенными полномочиями и сохраняется с определенным на предыдущем экране именем.

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

Составные роли

Чтобы еще больше упростить администрирование, можно сгруппировать роли в виде составных ролей. Создание и обслуживание составных ролей в основном совпадает с обслуживанием отдельных ролей.

На начальном экране ►Role maintenance введите имя и щелкните на кнопке Create collective role, чтобы создать составную роль. Используйте вкладку Roles для определения ролей, которые желательно объединить вместе. Можно импортировать и обрабатывать меню отдельных ролей на вкладке Menu. Полномочия в этом месте редактировать нельзя.

8.3.6. Важные роли для системного администрирования

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

Таблица 8.5. Наиболее важные роли для администрирования

Имя профиля	Описание
SAP_BC_BASIS_ADMIN	Базовое администрирование и мониторинг системы
SAP_BC_SPOOL_ADMIN	Администратор спулинга
SAP_BC_BATCH_ADMIN	Администратор фоновой обработки
SAP_BC_CUS_ADMIN	Администратор проектов настройки
SAP_BC_DWB_ABAPDEVELOPER	Разработчик АВАР
SAP_BC_SRV_GBT_ADMIN	Администратор коммуникации, папок, планирования сроков
SAP_BC_SRV_COM_ADMIN	Администратор внешних коммуникаций
SAP_BC_SRV_EDI_ADMIN	Администратор IDoc
SAP_BC_MID_ALE_ADMIN	Администратор ALE
SAP_BC_TRANSPORT_ADMIN	Администратор системы изменений и переноса (CTS)
SAP_BC_BMT_WFM_ADMIN	Системный администратор информационных потоков
SAP_BC_BDC_ADMIN	Администратор бизнес-потоков
SAP_BC_USER_ADMIN	Администратор пользователей
SAP_BC_AUTH_DATA_ADMIN	Администратор данных полномочий

8.3.7. Назначение и сравнение пользователей

Есть два основных способа назначения ролей:

1. Роли назначаются пользователям в ►User Maintenance

2. Пользователи назначаются ролям в ►Role Maintenance

Чтобы назначить роли в ►User Maintenance (см. раздел 8.2.1), выберите вкладку Roles. Затем можно ввести требуемые роли непосредственно для этого пользователя. При этом для данной роли сгенерированные профили автоматически добавляются на вкладку Profiles.

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

Пользователей можно назначать роли на вкладке User при обслуживании роли.

1. Выберите вкладку User.

2. Введите нового пользователя в поле User ID (см. рис. 8.15 для пользователя MUSTERMANN). Пользователь уже должен быть определен.

Рис. 8.15. Назначение пользователя

Период действия

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

3. Щелкните на кнопке User compare, чтобы назначить созданные для роли профили полномочий выбранным пользователям (см. рис. 8.16). Этот процесс называется сравнением основных записей пользователей.

4. Выйдите из обслуживания ролей.

Это завершает пример. Транзакцию обслуживания пользователей можно использовать для подтверждения того, что сделанные изменения были сохранены. Все назначенные пользователи получили выбранную роль и сгенерированный профиль. На рис. 8.17 это показано для пользователя MUSTERMANN.

Рис. 8.16. Сравнение основных записей пользователей

Рис. 8.17. После сравнения основных записей пользователей

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

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

► Выбор пункта Automatic User Master Adjustment when Saving Role в ►Role Maintenance в меню SAP в разделе Utilities • Settings. Затем сравнение выполняется автоматически каждый раз при сохранении роли.

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

8.3.8. Перенос ролей

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

При использовании Central User Administration (CUA, см. раздел 8.7.4), пользователей можно назначать только в центральной системе.

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

8.3.9. Процедуры обновления

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

Преобразование в Profile Generator

Обновление версии системы R/3, которая не использует Profile Generator, в версию, использующую эту утилиту, крайне трудоемко. В этом случае SAP рекомендует заново создать систему управления полномочиями.

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

Если исходная версия использует Profile Generator, то можно использовать ►SAP values (с шагами от 2А до 2С) для сравнения существующих данных полномочий с новыми данными.

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

8.3.10. Выявление проблем и трассировки

Достаточно часто встречаются ситуации, когда пользователи не имеют всех требуемых полномочий особенно во время начальных фаз реализации R/3. В этом случае после прекращения транзакции в связи с отсутствием полномочий затронутый пользователь или системный администратор может выбрать ►Authorization Data для вывода списка отсутствующих полномочий. Транзакция показывает, какое требуется полномочие для выполнения выбранного действия.

Кроме всего прочего, можно использовать ►SAP System Trace (см. главу 15) для записи всех проверок полномочий. В этом случае записываются все проверенные проекты полномочий, включая проверенные значения. Можно использовать меню Edit filters для ограничения трассировки отдельных пользователей, процессов или транзакций. Администраторы могут затем еще больше ограничить выбор, например пользователем, во время анализа трассировки. Система SAP System Trace удобна для определения всех необходимых полномочий для действия на основе выполненной проверки полномочий.

8.4. Персональные настройки

Управляющий пользователями администратор несет ответственность за обслуживание данных в главной записи пользователя. Пользователи разных прикладных областей обычно не имеют полномочий на самостоятельное обслуживание этих данных за исключением адреса компании. В то же время все пользователи могут определять в главной записи специальные настройки, помогающие им работать с системой R/3. Например, эти настройки задают начальное меню, язык входа в систему, назначенный по умолчанию принтер и формат данных для ввода стандартных значений в отдельные поля. Для ввода таких данных нужно выбрать команду ►Own Data. Система выведет окно Maintenance, где можно задать почтовый адрес компании, фиксированные значения и параметры. Эти вкладки соответствуют аналогичным вкладкам при обслуживании пользователей (см. раздел 8.2.1).

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

Рис. 8.18. Обслуживание задаваемых по умолчанию значений пользователя

Обслуживание задаваемых по умолчанию пользовательских параметров позволяет назначать индивидуальные значения для полей ввода. Это означает, что не придется вводить значение в поле явным образом. Поля сами заполняются определяемыми значениями. Например, можно вывести на экран техническую информацию по коду компании или месту возникновения затрат. Чтобы вывести на экране техническую информацию для поля ввода, выделите это поле и активируйте кнопку технической информации в контекстной справочной системе F1. Поле Parameter ID содержит имя параметра,которое требуется для его определения. Например, BUK означает код компании. Это сокращение можно использовать в своих персональных значениях.

8.5. Пользователи Интернета

Во многих случаях, когда информация просто выводится (но не изменяется), пользователи могут работать анонимно в Интернете. Однако в среде системы SAP даже при работе в Интернете доступ обычно требует индивидуального имени пользователя и соответствующего пароля. Это требуется, когда через Интернет должны выполняться такие транзакции, как размещение заказа. В зависимости от Internet Application Component (IAC, см. главу 1) может быть достаточно сконфигурировать обычный диалог пользователя для активации в Интернете, но может понадобиться создать и поддерживать дополнительную учетную запись пользователя Интернета. Обратитесь к описанию конкретного IAC, чтобы выяснить, какой вариант применим.

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

Если требуется отдельный пользователь Интернета для IAC, то его можно сконфигурировать следующим образом:

1. Выберите Internet user (см. рис. 8.19).

Рис. 8.19. Обслуживание пользователей Интернета

2. Введите идентификатор пользователя (ID).

3. Задайте тип пользователя. Тип часто соответствует прикладной области и ограничивает права пользователя. Например, «KNA1» означает, что данную транзакцию Интернета может выполнять только сам пользователь.

4. Инициализируйте пользователя с помощью Initialize.

5. Теперь пользователь активен. Система автоматически генерирует для него пароль. Чтобы сменить пароль, выберите Change Password.

Пользователя Интернета можно блокировать и разблокировать.

8.6. Информация о пользователях и полномочиях

Чем больше пользователей работает в системе R/3, тем более сложным и трудным будет управление пользователями и мониторинг критических для безопасности пользователей. Система SAP обладает дополнительными инструментами для выполнения этих задач.

8.6.1. Информационная система

Чтобы предоставить системному администратору обзор всех пользователей и полномочий, система R/3 предлагает специальную ►Information system. Она позволяет анализировать и сравнивать пользователей и полномочия, предоставленные в системе для большого набора критериев. На рис. 8.20 показан начальный экран этого инструмента.

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

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

8.6.2. Журнал аудита безопасности

Журнал аудита безопасности (Security Audit Log) позволяет регистрировать всю деятельность пользователя, которая имеет отношение к безопасности системы. Аудиторы часто требуют такие записи, особенно для пользователей с критически важными полномочиями, чтобы гарантировать контролируемость системы. Не имеет смысла и технически невозможно регистрировать деятельность всех пользователей с помощью журнала аудита безопасности. Журнал аудита чаще используется для мониторинга критически важных пользователей, которые имеют много полномочий, особенно пользователи службы чрезвычайных ситуаций и поддержки, а также для выявления специальных критически важных для безопасности событий, таких как неудачные попытки регистрации.

Рис. 8.20. Информационная система пользователей

Функцию ►Security Audit Configuration можно использовать для определения, какие типы деятельности и для каких пользователей будут записываться в журнал аудита безопасности. Эти пользователи и виды деятельности затем будет контролироваться постоянно. Можно использовать ►Security Audit Analysis для анализа записей аудита согласно различным критериям.

Сначала в ►Security Audit Configuration (см. рис. 8.21) необходимо создать профиль. Затем имя этого профиля используется для сохранения настроек.

Фильтры

Можно использовать фильтры для определения, какие события в каких классах аудита (диалоговая регистрация, начало транзакции, RFC и т.д.) будут записываться для каких пользователей в каких клиентах. Можно использовать символы-местозаполнители (*) для пользователя и клиента, но нельзя использовать записи с групповыми символами, такие как «MULLER*». В результате число пользователей, которые могут записываться в журнал с помощью профиля, ограничивается числом фильтров. Необходимо явно выбрать каждый фильтр с помощью Filter active.

Рис. 8.21. Конфигурация журнала аудита безопасности

Профиль

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

Динамическая конфигурация

В качестве альтернативы статической конфигурации можно также изменять эти настройки динамически во время работы с помощью вкладки Dyn.Configuration. Параметризация использования фильтров для динамической конфигурации идентична статической конфигурации

Записанные в журнал данные сохраняются в файлах на уровне операционной системы. Функция ►Security Audit Analysis позволяет выбирать с помощью известных параметров фильтра, а также по дате/времени и терминалу пользователя. Выбранные данные форматируются в соответствии с настройками системного журнала (см. главу 15)

Параметры профиля

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

► rsau/enable - Активирует журнал аудита безопасности

► rsau/max_diskplace/local - Максимальный объем пространства, который может быть выделен файлам аудита

► rsau/selection_slots - Число фильтров, допустимых для журнала аудита безопасности (максимум 5)

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

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

8.7. Центральное управление пользователями

В больших системных средах с множеством пользователей описанное выше локальное управление пользователями может требовать много времени Обслуживание одинаковых пользователей в различных системах и синхронизация изменении между системами, что означает, что администраторам необходимо регистрироваться на каждой локальной системе, может сделать обслуживание пользователей утомительным и подверженным ошибкам. К счастью здесь может помочь Центральное управление пользователями (CUA- Central User Administration). В Basis Release 4.6 и более поздних версиях можно выполнить все действия по обслуживанию пользователей на одном определенном клиенте одной системы, а затем распространить данные на других клиентов той же или других систем. Специальный клиент является отправителем (центральной системой), в то время как все остальные клиенты (дочерние системы) - получателями данных. Application Link Enabling (ALE, см. главу 13) является технологией, которая используется для обмена данными. Клиенты, которые обмениваются данными, конфигурируются и управляются как логические системы.

Преимущества

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

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

► Число пользователей на систему

► Число логических систем

► Частота изменений пользователей и полномочий

► Продолжительность разработки (и поэтому время, в течение которого разработчики требуются как пользователи систем)

► Конфигурирование административного пользователя в центральной системе

► Конфигурирование сценария ALE:

- Именование логических систем

- Присвоение логических систем клиентам

- Создание пользователей коммуникации (которые используются в интерфейсах RFC) во всех вовлеченных клиентах

- Создание интерфейсов RFC

- Создание новых представлений модели распределения ALE

- Поддержание и генерация профилей Partner между всеми клиентами, участвующими в CUA

- Распространение представлений модели

► Активация CUA

► Конфигурирование параметров распределения для полей

► Распространение адреса компании

► Синхронизация пользователей

Более подробно эти шаги описаны в следующих разделах.

8.7.1. Конфигурирование сценария ALE

Свойства и управление интегрированной системой ALE описаны в главе 13. Поэтому здесь описаны только настройки специфические для Центрального управления пользователей (CUA).

Сначала нужно сконфигурировать логические системы (см. главу 13), для всех клиентов, работающих с CUA. Затем используется ►Client Administration для присвоения логических систем клиентам. Одно соединение RFC должно быть задано для пересылки данных из центральной системы в каждую дочернюю систему и в противоположном направлении — необходимо иметь отдельные соединения RFC для каждого направления. Между дочерними системами не требуется никаких соединений. Клиент в месте расположения CUA также должен быть интегрирован как дочерняя система в центральное управление. Определяется новое представление модели для модели распространения ALE, чтобы указать, какие данные будут обмениваться между логическими системами. Для CUE это будут предопределенные бизнес-объекты USER и UserCompany с методом распространения Clone.

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

8.7.2. Активация и конфигурирование центрального управления пользователями

Чтобы активировать CUA, необходимо только присвоить CUA представление модели ALE. Для этого нужно ввести имя представления модели в ►Central Role Administration и нажать Create. На следующем экране следует ввести все дочерние системы для центрального управления и сохранить их. Теперь можно распространить модель с помощью меню с путем доступа Distribution Model • Distribute Distribution Model для распространения модели на дочерние системы. Центральное управление пользователями активно.

Основной аспект конфигурирования CUA включает определение места обслуживания атрибутов пользователей в различных системах, т.е. в центральной или в дочерней системе. Для определения, как будет обслуживаться каждый атрибут пользователя (см. рис. 8.22), можно использовать ►Distribution Parameters в Customizing.

Рис. 8.22. Определение параметров распространения

Администраторы могут использовать следующие параметры:

Таблица 8.6. Параметры для выбора полей

Параметр	Обслуживание и синхронизация
global	Это поле может обслуживаться только в центральной системе. Изменения затем распространяются автоматически.
local	Данные обслуживаются только в дочерних системах и не распространяются на другие системы.
proposal	Поле с этим параметром обслуживается и распространяется со значением по умолчанию, когда создается пользователь. Дальнейшее обслуживание имеет место в дочерних системах. Последующие изменения не распространяются.
retval	Это значение может обслуживаться как центрально, так и локально. Когда данные изменяются локально, их можно послать назад на центральную систему и затем распространить на все дочерние системы.
everywhere	Значение может обслуживаться как центрально, так и локально. Центральные изменения распространяются на дочерние системы, но изменения в дочерних системах не возвращаются. Этот параметр доступен только для небольшого числа полей.

8.7.3. Удаление центрального управления пользователями

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

Когда CUA полностью удалено, необходимо также выполнить следующие задачи по очистке:

► Удалить партнерское соглашение.

► Удалить модель распространения ALE.

► Удалить соединения RFC.

► Заблокировать пользователя коммуникации.

Если удаляется только одна дочерняя система, то нужно соответственно ограничить партнерское соглашение, модель ALE и интерфейсы RFC.

8.7.4. Управление пользователями в CUA

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

► New users

Эти пользователи существуют только в дочерней системе, но еще не в CUA. Во время переноса все параметры интегрируются в CUA.

► Identical users

Пользователь с таким же именем пользователя и реальным именем существует как в CUA, так и в дочерней системе. Пользователя можно либо скопировать из дочерней системы в CUA и перераспределить оттуда, либо удалить в дочерней системе и определение перераспределить из CUA.

► Different users

Одно и то же имя пользователя содержится как в CUA, так и в дочерней системе, но с другими реальными именами (реальное имя является комбинацией имени и фамилии). Необходимо решить, какой пользователь будет обслуживаться в дальнейшем. Может быть, желательно создать нового пользователя в CUA.

► Central users

Эти пользователи уже зарегистрированы в CUA идентичным образом и управляются централизованно.

Затем можно интегрировать пользователей в CUA по отдельности или всех сразу. В ходе этого процесса данные для всех пользователей за исключением New users всегда берутся и распространяются из центральной системы. Если два различных пользователя используются в действительности для Different users, то необходимо определить их снова в центральной системе и удалить идентично именованных пользователей в дочерней системе.

Для обслуживания пользователей продолжают использовать ►User maintenance (см. раздел 8.2.1), далее когда CUA активно. Однако пользователей нельзя больше создавать в дочерних системах, и готовы для ввода только те поля, которые могут обслуживаться локально согласно определению параметров распространения (см. раздел 8.7.2). В центральной системе появляется новая вкладка Systems в транзакции ►User maintenance. Эта вкладка используется для ввода систем, в которые вы хотите распространить пользователей. Данные пользователя можно определить только один раз, и они будут затем идентичны во всех дочерних системах. Каждой дочерней системе можно присвоить различные роли и профили.

8.8. Обзор: службы каталогов

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

LDAP

Службы каталогов делают возможным для различных приложений в структуре ИТ обращение к общим данным, которые управляются централизованно. Считайте службу каталогов «адресной книгой ИТ». Если служба каталогов поддерживает Стандартный легковесный протокол доступа к каталогам (LDAP), то можно использовать LDAP Connector для обмена данными со службой каталогов в Basis Release 6.10 и более поздних версиях. Следовательно, центральные данные пользователя должны сохраняться только один раз в центральной службе каталогов и могут синхронизироваться прямо с системой SAP или Центральным управлением пользователями с помощью функций синхронизации LDAP. Затем данные можно распределить на дочерние системы в CUA (включая данные более ранней версии Basis).

8.9. Советы

► Обслуживание данных коммуникации

При обслуживании в ►User maintenance данных коммуникации — особенно номеров факсов — необходимо проверить, чтобы эти данные соответствовали соглашениям SAP. Необходимо вводить значения без каких-либо ведущих пробелов или специальных символов, с разделителем между номером компании и расширением и без кода страны (это можно выбрать в Other Communication), в противном случае SAPConnect не сможет проверить данные (см. главу 13).

► Высокие требования к памяти в связи с большими меню пользователей

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

► Клиент для Центрального управления пользователями

Концепция полномочий для CUA упрощается, когда CUA задается на отдельном клиенте или даже на отдельной системе (например, отдельная система мониторинга).

8.10. Транзакции и пути доступа меню

ALE Customizing: SAP Implementation Guide (SPRO) • R/3 Basis Customizing • Application Link Enabling (SALE)

Authorization data: SAP Menu • System • Utilities • Disp.Authorization Check (SU53)

Central Role Administration: ALE Customizing (SALE) • Configure Predefined ALE Business Processes • Configure Central User Administration • Select Model Views for Central Administration (SCUA)

Check indicators: SAP Implementation Guide (SPRO) • Basis • System Administration • Users and Authorizations • Maintain Authorizations and Profiles with the Profile Generator • Edit SAP Check Indicators and Field Values • Change Check Indicators (SU24)

Client administration: SAP Menu • Tools • Administration • System Administration • Administration • Client Administration • Client Maintenance (SCC4)

Company address: SAP Menu • Tools • Administration • User Maintenance • Users • Environment • Maintain Company Address (SUCOMP)

Distribution Model: ALE Customizing (SALE) • Model Business Processes • Maintain Distribution Model and Distribute Views (BD64)

Distribution Parameters: ALE Customizing (SALE) • Configure Predefined ALE Business Processes • Configure Central User Administration • Configure Distribution Parameters for Fields (SCUM)

Information system: SAP Menu • Tools • Administration • User Maintenance • Information System (SU01 • Info • Info System)

Internet users: SAP Menu • Tools • Administration • User Maintenance • Internet Users (SU05)

License Administration Workbench (LAW): He доступно в стандартном меню SAP (LICENSE_ADMIN)

Mass changes: SAP Menu • Tools • Administration • User Maintenance • Users • Environment • Mass Change (SU10)

Object classes: SAP Menu • Tools • ABAP/4 Workbench • Development • Other Tools • Authorization Objects • Objects (SU21)

Own data: SAP Menu • System • User Profile • Own Data (SU3)

Partner agreements: ALE Customizing (SALE) • Model Business Processes • Maintain Distribution Model and Distribute Views (BD64) • Generate Partner Agreement (BD82)

Role maintenance: SAP Menu • Tools • Administration • User Maintenance • Roles (PFGC)

SAP Implementation Guide: SAP Menu • Tools • AcceleratedSAP • Customizing • Edit Project (SPRO)

SAP Proposals: SAP Implementation Guide (SPRO) • System Administration • Users and Authorizations • Maintain Authorizations and Profiles with the Profile Generator • Copy SAP Check Indicators and Field Values (SU25)

SAP System Trace: SAP Menu • Tools • Administration • Monitor • Traces • SAP System Trace (ST01)

Security Audit Analysis: SAP Menu • Tools • Administration • Monitor • Security Audit Log • Analysis (SM20)

Security Audit Configuration: SAP Menu • Tools • Administration • Monitor • Security Audit Log • Configuration (SM19)

System Measurement: SAP Menu • Tools • Administration • Administration • System Measurement (USMM)

User group: SAP Menu • Tools • Administration • User Maintenance • Maintain User Groups (SUGR)

User maintenance: SAP Menu • Tools • Administration • User Maintenance • Users (SU01)

User transfer: ALE Customizing (SALE) • Configure Predefined ALE Business Processes • Configure Central User Administration • Transfer Users from New Systems (SCUG)

8.11. Дополнительная документация

Быстрые ссылки

► SAP Service Marketplace, псевдоним licenseauditing

Документ: "Introduction to System Measurement"

► SAP Service Marketplace, псевдоним security

► SAP Service Marketplace, псевдоним securityguide

Документ: "SAP Security Guidelines"

► SAP Service Marketplace, псевдоним sso

Указания SAP Service Marketplace

Таблица 8.7. Указания SAP Notes для администрирования пользователей

Содержание	Указание
Additional documentation regarding the authorization concept	093769
Responsibilities replaced as of Release 4.5A	156250
High memory consumption with Easy Access menu	203617

8.12. Контрольные вопросы

1. Какое утверждение правильно?

Пользователь с типом «System»:

a. может регистрироваться в системе без пароля через интерфейс RFC

b. имеет пароль, но настройки для периода действия не применимы

c. не может регистрироваться в системе в диалоговом режиме

2. Какое утверждение правильно?

a. Пользователю может быть присвоена только одна роль.

b. Пользователю может быть присвоено несколько ролей.

3. Какая информация переносится при переносе ролей?

a. Профили полномочий для роли

b. Определение пользователей

c. Назначение ролей пользователям

4. Полномочия роли расширены. С какого момента пользователь, которому была назначена эта роль и который уже зарегистрировался в системе, сможет начать использовать измененные полномочия?

a. Пользователь может начать использовать измененные полномочия немедленно.

b. Пользователь может использовать измененные полномочия после сравнения пользователей.

c. Пользователь должен снова зарегистрироваться в системе и может затем начать использовать измененные полномочия.

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

ГЛАВА 9 ФОНОВАЯ ОБРАБОТКА

9.1. Концепции

Фоновая обработка

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

Чтобы пользователи не выполняли длительно выполняющиеся отчеты интерактивно (см. рис. 9.1), шаги диалогового режима имеют ограничение по времени выполнения. Это ограничение задано по умолчанию равным 600 сек. Обработка прекращается после завершения этого периода времени. Можно задать это ограничение в системном профиле (параметр rdisp/max_wprun_time). Фоновая обработка не имеет таких ограничений.

Рис. 9.1. Длительная задача в диалоговом режиме

Автоматическая обработка, требующая периодического выполнения определенных задач, является другим очевидным применением фоновой обработки. Для фоновой обработки в системе R/3 предусмотрена служба фонового выполнения с фоновыми рабочими процессами, которые называют просто фоновыми процессами. В отличие от диалоговой обработки, когда каждая логическая единица работы (LUW—Logical Unit of Work; см. главу 1)) присваивается следующему свободному процессу диалога, при фоновой обработке один процесс присваивается фоновому заданию на все время выполнения. Время запуска фонового задания определяет системный администратор или обычный пользователь. Задание можно запускать не только при наступлении указанного времени, но и по какому-то событию.

Планировщик фоновых заданий по времени

Для запуска задания в конкретное время нужно запланировать его выполнение. Каждая инстанция системы R/3, сконфигурированная для выполнения фоновых рабочих процессов, имеет активный планировщик заданий по времени. Через определенные интервалы времени он проверяет наличие фонового задания для обработки. Описания ожидающих заданий хранятся в центральных таблицах в базе данных. Планировщик — это программа АВАР, интерпретируемая и обрабатываемая заданным диалоговым процессом, который автоматически выбирается при запуске системы R/3. По умолчанию интервал активизации планировщика фоновых заданий составляет 60 сек. Администратор может его настроить, для чего в профиле инстанции устанавливается параметр rdisp/btctime. Таким образом, задание может запускаться с точностью до интервала активизации планировщика фоновых заданий. Если задержка слишком длительная, интервал можно уменьшить. С другой стороны, если задержка запуска задания не столь важна, лучше увеличить этот интервал времени, хотя уменьшение частоты запуска планировщика фоновых заданий мало влияет на производительность системы.

Планировщик фоновых заданий на основе событий

Планировщик на основе событий функционирует в системе R/3 на уровне приложений. Он запускает соответствующее фоновое задание в ответ на определенное событие. Планировщик заданий на основе событий также обрабатывается диалоговым рабочим процессом. Инстанцию для него можно выбрать с помощью параметра rdisp/btcname = <имя_сервера> в стандартном профиле системы R/3 (DEFAULT.PFL).

Системные события

Сначала необходимо определить события, на которые должна реагировать система R/3. В стандартной системе R/3 уже определены многие виды событий. Для вывода списка этих событий можно использовать ►Event Maintenance. События, определенные для стандартной системы, называются системными. Они часто используются для внутреннего управления R/3, но могут применяться и пользователями R/3 для своих целей.

Пользовательские события

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

Инициация события (триггеры)

Инициировать событие можно следующими способами:

► Вручную с целью тестирования — с помощью ►Trigger Event

► Используя в программе АВАР в системе R/3 функциональный модуль BP_EVENT_RAISE

► Посредством внешней программы sapevt

Программа sapevt

Программа sapevt позволяет инициировать событие в системе R/3 из внешней программы. Эта программа доступна в стандартном каталоге SAP для исполнимых программ (см. главу 1). Вызывается она так:

□ sapevt <идентификатор события> [-р <параметр>] [-t] [pr = <профиль> name = <имя_системы R/3> nt = <номер_системы R/3>]

Параметр -t задает запись файла журнала dev_evt в тот каталог, откуда вызывалась программа sapevt. Параметр -р можно использовать для указания модуля R/3, например F1. Это позволяет присваивать события прикладным областям. Это присваивание имеет только описательную природу и не обладает другими функциями.

Например, вызов:

□ sapevt SAP_TRIGGER_RDDIMPDP name=Q01 nr=00

инициирует событие SAP_TRIGGER_RDDIMPDP в системе Q01.

В самой системе R/3 управление событиями используется, например, для переноса объектов между системами R/3. Перенос выполняется в несколько этапов с помощью программы управления переносом tp. Кроме фактического импорта данных нередко возникает необходимость сгенерировать или активизировать отдельные объекты. Программа tp инициирует событие SAP_TRIGGER_RDDIMPDP при завершении импорта данных. В системе R/3 задание RDDIMPDP всегда планируется как зависимое от события SAP_TRIGGER_RDDIMPDP. Если наступает это событие, то в фоновом режиме выполняется задание RDDIMPDP.

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

9.2. Определение фоновых заданий

Для определения фоновых заданий в R/3 используется ►Job Definition (см. рис. 9.2).

Рис. 9.2. Начальный экран: Job Definition

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

Определение фонового задания охватывает три основных области:

► Общую информацию, такую как имя задания, его класс и целевой сервер

► Информацию о времени запуска или инициирующем событии.

► Список шагов обработки

9.2.1 Общая информация

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

Классы заданий

Приоритет выполнения задания определяется присвоенным ему классом. Существуют следующие классы заданий:

► А: наивысший приоритет — задания, обеспечивающие функционирование R/3 и критические по времени

► В: средний приоритет — периодические задания, обеспечивающие функционирование R/3

► С: обычный приоритет — обычные задания для пользователей R/3

Класс задания используется для присвоения ему системных ресурсов. Если приходится часто обрабатывать большое число заданий класса C (это означает, что задания класса A и B должны ожидать освобождения фоновых процессов), то системный администратор может явным образом зарезервировать некоторое число n фоновых процессов для заданий класса А в ►Operation Mode Maintenance. Такая конфигурация гарантирует, что п фоновых процессов всегда доступны для выполнения заданий класса А. Задания классов В и С должны ждать, пока число доступных фоновых процессов не будет равно как минимум п+1. Эта конфигурация описана в разделе 14.2.

Целевой сервер

В распределенной системе R/3 можно также указать инстанцию R/3 со службой фоновой обработки заданий. Эта инстанция R/3 называется целевым сервером в контексте фоновой обработки. Если инстанция не указывается, то во время выполнения R/3 выбирает первый доступный фоновый процесс в любой инстанции.

Для обработки запроса на определенном фоновом сервере выделены следующие приоритеты:

1. Задание класса A, целевой сервер задан

2. Задание класса A, целевой сервер не определен

3. Задание класса B, целевой сервер задан

4. Задание класса B, целевой сервер не определен

5. Задание класса C, целевой сервер задан

6. Задание класса C, целевой сервер не определен

Если ожидающие задания имеют равный приоритет согласно приведенным выше критериям, то используется время ожидания.

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

Созданный программой АВАР вывод сохраняется как запрос спула в системе спула SAP. С помощью средства Spool List Recipient можно послать вывод пользователю. Эта техника позволяет, например, нескольким людям управлять фоновым заданием и анализировать его результаты. Поскольку вывод может быть достаточно большим, то рекомендуется использовать эту возможность с осторожностью. По соображениям производительности длина вывода, посылаемого в SAPoffice, ограничена 1000 строками. Значения параметров печати задаются при определении шага (см. раздел 9.2.3).

9.2.2. Время запуска

Следующий шаг состоит в выборе параметров, определяющих время запуска. Выберите на начальном экране определения задания условие Start. Можно назначить запуск задания на конкретное время или запускать его по событию (см. рис. 9.3). Используемая информация о времени и часовом поясе основывается на системном времени. Кроме определения времени запуска задания, планирование заданий по времени позволяет также планировать периодическое выполнение задания, например для регулярного анализа служебных заданий (см. раздел 9.6). Можно выбрать любой интервал повторения: через несколько минут, каждый час, ежедневно, еженедельно и т.д. Можно воспользоваться кнопкой Restrictions для определения исключений для обычного периода, например для указания дней отдыха в действующем производственном календаре. Когда используются задания, чувствительные ко времени, можно определить самое позднее возможное время для запуска задания (No start after).

Вместо определения управления по времени можно также определить некоторое событие в качестве триггера. В частности, изменения операционных режимов (см. главу 14) и конец задания определяются как события, что означает, что фоновое задание может также выполняться в зависимости от другого, уже определенного задания. В этом случае второе задание запускается после окончания первого. Если нужно запустить второе задание, когда первое успешно обработано, используйте опцию Start status-dependent. Тогда в случае прерывания первого задания второе переводится в состояние отмены и не выполняется.

Рис. 9.3. Время запуска для планирования фоновых заданий

Если задания с временем запуска After job (после задания), After event (после события) или At operation mode (при режиме работы) не могут запуститься из-за отсутствия доступных фоновых процессов при возникновении ожидаемого события, они помечаются для немедленного запуска и запускаются затем планировщиком заданий по времени, как только будет возможно.

9.2.3. Шаги обработки

Для завершения определения фонового задания следует описать шаги обработки, составляющие это задание. Шаг обработки представляет собой выполнение независимой программы, например АВАР или внешней программы. Фоновое задание может состоять из одного или более таких шагов обработки. Для определения шагов нужно выбрать в транзакции определения задания функцию Step (см. рис. 9.2). Каждый шаг обработки не обязательно должен выполняться пользователем, назначенным планировщиком. Для назначенного пользователя всегда выполняется проверка полномочий. Таким образом, можно предоставить полномочия и ответственность для планирования задания и для анализа результатов его выполнения разным группам пользователей. Например, явное назначение пользователей упрощает последующий анализ результатов фонового задания, поскольку в этом случае можно назначить генерируемые списки этим пользователям. С данной целью удобно определить пользователей фоновых заданий (см. главу 8).

Шаги обработки могут включать в себя также программы АВАР, внешние команды или программы (см. рис. 9.4).

Программы АВАР

Все недиалоговые программы АВАР можно выполнять в фоновом режиме. Для этого нужно выбрать функцию АВАР Program (см. рис. 9.4), ввести имя программы АВАР и при необходимости указать язык, на котором будет генерироваться журнал. Многие программы АВАР (например, программа RSPFPAR) управляются с помощью переменных. Перед выполнением такой программы можно ограничить диапазон выводимых на экран имен параметров инстанции. Для выполнения подобного типа программ в фоновом режиме нужно создать для программы варианты (variants). Вариант является фиксированным набором значений для переменных программы, который сохраняется под именем варианта. Варианты определяют в ►АВАР Editor с помощью Goto • Variants. Необходимо также ввести имя варианта и требуемые значения параметров. Определенный таким образом вариант программы АВАР можно планировать для фонового выполнения. На рис. 9.4 показано планирование выполнения программы АВАР RSPFPAR, вариант которой называется ALL. Он был создан для генерации списка определенных на данный момент параметров инстанции. Для управления печатью данного списка нужно выбрать Print Specifications.

Рис. 9.4. Определение шага

Внешние программы

Пользователи R/3 с полномочиями администратора могут выбрать External Program для выполнения любых программ на уровне операционной системы из системы R/3. В этом случае требуется имя целевого сервера; параметры являются необязательными. Для выполнения программы на целевом сервере запускается процедура SAPXPG, которая осуществляет коммуникацию вызывающей системой R/3 через RFC, используя идентификатор специального пользователя R/3 SAPCPIC (см. главу 8).

Внешние команды

Чтобы иметь возможность выполнять внешние программы ограниченным образом, используя внутренний механизм авторизации R/3, конфигурируются расширенные внешние команды. Внешняя команда состоит из имени и назначенной внешней программы вместе с возможными значениями параметров, которые могут изменяться в зависимости от операционной системы. Прежде чем внешние команды можно будет использовать в фоновой обработке, необходимо определить их с помощью ►Create External Operating System Commands (см. рис. 9.5).

Рис. 9.5. Создание внешней команды

Стандартная система R/3 уже содержит многие внешние команды. Системные администраторы могут определить любую другую команду в пространстве имен заказчика. На рис. 9.5 показан пример команды ZLIST, за которой «скрывается» команда ls с параметром -lisa, выводящая на экран содержимое текущего каталога в системах UNIX.

Для систем Windows NT можно задать внешнюю команду с тем же именем для соответствующей команды dir. Определенная таким образом команда может использоваться и при создании фоновых заданий, и в CCMS (Computing Center Management System). Для этого нужно запустить ►External Operating System Commands, выбрать требуемую команду и затем Edit Execute.

Можно определить модуль проверки, чтобы еще больше ограничить использование внешней команды по соображениям безопасности. Модуль проверки выполняется перед запуском команды. В зависимости от результата выполнения проверки команда либо выполняется, либо нет. Процедура SPXG_DUMMY_COMMAND_CHECK является модельным примером в системе, который можно использовать в качестве шаблона для собственных проверок.

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

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

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

Мастер заданий

Все описанные записи можно создать также последовательно с помощью Job Wizard (Мастер заданий). Мастера заданий можно вызвать прямо из ►Job Definition.

API

Кроме метода, предусматривающего использование меню, в системе R/3 предлагается интерфейс прикладного программирования (API, Application Programming Interface) для планирования фонового выполнения заданий из программ заказчика.

9.3. Анализ

Для анализа и мониторинга фоновых заданий используется ►Simple Job Selection или ►Extended job selection. Задания можно фильтровать по различным критериям, таким как пользователь, период времени, событие и состояние задания (см. рис. 9.6), а полномочия позволяют еще более сузить выбор. Если имеются полномочия администратора для фоновой обработки, то можно вывести задания в любых клиентах при выборе дополнительных заданий. Если нет, то задания можно вывести только в клиенте регистрации.

На основе заданного критерия генерируется список фоновых заданий (см. рис. 9.7).

Каждое задание может иметь одно из следующих состояний:

► Sched. (запланировано)

Сохранены определения шагов задания; время запуска пока еще не определено.

► Released (разблокировано)

Задание спланировано, и время запуска задано явно, или задание ожидает событие.

► Ready(готово)

Время запуска достигнуто, или произошло ожидаемое событие; задание ожидает системные ресурсы для начала выполнения.

► Active (активно)

Задание обрабатывается в данный момент.

► Finished (закончено)

Задание успешно завершено.

Рис. 9.6. Простой выбор задания

Рис. 9.7. Список фоновых заданий

► Canceled (отменено)

При обработке возникла проблема, и задание отменено. Задание не было завершено успешно.

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

Рис. 9.8. Журнал прерванного задания

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

► Вывод данных планирования

► Отмену заданий со статусом Active

► Удаление заданий со статусом Sched., Released, Finished или Canceled

► Отмену выпуска одного или нескольких заданий; статус задания изменяется на planned

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

► Перемещение на другой сервер

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

► Проверка статуса активных заданий (см. раздел 9.4)

► Копирование спланированных, выпущенных или законченных заданий; новое задание задается со статусом Sched.

Кроме этого списка, можно использовать графическое представление с аналогичными функциями, которое позволяет изменять и выпускать задания, а также проверять активные задания. Для вызова графического монитора заданий нужно использовать ►Job Monitor (см. рис. 9.9). Состояния заданий выделяются цветом.

Рис. 9.9. Монитор планирования заданий

Можно также выбрать ►Own Jobs или ►Job Definition • Own jobs для вывода обзора имеющихся собственных фоновых заданий.

9.4. Функции анализа

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

Анализ времени выполнения

До версии R/3 Release 4.6D функция ►Performance Analysis выводила список всех выбранных фоновых заданий вместе с запланированным и реальным временем запуска и временем выполнения. Начиная с версии R/3 Release 4.6C, эта информация интегрирована в ►Simple Job Selection. Большие задержки между запланированным и реальным временем старта отмечают «узкое место» в доступных фоновых процессах, так как они указывают на задержку при получении заданием фонового процесса для выполнения. Если пользователю могут помешать «узкие места» производительности во время выполнения запланированных фоновых заданий, то администратор должен проверить ресурсы и при необходимости увеличить число фоновых процессов (параметр rdisp/wp_no_btc в профилях инстанций или в обслуживании профиля; см. главу 14).

Зомби

При запуске система R/3 проверяет наличие заданий со статусом ready или active, хотя они невозможны в этой ситуации. Все найденные подобные задания переводятся в состояние Sched. или canceled. Такие задания-зомби (zombies) могут создаваться при выключении сервера приложений до завершения выполнения задания, и статус может быть обновлен в базе данных.

Проверка статуса

Чтобы проверить, что выведенный статус действительно согласуется с реальным статусом (или существует несогласованность), можно выбрать критические задания в ►Simple Job Selection, а также Job status, чтобы найти все возможные несогласованности. При необходимости можно сбросить статус задания в Sched. или отменить сами задания.

Сигналы фоновой обработки

Некоторые параметры фоновой обработки были интегрированы в архитектуру мониторинга CCMS. Монитор Background Processing (Фоновая обработка) предоставляет информацию о средней нагрузке на фоновые рабочие процессы, специфическую для сервера и среднюю длину очереди ожидания для заданий со статусом Ready (которые не могут запуститься в связи с отсутствием фонового сервера), а также число прерванных заданий (см. рис. 9.10).

Список управляющих объектов

Чтобы обеспечить правильность работы управления фоновой обработкой, используйте ►Background Control Object Monitor. Эта транзакция позволяет проверить важные компоненты фоновой обработки, такие как планировщики заданий по времени и на основе событий, очистка от зомби, запуск внешних программ и переключение операционных режимов, и анализировать их с помощью вывода дополнительной трассировки.

Инструмент анализа фоновой обработки

Исчерпывающий анализ всех аспектов фоновой обработки можно выполнить с помощью ►Analysis of Background Processing. В частности, этот инструмент анализа позволяет находить и исправлять несогласованности в таблицах базы данных для управлениями заданиями. Следующий листинг содержит пример вывода этого инструмента:

Листинг 9.1. Вывод инструмента анализа

******************************************************

* Analysis tool for background processing

******************************************************

** Test: Determine all batch-capable servers

******************************************************

Рис. 9.10. Интеграция фоновой обработки в мониторинг сигналов

Рис. 9.11. Монитор элементов управления фоновой обработки

* Server name Host name

* psasb009_IE4_00 psasb009

******************************************************

* Test: Test TemSe functionality

******************************************************

* ==> TemSe check ran without errors

******************************************************

* Test: Check a user's batch authorizations

******************************************************

* User to check = D036044

* ==> Possesses the following authorizations:

* Batch administrator : Yes

* EarlyWatch: Yes

* Delete external jobs: Yes

* Display job logs: Yes

* Release jobs: Yes

* Display external jobs: Yes

******************************************************

* Test: Test environment for starting external programs

******************************************************

* ==> User SAPCPIC.not defined in client 002

* External programs cannot be started in this client!

* ==> User SAPCPIC not defined in client 066

* External programs cannot be started in this client!

******************************************************

* Test: Consistency check of database tables

******************************************************

* ==> No inconsistencies found!

* ==> All job contexts are consistent

******************************************************

* Test: Check profile parameters

******************************************************

* Server = psasb009_IE4_00 , Date = 10/13/2002 ,

* Time = 2:35:46 p.m.

******************************************************

* rdisp/btctime = 60

* rdisp/wp no btc = 6

* ==> Server is configured correctly for

* background processing ******************************************************

* Test: Check local host name against message server

******************************************************

* Server: psasb009_IE4_00 , Date = 10/13/2002 ,

* Time = 2:35:46 p.m.

******************************************************

* Local host name = psasb009

* ==> Local host name agrees with name on

* message server

******************************************************

* Test: Determine status of batch work processes

* on a server

******************************************************

* Server = psasb009_IE4_00 , Date = 10/13/2002 ,

* Time = 2:35:46 p.m.

******************************************************

* ==> Status of batch work processes:

* WP 1 : waiting

* WP 2 : waiting

* WP 3 : waiting

* WP 4 : waiting

* WP 5 : waiting

* WP 6 : waiting

* Number of reserved class A work processes: 0

******************************************************

* Test: Determine number of requests in batch queue

******************************************************

* Server = psasb009_IE4_00 , Date = 10/13/2002 ,

* Time = 14:35:46

******************************************************

* ==> Number of requests in batch queue = 0

******************************************************

9.5. Полномочия

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

► Манипуляции с запланированными заданиями других пользователей

► Вывода журнала задания

► Вывода запроса спулинга, сгенерированного фоновым заданием

► Выпуска задания для выполнения

► Использования внешней команды

Таблица 9.1. Полномочия для фоновой обработки

Полномочие	Описание
S_BTCH_ADM	Администратор фоновой обработки
S_BTCH_JOB	Операции с фоновыми заданиями, зависят от клиента Возможные значения:
	DELE — Удаляет задания других пользователей
	LIST — Выводит списки спула других пользователей
	PROT — Выводит журналы других пользователей
	RELE — Планирует собственные задания и разблокирует их для выполнения
	SHOW — Выводит на экран подробную информацию о заданиях других пользователей
	Можно использовать поле «Job Groups», чтобы ограничить полномочия для выбранных имен заданий
S_BTCH_NAM	Выполнение с явно заданным пользователем фоновых заданий
S_DEVELOP	Прерывание заданий
S_LOG_COM	Выполнение внешних команд Требуемые параметры:
	COMMAND — имя логической команды
	OPSYSTEM — операционная система
	HOST — имя целевой системы
S_RZL_ADM	Администрирование системы CCMS
S_ADMI_FCD	Системное полномочие для специальных функций

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

9.6. Служебные задания

Системный администратор обязан выполнять определенные задания для поддержания производительности и функциональности системы R/3. Например, эти задания могут удалять ненужные таблицы или собирать статистику для анализа производительности. В обязанности системного администратора входит планирование и мониторинг этих заданий. Наиболее важные задания перечислены в таблице 9.2. В зависимости от используемых приложений и применения специфических пользовательских программ могут потребоваться дополнительные задания.

Таблица 9.2. Важные служебные задания

Рекомендованное имя задания/описание	АВАР	Изменяемое	Интервал
SAP_COLLECTOR_FOR_PERFMONITOR	RSCOLL00	Нет	Ежечасно
Собирает общие статистические данные для анализа производительности в системе R/3; Общее для всех клиентов; Планируется на клиенте 000 как DDIC
SAP_COLLECTOR_FOR_JOBSTATISTIC	RSBPCOLL	Нет	Ежедневно
Собирает статистические данные для анализа среднего времени выполнения периодически спланированных заданий; Общее для всех клиентов
SAP_REORG_JOBS	RSBTCDEL	Да	Ежедневно
Удаляет все журналы успешно выполненных заданий; Системные администраторы могут использовать варианты для определения числа дней, которые должны пройти до удаления задания; Общее для всех клиентов
SAR_REORG_JOBSTATISTIC	RSBPSTDE	Да	Ежемесячно
Реорганизует статистику времени выполнения фоновых заданий; Удаляются все объекты, которые старше определенной даты; Общее для всех клиентов
SAP_REORG_BATCHINPUT	RSBDCREO	Да	Ежедневно, но только в то время, когда отсутствует деятельность пакетного ввода
Удаляет выполненные сеансы пакетного ввода и их журналы, а также все журналы, для которых сеансы больше не существуют; Зависит от клиента
SAP_REORG_SPOOL	RSPO0041/RSPO1041	Да	Ежедневно
Удаляет устаревшие объекты спула; Зависит от клиента
Нет стандартного имени	RSPO0043/ RSPO1043	Да	Ежедневно
Удаляет списки спула, которые являются остатками завершенных фоновых программ; Проверка согласованности таблиц спулера; Общее для всех клиентов
SAP_REORG_ABAPDUMPS	RSSNAPDL	Да	Ежедневно
Удаляет записи (короткий вывод) из ошибок времени выполнения; Общее для всех клиентов
SAP_REORG_PRIPARAMS	RSBTCPRIDEL	Нет	Ежемесячно
Реорганизует параметры печати; Общее для всех клиентов
SAP_CCMS_MONI_BATCH_DP	RSAL_BATCH	Нет	Ежечасно
Мониторинг системы; Зависит от клиента	TOOL DISPATCHING
Нет стандартного имени	RDDIMPDP		Управляется событиями
Реализует транспортные запросы
EU_PUT	SAPRSLOG		Ежедневно
Административное задание для обновления списков объектов и индексов навигации; Общее для всех клиентов
EU_REORG	SAPRSEUT		Ежедневно
Административное задание для обновления списков объектов после переноса; Общее для всех клиентов

Дополнительную информацию о свойствах и параметрах этих заданий можно найти в документации по отдельным программам. Это можно сделать в ►АВАР Editor. Введите имя программы и выберите Documentation • Display.

В версии R/3 Release 4.6C и более поздних можно спланировать все приведенные выше задания по отдельности или автоматически со стандартными параметрами с помощью ►Job Definition • Standard jobs.

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

9.7. Внешний интерфейс

Интерфейс SAP BC-XBP позволяет интегрировать фоновые задания R/3 с внешними системами управления заданиями. Поддерживаются следующие функции:

► Определение заданий

► Изменение, редактирование или удаление заданий

► Запуск заданий

► Прекращение выполнения активных заданий

► Доступ к информации о задании (статус, файлы журналов и т.д.)

Чтобы вывести список продуктов, сертифицированных для этого интерфейса, посетите SAP Service Marketplace раздел с псевдонимом background.

9.8. Советы

► Определение заданий с целевым сервером

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

- Сервер приложений перемещается на другое оборудование (изменение имени сервера)

- Изменяется распределение рабочих процессов в определении операционных режимов

► Удаление заданий, которые больше не являются текущими и имеют статус Sched.

При выводе очереди текущих заданий в ►Simple Job Selection флажок Job Status: Planned обычно не отмечен; это означает, что администратор может не обращать внимания на ненужные задания с этим статусом. Другая обычная ошибка состоит в пренебрежении флажком Or after event, который означает, что включаемые событиями задания не выводятся.

► Планирование заданий не для базового пользователя

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

► Минимальное число процессов

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

► Освобождение и перепланирование всех выпущенных заданий

Отчет BTCTRNS1 используется во время обновления в R/3 Release 4.5B и более поздних версиях. Он меняет статус всех заданий на статус, который планировщик заданий не распознает, чтобы предотвратить нежелательный запуск. После обновления используется отчет BTCTRNS2 для возврата заданий в их исходный статус. Конечно, эти функции можно использовать и для других целей.

► Перенос времени запуска отдельных управляемых по времени планировщиков заданий

Если используется несколько инстанций с фоновыми процессами, то может иметь смысл задать параметру rdisp/btctime различные значения в профилях инстанций, чтобы обеспечить лучшее распределение нагрузки.

► Проблемы с самопланирующимися периодическими заданиями с ограниченным временем запуска

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

9.9. Транзакции и пути доступа меню

АВАР Editor: SAP Menu • Tools • АВАР Workbench • Development АВАР Editor (SE38)

Analysis of background processing: SAP Menu • Tools • CCMS • Jobs • Check Environment (SM65)

Background control object monitor: SAP Menu • Tools • CCMS • Jobs • Background Objects (SM61)

Create external operating system commands: SAP Menu • Tools • CCMS • Configuration • External Commands (SM69)

Event maintenance: SAP Menu • Tools • CCMS • Jobs • Maintain Event (SM62)

Extended job selection: SAP Menu • Tools • CCMS • Jobs • Maintenance • Extended job selection (SM37C)

External operating system commands: SAP Menu • Tools • CCMS • Jobs • External Commands (SM49)

Job definition: SAP Menu • Tools • CCMS • Jobs • Definition (SM36)

Job monitor: SAP Menu • Tools • CCMS • Control/Monitoring • Job Scheduling Monitor (RZ01)

Operation mode maintenance: SAP Menu • Tools • CCMS • Configuration • Operation modes/Instances (RZ04)

Own jobs: System • Own jobs (SMX)

Performance analysis: SAP Menu • Tools • CCMS • Jobs • Performance analysis (SM39)

Simple job selection: SAP Menu • Tools • CCMS • Jobs • Maintenance (SM37)

Trigger event: SAP Menu • Tools • CCMS • Jobs • Trigger Event (SM64)

9.10. Другая документация

Быстрые ссылки

► SAP Service Marketplace, псевдоним background

Указания SAP Service Marketplace

Таблица 9.3. Указания SAP для пользовательской фоновой обработки

Содержание	Указание
Standard jobs, reorganization jobs	16083
Distribution of background jobs on application servers	24092
Error analysis: Background processing system	37104
Behavior of transactions SM37 and SM37C	422000

9.11. Контрольные вопросы

1. Какая транзакция используется для анализа журнала выполнения задания?

a. SE38

b. SM37

c. S000

2. Какая внешняя программа используется для инициации событий в системе R/3?

a. sapevt

b. sapxpg

c. sapstart

d. spmon

3. Что означает состояние фонового задания Ready?

a. Планирование задания завершено и сохранено

b. Задание выполнено, и можно распечатать журнал

c. Задание может быть запущено и ожидает системных ресурсов

ГЛАВА 10 СЛУЖБА ОБНОВЛЕНИЯ

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

SAPLUW

Бизнес-процесс в системе SAP отображается в логическую единицу работы SAP (LUW, см. главу 1), которая может состоять из нескольких изменений экрана. Эта диалоговая или фоновая обработка приводит к изменению данных, которое можно записать в базу данных только полностью (т. е. со всеми изменениями из LUW) или нельзя записать вообще. Система обновления SAP гарантирует, что изменения не записываются в базу данных, пока не будет завершен SAP LUW, и что никакие данные не изменяются, если транзакция SAP прерывается. В большинстве случаев обновление выполняется асинхронно в конце LUW (см. раздел 1.4). Это приводит к значительному повышению производительности для диалоговых пользователей, которые могут продолжать свою работу в следующей LUW, пока система обновления все еще записывает изменения в базу данных.

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

10.1. Концепции обновления

Определение

В среде R/3 термин обновление означает выполнение изменений в базе данных R/3, которые система SAP производит обычно асинхронно после того, как данные были введены или изменены. Для отображения LUW R/3 в транзакции базы данных требуется специальная система обновления. Логические единицы работы R/S отображаются в независимые LUW R/3, которые состоят из нескольких транзакций базы данных. Это возможно только с отдельной системой обновления; в противном случае каждая LUW R/3 должна будет отображаться точно в одну транзакцию базы данных. Система обновления делает возможным управление вводом данных отдельно от самого обновления и консолидирует процессы обновления.

Например, если пользователь вводит данные, то они сначала передаются процессу диалога. Самим процессом диалога изменения в БД не вносятся; для этого используются специальные процессы обновления, записывающие изменения асинхронно (см. рис. 10.1).

Рис. 10.1. Асинхронное обновление

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

Пользователи могут заметить, что асинхронные изменения по сравнению с синхронными дают более высокую производительность системы. Пользователь может быстро модифицировать, ввести или удалить данные — ему не нужно ждать, пока будут выполнены эти запросы, а изменения асинхронно поступят в БД. Подобные запросы обрабатываются в фоновом режиме специальными процессами. Асинхронное обновление особенно выгодно при внесении в данные обширных изменений, например при крупной модификации корпоративных данных или создании заказов. Оно улучшает масштабируемость системы R/3. Обычно пользователи никак не могут повлиять на то, как именно вносятся изменения в БД — асинхронно или синхронно. Это зависит от применяемой программы АВАР.

Рис. 10.2. Запрос обновления

Запрос обновления

Данные, которые будут изменены SAP LUV, сохраняются в запросе обновления (называемом также записью обновления). Запросы обновления состоят из заголовка обновления, одного или нескольких V1, V2 и модулей групповой обработки (см. рис. 10.2).

Таблицы обновления

Информация о запросах обновления сохраняется в таблицах обновления:

► VBHDR — Заголовки обновления

► VBMOD — Модули обновления

► VBDATA — Данные, перенесенные в модули

► VBERROR — Информация об ошибках, которая порождается, если обновление прерывается.

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

10.1.1. Режим и модули обновления

Режим обновления

Программы ABAP поддерживают три типа обновлений:

► Локальные обновления

► Асинхронные обновления

► Синхронные обновления

Программа ABAP определяет используемый режим, который не могут изменить ни администратор, ни пользователь.

Локальные обновления

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

Асинхронные обновления

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

Синхронное обновление

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

Обновления V1 и V2

Система различает модули обновления V1 и V2. Существует также групповая обработка для часто используемых функциональных модулей, называемая иногда обновлением V3. Обновление V1 включает в себя критические изменения управляющих функций. Подобные обновления используются для бизнес-операций, например для изменения в имеющихся на складе материалах. Изменения в такие объекты должны вноситься как можно быстрее. Обновления V2, напротив, используются в основном для целей статистики и поэтому имеют более низкий приоритет, чем обновления V1.

Каждый модуль обновления соответствует модулю функции обновления. Будет ли использоваться обновление V1, V2 или V3, зависит от модуля функции и не может изменяться администратором.

На уровне системы обработку модулей V1 и V2 можно распределить по отдельным рабочим процессам обновления в классах UPD и UPD2 (см. главу 15). Для определения числа обновленных процессов UPD и UPD2 используются профильные параметры. Проверить распределение рабочих процессов можно с помощью ►Process Overview (см. главу 15). Если в системе не сконфигурированы рабочие процессы UDP2, то обновление V2 выполняется в рабочем процессе UDP.

Обновления V2 не обязательно выполняются только после обновлений V1. Когда обрабатывается компонент V1, система автоматически пытается обработать компоненты V2 этого запроса обновления.

Модули групповой обработки

В модулях групповой обработки (V3) обновление выполняется не в процессе обновления — оно выполняется асинхронно в пакетном задании (отчет RSM13005). При таком подходе сначала консолидируют собранные вызовы функционального модуля. Если одна и та же запись изменяется несколько раз, то сначала вычисляется получающееся значение и только оно записывается в базу данных один раз. В остальном же администрирование и управление функциональными модулями идентичны модулям обновления V2. В частности, это означает, что запросы обновления остаются в таблицах обновления, пока они не будут обработаны при групповой обработке.

Будут ли использоваться для групповой обработки модули V3, определяется в программе АВАР или в Customizing для приложения (одним из примеров является извлечение «дельта» в логистике с помощью транзакции LBWE). Если определено использование модуля V3, то администратор SAP отвечает за планирование и мониторинг регулярной групповой обработки.

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

10.2. Конфигурация системы обновления

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

Число процессов обновления UDP и UDP2 определяется с помощью параметров rdisp/wp_no_vb и rdisp/wp_no_vb2 (соответственно) в профиле инстанции. Число записей обновления для обработки является критическим фактором в определении числа и распределения процессов обновления (см. раздел 10.3.1). Верхняя граница задается производительностью оборудования, т. е. доступными в системе R/3 ресурсами. Соответственно необходимо контролировать процессы обновления. В качестве точки отсчета для начальных настроек рекомендуется сконфигурировать примерно один рабочий процесс обновления для каждых четырех диалоговых процессов. Поскольку обновление V2 не является критическим по времени, то обычно бывает достаточно одного рабочего процесса UDP2 на систему.

Мультиплексирование

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

Хороший обзор параметров профиля для управления задачей обновления и краткое описание каждого параметра доступно в ►Update Program Administration. Некоторые из наиболее важных конфигурационных параметров описаны ниже.

Конфигурационные параметры

► rdisp/vbmail

Можно сконфигурировать систему R/3 для автоматической отправки сообщения пользователю, когда запрос обновления этого пользователя вызвал ошибку. Для этого нужно задать rdisp/vbmail = 1. Однако значение 0 деактвирует отправку сообщений пользователю в случае ошибки. Значением по умолчанию для этого параметра является 1.

► rdisp/vbdelete

Этот параметр определяет интервал в днях, после которого не полностью выполненные запросы обновления удаляются, когда система R/3 (или одна из ее инстанций) перезапускается. Значением по умолчанию для этого параметра является 50 дней. Разрешено или нет автоматическое удаление или обновление, зависит от бизнес-окружения и может также обсуждаться с аудиторами. Если нежелательно, чтобы незавершенные записи обновления удалялись, нужно задать этот параметр равным 0.

► rdisp/vbreorg

Этот параметр управляет удалением не полностью созданных запросов обновления при перезапуске системы R/3 или одной из ее инстанций. 0 означает, что такие запросы не удаляются; 1 означает удаление таких запросов. Можно также удалять неполные запросы обновления с помощью ►Update Program Administration, управления для ►Update Records или отчета RSM13002. Неполные запросы обновления возникают во время прерывания пользователем процесса (отката), когда часть запроса обновления уже была записана в базу данных.

► rdisp/vb_stop_active

Этот параметр определяет, может ли задача обновления быть деактивирована. Когда это значение задано как 1, задача обновления может быть деактивирована автоматически при серьезных проблемах с базой данных или вручную. В отличие от предыдущих версий эта деактивация задачи обновления предотвращает проблемы с базой данных, возникающие в результате отмены обновлений. Если это значение задано как 0, то задача обновления не может быть деактивирована.

10.3. Мониторинг и обслуживание обновления

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

Причины ошибок

Возможные причины отказа обновлений (или даже отказа всей системы обновлений) включают проблемы с базой данных и конфликты блокировок в приложении.

Различаются две основные области проблем:

► Проблемы для всей системы, такие как вызванные проблемами базы данных, часто деактивируют задачу обновления. Хорошим примером этого является достижение максимального размера в базе данных Oracle. Поэтому при остановке задачи обновления сначала необходимо проверить журнал системы R/3 (см. главу 15) и файлы журналов базы данных и поискать общие системные проблемы. Когда проблема решена, необходимо перезапустить службу обновления вручную.

► Другой тип проблем обновления имеет более изолированную, локальную природу, которая часто вызывается ошибками программирования в объектах заказчика. Это требует вмешательства разработчика и пользователя, чтобы совместно решить, что делать с записями обновления. Можно использовать обзор ►Update Records для удаления, обновления, размещения или сброса отдельных или всех записей. Обновление означает продолжение обновления; размещение означает, что обновленная запись все еще находится в своем начальном состоянии (статус init). Если обновление или размещение также вызывают отказ, то необходимо удалить соответствующие записи или сбросить и обработать их заново.

10.3.1. Мониторинг обновления

Доступ к общему мониторингу процесса обновления и подробному рассмотрению выявленных неисправностей можно получить либо через административное управление для ►Update Records (см. рис. 10.3), либо из ►Update Program Administration (см. рис. 10.4).

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

Если происходят ошибки на уровне системы, то можно также деактивировать обновление вручную в окне управления ►Update Records с помощью Update Records • Update • Deactivate, а затем после исправления проблем вновь активировать с помощью Update Records • Activate (см. рис. 10.3). Прерывание обновления и проблемы с обновлением записываются в системном журнале R/3 (см. главу 15).

Рис. 10.3. Управление записями обновления

Чтобы получить обзор текущей ситуации, необходимо вывести сначала все запросы обновления. Когда начинается работа с ►Update Records, следует проверить, что выбраны предыдущие записи обновления для всех пользователей и во всех клиентах. Однако для пользователя при настройках по умолчанию выводятся только его собственные записи обновления от текущей даты и текущего клиента. Объем данных, которые ожидают обновления в любой данный момент времени, является хорошим индикатором того, что число процессов обновления удовлетворяет требованиям системы (см. рис.10.5).

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

Рис. 10.4. Начальное меню для управления программой обновления

Рис. 10.5. Обзор записей обновления

10.3.2. Обслуживание прерванных обновлений

Прерванные обновления являются особенно важными. Когда обновления прерываются, необходимые для обновления записи данных процессы не могут выполняться, что означает, что изменения не будут реализованы в базе данных R/3 (см. рис. 10.6).

Рис. 10.6. Прерванные обновления

Чтобы проанализировать прерванные обновления, можно выбрать соответствующие операции обновления, используя различные критерии на начальном экране для ►Update Program Administration. Для каждой записи данных, которая должна обновляться (запись обновления), выводится следующая информация: клиент, работающий пользователь, полученное время, код транзакции, которая привела к обновлению записи, любая дополнительная информация для запроса обновления и его текущий статус. Возможны следующие значения статуса записей обновления:

► init — Запись ожидает обновления

► auto — Когда задача обновления снова активируется после выключения сервера обновлений, запись будет обновлена автоматически

► run — Запись обрабатывается

► err — Произошла ошибка, которая вызвала прерывание запроса

► V1 — Модули V1 заказа были выполнены без ошибок; запрос ожидает обновления V2

► V2 — Запрос ожидает групповой обработки (обновления V3)

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

Таблица 10.1. Описания информационных пиктограмм

Поиск неисправностей

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

1. В меню ►Update Records выберите статус Terminated, укажите клиента, пользователя и период времени.

2. Выберите Execute.

3. Система выводит на экран список прерванных обновлений (см. рис. 10.6). Для каждой записи показывается клиент, пользователь, время, код сгенерировавшей обновление транзакции и состояние.

4. Проанализируйте прерывание обновления совместно с ответственным лицом из отделапользователей.

5. Выделите отдельные записи обновления и протестируйте их с помощью команды Update Records • Test. Можно также осуществлять обновление с помощью Update Records • Debugging. Перед использованием данной функции следует учесть, что она создает ощутимую нагрузку на системные ресурсы.

6. Если это не дает результатов, проверьте заголовок записи обновления. Он содержит все административные данные записи. Чтобы вывести ее, выберите Goto • Update Header (см. рис. 10.7).

Рис. 10.7. Заголовок обновления

Рис. 10.8. Модули обновления

7. Чтобы найти функциональный модуль, необходимый для обновления записи (модуль обновления), выберите Update Modules в списке записей с прерванным Обновлением ►Update Records. На рис. 10.8 это показано для записей из рис. 10.6. Здесь необновленная запись состоит из двух компонентов V1 и одного компонента V2.

8. Для проверки реальных данных в записи обновления выберите команду Goto • Display Data.

9. Проверьте в ►System Log системы R/3 сообщения об ошибках, которые возникли во время прерывания обновления.

Примечание

В процессе обычной работы R/3 администратора непосредственно касаются три вопроса, связанных с обновлением:

1. Активен ли сервис обновления?

2. Были ли прерывания обновления?

3. Насколько велика очередь ожидающих запросов обновления?

Мониторинг операций обновления — это одна из повседневных задач системного администратора.

10.4. Советы

► Обзор всех открытых обновлений

Чтобы получить начальный обзор при запуске SM13, необходимо ввести «*» для пользователя и клиента и выбрать дату перед установкой системы. В противном случае при настройках по умолчанию будет показан только список собственных записей обновления пользователя в текущем клиенте от текущей даты.

► Удаление блокированных записей

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

10.5. Транзакции и пути доступа меню

Lock entries: SAP Menu • Tools • Administration • Monitor • Lock Entries (SM12)

System log: SAP Menu • Info • System Log (SM21)

Update program administration: не существует записи в стандартном меню SAP (SM14)

Update records: SAP Menu • Tools • Administration • Monitor • Update (SM13)

10.6. Дополнительная документация

Быстрые ссылки

► SAP Service Marketplace, псевдоним installation

► SAP Service Marketplace, псевдоним technology

Указания SAP Service Marketplace

Таблица 10.2. Указания SAP для системы обновления

Содержание	Указание
V3 update, questions, and answers	396647
Update groups for asynchronous updates	109515

10.7. Контрольные вопросы

1. Обновление было деактивировано в связи с переполнением табличного пространства. Какие требуются действия после расширения табличного пространства?

a. Никакие действия не требуются; служба обновления реактивируется автоматически.

b. Необходимо активировать службу обновления.

c. Необходимо разместить все записи обновления вручную.

2. Какое состояние имеет запись обновления в случае ожидания?

a. Active

b. Released

c. Init

d. Start

3. Какой параметр профиля R/3 используется для передачи сообщения пользователю, запрос обновления которого отменен?

a. rdisp/vbmail

b. Сообщение передается пользователю в любом случае

c. rdisp/rbdelete

ГЛАВА 11 КОНФИГУРАЦИЯ И АДМИНИСТРИРОВАНИЕ ВЫВОДА

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

Запросы печати, созданные в системе SAP R/3, преобразуются в зависящий от устройства поток данных и выводятся через базовую систему спула. Чтобы реализовать эту функцию, система SAP R/3 должна быть осведомлена о свойствах различных устройств. Кроме определения устройств вывода на уровне операционной системы, спецификация этих устройств всегда требуется в системе SAP R/3.

11.1. Основы вывода

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

Спул и запрос вывода

Диалоговый или фоновый процесс выполняют затем запрос вывода. Активный рабочий процесс создает сначала запрос спула из записей пользователя. Затем он сохраняет необработанные данные, предназначенные для вывода в TemSe (сокр. от temporary sequential object— временный последовательный объект) в базе данных или на уровне файловой системы (см. раздел 11.4). Описание запроса сохраняется в базе данных SAP R/3. Если запрос спула должен затем распечатываться, то рабочий процесс спула, присвоенный выбранному устройству вывода, выполняет форматирование данных в печатную форму и направляет их спулеру операционной системы, который отвечает за устройство вывода. Таким образом, рабочий процесс спула создает запрос вывода.

Рис. 11.1. Запрос вывода в диалоговом режиме (SAP R/3 Release 4.6D)

Каждый вывод происходит в два этапа:

1. Генерирование запроса спула — информация запроса (автор, число копий и дата запроса) сохраняется в базе данных; не зависимые от устройства данные печати хранятся в TemSe.

2. Генерирование и обработка запроса вывода из запроса спула — если устройство вывода было определено и готово получить данные.

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

Рис. 11.2. Поток данных во время печати

Если менеджер печати спула хоста не может обратиться к устройству вывода на уровне операционной системы, то печать из системы SAP R/3 происходить не может.

11.2. Конфигурирование рабочих процессов спула

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

Теоретически можно использовать для каждой инстанции системы R/3 любое количество рабочих процессов спула. В зависимости от конкретных требований инфраструктуры спула необходимо рассмотреть следующие критерии для получения оптимальной конфигурации:

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

► Поскольку не все серверы, на которых выполняются инстанции SAP R/3, могут иметь доступ ко всем используемым в операционной системе принтерам, то отказ инстанции может означать невозможность получения доступа к устройству вывода.

► Рабочие процессы спула отвечают за форматирование запросов печати, пересылку запросов системе спула хоста и за другие административные задачи:

- Реорганизацию системы спула (удаление устаревших запросов)

- Перенаправление запросов при отказе сервера

- Поиск необработанных запросов

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

Можно определить число конфигурируемых рабочих процессов спула, задавая параметр rdisp/wp_no_spo в профиле инстанции.

Управление запросами

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

Последовательная обработка

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

11.3. Настройка сервера спула

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

Можно определить архитектуру логического спула для следующих целей:

► Выравнивание нагрузки между серверами спула

► Доступность альтернативного средства при отказе сервера спула

► Возможность простого переноса определенной инфраструктуры принтера

Логический сервер

Логический сервер является иерархией из одного или нескольких логических серверов и точно одного реального сервера спула, который? в конечном счете? обрабатывает запросы вывода. При настройке архитектуры логического спула можно использовать логические серверы для представления реальных серверов спула. При определении логического сервера, кроме сервера спула, можно задать дополнительный сервер спула, который должен представлять логический сервер. Если необходимо, дополнительный сервер может выполнить задачи реального сервера спула, который отказал, или можно сконфигурировать подходящие настройки для использования этого дополнительного сервера для распределения нагрузки.

На рис. 11.3 показана реализация сценария отказа с определением логического сервера и его альтернативного сервера. Логический сервер «LOGI1» присвоен принтерам; «LOGI1» представляет реальный сервер спула «host1_PRD_00». Реальный сервер спула «host2_PRD_00» является альтернативным сервером. Если сервер спула «host1_PRD_00» отказывает, все запросы печати, предназначенные для устройств, которые присвоены логическому серверу «LOGI1», обрабатываются альтернативным сервером «host2_PRD_00».

Если определение «LOGI1» позволяет также распределение нагрузки, то система всегда будет определять наиболее подходящий сервер спула и разделять запросы соответственно между «host1_PRD_00» и «host2_PRD_ 00» (см. рис. 11.4).

Рис. 11.3. Сценарий отказа с логическим сервером спула

Рис. 11.4. Выравнивание нагрузки

Если принтеры были присвоены прямо серверу спула «host1_PRD_00», то ожидающие запросы вывода не будут обработаны, если сервер спула откажет.

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

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

Классификация

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

Для классификации реальных и логических серверов спула доступны следующие варианты:

► Производственная печать: например документы и сопроводительные письма.

► Массовая печать: например распечатки с места возникновения затрат

► Настольная печать: например документы SAPoffice

► Тестовый сервер для тестовой печати

► Производственная и массовая печать

► Производственная и настольная печать

► Массовая и настольная печать

► Производственная печать, массовая печать и настольная печать

► Производственная печать и тестовая печать

► Не классифицировано

Системой спула SAP можно управлять с помощью ►Spool administration. Есть три различных уровня для простого, расширенного и полного управления (см. рис. 11.6).

Рис. 11.5. Предупреждение о противоречивой классификации

Ниже представлены различия между этими слоями:

► Простое управление

- Устройства/серверы (вывод и редактирование устройств вывода, вывод и редактирование серверов спула, вывод методов доступа и распределение устройств по этим методам доступа, а также вывод хостов назначения и распределение по ним устройств).

- Управление (настройка, удаление старых запросов спула, проверка согласованности базы данных спула и обзор запросов печати).

► Расширенное управление

- Дополнительно: вывод управляющих систем (вывод и редактирование реального и логического OMS).

► Полное управление

- Дополнительно: типы устройств (типы устройств, управление печатью, типы форматирования, форматы страниц и тексты для сопроводительных писем).

- Дополнительно: наборы символов (наборы символов, символы SAP и наборы символов производителей).

Рис. 11.6. Управление спулом (Полное управление)

Определение серверов спула

После конфигурации рабочих процессов спула на уровне профиля определяют логические и реальные серверы спула.

1. Из простого, расширенного или полного управления в Spool Administration выберите Configuration • Spool servers или кнопку Spool Servers. Из списка уже известных серверов спула переключитесь в режим изменения с помощью Spool Server • Create на экран Spool Administration • Server (Change) • Full Administration: Create Server (см. рис. 11.7).

2. Задайте свойства сервера. Если активирован параметр для Logical Server, то на экран после нажатия клавиши Enter выводится дополнительное поле Mapping для ввода этой информации.

3. В поле Mapping введите реальный сервер спула, в который будет отображаться логический сервер спула.

4. В поле Alt server можно определить альтернативный сервер в качестве замены, если откажут активный или реальный сервер спула.

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

В связи с возможностью использования как реального, так и логического сервера спула, в качестве альтернативы или отображения логических серверов спула, в некоторых ситуациях могут возникать достаточно сложные инфраструктуры спула. Можно вывести различные графические иллюстрации инфраструктуры, чтобы избежать потери представления о ситуации. Можно использовать ►Spool Administration • Spool servers • View • Mapping relationship для вывода представления. Отношения отображения между логическими или реальными серверами спула иллюстрируются горизонтально, а с альтернативными — вертикально (см. рис. 11.8).

Рис. 11.7. Управление спулом: создать сервер

Использование логической архитектуры спула предлагает следующие возможности:

► Присвоение принтеров логическим серверам спула позволяет группировать устройства вывода, такие как локальные и сетевые принтеры. Хотя структура присваивает группы различным логическим серверам, они все ссылаются на один и тот же реальный сервер спула. Затем можно, если потребуется, настроить отображение, чтобы присвоить группы другим серверам спула.

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

► Поскольку имя логических серверов не зависит от имени инстанции системы SAP R/3 (в отличие от случая реальных серверов спула) и может быть идентично для всех систем, то можно определить стандартизованную и переносимую архитектуру печати с логическими серверами. Необходимо просто настроить определения отображений в физические свойства целей переноса.

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

Логическую структуру отображать не требуется.

Рис. 11.8. Структура логических серверов спула

11.4. Настройка инфраструктуры устройств вывода

Поскольку система спула SAP сама управляет устройствами вывода, необходимо определить принтеры, факсы и устройства архивирования не только на уровне операционной системы, но также в спуле SAP R/3. Конфигурация устройства в системе спула SAP R/3 означает, что устройство присваивают типу устройств SAP и что определяют соединение. При этом неявно определяется, как данные запроса спула в TemSe должны форматироваться для данного устройства, чтобы был сгенерирован соответствующий запрос вывода для устройства.

Классификация

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

► Производственная печать

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

► Массовая печать

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

► Настольная печать

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

► Тестовая печать

Можно создать отдельный класс принтеров для новых принтеров или для использования во время модификация конфигурации вывода.

Методы доступа

В широком смысле метод доступа, присвоенный устройству вывода, описывает метод или протокол, который используется для передачи данных запроса вывода с сервера спула на хост-принтер. Рабочий процесс спула присвоенного сервера спула может передавать данные непосредственно системе спула хоста, системе управления выводом, сетевому принтеру или программе переноса SAPLPD. SAPLPD действует между рабочим процессом спула и менеджером печати Windows. Программа SAPLPD запускается на компьютере Windows.

Локальные методы доступа

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

► Метод доступа L: Локальная печать с помощью команд

Служба спула сохраняет данные для печати в виде файла на хост-системе. Данные могут выводиться на печать соответствующей командой спула хост-системы, по умолчанию командами lp или lpr в системах UNIX или print в среде Windows NT. Команда операционной системы определяет также статус вывода. Если устройству требуются команды для печати и запрос, которые отличаются от используемых по умолчанию, можно определить наборы команд (command sets). Для этого выберите ►Spool Administration • Output devices для выбора предпочтительного принтера и используйте Edit • Command Set для присвоения существующего набора команд принтеру. Или же можно ввести букву в поле ID набора команд, а затем дважды щелкнуть мышью, чтобы определить новый набор команд; ввести команду печати, которую надо использовать, и команду для запроса статуса. Все устройства, созданные с методом доступа L, могут затем использовать новую команду. Настройки по умолчанию для команд печати и команд запроса статуса хранятся в параметрах инстанции rspo/host_spool/print и rspo/host_spool/query. Например, для систем Windows NT будет использоваться команда печати

□ rspo/host_spool/print = print /d:&P &F,

где /d означает опцию подключения принтера, &Р — макрокоманду подстановки порта (LPT1, СОМ1 и т.п.), a &F — файл для печати.

► Метод доступа C: Прямой вызов операционной системы

Для метода доступа C в отличие от метода доступа L данные не сохраняются временно в файле на хост-системе, а передаются сразу системному диспетчеру печати через интерфейс программирования. Этот метод доступа может применяться только в системах Windows NT.

Рис. 11.9. Метод локального доступа: сервер спула и хост-спул выполняются на одном компьютере

► Метод доступа E: Внешняя система управления выводом

Если устройство, обслуживаемое системой управления выводом (OMS — Output Management System), должно быть сделано доступным для печати из системы SAP R/3, то можно присвоить устройству локальный метод доступа E после установки OMS и определения ее свойств в системе SAP R/3. По большей части, как и в случае процесса с методом доступа L, сервер спула сохраняет данные в файловой системе: локальная установка OMS извлекает их оттуда.

► Метод доступа P: Пул устройств

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

- Параллельно всем устройствам вывода в пуле

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

Все устройства в пуле создаются в системе SAP R/3 со своим собственным методом доступа; к ним можно обращаться по отдельности по именам принтеров.

► Метод доступа F: Печать с фронтального компьютера

Метод доступа F можно использовать для прямого вывода на принтеры, которые могут быть доступны фронтальным персональным компьютерам, но не обязательно определены в системе SAP R/3. Поэтому этот метод доступа не разрешен для промежуточной печати из фоновых заданий. Обработка фронтальной печати выполняется также рабочим процессом спула. Можно использовать параметр инстанции rdisp/wp_no_spo_Fro_max для ограничения числа доступных рабочих процессов для фронтальной печати, чтобы избежать блокирования обычных запросов печати. Немедленный вывод с помощью метода доступа F (и на фронтальных машинах Windows) передается программе SAPLPD, которая запускается, если требуется, автоматически. Она посылает запрос принтеру по умолчанию — _DEFAULT. Если принтер по умолчанию не определен, как в случае систем UNK, должен быть определен хост-принтер в определении устройства для фронтальной печати.

Методы удаленного доступа

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

► Метод доступа S: Печать с помощью протокола SAP

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

► Метод доступа U: Печать с помощью протокола Беркли

Метод доступа U служит протоколом обмена для систем спула в системах UNIX. В отличие от метода S данные здесь не сжимаются. Метод доступа U можно применять в системах Windows вместе с программой SAPLPD, хотя здесь предпочтительнее метод доступа S. Сетевые принтеры со своим собственным спулером операционной системы также соединяются с помощью метода доступа U.

Рис. 11.10. Метод удаленного доступа: сервер спула и хост-спул выполняются на различных компьютерах

Специальные методы доступа

Для вывода на устройства, отличные от принтеров, существуют специальные методы доступа:

► Метод доступа X: Соединение с факсом с помощью SAPcomm

Метод доступа X присоединяет факсы через интерфейс SAPcomm. Начиная с Basis Release 6.10, этот интерфейс больше не поддерживается; вместо него можно использовать SAPconnect (см. главу 13).

► Метод доступа I: Соединение с ArchiveLink

Этот метод доступа используется с SAP ArchiveLink (см. главу 12). Система спула применяется только для временного хранения архивируемых документов. Дальнейшую обработку выполняет SAP ArchiveLink.

Определение устройства вывода

Для определения устройств вывода и назначения их выбранным серверам спула действуйте следующим образом:

1. В простом, расширенном или полном управлении в ►Spool administration выберите пункты меню Configuration • Output devices или кнопку Output devices. Перейдите в режим изменений. В списке уже определенных принтеров выберите Output device • Create, чтобы перейти на экран для Spool Administration: Create Output device (см. рис. 11.11).

Рис. 11.11. Создание логического принтера — атрибуты устройства

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

3. Выберите для принтера подходящий тип устройства SAP и присвойте его логическому или реальному серверу спула. В типичных случаях подходящий тип устройства уже определен в системе SAP R/3, так как типы устройств представляют семейство моделей, а не конкретные модели. Если требуется, можно также загрузить дополнительные типы устройств со служебных компьютеров SAP — sapserv[x] (см. главу 3), использовать режим совместимости многих моделей или ввести тип устройства SWIN (b средах Windows) для выполнения форматирования диспетчером печати и драйвером Windows вместо рабочего процесса спула SAP R/3. Можно также определить собственные типы устройств, хотя это и непростая задача.

4. Существуют следующие классы устройств:

- Стандартный принтер

- Программа архивирования

- Факс

- Телекс

- Пул устройств (как отдельный класс устройств, начиная с Basis Release 6.10)

- Логическое устройство вывода (как отдельный класс устройств, начиная с Basis Release 6.10)

5. Используйте поле Authorization group для объединения группы устройств вывода, которую можно ввести в определении авторизации вместо ввода отдельного устройства.

6. Используйте поля Model, Location и Message для поясняющего текста. Обзор всех определенных устройств вывода покажет содержимое поля сообщений Message; будет выводиться значение поля Location, если поле Message будет пустым. Принтер можно заблокировать для работы по обслуживанию со стороны SAP R/3.

7. Поле Host spool access method определяет коммуникации между сервером спула и спулом хоста (см. рис. 11.12).

8. Используйте поле Host printer для ввода имени устройства, как оно определено на уровне операционной системы, например \\host\printername или _DEFAULT. Для локального доступа здесь выводится компьютер, на котором выполняются сервер спула и спул хоста. Для удаленного доступа необходимо явно определить хост назначения, который получает данные.

Рис. 11.12. Создание локального принтера — доступ к спулу хоста

9. Из системы SAP R/3 можно проследить статус запроса печати после его пересылки в систему спула хоста. Это делается с помощью явного запроса активного рабочего процесса спула. Чтобы избежать этого, а также потерь производительности, можно активировать флажок Do not query host spooler for output status. Явный запрос не может происходить с фронтальной печатью. Здесь и при деактивации запроса на спуле хоста запрос в системе спула считается завершенным, когда он переносится в процесс спула хоста.

10. Можно выбрать Monitor using monitoring architecture для важных устройств вывода (см. рис. 11.13).

11. Параметр Process requests sequentially обеспечивает, что запросы для этого устройства выполняются в том порядке, в котором они были запрошены. Здесь настройка устройства имеет приоритет над определением выравнивания нагрузки сервера спула.

12. Можно использовать вкладку Tray info для прямого обращения к лоткам для бумаги устройства вывода.

13. Устройство классифицируется с помощью Edit • Classification.

Рис. 11.13. Создание локального принтера — атрибуты вывода

14. Для каждого устройства можно явно определить, где будут помещаться данные для печати для промежуточного хранения: в базе данных в соответствии с системными настройками (см. раздел 11.5) или в файловой системе. Выберите Edit • Data storage.

При необходимости можно присвоить отдельные или все определения устройств запросу переноса и перенести их на другие системы SAP R/3.

Если необходимо обеспечить большую гибкость архитектуры спула, то, начиная с Basis Release 6/10, можно определить логические устройства вывода с назначением физическим устройствам вывода. В версиях Basis до Release 6.10 возможно преобразование физического устройства в логическое и наоборот.

Внешние системы управления выводом

Интерфейс XOM-API позволяет подключать к системе спула SAP R/3 внешнюю систему управления выводом (OMS — Output Management Systems). Системы OMS применяются в основном в сложных системных инфраструктурах. Соединение R/3 с OMS позволяет использовать в R/3 все преимущества OMS. Система OMS дает более точную и непосредственную информацию о состоянии запросов вывода. В ряде случаев ее использование очень полезно.

ROMS и LOMS

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

Определение внешней OMS

Чтобы использовать внешнюю систему OMS, нужно определить в системе SAP R/3 ROMS и при необходимости — LOMS. Этот шаг является частью расширенного или полного администрирования спула. Для определения внешних OMS нужно иметь точную информацию о системе спула на каждом сервере. Изучите документацию по OMS и определите атрибуты своей системы ROMS. Используемое для этого окно показано на рис. 11.14. Для вывода данного окна выберите меню ►Spool Administration Configuration • Output Management Systems или используйте вкладку Output Management System.

Рис. 11.14. Определение ROMS

11.5. Анализ и устранение ошибок

11.5.1. Использование статистики

Есть два способа отслеживания операций спула SAP R/3:

1. Выберите ►Output control.

2. Для целей статистики выберите ►Spool administration • Administration • Request overview.

► Output control может вывести все запросы спула и вывода или запросы, выбранные согласно различным критериям, таким как пользователь, дата, устройство вывода или номер запроса (см. рис. 11.15). Полномочия определяют, может ли один пользователь видеть запросы другого и управлять действиями, разрешенными для ожидающих запросов спула. Такие действия могут включать повторный вывод запроса спула, перенаправление на другой принтер или просмотр их содержимого.

Пользователи могут также переходить с помощью System • Own Spool Requests к обзору своих собственных запросов спула.

Рис. 11.15. Обзор запросов спула

Таблица 11.1. Состояние спула и запросов вывода

ID	Состояние
-	He существует запроса вывода
+	Генерируется запрос спула
waiting	Запрос вывода еще не обработан
in proc	Запрос форматируется
printing	Запрос печатается спулером хоста
compl	Запрос успешно напечатан или перенесен на спулер хоста
<F5>	Запрос спула создал несколько запросов вывода, все с различными состояниями
Problem	Запрос был напечатан, несмотря на незначительную проблему, но вывод, вероятно, содержит ошибки
Error	Запрос спула не может быть напечатан
Archive	Запрос был обработан и ожидает архивации
Time	Было спланировано специальное время для вывода запроса

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

При проблемах с печатью всегда необходимо сначала проверить работоспособность устройства на уровне операционной системы. Для этого нужно использовать команды, специфические для операционной системы, такие как lpr или print. Если к устройству невозможно обратиться на уровне операционной системы, то к нему нельзя обратиться и из системы SAP R/3.

Можно вывести содержимое, выбранные для генерации настройки, журнал вывода (но только для запросов вывода) и статистические данные для каждого спула и запроса вывода, перечисленные в ►Output control.

Обзор запросов вывода в ►Spool administration включает конфигурационные функции системы спула и статистическую информацию, такую как число запросов печати на устройство, на хост назначения или на пользователя (см. рис. 11.16).

Рис. 11.16. Обзор запросов печати

Эта информация представляет интерес, когда оценивается общая структура устройств вывода. Нагрузка должна быть разделена между инстанциями SAP R/3 как можно равномернее.

11.5.2. Административные задачи

Проверка установки

Немедленно после первой настройки системы или после значительных изменений в структуре спула рекомендуется проверить конфигурацию с помощью ►Installation check. Эта проверка не включает данные спула (запросы спула и вывода или TemSe).

Обслуживание объектов TemSe

Данные запроса спула (неформатированные) хранятся во временных последовательных объектах (TemSe). Эти объекты содержат данные спула и аналогичные данные, такие как журналы фоновых заданий и временные данные FI и HR. Физически TemSe является таблицей в базе данных или файлом (вне базы данных) в файловой системе сервера приложений или в глобальном каталоге системы SAP R/3. Точное расположение зависит от параметра инстанции rspo/store_location. Значением по умолчанию является «db», что означает хранение в базе данных. Задание значения параметра как «G» сохраняет данные в глобальном подкаталоге в дереве каталогов SAP (см. главу 1). Если данные хранятся в базе данных, то они подчиняются административным методам и мерам безопасности РСУБД: управлению транзакциями и журналами, а также регулярному резервному копированию. Однако это означает также, что РСУБД должна выполнять некоторую работу, поэтому доступ к TemSe в файловой системе будет быстрее. Если TemSe хранится в файловой системе, нагрузка на РСУБД снижается, но преимущества, которые предоставляет РСУБД, недоступны. Например, резервные копии данных должны создаваться отдельно, и они не включаются автоматически в системную копию.

Статистическую информацию можно найти на уровне заполнения и содержимого TemSe с помощью ►TemSe Management или ►Spool administration • Environment • TemSe administration. Выберите TemSe database • Memory allocation (или TemSe data storage • Memory Occupation с версии Basis Release 6.10) для просмотра списка всех данных, хранящихся в TemSe для пользователя и клиента, включая пространство для хранения данных, которое требуется каждому пользователю и клиенту. Когда TemSe хранится в базе данных SAP R/3, размер сегментов базы данных ограничивает размер хранилища данных TemSe. Если данные хранятся в файлах на уровне операционной системы, то максимальный размер файловой системы является максимальным размером TemSe. Однако соображения производительности предполагают поддержание базы данных TemSe как можно меньшего размера.

Реорганизация системы спула

Администратор должен обеспечить удаление запросов спула из TemSe, когда они больше не требуются. Необходимо регулярно выполнять отчет RSPO1041 (см. главу 9 и рис. 11.17). Существенные критерии выбора включают возраст запроса спула (в зависимости от его статуса) и данные о том, не устарел ли он. Запрос спула является устаревшим, когда истек его срок хранения. По умолчанию срок хранения запроса спула — восемь дней (см. рис. 11.1). Можно также автоматизировать удаление устаревших запросов спула с помощью ►Spool Administration • Settings • Spool system • Admin.

Отчет RSPO1041 удаляет только данные спула из TemSe. Для удаления других типов данных нужно использовать отчет для журналов фоновой обработки RSBTCDEL (см. главу 9).

Для применения RSTS0022 используйте путь меню ►TemSe management • TemSe database • Reorganization. Этот путь меню не запускает отчет RSPO1041 или его предшественника RSPO0041. Отчет RSTO0022 необходимо выполнять с большей осторожностью, чем это требуется для двух других отчетов, так как он удаляет все устаревшие записи из TemSe без учета зависимостей от других таблиц.

Проверка согласованности

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

► Проверка согласованности системы спула

Спланируйте ежедневное выполнение отчета RSPO1043 (см. главу 9).

► Проверка согласованности хранилища данных TemSe

Можно спланировать регулярное выполнение этого отчета через ►TemSe management • TemSe database • Consistency check или определяя отчет RSTS0020.

Рис. 11.17. Выбор критериев для удаления запросов спула

11.6. Использование полномочий

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

► Полномочия на устройства — S_SPO_DEV

► Полномочия на выбор — S_ADMI_FCD

► Полномочия на операции с запросами спула — S_SPO_ACT

► Полномочия на управление TemSe — T_TMS_ACT

► Полномочия на ограничение максимального числа печатаемых страниц — S_SPO_PAGE

Полномочия на устройства

Полномочия на устройства определяют устройства вывода, для которых пользователь может генерировать запросы. Для этого реальное или базовое имя одного или нескольких устройств вывода или группы полномочий присваивается объекту полномочий (см. рис. 11.11). При определении устройств вывода полезно придерживаться соглашений по именам. Например, если первый символ в имени принтера означает для всех настольных принтеров имя группы (такое как «D»), то будет проще назначать полномочия конкретным группам устройств вывода.

Полномочия на выбор

Объект полномочий S_ADMI_FCD определяет, какие именно устройства вывода может просматривать пользователь. Все пользователи могут выводить на экран информацию о своих запросах спула с помощью команды System • Own spool request. Вывод запросов спула в общем выполняется с помощью ►Output control. Значениеполномочий SPOR расширяет права, позволяя выводить запросы спула всех пользователей на том же клиенте. Чтобы предоставить пользователю права на просмотр всех запросов спула на всех клиентах, ему нужно назначить значение полномочий SP01.

Полномочия на операции

Объект полномочий S_SPO_ACT определяет, какие действия пользователь может выполнять с видимыми ему запросами спула. Доступные значения полномочий перечислены в таблице 11.2.

Таблица 11.2. Значения полномочий для объекта S_SPO_ACT

Значение	Какие полномочия оно предоставляет
BASE	Вывод на экран всех запросов спула
ATTR	Изменение атрибутов запроса
AUTH	Изменение значений полномочий
DISP	Вывод на экран содержимого запроса спула
DELE	Удаление запросов спула
PRNT	Первый вывод
REDI	Переадресация запроса спула на другое устройство
REPR	Повторение запроса вывода

11.7. Советы

► Максимальное число запросов спула

Максимальное число запросов спула, которое можно использовать в системе, равно 32000. С некоторыми дополнительными усилиями это число можно увеличить до 99000.

► Приоритеты

Каждому запросу спула можно присвоить приоритет от 0 до 9; 0 является самым высоким приоритетом. Значением по умолчанию является 5. Это значение пересылается спулу хоста; сама система спула SAP его не проверяет.

► Ограничение видимости принтеров в клиентах

Если желательно сделать принтеры, которые заданы для всей системы, доступными только из определенных клиентов, используйте путь меню ►Output control • Configuration • Output devices. Выберите устройство и затем ►Extras • Display client field.

► Нагрузка на сеть

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

► Вывод кодовых страниц, не являющихся Latin 1, на стандартные принтеры

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

11.8 Транзакции и пути доступа меню

Проверка установки: нет записи в стандартном меню SAP (SPIC).

Управление выводом: SAP Menu • Tools • CCMS • Spool • Output controller (SP01)

Управление спулом: SAP Menu • Tools • CCMS • Spool • Spool Administration (SPAD)

Управление TemSe: SAP Menu • Tools • CCMS • Spool • TemSe administration (SP12)

11.9. Дополнительная документация

Быстрые ссылки

► SAP Service Marketplace: псевдоним output

Указания SAP Service Marketplace

Таблица 11.3. Указания SAP о системе спула

Содержание	Указание
Collective note on spool and printing	504952
Flexible design of the spool service in SAP R/3	118057
R/3 does not print	26009
How many spool work processes per instance?	108799
Front-end printing: collective note	114426
Front-end printing with HTML GUI	351230
Setting up front-end printing as of SAP R/3 4.6B	351492
Printing under Windows Terminal Server	150533
Printing over e-mail	311037,513352 только для SAP R/3 4.5B
LPD for remote printing	2863
Printing to a file	161516
Cannot reach SAPLPD	10758
Device type SAPWIN	21738
List of supported printers	8928
Printing Asian languages	423003, 83502
Printing to a file on tape	6753
Authorizations of spool requests	29666
Reorganization of TemSe and spool	48400

11.10. Контрольные вопросы

1. Что из перечисленного ниже относится к методам доступа?

a. Локальные методы доступа

b. Удаленные методы доступа

c. Специальные методы доступа

d. Методы доступа с форматированием

e. Методы доступа без форматирования

f. Внутренние методы доступа

g. Внешние методы доступа

2. Для каких полномочий SAP R/3 предусмотрены объекты полномочий?

a. Полномочия на устройства

b. Полномочия на просмотр запросов спула

c. Полномочия на администрирование TemSe

d. Полномочия на операции с запросами спула

3. Какое из следующих утверждений правильно?

Запрос вывода:

a. генерируется рабочим процессом спула из запроса спула

b. можно напечатать несколько раз

c. можно вывести на любой принтер

4. Какой метод доступа рекомендуется использовать для массовой печати?

a. Локальный метод доступа L для передачи спулу хоста с помощью соответствующего командного интерфейса

b. Локальный метод доступа С для прямой передачи диспетчеру печати спула хоста с помощью соответствующего командного интерфейса

c. Локальный метод доступа F для печати на клиентской системе

d. Удаленный метод доступа S для печати на принтерах на рабочих местах через SAPLPD

e. Удаленный метод доступа U на основе протокола Berkeley

5. Что такое выделенный сервер спула?

a. Выделенный сервер приложений в системе SAP R/3, который используется для централизованного управления спулом

b. Сервер приложения, назначенный определенному в системе SAP R/3 устройству вывода. Сервис спула выделенного сервера спула осуществляет обработку и администрирование запросов спула, направляемых на это устройство

c. Клиентский компьютер (настольный ПК), используемый в настоящее время для печати

d. Сервер приложений в системе R/3, явным образом назначаемый пользователю как сервер спула

ГЛАВА 12 АРХИВИРОВАНИЕ ДАННЫХ

Термин «архивирование» в среде R/3 может описывать одну из трех областей:

► С точки зрения администрирования БД Oracle архивирование часто означает автономное сохранение журналов восстановления.

► Сохранение входящих и исходящих документов, таких как введенные счет-фактуры и подтверждения заказов, или вывод списков, созданных в системе R/3 или внешних системах хранения (раньше в бумажной форме или на микрофишах, сейчас обычно на оптических носителях) также является формой архивирования.

С помощью интерфейса SAP ArchiveLink в соответствии со специфическим для ситуации Customizing можно создать связь между архивированными документами и документами приложений, выделенными в систему SAP. Исходные документы хранятся на внешнем носителе и связываются таким образом с бизнес-объектами R/3; они могут быть доступны из бизнес-транзакции или прикладного документа. Начиная с версии R/3 Release 4.6C, интерфейс ArchiveLink основывается на технологии HTTP Content Server. Хранение архивных файлов во внешних системах выполняется с помощью Content Management Service (CMS).

► Наиболее важной задачей системного администратора является сохранение и обслуживание данных бизнес-процессов, которые были завершены в системе R/3. Поскольку эти данные больше не будут изменяться, они уже не нужны в базе данных. Поэтому их можно сжать и сохранить в архивных файлах на уровне операционной системы и, когда потребуется, перенести во внешние системы хранения

Зачем нужно архивирование

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

Требования, предъявляемые к архивированию

По различным причинам может потребоваться хранить данные таким образом, чтобы при необходимости их можно было прочитать и использовать. Нередко при этом требуется также гарантировать защиту данных от изменений. Для этого хорошо подходит архивирование на носителях WORM (Write Once, Read Multiple — однократная запись, многократное чтение) , DVD или CD-ROM.

При архивировании данные в базе данных системы R/3, которые больше не требуются для непосредственного доступа, идентифицируются, извлекаются и сохраняются сначала в сжатой форме в файлах на уровне операционной системы. Оттуда эти данные можно, например, перенести на одну из внешних систем памяти, упомянутых выше. После успешного извлечения и архивации данные удаляются из самой базы данных. В зависимости от используемой РСУБД вновь освобожденное пространство в базе данных будет доступно для использования после реорганизации.

12.1. Комплект инструментов архивирования (Archive Development Kit)

Объекты архивирования

Объекты архивирования являются базовым компонентом архивирования данных в системе R/3. Объект архивирования — это логическая единица связанных физических данных, например документы бухгалтерского учета, основные данные банка, заявки, данные по командировкам или бухгалтерские ведомости. В них входят и программы, необходимые для архивирования данных, такие как программы редактирования, чтения, записи и удаления (см. рис. 12.1). Данные в объектах архивирования можно архивировать только все вместе, тем самым поддерживается логическая согласованность базы данных. Примером объекта архивирования из области mySAP Financials является объект FI_DOCUMNT (документы финансового учета). Среди всего прочего он состоит из данных таблиц BKFT, BSEG и BSET в дополнение к текстам SAPscripts и документам изменения и программам для:

► Архивирования (выбора данных из таблиц и последующей записи их в архивные файлы)

► Удаления (сравнения данных, записанных в архивные файлы с данными, все еще находящимися в базе данных, и удаления последних, если данные согласованы)

► Перезагрузки (в критической ситуации)

► Разборки на части и перестройки индекса (для прямого доступа после архивирования)

Кроме того, поставляется более десяти программ анализа. Можно также использовать Transaction FB03 для непосредственного чтения архивированных документов.

Рис. 12.1. Структура объекта архивирования

Если архивирование данных должно выполняться для данных, принадлежащих бизнес-объекту, который не определен в стандарте SAP, необходимо сначала определить, какие физические данные принадлежат объекту, в какой форме они должны быть архивированы и какие требуются функции обработки. Объекты архивирования уже определены для стандартных бизнес-процессов SAP. Дополнительные объекты архивирования для добавленных специфических для заказчика процессов можно создать требуемым образом с помощью ►Definition of archiving objects.

Комплект инструментов архивирования (ADK)

Комплект инструментов архивирования (ADK — Archive Development Kit) представляет собой интерфейс между приложением SAP, базой данных и архивными файлами, в которых извлеченные данные приложения должны быть сохранены. ADK предоставляет функциональные модули, позволяющие программам объектов архивирования записывать подготовленные архивные данные в каталоги вне базы данных в предопределенном формате (см. рис. 12.2). Кроме того, ADK управляет файлами архивирования на уровне операционной системы и сеансами архивирования.

Рис. 12.2. Комплект инструментов архивирования (ADK)

Процедура архивирования выполняется в три этапа:

1. Извлечение данных из базы данных и создание архивных файлов.

2. Возможный перенос архивных файлов во внешнюю среду хранения.

3. Запуск программы удаления.

Этап 1

Соответствующий отдел пользователей определяет, какие данные можно архивировать. Обычно администратор системы R/3 отвечает за техническое выполнение процесса архивирования, а не за оценку значимости бизнес-данных. Объем данных архивирования определяется соответствующими объектами архивирования и определением периода архивации. Все данные, созданные за этот период, архивируются. Фоновый процесс, запускаемый системным администратором, копирует определенные таким образом данные в предопределенном формате в указанный каталог на жестком диске, вне базы данных. Предопределенные данные соответствуют данным, извлеченным из базы данных в метаформате, независимом от РСУБД и оборудования. Помимо реальных данных также сохраняются данные об используемых кодовых страницах, структуре записей или форматах чисел. Эти данные требуются для обеспечения правильной интерпретации архивированных данных при любом последующем доступе чтения. Одновременно данные сжимаются максимум с коэффициентом 5, за исключением кластерных таблиц, так как они уже хранятся в базе данных в сжатом формате. Начиная с версии R/3 Enterprise, можно архивировать также данные в формате Unicode. Можно обращаться к архивированным файлам, использующим и не использующим Unicode, для чего не требуется преобразовывать существующие архивные файлы.

Этап 2

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

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

Чтобы обеспечить регламентированную коммуникацию между системой SAP и системой архивирования, SAP AG предлагает процесс сертификации для поставщиков архивов. Дополнительную информацию о сертифицированных поставщиках можно найти в Интернете по адресу http://www.sap.com в разделе partners/software/directory.

Если используется Система управления иерархическим хранилищем (HSM System), можно просто сохранить архивные файлы в каталоге в системе HSM. В этом случае ArchiveLink не используется. Перенос архивных файлов на уровень поддержки (жесткий диск, накопитель со сменными дисками, магнитная лента) управляется стратегиями доступа и реализуется с помощью HSM. Для системы R/3 HSM представляется как бесконечно большая файловая система, в которой к архивным файлам всегда обращаются под одним и тем же именем независимо от их реального расположения.

Рис. 12.3. Перенос архивных файлов

Кроме соединения с системой архивирования, возможно также сохранение вручную архивных файлов, созданных на этапе 1 в другой среде, такой как магнитная лента.

Этап 3

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

► Удаление данных из базы данных, когда файл архивирования был создан.

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

► Удаление данных из базы данных после переноса архивного файла во внешнюю систему хранения.

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

Начиная с R/3 Enterprise, программа удаления может планироваться независимо от реального архивирования как периодическое фоновое задание.

12.2. Пользовательская настройка

Выбор данных для архивирования

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

Первая задача состоит в преобразовании представления приложения в техническое представление БД R/3. Необходимо определить, какой объект архивирования лучше всего отвечает этим требованиям. Иногда объекты архивирования логически и хронологически связаны друг с другом. Возьмем в качестве примера объект архивирования MM_MATNR (главная запись материала из компонента mySAP Logistics). Объект такого типа нельзя архивировать пока существуют объекты, ссылающиеся на главную запись материала, и которые еще не архивированы. Поэтому, если все еще существует документ закупки (объект ММ_ЕККО), который ссылается на главную запись материала, заданную для архивации, и который еще не был сам архивирован, то сеанс архивирования для ММ_ MATNR будет прекращен с сообщением об ошибке.

Взаимосвязь между архивированием объектов можно проиллюстрировать с помощью сетевого графика (см. рис. 12.4), который доступен через ►Archive Administration Initial screen • Goto • Network graphic. Иерархическое представление архивируемых объектов и их взаимосвязей показывает, в каком порядке они должны быть архивированы для достижения оптимального хранения данных. Каждый архивируемый объект символизируется узлом внутри сетевого графика. Цветной прямоугольник в каждом узле показывает статус архивирования объекта.

Рис. 12.4. Сетевой график для объекта MM_MATNR

Отношения между архивируемым объектом и соответствующими таблицами можно проанализировать с помощью компонента ADK ►Tables and archiving objects. Здесь перечислены все таблицы, данные из которых включаются в выбранный: объект архивирования; все архивируемые объекты, содержащие данные из выбранной таблицы, также выводятся. В принципе можно архивировать только согласованные объекты.

На рис. 12.5 показан существующий архивируемый объект для таблицы RFBLG, который называется FI_DOCUMNT — документ финансового учета. Также показаны все таблицы в объекте FI_DOCUMNT.

Объем данных, подлежащих архивированию

После выбора объекта архивирования данных нужно определить объем данных, подлежащих архивированию. Чтобы определить, даст ли архивирование какой-нибудь выигрыш, нужно получить информацию о текущем физическом и логическом размере таблиц в базе данных объекта. Физический размер — это фактическое пространство памяти, занимаемое в БД. Логический размер — это число записей в таблице. Есть два метода анализа размера, которые в сильной степени зависят от БД.

Используйте Online space в ►Tables and Archiving Objects (см. рис. 12.5) для определения текущего размера выбранной таблицы, если база данных позволяет анализировать ее размер. В зависимости от используемой РСУБД будет выведен фактический физический размер таблицы или определяемое базой данных статистическое значение. Может потребоваться несколько минут для вывода в зависимости от процесса и размера таблицы.

Рис. 12.5. Таблицы и объекты архивирования

Можно использовать Space Statistics, если будет достаточно статистики, собираемой оптимизатором SQL. Размеры определяются на основе статистики не точно, а по выборке на время последнего обновления статистики оптимизатора. Если с момента последнего обновления прошло достаточно много времени, то таблица может существенно измениться. Это нужно принимать во внимание при определении размера таблиц. Все РСУБД, применяемые с R/3, работают с оптимизаторами на основе стоимости; доступ к содержанию таблиц осуществляется на основе статистических данных, описывающих рост таблицы и распределение в ней данных. Таким образом, в зависимости от используемой БД администратор БД должен регулярно обновлять статистические данные.

Конфигурация архива

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

Выбрав Database Tables, можно опять увидеть все таблицы в объекте архивирования. Выбирая Information system, можно перейти прямо к информационной системе архивирования. Чтобы начать выполнение архивирования для выбранных объектов, необходимо выполнить некоторые настройки. В частности, необходимо решить, куда будут записываться архивируемые данные. Это делается в настройке (Customizing), которая делится на четыре области:

► Настройка, общая для всех объектов архивирования

► Настройка, зависимая от объекта архивирования

► Базовая настройка

► Настройка, зависимая от приложения

Рис. 12.6. Начальный экран управления архивом

12.2.1. Настройка, общая для всех объектов архивирования

Задаваемые здесь параметры действительны для всех приложений и для всех объектов архивирования. Они относятся к следующим областям:

► Монитор данных архивирования CCMS

► Контроль доступа при выборе архива

► Проверка архивных файлов

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

Доступ к архивным файлам

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

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

Для R/3 Enterprise можно определить максимальную длительность (в часах) или максимальный размер архивного файла для сеанса архивирования (фаза записи). Когда будет достигнуто ближайшее из этих ограничений, выполнение архивирования останавливается, и в заданное время его можно возобновить в том же месте.

12.2.2. Настройка, зависимая от объекта архивирования

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

На рис. 12.7 показаны возможные технические настройки для объекта архивирования FI_DOCUMNT. Чтобы сохранить архивные файлы, необходимо определить путь доступа каталога сохранения и имена файлов в этом каталоге для реальных архивных данных. Логическое имя файла ARCHIVE_DATA_FILE является значением по умолчанию для независимого от операционной системы имени создаваемого архивного файла. Логическое имя ARCHIVE_GLOBAL_PATH присваивается пути доступа. Во время выполнения генерируется зависящее от платформы имя. Размер архивного файла ограничен аппаратными такими факторами, как максимальный размер файловой системы и емкость среды резервного копирования (CD, DVD, WORM). Если размер не определен, то размер архивного файла ограничен 2 Гбайт. Если программа архивирования видит, что при записи следующего объекта максимальный размер, заданный для файла архива, или максимальное число определенных здесь объектов данных будет превышено, то создается новый архивный файл. Для обоих параметров — Maximum size in MB и Maximum number of data objects — предполагаются значения по умолчанию, зависящие от объекта.

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

Рис. 12.7. Настройка, зависимая от объекта архивирования

На первом этапе архивирования копия архивируемых данных просто создается в файлах за пределами базы данных. Последнюю фазу архивирования — удаление успешно скопированных данных — можно сконфигурировать для автоматического выполнения после фазы 1. Если архивные файлы переносятся во внешнюю систему хранения, можно выбрать удаление данных в базе данных — перед или после сохранения. Архивные файлы на уровне операционной системы или в системе хранения используются для сравнения данных перед удалением.

Индекс

В процессе удаления можно начать создавать индекс с выбранными объектами архивирования, используя параметр Build index. Индекс позволяет выбирать с помощью ADK отдельные объекты данных в архивном файле. С точки зрения базы данных удаление, в отличие от копирования данных, является транзакцией изменения и записывается в журнал РСУБД. Следовательно, администратор базы данных должен гарантировать, что области, необходимые для обеспечения исходного образа в случае отката транзакции базы данных — например, сегмент отката в Oracle — сконфигурированы достаточного размера. Можно использовать различные варианты, чтобы осуществить следующие настройки для тестового и производственного сеансов:

► Тестовый сеанс

► Подробный журнал

► Перезапуск после прерывания

► Удаление собственного кода поиска

В области Setting for post-processing program и Variants можно определить дополнительные спецификации приложений. Эти настройки зависят от клиента, что означает, что при необходимости они должны определяться отдельно для каждого клиента.

Репозиторий содержимого

Размещение в подчиненной системе хранения производится с помощью введения репозитория содержимого, который должен быть перед этим определен в ►Maintain content repository.

12.2.3. Базовая настройка

Можно задать имя физического файла, которое на рисунке 12.7 скрыто за логическим именем файла ARCHIVE_DATA_FILE, либо для всех клиентов с помощью ►Logical file name, либо, если требуется, в зависимости от клиента с помощью ►Logical file name (client-specific).

На рис. 12.8 показано определение имен файлов и путей доступа для всех клиентов. Физическое имя файла для всех клиентов можно присвоить каждому логическому имени файла.

12.2.4. Настройка, зависимая от приложения

В зависимости от выбранного объекта архивирования необходимо также сделать зависимыми от клиента настройки приложений. За эти настройки отвечает менеджер приложений. Для системного администратора важность имеют только технические настройки.

Заключение

При настройке сеанса архивирования необходимо удовлетворять следующие требования:

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

Рис. 12.8. Присвоение логических имен файлов

► Настроить параметры базы данных, особенно для сеансов удаления.

► Настроить параметры архивирования для приложения.

12.3. Управление и анализ

Управление и анализ сеанса архивирования выполняется из ►Archive administration. Операции и последовательность их выполнения зависят от объекта архивирования, поэтому здесь даются лишь общие комментарии. Подробности специфических процедур для различных объектов можно узнать с помощью ►Definition of archiving objects (см. рис. 12.9).

Рис. 12.9. Начальный экран управления архивом для конкретного объекта

Следующий список представляет обзор доступных для управления и анализа сеансов архивирования программ:

► Предварительная обработка (необязательно)

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

► Архивирование

Определяет начальную дату сеанса архивирования и возможные параметры спула (см. рис. 12.10).

При обслуживании вариантов определяют зависимый от приложения выбор данных. На рис. 12.11 показано фоновое задание, автоматически спланированное из этих данных (►Job overview).

Рис. 12.10. Планирование сеанса архивирования

Рис. 12.11. Обзор задания для спланированного сеанса архивирования

► Удаление

Если данные не должны немедленно автоматически удаляться после архивирования, здесь можно задать начальную дату и параметры спула для удаления помеченного в Archive selection архива.

Рис. 12.12. Планирование сеанса удаления

► Последующая обработка (необязательно)

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

► Программы анализа

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

► Индекс (необязательно)

Впоследствии можно создать индекс для существующих архивных файлов. Можно также удалить существующий индекс. В зависимости от приложения индекс архива хранится в таблицах приложения (например, документы FI) или в общей для приложений таблице индекса архива.

► Система хранения

Если перенос архивных файлов во внешнюю систему хранения (storage system) не планируется в зависимой от объекта настройке архивирования, то файлы можно перенести сюда при условии, что репозиторий содержимого, который будет использоваться, уже был использован в настройке объекта архивирования.

► Управление

Управление (management) архивом предлагает обзор всех сеансов архивирования (см. рис. 12.13). Они упорядочены согласно своему статусу. Чтобы вывести данные сеансов, дважды щелкните мышью на требуемом сеансе.

Все программы обработки, которые активируются, выполняются в фоновом режиме.

Перезагрузка

При перезагрузке (reload) данные импортируются из архива обратно в БД. Обычно не требуется заново загружать архивированные данные в базу данных, так как эти данные можно анализировать и получить доступ к отдельным данным непосредственно с помощью ADK. Эту функцию следует использовать лишь в исключительных ситуациях для немедленной отмены действия сеанса архивирования, если, например, критерий выбора для программы архивирования был задан неправильно. Когда же необходимо перезагрузить архивированные данные после длительного периода времени, необходимо сначала убедиться, что все данные, на которые ссылаются перезагруженные данные, доступны в базе данных. Повторный импорт после смены версии не поддерживается. Если для архивированного объекта возможна перезагрузка, то это действие можно активировать с помощью ►Archive administration Initial screen • Goto • Reload.

Рис. 12.13. Управление сеансами архивирования

12.4. Советы

Статистика

Начиная с версии R/3 Enterprise, при выборе Statistics в ►Archive administration можно просматривать обширную информацию о завершенных сеансах архивирования. В частности, можно видеть, сколько данных было реально удалено из базы данных в результате сеанса архивирования (см. рис. 12.14).

Перезапуск после прерывания

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

► Прерывание во время процесса записи

Архивные файлы создаются последовательно; только обрабатываемый файл имеет состояние created. После успешного завершения процесса записи задается состояние active, а записанный файл можно обрабатывать или анализировать с помощью ADK. Если программа записи прерывается, то затрагивается только файл, что записывается в данный момент. Последовательность процесса будет следующей:

- Запустите сеанс удаления для всех закрытых в данный момент архивных файлов.

- В Archive administration пометьте файл из прерванного задания как недействительный.

- Удалите ошибочный архивный файл на уровне операционной системы.

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

► Прерывание во время сеанса удаления

Если прерывание происходит во время сеанса удаления, необходимо проанализировать и исправить проблему с помощью предназначенных для объекта указаний SAP (Notes). Если архивные файлы будут доступны, то после разрешения проблемы можно перезапустить сеанс удаления в любое время. Если невозможно обратиться к реальным архивным файлам, можно уменьшить проблему, копируя читаемую часть данных в новый архивный файл. До прерывания были удалены только данные базы данных, которые читались в архивном файле. Затем запустите сеанс удаления снова с помощью этого файла. Для восстановления архивных файлов потребуются дополнительные отчеты, которые можно получить в службе поддержки SAP.

Информационная система архива

Информационная система архива SAP (SAP AS) является инструментом для поиска в архивах данных R/3, интегрированным в среду архивирования. Поиск и вывод данных выполняется на основе структур архивной информации, которые пользователь может определить и заполнить данными из архива.

Рис. 12.14. Статистика архива

Браузер взаимосвязей документов

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

Дополнительную информацию об архивировании данных в системах SAP можно найти в книге Helmut Stefani "Archiving Your SAP Data", которая опубликована издательством SAP PRESS.

12.5. Транзакции и пути доступа меню

Administration of stored documents: SAP Menu • Tools • Business Documents • Miscellaneous • Stored documents (OAAD)

Archive administration Initial screen: SAP Menu • Tools • Administration • Administration • Archiving • (SARA)

Archive Information System: SAP Menu • Logistics • Agency business • Environment • Archive • Display (SARI); туда можно также попасть через ►Archive administration Initial screen.

ArchiveLink Monitor: SAP Menu • Tools • Business Documents • Environment • ArchiveLink Monitor (OAM1).

Definition of archiving objects: недоступно через стандартное меню SAP (AOBJ)

Document Relationship Browser: недоступно через стандартное меню SAP (ALO1)

Job overview: SAP Menu • Tools • CCMS • Jobs • Maintenance (SM37)

Logical file names: SAP Menu • Accounting • Enterprise Controlling • Executive InfoSystem • Environment • Configuration Menu • Basic Settings • File Names • File Names—Client-independent (FILE)

Logical file names (client-specific): SAP Menu • Accounting • Enterprise Controlling • Business Planning • Environment • Configuration Menu • Basic Settings • File names • Logical file names (SF01)

Maintain content repository: SAP Menu • Tools • Business Documents • Environment • KnowledgeProvider • KPro • Content Repositories (OACO)

Tables and archiving objects: SAP Menu • Tools • CCMS • DB Administration • Data archiving (DB15)

12.6. Дополнительная документация

Быстрые ссылки

► SAP Service Marketplace, псевдоним adk

► SAP Service Marketplace, псевдоним archivelink

► SAP Service Marketplace, псевдоним data-archiving

► SAP Service Marketplace, псевдоним dma

Указания SAP Service Marketplace

Таблица 12.1. Указания SAP по архивированию

Содержание	Указание
Archive file cannot be read	79186
Maintaining logical path and file names	35992
Compiling information sources for archiving R/3 data	71930
Archiving outside of SARA	133707

12.7. Контрольные вопросы

1. Что такое объект архивирования?

a. CD-ROM или WORM

b. Архивные файлы, созданные в результате архивирования

c. Логический блок связанных данных и необходимых для их архивирования программ

2. Что означает «архивирование данных»?

a. Сохранение журналов архивирования

b. Архивирование таких документов, как списки входящих и исходящих, счетов или документов из компонентов приложений

c. Удаление данных из БД и их сохранение в системе архивирования или на отдельном носителе

3. Какое инструментальное средство используется в архивировании данных R/3 для переноса информации в архив?

a. SAP ArchiveLink

b. HSM (Hierarchical Storage Management)

с. ADK (Archive Development Kit)

d. RFC

4. Какое утверждение правильно?

a. Весь процесс архивирования выполняется в ходе обычной работы SAP R/3.

b. Для выполнения архивирования нужно выполнить остановку системы R/3.

c. При генерации файлов архива в R/3 не должна выполняться никакая другая работа.

ГЛАВА 13 РАСПРОСТРАНЕНИЕ И ПЕРЕНОС ДАННЫХ

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

Стандартным сценарием распределенного приложения является Поддержка прикладных связей (ALE — Application Link Enabling). Для технической реализации должны быть определены структуры данных и методы коммуникации. В качестве усовершенствования традиционных процедур реализованы также новые интерфейсы с помощью технологии BAPI.

BAPI

Интерфейс программирования бизнес-приложений (BAPI — Business Application Programming Interface) предоставляет внутренний, а также внешний доступ к данным и бизнес-процессам, определенным в системе SAP R/3. Нижележащими базовыми компонентами этого объектно-ориентированного подхода являются типы бизнес-объектов, которые представляют объекты реального мира в виде программного обеспечения. Стандартные примеры включают план счетов, торговый заказ или закупочную организацию. Эти типы объектов могут быть доступны только с помощью стандартизованных, независимых от платформы методов, которые не зависят также от версии и открыты, — BAPI.

Все типы бизнес-объектов и соответствующие BAPI хранятся в репозитории бизнес-объектов (BOR — Business Object Repository) системы SAP R/3. С помощью ►BAPI Explorer можно получить обзор определенных типов объектов, их методах и характеристиках и сделать изменения. Объекты являются конкретными экземплярами типа объектов.

Кроме специфических методов объектов, некоторые BAPI доступны для всех типов объектов, а именно:

<Object>.Display	Для вывода объекта
<Object>.Delete	Для удаления объекта
<Object>.GetDetail	Для вывода данных объекта

Технически методы реализуются как модули функций. Например, можно использовать BAPI для соединения с внешними программами, а метод распространения ALE — для соединения с бизнес-процессами за пределами системы.

13.1. Адреса назначения RFC

Многие соединения/связи между двумя системами SAP R/3 или системой SAP R/3 и внешней системой основываются на протоколе интерфейса SAP — вызове удаленной функции (RFC — Remote Function Call). С помощью этого протокола приложения могут вызывать функции АВАР в системе SAP R/3, а системы SAP R/3 — внешние приложения (см. главу 1). Функции RFC делаются доступными для внешних программ через динамическиебиблиотеки.

RFC вызывает предварительно определенный модуль функций в партнерской системе; вызывающая программа является клиентом RFC, а «отвечающая» вызванная система — сервером RFC (см. рис. 13.1).

Рис. 13.1. Распределение задач на различные системы

В среде SAP RFC предлагает интерфейс CPI-C, реализованный SAP.

Адреса назначения RFC

Чтобы полностью интегрировать систему SAP R/3 в существующую системную инфраструктуру, предоставленные соединения RFC должны быть идентифицированы как адреса назначения RFC. Часть этого определения делается автоматически, когда система SAP R/3 конфигурируется в инфраструктуре. Например, это включает соединения RFC, требуемые для системы управления транспортом (TMS, см. главу 5), которые создаются, когда система SAP R/3 интегрируется в области транспорта. Во время установки системы SAP R/3 также генерируются адреса назначения RFC для всех относящихся к делу серверов приложений; но зачастую необходимо создавать дополнительные адреса назначения. Типичными примерами из области системного администрирования являются соединения RFC для:

► Копирования удаленного клиента (см. главу 7)

► Настройки центрального управления пользователями (CUA, см. главу 8)

► Мониторинга удаленных систем SAP R/3 с помощью Alert Monitor (см. главу 16)

Чтобы определить адрес назначения RFC, все данные, необходимые для коммуникации с партнерской системой, компилируются с логическим именем. Устанавливается тип коммуникации. Заданное соединение RFC можно использовать любой программой; оно не присваивается какой-то определенной функции или определенному клиенту.

Соединения RFC всегда являются однонаправленными.

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

Таблица 13.1. Типы соединений для адреса назначения RFC

Тип	Описание	Требуемые данные
1	Соединение с сервером приложений с той же самой базой данных	нет
3	Соединение с системой SAP R/3	Целевая машина и системный номер
2	Соединение с системой SAP R/3	нет
Т	Запуск внешней программы через TCP/IP	Зависит от типа активации Start: имя хоста и путь доступа программы Registration: ID программы
L	Ссылочная запись (указывает на другой адрес назначения)	Адрес назначения RFC, для которого создается псевдоним
S	Запуск внешней программы с помощью SNA или АРРС	нет
X	RFC через специальные драйверы подпрограммы АВАР/4	драйвер АВАР/4
M	Соединение CMC	нет

В качестве примера рассмотрим определение нового соединения между двумя системами SAP R/3, «KLU» и «ELU».

1. Сначала с помощью ►RFC Administration выводится список всех известных адресов назначения RFC и сортируется согласно типу соединения (см. рис. 13.2).

Рис. 13.2. Начальный экран управления адресом назначения RFC

2. Щелкните на Create, чтобы открыть поле ввода для нового соединения RFC.

3. Введите логическое имя соединения в поле RFC destination. Необходимо отметить, что после создания этого имени, его невозможно будет изменить.

4. В зависимости от выбранного типа соединения экран автоматически расширится, чтобы включить необходимые поля ввода. На рис. 13.3 показан шаблон для записи данных для соединения RFC с другой системой SAP R/3 (тип соединения 3).

5. Результатом активации параметра трассировки будет подробная запись в файлы на уровне операционной системы выполнения всех программ, использующих это соединение RFC (см. раздел 15.5). Эти журналы можно анализировать с посылающей или принимающей системы с помощью либо программы отчета RSRFCTRC, либо ►RFC Administration • RFC • Display trace.

Рис. 13.3. Создание нового адреса назначения RFC

6. Введите Target host в качестве имени хоста или IP-адрес и System Number инстанции на этой машине.

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

- Явный ввод всех данных в разделе Logon. Чтобы избежать неправомочного использования, здесь должен использоваться пользователь типа communication.

- Использование текущего пользователя. При таком подходе текущий пользователь должен иметь такие же данные пользователя на целевом клиенте.

- Если в разделе Logon не вводятся никакие данные, то данные для регистрации запрашиваются с помощью всплывающего окна, когда используется соединение RFC. Этот метод не подходит для фоновой обработки.

- Если локальная система определена как Trusted system на цели адреса назначения RFC, то не требуется вводить никакие идентификационные данные. Можно создать доверительные отношения между системами SAP R/3 с помощью ►Trusted systems или из ►RFC administration с помощью RFC • Trusted systems или Trusting systems.

- Когда создается соединение RFC с удаленной системой, то предоставленные для соединения данные регистрации используются для авторизации его на удаленной системе. Назначение является статическим. Если, например, пароль пользователя на удаленной системе изменяется, то необходимо проверить определения соединений RFC.

8. Проверьте соединение с помощью Test connection, чтобы избежать проблем в последующем. Обратите внимание на то, что, выполняя ping таким образом, можно проверить только физическую доступность сервера.

В обзоре определенных соединений SAP R/3 (см. рис. 13.2) можно также видеть записи, созданные во время конфигурации TMS. Они всегда начинаются с кода «TMSADM». Для соединений RFC между системами SAP R/3 используется соединение типа 3.

Группы серверов

При определении соединений RFC вместо отдельной целевой машины можно использовать также имена группы серверов приложений. Необходимо, однако, сгенерировать их перед этим с помощью ►RFC administration • RFC • RFC groups или ►Maintenance of Server Groups. Преимущество этого метода заключается в том, что при установлении соединения из группы прикладных серверов выбирается машина с наименьшей нагрузкой, поэтому автоматически происходит распределение нагрузки. Этот механизм используется, например, когда распараллеливают копию большого клиента (см. главу 7). Можно управлять распределением нагрузки в группах серверов, настраивая предварительно определенные параметры ресурсов. Одним из важных параметров является число рабочих процессов, которые должны оставаться свободными.

Соединения TCP/IP

Определение других спецификаций для соединений RFC делается таким же образом. Данные, которые должны вводиться, различаются в зависимости от типа. Для адреса назначения RFC для выполнения внешних программ (соединение типа Т) необходимо сначала разграничить целевые серверы. Можно выбрать между сервером приложений, фронтальной рабочей станцией и явным хостом, который не используется текущей системой SAP R/3. Если внешняя программа должна выполняться на явном хосте, необходимо ввести имя или IP-адрес сервера при определении адреса назначения RFC. Для фронтальных рабочих станций и серверов приложений реальных систем SAP R/3 имена компьютеров уже стали известны во время регистрации в системе. Все серверы должны быть доступны через сеть без нового запроса имени пользователя и пароля. Внешняя запускаемая программа присваивается соединению RFC, которое будет определено.

Вместо явного запуска программы внешнего сервера RFC можно также зарегистрироваться на шлюзе SAP. Зарегистрированная программа ожидает затем запросы от различных систем SAP R/3, направленных на этот шлюз при вводе регистрации.

Логические соединения

Рекомендуется также использовать записи соединения типа L. Они называются логическими записями и ссылаются на другой адрес назначения RFC. Чтобы использовать этот механизм, сначала определяют адрес назначения RFC таким образом, который в конечном счете определяет только физическую цель — выбранный сервер. Затем создаются соединения типа L, ссылающиеся на эту запись. Соединения RFC типа L используют целевой сервер и тип соединения адреса назначения RFC, на который они ссылаются. Если нужно, логическое соединение RFC можно расширить, чтобы включить данные регистрации. Поэтому можно определять соединения RFC независимо друг от друга. Если, например, система SAP R/3 перемещается с одного сервера на другой, то потребуется только настроить адреса назначения RFC, которые используются как точки ссылки для определения соединений типа L.

Типы соединений RFC

Различают несколько типов коммуникации RFC, для которых можно задать дополнительные специальные конфигурационные параметры:

► Синхронный RFC

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

► Асинхронный RFC

Для асинхронного RFC вызывающая программа выдает запрос удаленной системе и немедленно продолжает работать локально. Запрошенный шаг обработки выполняется на удаленной системе независимо. Если удаленная система не может быть доступна во время вызова, асинхронные вызовы клиента RFC теряются.

► Транзакционный RFC

Транзакционный RFC также работает асинхронно, и, выделяя транзакционный идентификатор (ID), он гарантирует, что, если запрос послан несколько раз в связи с сетевыми проблемами, он обрабатывается только один раз. В противоположность асинхронному RFC при транзакционном RFC удаленная система не обязаны быть доступна в момент, когда клиентская программа RFC начинает вызов. Данные находятся в системе источника, пока целевая система не станет доступна. Программа отчета RSARFCSE вызывается в фоновом режиме с регулярными интервалами и пытается снова разместить неудачные запросы, идентифицированные их транзакционный ID.

► Упорядоченные (queued) RFC

Упорядоченный RFC является расширением транзакционного RFC. Для этого варианта запросы собираются в очередь и обрабатываются в транзакционном RFC только в том случае, если все предыдущие вызовы были обработаны соответствующим образом. Эта процедура гарантирует, что запросы обрабатываются в той последовательности, в которой они получены.

Характеристики определенных адресов назначения RFC можно адаптировать по данным, выводимым в определении соединения, с помощью Destination • TRFC options или ARFC options.

Коммуникационные партнеры не всегда могут получить доступ ко всем серверам приложений или серверу сообщений системы клиента RFC. Для присоединенных внешних программ при описании соединения часто требуется определить один конкретный сервер приложений. Если с внешней программой должны общаться и другие серверы приложений, можно определить сервер приложений, известный внешней программе, как шлюз для этого соединения RFC, чтобы вся коммуникация между клиентом RFC и внешней системой происходила через этот сервер приложений.

Мониторинг вызовов RFC

Транзакционные RFC контролируются с помощью ►tRFC Monitor, упорядоченные RFC с помощью ►qRFC Monitor Inbound, ►qRFC Monitor Outbound и ►qRFC Monitor.

13.2. Поддержка прикладных связей (ALE)

Нередко бизнес-процессы на предприятии невозможно представить одной центральной системой. Очень часто причиной этого является деление информационного потока между относительно независимыми подразделениями компании. Другой причиной может быть техническое узкое место, которое возникает в связи с размером одной центральной системы. Вопросы безопасности также могут играть свою роль. Кроме того, может также понадобиться общение с системами внешних программ (например, системой управления хранилищем данных). Если по одной или нескольким причинам невозможно создать систему с центральной конфигурацией, но требуется постоянное согласование данных или поток сообщений, можно попробовать соединить систему с помощью Поддержки прикладных связей (ALE). Учитывая сложность ALE как с технической, так и с прикладной точки зрения, в следующих разделах рассматриваются только основы этой технологии. Наиболее важные моменты работы ALE описаны для будущих системных администраторов.

13.2.1. Технические основы

Поддержка прикладных связей (ALE — Application Link Enabling) является методом и технологией в SAP R/3 для поддержки управляемого деятельностью обмена сообщениями между слабо связанными системами. ALE содержит сценарии деятельности и модули функций, которые позволяют передавать и согласовывать данные системы SAP R/3 без специального участия пользователя.

Вопросы реализации

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

► Какие процессы должны быть представлены в разных системах?

► Какие объекты вовлечены в эти процессы?

► Какие данные должны рассматриваться на различных системах?

► В каком формате должны быть доступны данные, и какая информация должна передаваться для форматирования?

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

► Какую форму будет принимать поток данных между вовлеченными системами?

Технология ALE интегрирована одновременно в приложения и в настройку (Customizing). Она предоставляет ряд служб распространения, и информация может посылаться отправителю в ходе обработки. Часто происходит не только перенос данных: последующие действия также могут запускаться в целевой системе.

Данные обмена

С точки зрения SAP R/3 передаваемые данные включают:

► Данные транзакций — Данные приложений и данные транзакций

► Основные данные — Например, основные данные о заказчиках или материалах

► Данные настройки — Данные, которые обеспечивают однородное, глобальное представление ALE

Данные могут передаваться между системами SAP R/3, между системами SAP R/3 и SAP R/2 и между SAP R/3 и внешними системами. Основным фокусом реализованных сценариев является распространение между системами SAP R/3. Это распространение не зависит от версии системы в максимально возможной степени, что означает, что нет необходимости обновлять все системы SAP R/3 в системной инфраструктуре в одно время. Системы связаны слабыми синхронными (чтение) или асинхронными (изменение) коммуникациями. Технические характеристики соединения задаются в определении порта (port definition). Типы портов соответствуют выбранным методам коммуникации. В настоящее время используются файловые интерфейсы, RFC, CPI-C и интерфейсы Интернета.

Тип сообщения

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

Типы IDoc

Реальная информация может посылаться с помощью промежуточного документа (IDoc — Intermediate Document). Тип IDoc, содержащий описание структуры данных, присваивается типу сообщения как контейнер для данных, которые будут пересылаться. Специальный тип IDoc существует для всех прикладных областей, которые должны готовить данные для обмена. Посылаемые данные, включая таблицы и поля, должны определяться на основе типов IDoc. Когда тип IDoc заполнен конкретными данными в соответствии с правилами структуры, он называется IDoc (промежуточный документ).

Генерация IDoc

В зависимости от приложения для генерации IDoc может использоваться один из трех методов (см. рис. 13.4).

Рис. 13.4. Методы генерации IDoc

Часто IDoc создается прямо из приложения. Прикладная программа либо заполняет внутреннюю таблицу в формате IDoc и переносит ее в службу ALE, либо использует BAPI с интерфейсом ALE.

Вторым методом является генерация IDoc из индикаторов изменения (change indicators). Основой деятельности является автоматическая синхронизация систем в терминах определенных основных данных. Для каждого изменения в наблюдаемом объекте (например, основной записи материала) индикатор изменения записывается для этой записи в таблице базы данных. С помощью планирования отчетов ALE или вручную IDoc генерируется из этих записей изменений и реплицируется в одну или несколько целевых систем.

В третьем методе используется управление сообщениями SAP R/3 для генерации соответствующего IDoc. Отправка сообщения формирует часть стандартных сценариев во многих приложениях, таких как создание заказа на покупку. Сообщение можно напечатать или послать в электронной форме с помощью базовой службы управления сообщениями. Для этого метода рассматриваемое приложение делает записи сообщений типа ALE в таблице NAST. В зависимости от конфигурации записи могут анализироваться либо немедленно системой управления сообщениями SAP R/3, либо с периодическими интервалами с помощью программы отчета RSNAST00; IDoc генерируется из этих записей.

Какой из трех методов будет оптимальным, зависит от приложения; невозможно произвольно выбрать метод по желанию.

Структура IDoc

IDoc состоит из нескольких различных сегментов. Каждый сегмент имеет свое собственное определение структуры и документацию. Для хранения данных используется несколько таблиц на уровне базы данных. IDoc организован иерархически (см. рис. 13.5).

Рис. 13.5. Структура IDoc

Каждый документ IDoc содержит одну управляющую запись, которая состоит из необходимой для переноса технической информации, такой как отправитель, получатель и тип сообщения. Управляющая запись определяет, какие операции обработки необходимы для переносимых данных. Реальные данные сообщения ALE идут после управляющей записи. Данные хранятся в различных сегментах согласно иерархии. Таблица кластеров определяет структуру сегмента и содержит данные, которые будут распространятся, в одном поле. Имя и структура этой таблицы зависит от версии SAP R/3. Третий компонент структуры IDoc является статусной информацией.

За определение обмена данных отвечает настройка (Customizing). Однако техническое определение соединений ALE обычно выполняет системный администратор SAP R/3, работая в тесном сотрудничестве с менеджером приложения или консультантом, отвечающим за прикладную сторону.

13.2.2. Ограничение и ослабление соединения с помощью BAPI

Если распределенный бизнес-процесс должен быть реализован с помощью удаленного вызова BAPI, также можно использовать механизм ALE.

Ограничение соединения

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

Ослабление соединений

Чтобы запустить BAPI на целевой системе асинхронно, можно послать в виде IDoc необходимые параметры интерфейса. Получение этой информации запускает обработку предпочтительного метода на целевой системе с пересланными параметрами.

13.2.3. Конфигурация

В этом разделе используется простой пример в качестве иллюстрации базового процесса для конфигурирования метода распространения ALE между двумя системами SAP R/3. Задача состоит в том, чтобы настроить Central User Administration (CUA, см. главу 8). Основное внимание будет здесь сконцентрировано не на приложении, а на системном администраторе и его задачах.

Процедура состоит из следующих шагов:

1. Определение партнера в инфраструктуре ALE

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

3. Генерация профиля партнера

Точкой входа для ►ALE Customizing является подузел Implementation Guide (см. главу 6).

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

Организация логических систем

Партнеры коммуникации в сценарии ALE называются логическими системами и должны быть сначала определены. В инфраструктуре SAP логические системы реализуются клиентами. При настройке коммуникации ALE не имеет значения, будут ли партнеры физически находиться в одной или в разных системах SAP R/3. При присвоении имени логической системе необходимо, насколько возможно, придерживаться соглашения об именах <SID>CLNT<Client>. Это соглашение делает партнера очевидным просто по использованному имени. На рис. 13.7 показаны записи логической системы, которые могут быть доступны прямо из дерева Customizing при использовании символа выполнения.

Рис. 13.6. ALE Customizing (Basis Release 4.6C)

Произведенные изменения записываются в запросе Customizing, который должен присваиваться пользователю, если рассматриваемый клиент сконфигурирован с параметром Automatic recording of changes (автоматическая запись изменений, см. главу 7). Этот запрос можно использовать для переноса проверенных базовых настроек на другие системы. Настройки содержатся в общеклиентской таблице и поэтому должны производиться только один раз для каждой системы SAP R/3.

Рис. 13.7. Определение логических систем

Присвоение клиентов

На следующем шаге имена логических систем присваиваются выбранным клиентам соответствующей системы SAP R/3. Для этого запустите ►ALE Customizing и перейдите к деятельности Sending and receiving systems • Logical systems • Assign client to logical system или используйте ►Client maintenance (см. главу 7 и рис. 13.8).

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

Обслуживание модели распространения

Используя логические системные имена, модель распространения описывает партнеров коммуникации и посылаемые данные. Чтобы обеспечить наличие только одной активной версии модели для всех подходящих систем, она создается и поддерживается в одной системе. Для этого в ►ALE Customizing выберите ►Modeling and Implementing Business Processes • Maintain Distribution Model and Distribute Views • Create Model View или прямой подход ►Maintenance of Distribution Model • Create Model View. Введите подходящий короткий текст и техническое имя для планируемого представления модели (см. рис. 13.9).

Рис. 13.8. Присвоение логической системы клиенту

Рис. 13.9. Создание представления модели для Central User Administration

BAPI/тип сообщения

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

► Add message type

С помощью нового представления модели присвоенный типу сообщения IDoc должен быть послан удаленной системе.

► Add BAPI

С помощью нового представления модели должен быть активирован метод BAPI или доставлен с параметрами на удаленную систему.

В данном примере CUA посылающей логической системой является «ЕРА_001», а получающей логической системой — «EPACLNT001». Типы бизнес-объектов User и UserCompany (адрес компании) должны быть заполнены с помощью метода Clone (см. рис. 13.10).

Рис. 13.10. Описательные данные модели распространения

Фильтры

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

Специальные настройки

Следующие настройки являются дополнительными параметрами для моделирования бизнес-процесса и реализацией настройки ALE:

► Конфигурирование предварительно определенных бизнес-процессов ALE

► Конфигурирование распространения основных данных

► Конфигурирование синхронизации данных Customizing

Эти параметры позволяют более точно дифференцировать распространяемые данные и использовать дополнительные функции ALE. Например, в разделе распространения основных данных можно распространить основные данные материалов при активации генерации индикаторов изменения. Индикатор изменения показывает, где были сделаны изменения в основной записи, и поэтому позволяет, сгенерировать подходящий Idoc — вручную или под управлением программы отчета.

Коммуникация

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

В каждой системе должно быть создано соединение RFC (см. раздел 13.2) с типом 3 (соединение с системой SAP R/3) для коммуникации между партнерами в группе ALE. В примере центрального управления пользователями адреса назначения RFC должны создаваться из центральной системы во всех дополнительных системах, а в зависимости от настроек параметра изменяемости также и в противоположном направлении (см. главу 8).

Если имя адреса назначения RFC соответствует имени логической получающей системы, дополнительные настройки могут генерироваться автоматически.

Профили партнеров

В следующем разделе ►Partner profiles в ALE Customizing описываются параметры для входящей и исходящей обработки для вовлеченных систем (см. раздел 13.11). После генерации профиля партнера этот раздел распространяется на все выбранные партнерские системы или, если задано только модельное представление без каких-либо явных имен партнеров, на всех партнеров в модельном представлении. При определении партнерского профиля в центральной системе в данном примере дополнительные системы являются партнерами.

Размер пакета и режим вывода задаются с помощью параметров вывода. Можно немедленно послать каждый сгенерированный IDoc получателю или собрать несколько IDoc в группу и послать их, когда группа будет заполнена. Недостатком нескольких небольших пакетов является то, что требуется устанавливать соединение с целевой системой и выполнять процедуру регистрации для каждого пакета. Этот подход может привести к деградации производительности. Однако если собирать документы IDoc и затем посылать их, то пул данных в посылающей и получающей системах может со временем различаться. Передача большого числа документов IDoc создает также пиковые нагрузки на получающей системе. Следовательно, необходимо найти разумный компромисс между этими подходами. Обычно SAP рекомендует собирать несколько документов IDoc и передавать их одним пакетом.

Настройки, задаваемые на получателе, относятся к управлению документами IDoc на получающей стороне. IDoc могут обрабатываться немедленно или в фоновом режиме. В типичных случаях можно обеспечить лучшую производительность, не обрабатывая входящие IDoc немедленно, а позже, когда нагрузка на систему ослабнет. Отложенная обработка означает также, что можно распараллелить входящие IDoc. После завершения определения необходимо сохранить его и сгенерировать партнерские профили. Порт и данные об обработке IDoc создаются автоматически как часть генерации партнерских профилей. Порт должен определяться вручную только в случае файлового интерфейса. Партнерские профили определяют, как управлять сообщениями при обработке ALE. Они зависят от типа партнера и от различных типов сообщений. На рис. 13.12 показан коммуникационный поток данных между логическими системами.

Рис. 13.11. Генерация партнерского профиля

Рис. 13.12. Технические настройки

Порт

Порт определяет тип соединения с партнером. Данные могут передаваться через tRFC с помощью последовательных файлов, с помощью CPI-C в систему SAP R/2 или через Интернет. Каждому порту присваивается уникальный номер.

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

Чтобы обеспечить работу сделанных и сгенерированных настроек, можно выполнить функцию Check all partner profiles for consistency в ►IDoc Check, чтобы осуществить проверку на согласованность всех партнерских профилей.

Настройки модели распространения

Настройки распространения должны быть известны всем партнерским системам. Соответственно последний шаг распространяет настройки модели: ►Maintenance of distribution model • Edit • Model view • Distribute.

Этот шаг завершает определение соединения ALE.

13.2.4. Мониторинг и анализ

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

►ALE status monitor (см. рис. 13.13) предлагает обзор статуса обработки документов IDoc, который можно профильтровать согласно нескольким критериям. Можно из обзора перейти к подробному представлению. Когда причина ошибки найдена и исправлена, можно также запустить повторную обработку документов IDoc, которые содержат ошибки и были обработаны не полностью.

Для поддержки различных типов анализа можно перечислить записи в мониторе состояния и отсортировать их согласно различным критериям. Можно дважды щелкнуть мышью, чтобы увидеть дополнительные детали, или щелкнуть на записи IDoc, чтобы вывести его определение (см. рис. 13.14).

►IDoc list предоставляет также подробный вывод документов IDoc, но без возможности повторной отправки.

Описанный здесь монитор статуса и дополнительные функции анализа интегрированы в мониторы для администрирования ALE. В управление ALE можно попасть из SAP Menu через Tools • ALE • ALE Administration. He существует транзакции для замены этого пути доступа.

Рис. 13.13. Монитор статуса для сообщений ALE

Рис. 13.14. Отдельный вывод IDoc в мониторе ALE

Таблица 13.2. Управление ALE

Меню	Подменю	Функции
Мониторинг		Монитор статуса сообщений ALE
		Монитор CCMS
		Вывод рабочих позиций
Службы	Смена указателей	Обработка
		Реорганизация
	Аудит ALE	Послать подтверждения аудита
		Реорганизовать базу данных аудита
	Настройка данных	Запросы ALE: Вывод исходящих запросов
		Запросы ALE: Вывод входящих запросов
		Запросы ALE: Генерировать
		Запросы ALE: Импортировать
		Запросы ALE: Консолидировать
Сериализация	Сериализация с помощью отметок времени	Удаление старых отметок времени
	Сериализация с помощью типов сообщений	Анализ
		Отправка
		Проверка
		Отправка
	Сериализация с помощью бизнес-объектов	Вывод сериализованных документов IDoc
		Проверка согласованности
		Регистрация исходящих
		Регистрация входящих

Проверка обработки документов IDoc включает также управление работой спланированных фоновых заданий для обработки IDoc.

Таблица 13.3. Фоновые задания для мониторинга

Программа	Описание
RSEOUT00	Обработка вывода ALE
RBDAPP01	Обработка ввода ALE
RSNAST00	Генерация документов Idoc из управляющих сообщений
RBDMIDOC	Генерация документов Idoc из указателей изменений
RBDMOIND	Преобразование статуса после успешной коммуникации tRFC
RBDCPCLR	Реорганизация таблицы указателей изменений
RSARFCEX	Обработка прерванных передач документов IDoc

Если обработка документа IDoc прерывается, можно использовать ►IDoc error handling для включения ручной повторной обработки после исправления ошибки.

Кроме конфигурируемого подтверждения с помощью типа сообщения ALEAUD, можно также выполнить синхронный запрос статуса для определенных документов IDoc. Для этого можно щелкнуть на кнопке Trace IDocs в окне монитора статуса ALE или ►IDoc Tracing.

Диалоговые рабочие процессы обрабатывают полученные документы IDoc. Следовательно, обработка документов IDoc в целевой системе требует присутствия не только обычных диалоговых рабочих процессов для диалоговых пользователей, но и процессов для функций ALE. Можно сконфигурировать параллельную или последовательную обработку полученных документов IDoc. Для параллельной обработки необходимо создать дополнительные диалоговые процессы в количестве, соответствующем среднему числу документов IDoc, которые получаются параллельно. Последовательная обработка требует меньше диалоговых рабочих процессов, но только один документ IDoc может обрабатываться в данный момент, так что может возникнуть затор и падение производительности на получающей стороне. При этом также исключается возможность обработки одного документа IDoc раньше другого, если это понадобится. Техническая команда должна обсудить преимущества и недостатки каждого метода с подразделениями пользователей, а затем создать подходящее техническое решение. Кроме распределения нагрузки между инстанциями SAP R/3, при создании групп в определении соединения RFC может быть полезно в некоторых ситуациях использовать отдельную инстанцию SAP R/3 для обработки документов IDoc. Конечно, такое решение требует анализа стоимости и эффективности, так как для его реализации нужно дополнительное оборудование.

13.3. Перенос данных

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

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

► Переноса преобразованных данных в новую систему SAP R/3, определяя, какие данные должны отображаться в какие поля таблиц и не требуется ли дополнительная настройка при условии различных структур данных в новой и унаследованной системах.

► Обеспечения полного переноса

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

Методы переноса данных

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

13.3.1. Пакетный ввод

Процедура пакетного ввода является стандартным подходом, который давно используется в среде SAP для переноса данных в систему SAP R/3, имитируя диалог пользователя. Согласованность данных гарантируется, так как процедура включает все транзакционные проверки. Перенос данных происходит в два шага:

1. Создание сеанса пакетного ввода, который содержит все необходимые данные (транзакции, экраны, поля и значения полей)

2. Обработка сеанса в системе. Выполнение сеанса пакетного ввода импортирует данные в систему SAP R/3.

Сеансы пакетного ввода

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

С помощью этой методики процедура пакетного ввода реализует перенос данных для каждого диалогового экрана DAP R/3, включая связанные с ними меры безопасности для сохранения целостности. Это применимо как к стандартным программам SAP R/3, так и к специальным пользовательским разработкам в системе SAP R/3.

Автоматическая запись

Автоматическая запись транзакций особенно полезна. Соответствующие структуры сеанса пакетного ввода и программа пакетного ввода могут генерироваться автоматически из записанных транзакций. Автоматическая запись начинается с помощью ►Transaction recorder. После запуска программа записи транзакции выполняет транзакции, которые позже будут перенесены с помощью процедуры пакетного ввода. Сеансы можно генерировать из записей и корректировать их необходимым образом. Затем на следующем шаге можно сгенерировать и при необходимости подкорректировать соответствующую программу АВАР. Такой подход сокращает ручную работу по программированию, которая требовалась ранее.

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

Для выполнения сеанса пакетного ввода имеется два метода:

► Запуск вручную с помощью ►Batch Input; выполнение в диалоге ил в фоновом режиме.

► Автоматический запуск с помощью программы АВАР RSDBCSUB

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

Во время разработки программы пакетной обработки необходимо отметить длину транзакции. Поскольку программы пакетной обработки выполняется в фоновом режиме, на экране не происходит никаких изменений, поэтому с точки зрения базы данных не происходит фиксации изменений (commit). Следовательно, необходимо контролировать длину транзакции с помощью явной фиксации изменений в программе. Доступ к анализу потоков выполнения пакетного ввода и запуск выполнения выполняются с помощью ►Batch Input (см. рис. 13.16). Для анализа есть различные представления. Технические вопросы программы и проблемы содержимого можно разрешить при тесном сотрудничестве между системным администратором, отделами пользователей и разработчиками.

Иногда успешно завершенные сеансы должны удаляться из базы данных, чтобы освободить пространство. Для этого можно использовать отчет RSBDCREO для фоновой обработки. Этот отчет должен выполняться ежедневно как часть стандартных заданий Basis (см. главу 9).

Рис. 13.15. Основной поток данных в процедуре пакетного ввода

Рис. 13.16. Доступ к анализу пакетного ввода

13.3.2. Прямой ввод

При прямом вводе данные в файле переноса данных подвергаются всем проверкам, которые будут происходить при диалоговом вводе; однако он затем переноситься прямо в систему SAP R/3.

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

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

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

13.3.3. Быстрый ввод/транзакция вызова

Метод быстрого ввода использует другую технику вместо начального переноса данных в сеанс. Переносимые данные сначала записываются во внутреннюю таблицу. Оттуда они обрабатываются с помощью специальной транзакции с помощью оператора АВАР CALL TRANSACTION. Поэтому структура внутренней таблицы должна следовать структуре данных, необходимых для транзакции. При использовании быстрого метода ввода разработчик отвечает за запись в журнал потока выполнения. Поскольку быстрый ввод требует меньше записей в журнале, чем пакетный, то этот ввод быстрее пакетного, но обычно медленнее, чем прямой ввод.

13.3.4. BAPI

Для переноса данных можно использовать также BAPI. Данные обрабатываются с помощью модели ALE, вызывая BAPI в получающем приложении. Для работы этого метода данные источника должны быть представлены в формате IDoc.

Этот процесс выполняет такие же проверки, что и во время диалогового ввода.

13.3.5. Рабочая среда миграции унаследованных систем

Для однократного или периодического переноса данных из систем, отличных от SAP, можно использовать рабочую среду миграции унаследованных систем (LSMW — Legacy System Migration Workbench). Миграция происходит следующим образом:

1. Чтение структуры данных из одного или нескольких файлов, представленных на сервере приложений или представлений.

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

3. Импорт данных в целевую систему через стандартный интерфейс (пакетный ввод, прямой ввод, BAPI или IDoc). Во время переноса данные подвергаются тем же проверкам, что и во время диалогового ввода.

LSMW полностью интегрирована в систему SAP R/3, но не в стандартную поставку до Basis Release 6.10 включительно. Можно загрузить требуемые переносы из SAP Service Marketplace по быстрой ссылке lsmw. Начиная с Basis Release 6.10, требуется Version 3; LSMW 4.0 является интегральным компонентом SAP Web Application Server.

Начиная с SAP R/3 4.6C, среда LSMW интегрирована в рабочую среду переноса данных (Data Transfer Workbench).

13.3.6. Рабочая среда переноса данных

Рабочую среду переноса данных (►Data Transfer Workbench) можно использовать для миграции больших объемов данных в систему SAP. Перенос данных управляется проектом: рабочая среда осуществляет управление проектами, которое состоит из извлечения, очистки, преобразования, загрузки и проверки.

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

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

13.4. SAPconnect

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

► Интернет (e-mail)

► Факс

► Пейджер/служба коротких сообщений (SMS)

► Х.400

► Другие системы SAP

Сертифицируемые интерфейсы BC-CON (факс) и BC-PAG (пейджер) используются для связи с внешними поставщиками. В Basis Release до 4.6D RFC устанавливал соединение e-mail независимо от того, что использует другая сторона, — Exchange Connector, Lotus Domino MTA или SAP Internet Mail Gateway (sendmail). Начиная с Basis Release 6.10, простой протокол пересылки почты (SMTP) является стандартным протоколом для соединения e-mail; к серверу SMTP можно обращаться непосредственно с помощью подключаемого модуля SMTP. Документы упаковываются в e-mail и перенаправляются на внутренний факс-сервер или внешнему поставщику.

Для использования функций SMTP параметры профиля инстанции SAP должны быть настроены таким образом, чтобы разрешить загрузку динамической библиотеки, реализованной через подключаемый модуль SMTP. Кроме того, в каждом клиенте, который получает почтовые сообщения или уведомления о состоянии, требуется пользователь типа system (см. главу 8) с профилем полномочий S_A.SCON.

Необходимо определить каждую внешнюю систему коммуникации, куда передаются сообщения, как узел (node). Параметры соединения задаются независимо от типа соединения (SMTP или RFC). Подключаемый модуль SMTP является частью Internet Communication Manager (ICM, см. главу 1).

Среда коммуникации SAPconnect соединена с Alert Monitor (см. главу 16) для мониторинга внешних компонентов. Если узлы должны выводиться в Alert Monitor, необходимо активировать флажок, который указывает, что узел, когда он определен, должен контролироваться с помощью Alert Monitor. Управляющий экран SAPconnect будет доступен через ►SAPconnect Administration.

►SAPconnect Transmission jobs предоставляет обзор заданий передачи, которые можно фильтровать по заданному периоду, типу адреса, отправителю, и статусу.

13.5. Советы

► Переименование логических систем

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

► Удаление документов IDoc

Документы IDoc, которые больше не требуются, можно удалить только с помощью стандартной процедуры архивации (см. главу 12) для объектов типа IDOC.

13.6. Транзакции и пути доступа меню

ALE Customizing: SAP Menu • Tools • Administration • User maintenance • Central user administration • ALE Customizing (SALE)

ALE Status Monitor: SAP Menu • Tools • ALE • ALE Administration • Monitoring (BD87)

BAPI Explorer: SAP Menu • Tools • Business Framework • BAPI Browser • (BAPI)

Batch Input: SAP Menu • Tools • Administration • Monitor • Batch input (SM35)

Client maintenance: SAP Menu • Tools • Administration • Administration • Client administration • Client maintenance (SCC4)

Data Transfer Workbench: SAP Menu • Tools • DataTransfer • Workbench (SXDA)

Direct input administration: нет стандартной записи в меню (BMV0)

IDoc check: нет стандартной записи в меню (IDOC)

IDoc error handling: нет стандартной записи в меню (BD73)

IDoc list: SAP Menu • Tools • Business Communication • Idoc Basis • Idoc Idoc Lists. (WE05)

IDoc tracing: SAP Menu • Logistics • Logistics Execution • Master Data • Transportation • Shipment Costs • ALE Monitoring • Monitoring • Idoc • Trace • (BDM2)

Maintenance of distribution model: нет стандартной записи в меню (BD64)

Maintenance of server groups: нет стандартной записи в меню (RZ12)

Partner profile: ALE Customizing (SALE) • Model business processes • Maintain distribution model and distribute views (BD64) • Generate partner profile (BD82)

Port definition: SAP Menu • Tools • Business Communication • Idoc Basis Idoc • Port Definition • (WE21)

qRFC Monitor: нет стандартной записи в меню (SMQR)

qRFC Monitor input: нет стандартной записи в меню (SMQ1)

qRFC Monitor output: нет стандартной записи в меню (SMQ2)

RFC administration: SAP Menu • Administration • Administration • RFC destinations (SM59)

SAPconnect administration: SAP Menu • Tools • Business Communication • SAPconnect (SCOT)

SAPconnect transmission jobs: нет стандартной записи в меню (SOST)

Transaction recorder: нет стандартной записи в меню (SHDB)

tRFC Monitor: SAP Menu • Tools • Administration • Monitor • Transactional RFC (SM58)

Trusted system: нет стандартной записи в меню (SMT1)

13.7. Дополнительная документация

Быстрые ссылки

► SAP Service Marketplace: псевдоним ale

► SAP Service Marketplace: псевдоним bapi

► SAP Service Marketplace: псевдоним communication

► SAP Service Marketplace: псевдоним connectors

► SAP Service Marketplace: псевдоним dta

► SAP Service Marketplace: псевдоним ibf

► SAP Service Marketplace: псевдоним lsmw

Указания SAP Service Marketplace

Таблица 13.4. Указания SAP по переносу и распространению данных

Содержание	Указание
Meaning of input types in SMQS	484753
ALE: Transmission of Idocs and QOUT Scheduler	580869
Resource Management for tRFC and aRFC	74141
Problems with the names of logical systems	423184
Converting the names of logical systems	121163
ZBV: Tips for optimizing performance	399271
SXC: Version overview and history	122657

13.8. Контрольные вопросы

1. Какое утверждение правильно?

Во время распространения данных на основе ALE:

a. создается фиксированное соединение между партнерскими системами

b. партнерские системы слабо связаны во время переноса данных

c. для переноса данных используются функции каждой РСУБД, такие как SAPDBA

2. Какие методы можно использовать для обмена данными?

a. CPI-C

b. последовательные файлы

c. tRFC

d. Интернет

e. Telnet

3. Как можно повторно обработать tRFC, прерванный ошибками коммуникации?

a. Автоматически, активируя параметр для автоматической повторения во время определения соединения tRFC

b. Выполняя задание RSARFCE

c. Выполняя задание RSEOUT00

d. Исправляя ошибку и выполняя повторно прикладную транзакцию.

4. Каково назначение процедуры пакетного ввода?

a. Передача данных из последовательных файлов в базу данных SAP R/3

b. Обработка массовых данных в фоновом режиме

c. Импорт файлов с помощью Программы управления переносом tp

ГЛАВА 14 ОБСЛУЖИВАНИЕ ИНСТАНЦИЙ

14.1. Обслуживание профилей

Системные или зависимые от инстанции определения конфигураций для системы SAP R/3 сохраняются в файлах инициализации на уровне операционной системы (см. главу 2). Эти профили генерируются и конфигурируются с настройками по умолчанию во время установки с помощью программы R3setup (до R/3 Release 4.6C) или SAPinst (в Win Application Server 6.10 и позже). В ходе жизненного цикла системы R/3 изменяющиеся обстоятельства — такие, как увеличение числа пользователей, обновление версий R/3 или установка новых модулей и оборудования — делают необходимым перенастройку этих системных параметров.

Изменения вручную

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

Функции обслуживания профилей в системе R/3 предоставляют пользователям следующие важные преимущества:

► Централизованное администрирование

Позволяет централизованно управлять профилями всех инстанций и обслуживать их.

► Управление версиями

В базе данных R/3 сохраняется каждое изменение в профиле как отдельная версия. Версии нумеруются последовательно.

► Проверка согласованности и непротиворечивости

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

► Сравнение активных профилей с сохраненными профилями в БД

Можно анализировать расхождения между текущим (используемым) профилем и профилем, сохраненным в БД. Этот анализ позволяет определить, не был ли системный профиль R/3 изменен вручную.

► Немедленная активизация изменений параметров

Некоторые параметры можно активизировать немедленно, не откладывая это до перезапуска системы R/3.

Одновременно функции управления профилем в системе R/3 являются необходимым условием для использования средств системного мониторинга, таких как панель управления, а также для определения и использования операционных режимов.

Средство Обслуживания профилей (►Profile Maintenance) в R/3 позволяет централизованно обслуживать стандартный профиль системы DEFAULT.PFL, профили запуска Start_<имя_инстанции>_<имя_сервера> и профилей инстанций (для всех инстанций) <SID>_<имя_инстанции>_<имя_сервера> (см. главу 2). Для обслуживания профилей с помощью средств R/3 их нужно сначала импортировать из файловой системы в БД R/3. Программы установки сохраняют файлы профилей в системе файлов, а не в базе данных. Для импорта профилей выполните следующие шаги:

Шаг 1

Выберите ►Profile Maintenance. Выводится окно Edit Profiles (см. рис 14.1).

Рис. 14.1. Начальный экран обслуживания профилей

Шаг 2

Выберите команду Utilities • Import Profiles • Of Active Servers. Структура центрального каталога в системе R/3 позволяет импортировать и сохранять в БД профили всех инстанций. В следующем отчете (см. листинг 14.1) показан журнал импорта для центральной системы IE4. В процессе импорта для всех параметров в профилях выполняется проверка согласованности. Логические имена импортированных профилей определяются как соответствующие имена файлов без информации о пути доступа.

Листинг 14.1. Журнал импорта профилей с последующей проверкой согласованности

------------------------------------------------------------

|Importing start/instance profiles for all active servers

------------------------------------------------------------

|The following default profile will be imported:

------------------------------------------------------------

|psasb009_IE4_00:D:\usr\sap\IE4\SYS\profile\DEFAULT.PFL

|[Ok? Does this continue to another line?]

------------------------------------------------------------

|The following instance profiles will be imported:

------------------------------------------------------------

|psasb009_IE4_00:D:\usr\sap\IE4\SYS\profile\IE4_DVEBMGS00_psasb009

------------------------------------------------------------

|The following start profiles will be imported:

------------------------------------------------------------

|psasb009_IE4_00:D:\usr\sap\IE4\sys\profile\START_DVEBMGS00_psasb009

------------------------------------------------------------

|Log for importing the profile

------------------------------------------------------------

|Profiles were imported free of errors.

------------------------------------------------------------

|Overall check of instance profiles and a default profile

------------------------------------------------------------

|Log for the default profile, single check

|Profile name : DEFAULT

|Physical profile name :

| D:usr\sap\IE4\SYS\profile/DEFAULT.PFL

|Check on server : psasb009_IE4_00

------------------------------------------------------------

|No errors found

------------------------------------------------------------

|Log for istance profiles, single check

|Profile name : IE4_DVEBMGS00_PSASB009

|Physical profile name :

|D:\usr\sap\IE4\SYS\profile\IE4_DVEBMGS00_psasb009

|Unknown parameter em/reserve_mapping_window cannot be checked

|rtbb/buffer_length factor 10 greater than default 2000

------------------------------------------------------------

|Log for the instance profile, overall check

|Profile name : IE4_DVEBMGS00_PSASB009

|Physical profile name :

|D:\usr\sap\IE4\SYS\profile\IE4_DVEBMGS00_psasb009

|Log for overall check

------------------------------------------------------------

|No errors found

------------------------------------------------------------

|Overall check of start profiles

------------------------------------------------------------

|Log for the start profiles, single check

|Profile name : START_DVEBMGS00_PSASB009

|Physical profile name :

|D:\usr\sap\IE4\SYS\profile\START_DVEBMGS00_psasb00

------------------------------------------------------------

|No errors found

------------------------------------------------------------

|Log for the start profiles, overall check

|Profile name : START_DVEBMGS00_PSASB009

|Physical profile name:

|D:\usr\sap\IE4WSYS\profile\START_DVEBMGS00_psasb00

|Log for start profile list

------------------------------------------------------------

|No errors found

------------------------------------------------------------

В приведенных в листинге 14.1 журналах показаны отдельные этапы проверки непротиворечивости импорта. Журнал начинается с импорта профиля, используемого по умолчанию, профиля инстанции и профиля запуска. Поскольку это центральная система R/3, здесь есть только один профиль запуска и один профиль инстанции. Далее параметры каждого отдельного профиля проверяются в своих интерактивных контекстах. В данном журнале проблем не обнаружено. После индивидуальной проверки для профилей каждого класса выполняется проверка в масштабе системы. Здесь система проверяет, удовлетворены ли основные правила конфигурации в системе R/3. Например, эти правила могут включать в себя условия, описанные в таблице 1.2. В случае центральной системы R/3, как и в предыдущем примере, данная проверка не выявила никаких проблем.

Импортированные профили составляют основу изменений параметров. Для загрузки отдельных профилей в БД (см. рис. 14.1) задайте имя профиля и выберите кнопку Import. Это нужно делать, в частности, при добавлении инстанций R/3 к существующей системе R/3. Перед внесением изменений в активные профили, сгенерированные в процессе инсталляции системы, скопируйте профили в файлы с другими логическими (административными) именами. При этом физическое присваивание профиля сохраняется. В качестве имени администрирования профиля в БД можно выбрать любое имя. Преимущество назначения различных имен администрирования, определяемых пользователем, и фактических имен профилей на уровне файлов операционной системы заключается в упрощении управления профилями. Это дает возможность поддерживать различные варианты одного профиля для разных целей (таких, как пробная реализация или обновление системы) под разными именами администрирования. В следующем примере рассматривается профиль инстанции, которую можно активировать с поддержкой или без поддержки SNC для зашифрованной передачи данных. Выполните следующие шаги:

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

Шаг 3

Введите имя целевого профиля. Если нужно сгенерировать новую версию, лучше использовать то же имя. В противном случае введите новое имя профиля (см. рис. 14.2).

Рис. 14.2. Копирование профиля

Шаг 4

Выберите команду Сору. Генерируется версия 1 нового профиля. Если используется то же имя, то система просто создает новую версию существующего профиля.

Обслуживание профилей осуществляется тремя способами:

► Администрирование данных

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

► Базовое обслуживание

Режим базового обслуживания охватывает обслуживание параметров выбранного профиля. Внешний интерфейс средства базового обслуживания профиля зависит от типа профиля, поскольку разные профили имеют различные значимость и содержимое. Базовое обслуживание просто позволяет модифицировать большинство важных параметров и предлагает пользователю логические имена для этих параметров. Кроме значений для рабочих процессов и буферов, показанных на рисунке 14.4, базовое обслуживание включает также информацию об используемых каталогах и языках, а также дополнительную информацию по управлению памятью. Затем система выводит требуемые начальное и максимальное значение объема свопа для инстанции на основе определенных настроек. Для обеспечения хорошей производительности проверьте, что это начальное значение не превышает 150% всей основной памяти сервера.

Рис. 14.3. Изменение административных данных профиля

► Расширенное обслуживание

Режим расширенного обслуживания показывает содержимое профиля в неформатированном виде, т. е. выводятся реальные имена параметров. Этот режим предназначен для опытных администраторов. Его можно использовать для изменения параметров, уже включенных в профиль, и создания новых параметров с помощью команды Parameter • Create. Для удаления параметров выберите Parameter • Delete.

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

Рис. 14.4. Базовое обслуживание профиля

□ Unknown parameter em/reserve_mapping_window (Неизвестный параметр em/...)

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

После сохранения изменений файлы профилей еще не переносятся на уровне операционной системы. Чтобы перенести изменения в соответствующий файл на этом уровне, выберите Profile • Activate.

Активация

При активации профиля создается файл резервной копии <имя_профиля>.ВАК с содержимым последнего действительного файла профиля. Активировать можно только самую последнюю версию профиля.

Чтобы помочь отследить историю изменений, все изменения параметров записываются в файл профиля (см. листинг 14.2).

Листинг 14.2. Файл модифицированного профиля (фрагмент)

Directоrу /usr/sap/HUY/SYS/profile

Name: HUY_D32_us7400

******************************************************

#.* Instance profile HUY_D32_WITH0UT_SNC

#.* Version = 000002

#.* Generated by user = D036044

#.* Generated date = 07/06/2003, 03:52:36 p.m.

#.****************************************************

#parameter created by: D024220

10/16/2002 11:02:06 a.m.

ssf/name = SAPSECULIB

#parameter created by: D024220

10/16/2002 11:00:22 a.m.

snc/accept_insecure_cpic = 1

#parameter created by: D024220

10/16/2002 11:04:21 a.m.

snc/gssapi_lib = /sapmnt/HUY/exe_64/libsapcrypto.so

#parameter created by: D024220

10/16/2002 11:03:02 a.m.

#old_value: 1 changed:

D036044 07/06/2003 03:52:36 p.m.

snc/enable = 0

#parameter created by: D024220

10/16/2002 10:55:27 a.m.

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

В ►Profile Maintenance выберите Profile • Dyn.Switching • Execute, чтобы перейти к динамическим параметрам инстанции (по отдельности или ко всем вместе), которые перечислены в ►Profile Maintenance • Profile • Dyn.Switching • Display Parameters. Динамическое изменение параметров возможно различными способами в зависимости от типа параметра. Можно временно изменить все динамические параметры с помощью ►Maintain Profile Parameters.

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

Область действия параметров	Параметры	Переключение
Уровень трассировки; Ресурсы tRFC/aRFC	rdisp/TRACE; rdisp/rfc_*	►Process Overview; Неявно с помощью ►RFC Server Group Maintenance
Управление памятью	abap/swapreserve; em/stat_log_*; abap/heap_area_*; ztta/roll_*	Отчет RSMEMORY
Шлюз	gw/*	Неявно с помощью ►Gateway Monitor
Диспетчер	rdsip/max_hold_time; rdisp/max_sleep; rdisp/max_pnv_time; rdisp/bufreftime; rdisp/btctime; rdisp/autoabaptime; rdisp/keepalive*; rdisp/gui_auto_logout; rdisp/spooltime; rdisp/wppriv_max_no	Отчет RSMON000_CHANGE_PARAMETER (более удобная для пользователей функция доступна в Web Application Server 6 20)
Обработчик задач	rdisp/max_wprun_time; rdisp/call_system; rdisp/no_core_info; rdisp/reinitialize_code_page; rdisp/no_rfc_commit_in_update_task; rdisp/async_dialog_timeout; rdisp/wpdbug_max_no; rdisp/wait_after_deadlock; rdisp/wp_auto_restart; rdisp/wp_abap_restart; rdisp/restartable_wp
RFC/CPIC	rdisp/sna_gateway; rdisp/sna_gw_service; rdisp/accept_remote_trace_level; rdisp/rfc_pooling; rdisp/rfc_pool_timeout
Буферы диапазона номеров	nobuf/max_attempts; nobuf/server
Обновление	rdisp/vbmail; rdisp/auto_vb_stop; rdisp/max_attempt_no; rdisp/vb_stop_active; rdisp/vb_auto_sync
Сервер сообщений	ms/http*; ms/max_sleep; ms/keepalive; ms/suspend_time; ms/conn*; ms/max_queue; ms/warn_queue; ms/audit ms/cache_check; ms/comment	Неявно с помощью ►Message Server Monitor или отчет RSM51000_CHANGE_PARAMETER

Все параметры профиля описываются детально по отдельности в ►Maintain Profile Parameters (см. рис. 14.5). Зависимая от параметра команда Documentation описывает дополнительные свойства и примеры использования. Щелкните на Change value, чтобы динамически изменить текущее значение параметра.

До сих пор одним из основных моментов внимания в этой книге была обработка функций обслуживания профиля, интегрированных в R/3. В соответствующих главах описывается, какие параметры доступны для конфигурирования R/3 для отдельных областей использования. Однако существует множество других параметров, не все они имеют отношение к заказчику и поэтому не должны изменяться без первоначальной консультации с SAP. Глоссарий содержит краткие описания наиболее важных параметров в системе R/3. В частности, размеры основных областей памяти инстанции являются критически важными для производительности. Дополнительную информацию можно найти в книге Томаса Шнайдера (Thomas Schneider) SAP Performance Optimization, выпущенной в SAP PRESS.

Рис. 14.5. Обслуживание параметров профиля

Создание нового параметра

Если необходимо изменить параметр, который использовался только со своим значением по умолчанию (в связи, например, с Указанием SAP), то сам параметр еще не определен в профилях. Его значение извлекается из исходного кода R/3 (см. главу 2). B ►Profile Maintenance выберите соответствующий профиль, в котором необходимо создать параметр. Выберите Extended Maintenance • Change • Parameter • Create, чтобы открыть экран обслуживания для нового параметра (см. рис. 14.6).

Рис. 14.6. Создание нового параметра

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

Отчет RSPARAM

Чтобы выяснить, какие параметры в настоящее время активны в системе R/3, можно запустить отчет RSPARAM. Каждый параметр R/3 имеет настройку по умолчанию, реализованную в ядре R/3. Пользовательские настройки в профилях переопределяют эти значения. Отчет RSPARAM генерирует список, который показывает оба значения для каждого параметра. Более того, можно выбрать отдельные параметры и увидеть в отчете доступную документацию. Динамические изменения параметров действительны только до следующего раза, когда будет считан соответствующий файл профиля, т. е. до следующего перезапуска инстанции. RSPARAM не выводит эти значения параметров.

Программа sappfpar

На уровне операционной системы пользователь <sid>adm может применять программу sappfpar для получения информации об установленных параметрах и требованиях к размеру области оперативной памяти инстанции. Команда sappfpar help дает краткую информацию по вызову этой программы:

► sappfpar <имя параметра>

Выводит на экран текущее значение параметра

► sappfpar all

Выводит список всех определенных параметров

► sappfpar check

Проверяет установленные параметры, включая конфигурацию областей оперативной памяти R/3; также вычисляются требования к оперативной памяти

При необходимости можно также определить профиль инстанции с помощью pf=<профиль инстанции> номер инстанции с помощью nr=<номер_ инстанции> или имя системы R/3 с помощью name=<SID>.

Программа memlimits

Эта программа, работающая на уровне операционной системы, также может быть полезна администратору. Она доступна пользователю <sid>adm и сравнивает требования к памяти системы R/3 (вычисленные на основе значений параметров) с параметрами ядра, определенными в операционной системе. Если требования к памяти, установленные в R/3, превышают ограничения ОС, то может возникнуть проблема, например, система R/3 просто не будет запускаться.

14.2. Режимы работы

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

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

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

1. Выберите ►Operation Mode Maintenance.

2. Введите имя режима работы и короткое описание.

3. Определите, какой вариант контролируемых свойств будет активироваться во время переключения рабочего режима (см. главу 15).

4. Сохраните свое определение.

Определенные режимы работы можно посмотреть на экране (см. рис. 14.8).

Рис. 14.7. Определение рабочего режима

Рис. 14.8. Обзор определенных рабочих режимов

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

Теперь зарегистрируйте все инстанции в своей системе. Для этого выполните следующее:

1. Снова выберите ►Operation Mode Maintenance, а затем перейдите в Instances/Profiles. Будет выведен активный стандартный профиль (см. рис. 14.9). Если режим не был обслужен, то никакие серверы приложений или инстанции не будут видны.

Рис. 14.9. Представление профиля операционных режимов и инстанций

2. Выберите Profile • Create New instance (см. рис. 14.10).

Рис. 14.10. Обслуживание данных инстанции

3. Введите имя сервера приложений и номер инстанции.

4. Выберите Current settings. Текущие настройки профиля, а также тип и число рабочих процессов текущей активной конфигурации используются автоматически (см. рис. 14.11).

5. Если для запуска и останова инстанций желательно использовать управляющую панель, выберите Instance • Maintain Start User, чтобы ввести имя и пароль пользователя операционной системы, который уполномочен запускать и останавливать инстанцию. В настройке по умолчанию это будет пользователь <sid>adm. Чтобы изменить профиль, выберите этот профиль и щелкните на Change. Автоматически появится функция обслуживания профилей.

Рис. 14.11. Копирование текущих настроек

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

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

Рис. 14.12. Распределение рабочих процессов

- Те же самые ограничения применимы к задачам обновления и обновления V2.

- Верхнее ограничение для числа фоновых процессов класса A равно общему числу фоновых процессов. Можно далее сократить число фоновых рабочих процессов до 0. Если в инстанции определены фоновые рабочие процессы только класса A, то в этой инстанции могут выполняться задания только класса A.

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

- Невозможно модифицировать число рабочих процессов спула при обслуживании инстанции.

7. Сохраните изменения.

Другие инстанции системы SAP R/3 присваивают инстанции определенным профилям аналогичным образом. Чтобы выполнить начальное присваивание инстанций после установки, можно создать общее определение инстанции для всех серверов с помощью ► Operation Mode Maintenance • Instances/Operation Modes • Settings • Based on Current Status • New Instances • Generate.

Примечание

Определенные назначения между рабочим режимом и определением инстанции можно вывести в ►Operation Mode Maintenance с помощью Instances/Operation Modes (см. рис. 14.13).

Рис. 14.13. Обзор рабочих режимов

Если нужно внести изменения, то сделайте двойной щелчок на рабочем режиме. Откроется экран с распределением рабочих процессов. Можно также изменить назначение рабочего режима, щелкнув на Other operation mode (см. рис. 14.12). Сохраните свои настройки. Если потребуется, можно также перейти к обслуживанию профиля или инстанции прямо в меню.

Последний шаг включает настройку режимов работы в расписании. Запустите снова ► Operation Mode Maintenance. Чтобы задать режимы работы в расписании, выберите Operation Modes • Time Table (см. рис. 14.14).

Для настройки расписания рабочих режимов:

1. В расписании выберите Normal Operation (24hr) • Change.

2. Для изменения интервала времени выберите Edit • Time Period. Можно выбрать интервал в 15, 30 и 60 мин.

Чтобы отметить начало нужного интервала времени, щелкните на начале интервала и выберите ►Operation Mode • Select Interval или нажмите клавишу F2. Щелкните на конце временного интервала таким же образом.

Рис. 14.14. Обслуживание расписания для рабочих режимов

3. Для назначения режима работы выберите Assign и введите его название.

4. Если в расписании остались «пробелы», повторите пункт 3.

5. Сохраните изменения (см. рис. 14.15).

Рис. 14.15. Расписание рабочих режимов

Для отмены назначения выберите кнопку Delete assignment. Стрелка в расписании отмечает текущее время.

Правила исключения

Можно определить также исключительный режим, отличающийся от обычного действующего расписания в данный день и время, с помощью ►Operation Mode Maintenance • Operation Mode • Time Table • Specify Exception Operation. Это может понадобиться, например, для обычной работы по обслуживанию или для выполнения специальных работ.

Теперь все необходимые шаги для автоматического переключения работы выполнены.

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

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

14.3. Панель управления

Для мониторинга инстанций и режимов работы в системе R/3 используется панель управления (Control Panel). Выберите ►Control Panel для вывода начального экрана этого инструмента (см. рис. 14.16).

Рис. 14.16. Начальный экран панели управления

С помощью панели управления можно:

► Проверять состояние всех инстанций в системе R/3, включая режимы работы

► Запускать и останавливать инстанции

► Изменять режимы работы вручную независимо от определенного расписания

► Выводить на экран различные параметры и характеристики, например тип и число рабочих процессов и фоновых рабочих процессов

► Обращаться к мониторам сигналов

► Выводить наиболее важные файлы трассировки

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

► Платформы UNIX

Команда rexec используется для выполнения команд на удаленном сервере UNIX. Административный пользователь локальной системы, который будет использовать rexec для запуска или останова инстанции, должен иметь соответствующую запись (имя пользователя и пароль) в конфигурационном файле .netrc на целевой системе.

► Платформы NT и Windows 2000

Инстанция R/3 на сервере NT или Windows 2000 останавливается и запускается с помощью сообщения для SAP Service Manager на удаленной системе.

► Платформа AS/400

Используется внутренний механизм AS/400 для запуска и останова инстанции на платформе AS/400.

14.4. Динамическое распределение пользователей

Распределение нагрузки

В системе R/3 с несколькими серверами приложений рекомендуется по возможности равномерно распределять нагрузку между всеми компьютерами или даже присваивать пользователей с особенно критическими по времени приложениями серверам с лучшими показателями производительности, для чего можно создать группы регистрации. Группа регистрации — этоподмножество всех доступных серверов приложений в системе R/3. Когда пользователи регистрируются в системе R/3, они выбирают присвоенную им группу регистрации. В ней система R/3 присваивает пользователей серверу приложений с наименьшей нагрузкой (т. е. наименьшим «временем отклика») в данный момент. Это называется также распределением нагрузки (балансированием нагрузки при регистрации) между инстанциями.

После создания групп регистрации важно знать, какие пользователи существуют в каждой прикладной области. Каждая инстанция имеет собственную область оперативной памяти. В идеальном случае все программы, применяемые пользователями в инстанции, и значительная часть данных уже должны быть доступны в оперативной памяти. Максимально приблизиться к такой ситуации можно, если все задачи пользователей в инстанции аналогичны. Для такой группы пользователей полезно определить группу следующим образом:

1. Выберите ►Logon Group Maintenance.

2. Выберите Edit • Create Assignment.

3. Введите имя группы регистрации и присвойте ее нужным инстанциям.

4. Сохраните данные.

Рис. 14.17. Определенные группы регистрации

Ограничения по нагрузке

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

IP-адрес сервера приложений

Для регистрации с клиентских систем можно присвоить инстанции специальный IP-адрес. Это следует делать, когда в системе R/3 применяется несколько отдельных локальных сетей. В частности, для коммуникаций между серверами приложений и БД нередко используется быстрая сеть, так как желательно передавать большие объемы данных между этими компьютерами с высокой скоростью. Компьютеры уровня презентации обычно объединяются в общую сеть. При применении в системе R/3 нескольких сетей серверы приложений имеют две сетевые платы и, следовательно, два IP-адреса. Нужно определить, какой IP-адрес будет действителен для клиентских систем.

Для определения ограничений нагрузки инстанции с помощью групп регистрации и задания IP-адреса выполните следующие шаги:

1. Выберите требуемую инстанцию в ►Logon Group Maintenance.

2. Дважды щелкните мышью на инстанции, чтобы выделить ее, и введите требуемые значения.

3. Сохраните определенные настройки.

Можно разрешить или блокировать доступ к группе регистрации через запросы контроллера удаленных функций RFC (см. рис. 14.18). Используйте вкладку Assignment, чтобы присвоить выбранную инстанцию другой группе регистрацию.

Рис. 14.18. Атрибуты группы регистрации

Чтобы вывести обзор текущего использования системы, выберите Goto • User List в ►Logon Group Maintenance, чтобы вывести текущий список активных пользователей, и Goto • Load Distribution, чтобы вывести текущее распределение инстанций в группе регистрации (см. рис. 14.19).

SAPLOGON

Группы регистрации с созданными для них определениями можно использовать при работе с программой SAPLOGON или до версии R/3 Release 4.6C — с SAP Session Manager. Для инстанции в системе R/3 интерфейс SAP GUI всегда должен вызываться непосредственно. В этом случае нельзя использовать автоматическое балансирование нагрузки между инстанциями в группах регистрации. Требуемая в SAPLOGON информация уже была описана в рамках необходимой после установки деятельности (см. главу 4).

Рис. 14.19. Текущее распределение нагрузки в группе регистрации

14.5. Советы

► Активация профиля для специального случая

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

► Выявление изменений в профиле, сделанных вручную

Если вы используете систему R/3 для обслуживания профилей (как рекомендуется), можно выявить любые сделанные вручную модификации в файлах профилей с помощью ►Profile Maintenance • Profile • Comparisons • Profile in Database • Against Active Profile.

► Автоматическая настройка общего пула памяти

Больше нет необходимости вручную задавать размеры буфера пула R/3(для коммуникации между рабочими процессами в инстанции R/3) в профиле инстанции. Эти значения вычисляются автоматически. Если система обнаружит различия во время проверки профиля, можно продолжить использование активного набора параметров. Эта ситуация не является ошибкой.

► Изменения параметров

Если необходимо изменить параметр профиля, убедитесь в том, что это делается только в соответствующем профиле:

- Общем для инстанций: DEFAULT.PFL

- Зависимом от инстанции: профиль инстанции

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

► Определение групп регистрации

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

► Использование групп регистрации для обслуживания серверов приложений

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

14.6. Транзакции и пути доступа меню

Control panel: SAP Menu • Tools • CCMS • Control/Monitoring • Control Panel (RZ03)

Gateway monitor: SAP Menu • Tools • Administration • Monitor • System Monitoring • Gateway Monitor (SMGW)

Logon group maintenance: SAP menu • Tools • CCMS • Configuration • Logon Groups (SMLG)

Operation mode maintenance: SAP menu • Tools • CCMS • Configuration • Operation Modes/Instances (RZ04)

Maintain profile parameters: Недоступно в стандартном меню SAP (RZ11)

Message server monitor: Недоступно в стандартном меню SAP (SMMS)

Operation mode calendar: SAP Menu • Tools • CCMS • Configuration • Operation Mode Calendar (SM63)

Process Overview: SAP Menu • Tools • Administration • Monitor • System Monitoring • Process Overview (SM50)

Profile maintenance: SAP Menu • Tools • CCMS • Configuration • Profile Maintenance (RZ10)

RFC server group maintenance: Недоступно в стандартном меню SAP (RZ12)

14.7. Дополнительная документация

Указания SAP Service Marketplace

В таблице 14.2 представлен обзор важных Указаний SAP из SAP Service Marketplace, которые имеют отношение к обслуживанию профиля, динамическому распределению пользователей, и управляющей панели.

Таблица 14.2. Указания SAP для обслуживания инстанций

Содержание	Указание
Set up for Logon group тог automatic load balancing	26317
Test tool tor message servers: Igtst	64015
Logon workload balancing verification test	27044

14.8. Контрольные вопросы

1. Каково назначение режима работы?

Режим работы описывает

a. число и тип рабочих процессов в одной или нескольких инстанциях

b. дополнительно все параметры областей оперативной памяти R/3.

c. состояние системы R/3: активна (готова для выполнения операций), активна БД (доступна только БД R/3), и система R/3 остановлена

2. Что означает группа регистрации?

a. Ее образуют все пользователи, включенные в одну группу.

b. Группа регистрации — это логически объединенное подмножество всех серверов приложений в системе R/3.

c. Ее составляют все пользователя, выполняющие аналогичные задачи.

ГЛАВА 15 МОНИТОРИНГ СИСТЕМЫ

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

15.1. Обзоры серверов и процессов

Подробное представление о состоянии инстанций систем R/3 и функциональном назначении рабочих процессов R/3 можно получить из обзора серверов, процессов (который был кратко описан в главе 2), а также управляющей панели Control Panel (см главу 14).

Обзор серверов

Обзор серверов ►Server Overview выводит все доступные инстанции системы R/3 (см. рис. 15.1) с информацией об используемых серверах и типах сконфигурированных рабочих процессов. В Web Application Server указывается также состояние инстанции.

► initial

Сервер приложений зарегистрировался на сервере сообщений, но к нему еще не обращались.

► starting

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

► active

Сервер приложений работает в обычном рабочем режиме и обрабатывает запросы.

► passive

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

► shutdown

Сервер приложений выключается и больше не будет обрабатывать никакие задачи.

► stop

Сервер приложений больше не имеет соединения с сервером сообщений и поэтому недоступен.

Рис. 15.1. Обзор серверов в системе R/3 уровня предприятия

Можно использовать пиктограммы или меню Goto для вывода более подробной информации или запуска действий для каждой записи списка.

Таблица 15.1. Параметры в обзоре серверов

Обзор сервера сообщений

Сервер приложений Web включает также ►Message Server Overview, который аналогичен обзору серверов. Чтобы проанализировать сервер сообщений, можно выбрать из позиций меню Goto. Кроме информации, доступной в обзоре серверов, этот новый обзор включает также следующие данные и действия:

► Выводит аппаратный ключ (см. главу 4)

► Выводит все (и изменяет некоторые) системные параметры, специфические для серверов сообщений

► Выводит статистические данные, такие как число регистрации, полученные запросы и количество записанных/прочитанных байтов

► Выводит файл трассировки разработчиков сервера сообщений dev_ms и изменяет текущий уровень трассировки без перезапуска инстанции

► Останавливает серверы приложений, с завершением или без завершения обработки запросов все еще присутствующих в очереди диспетчера; статус сервера будет shutdown

► Деактивирует серверы приложений и завершает обработку запросов все еще присутствующих в очереди диспетчера; статус сервера будет passive

► Реактивирует деактивированные серверы приложений.

Обзор процессов

Чтобы вывести всеобъемлющий обзор процессов одной инстанции (помимо вызова соответствующей функции в обзоре серверов), выберите ►Process Overview. В табличной форме будет выведена следующая информация:

► Внутренний номер процесса

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

► Тип процесса

- DIA: Диалоговый рабочий процесс

- UPD: Процесс обновления для критических по времени изменений в базе данных (обновление VI, см. главу 10)

- UPD2: Процесс обновления для некритических по времени изменений в базе данных (обновление V2, см. главу 10)

- ENQ: Рабочий процесс очереди для обработки блокировок SAP

- ВТС: Фоновый рабочий процесс

- SPO: Рабочий процесс спула

► Номер процесса на уровне операционной системы (PID)

При необходимости можно указать этот номер процесса, чтобы завершить процесс на уровне операционной системы

► Статус процесса

- running. Процесс в данное время обрабатывает запрос

- waiting. Процесс доступен и ожидает новые запросы

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

- killed: Процесс был прекращен в связи с ошибкой и не был перезапущен

► Причина удержания

Когда процессы имеют статус hold, причиной удержания процесса появляется здесь. Обычными причинами являются:

- CPIC: Рабочий процесс ожидает сообщение CPI-C

- DEBUG: Рабочий процесс находится в данное время в режиме отладки

- LOCK: Рабочий процесс был присвоен одному пользователю исключительно для системного анализа

- NUM: Рабочий процесс ожидает ответа сервера диапазона номеров

- OS: Рабочий процесс ожидает обработки команды операционной системы

- PRTV: Рабочий процесс работает исключительно для одного пользователя

- SLEEP: Рабочий процесс ожидает в связи с недостатком ресурсов

- VB: Рабочий процесс ожидает обработки синхронного запроса обновления

► Метод запуска

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

► Число прекращений

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

► Семафоры

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

► Накопленное время выполнения текущего действия в секундах

► Текущий отчет

► Присвоенный в настоящее время пользователь для клиента

► Текущее действие и обрабатываемая таблица

Можно использовать функцию List • CPU в Process Overview для вывода дополнительной информации о загрузке ЦП, создаваемой процессами. На рис. 15.2 показан раздел обзора процессов.

Обзор процессов позволяет, например, обнаружить особенно долго выполняющиеся отчеты. Можно также выбрать Process • Details (или дважды щелкнуть мышью на соответствующей строке), чтобы вывести подробную информацию для шага обработки. Будут выведены обрабатывающаяся в данный момент таблица и использованные до сих пор ресурсы.

Рис. 15.2. Обзор процессов

Режим отладки

Опытные пользователи могут использовать режим отладки, который может оказаться полезным и информативным для выполнения программ АВАР. Чтобы активизировать этот режим для выбранного процесса, выберите Program/Session • Program • Debugging. Будет выводиться пошаговое выполнение соответствующей программы. Пользователь получает полный контроль над потоком выполнения программы. Поскольку выполнение программы в режиме отладки требует очень много ресурсов, необходимо использовать его только для тестирования и разработки систем.

При возникновении серьезных проблем можно также отменить или перезапустить диалоговый или фоновый рабочие процессы (Process • Cancel with Core, Process • Cancel w/o Core, Restart after Error • Yes). Соответствующая транзакция откатывается назад. Пользователю обычно посылается сообщение, указывающее, что системный администратор отменил его процесс. Однако на самом деле невозможно отменить процессы обновления или обработки очереди вручную, так как это могло бы создать логические противоречия в базе данных.

Каждый рабочий процесс записывает отдельный файл журнала ошибок (см. раздел 15.5). Можно задать степень детализации в журнале ошибок, используя различные критерии, такие как выбор вручную или тип рабочего процесса, задавая системный параметр, или через Process • Trace из ►Process Overview. Можно ограничить загружаемые компоненты, чтобы сократить записанную информацию трассировки до определенной подобласти. Выводимые компоненты являются подмножеством выбранных компонентов загрузки и описывают информацию трассировки, которая фактически выводится из собранной информации. Рабочие процессы, которые выполняются с уровнем трассировки больше 1, выделяются желтым цветом в списке процессов.

Обзор глобальных рабочих процессов

Кроме описанного выше обзора локальных процессов, доступен обзор ►Global Work Process Overview. Эту транзакцию можно использовать для мониторинга загрузки рабочих процессов на всех активных инстанциях. Широкий диапазон критериев выбора доступен для форматирования, фильтрации и сортировки вывода.

Рис. 15.3. Выбор процесса в обзоре глобальных рабочих процессов

Монитор ICM

Администрирование и мониторинг Менеджера коммуникации Интернета (ICM, см. главу 1) выполняется в ►ICM Monitor. Подобно обзору процессов Монитор ICM (см. рис. 15.4) выводит список сконфигурированных рабочих потоков (worker threads) и их текущих состояний вместе с дополнительной информацией и возможными действиями.

Меню Goto содержит выбранные опции (см. таблицу 15.2), некоторые из которых могут быть доступны непосредственно с помощью щелчка на соответствующей пиктограмме.

Рис. 15.4. Монитор ICM

Таблица 15.2. Опции обзора рабочих потоков

Пункт меню Goto	Пиктограмма	Действие
SAP Directories		Переход к изображению каталогов SAP для выбранной инстанции (см. рис. 15.5)
OS Monitor		Переход к ►OS Monitor для выбранной инстанции (см. рис. 15.7)
Communication table		Вывод всех соединений CPI-C (клиент и сервер)
Queue Information		Информация об очереди запросов; число сконфигурированных процессов для каждого типа запросов и статистические данные об их использовании, интегрированные в выборку серверной информации в Web AS 6.10 и более поздних версиях
Host Name Buffer		Записи в сетевых конфигурационных файлах, хосты и службы, может активироваться без перезапуска инстанций
Gateway Monitor		Переход к ►Gateway Monitor для выбранной инстанции (см. главу 13).
Server Information		В Web AS 6.10 и более поздних версиях здесь консолидируются описанные выше позиции Environment, Queue Info, и Comm. Table. Можно также зарегистрироваться на сервере приложений (Logon Data) и выполнить тест соединения (Connection Test). Функция поиска в трассировке позволяет найти определенную строку во всех трассировках разработчиков в выбранной инстанции (см. раздел 15.5)

Можно использовать меню Administration для прекращения или перезапуска ICM, а также для администрирования процессора J2EE.

icmon

При необходимости некоторые из функций монитора ICM можно выполнять также на уровне операционной системы с помощью программы icmon:

□ icmon [-gs -с <командный файл> -f <файл трассировки> -t <уровень трассировки>] -u <пользователь> -p <пароль> pf=<профиль>

Аналогично утилите dpmon (см. главу 2) icmon предоставляет статистические данные о состоянии ICM и позволяет, например, модифицировать уровень трассировки рабочих процессов.

Листинг 15.1. Вывод icmon

ICM's Statistics

================

Server started at: Wed Oct 16 10:04:11 2002

Status: ICM_STATUS_RUN (pid: 956), DP port: 65000

Current number of threads: 10, peak: 10, max: 50

Current number of open connections: 0, peak: 4, max: 300

Current number of requests in queue: 0, peak: 2, max: 100

Floating average of requests in queue: 0

Statistics level: 1

Bytes read (MB): 0

Bytes read: 123456

Bytes written (MB): 1

Bytes written: 495546

No. of requests: 281

No. of rollouts: 81

No. of rollins: 81

No. of timeouts: 0

No. of errors: 23

Overall time: 0:33:17:929851

Min req time (sec): 0.019779

Max req time (sec): 154.859192

+--+----+----+--—+-------------------+--------------+

|No|thid|#req|cid|     Thread Status | Request type |

+--+----+----+--—+-------------------+--------------+

| 0|  0 | 29 |-1 |ICM_THR_STATUS_IDLE|          NOP |

| 1|  0 | 38 |-1 |ICM_THR_STATUS_IDLE|          NOP |

| 2|  0 | 28 |-1 |ICM_THR_STATUS_IDLE|          NOP |

| 3|  0 | 31 |-1 |ICM_THR_STATUS_IDLE|          NOP |

| 4|  0 | 36 |-1 |ICM_THR_STATUS_IDLE|          NOP |

| 5|  0 | 26 |-1 |ICM_THR_STATUS_IDLE|          NOP |

| 6|  0 | 31 |-1 |ICM_THR_STATUS_IDLE|          NOP |

| 7|  0 | 28 |-1 |ICM_THR_STATUS_IDLE|          NOP |

| 8|  0 | 33 |-1 |ICM_THR_STATUS_IDLE|          NOP |

| 9|  0 | 36 |-1 |ICM THR STATUS_IDLE|          NOP |

+--+----+----+---+-------------------+--------------+

+ - increase trace level by one

- - decrease trace level by one

S - increase statistic level by one

s - decrease statistic level by one

q – quit

m - menu

На рис. 15.5 показана статистика кэша сервера ICM со статистикой уровня 1 (настройка по умолчанию).

Рис. 15.5. Статистика ICM

15.2. Обзоры пользователей

Для дополнительного анализа можно выбрать функцию Goto • User в ►Server Overview для вывода ►User Overview или вызова действия непосредственно.

Деятельность пользователей на локальной инстанции

Этот обзор (см. рис. 15.6) дает представление о текущей деятельности пользователей на локальной инстанции. Система выводит следующую информацию для каждого активного пользователя: терминал, использованный для регистрации, текущую транзакцию, число открытых сеансов и время последнего выполненного диалогового шага. Можно активировать трассировку пользователей (User • Trace • Activate) для выбранных пользователей, которая записывает в журнал все действия, выполненные этими пользователями. Можно проанализировать и деактивировать трассировку пользователей аналогичным образом. Активацию трассировки пользователей рекомендуется использовать, когда необходимо анализировать проблемные ситуации, возникающие только для отдельных пользователей. При необходимости в обзоре пользователей можно также удалить сеансы пользователей и заставить пользователей выйти из системы.

Рис. 15.6. Обзор локальных пользователей

Обзор глобальных пользователей

►Global User Overview выводит всех активных пользователей с подробной информацией о типе, клиенте регистрации, выполненной транзакции и времени последнего диалогового шага (см. рис. 15.7).

Этот монитор всегда появляется на английском языке, независимо от языка регистрации в системе.

Рис. 15.7. Обзор глобальных пользователей

15.3. Системный журнал

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

Поэтому Каждый системный администратор должен ежедневно осуществлять проверку системного журнала (►System Log). Локальный системный журнал записывается для каждого сервера приложений в файл SLOG<номер_инстанции>.log в подкаталоге log-каталога инстанции (см. главу 1), если не указано иначе. Каждая запись журнала занимает 192 байт. Это означает, что используемый по умолчанию размер в 500 Кбайт соответствует 2065 записям журнала. Начиная с пустого файла при достижении файлом журнала определенного предела размера, каждая новая запись выталкивает самую старую запись из файла. Можно также определить файл резервной копии, в который переносится содержимое реального файла журнала, когда достигается максимальный размер. В этом случае файл журнала начинается снова с пустого файла.

Соответствующими параметрами являются rslg/max_diskspace/local для размера файла журнала и rslg/local/file и rslg/local/old_file для имен файлов журнала и резервной копии.

Глобальный системный журнал

Глобальный системный журнал доступен также в системах UNIX. Записи всех локальных журналов систем сконфигурированных инстанций можно объединить в одном журнале. Соответствующий файл сохраняется в подкаталоге global системного каталога; его имя по умолчанию — SLOGJ. В противоположность локальному системному журналу центральный системный журнал автоматически переносится в файл резервной копии SLOGJ0, когда файл заполняется, а старый файл SLOGJ0 перезаписывается. Можно задать размер глобального системного журнала с помощью системного параметра rslg/max_diskspace/global. Это значение является суммой SLOGJ и SLOGJ0 и по умолчанию равно 2 Мбайт.

Если желательно использовать глобальный системный журнал, выполните следующие действия:

► Определите инстанцию для записи глобального системного журнала.

► Задайте требуемые параметры журнала в профилях инстанций.

► Запустите процесс send (послать) на всех вовлеченных инстанциях.

► Запустите процесс collector (сборщик) на инстанции, определенной на первом шаге.

Выбор системных журналов

При запуске анализа записей журнала с помощью ►System Log есть возможность сначала выбрать, какие системные журналы желательно проверить. Пункт меню System Log • Choose предлагает следующие варианты:

► Local SysLog

Настройка по умолчанию; выводятся записи системного журнала на локальной инстанции.

► Remote SysLog

Выводятся записи системного журнала инстанции, определенной в поле Instance Name.

► All Remote SysLog

Выводятся записи системного журнала всех доступных инстанций.

► Central SysLog

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

Анализ системных журналов

Для анализа системного журнала (►System Log) доступно множество критериев выбора. Экспертный режим (Edit • Expert Mode) предлагает еще более широкие возможности. При желании можно ограничить выбор по:

► Временным рамкам

► Пользователю

► Коду транзакции

► Типу процесса

► Классу проблемы

► Дополнительным критериям в экспертном режиме

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

На рис. 15.8 показан фрагмент локального системного журнала системы «HUY». Системный журнал содержит последние действия запуска инстанции вместе со связанными действиями, такими как запуск процесса отправки rslgsend для глобального системного журнала. В 13:06 процесс обновления динамически переключился в рабочий процесс для фоновой обработки (о переключении рабочего режима см. главу 14). Потом в нескольких транзакциях выполняется откат. Можно вывести причину проблем, дважды щелкнув мышью на записи или выбирая в списке Edit • Details. Стандартная компоновка списка выводит отметку времени, соответствующий рабочий процесс, клиента, пользователя, код транзакции, номер сообщения и небольшой текст. При желании можно также дополнить этот вывод другой информацией, такой как имя программы, как показано в примере.

15.4. Анализ ошибок времени выполнения

Краткий дамп

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

Рис. 15.8. Фрагмент локального системного журнала

Поэтому системному администратору нужно ежедневно проверять, не произошли ли аварийные завершения программ, а если они случились, определить, почему это произошло. Для этого используется ►Dump Analysis. Вся важная фоновая информация (в дополнение к точке прекращения и времени ошибки) сохраняется для каждого завершения программы. Эта информация включает время завершения, информацию о версии R/3, используемую РСУБД и операционную систему, а также значения переменных. Пользователям предлагаются также инструменты для поиска неисправностей (см. рис. 15.9).

Рис. 15.9. Анализ дампа, компоновка Web AS

Необходимо регулярно выполнять отчет RSSNAPDL (см. раздел 9.6), чтобы удалять отчеты об ошибках времени выполнения, которые устарели или уже были проанализированы. Если желательно избежать удаления кратких дампов, так как они еще не были проанализированы, то можно сделать это с помощью Short Dump • Keep/Release.

15.5. Файлы трассировки

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

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

► Предоставление достаточного дискового пространства для файлов вывода

► Очистка файлов трассировки после завершения анализа

► Настройку уровней трассировки, в частности, восстановление уровня трассировки (или деактивация трассировки полностью) после завершения анализа.

Трассировки разработчиков

Файл журнала ошибок — трассировка разработчика — записывается для всех процессов каждого сервера приложений. Это файлы dev_<xx> в рабочем подкаталоге каталога инстанции (см. главу 1).

Число рабочих процессов идентично числу, выводимому в ►Process Overview.

Таблица 15.3. Трассировки разработчиков

Имя файла	Связанный процесс
dev_disp	Диспетчер
Dev_icm	Менеджер коммуникации Интернет (ICM)
dev_ms	Сервер сообщений
dev_rd	Процесс чтения шлюза
dev_rfc	Вызовы RFC внешних функций
dev_rfc<n>	Вызовы RFC рабочего процесса с номером n
Dev_tp	tp и R3trans
dev_w<n>	Рабочий процесс с номером n

Эти данные особенно важны, когда инстанцию невозможно запустить или когда процессы завершаются в активных системах. Можно задать уровень трассировки для каждой инстанции с помощью параметра rdisp/TRACE. Можно также настроить уровни трассировки динамически для отдельных процессов в обзоре процессов системы R/3 (см. раздел 15.1) или используя командную строку.

Уровни трассировки

Можно сконфигурировать следующие уровни детализации:

► Trace level 0

Трассировка деактивирована.

► Trace level 1 (по умолчанию)

Сообщения об ошибках записываются в файлы трассировки.

► Trace level 2

Полная трассировка.

► Trace level 3

Кроме сообщений об ошибках и действиях в файлы трассировки также записывается содержимое блоков данных.

Увеличивать уровень трассировки необходимо только при анализе специфических ошибок, так как это увеличивает также нагрузку записи в файлы. В производственных системах уровень трассировки при нормальной работе не больше 1.

При перезапуске системы R/3 создаются новые версии трассировок разработчиков dev_<xx>; последняя версия сохраняется в файлах резервной копии dev_<xx>.old.

Можно анализировать трассировки разработчиков на уровне операционной системы и, если возможно, из системы R/3 с помощью ►Trace Files, ►Process Overview или ►SAP Directories. Выбор ►SAP Directories позволяет вывести файлы на фронтальном компьютере SAP. Все файлы в каталогах R/3 могут быть доступны при настройках по умолчанию; можно использовать пиктограмму Configure (см. рис. 15.10) для создания дополнительных каталогов, доступных по логическому имени.

Трассировка фронтального компьютера

Можно активировать многоуровневую трассировку для фронтального компьютера, выбирая параметры в SAPLOGON (см. главу 4). Файлы трассировки сохраняются в рабочем каталоге на фронтальном компьютере. Чтобы вывести текущие настройки для этого каталога в SAPLOGON, выберите SAPLOGON • System Information • Additional Information. Для открытия и анализа определенных файлов трассировки можно использовать любой текстовый редактор.

Системная трассировка SAP

Можно использовать ►SAP system traces для записи подробного выполнения процесса в системе R/3. Необходимо использовать трассировку системы SAP с осторожностью и только вместе с SAP, так как записанная информация очень разнообразна и трудна для интерпретации. Трассировка системы SAP не подходит для действующих систем.

Рис. 15.10. Начальный экран SAP Directories (Каталоги SAP)

Доступные компоненты трассировки зависят от версии. Следующие компоненты доступны как минимум в R/3 4.6 и Web AS:

► Проверка полномочий

► Функции ядра

► Общее ядро

► Доступ к базе данных (трассировка SQL)

► Трассировка табличного буфера

► Вызовы RFC

► Операции блокировки

Для анализа информации трассировка выберите ►SAP System Traces • Analysis. Можно использовать различные критерии отбора для анализа, как и при активации трассировки.

Трассировка производительности

Можно активировать другие специальные функции трассировки с целью поиска неисправностей, в частности, анализа производительности отдельных транзакций. Можно использовать ►Performance Analysis (анализ производительности) для активации сбора данных в следующих областях:

► Трассировка SQL

Обращения к базе данных отчетов и транзакций

► Трассировка очередей

Поведение системных блокировок

► Трассировка RFC

Вызовы RFC функциональных модулей между инстанциями

► Трассировка буферов

Трассировка табличного буфера

В этом случае записываются все команды SQL, которые создаются действиями пользователя, вместе с продолжительностью, результатами и данными. Можно использовать ►Performance Analysis • Deactivate Trace • Display Trace (или ►Performance Analysis • Performance Trace • Display Trace or Deactivate First) сначала для фильтрации данных по различным критериям, а затем их анализа.

Рис. 15.11. Активация трассировок SQL

На рис. 15.12 показан фрагмент трассировки SQL. Например, время выполнения оператора

□ SELECT WHERE "MANDT" = 'EXP' AND "SOURCEMAND" = '001' OR "MANDT" = '001' ORDER BY "TSTAMP"

было в этом случае 59 миллисекунд (ms), поиск происходил в таблице CCC-FLOW (отслеживаемой операцией был вывод журналов копирования клиента). Продолжительность операции всегда определяется в миллисекундах. Команды, которые превышают определенное время выполнения и поэтому могут быть критическими, выделяются красным.

Рис. 15.12. Фрагмент трассировки SAL

Выберите Edit • Explain for SQL statement, чтобы вызвать план выполнения, вычисленный оптимизатором для этой команды. Выберите Goto • АВАР Display, чтобы перейти к программе АВАР, где был сгенерирован оператор SQL.

Столбцы таблицы имеют слегка отличные значения в зависимости от используемой трассировки (см. таблицу 15.4).

Таблица 15.4. Трассировка производительности

Столбец	Трассировка SQL	Трассировка очереди	Трассировка RFC	Трассировка буфера
Duration	Продолжительность выполнения оператора	Продолжительность выполнения оператора	Продолжительность выполнения оператора	Продолжительность выполнения оператора
Object Name	Таблица или процедура БД	Объект блокировки	Имя инстанции	Имя таблицы
Operation	Выполняемая в базе данных операция	Операция блокировки	Роль (клиент или сервер)	Функция, выполняемая для объекта в буфере
Records	Число обработанных записей	Number of granulates	Тип записи	Число прочитанных записей
RC	Возвращаемый код из РСУБД	0: Правильно	0: Правильно	0: Правильно
		2: Коллизия		64: Записей не найдено
		8: Внутренняя ошибка		256:Запись недоступна
				1024: Загрузка буфера
Statement	Команда SQL	Granulates	Функциональный модуль сервера источника и назначения	Тип буферизации Ключевое значение

Журналы базы данных

Все системы баз данных, используемые в среде SAP, записывают свои собственные файлы журналов, которые не зависят от системы SAP. Эти файлы можно вывести на уровне операционной системы или с помощью ►Database Monitor в системе R/3. Важные сообщения об ошибках, которые непосредственно влияют на систему R/3, также выводятся в системном журнале.

15.6. Записи блокировки

Система R/3 обладает своим собственным управлением блокировками, которое использует рабочие процессы обработки очередей (см. главу 1). Записи блокировки задаются активными программами и обычно удаляются, снова не требуя никакого вмешательства вручную. Однако если в системе R/3 возникают проблемы, например, если диспетчер инстанции или весь сервер приложений внезапно отказывает, могут сохраниться устаревшие записи блокировок. Поэтому необходимо ежедневно проверять записи блокировки и удалять их вручную, когда потребуется. Для этого действуйте следующим образом:

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

2. Выберите List. Будет выведен список всех текущих блокировок системы (см. рис. 15.13).

Кроме пользователя и клиента, который задал блокировку, система также выводит время создания блокировки и задействованные таблицы. Аргумент блокировки (ключ блокировки) особенно важен. Столбец Shared указывает, будет ли блокировка использоваться несколькими пользователями. Чтобы отсортировать список по различным критериям, можно использовать Edit • Sort by.

Рис. 15.13. Записи блокировки

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

4. Если для записей блокировки все еще существуют открытые запросы обновления, сначала проверьте и очистите эти транзакции обновления.

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

Проблемы в управлении блокировками часто являются симптомами других проблем. Поэтому, если будут обнаружены устаревшие записи блокировки, необходимо сначала проверить вовлеченную в это прикладную область, которая. Если анализ покажет, что запись блокировки не нужна, то ее можно удалить, выбирая в ►Lock Monitor и вызывая затем функцию Lock Entry • Delete. Удаление записейблокировки записывается в системном журнале инстанции.

Чтобы вывести статистические данные о поведении блокировки, в частности, об использовании общей области памяти, где хранятся блокировки, выберите Extras • Statistics. Чтобы обеспечить правильную работу управления блокировками, выберите Extras • Diagnosis. Чтобы проверить взаимодействие между управлением блокировками и задачей обновления, выберите Extras • Diagnosis in Update.

15.7. Мониторинг производительности

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

В частности, системный администратор отвечает за правильную работу монитора сигналов и всех других мониторов в системе R/3.

15.7.1. Базовое администрирование

Со временем собранные данные становятся основанием для всего анализа производительности в системе R/3. На уровне операционной системы программа saposcol собирает важную информацию о производительности компонентов вне R/3. В системе R/3 программа АРАР RSCOLL00 собирает эти данные и вычисляет значения производительности для других компонентов R/3, таких как база данных и буферы R/3. Необходимо запланировать выполнение RSCOLL00 каждый час как фоновый процесс со стандартным именем SAP_COLLECTOR_FOR_PERFMONITOR. Собранные данные записываются в таблицу MONI, называемую также базой данных производительности. Чтобы сконфигурировать базу данных производительности в системах до R/3 4.6C, выберите ►Workload Analysis • Goto • Parameters • Performance Database; в 4.6D и более поздних версиях выберите ►Load Analysis • Collector • Workload Collector • Data. Дополнительными параметрами конфигурации являются:

► Длительность сохранения собранных статистических данных

► Уплотнение данных

► Правила реорганизации

Данные производительности реорганизуются автоматически фоновым заданием SAP_COLLECTOR_FOR_PERFMONITOR на основе этих настроек.

15.7.2. Мониторы

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

Анализ рабочей нагрузки

► Workload Analysis (до версии R/3 4.6C)

Предшественник анализа нагрузки

► Load analysis

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

► Business process analysis

Анализ одиночных статистических записей

► Application monitor

Показывает распределение пользователей

Рис. 15.14. Анализ нагрузки

Буферы

► Buffer load

Показывает качество и размер наиболее важных буферов SAP, включая информацию об использовании памяти

► Table calls

Показывает статистику вызовов таблиц

► Profile parameter changes

Показывает историю изменений параметров профиля

Операционная система

► OS monitor

Мониторинг ресурсов операционной системы, таких как память, центральный процессор, файловая система, жесткие диски

► OS system configuration

Показывает текущие параметры операционной системы

► OS parameter changes

Показывает историю изменений параметров операционной системы

База данных

► Database monitor

Выводит наиболее важную статистику для анализа деятельности базы данных и предоставляет доступ к журналу базы данных

► Lock waits

Показывает число ожидающих и расширенных блокировок

► Tables and indexes

Показывает статистику ресурсов, анализ таблиц, и анализ индексов

► DB parameter changes

Показывает историю изменений для параметров базы данных

Знакомые по предыдущим версиям R/3 мониторы сигналов были полностью интегрированы в инфраструктуру мониторинга (см. главу 16), и только некоторые из этих мониторов все еще могут вызываться отдельно в R/3 4.6C по историческим причинам.

15.8. Администрирование базы данных

Администратор базы данных отвечает за управление развернутой РСУБД и базой данных. Поскольку ассоциированные с этим задачи являются специфическими для РСУБД, то их можно описать здесь только в общем.

Наиболее важными видами деятельности системного администратора, включающими мониторинг базы данных и администрирование, являются:

► Планирование, выполнение и мониторинг резервного копирования базы данных

► Планирование, выполнение и мониторинг резервного копирования журналов транзакций

► Планирование, выполнение и мониторинг проверки содержимого ленты (резервной копии базы данных) и согласованности базы данных

► Планирование, выполнение и мониторинг генерации статистики для оптимизатора на основе стоимости

► Планирование мощности и мониторинг ресурсов (на уровне операционной системы и базы данных)

► Конфигурирование и мониторинг параметров базы данных

Аналогичные инструменты доступны для каждой РСУБД, используемой с системой R/3; однако их вид и имена могут различаться в деталях.

15.8.1. Регулярно планируемые задачи

База данных играет крайне важную роль в системе R/3. Она является центром хранения данных. Поэтому крайне необходимо регулярно выполнять резервное копирование данных, хранящихся в базе данных, чтобы иметь возможность восстановить данные в случае ошибки. Для этой и других регулярно выполняемых задач в систему R/3 интегрирован ►DBA Planning Calendar.

Здесь можно спланировать наиболее важные административные задачи базы данных для фоновой обработки (см. рис. 15.15). Они включают:

► Резервное копирование базы данных на ходу (в сети) или остановленной (вне сети)

► Пошаговое резервное копирование данных

► Резервное копирование областей журнала

► Резервное копирование отдельных областей данных

► Обновление статистики оптимизатора

► Анализ структур базы данных

► Анализ статуса базы данных

Рис. 15.15. Недельное планирование в календаре планирования DBA

Оптимизатор на основе стоимости

Все системы управления реляционными базами данных, применяемые в настоящее время с системами R/3, используют оптимизатор на основе стоимости для вычисления стратегии выполнения команд SQL. Если есть несколько планов выполнения, то оптимизатор на основе стоимости определяет наиболее экономную стратегию. Стоимости вычисляются как общее число обрабатываемых блоков данных, т. е. записей реальных данных и любой используемой индексной информации. Эта стратегия основывается на статистике данных в таблице, такой как число записей и различных значений в индексированном столбце. Статистики, используемые оптимизаторами, обновляются не автоматически. Администратор базы данных должен обновлять их в зависимости от динамики базы данных, как минимум, еженедельно и после существенных изменений. Устаревшая статистическая информация хуже, чем отсутствие информации, так как она может иметь большое влияние на скорость доступа.

Проверка

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

Резервное копирование

По возможности желательно создавать резервную копию всей базы данных производственных систем ежедневно. Чтобы вывести суммарную информацию для последних резервных копий, выберите ►Backup Logs; выберите ►Database Logs для подробной информации. При возникновении ошибки файлы журналов потребуются для восстановления множества данных, начиная с последней завершенной резервной копии, чтобы восстановить последующие изменения данных. Для этого должны быть доступны все данные из областей журнала без пробелов. Все системы РСУБД не перезаписывают данные в журнал, пока не будет сделана должным образом его резервная копия. Если данные не были скопированы, то риск будет двояким: кроме потенциальной потери данных, может быть полностью заполнена область журнала. В этом случае база данных (и поэтому также система R/3) больше не сможет работать. Можно использовать специальные инструменты РСУБД или предоставляемые SAP инструменты для администрирования баз данных вне системы SAP. Наиболее широко используемым в установках SAP инструментом администрирования баз данных Oracle является sapdba.

15.8.2. Уровень заполнения и объекты базы данных

Администраторы базы данных должны постоянно следить за увеличением базы данных. Недостаточное пространство для хранения данных в БД может сделать систему R/3 неработоспособной. Поэтому необходимо регулярно проверять уровень заполнения базы данных и увеличивать базу данных при необходимости. Чтобы вывести информацию о размере базы данных и содержащихся в ней объектах, выберите ►Tables and Indexes. Этот монитор предоставляет информацию о текущем уровне заполнения и его изменении, а также размер отдельных объектов, таких как табличные пространства, таблицы, и индексы. На рис. 15.16 показано изменение уровня заполнения базы данных в графической форме для SAP БД, В то же самое время вычисляется прогноз, чтобы помочь администраторам выявить потенциальные узкие места.

Рис. 15.16. Уровень заполнения базы данных

Согласованность словаря

Кроме требований к пространству отдельных объектов, система R/3 регулярно проверяет объекты, определенные в словаре данных R/3 и в базе данных. Системные администраторы должны обеспечить, чтобы между R/3 и базой данных не возникало никаких несогласованностей. Отсутствующие индексы могут приводить к громадной потере производительности. После обновления, в частности, всегда необходимо использовать этот монитор для проверки согласованности объектов и создания всех отсутствующих объектов.

Обзор стандартных задач

В таблице 15.5 представлены все регулярно повторяющиеся административные задачи в действующей системе R/3. Задачи системного мониторинга можно сократить соответственно для систем разработки и консолидации, доступность которых обычно не должна быть такой же высокой. ►

Таблица 15.5. Стандартные административные задачи

Деятельность	Пути доступа и коды транзакций	Периодичность	Подробнее
Проверка монитора сигналов	►Alert Monitor	Несколько раз в день	Глава 16
Проверка системного журнала	►System log	Несколько раз в день	Раздел 15.3
Проверка ошибок времени выполнения	►Dump Analysis	Ежедневно	Раздел 15.4
Статус инстанций и рабочие режимы	►Control Panel	Еженедельно	Глава 14
Статус серверов приложений и рабочие процессы	►Server Overview; ►Process Overview	Ежедневно	Раздел 15.1
Проверка службы обновления	►Update Administration	Ежедневно	Глава 10
Проверка обновлений	►Update Monitor	Ежедневно	Глава 10
Проверка службы спула	►Output Control	Ежедневно	Глава 11
Проверка записей блокировок	►Lock Monitor	Ежедневно	Раздел 15.6
Проверка заданий фоновой обработки	►Job Selection	Ежедневно	Глава 9
Проверка регулярных заданий обслуживания	►Job Selection	Ежемесячно	Раздел 9.6
Обслуживание статистики оптимизатора	►DBA Planning Calendar	Еженедельно и по мере необходимости	Раздел 15.8
Выполнение и проверка резервного копирования	►DBA Planning Calendar; ►Backup Logs; ►Database Logs	Ежедневно	Раздел 15.8
Проверка административных журналов базы данных	►Database Logs	Ежедневно	Раздел 15.8
Проверка согласованности базы данных	►DBA Planning Calendar	Один раз за цикл резервного копирования	Раздел 15.8
Проверка уровня заполнения базы данных	►Tables and Indices	Еженедельно	Раздел 15.8
Проверка уровней заполнения файловой системы	Команда операционной системы	Регулярно и по мере необходимости
Проверка согласованности объектов базы данных	►Tables and Indexes	Как минимум после обновления	Раздел 15.8
Анализ производительности	►Load Analysis	По мере необходимости	Раздел 15.7
Проверка сеансов пакетного ввода	►Batch Input	Регулярно, если используются процедуры пакетного ввода	Глава 13
Проверка работы шлюза	►Gateway monitor	Регулярно, если используются шлюзы	Глава 13
Проверка потоков ALE на стороне отправителя и получателя	►MLE Status Monitor	Регулярно, если используется ALE	Глава 13
Коммуникация RFC	►Transactional RFC; ►qRFC Monitor Inbox; ►qRFC Monitor Outbox	Регулярно, если используются соединения RFC	Глава 13

Помощник администратора системы

►System Administration Assistant был создан для поддержки системных администраторов как часть инициативы SAP Ready-to-Run (готовность к работе). Наиболее важные вопросы системного администрирования перечислены в System Administration Assistant в древовидной структуре, отсортированной по ежедневным, еженедельным, годовым и нерегулярно требуемым задачам. Кроме подробной документации по отдельным вопросам, которые можно вывести из структуры, можно также запустить требуемые действия непосредственно и пометить их как завершенные.

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

На рис. 15.17 показаны административные задачи, которые должны выполняться ежедневно для поддержки производственной системы с базой данных Oracle; несколько первых шагов уже были выполнены.

Рис. 15.17. Ежедневные задачи в Помощнике администратора системы

15.10. Советы

► Трассировка разработчика и уровень трассировки процесса диспетчера

Можно задать уровень трассировки диспетчера и вывести файл трассировки с помощью ►Process Overview • Process • Trace • Dispatcher, хотя в обзоре процессов сам процесс не показан.

► Запись в журнал трассировки — Автоматическое восстановление уровня трассировки

Начиная с версии SAP Web Application Server, можно определить максимальный размер файла трассировки. Для поиска случайной ошибки можно увеличить уровень трассировки соответствующего рабочего процесса до 2 или 3; файл трассировки затем автоматически с регулярными интервалами проверяется на наличие заранее определенных комбинаций слов. Если комбинация будет найдена, то уровень трассировки автоматически сбрасывается в 1. Если файл трассировки достигает определенного максимального размера, он сохраняется в файле резервной копии <имя_файла_трассировки>.old и создается новый файл трассировки.

► Восстановление локального системного журнала

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

► Глобальный анализ производительности

Необходимость анализа производительности во всей инфраструктуре системы mySAP делает необходимым создание и оценку файлов трассировки и статистический анализ бизнес-процесса даже за границами системы. Кроме того, должно выполниться автоматическое тестирование работы и тестирование конфигураций на удаленных системах. Можно использовать для этой цели ►Global Performance Analysis, начиная с SAP R/3 4.6C.

► Таблица блокировок

Таблица блокировок является на самом деле общей областью памяти, а не таблицей. Чтобы изменить ее размер, нужно модифицировать параметр инстанции enque/table_size.

► Обработка очередей в центральной системе

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

► Очистка файловой системы

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

15.11. Транзакции и пути доступа меню

Alert monitor: SAP Menu • Tools • CCMS • Control/Monitoring • Alert Monitor (RZ20)

ALE status monitor: SAP Menu • Tools • ALE • ALE Administration • Monitoring • Status Monitor for ALE messages (BD87)

Application monitor: SAP Menu • Tools • Administration • Monitor • Performance • Workload • Application Monitor (ST07)

Backup logs: SAP Menu • Tools • CCMS • DB Administration • Backup Logs (DB12)

Batch input: SAP Menu • Tools • Administration • Monitor • Batch input (SM35)

Buffer load: SAP Menu • Tools • Administration • Monitor • Performance • Setup/Buffers Buffers (ST02)

Business process analysis: SAP Menu • Tools • Administration • Monitor • Performance • Workload • Bus. Trans. (STAD)

Control panel: SAP Menu • Tools • CCMS • Control/Monitoring • Control Panel (RZ03)

Database logs: SAP Menu • Tools • CCMS • DB Administration • Operations Monitor (DB24)

Database monitor: SAP Menu • Tools • Administration • Monitor • Performance • Database Activity (ST04)

DBA Planning Calendar: SAP Menu • Tools • CCMS • DB Administration • DBA Planning Calendar (DB13)

DB parameter changes: SAP Menu • Tools • Administration • Monitor • Performance • Database • Parameter Changes (DB03)

Dump analysis: SAP Menu • Tools • Administration • Monitor • Dump Analysis (ST22)

Trace files: SAP Menu • Tools • Administration • Monitor • Traces • Developer Traces (ST 11)

Gateway Monitor: SAP Menu • Tools • Administration • Monitor • System Monitoring • Gateway Monitor (SMGW)

Global performance analysis: Отсутствует в стандартном меню (ST30)

Global user overview: SAP Menu • Tools • Administration • Monitor • Performance • Exceptions/Users • Active users • Users global (AL08)

Global work process overview: SAP Menu • Tools • CCMS • Control/ Monitoring • Work Process Overview (SM66)

ICM Monitor: SAP Menu • Tools • Administration • Monitor • System Monitoring • Internet Communication Manager (SMICM)

Job selection: SAP Menu • Tools • CCMS • Jobs • Maintenance (SM37)

Load analysis: SAP Menu • Tools • Administration • Monitor • Performance • Workload Analysis (ST03N)

Lock monitor: SAP Menu • Tools • Administration • Monitor • Lock Entries (SM12)

Lock waits: SAP Menu • Tools • Administration • Monitor • Performance • Database • Exclusive Lock Waits (DB01)

Message server overview: Отсутствует в стандартном меню (SMMS)

OS monitor: SAP Menu • Tools • Administration • Monitor • Performance • Operating System • Local • Activity (ST06, OS06)

OS parameter changes: SAP Menu • Tools • Administration • Monitor • Performance • Operating System • Local/Remote • Parameter Changes (OS03)

OS system configuration: SAP Menu • Tools • Administration • Monitor • Performance • Operating System • Remote • Activity (OS07)

Output control: SAP Menu • Tools • CCMS • Spool • Output Controller (SP01)

Performance analysis: SAP Menu • Tools • ABAP Workbench • Text • SQL Trace (ST05)

Process Overview: SAP Menu • Tools • Administration • Monitor • System Monitoring • Process Overview (SM50)

Profile parameter changes: SAP Menu • Tools • Administration • Monitor • Performance • Setup/Buffers Parameter Changes (TU02)

qRFC monitor inbox: Отсутствует в стандартном меню SAP (SMQ2)

qRFC monitor outbox: Отсутствует в стандартном меню SAP (SMQ1)

SAP directories: SAP Menu • Tools • Administration • Monitor • Performance • Exceptions/Users • Exceptions • SAP Directories (AL11)

SAP system trace: SAP Menu • Tools • Administration • Monitor • Traces • System Trace (ST01)

Server overview: SAP Menu • Tools • Administration • Monitor • System Monitoring • Servers (SM51)

System administration assistant: SAP Menu • Tools • Administration • Monitor • System Administration Assistant (SSAA)

System log: SAP Menu • Tools • Administration • Monitor • System Log (SM21)

Table calls: SAP Menu • Tools • Administration • Monitor • Performance • Setup/Buffers Table Calls • Calls (ST10)

Tables and indexes: SAP Menu • Tools • Administration • Monitor • Performance • Database • Tables/Indexes (DB02)

Transactional RFC: SAP Menu • Tools • Business Documents • Environment • Transactional RFC (SM58)

Update monitor: SAP Menu • Tools • Administration • Monitor • Update (SM13)

Update program administration: Отсутствует в стандартном меню SAP (SM14)

User overview: SAP Menu • Tools • Administration • Monitor • System Monitoring • User Overview (SM04)

Workload analysis: SAP Menu • Tools • Administration • System Monitoring • Monitor • Performance • Workload Analysis (ST03)

15.12. Дополнительная документация

Быстрые ссылки

► SAP Service Marketplace, псевдоним systemmanagement

► SAP Service Marketplace, псевдоним performance

Указания SAP Service Marketplace

Таблица 15.6. Указания SAP для системного мониторинга

Содержание	Указание
FAQ: Lock management R/3	552289
Several enqueue work processes	127773
System error in the block handler, overflow lock table	13907
Contents of table TCOLL	12103
Get the latest saposcol	19227
saposcol: monitoring processes	451166

15.13. Контрольные вопросы

1. В какой каталог записываются трассировки разработчиков?

a. \users\<sid>adm

b. \usr\sap\<SID>\<instance>\work

c. \usr\sap\<SID>\SYS\global

2. Пользователь информировал вас, что его сеанс завершился с ошибкой. К сожалению, он не записал никакой дополнительной информации об останове. В каком месте лучше всего начать анализ ситуации?

a. Нигде. Если нельзя получить дополнительную информацию, то нет способа узнать причину ошибки.

b. Проверьте все ошибки времени выполнения в системе R/3.

c. Проверьте системный журнал.

d. Проверьте журнал резервного копирования.

ГЛАВА 16 АРХИТЕКТУРА МОНИТОРИНГА

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

В расширяемой инфраструктуре специализированные программы сбора накапливают и сохраняют данные и ключевые значения для заранее определенных объектов в общей области памяти и в таблицах базы данных систем mySAP. Эти данные можно анализировать на основе различных критериев, используя продукты независимых поставщиков и монитор сигналов (Alert Monitor), интегрированный в Систему управления вычислительным центром (CCMS — Computing Center Management System). В дополнение к локальному анализу самих контролируемых систем можно также сконфигурировать центральную систему mySAP, где собираются все данные систем SAP и других систем. Общая инфраструктура имеет три слоя:

► Сбор данных

► Сохранение данных

► Администрирование данных и анализ

Взаимодействие этих слоев представлено на рис. 16.1.

16.1. Монитор сигналов

16.1.1. Основы

В дополнение к локальному мониторингу отдельных систем архитектура мониторинга централизованно контролирует несколько систем mySAP — их критические компоненты, статистику и производительность в системной инфраструктуре. Внешние, отличные от SAP системы также могут присоединяться и контролироваться. Монитор сигналов (см. раздел 16.1.2) выводит значения, которые собраны и проанализированы согласно различным критериям в архитектуре мониторинга. Системный администратор может задавать зависящие от системы пороговые значения для входящей информации. Когда входящая информация превышает эти пороговые значения или падает ниже них, можно отметить такую ситуацию как неправильное функционирование (или сигнал), изменяя цвет светофора в Мониторе сигналов (см. рис. 16.3). Можно также определить методы анализа и автоматического реагирования, присвоить эти методы элементам дерева для подробного анализа проблемы, информировать системного администратора и включить автоматические исправляющие действия.

Рис. 16.1. Архитектура мониторинга

Основное достоинство Монитора сигналов состоит в том, что он независимо уведомляет системных администраторов об отклонениях, не требуя выполнения явного запроса или регистрации в соответствующей системе. Системы mySQL обладают рядом инструментов анализа для своих разнообразных компонентов (см. главу 15); однако администраторы должны самостоятельно инициировать такой анализ. Кроме того, разработанный SAP Монитор сигналов может анализировать системную инфраструктуру независимо на основе выбранных параметров и специально заданных пороговых значений и порождать при необходимости сигналы. Системный администратор может затем использовать специальные инструменты, интегрированные в программное обеспечение mySAP для запуска подробного анализа на основе информации Монитора сигналов, или может немедленно начать исправлять указанную проблему.

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

Набор мониторов

Мониторы сигналов объединяются для специальных целевых групп в так называемые наборы мониторов и поставляются с настройками по умолчанию, которые позволяют начать использовать их базовые функции немедленно после установки системы. Заранее определенные мониторы (с незначительными, зависящими от версии различиями) расположены в CCMS в ►Alert Monitor:

► SAP CCMS Monitor Templates

Мониторы для регулярного администрирования системой SAP

► SAP CCMS Technical Experts Monitors

Мониторы для выявления неисправностей и для управления самой архитектурой мониторинга

► SAP CCMS Monitors for Optional Components

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

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

Рис. 16.2. Заранее определенные наборы мониторов (Версия 6.20)

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

16.1.2. Компоненты

Набор мониторов является логическим объединением любого числа мониторов; сами мониторы организованы в древовидную структуру.

Элементы дерева мониторинга

Узлы ветвей в дереве мониторинга называются элементами дерева мониторинга (МТЕ — monitoring tree elements). МТЕ логически объединяет лежащие ниже узлы или другие МТЕ. Они называются также итоговыми узлами мониторов (monitor summary nodes) или просто узлами.

Атрибуты мониторинга

Листья дерева мониторинга формируются через атрибуты мониторинга, описывающие тип информации отдельных элементов системы mySAP, которые находятся под наблюдением. Атрибут мониторинга относится к одной характеристике объекта мониторинга. Определены следующие типы атрибутов мониторинга:

► Атрибуты производительности

Атрибут производительности определяет меру для размера или частоты события. Если определенные пороговые значения превышаются, то цвет соответствующей записи в дереве мониторинга изменяется.

► Атрибуты статуса

Появление одного определенного сообщения включает сигнал.

► Атрибуты журнала

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

► Деятельность

Наблюдается деятельность определенных элементов системы, таких как R/3 Services. Если контролируемые элементы отказывают, включается сигнал.

► Текстовые атрибуты

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

Рис. 16.3. Элементы монитора

Объект мониторинга

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

► Dialog, включающий атрибуты мониторинга ResponseTime, ProgramErrors и UsersLoggedIn

► R3Syslog, включающий атрибуты мониторинга BasisSystem, Database и Applications

► Server Configuration, включающий атрибуты мониторинга R/3 Kernel Release, Machine Type и Host

Объект монитора является также МТЕ, наименьшим итоговым узлом монитора. Несколько МТЕ можно объединить, чтобы сформировать другой МТЕ для улучшения обозримости вывода. Если сигнал порождается атрибутом мониторинга (например, потому что входящие данные превышают сконфигурированное пороговое значение или падают ниже его), соответствующий атрибут и все узлы более высокого уровня выделяются на изображении красным цветом. Следовательно, взгляд на узел верхнего уровня показывает администратору, когда возникла проблема, по крайней мере, с одним из подчиненных атрибутов в дереве иерархии. Желтый фон указывает на предупреждение; зеленый — на нормальный статус системы (см. рис. 16.4).

Рис. 16.4. Вывод статуса узла с помощью цветовых сигналов

Реальные и виртуальные МТЕ

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

16.1.3. Техническая реализация

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

Сборщики данных

Эти задачи выполняют сборщики данных (см. рис. 16.1). Эти программы, написанные на C, АВАР или Java, собирают требуемые данные и сохраняют их в определенных сегментах памяти (сегментах монитора) на сервере. Кроме собранных данных, в сегменте памяти также сохраняются определенные пользователями пороговые значения. Просто анализируя память, система может обнаружить отклонения от пороговых значений. Можно добавлять свои собственные сборщики данных, если требуется собирать и контролировать дополнительные данные. Эти сборщики можно интегрировать в архитектуру мониторинга с помощью определенных программных интерфейсов.

Одним из примеров важного сборщика является сборщик данных операционной системы saposcol (см. главу 15). saposcol является независимой программой, которая выполняется на каждом сервере независимо от инстанции SAP и определяет подходящие данные операционной системы. Примеры включают:

► Использование памяти (виртуальной и физической)

► Загрузку ЦП, деленную в процентном отношении на время системы, время пользователя и время простоя

► Использование физического дискового пространства и файловых систем

► Использование ресурсов текущими процессами

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

Поскольку деятельность saposcol зависит от системы, то для каждой операционной системы определяются слегка разнящиеся данные.

Примерами других сборщиков данных являются отчет RSDSLAN1, который собирает данные в ЛВС для метода CCMS_OSJLAN, и модуль функций RDDS_BP_CLASSAWP, который подсчитывает число фоновых процессов, зарезервированных для запросов класса A для метода CCMS_BP_ CLASSA_WR.

Агенты

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

Рис. 16.5. Использование агентов

SAP предоставляет следующих агентов для различных систем:

► SAPCCMSR

Этот агент работает вместе со сборщиком данных операционной системы saposcol. Агент управляет этими данными в соответствующей общей области памяти и посылает их выбранной инстанции R/3. Эта техника может использоваться для любого компонента SAP, а также для систем, отличных от SAP. Кроме анализа данных в ►Alert Monitor можно также оценить их из ►OS System Configuration.

► SAPCCM4X

Агент SAPCCM4X улучшает соединение между системой SAP с 4.x Basis и центральной системой мониторинга с Release 4.6C или более поздней версией. Для переноса собранных данных не требуется никакого диалогового рабочего процесса па центральном сервере.

► SAPCM3X

Необходимо установить агента SAPCM3X для мониторинга систем mySAP с версией Basis Release 3.x. Этот агент создает независимый общий сегмент памяти для управления данными.

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

Установка и регистрация агентов

Если желательно использовать агентов для дополнения системы мониторинга, поступите следующим образом:

1. Загрузите текущую версию агента из SAP Service Marketplace.

2. Скопируйте агента в его рабочий каталог.

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

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

- Мониторинг файлов журналов

- Мониторинг определенных файловых систем или процессов

- Мониторинг клиентов или транзакций

5. Перезапустите агента. На этом шаге соединения RFC с агентом создаются автоматически в центральной системе мониторинга.

Все агенты обратно совместимы по отношению к версии SAP. Это означает, что агент CCMS может работать в любой системе SAP вместе с версией, которая меньше или равна его собственной версии. Поэтому всегда необходимо использовать самые последние доступные версии агентов CCMS. Поскольку создание экземпляров агентов зависит от операционной системы, то SAP Service Marketplace имеет соответствующих агентов для различных операционных систем и их версий. Обычно все доступные агенты SAPCCMSR, SAPCCM4X и SAPCM3X архивированы в общем файле CCMAGENT.SAR. Загрузите соответствующий архив для используемого аппаратного окружения из SAP Service Marketplace из раздела /patches или с хоста служб SAP sapserv3 (см. главу 3). Воспользуйтесь для распаковки архива инструментом SAPCAR, который доступен в каждой инсталляции SAP.

Агентам требуется рабочий каталог для хранения файлов конфигурации и журналов (см. таблицу 16.1).

Таблица 16.1. Рабочие каталоги агентов мониторинга

Агент CCMS	Каталог UNIX	Каталог NT
SAPCCMSR	/usr/sap/tmp/sapccmsr или: $DIR_PERF/sapccmsr	\\<host>\saploc\prfclog\sapccmsr
SAPCCM4X	$DIR_LOGGING/sapccm4x	%DIR_LOGGING\sapccm4x
SAPCM3X	$DIR_PERF/sapcm3x	%DIR_PERF\sapcm3x

Введите следующие команды для установки и регистрации агентов:

□ sapccmsr -r [ -f <имя_файла_установки> ]

[ pf=<путь_доступа_к_профилю> ]

sapccm4x -r [ -f <имя_файла_установки> ]

[ pf=<путь_доступа_к_профилю> ]

sapcm3x -r [ -f <имя_файла_установки> ]

[ pf=<путь_доступа_к_профилю> ]

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

Значение пути доступа к профилю различается для агентов. Необходимо определять этот путь доступа к профилю для SAPCCM4X; в этом случае используется профиль контролируемой инстанции SAP. Если используются два другие агента, то вы узнаете, что либо не существует инстанции SAP (SAPCCMSR), либо версия SAP не имеет архитектуры оперативного мониторинга (SAPCM3X). В этом случае (при желании) файл профиля можно использовать для контроля следующих настроек:

► Размер сегмента монитора в байтах общей памяти как alert/MONI_SEGM_SIZE (только SAPCCMSR)

► Рабочий каталог агента и локальной программы saposcol, DIR_PERF

► Полный путь доступа сборщика данных операционной системы, exe/saposcol

Файлы журналов агентов

При запуске агента создается файл журнала <имя_агента><IDпроцесса>.log, в рабочем каталоге этого агента. Этот файл используется для записи всех шагов инициализации и сообщений об ошибках, вызванных выполнением агента. Также записываются любые проблемы с конфигурационными или управляющими файлами.

Агенты выполняются как службы в системе Windows и как процессы в UNIX. Поэтому агенты запускаются и останавливаются вместе с операционной системой Windows. В UNIX используют следующие явные команды

□ sapccmsr -DCCMS [ pf=<путь_доступа_к_профилю>]

sapccm4x -DCCMS [ pf<путь_доступа_к_профилю>]

sapcm3x -DCCMS [ pf<путь_доступа_к_профилю>]

для запуска агентов и те же самые команды с параметром -stop для останова агентов.

Как только агенты будут запущены, собранная ими информация появляется в наборе мониторов. Данные агента SAPCCMSR расположены в ►Alert Monitor в наборе мониторов SAP CCMS Technical Experts Monitors, в разделе System/All Monitoring Segments/All Monitoring Contexts как виртуальный узел SAP_CCMS_<имя_хоста>; контексты с именем SAP_CCMS_<имя_хоста>_local принадлежат агенту SAPCM3X. Контексты данных, поставляемых SAPCCM4X, расположены в том же месте; единственным различием является тип коммуникации с инстанциями SAP. Если поставка информации от агента прерывается, то можно вывести обзор всех сегментов памяти, которые сообщают центральной инстанции мониторинга, используя ►Monitoring: Properties and Methods • Technical Infrastructure • Overview of Segments (до Basis Release 4.6D) или ►Monitoring: Properties and Methods • Technical Infrastructure • Display Topology (в Basis Release 6.10 и позже). Segment type Agent перечисляет требуемые сегменты, которые можно проанализировать после двойного щелчка.

16.2. Настройка монитора сигналов

Монитор сигналов (Alert Monitor) служит для визуального указания на критические ситуации. Цвета МТЕ, выводимые вдереве мониторинга, изменяются с зеленого на желтый или красный в зависимости от определенных пороговых значений и их уровня опасности. Определение критической ситуации различается от системы к системе. Поэтому необходимо настроить используемые по умолчанию значения, которые предоставляет SAP с наборами мониторов.

16.2.1. Интегрирование удаленных систем

Определение соединений RFC

Чтобы осуществлять мониторинг нескольких компонентов из центральной системы SAP, необходимо зарегистрировать нелокальные компоненты, которые желательно контролировать как новые контексты в

► Monitoring: Properties and Methods. Прежде всего необходимо определить два соединения RFC (см. главу 13). Рекомендуется определять соединения эти RFC следующим образом:

► Извлечение данных

Должен быть возможен доступ для чтения к общим сегментам памяти, которые содержат данные, чтобы извлекать данные, собранные на удаленных системах. Для этого необходимо сконфигурировать пользователя с типом «CPIC» (до Basis Release 4.6D) или «Communication» (в Basis Release 6.10 и позже).

► Функции анализа

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

Затем можно добавить другую систему в Technical Infrastructure • Create Entry for Remote Monitoring.

16.2.2. Создание мониторов и наборов мониторов, зависимых от заказчика

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

Для создания собственного монитора с требуемыми МТЕ сделайте следующее:

1. Вызовите функцию обслуживания на экране ►Alert Monitor через Extras • Activate Maintenance Functions. В меню появятся функции активного изменения.

2. Выберите Monitor (Set) • Create.

3. Ведите имя для набора мониторов и определите, кому разрешено его обслуживать и просматривать. Обратите внимание на то, что имя не должно начинаться с «SAP».

4. Сохраните введенные данные; при этом создается пустой набор мониторов в качестве контейнера для специфических мониторов заказчика.

5. Чтобы создать статический монитор в этом новом наборе мониторов, снова выберите Monitor (Set) • Create в новом наборе мониторов; будут выведены все доступные МТЕ.

6. Выберите все МТЕ, которые желательно включить в монитор, и сохраните монитор с легко запоминающимся именем.

Внесение изменений

Выбранные МТЕ интегрированы теперь в новый монитор. Если желательно сделать изменения, выберите Monitor (Set) • Change. В частности, если желательно добавить новую систему и сделать ее видимой в центральном мониторе, необходимо добавить соответствующие параметры дополнительной системы (см. выше). Поэтому имеет смысл использовать в больших динамических системных инфраструктурах добавление существующих мониторов на основе правил. Сначала либо выберите существующий монитор, который будет обновлен с помощью правил, либо создайте новый монитор, как описано выше. Затем действуйте следующим образом:

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

2. При выборе Edit • Create Node • Rule node выводятся доступные правила, которые можно использовать для динамического улучшения структуры монитора во время запуска.

На рис. 16.6 показано добавление монитора с правилом CCMS_GET_ MTEJBY_CLASS в отношении всех доступных систем и МТЕ класса CPU_ Utilization. Когда вызывается монитор, текущие данные по использованию ЦП выводятся для всех систем, которые зарегистрированы и доступны через RFC.

При необходимости можно перенести набор мониторов на другие системы. Это означает, что сначала можно создать собственные наборы мониторов в системе разработки, протестировать их, а затем распространить в системной инфраструктуре. Для переноса наборов мониторов на другие системы используйте функцию ►Alert Monitor • Monitor (Set) • Transport Monitor Set.

16.2.3. Специальные настройки свойств

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

Properties в МТЕ делятся на следующие области, которые имеют различные значения в зависимости от типа используемого МТЕ.

Общие свойства

Можно определить следующие свойства в области General:

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

Рис. 16.6. Монитор на основе правил

► Видимость для групп пользователей в зависимости от полномочий пользователя (до Basis Release 4.6B).

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

► Настройки для свойств монитора

Эти настройки включают вес или важность настройки, максимальное число сигналов соответствующего типа для сохранения и ограничения для включения сигнала.

Методы

Каждому МТЕ можно присвоить до трех методов в области Methods. Функциональные модули, отчеты, URL или транзакции можно использовать в качестве методов. Также возможны команды на уровне операционной системы при условии, что они были определены как внешние команды (см. главу 9).

Определены следующие различные методы (см. рис. 16.7):

► Метод сбора данных

Метод сбора данных является инструментом, который поставляет значения контролируемым атрибутам, присвоенным в конечной инстанции. Необходимо различать активные и пассивные сборщики данных; только пассивные сборщики данных определяются и конфигурируются в архитектуре мониторинга. Наиболее важной спецификацией является частота, с которой собираются новые значения. Активные сборщики данных запускаются непосредственно контролируемыми приложениями и не контролируются Монитором сигналов (Alert Monitor). Данные сообщаются с нерегулярными интервалами, на которые невозможно влиять. Всем MTS уже присвоены по умолчанию методы сбора данных. Метод сбора данных <No Method> описывает активный сборщик данных, который невозможно модифицировать.

► Метод анализа

Метод анализа определяет, какое действие будет включаться для более подробного исследования проблемы, которая выводится в мониторе. Например, действие для МТЕ для мониторинга качества буфера R3BufferSpaceUsed, состоит в выводе анализа ►Buffer Load.

► Метод автоматического реагирования

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

Прежде чем можно будет использовать отчет, функциональный модуль, URL или транзакцию в качестве метода, необходимо зарегистрировать соответствующий объект как метод и присвоить ему имя метода. Для этого запустите ►Monitoring: Properties and Methods и выберите Methods • Create New Method. Во время определения метода выясняют, какой тип метода вовлечен (сбор данных, анализ, автоматическое реагирование) и как он будет выполняться (вручную, в диалоговом или в фоновой режимах). Можно также присвоить параметры. Обзор Methods • Definitions содержит все доступные в системе методы, включая заранее сконфигурированные методы автоматического реагирования, которые можно использовать при необходимости. Например, шаблоны для отправки сообщений уже предоставлены SAP. Системный администратор может создавать новые инструменты и интегрировать их в системы mySAP в любое время. Можно написать программу АВАР, которая включает определенное действие в системе, когда возникает некоторая проблема.

Свойства производительности, статуса и журнала

Самый нижний уровень в дереве мониторинга содержит атрибуты мониторинга. Этим атрибутам мониторинга присвоены дополнительные пороговые значения (в наиболее широко понимаемом определении) в окне Properties. Определения пороговых значений различаются в зависимости от типа используемого свойства монитора:

► Атрибуты производительности

Сигнал включается, как только данные превышают сконфигурированное пороговое значение или падают ниже его. Пороговые значения активно используются при измерении производительности; в данном случае это понимается как мониторинг ResponseTime в МТЕ Dialog (см. рис. 16.8).

► Атрибуты статуса

Одним из примеров использования атрибута статуса для порождения сигнала является появление сообщения об ошибке в определенном компоненте, таком как задача обновления (см. рис. 16.9).

Рис. 16.7. Присвоение метода

► Атрибут журнала

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

Необходимо особо внимательно конфигурировать пороговые значения. Если эти значения сконфигурированы слишком строгими и нарушаются во время обычной работы системы mySAP, то будут постоянно включаться красные сигналы. Система будет включать сигнал для состояния, которое в действительности является нормальным. И наоборот, пороговые значения могут быть сконфигурированы настолько слабыми, что никогда не будут нарушаться, фальсифицируя также сигналы Монитора сигналов — даже если ситуация достигнет критического уровня, цвет монитора не будет изменяться, чтобы указать на наличие проблемы. Поэтому, если возможно, необходимо сконфигурировать пороговые значения таким образом, чтобы все сигналы светофора были зелеными при нормальной работе системы. Выделяйте только те состояния, что отклоняются от нормы. Поскольку может оказаться трудно определить соответствующие пороговые значения во время начальной фазы реализации системы mySAP, то лучше использовать сначала значения по умолчанию, заданные SAP, или оценить свои собственные значения.

Рис. 16.8. Определение порогового значения

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

Последний человек, изменивший объект, записывается в свойстве Additional Information.

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

1. Выберите требуемый атрибут в ►Alert Monitor и выберите Properties.

2. Переключитесь из режима вывода в режим изменений и модифицируйте требуемые свойства.

3. Выберите Edit • Properties • Use for individual MTE, чтобы сохранить измененные свойства только для выбранного элемента.

Рис. 16.9. Свойство атрибута статуса

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

Классы МТЕ

Чтобы упростить администрирование, элементы дерева мониторинга с аналогичными физическими и логическими свойствами объединяются вместе в классы МТЕ. Класс МТЕ R3BufferHitRatio, например, объединяет все МТЕ, которые описывают качество буфера. Поэтому вместо присваивания метода анализа ►Buffer Load каждому МТЕ, можно выбрать атрибут класса для реализации изменения во всех МТЕ этого класса.

Группы атрибутов

Группы атрибутов характеризуют общие пороговые значения для генерации сигналов для выбранного типа объектов.

Варианты свойств

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

1. Запустите ►Monitoring: Properties and Methods.

2. Выберите Properties • Variants • Create.

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

4. Введите имя варианта.

Можно также скопировать и изменить один из существующих вариантов:

1. Запустите ►Monitoring: Properties and Methods.

2. Выберите Properties • Variants • Create.

3. Будет выведена подборка свойств, которые можно скопировать.

4. Введите имя варианта.

Активируйте новый вариант, используя Variant • Activate. Новый вариант теперь сгенерирован и активирован. Все настройки Customizing, которые определяются в дальнейшем, будут автоматически присваиваться варианту свойств. Можно легко вернуться к значениям SAP по умолчанию, переключаясь на вариант свойств SAP-DEFAULT. Можно обслуживать несколько вариантов свойств, чтобы легко и быстро адаптировать мониторы к специальным ситуациям. Можно также переносить варианты свойств: если был создан и протестирован удовлетворительный вариант свойств в одной системе mySAP, то можно перенести этот вариант в любую другую систему mySAP. Для этого выберите ►Monitoring: Properties and Methods • Properties Variants • Variant Overview. Выберите необходимый вариант и выполните Variant • Transport.

Чтобы присвоить вариант свойств операционному режиму, выберите ►Maintain Operation Mode • Operation Mode • Change и введите вариант свойств.

16.3. Анализ мониторов сигналов

Чтобы обеспечить сохранение работоспособности системы mySAP и инфраструктуры необходимо обязательно анализировать сигналы. Существуют два представления событий мониторов. Начальный экран, вызываемый через Current Status, показывает все сигналы, действительные в данный момент. Можно нажать кнопку Open Alerts, чтобы перейти к представлению всех собранных сигналов. Дважды щелкните на МТЕ, чтобы вывести в виде таблицы соответствующие сигналы, которые хранятся по уровням опасности. Можно использовать кнопку Properties, чтобы определить, какие сигналы надо сохранить для каждого монитора: все, самые старые, самые новые или только те, что представляют текущий статус.

Чтобы удалить известные сигналы из вывода, щелкните на Complete • Alerts на этом изображении (или прямо из монитора сигналов). Выбранные значения сохраняются в базе данных сигналов, но не используются для оценки текущей ситуации; используются только новые значения. Отметим, что эту функцию необходимо применять только после анализа, если вы исключили причину проблемы или смогли диагностировать ее как не критическую. Щелкните на Show Alert History, чтобы вывести историю всех включенных до сих пор сигналов. Это позволяет оценить уровень опасности текущей ситуации относительно прошлых ситуаций. Выберите Goto • Display Details, чтобы вывести данные выбранного атрибута монитора. Если требуется более точный анализ проблемы, можно щелкнуть на значке Start Analysis Method или дважды щелкнуть на МТЕ, чтобы перейти прямо к транзакции, которая была определена как метод анализа.

Закрытие сигнала удаляет его из списка активных сигналов и сегмента монитора, однако он сохраняется в базе данных. Поэтому необходимо также периодически удалять эти записи из базы данных. Это можно сделать с помощью метода анализа для объекта мониторинга AlertsInDB в Monitor CCMS Self-monitoring совокупности SAP CCMS Technical Experts Monitor или конфигурируя автоматическую реорганизацию, которая удаляет сигналы из базы данных, когда сегмент монитора достигает определенного уровня заполнения или после определенного числа дней. Это делается с помощью изменения значения параметров CMPL_ALERT_AFTER_DAY и CMPL_ALERT_IF_QUOTA для метода CCMS_Segment_Space_Collect с помощью ►Monitoring: Properties and Methods • Methods • Definitions.

16.4. Примеры настройки

Мониторы сигналов доступны для всех системных компонентов SAP. Начальная основная задача для системного администратора состоит в настройке пороговых значений и обслуживании методов реагирования. Можно также сконфигурировать агентов (см. раздел 16.1.3), что предоставит дополнительные возможности мониторинга.

16.4.1. Анализ файла журнала

Можно использовать агентов SAPCCMSR, SAPCCM4X или SAPCM3X для анализа содержимого любых текстовых файлов. Агент ищет в файлах определенные текстовые строки и выводит результаты в монитор сигналов. Чтобы сконфигурировать адаптер журнала, выполните следующие действия:

► Определите файлы журналов для поиска

Записи Logfile в конфигурационном файле sapccmsr.ini

► Определите целевую текстовую строку

Запись Pattern в соответствующем управляющем файле для файла журнала

► Сконфигурируйте появление сигнала в центральном мониторе сигналов

Записи в соответствующем управляющем файле для файла журнала.

Конфигурационный файл sapccmsr.ini

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

Таблица 16.2. Конфигурационные записи в файле sapccmsr.ini

Параметр	Значение	Описание
Plugin	<путь_доступа>	Имя библиотеки, которая будет загружаться агентом
Logfile	<путь_доступа>	Конфигурационный файл для адаптера журнала
LogfileParam	DelTree	Устаревшие элементы удаляются из общей памяти
OsColFile	<путь_доступа>	Имя файла для фильтрации поддеревьев в области действия мониторинга операционной системы
Alertlog	<путь_доступа>	Имя файла для хранения полученных сигналов

В листинге 16.1 показан пример конфигурационного файла. Файл c:\saploc\PRF-CLOG\sapccmsr\ccmsini.ini был определен как управляющий файл для анализа файла журнала.

Листинг 16.1. Конфигурационный файл для агентов CCMS

### Конфигурационный файл для агентов CCMS SAPCCMSR,

### SAPCM3X и SAPCCM4X

###

### Формат записей для подключаемых модулей:

# Plugin <полный путь доступа общей библиотеки для загрузки>

###

### Формат записей для мониторинга файла журнала:

Logfile с:\saploc\PRFCLOG\sapccms r\ccmsini.ini

###

### Формат записей для возможности удаления деревьев, если

### не существует соответствующего файла журнала:

### Этот параметр необязателен. Если он не определен, то

### дерево продолжает оставаться

# LogFileParam DelTree

###

### Формат записей для механизма фильтрации

### Значения SAPOSCOL:

# OsColFile <полный путь доступа шаблона oscolfile>

#

Листинг 16.2. Управляющий файл ccmsini.ini (Мониторинг файла журнала БД SAP)

LOGFILE_TEMPLATE

DIRECTORY="c:\sapdb\LVC\db"

FILENAME="knldiag"

MTE_CLASS="SAPDB_LOG"

SHOWNEWLINES=1

MONITOR_FILESIZE_KB=5

PATTERN_0="cannot"

VALUE_0=RED

SEVERITY_0=51

MESSAGEID_0="RT-013"

Настройки в этом управляющем файле означают, что файл knldiag в каталоге c:\sapdb\LVC\db анализируется автоматически. Все мониторы, которые агент сможет сгенерировать для контроля файла, присваиваются классу дерева мониторинга SAPDB_LOG (параметр MTE_CLASS). Преимущество такого подхода состоит в том, что все настройки и изменения в общих свойствах и методах влияют на этот класс МТЕ в общем.

SHOWNEWLINES заставляет выводиться в мониторе новые записи, которые были добавлены в этот файл в последнюю минуту. Размер файла также будет контролироваться. Если размер файла превышает определенное значение в 5 Кбайт, то будет включаться сигнал (параметр MONITOR_FILESIZE_KB). Можно использовать PATTERN_<x> для определения строк символов, которые будут включать сигнал. В предыдущем примере красный сигнал включается, когда будет найдено слово «cannot» (VALUE_<x>). Степень опасности сигнала (SEVERITY<x>) задана как 51. Сообщение 013 класса сообщений RT (MESSAGEID_<x>) является выводом. В этом месте при анализе данного файла можно использовать все сообщения, которые были определены в ►Message Maintenance и доступны. RT-013 означает «Подробное описание отсутствует». Управляющий файл завершается точкой «.» на последней строке файла.

16.4.2. Метод автоматического реагирования: Отправка почты

Одним из важных решений, которое будет неотделимо от конфигурирования монитора, является тип метода автоматического реагирования. Обычно в качестве метода автоматического реагирования можно использовать любой функциональный модуль и отчет. Автоматическое реагирование может включать также отправку e-mail, однако сначала необходимо будет сконфигурировать SAPconnect, чтобы система SAP могла послать e-mail (см. главу 13).

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

1. Запустите ►Monitoring: Properties and Methods на клиенте 000 системы.

2. Выберите Methods • Definitions.

3. Сделайте двойной щелчок, чтобы выбрать метод CCMS_OnAlert_Email.

4. Настройте свойства метода, особенно параметры (Parameters). Можно определить отправителя как существующего пользователя

SAP на клиенте 000 или любого пользователя SAP с обозначением <SID>:<клиент>:<имя>, начиная с версии Basis Release 6.10. Определенный пользователь записывается как отправитель сигнализирующей почты, генерируемой монитором. Необходимо выбрать действительный адрес e-mail в качестве получателя (Recipient). Параметр Recipient Type определяет тип адреса. «U» обозначает e-mail Интернета. Генерируемые сообщения e-mail посылаются по этому адресу. Можно также использовать список распространения. Методы автоматического реагирования присваивают либо с помощью ►Monitoring: Properties and Methods • Properties • Assigned MTE Classes, Properties • Single MTEs, либо непосредственно в ► Alert Monitor.

Если желательно отправлять сообщения e-mail различным пользователям для каждого монитора сигналов, скопируйте метод CCMS_OnAlert_Email под другим именем и настройте параметры соответствующим образом.

16.4.3. Фильтрация системных журналов

В качестве другого примера использования мониторов сигналов в этом разделе показано, как фильтровать специфические сообщения из системного журнала системы SAP и отвечать на них. Можно, например, послать e-mail, когда возникает критическая ошибка базы данных. Отдельный набор мониторов предоставляется для анализа системных журналов инстанций mySAP. Эти мониторы расположены в ►Alert Monitor в разделе SAP CCMS Technical Expert Monitors • System /All Monitoring Segments / All Monitoring Context. Для каждой инстанции определяется узел, который посылает отчет системе SAP и имеет следующую структуру имени: <имя_хоста>_<SID>_<номер_инстанции>. Узел R3Syslog появляется ниже узла инстанции. Системный журнал дифференцируется дальше в зависимости от функции системы. Все мониторы в узле R3Syslog поставляются активными сборщиками (см. раздел 16.2.3); это означает, что их невозможно сконфигурировать непосредственно в архитектуре мониторинга.

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

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

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

Выберите монитор системного журнала, такой как BasisSystem. Перейдите в область Properties и измените настройки сигнала в разделе Log Attribute. Задайте пороговое значение для красного сигнала больше 50. Затем увеличьте критичность выбранных сообщений (до значения больше 50). В дальнейшем только эти значения будут превышать пороговое значение красного сигнала. Существуют два способа настройки критичности сообщений.

Рис. 16.10. Методы в мониторах системного журнала

Обслуживание сообщений системного журнала

Выберите ►System Log Messages • Edit • List All Numbers, чтобы вывести список всех доступных в системе сообщений системного журнала. Выберите требуемое число, такое как BY2 - Database error 8с6 occurred at8c3. Вы автоматически перейдете на начальный экран ►System Log Messages; выбранный номер сообщения является заданным заранее. Выберите Edit • Maintain. Кроме определения категории, где сообщение системного журнала выводится в дереве монитора сигналов, можно также настроить критичность сообщения (см. рис. 16.11). Поэтому можно фильтровать сообщения выбранного системного журнала и включать для них специальные действия, увеличивая их критичность. В примере выше увеличение критичности для сообщения BY2 будет включать красный сигнал в случае ошибок базы данных.

Модификация монитора сигналов

Можно также изменить критичность сообщений системного журнала через монитор свойств в узле R2Syslog. Помните, что любые изменения в одном из мониторов будут влиять на все мониторы в узле R3Syslog. Изменения в мониторе сигналов будут переопределять все существующие определения, сконфигурированные при обслуживании системного журнала. Чтобы переконфигурировать критичность сообщения системного журнала, выберите Filters в свойствах монитора.

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

Рис. 16.11. Обслуживание системного журнала

16.5. Советы

► Использование saposcol в диалоговом режиме

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

□ saposcol -d

запускает диалоговый интерфейс. Можно ввести

□ Collector> dump <parameter> <option>

чтобы вывести данные, которые saposcol записал в свой общий сегмент памяти. Введите quit или exit, чтобы выйти из диалогового режима.

► Активация мониторинга процесса с помощью saposcol

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

□ $PROC

<имя_процесса> <имя_пользователя>

<имя_процесса> <имя_пользователя>

…

$

Можно заменить сегменты имен на «*». Необходимо перезапустить saposcol, чтобы активировать новую конфигурацию.

► Исключение из мониторинга файловых систем/дисковых областей

Можно исключить дисковые области и файловые системы из процесса мониторинга, например, если непрерывно поступают сигналы об известной ситуации, которая оценена как некритическая (например, если статическая дисковая область имеет уровень заполнения около 100%). Для этого включите в файл dev_filter в рабочем каталоге saposcol список файловых систем и дисковых областей, которые желательно исключить:

□ $DISK

<имя_диска>

…

$FSYS

<имя_файловой_системы>

…

► Сокрытие данных в сегменте мониторинга

Если желательно, чтобы сборщик операционной системы собирал определенные данные, но не передавал их в сегмент мониторинга центральной системы мониторинга, то можно реализовать это условие с помощью записи в конфигурационном файле sapccmsr.ini. Введите путь доступа к управляющему файлу с ключом записи OsColFile; определите значения, которые желательно подавить в этом управляющем файле.

► Сортировка сигналов в списке сигналов

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

► Центральный метод автоматического реагирования

Можно определить методы автоматического реагирования, чтобы обеспечить автоматические ответы на сигнал. При настройках по умолчанию этот метод запускается в системе, где возникает сигнал. Начиная с Basis Release 6.10 можно сконфигурировать центральный метод автоматического реагирования, который выполняется в центральной системе мониторинга при возникновении сигнала в одной из контролируемых систем. Этот метод задается в ►Monitoring: Properties and Methods • Technical Infrastructure • Assign Central Auto-Reactions.

► Привилегии доступа для агента SAPCCM4X

Поскольку SAPCCM4X обращается к локальным общим сегментам памяти архитектуры мониторинга в контролируемой системе SAP, он должен обладать необходимыми привилегиями чтения. Необходимо предоставить привилегии <sid>adm (UNIX) или SAPService<SID> (NT).

► Сохранение данных saposcol удаленной системы в течение 30 дней

Если требуется, чтобы данные, собранные saposcol и отправленные в центральную систему мониторинга, сохранялись дольше периода по умолчанию в 24 часа, необходимо активировать позицию save last 30 days для существующего места назначения в ►SAPOSCOL • Destination.

16.6. Транзакции и пути доступа меню

Alert monitor: SAP Menu • Tools • CCMS • Control/Monitoring • Alert Monitor (RZ20)

Buffer load: SAP Menu • Tools • Administration • Monitor • Performance • Setup/Buffers Buffers (ST02)

Maintain operation modes: SAP Menu • Tools • CCMS • Configuration • Operation Modes/Instances (RZ04)

Message maintenance: SAP Menu • Tools • ABAP Workbench • Development • Programming Environment • Messages (SE91)

Monitoring: Properties and Methods: SAP Menu • Tools • CCMS • Configuration • Alert Monitor (RZ21)

OS system configuration: SAP Menu • Tools • Administration • Monitor • Performance • Operating System • Remote • Activity (OS07)

SAPOSCOL destination: SAP Menu • Tools • Administration • Monitor • Performance • Operating System • SAPOSCOL Destination (AL15)

System log: SAP Menu • Tools • Administration Monitor • System Log (SM21)

System log messages: SAP Menu • Tools • ABAP Workbench • Development • Programming Environment • System Log Messages (SE92)

16.7. Дополнительная документация

Быстрые ссылки

► SAP Service Marketplace: псевдоним systemmanagement

► SAP Service Marketplace: псевдоним monitoring

Указания SAP Service Marketplace

Таблица 16.3. Важные указания SAP в отношении мониторинга сигналов

Содержание	Указание
FAQ-GGMS monitoring infrastructure	110368
FAQ-CCMS monitor architecture: meaning of profile parameters	135503
Composite SAP note: Central monitoring of mySAP	420213
Get the latest saposcol	19227
SAPOSCOL: monitoring processes	451166
SAPOSCOL: Disk and file system filter	498112
RZ20: Monitoring operating system data	522453, 371023
CCMS agent technology (composite SAP note)	209834
SAPCM3X (CCMS monitor architecture: monitor 3x systems)	308061
RZ20: Availability of R/3 systems	381156
CCMS monitor architecture: Service level agreements	308048
RZ20: Monitoring background jobs	553953
CCMS agents: Monitoring log files	535199
Setting up tRFC and qRFG monitoring in the Alert Monitor	441269
Enable Monitoring of InQMy/SAP J2EE Engine	498179
CRM: CCMS Agent Plug-In for IPC/IMS	502461, 502463
Installation of the ITS-Plug-In for the CCMS Agent	418285
Alerts for Oracle database monitoring	483856, 426781
Auto-reactions	176492, 502959, 536535, 429265
RZ20: Automatic reorganization of alerts	414029

16.8. Контрольные вопросы

1. Какие системы и какое их количество можно контролировать с помощью CCMS?

a. только локальную систему R/3

b. несколько систем R/3, но не системы, отличные о R/3

c. несколько систем R/3, а также системы, отличные от R/3, на которых установлены соответствующие сборщики данных

2. Вы обнаружили, что для МТЕ слишком часто включается сигнал, и поэтому изменили пороговые значения. Какое утверждение правильно?

a. Измененное определение порогового значения применимо только к текущему выбранному МТЕ.

b. Измененное определение порогового значения применимо ко всему классу МТЕ.

c. Обычно изменения влияют на весь класс МТЕ. Однако эту настройку можно изменить, чтобы поддерживать также и отдельные МТЕ.

d. Пороговые значения МТЕ изменить невозможно.

Приложение A ОТВЕТЫ НА КОНТРОЛЬНЫЕ ВОПРОСЫ

Глава 1

1. b, с, d, e, g, i, j; 2. b; 3. b, d, e; 4. b; 5. d

Глава 2

1. b, d, e; 2. a, b, d; 3. a

Глава 3

1. b; 2. a; 3. a, b, с

Глава 4

1. b, с; 2. b, с; 3. а

Глава 5

1. a, b, d; 2. b, d; 3. c, d; 4. с

Глава 6

1. b; 2. b, d; 3. a; 4. с

Глава 7

1. b, с; 2. a, b, d; 3. а, с

Глава 8

1. b, с; 2. b; 3. a, c; 4. d

Глава 9

1. b; 2. a; 3. с

Глава 10

1. b; 2. c; 3. a

Глава 11

1. a, b, c; 2. a, b, c, d; 3. a, b; 4. a, b; 5. b

Глава 12

1. с; 2. с; 3. с; 4. а

Глава 13

1. b; 2. а, b, с, d; 3. а, b; 4. а

Глава 14

1. a; 2. b

Глава 15

1. b; 2. с

Глава 16

1. с; 2. с

Приложение B КОДЫ ВАЖНЫХ ТРАНЗАКЦИЙ

В следующей таблице перечислены коды наиболее важных транзакций для системного администрирования R/3 Можно вводить коды транзакций R/3 в поле команды SAP GUI Доступны следующие параметры:

► /n<код_транзакции>

Выход из активной в данный момент транзакции R/3 и запуск запрошенной новой транзакции в том же сеансе

► /o<код_транзакции>

Запуск новой транзакции в новом сеансе

► /h<код_транзакции>

Запуск новой транзакции в режиме отладки в текущем сеансе

Если ввести в поле команды /h без кода транзакции и нажать клавишу Enter для подтверждения, то текущая транзакция будет с этого момента выполняться в режиме отладки

AL08	Глобальный обзор пользователей
AL11	Вывод файлов CCMS операционной системы
AL12	Синхронизация буфера
DB02	Недостающие объекты базы данных и требования к памяти
DB12	Журналы SAPDBA
DB13	Еженедельное планирование
FILE	Архивирование: установление соответствий между логическими и физическими именами файлов — общее для всех клиентов
0SS1	Регистрация в SAP Service Marketplace
PFCG	Обслуживание роли
RZ01	Графический монитор планирования фоновых заданий
RZ02	Сетевой график инстанций
RZ03	Управляющая панель операционные режимы и состояния сервера
RZ04	Обслуживание инстанций
RZ06	Обслуживание пороговых значений для мониторов сигналов
RZ08	Монитор сигналов SAP
RZ10	Обслуживание параметров профиля
RZ20	Монитор сигналов
RZ21	Настройка монитора сигналов
S000	Короткое сообщение
SA38	Отчеты АВАР
SADG	Адреса Обслуживание типов коммуникации
SALE	Разрешение прикладных связей IMG
SAR	Администрирование архивом генерация архивных файлов
SAR0	Вывод стандартного дерева отчетов
SAR1	Структура объекта архивирования
SAR2	Определение объекта архивирования
SAR3	Архивирование настройки
SAR4	Определение классов архивирования
SAR5	Присвоение классов архивирования
SAR6	Программа генерации архива в определенное время
SARA	Администрирование архивом
SARL	Монитор вызова ArchiveLink
SG3S	Запуск удаленного отчета
SC80	Утилиты САП
SCAM	Управление САТТ
SCC1	Копирование клиента через запрос переноса
SCC3	Журнал копирования клиента
SCC4	Администрирование клиента
SCC5	Удаление клиента
SCC6	Импорт клиента
SCC7	Заключительная обработка импорта клиента
SCC8	Экспорт клиента
SCC9	Удаленное копирование клиента
SCCL	Локальное копирование клиента
SCMP	Сравнение представления/таблицы
SCPF	Генерация Enterprise IMG
SCPR1	Настройка профилей: инструмент обслуживания
SCPR2	Сравнение профилей настройки
SCU0	Сравнение настройки
SDBE	Объяснение оператора SQL
SDW0	Запуск инструментальных средств АВАР
SE01	Организатор переноса
SE03	Организатор инструментальных средств: Инструменты
SE06	Настройка Организатора инструментальных средств
SE07	Вывод статуса системы переноса
SE09	Организатор инструментальных средств
SE10	Настройка организатора
SE11	>Обслуживание словаря данных R/3
SE12	Вывод словаря данных R/3
SE14	Инструмент для преобразования таблиц словаря данных на уровне базы данных
SE15	Информационная система репозитория R/3
SE16	Вывод содержимого таблиц
SE17	Вывод общих таблиц
SE93	Обслуживание кодов транзакций
SEU	Браузер репозитория
SF01	Архивирование: установление соответствий между логическими и физическими именами файлов, зависимое от клиента
SFT2	Обслуживание календаря нерабочих дней
SFT3	Обслуживание производственного календаря
SHDB	Запись пакетного ввода
SICK	Проверка установки
SM01	Блокирование транзакций
SM02	Системные сообщения
SM04	Список локальных пользователей
SM12	Изображение и удаление блокировок
SM13	Изображение записей обновления
SW121	Системный журнал
SM28	Проверка установки
SM30	Вызов обслуживания представления
SM31	Обслуживание таблицы
SM35	Мониторинг пакетного ввода
SM36	Планирование фоновых заданий
SM37	Обзор фоновых заданий
SM39	Анализ заданий
SM49	Выполнение внешних команд
SM50	Обзор рабочих процессов
SM51	Обзор инстанций
SM56	Буферы числовых диапазонов
SM58	Журнал ошибок асинхронного RFC
SM59	Соединения RFC (вывод и обслуживание)
SM63	Вывод/обслуживание операционных узлов
SM64	Включение события
SM65	Инструмент анализа для фоновой обработки
SM66	Глобальный обзор рабочих процессов
SM69	Обслуживание внешних команд операционной системы
SMLG	Обслуживание присваивания инстанции группы регистрации
SMLI	Импорт языка
SMLT	Администрирование языка
SO00	Короткое сообщение SAPoffice
SO01	Входящий ящик SAPoffice
SO02	Исходящий ящик SAPoffice
SO03	Приватные папки SAPoffice
SO04	Общие папки SAPoffice
SO21	Обслуживание рабочего каталога ПК
SO99	Обновление информационной системы
SOA0	ArchiveLink: типы документов рабочего процесса
SOA1	ArchiveLink: раннее архивирование
SOA2	ArchiveLink: позднее архивирование
SOA3	ArchiveLink: настройки по умолчанию для раннего архивирования
SOA4	ArchiveLink: настройки по умолчанию для позднего архивирования
SOA5	ArchiveLink: сохранение и ввод
SOA6	ArchiveLink: настройки по умолчанию для сохранения и ввода
SPO0	Спул и связанные с ним области
SPO1	Управление спулом
SPO2	Изображение запросов вывода
SP11	Таблица содержания TemSe
SP12	Администрирование TemSe
SPAD	Администрирование спула
SPAM	Менеджер поддержки пакетов SAP
SPAU	Показ модифицированных объектов а среде выполнения
SPCC	Проверка согласованности спула
SPDD	Показ модифицированных объектов DDIC
SPIC	Spool: проверка установки
SPRO	Customizing- начальный экран
SPRP	Прямой ввод в управление проектом
ST01	Трассировка системы SAP
ST02	Статистика буферов R/3
ST03	Анализ рабочей нагрузки
ST04	Статистика активности РСУБД
ST05	Трассировка SQL
ST06	Монитор операционной системы
ST07	Монитор приложений
ST08	Монитор сети
ST09	Монитор сетевых сигналов
ST10	Статистика вызова таблиц
ST11	Показ трассировки разработчика
ST12	Монитор приложений
ST14	Анализ приложений
ST22	Анализ ошибок времени выполнения АВАР
ST4A	Oracle: анализ общего кэша курсора
STAT	Статистика локальных транзакций
STMS	Система управления переносом
STUN	Меню производительности R/3
SU01	Обслуживание пользователей
SU01D	Просмотр пользователей
SU02	Обслуживание профилей полномочий
SU03	Обслуживание полномочий
SU05	Обслуживание пользователей Интернета
SU10	Массовые изменения в главных записях пользователей
SU12	Массовые изменения в главных записях пользователей — удаление всех пользователей
SU2	Обслуживание параметров пользователей
SU20	Обслуживание полей полномочий
SU21	Обслуживание объектов полномочий
SU22	Использование объектов полномочий в транзакциях
SU24	Модификация индикаторов проверки SAP
SU25	Перемещение предложений SAP в таблицы заказчика
SU26	Сравнение проверок полномочий
SU3	Обслуживание зависимых от пользователей данных
SU30	Полные проверки полномочий
SU52	Обслуживание собственных параметров пользователей
SU53	Показ тестовых значений
SU56	Анализ буферов пользователей
SUPC	Профили для активных групп
SUPF	Интегрированное обслуживание пользователей
SUPO	Обслуживание организационных уровней
SWDC	Определение потока операций: администрирование
SWUE	Включение события
TU02	Показ активных параметров

Приложение C ПАРАМЕТРЫ ПРОФИЛЕЙ

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

Наиболее важные параметры R/3 представлены в следующих таблицах.

Параметры, которые используются исключительно в профиле по умолчанию R/3 DEFAULT.PFL и поэтому действуют во всей системе, перечислены в таблице С.1.

Таблица С.1. Параметры профиля по умолчанию

Параметр	Описание
SAPSYSTEMNAME	Трехпозиционный идентификатор (SID) системы R/3
SAPDBHOST	Имя сервера базы данных
sna_gateway	Имя хоста, где выполняется шлюз SNA
sna_gwservice	Порт шлюза SNA
rdisp/mshost	Имя хоста сервера сообщений
rdisp/vbname	Инстанция, служба обновления которой действует как диспетчер для всех задач обновления
rdisp/enqname	Инстанция, которая предоставляет службу очередей
rdisp/btcname	Инстанция, которая предоставляет планировщик событий
rdisp/bufrefmode	Параметры для синхронизации буферов в распределенных системах
	Для центральной инстанции: sendoff/exeauto
	В распределенных системах: sendon/exeauto
rdisp/bufreftime	Интервал в секундах между двумя синхронизациями буфера
	По умолчанию: 60
auth/no_check_in_ some_cases	Активация генератора профилей
	N: неактивный
	Y: активный (по умолчанию)
dbs/ora/tnsname	Логическое имя базы данных Oracle
	Идентифицирует базу данных Oracle, если используется SQL* Net V2.
	Соответствующее имя должно определяться в конфигурационном файле tnsname.ora.
	По умолчанию: $(SAPSYSTEMNAME)

Параметры в таблице С.2 являются типичными параметрами в профиле инстанции. Они могут также использоваться в стандартном профиле DEFAULT.PFL. Введенные в стандартном профиле значения параметров действительны во всей системе R/3, пока им не будут заданы другие значения в соответствующем профиле инстанции.

Таблица С.2. Параметры и их значения по умолчанию в профилях инстанций.

Часть 1

Область действия	Параметр	Описание
Диалог	rdisp/wp_no_dia	Число диалоговых рабочих процессов
Спул	rdisp/wp_no_spo	Число рабочих процессов спула
	rspo/store_location	Место хранения базы данных TemSe в БД; G: в глобальном каталоге R/3 /usr/sap/<SID>/SYS/global; L: в локальном файле инстанции /usr/sap/<SID>/<инстанция>/data; Т: локально в каталоге /tmp (Unix) или \TEMP (Windows NT)
	rspo/host_spool/print	Команда печати операционной системы, включая параметры
	rspo/tcp/retries	Число попыток установить соединение с удаленным устройством вывода (метод доступа U); По умолчанию: 3
	rspo/tcp/retrytime	Время в секундах между двумя попытками установить соединение с удаленным устройством вывода; По умолчанию: 300
	rspo/tcp/timeout/connect	Допустимое время ожидания (в секундах) для установления соединения с удаленным принтером; По умолчанию: 10
Обновление	rdisp/wp_no_vb	Число рабочих процессов обновления
	rdisp/wp_no_vb2	Число рабочих процессов обновления для V2
	rdisp/vbreorg	Удаление незавершенных запросов обновления при перезапуске инстанции; 1 (по умолчанию): активно; 0:неактивно
	rdisp/vbmail	Уведомляет пользователя, когда происходит прерывание обновления; 1 (по умолчанию): активно; 0: неактивно
	rdisp/vbdelete	Число дней, после которых прерванные процессы обновления будут удалены; По умолчанию: 50
Фоновая обработка	rdisp/wp_no_btc	Число фоновых рабочих процессов
	rdisp/btctime	Период времени (в секундах) между двумя запусками пакетного планировщика; По умолчанию: 60
Очередь	rdisp/wp_no_enq	Число рабочих процессов очереди
Память R/3	rsdb/ntab/entrycount	Максимальное число записей буфера в буфере ТТАВ; Рекомендация: 30000
	rsdb/ntab/entrycount	Размер буфера FTAB (в Кбайтах) Рекомендация: 30000
	rsdb/ntab/irbdsize	Размер буфера IRBD (в Кбайтах) Рекомендация: 4000
	rsdb/ntab/sntabsize	Размер буфера STAB (в Кбайтах) Рекомендация- 2500
	rsdb/cua/buffersize	Размер буфера FTAB (в Кбайтах) Рекомендация: 5000
	zcsa/presentation_buffer_area	Размер экранного буфера * 2 (в байтах) Рекомендация: 20 000 000
	sap/bufdir_entries	Максимальное число записей буфера в экранном буфере; Рекомендация: 4500
	zcsa/table_buffer_area	Размер базового буфера таблиц (в байтах)
	zcsa/db_max_buftab	Максимальное число записей в базовом буфере таблиц
	rtbb/buffer_length	Размер буфера таблицы для одной записи (в Кбайтах)
	rtbb/max_tables	Максимальное число записей в буфере таблицы для одной записи
	abap/buffersize	Размер буфера программы АВАР
	rsdb/obj/buffersize	Размер буфера импорта/экспорта (в Кбайтах)
	rsdb/obj/max_objects	Максимальное число записей буфера в буфере импорта/экспорта
	rsdb/obj/large_object_size	Оценка размера самого большого объекта в буфере импорта/экспорта (в байтах)
	rdisp/ROLL_MAXFS	Размер области памяти прокрутки, т. е. буфера прокрутки плюс файла прокрутки (блоками по 8 Кбайт); Рекомендация: оптимальное значение: 32 000, минимальное: 16 00
—	rdisp/PG_MAXFS	Размер области страничного обмена R/3, т. е. буфера страничного обмена плюс файл страничного обмена (блоками по 8 Кбайт) Рекомендация: оптимальное значение 32 000, минимальное 16 000
—	rdisp/ROLL_SHM*	Размер буфера прокрутки (блоками по 8 Кбайт)
—	rdisp/PG_SHM*	Размер области страничного обмена R/3 (блоками по 8 Кбайт)
—	em/initial_size_MB*	Начальный размер расширенной памяти (в Мбайтах)
	em/max_size_MB*	Максимальный размер расширенной памяти в Мбайтах (только под Windows NT)
—	em/address_space_MB*	Адресное пространство (в Мбайтах), зарезервированное для расширенной памяти (только под Windows NT)
	ztta/roll_first*	Размер первой области памяти, выделенной из области прокрутки (в байтах); Рекомендация: 1
	ztta/roll_area*	Размер области прокрутки в байтах Рекомендация: 2 000 000 (Windows NT) 6 500 000 (другие)
	ztta/roll_extension*	Объем памяти, который может запросить рабочий процесс в расширенной памяти (в байтах); Рекомендация: 2 000 000 000 (Windows NT); 1/3 размера расширенной памяти (другие)
	abap/heap_area_dia*	Размер памяти локального процесса (кучи), который может запросить диалоговый процесс (в байтах); Рекомендация: 2 000 000 000 по умолчанию
	abap/heap_area_nondia*	Размер памяти локального процесса (кучи), который может запросить недиалоговый процесс (в байтах); По умолчанию 400 000 000
	abap/heap_area_total*	Максимальная память кучи для всех рабочих процессов (в байтах)
	abap/heaplimit*	Если рабочий процесс занимает больше памяти, чем определено этим параметром (в байтах), то рабочий процесс автоматически перезапускается после завершения шага обработки, чтобы освободить присоединенную память; Рекомендация: 20000000

Параметры, отмеченные звездочками (*) в таблице С.2, в Windows NT задаются автоматически для R/3 4.0 с помощью Zero Administration Memory Manager. При использовании R/3 4.0 с Windows NT необходимо удалить эти параметры из профилей. Предыдущие рекомендации применимы только к R/3 в средах UNTX.

Все рекомендации применимы к хостам с основной памятью не менее 500 Мбайт для инстанции R/3 и 750 Мбайт для центральной системы R/3. Дополнительные рекомендации можно найти в книге "SAP Performance Optimization".

Таблица С.3. Параметры и их значения по умолчанию в профилях инстанций.

Часть 2

Область действия	Параметр	Описание
Монитор сигналов	alert/ALERTS	Имя файла для сохранения сигналов в архитектуре мониторов CCMS
Регистрация	login/fails_to_session_end	Число допустимых неудачных попыток регистрации, прежде чем SAP GUI будет закрыт; По умолчанию: 3
	login/fails_to_user_lock	Число допустимых неудачных попыток регистрации, прежде чем пользователь будет заблокирован; По умолчанию: 12
	login/failed_user_auto_unlock	Разблокирование блокированных пользователей на следующий день; 1: пользователи разблокируются; 0: пользователи остаются блокированными
	login/min_password_lng	Требуемая минимальная длина паролей; По умолчанию: 3
	login/password_expiration_time	Максимальный период действия пароля; По умолчанию: 0 — без ограничения
	login/no_automatic_user_sapstar	0: Если удалить пользователя SAP*, то пользователь SAP* будет доступен автоматически с паролем PASS; 1: Нет автоматически создаваемого пользователя SAP*
	login/system_client	Используемый по умолчанию клиент регистрации
	rdsip/gui_auto_logout	Автоматический выход из системы после определенного периода бездействия (в секундах); 0: неактивно
Системный журнал	rslg/max_diskspace/local	Максимальный размер файла для локального системного журнала
	rslg/max_diskspace/central	Максимальный размер файла для глобального системного журнала (только UNIX)
Трассировка	rdisp/TRACE	Уровень регистрации в трассировках разработчика; 0: Трассировка отключена; 1 (по умолчанию): Только ошибки; 2, 3 - Расширенная трассировка
Пакетный ввод	bdc/altlogfile	Каталог для реорганизации файла журнала пакетного ввода (RSBDCREO)

Приложение D СТРУКТУРА МЕНЮ

Представленные, ниже деревья меню показывают структуру пункта меню «Tools» стандартного начального экрана системы R/3 вместе с пунктами меню «System» и «Help», которые доступны в каждом меню R/3.

Следующее дерево меню показывает действия, присвоенные пункту меню «Administration»

Следующее дерево меню показывает структуру Системы управления вычислительным центром (транзакция CCMS)

Приложение E ГЛОССАРИЙ

АВАР (Advanced Business Application Programming) — Язык программирования, используемый в системе R/3 для разработки приложений.

АВАР Dictionary — Центральные метаданные всех объектов системы R/3.

ACID — Описывает базовые принципы управления транзакциями в базе данных и в R/3 означает Atomic (атомарность), Consistent (непротиворечивость), Isolated (изолированность), Durable (сохранность).

ADK (Archive Development Kit) — Набор разработчика архива. Содержит инструменты для определения коммерчески связанных данных как логическая единица архивирования (объект архивирования), методы для переноса архивируемых данных в файл архива в форме модулей функций, примеров программ, документации, администрирования архива для запуска программ, управления переносом данных, сетевых графиков для иллюстрации зависимостей между архивируемыми данными.

ADO (Active Data Object) — Активный объект данных. Определенный в приложении объект.

ALE (Application Link Enabling) — Обеспечение прикладных связей. ALE является технологией для создания и работы распределенных приложений. Основная идея ALE состоит в обеспечении распределенной но интегрированной инсталляции R/3. Это включает коммерчески управляемый обмен сообщениями согласованными данными между слабо связанными приложениями SAP.

Приложения интегрируются не через центральную базу данных, а через синхронную и асинхронную коммуникацию. Бизнес-объекты могут быть распределены между системами в инфраструктуре SAP благодаря модели распределения ALE.

ALE состоит из трех слоев: прикладные службы, службы распределения и службы коммуникации.

Alert Monitor — Монитор сигналов. Графический экран для анализа системных состояний и событий.

ANSI (American National Standards Institute) — Американский институт национальных стандартов.

API (Application Programming Interface) — Интерфейс прикладного программирования. API является логическим, тесно связанным набором интерфейсов (функций или служб) для использования ряда функций, определенных приложением.

АРРС (Advanced Program-to-Program Communication) — Коммуникация между программами в мире IBM на основе протокола LU6.2.

Application server — Сервер приложений. Сервер, на котором расположена хотя бы одна инстанция SAP.

ArchiveLink — Один из интерфейсов коммуникации между компонентами mySAP и внешними компонентами. Один из базовых компонентов системы R/3. SAP ArchiveLink включает следующие интерфейсы:

► Интерфейс пользователя: Интерфейс с приложениями R/3

► Интерфейс с внешними компонентами: системы архивации, системы и сканирования

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

ASAP — AcceleratedSAP. Стандартизованная модель процесса для реализации R/3 и других решений SAP.

Background processing — Фоновая обработка. Обработка, которая выполняется не на экране. С помощью этой процедуры данные обрабатываются в фоновом режиме, в то время как другие функции могут выполняться параллельно на экране. Хотя при фоновой обработке пользователь не может видеть процессы или оказывать на них какое-либо прямое влияние (диалоговый режим невозможен), они имеют такой же приоритет как и оперативная обработка.

BAPI (Business Application Programming Interface) — Стандартный интерфейс программирования, который предлагает внешний доступ к бизнес процессам и данным в системе R/3.

Batch input — Пакетный ввод. Методы и инструменты, которые позволяют быстро импортировать данные из последовательных файлов или электронных таблиц в базу данных R/3.

САТТ (Computer-Aided Test Tool) — Инструмент тестирования с помощью компьютера. Этот инструмент можно использовать для создания тестовых данных и для автоматизации и тестирования бизнес-процессов.

CCMS (Computing Center Management System) — Система управления вычислительным центром. Инструмент для мониторинга, управления и конфигурирования системы R/3. CCMS поддерживает функции круглосуточного системного администрирования, позволяет анализировать и распределять системную нагрузку и контролировать требования к ресурсам различных системных компонентов.

Client — Клиент. В коммерческом, организационном и техническом смысле самодостаточная единица в системе SAP с отдельными основными записями в таблице.

Control panel — Управляющая панель. Центральный инструмент мониторинга системы R/3 и ее инстанций.

CPI-C (Common Programming Interface Communication) — Общий интерфейс программирования коммуникации. Базовый интерфейс программирования для синхронной, межсистемной и межпрограммной коммуникации.

CTS (Change and Transport System) — Система изменения и переноса. CTS предоставляет инструменты для организации проектов разработки в Customizing и в АВАР Workbench, а также для переноса изменений между системами SAP и их клиентами. CTS состоит из трех блоков: Transport Organizer, Transport Management System, Transport Took.

Customizing — Пользовательская настройка. Адаптация компонента SAP для удовлетворения специальных требований заказчика с помощью выбора различных вариантов, настройки параметров и т.д.

Data archiving — Архивация данных. Удаление данных, которые не требуются в данный момент, из реляционной базы данных и сохранение их в архиве (см. также Archiving object).

Database — База данных. База данных содержит файлы, которые необходимы для постоянного хранения данных на жестком диске и одной или нескольких инстанций. Каждая система R/3 имеет ровно одну базу данных.

Database instance — Инстанция базы данных. Административная единица, которая делает возможным доступ к базе данных. Инстанция базы данных состоит из процессов базы данных и общего набора буферов базы данных в общей памяти. Как правило, для базы данных существует только одна инстанция. Примером системы базы данных, в которой база данных может иметь более одной инстанции, является DB2/390.

В системе R/3 инстанция базы данных может быть либо сама по себе на сервере, либо она может быть вместе с одной или теоретически несколькими инстанциями SAP.

Database server — Сервер базы данных. Сервер, на котором (как минимум) расположена одна инстанция базы данных.

DBA (Database administrator) — Администратор базы данных.

DCL (Data Control Language) — Язык управления данными. Элементы языка для проверки и управления транзакциями или пользователями.

DDL (Data Definition Language) — Язык определения данных. Элементы языка, используемые для определения отношений.

Deadlock — Взаимоблокировка нескольких связанных транзакций, ожидающих освобождения заблокированных объектов.

DIAG protocol — Коммуникационный протокол между SAP GUI и диалоговыми рабочими процессами на уровне приложений SAP.

Dialog work process — Диалоговый рабочий процесс. Рабочий процесс R/3 для обработки запросов пользователей, работающих в диалоговом режиме.

Dispatcher — Диспетчер. Процесс для координации рабочих процессов в инстанции.

DML (Data Manipulation Language) — Язык манипуляции данными. Элементы языка для запросов данных и изменения данных.

Dynpro (DYNamic PROgram) — Динамическая программа, состоящая из изображения на экране и нижележащей логики потока выполнения.

EDI (Electronic Data Interchange) — Электронный обмен данными. Электронный обмен структурированными данными (например, торговой документацией) между компаниями, партнерами по бизнесу внутри страны и иностранными, которые могут использовать различное оборудование, программное обеспечение и службы коммуникации. Для этого данные структурируют в соответствии с определенными стандартами.

FDDI (Fiber Distributed Data Interchange) — Распределенный обмен данными по оптоволокну.

Firewall — Брандмауэр, или сетевой экран. Программное обеспечение для защиты локальной сети от неавторизованного доступа извне.

Front-end computer — Фронтальный компьютер. «Обычно компьютер или устройство обработки, которое производит или манипулирует данными, прежде чем они будут получены другим процессором». (Компьютерный словарь. Microsoft Press).

GUI (Graphical User Interface) — Графический интерфейс пользователя. Среда, посредством которой пользователь может обмениваться информацией с компьютером. С помощью интерфейса пользователя можно выбирать команды, запускать программы, выводить файлы или выполнять другие действия, нажимая функциональные клавиши или кнопки, выбирая пункты меню или щелкая на пиктограммах с помощью мыши.

High availability — Высокая доступность. Возможность службы или системы оставаться в рабочем состоянии большую часть времени. Высокая доступность для системы R/3 означает, что запланированное и внеплановое нерабочее время можно свести к минимуму. Хорошее системное администрирование является жизненно важным для высокой доступности. Сокращения незапланированного нерабочего времени можно добиться профилактическими аппаратными и программными решениями, которые нацелены на сокращение точек отказа в службах, поддерживаемых системой R/3. Оптимальное планирование необходимых работ по обслуживанию может помочь сократить запланированное нерабочее время.

HSM (Hierarchical Storage Management) — Управление иерархической памятью. Программное и аппаратное обеспечение для архивирования данных. Система HSM управляет данными внутренне в иерархической структуре на основе частоты обращения к данным и действует для приложения как бесконечно большая файловая система.

HTML (Hypertext Markup Language) — Язык разметки гипертекста. Независимый от платформы язык создания текстовых и графических страниц для Интернета.

HTTP (Hypertext Transfer Protocol) — Протокол передачи гипертекста. Протокол для передачи данных между Web-сервером и Web-клиентом.

IAC (Internet Application Component) — Прикладной компонент Интернета. Законченные бизнес-решения для соединения системы SAP с Интернетом. С помощью IAC пользователи Интернета могут выполнять транзакции, функции и отчеты через интерфейс Web-браузера и таким образом разрабатывать бизнес процессы через Интернет или интранет.

IDES (International Demonstration and Education System) — Международная демонстрационная и образовательная система. IDES включает несколько примеров предприятий, которые служат в качестве модели для соответствующих бизнес-процессов в системе R/3. Используя простые инструкции пользователя и изменяющиеся основные и транзакционные данные, можно разыгрывать различные сценарии. IDES очень полезна в качестве тренировочного материала для проектной группы.

IDoc (Intermediate Document) — Промежуточный документ. Тип IDoc заполняется определенными данными.

IDoc type — Формат SAP, в котором должны передаваться данные бизнес процесса. IDoc является специальным бизнес процессом в форме типа IDoc. Тип IDoc описывается следующими компонентами:

► Управляющая запись

Ее формат одинаков для всех типов IDoc.

► Одна или несколько записей данных

Запись данных состоит из фиксированной административной части и части данных (сегмента). Число и формат этих сегментов различен для разных типов IDoc.

► Записи статуса

Описывают этапы обработки, через которые может пройти IDoc. Записи статуса имеют одинаковый формат для всех типов IDoc.

IMG (Implementation Guide) — Руководство по реализации. Инструмент, предназначенный для специальной настройки заказчика в системе R/3. Для каждого прикладного компонента руководство по реализации содержит:

► Все шаги для реализации системы R/3.

► Все стандартные настройки и все действия для конфигурирования системы R/3.

Иерархическая структура IMG отражает структуру прикладных компонентов R/3 и перечисляет всю документацию, которая имеет отношение к реализации системы R/3.

Instance — Инстанция. Инстанция SAP. Административная единица, в которой объединяются процессы системы SAP, предлагающие одну или несколько служб. Инстанция R/3 может предоставлять следующие службы:

► D: диалог

► V: обновление

► E: управление блокировками SAP (очередь)

► B: фоновая обработка

► S: форматирование печати (спул)

► G: шлюз SAP

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

Диспетчер управляет запросами обработки, выполняемыми рабочими процессами. Каждая инстанция предоставляет как минимум одну диалоговую службу и один шлюз. При желании они могут также предоставлять дополнительные службы. Только одна инстанция должна предоставлять службу управления блокировками SAP.

IPC (Inter Process Communication) — Коммуникация между процессами.

ITS (Internet Transaction Server) — Сервер транзакций Интернета. Интерфейс между системой SAP и сервером Web для создания динамических страниц HTML.

LAN (Local Area Network) — Локальная вычислительная сеть. Сеть в некотором месте, которая имеет обычно более высокие скорости передачи, чем в среде WAN.

LDAP (Lightweight Directory Access Protocol) — Легковесный протокол доступа к каталогу. Протокол для доступа к информационным каталогам. LDAP позволяет каждому приложению на любой платформе получить доступ к информации каталога, такой как адреса e-mail и общедоступные ключи. LDAP является открытым протоколом, что означает, что для пользователя не имеет значения тип сервера, на котором расположен каталог.

LUW (Logical Unit of Work) — Логическая единица работы. С точки зрения бизнес-логики существует определенная последовательность операций базы данных, которая следует принципам ACID (либо выполняется полностью, либо не выполняется вообще). С точки зрения системы базы данных эта последовательность составляет единицу, которая помогает обеспечить целостность данных.

MAPI (Messaging Application Programming Interface) — Интерфейс программирования приложений обмена сообщениями. Интерфейс, через который почту SAPoffice можно читать также из других приложений (клиентов MAPI), таких как Microsoft Outlook.

MCOD (Multiple Components in one Database) — Несколько компонентов в одной базе данных. Комбинированная установка компонентов OLTP и OLAP системной инфраструктуры SAP в одной базе данных, как в случае системы R/3 и системы EBP в одной базе данных. Это может помочь сократить расходы на администрирование базы данных.

OLE (Object Linking and Embedding) — Связывание и встраивание объектов.

OLTP (Online Transaction Processing) — Сетевая обработка транзакций. Обработка, связанная с обновлением данных.

OMS (Output Management System) — Система управления выводом.

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

OS (Operation system) — Операционная система.

OSS (Online Service System) — Система сетевых служб. OSS является одной из центральных систем SAP служб и поддержки. OSS может использоваться всеми заказчиками и партнерами SAP. Однако предложения новых служб становятся доступными только через SAP Service Marketplace.

PAI (Process after input) — Обработка после ввода. Техническое выполнение программы после ввода данных в экранном шаблоне (в приложениях, разработанных в АВАР).

РВО (Process before output) —Обработка перед выводом. Техническое выполнение программы, прежде чем данные выводятся в экранном шаблоне (в приложениях, разработанных в АВАР).

Performance — Производительность. Системная производительность, действующая мощность, мера эффективности системы цифровой обработки.

Popup — Всплывающее окно. Экранное окно, которое вызывается и выводится в первичном окне.

Port — Порт. Имя для канала, через который система R/3 обменивается данными с внешней системой.

Profile — Профиль.

1. Техническое объединение полномочий. Генерируется автоматически генератором профилей как часть обслуживания роли.

2. Файлы на уровне операционной системы, согласно которым задаются параметры системы R/3 при запуске (например, профиль инстанции).

Profile Generator — Генератор профилей. Инструмент для создания профилей при обслуживании роли, с помощью которого автоматически генерируется профиль полномочий на основе деятельности роли.

Pushbutton — Кнопка. Элемент графического интерфейса пользователя (GUI). С помощью простого щелчка на кнопке можно выполнить задачу, которая с ней связана. Кнопки можно активировать с помощью мыши или клавиатуры, для чего нужно поместить курсор клавиатуры на соответствующей кнопке и нажать клавишу ENTER. Кнопки могут содержать текст и/или графические символы.

Q-API (Queue Application Programming Interface) — Прикладной интерфейс программирования очередей для буферизированного, асинхронного переноса данных между децентрализованными приложениями и системами SAP R/2 и R/3 на основе CPI-C.

R/3 — Realtime System 3.

RAID (Redundant Array of Independent Disks) — Массив независимых дисков с избыточностью. Аппаратная технология, которая поддерживает избыточность дисков, используя зеркалирование дисков и связанные методы.

RDBMS (Relational Database Management System) — Система управления реляционной базой данных (РСУБД).

RFC (Remote Function Call) — Вызов удаленной функции. RFC является протоколом интерфейса SAP на основе CPI-C. В связи с этим программирование потока коммуникации между системами становится значительно легче. С помощью RFC можно вызывать определенные ранее функции и выполнять на удаленной системе или в той же системе. RFC контролирует управление коммуникацией, пересылку параметров и обработку ошибок.

Role — Роль. Объединение действий, выполняемых одним человеком, которые имеют отношение к одному или нескольким бизнес-сценариям компании. Определение ролей включает полномочия, отчеты и меню пользователя.

SAP GUI — Графический интерфейс SAP (см. также GUI).

SAP transaction (=SAP LUW) — Логический процесс в системе R/3, который с точки зрения пользователя состоит из самодостаточных единиц. Транзакция SAP гарантирует принципы ACID для нескольких шагов транзакции базы данных. Краткая форма кода транзакции, с помощью которого можно вызвать программу АВАР.

SAProuter — Программный модуль, который действует как часть системы брандмауэра и управляет сетевыми соединениями между сетью R/3 и внешним миром (например, соединением SAPNet).

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

Session — Сеанс пользователя в окне SAP GUI.

Shared memory — Общая память. Область основной памяти, которая может быть доступна нескольким процессам операционной системы, например всем рабочим процессам инстанции. Иногда используется в области РСУБД. Используется также для указания на область основной памяти, совместно используемую процессами РСУБД.

SID (SAP System Identifier) — Системный идентификатор SAP. Метка-заполнитель для трехсимвольного имени системы R/3.

SNC (Secure Network Communication) — Защищенная сетевая коммуникация. Интерфейс, через который система R/3 может общаться с внешними продуктами системы безопасности, чтобы защитить коммуникационные соединения между компонентами системы R/3.

SQL (Structured Query Language) — Язык структурированных запросов.

SSCR (SAP Software Change Registration) — Регистрация изменения программного обеспечения SAP. Процедура регистрации сделанных вручную изменений в исходных кодах SAP и репозитории объектов SAP.

Support package — Пакет поддержки. Совокупность соединений, предоставленных SAP для определенного выпуска версии компонента SAP (ранее Hot Package).

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

TCP/IP (Transmission Control Protocol/Internet Protocol) — Протокол управления передачей/протокол Интернета.

TDC (Transport domain controller) — Контроллер транспортного домена. Прикладной сервер в системе R/3 в домене переноса, из которого управляются события переноса между системами R/3 в этом домене.

TemSe (Temporary sequential objects) — Временные последовательные объекты. Сохранение данных при управлении выводом.

TMS (Transport Management System) — Система управления переносом. Инструмент управления запросами переноса между системами R/3.

ТО (Transport Organizer) — Организатор переноса. Всеохватывающий инструмент для управления всеми запросами изменений и переноса.

Transaction — Транзакция. Транзакция базы данных: Операционная единица работы в базе данных, которая следует принципам ACID.

Transaction code — Код транзакции. Последовательность буквенно-цифровых символов, которые идентифицируют транзакцию в системе SAP.

Transport — Перенос. Термин логистики программного обеспечения R/3. Экспорт и импорт объектов SAP между системами SAP.

Transport domain — Домен переноса. Логическая группа систем SAP, между которыми происходит перенос в соответствии с некоторыми правилами. Домен управляется Контроллером транспортного домена.

tRFC (Transactional RFC) — Транзакционный RFC. RFC, для которого применяются принципы ACID.

URL (Uniform resource locator) — Адрес в Интернете.

WAN (Wide Area Network) — Сеть компьютеров, которая охватывает достаточно большую географическую область. WAN состоит обычно как минимум из двух LAN (локальных сетей). Компьютеры, соединенные с сетью такого типа, обычно связываются через публичную сеть, такую как телефон. Соединение может создаваться также с помощью арендуемых линий или спутников. Самой большой WAN является Интернет.

WORM (Write Once, Read Multiple) — Однократная запись, многократное чтение. Запоминающая среда, куда можно записать только один раз, а считывать многократно. WORM гарантирует, что записанные данные не смогут измениться в точение нескольких лет. Основной областью применения является архивация данных.

WP (Work process) — Рабочий процесс. Прикладные службы системы R/3 имеют дело со специальными процессами, например для управления диалогом, размещения измененных документов, фоновой обработки, спулинга, управления блокировками. Рабочие процессы назначают выделенным серверам приложений.

XML (extensible Markup Language) — Расширяемый язык разметки. Спецификация W3C. XML является сокращенной версией SGML, который был специально разработан для документов Web. XML позволяет создавать теги для предоставления функций, которые невозможно реализовать с помощью HTML. Таким образом, например, XML поддерживает ссылки на несколько документов, в то время как ссылки HTML могут ссылаться только на один документ. XML стал стандартом обмена данными. В среде SAP XML используется как для обмена данными с внешними системами, так и (начиная с Basis release 6.10) в качестве языка описания в конфигурационных файлах установки.

Оглавление

Предисловие к серии книг

Предисловие

Введение

ГЛАВА 1 ТЕХНИЧЕСКАЯ РЕАЛИЗАЦИЯ АРХИТЕКТУРЫ КЛИЕНТ/СЕРВЕР В СИСТЕМЕ SAP R/3

ГЛАВА 2 ПЕРВЫЕ ШАГИ

ГЛАВА 3 ОБСЛУЖИВАНИЕ И ПОДДЕРЖКА

ГЛАВА 4 ПРИНЦИПЫ ИНСТАЛЛЯЦИИ

ГЛАВА 5 СОЗДАНИЕ И НАСТРОЙКА СИСТЕМНОЙ ИНФРАСТРУКТУРЫ

ГЛАВА 6 ЛОГИСТИКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

ГЛАВА 7 АДМИНИСТРИРОВАНИЕ КЛИЕНТА

ГЛАВА 8 ПОЛЬЗОВАТЕЛИ И ИХ ПОЛНОМОЧИЯ В СИСТЕМЕ R/3

ГЛАВА 9 ФОНОВАЯ ОБРАБОТКА

ГЛАВА 10 СЛУЖБА ОБНОВЛЕНИЯ

ГЛАВА 11 КОНФИГУРАЦИЯ И АДМИНИСТРИРОВАНИЕ ВЫВОДА

ГЛАВА 12 АРХИВИРОВАНИЕ ДАННЫХ

ГЛАВА 13 РАСПРОСТРАНЕНИЕ И ПЕРЕНОС ДАННЫХ

ГЛАВА 14 ОБСЛУЖИВАНИЕ ИНСТАНЦИЙ

ГЛАВА 15 МОНИТОРИНГ СИСТЕМЫ

ГЛАВА 16 АРХИТЕКТУРА МОНИТОРИНГА

Приложение A ОТВЕТЫ НА КОНТРОЛЬНЫЕ ВОПРОСЫ

Приложение B КОДЫ ВАЖНЫХ ТРАНЗАКЦИЙ

Приложение C ПАРАМЕТРЫ ПРОФИЛЕЙ

Приложение D СТРУКТУРА МЕНЮ

Приложение E ГЛОССАРИЙ