Системный ландшафт sap erp

Корпоративные хранилища данных. Интеграция систем. Проектная документация.

Существующий системный ландшафт (описание систем) в SAP PI

Ниже представлен пример (образец) проектного документа описания систем, с которыми производится интеграция и которые включаются в справочник системного ландшафта SAP PI (SAP XI) (SLD). Приводится описание технических систем и бизнес-систем. Данный документ формируется IT-специалистом на этапе проектирования интерфейсов интеграции (обмена данными).

Описание технических систем

Код в SLD 1
Наименование 2
Описание 3
Поставщик (вендор)
Версия системы (если есть) 4
Имя хоста (IP-адрес) 5
Дополнительная информация 6

1 Указывается код системы в SLD. Технические системы кодируются по следующему правилу:

Синтаксис
Техническая система	TS_ _ _ _
Глоссарий
Определяет бизнес-единицу предприятия, для которой система предназначена
Определяет функциональное-назначение системы или саму используемую систему (через ее краткий код, например)
Уникальный порядковый двухзначный номер системы
D | Q | P | T | (для Development, Quality Assurance, Production, Training и т.д.)

Например: TS_UNH_Lexema_01_Q. TS_UK_1C_02_P, TS_MDMServer_08_P.

2 Указывается бизнес наименование информационной системы. Например, АС БП, АСУ ЗП.

3 Указывается для чего используется информационная система. Приводится краткое описание. Например, Система бюджетирования используемая в …; Расчета ЗП для сотрудников предприятия …. и т.п.

4 Версия системы. Например, SAP R/3 4.6.

5 Например, Server (192.168.0.100).

6 Например, ФИО, тел., email администратора системы.

Описание бизнес-систем

Код в SLD 1
Наименование 2
Описание 3
Принадлежность к технической системе 4
Дополнительная информация

1 Указывается код системы в SLD. Бизнес-системы кодируются по следующему правилу:

Синтаксис
SAP System	BS_ _ _
Other System	BS_ _ _ _
Глоссарий
Определяет три буквы системы
Определяет номер клиента SAP системы
Уникальный порядковый двухзначный номер системы
D | Q | P | T |
Определяет бизнес-единицу предприятия, для которой система предназначена
Определяет бизнес-назначение системы или саму используемую систему (через ее краткий код, например)

Например: BS_UNH_Lexema_01_Q. BS_UK_1C_02_P, BS_BUY001_P, BS_MDMServer_09_P.

2 Указывается бизнес наименование информационная система. Например, АС БП, АСУ ЗП.

3 Указывается для чего используется ИС. Приводится краткое описание. Например, Система бюджетирования используемая в …; Расчета ЗП для сотрудников предприятия …. и т.п.

4 Указывается код технической системы в SLD.

Источник статьи: http://www.prj-exp.ru/patterns/pattern_system_landscape.php

Системный ландшафт SAP BW, проектируем на перспективу.

Хранилища данных

Муковоз Илья Сергеевич

Архитектор решений BI

08 февраля 2013, 15:08

В данной статье рассматривается организация правильного системного ландшафта SAP BW, ориентированного на динамичное, итерационное развитие аналитической системы в многолетней; временной перспективе.

Обычно системный ландщафт SAP BW повторяет ландшафт SAP R/3 или ECC и включает в себя три базовые системы:

• BW DEV – система разработки
• BW QA – система тестирования
• BW PRD – продуктивная система

На этапе разработки и подготовки первого релиза аналитической системы поток изменений системы — линейный: BW DEV => BW QA => BW PRD, такой подход предполагает что разработки выполненные в BW DEV переносятся в BW QA систему, где производится их проверка и после подтверждения корректности работы разработка переносится в систему продуктивной эксплуатации: BW PRD.

Если речь идет о консалтинговой компании или на объекте внедрения формируется внутренний штат консультантов BW, которым необходимо «место» для обучения и экспериментов, в системный ландшафт SAP BW необходимо добавить систему «песочницу» — BW SANDBOX.

Система BW SANDBOX не должна быть связана с основным ландшафтом и предназначена в первую очередь для выполнения экспериментов и обучения консультантов.

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

• Фиксирование разработки и формирование системы обучения BW TRAIN путем копирования из BW QA. Таким образом, процесс обучения пользователей проводится в системе с зафиксированным на определенную дату состоянием. В то же время доработка системы может продолжаться, но изменения не имеют оперативного отражения в системе обучения. Выравнивание систем может быть выполнено в «ручном режиме» путем переноса необходимых запросов. Преимуществом такого подхода является возможность быстрого получения системы обучения сразу с готовыми данными, т.к. делается копия с системы тестирования, которая уже наполнена тестовыми данными, на которых осуществляется проверка работоспособности.

• Второй подход: одновременный перенос настроек в две системы: BW QA и BW TRAIN. При таком подходе в настройках транспортной системы добавляется целевая группа, которая включает две системы: систему тестирования и систему обучения. Преимуществом такого подхода является то, что система обучения BW TRAIN будет максимально соответствовать системе тестирования и будет включать все последние доработки. Недостатком такого подхода является необходимость загрузки и перезагрузки данных в систему обучения при серьезных изменениях логики, что требует отвлечения ресурсов.

