
- •Міністерство освіти і науки, молоді та спорту України
- •Короткі відомості про ат «Мотор Січ»
- •Технічна реалізація архітектури кієнт/сервер r/3
- •Призначення повноважень
- •Завдання, що виконуються системною инфоструктурою
- •Адміністрування клієнта
- •Логіка програмного забезпечення
- •Фонова обробка
- •Ахітектура даних
- •Моніторинг системи
- •Висновки
- •Спиок джерел
Адміністрування клієнта
Основні поняття про клієнтів
Клієнт - це незалежно що враховується бізнес-одиниця компанії. Дане поняття включає в себе незалежний бухгалтерський баланс. Установка окремих параметрів відповідно до вимог бізнесу називається користувальницької налаштуванням (Customizing). Її можна використовувати також для завдання параметрів, діючих в масштабі всієї системи, таких як вибір виробничого календаря.
Стандартні клієнти
У стандартній системі SAP пропонує наступних клієнтів із заздалегідь заданою конфігурацією:
000 для цілей адміністрування і як шаблон для створення додаткових клієнтів
001 для цілей тестування на відповідність ECU (European Currency Unit) і як шаблон для створення додаткових клієнтів
066 для SAP Remote Services (Дистанційні сервіси)
Роль клієнта
Призначення кожного клієнта Б системі R / 3 визначається тими завданнями, для яких він іспользуетсяю При створенні клієнта це відбивається в присваиваемой йому ролі. Дана роль відображає функції клієнта і присвоєні йому атрибути:
Робочий клієнт
Клієнт для тестування
Клієнт для користувача настройки
Клієнт для демонстрації
Клієнт для навчання та підготовки
Еталонний клієнт SAP
Логіка програмного забезпечення
Запити користувача настройки
При впровадженні системи R/3 необхідні для користувача настройки (Customizing). Подібна настройка зазвичай стосується бізнес-процесів і, таким чином, залежить від клієнта (якщо клієнт представляє підрозділ компанії). Коли клієнт налаштований для автоматичного запису змін, задача і запит користувача настройки при змінах налаштувань користувача у системі R/3 створюються автоматично. Якщо маються запити користувача настройки, то можна явним чином управляти призначенням задач для таких запитів.
Переносні запити на зміни
Крім зміни в користувальницької налаштуванні може виявитися необхідним створити власні об'єкти або модифікувати об'єкти, що поставляються SAP (SAP-owned objects). Це дозволить вам налаштувати систему R / 3 у відповідності зі своїми вимогами. Подібні зміни не залежать від клієнтів, тобто діють в масштабі всієї системи. Дані при таких змінах записуються негайно в задачі, призначеної запиту на перенос.
Локальний запит на зміну
Крім використання переносите запитів па зміни (глобальних), можна вносити локальні зміни. При такому типі змін створюються локальні запити на зміни. Подібні запити не можуть переноситися в інші системи.
При призначенні завдання в запиті на зміну, що стосується розробки ПЗ, необхідно дотримуватися запобіжних заходів. Даний об'єкт блокується користувачами, які не є власниками завдання і запиту на зміну, поки що відповідає за модифікацію розробник явно не передасть повноваження на цю задачу іншому користувачеві. Якщо проект розробки завершений, деблокується спочатку задача, а потім запит на зміну. Об'єкт може бути змінений знову тільки після деблокування запиту. Такий механізм запобігає одночасна зміна одного і того ж об'єкта.
Номер запиту
Усі завдання і запити від користувачів мають унікальний ідентифікатор, що складається з трехеімвольного імені системи R / 3, ідентифікатора К9 і послідовного номера з 5 цифр, наприклад QO1K900005. Кожен запит на зміну має одного власника - керівника проекту, який відповідає за адміністрування запиту. При необхідності власника можна змінити. Запит на зміну нерідко складається з декількох задач, призначених одному користувачеві. Запит на зміну можна розглядати як проект, в якому різні користувачі мають різні завдання. Допускається передача завдання іншому користувачеві. Проект буде закінчений тільки після завершення або деблокування всіх задач в запиті на зміну (тобто після деблокування запиту на зміну). Якщо запит на зміну є стерпним або являє собою запит користувача настройки, то після переносу він деблокується автоматично. Запит на зміну стає запитом на перенос. Шлях запиту на перенос визначається при створенні системної інфраструктури.
Створення запиту користувацького налаштування
Створити запит користувацького налаштування можна двома способами:
Внести зміну і дозволити системі R / 3 згенерувати запит користувацького налаштування і задачу для зміни.
Використовувати СО для створення запиту користувацького налаштування з даною задачею. Потім внести зміну і явним чином призначити задачу.
Вибір процедури залежить головним чином від прийнятої концепції користувача. Призначаючи повноваження, можна запобігти створенню користувачами власних запитів на зміну. Це завдання можна зарезервувати для вибраної групи користувачів. Перевага подібної процедури полягає в наступному: ви зберігаєте контроль нал запитами користувацького налаштування і призначенням, а також можете для створення нового типу запиту на зміну перевизначати права розробника, наприклад дозволити йому вносити зміни тільки після створення та призначення відповідних запитів на зміну уповноваженій особі, такому як керівник проекту. Це дає можливість більш ефективно координувати розробку в системі R/3 (дів. Малий. 3).
Мал. 3.