Завдання, що виконуються системною инфоструктурою
Кожна інстальована система R / 3 містить ресурси, що охоплюють цілий спектр функцій R / 3. Це не тільки завдання, пов'язані з бізнесом, але і такі як розробка ПЗ, адміністрування та забезпечення якості. Вони призначені для спеціальних компонентів системою R / 3. Виконувати їх распологая однією лише системою R / 3, не рекомендується. Наявність однієї системи адекватно відповідає тільки вимогам підготовки та навчання млм демонстрації. Причина криється в різних вимогах, наприклад до текстової та робочої системі:
Всі зміни в репозиторії (сховищі) впливають на середу системи R / 3 (етапу виконання, а відтак - на робочу систему).
Розробники мають доступ до всіх таблиць R / 3.
Операції, з розробкою, негативно впливають на продуктивність. Наприклад, якщо програми для цілей тестування виконуються в режимі налагодження, то робочий процес діалогу в цей час не може бути призначений іншому користувачеві.
Таким чином, рекомендується розподілити завдання по різних системах і переносити їх з тестової системи в робочу тільки після перевірки на коректність функціонування. Це називається транспортуванням або перенесенням змін. СТО використовується для управління всіма модифікаціями і для розробки ПЗ в системі R / 3, а також для переносу його між системами.
Трехсістемні інфраструктури
Зміни в ПЗ і програмах ABAP, а також багато системні програми діють в маштабі всієї системи R / 3. Наприклад, неможливо протестувати проміжний код програми ABAP, поки ведеться робота з цим об'єктом. Таке "неподілювані" використання об'єкта неминуче створює "вузькі місця" в двухеістемной інфраструктурі, коли для розробки ПЗ та забезпечення якості використовується одна система. Єдине рішення полягає у використанні трехсістемной інфраструктури. З технічної точки зору це наступні три системи:
Система інтеграції, яка грає роль системи для розробки
Система консолідації, яка застосовується для забезпечення якості
Інформація, що поставляється система, що служить робочої
Ролі систем для розробки, забезпечення якості та експлуатації строго розділені. Перш ніж використовувати ПЗ в робочій системі, його потрібно ретельно протестувати в інший, окремій системі. Шляхи перенесення з однієї системи в іншу фіксовані і не можуть змінюватися, якщо не вжити для цього спеціальних тагов (див. Мал.1).
Мал. 1
Визначальним фактором у прийнятті рішення щодо вибору інфраструктури системи є співвідношення витрат і вигод (з урахуванням пропонованих до системи вимог). Незважаючи на ті переваги, які дає трехсістемная інфраструктура, її складність призводить до збільшення робіт з адміністрування. Потрібно ретельно зважити ці вимоги і оцінити витрати.
Многосістемность інфраструктури
Існують конфігурації, в яких має сенс не обмежуватися трехсістемной інфраструктурою. Наприклад, іноді краще мати кілька географічно розділених робочих систем, обслуговуючих різні філіали компанії. Технічні відмінності між системами (системою інтеграції, консолідації та системою поставки) зберігаються і в таких інфраструктурах - їх технічні функції залишаються колишніми. Такі інфраструктури охоплюють кілька паралельно функціонуючих систем одного типу. Між тим, роль даних систем не завжди можна визначити точно. В певному сенсі вона двоїста. На мал. 2 показаний приклад многосістемной інфраструктури. Точкою входу є центральна система інтеграції, яка використовується для розробки "міжнародного" ПО. Підключення до неї незалежні системні інфраструктури застосовуються для розробки ПО для конкретної країни.
Мал.2