В больших компаниях, например, таких как банки или крупные корпорации,

Если хотите прочитать статью полностью и оставить свои комментарии присоединяйтесь к sapland

Источник статьи: http://sappro.sapland.ru/blogs/mukovoz/8131

SAP@Pitroff.Ru

SAP Process Integration – основы. Часть 3 – System Landscape Directory.

Интеграция – вид сверху: System Landscape Directory

Сегодня мы с вами поговорим о System Landscape Directory.

Напомню общую схему всех компонент SAP Process Integration:

Рис 1: Архитектура PI – Dual Stack

System Landscape Directory (SLD) – это самостоятельный компонент SAP NetWeaver, который необходим для работы интеграционной шины.

В процессе инсталляции SAP PI мы можем выбрать – устанавливать SLD вместе с SAP PI или подключиться к уже существующей.

Помимо SAP PI, информацию из SLD использует также SAP Solution Manager – продукт для управления SAP-ландшафтом.

В каталоге SLD описаны все компоненты системного ландшафта – сервера, технические данные, программное обеспечение, логические блоки ландшафта – и связи между этими компонентами. Основой для хранения служит Common Information Model (CIM).

CIM-модель.

CIM – это стандарт группы Distributed Management Task Force (DMTF), базирующийся на объектной модели. Этот стандарт описывает общую схему реализации управления информацией в компьютерных средах.

Модель ландшафта в CIM строится на стандартных объектных сущностях:

• Класс и наследование
• Экземпляр
• Ассоциация и ссылка
• Схема

Если Вы знакомы с объектно-ориентированным программированием – можете пропустить следующий абзац.

Класс – это описание множества объектов, имеющих одинаковые признаки. Например, “сервер” – это пример класса, у которого есть признаки “операционная система”, “IP адрес”, “e-mail администратора” и другие.

Наследование – это возможность создавать новые множества, используя уже существующие. Скажем, класс “Мэйнфрейм”, унаследованный от “сервер”, будет иметь все признаки класса-родителя плюс собственные, характерные только для мэйнфреймов, признаки.

Экземпляр – это конкретный сервер, то есть его набор признаков содержит конкретные значения, к примеру: IP = 10.11.12.13, DNS = host1.domain.org , а параметр “операционная система” содержит значение “Unix”.

Термины ассоциация и ссылка можно проиллюстрировать следующей картинкой:

Рис.2: Объединение двух объектов при помощи ссылок и объекта-ассоциации

Более подробно о CIM вы можете узнать на сайте группы www.dmtf.org.

Ландшафт в SLD: договоримся о терминах.

Модель системного ландшафта в SLD состоит из трех основных частей:

• технического ландшафта,
• бизнес-ландшафта,
• программного обеспечения.

Все три части связаны между собой следующим образом:

Рис.3: Модель ландшафта в SLD

Программное обеспечение – это программные компоненты (software components), которые могут быть объединены в продукты (products).
Программный компонент – это самостоятельная часть программного обеспечения, которая разрабатывается отдельно, имеет собственную версию, может быть предоставлена на отдельном носителе, но не может быть инсталлирована и использована сама по себе. Примеры программных компонент, разработанных SAP: SAP BASIS, SAP ABA, SAP RE-FX.
Продукт – это независимое программное обеспечение, которое имеет собственную версию, может быть инсталлировано и использовано для выполнения каких-либо задач. Продукт состоит из одного или более программных компонент. Примеры продуктов – SAP PI, SAP BI, SAP ERP.

Каждый продукт может иметь сколько угодно версий продукта, точно также, как программный компонент может иметь сколько угодно версий компонента. Каждая версия продукта состоит из компонент определенной версии. В SLD зависимость версии продукта и версий его компонент определяется в объекте CIM-модели, называемом характеристика программного продукта(software feature).

Изначальная CIM-модель программного обеспечения SAP загружается в SLD при инсталляции и, в дальнейшем, модель должна актуализироваться в процессе установки патчей и апдейтов на SAP PI.

Для доступа к SLD используется следующий url: http:// :

/sld
Либо можно использовать транзакцию SLDHTMLGUI в SAPGUI – она вызовет нужный адрес.

Рис.4: Основной экран SLD (версия 7.4)

Вызовем ссылку “Products” из блока “Software Catalog”, наберем в поле фильтра “SAP ERP” и выберем на просмотр версию SAP ERP 6.0:

Рис.5: Продукты и программные компоненты в SLD

Мы видим, что версия продукта SAP ERP 6.0 состоит из множества версий программных компонент – FINBASIS версии 6.00, ST-PI2005_1 версии 7.00 и т.д.

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

Пока перейдем к следующему слою модели – техническому ландшафту.

Технический ландшафт – это описание всех технических компонент ландшафта (серверов/компьютеров) в виде CIM-модели. Информация по техническим компонентам включает в себя также все продукты и программные компоненты, инсталлированные на данном сервере/компьютере.

В SLD все технические системы делятся на следующие группы:

