Читать онлайн «Внедрение SAP R/3: Руководство для менеджеров и инженеров». Страница 60

Модуль SD включает в себя такие требующие оперативности процессы, как заказы на продажу, уведомления о поставках, составление расписаний и выписка счетов-фактур. Например, ввод заказа на продажу вызывает проверку запасов и расписания производства, создание расписания поставок, проверку и обновление данных о кредите потребителя, выписку счет-фактуры, обновление данных по дебиторской задолженности, заносит в журнал учета данные по затратам на поставленную продукцию и т. д. Сложность операций SD можно оценить в сравнении с транзакциями модуля «Финансы» (Finance, FI), которая состоит из четырех шагов (инициация транзакции, обновление транзакции, выполнение транзакции и статус результата), в то время как транзакции SD могут состоять из 15 и более диалоговых шагов.

В SAP предусмотрен список контрольных вопросов, которые выступают в качестве координатора требований к операционной системе и реляционной системе управления базами данных (RDBMS) для выбранной платформы оборудования. Например, для основной копии системы R/3 Release 4.0А требуется примерно 15 GB дискового пространства.

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

• Высокая пропускная способность и прозрачность сети

• Простота администрирования сети.

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

Серверная сеть

Серверная сеть соединяет все серверы приложений с серверами баз данных. Для каждого диалогового шага объем данных, которыми обмениваются сервера приложений и баз данных, не превышает 20 КВ.

Пользовательская сеть

Пользовательская сеть соединяет рабочие станции пользователей с серверами приложений SAP; требования по пропускной способности этой сети во многом зависят от количества пользователей. Объем данных, которые передаются по этой сети между графическим интерфейсом SAPGUI и серверами приложений при каждом диалоговом шаге обычно не превышает 2 КВ.

Начиная с версии R/3 Release 4.0 работа программы инсталляции R3Setup направляется общей программой InstGUI, которая управляет R3Setup при установке на различные операционные системы — такие, как UNIX или NT и на различные RDBMS — такие, как Oracle, Informix и т. д.

Изначально установка начинается с уровня баз данных и затем переключается на уровень интерфейсов. Сначала инсталлируются реляционные системы управления базами данных (RDBMS) на сервер баз данных; затем устанавливается основная копия на сервер приложений (который может быть одновременно и сервером баз данных). Затем следует установка рабочих мест пользователей (причем инсталляцию необходимо проводить отдельно для каждого сервера приложений).

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

Природа рабочей среды SAP, а также среды разработки такова, что ни одна инсталляция не может проводиться по принципу односистемной платформы. Причина в следующем: вся информация содержится в хранилище R/3 и любые изменения этой информации ведут к автоматическому изменению информации в среде выполнения. Рабочий процесс интерпретирует объект, который всегда генерируется на основе исходного кода программы АВАР. Каждый раз, когда написанный на АВАР исходный код изменяется, объекты генерируются заново и только потом возможно их выполнение. В односистемной платформе это означало бы либо полную невозможность внедрения разработок в рабочую среду, либо необходимость остановки функционирования системы каждый раз, когда изменяется программа АВАР/4, что может случаться достаточно часто. Из этого вытекает необходимость использования двух- или трехсистемной платформы.

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

• Система 1: Система разработки и тестирования.

• Настройки и разработки АВАР производятся в клиенте разработки. Измененные объекты передаются второму клиенту для тестирования.

• Настройки и программы АВАР тестируются и утверждаются в клиенте обеспечения качества. В рабочую среду выпускаются только прошедшие тестирование и одобренные объекты.

• Система 2: Рабочая система.

• Эта система принимает и использует измененные объекты от клиента обеспечения качества.

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

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

• Система 1: Система разработки — среда для разработки и настройки программ.

• Система 2: Система обеспечения качества — среда, в которой производится тестирование и подтверждение изменений.

• Система 3: Рабочая система — среда, в которой работают измененные программы.

Администрирование клиентов подразумевает копирование клиентов в пределах одной или нескольких систем в зависимости от целей и требований утилит. Некоторые стандартные клиенты приведены ниже:

• Демонстрация

• Разработка

• Настройка

• Тестирование

• Обучение и образование

• Производство.

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

• Копирование клиента в рамках системы (локальное копирование)

• Копирование клиента из другой системы R/3 (удаленное копирование)

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

Ниже приведен список общих административных задач, которые необходимо выполнять на постоянной основе:

• Проверка статуса системы

• Отправка системных сообщений

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

• Просмотр протекающих процессов

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

Рис. 11.1. Экран меню Системного администрирования.

• Обновление таблиц.

На рис. 11.1 представлен экран Системного администрирования. Многие задачи выполняются с помощью CCMS, как описано в соответствующем разделе главы 7, в то время как некоторые задачи полностью или частично выполняются операционной системой.

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

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

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

• Спецификации обработки, что включает в себя информацию о различных шагах обработки — таких, как тип программы АВАР, которая будет задействоваться на том или ином этапе обработки.