• Application Server ABAP (AS ABAP)
• Application Server J2EE (AS Java)
• Standalone
• Third-party

Standalone – продукты SAP, не входящие в первые две группы, third-party – все остальные (не-SAP) инсталляции.

Давайте откроем еще раз начальную страницу SLD, затем вызовем ссылку “Technical systems” из блока “Landscape”.
В открывшемся списке мы должны увидеть, как минимум, инсталляцию самого PI, а перейдя на вкладку “Installed Software” можно посмотреть установленные продукты и компоненты:

Рис.6: технические системы в SLD

В данном случае PI инсталлирован в опции “Dual Stack” – мы видим две технических системы, AS ABAP и AS Java, автоматически занесенные в SLD при инсталляции.

Инсталляции SAP умеют самостоятельно заносить в SLD данные о себе. В ABAP для этого используется транзакция RZ70, в J2EE – SLD Bridge.

Интеграционный ландшафт

SAP PI в своей работе использует интеграционный ландшафт, где участниками обмена информацией являются бизнес-системы.
Бизнес-система – это, по сути, логическое имя участника интеграции, присвоенное технической системе.
Каждой технической системе может быть присвоена только одна бизнес-система (за исключением технической системы типа AS ABAP – там бизнес-системой может выступать каждый из мандантов инсталляции).

Откроем начальную страницу SLD, затем вызовем ссылку “Business systems” из блока “Landscape”.

Рис.7: Бизнес-система в SLD

Как мы видим, технической системе ABAP (XID on saphost1, client 001) присвоено имя INTEGRATION_SERVER_XID. Каждый тип бизнес-системы имеет свой набор параметров.

Подключение новой системы к интеграционному ландщафту в SLD.

Исходя из вышеперечисленного, для подключения нового участника интеграции к SAP PI нам понадобятся следующие объекты SLD:

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

Предположим, мы хотим подключить к интеграции новую продуктивную систему ERP с настроенным модулем SAP FI.

Запустим в ERP транзакцию RZ70 и настроим соединение с SAP PI:

Рис.8: Транзакция RZ70 -настройка соединения с SLD

Проверим, появилась ли в SLD отправленная информация: пункт “Technical systems” из блока “Landscape” – там должна присутствовать наша новая техническая система. В параметре “last update” должно отображаться время запуска автоматической регистрации системы.
Проверим также передачу информации об установленном программном обеспечении – в разделе “Installed Software” должен присутствовать продукт SAP ERP 6.0, а нужные нам компоненты (FINBASIS 600 и EA-FINSERV 600) отмечены, как установленные. Если нет – то воспользуемся кнопкой “Add product” и фильтром по продуктам, а затем отметим нужные компоненты вручную и сохраним изменения.

Рис.9: Техническая система и установленные компоненты в SLD

Теперь осталось лишь создать бизнес-систему: на исходной странице SLD выбираем пункт “Business systems” из блока “Landscape”. Нажимаем кнопку “New business system..”, выбираем последовательно:

• тип системы (AS ABAP);
• техническую систему (созданную перед этим) и требуемый мандант ABAP-сервера;
• имя бизнес-системы;
• релевантные продукты и компоненты для этой бизнес-системы(не все компоненты, установленные на технической системе могут участвовать в интеграции – данный шаг позволяет выбрать только нужные);
• Роль системы (все интегрируемые системы – это application system) и соответствующий ей Integration Server SAP PI

Если все было сделано правильно, то в SLD появится новый будущий участник интеграции – бизнес-система BS_NEW_FI_ERP. Можно заполнить также другие необязательные параметры – например, описание системы и/или e-mail администратора:

Рис.10: Новая бизнес-система в SLD

Возьмем еще пример – требуется подключить не-SAP систему. Пусть это будет некоторая внешняя база данных, расположенная в нашем системном ландшафте.

Поскольку программное обеспечение системы разработано не SAP, то необходимо создать в SLD продукт и программный компонент.
На начальной странице SLD выбираем “Products” из блока “Software Catalog”, затем нажимаем кнопку “New..”.

Если какой-то из параметров процедуры создания не совсем понятен – нажмите квадратик с буквой “I” справа от поля ввода.

Задаем имя, производителя, версию и техническое имя для продукта:

Рис.11: Создание продукта в SLD

Рис.12: Создание программного компонента в SLD

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

Теперь, когда продукт и компонент созданы – переходим к созданию технической системы. В разделе “Technical systems” из блока “Landscape” нажимаем кнопку “New Technical System..”.
Заполняем параметры “System Name” и “Host name”, затем выбираем установленное ПО (созданное на предыдущем шаге).

Рис.13: Создание технической системы для non-SAP продукта

Рис.14: Создание бизнес-системы из свойств технической системы для non-SAP продукта

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

Рис.15: Бизнес-система для non-SAP продукта

О том, как информация из SLD используется в SAP PI – я расскажу в следующей статье.

Источник статьи: http://sap.pitroff.ru/sap-netweaver/sap-xi-pi/sap-process-integration-osnovyi-chast-3-system-landscape-directory/