Размещено на http://www.allbest.ru/

Вступ

Преддипломна практика є невід'ємною частиною учбового процесу. В ході її проходження студент отримує поглиблення і закріплення знань і професійних навиків, отриманих в процесі вчення на основі вивчення практичних ситуацій. Завданнями переддипломної практики є:

- ознайомлення з організацією: його структурою, основними функціями управлінських і виробничих підрозділів;

- безпосередня участь в поточній діяльності підприємства;

- підбір і систематизація матеріалів.

Я проходив преддипломну практику на підприємстві АТ «Мотор Січ» у відділі Управління обчислювальної технікию. Відділ Управління обчислювальної техніки, інформатики і зв'язку займається вирішенням основних завдань, що відносяться до впровадження і управління комп'ютерною технікою підприємства, супроводом автоматизованих систем. В ході проходження практики були пройдені основні етапи:

- отримання пропусків, інструктаж по техніці безпеки, отримання індивідуального завдання;

- ознайомлення зі структурою управління, а також з основними напрямками, які закріплені за відділом проектування автоматизаванних систем;

- збір матеріалів, передбачених завданням по практиці.

В результаті проходження практики були виконані всі поставлені завдання.

1. Короткі відомості про АТ «Мотор Січ»

Біографія підприємства почалася в 1907 році. До грудня 1915 року на нім вироблялися сільськогосподарські механізми і інструменти, виконувалися різні види механічної обробки, відливали чавун і мідь. У грудні 1915 року акціонерне суспільство «Дюфлон, Костянтинович і К°» («Дека») викупило завод і змінило профіль його виробничої діяльності.

У листопаді 1916 р. був зібраний перший шести-циліндровий двигун рідинного охолоджування «Дека» М-100. З того часу на заводі освоїли виробництво і тривалий час випускали широку гамму поршневих двигунів: М-6, М-11, М-22, М-85, М-86, М-87, М-88, АШ-82ФН, АШ-62ИР, які не поступалися, а у ряді випадків перевершували кращі світові аналоги того часу.

У 1953 р. на заводі почали виробляти реактивні двигуни РД-45, РД-500, що поклали почало настанню ери газотурбінних двигунів. Представниками нового покоління з'явилися турбогвинтові двигуни АЇ-20 (1957 р.) і АЇ-24 (1962 р.) конструкції А.Г. Івченко різні модифікації яких експлуатуються до теперішнього часу. програмний клієнт сервер адміністрування

У 1967 р. на заводі почалося освоєння виробництва двоконтурних турбореактивних двигунів і послідовно були запущені в серію двигуни АЇ-25, АЇ-25ТЛ, Д-36, Д-18Т, Д-436Т1/ТП. Газотурбінні турбовальниє двигуни сімейств ТВЗ-117, ВК-1500, ВК-2500 разом з Д-136 піднімають в піднебіння вертольоти з марками «Мі», «Но».

У 1995 р. підприємство перетворене у відкрите акціонерне суспільство «Мотор Сич». У сьогодення на підприємстві ведеться інтенсивна підготовка до серійного виробництва авіаційних двигунів Д-27, АЇ-22, АЇ-222, ВК-1500, АЇ-450, Д-36 сірок. 4А, Д-436-148, АЇ-25ТЛШ для літаків Ан-70, Ту-324, Як-48, Як-130, L-159, Ан-3, Ан-38, Бе-132МК, Ан-74ТК-300, Ан-148, вертольота Но-226, а також для переоснащення тих, що знаходяться в експлуатації Ан-2, Мі-2, L-39.

Спеціалізація підприємства

Розробка, виробництво, ремонт і супровід в експлуатації газотурбінних двигунів для військової та цивільної авіації, промислових приводів та енергетичних установок, споживчих товарів. ВАТ «Мотор Січ» - одне з найбільших в світі виробників сучасних, надійних авіаційних двигунів, які експлуатуються більш ніж в ста двадцяти країнах світу. Його товарний знак є символом конкурентоспроможної продукції, економічної та надійної.

Займаючи одне з провідних місць в світовому співтоваристві виробників авіаційної техніки, в 2007 році підприємство відзначає свій 100-річний юбілей.

Трудова біографія заводу

У 2006 році моторобудівники відзначили 90-річчя з дня випуску в серпня 1916 першого поршневого двигуна водяного охолодження «Дека» М-100 для чотиримоторного бомбардувальника «Ілля Муромець». Вся подальша історія підприємства - це поетапне освоєння в серійному виробництві нових двигунів, кожен з яких був значною віхою у розвитку вітчизняного авиадвигателестроения.

На сьогоднішній день пріоритетним напрямком діяльності підприємства є освоєння виробництва двигунів Д-436-148, АИ-222, АИ-25ТЛШ, АИ-450, АИ-450-МС.

2. Технічна реалізація архітектури клієнт/сервер R/3

Архітектура клієнт/сервер R/3

З точки зору ПЗ(Програмного забезпечення) триланкова архітектура клієнт/сервер складається з презентаційного рівня, рівня додатків та рівня БД(Баз даних). З точки зору апаратних засобів ці рівні незалежно функціонують на різних машинах або спільно на одному комп'ютері. Крім того, R/3 дозволяє розподіляти презентаційний рівень та рівень додатків по декількох комп'ютерів.

Презентаційний рівень

Для користувачів, працюючих з бізнес-функціями R/3, основне значення має презентаційний рівень. В системі R/3 він складається з графічного інтерфейса SAP(SAPGUI, Graphical user Interface). Інтерфейс SAPGUI сприймає те, що вводить користувач, та передає цю інформацію для подальшої обробки на наступний рівень - рівень додатків. Та навпаки SAPGUI отримує данні від рівня додатків та надає їх користувачу. Адміністратор системи R/3 може визначати скільки саме процесів SAPGUI будуть запускатися з клієнтських місць.

Рівень додатків

Тут виконуються фактичні обчислення та оцінки. Необхідні для цього відомості запрашуються з рівня БД. Вхідні дані обробляються рівнем додатків та передаються в БД. Рівень додатків представляє собою центр управління системою R/3, тобто це один з центральних компонентів, на котрий може впливати адміністратор системи R/3. В білшості випадків застосоване адміністратором кошти повністю інтегровані з R/3. Це озеачає, що операції з адміністрування системи R/3можна застосовувати через інтерфейс користувача SAPGUI.

Рівень БД

Цей рівень складається з реляційних систем управління базою даних(РСУБД). Обмін даних між РСУБД та процесамидодатків здійснюється черкз інтерфейс SQL. Дані в системі R/3 зберігаються в одній БД, на одному комп'ютері. Ім'я цієї БД визначається ім'ям системи R/3. Вона має складатися з трьох символів - букв у верхньому регістрі або цифр, наприклад: D10, K11, K4K, DDD.Для позначення імені системи R/3 зазвичай використовуються скорочення SID(System Identifier).



3. Призначення повноважень

Створення користувача- одне з завдань системного адмінистратора R/3 або адмінистратора користувачів. Повноваження визначаються, виходячи з того, які дії повинен використовувати користувач конкретного типу або групи. Іноді завдання призначення повноважень покладають на іншу особу - адміністратора повноважень. Рекомендується розподіляти ці обов'язки хоча б між двома особами, що дозволить звести до мінімуму ризик злому.

Повноваження та об'єкти поноважень

Кожне уповноваження у системі R / 3 засноване на так званому об'єкті повноважень. З технічної точки зору цей об'єкт являє собою модуль, що містить ім'я, поля і, можливо, значення, які представляють операції (дії). Присвоєння об'єкту повноважень процесу (звітом, транзакції або оновленню) визначення SAP.

Число об'єктів авторизації в системі R / 3 досить значно, що пов'язано з диапозоном функцій R / 3. Щоб кращє розрізняти їх, об'єкти розділяються на класи об'єктів.

Профілі повноважень

Щоб спростити завдання присвоєння повноважень, їх можна групувати в профілі повноважень, а кілька профілів повноважень - один складений профіль. Компанія SAP пропонує повний набір заздалегідь визначених профілів повноважень, що відповідають вимогам звичайного використання. В будь-який час для розроблених вами програм можна створити свої власні повноваження. Вони визначаються на основі ваших нових власних об'єктів повноважень, які можна привласнити існуючим профілям або новим створюваним вами профілем. Профілі R / 3 мають три різних стани:

· Активний / неактивний

· Обслужений (тобто адаптованості до поточних умов або залишений без змін).

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

4. Завдання, що виконуються системною инфоструктурою

Кожна інстальована система R / 3 містить ресурси, що охоплюють цілий спектр функцій R / 3. Це не тільки завдання, пов'язані з бізнесом, але і такі як розробка ПЗ, адміністрування та забезпечення якості. Вони призначені для спеціальних компонентів системою R / 3. Виконувати їх распологая однією лише системою R / 3, не рекомендується. Наявність однієї системи адекватно відповідає тільки вимогам підготовки та навчання млм демонстрації. Причина криється в різних вимогах, наприклад до текстової та робочої системі:

· Всі зміни в репозиторії (сховищі) впливають на середу системи R / 3 (етапу виконання, а відтак - на робочу систему).

· Розробники мають доступ до всіх таблиць R / 3.

· Операції, з розробкою, негативно впливають на продуктивність. Наприклад, якщо програми для цілей тестування виконуються в режимі налагодження, то робочий процес діалогу в цей час не може бути призначений іншому користувачеві.

Таким чином, рекомендується розподілити завдання по різних системах і переносити їх з тестової системи в робочу тільки після перевірки на коректність функціонування. Це називається транспортуванням або перенесенням змін. СТО використовується для управління всіма модифікаціями і для розробки ПЗ в системі R / 3, а також для переносу його між системами.

Трехсістемні інфраструктури

Зміни в ПЗ і програмах ABAP, а також багато системні програми діють в маштабі всієї системи R / 3. Наприклад, неможливо протестувати проміжний код програми ABAP, поки ведеться робота з цим об'єктом. Таке "неподілювані" використання об'єкта неминуче створює "вузькі місця" в двухеістемной інфраструктурі, коли для розробки ПЗ та забезпечення якості використовується одна система. Єдине рішення полягає у використанні трехсістемной інфраструктури. З технічної точки зору це наступні три системи:

· Система інтеграції, яка грає роль системи для розробки

· Система консолідації, яка застосовується для забезпечення якості

· Інформація, що поставляється система, що служить робочої

Ролі систем для розробки, забезпечення якості та експлуатації строго розділені. Перш ніж використовувати ПЗ в робочій системі, його потрібно ретельно протестувати в інший, окремій системі. Шляхи перенесення з однієї системи в іншу фіксовані і не можуть змінюватися, якщо не вжити для цього спеціальних тагов.

Визначальним фактором у прийнятті рішення щодо вибору інфраструктури системи є співвідношення витрат і вигод (з урахуванням пропонованих до системи вимог). Незважаючи на ті переваги, які дає трехсістемная інфраструктура, її складність призводить до збільшення робіт з адміністрування. Потрібно ретельно зважити ці вимоги і оцінити витрати.

Многосістемность інфраструктури

Існують конфігурації, в яких має сенс не обмежуватися трехсістемной інфраструктурою. Наприклад, іноді краще мати кілька географічно розділених робочих систем, обслуговуючих різні філіали компанії. Технічні відмінності між системами (системою інтеграції, консолідації та системою поставки) зберігаються і в таких інфраструктурах - їх технічні функції залишаються колишніми. Такі інфраструктури охоплюють кілька паралельно функціонуючих систем одного типу. Між тим, роль даних систем не завжди можна визначити точно. В певному сенсі вона двоїста. На мал. 2 показаний приклад многосістемной інфраструктури. Точкою входу є центральна система інтеграції, яка використовується для розробки "міжнародного" ПО. Підключення до неї незалежні системні інфраструктури застосовуються для розробки ПО для конкретної країни.

5. Адміністрування клієнта

Основні поняття про клієнтів

Клієнт - це незалежно що враховується бізнес-одиниця компанії. Дане поняття включає в себе незалежний бухгалтерський баланс. Установка окремих параметрів відповідно до вимог бізнесу називається користувальницької налаштуванням (Customizing). Її можна використовувати також для завдання параметрів, діючих в масштабі всієї системи, таких як вибір виробничого календаря.

Стандартні клієнти

У стандартній системі SAP пропонує наступних клієнтів із заздалегідь заданою конфігурацією:

· 000 для цілей адміністрування і як шаблон для створення додаткових клієнтів

· 001 для цілей тестування на відповідність ECU (European Currency Unit) і як шаблон для створення додаткових клієнтів

· 066 для SAP Remote Services (Дистанційні сервіси)

Роль клієнта

Призначення кожного клієнта Б системі R / 3 визначається тими завданнями, для яких він іспользуетсяю При створенні клієнта це відбивається в присваиваемой йому ролі. Дана роль відображає функції клієнта і присвоєні йому атрибути:

· Робочий клієнт

· Клієнт для тестування

· Клієнт для користувача настройки

· Клієнт для демонстрації

· Клієнт для навчання та підготовки

· Еталонний клієнт SAP

6. Логіка програмного забезпечення

Запити користувача настройки

При впровадженні системи R/3 необхідні для користувача настройки (Customizing). Подібна настройка зазвичай стосується бізнес-процесів і, таким чином, залежить від клієнта (якщо клієнт представляє підрозділ компанії). Коли клієнт налаштований для автоматичного запису змін, задача і запит користувача настройки при змінах налаштувань користувача у системі R/3 створюються автоматично. Якщо маються запити користувача настройки, то можна явним чином управляти призначенням задач для таких запитів.

Переносні запити на зміни

Крім зміни в користувальницької налаштуванні може виявитися необхідним створити власні об'єкти або модифікувати об'єкти, що поставляються SAP (SAP-owned objects). Це дозволить вам налаштувати систему R / 3 у відповідності зі своїми вимогами. Подібні зміни не залежать від клієнтів, тобто діють в масштабі всієї системи. Дані при таких змінах записуються негайно в задачі, призначеної запиту на перенос.

Локальний запит на зміну

Крім використання переносите запитів па зміни (глобальних), можна вносити локальні зміни. При такому типі змін створюються локальні запити на зміни. Подібні запити не можуть переноситися в інші системи.

При призначенні завдання в запиті на зміну, що стосується розробки ПЗ, необхідно дотримуватися запобіжних заходів. Даний об'єкт блокується користувачами, які не є власниками завдання і запиту на зміну, поки що відповідає за модифікацію розробник явно не передасть повноваження на цю задачу іншому користувачеві. Якщо проект розробки завершений, деблокується спочатку задача, а потім запит на зміну. Об'єкт може бути змінений знову тільки після деблокування запиту. Такий механізм запобігає одночасна зміна одного і того ж об'єкта.

Номер запиту

Усі завдання і запити від користувачів мають унікальний ідентифікатор, що складається з трехеімвольного імені системи R / 3, ідентифікатора К9 і послідовного номера з 5 цифр, наприклад QO1K900005. Кожен запит на зміну має одного власника - керівника проекту, який відповідає за адміністрування запиту. При необхідності власника можна змінити. Запит на зміну нерідко складається з декількох задач, призначених одному користувачеві. Запит на зміну можна розглядати як проект, в якому різні користувачі мають різні завдання. Допускається передача завдання іншому користувачеві. Проект буде закінчений тільки після завершення або деблокування всіх задач в запиті на зміну (тобто після деблокування запиту на зміну). Якщо запит на зміну є стерпним або являє собою запит користувача настройки, то після переносу він деблокується автоматично. Запит на зміну стає запитом на перенос. Шлях запиту на перенос визначається при створенні системної інфраструктури.

Створення запиту користувацького налаштування

Створити запит користувацького налаштування можна двома способами:

· Внести зміну і дозволити системі R / 3 згенерувати запит користувацького налаштування і задачу для зміни.

· Використовувати СО для створення запиту користувацького налаштування з даною задачею. Потім внести зміну і явним чином призначити задачу.

Вибір процедури залежить головним чином від прийнятої концепції користувача. Призначаючи повноваження, можна запобігти створенню користувачами власних запитів на зміну. Це завдання можна зарезервувати для вибраної групи користувачів. Перевага подібної процедури полягає в наступному: ви зберігаєте контроль нал запитами користувацького налаштування і призначенням, а також можете для створення нового типу запиту на зміну перевизначати права розробника, наприклад дозволити йому вносити зміни тільки після створення та призначення відповідних запитів на зміну уповноваженій особі, такому як керівник проекту. Це дає можливість більш ефективно координувати розробку в системі R/3.

Фонова обробка

Планувальник фонових завдань

Для запуску завдання в конкретний час потрібно запланувати його виконання. В примірниках R / 3 функціонує планувальник фонових завдань. Через певні інтервали часу він перевіряє наявність фонового завдання для обробки. Планувальник фонових завдань - це програма, интерпретируемая і оброблювана заданим діалоговим процесом. Він автоматично вибирає діалоговий процес при запуску системи R / 3. За замовчуванням інтервал активізації планувальника фонових завдань становить 60 секунд. Адміністратор може його налаштувати. Для цього в профілі примірника встановлюється параметр rdisp / btctime.

Таким чином, завдання може запускатися з точністю до інтервалу активізації планувальника фонових завдань. Якщо затримка занадто тривала, інтервал можна зменшити. З іншогобоку, якщо затримка запуску завдань не настільки важлива, краще збільшити цей інтервал часу, хоча зменшення частоти запуску планувальника фонових завдань мало впливає на продуктивність системи.

Планувальник подій

Планувальник подій функціонує в системі R/3 на рівні додатків. Примірник для нього можна вибрати за допомогою параметра rdisp / btcname = <ім'я комп'ютера> в заданому за замовчуванням профілі системи R/3 (DEFAULT.PFL). На відміну від планувальника фонових завдань, планувальник подій реагує на події і запускає завдання з конкретної події в системі R / 3.

Системні події

У стандартній системі R / 3 визначено набір подій. Для виведення списку цих подій виберіть команду Tools > CCMS V Jobs 3 > Define Events> System Event Names > Display. Події, визначені для стандартної системи, називаються системними. Вони часто використовуються для внутрішнього управління R / 3, але можуть застосовуватися і користувачами R / 3 для своїх цілей.

Користувальницькі події

За допомогою того ж меню можна визначити нові події. Подібні події називаються призначеними для користувача. Для визначення події потрібно створеного запису ь в таблиці.

7. Визначення завдань

Для визначення завдань в R / 3 передбачена транзакція. Вона доступна в системі управління CCMS (Computing Center Management System), яка викликається командою Tools > CCMS. Щоб визначити завдання, виберіть команду jobs > Definition або використовуйте код транзакції SM36.

Нерідко планування фонових завдань вже вбудовано в додатки, наприклад цей метод застосовується при копіюванні клієнта або при оновленні головної записи користувача.

Визначення фонового завдання охоплює три основні області:

· Загальну інформацію, таку як ім'я завдання, її клас і цільової комп'ютер

· Інформацію про час запуску або ініціюванні подію.

· кроки обробки

Класи завдань

Пріоритет виконання завдання визначається привласненим йому класом. Існують наступні класи завдань:

А: найвищий пріоритет - завдання, що забезпечують функціонування R / 3 і критичні за часом.

В: середній пріоритет - періодичні завдання, що забезпечують ункціонування R/3.

С: звичайний пріоритет - звичайні завдання для користувачів R / 3.

Клас завдання використовується для присвоєння йому системних ресурсів. Якщо доводиться часто обробляти велику кількість завдань класу С, які очікують обробки, та завдання класу А також чекатимуть деблокування фонових процесів.

8. Ахітектура даних

Что такое архивирование

Термін "архівування" в середовищі R / 3 може описувати одну з трьох областей. По-перше, з точки зору БД це область адміністрування БД, де архівування даних означає резервне копіювання журналу архівування.

По-друге, з точки зору програми, архівування - це використання інтерфейсу SAP ArchiveLink для архівування вхідних і вихідних документів. Додатки вже готові для взаємодії з системою архівування. Їх конфігурація повинна налаштовуватися таким чином, щоб рахунки, рахунки-фактури, квитанції та інші специфічні для додатків документи зберігалися в архіві.

По-третє, з точки зору адміністратора R / 3, архівування полягає переважно у видаленні застарілих даних з БД і збереженні їх в архіві. У даній главі основна увага приділяється саме цьому аспекту.

Archive Development Kit

ADK (Archive Development Kit) являє собою інтерфейс між програмами архівування конкретного додатка (наприклад, програмою архівування даних) і архівними файлами. ADK. передбачає функціональні модулі, що дозволяють програмам архівування записувати підготовлені архівні дані в каталоги поза БД.

Визначте підлягають архівуванню дані. Це рішення повинні приймати працюють з даними підрозділу, так як адміністратор системи R / 3 не може судити про релевантністю бізнес-даних. Адміністратор відповідає за технічну реалізацію процесу архівування. В системі R / 3 визначено об'єкти архівування. Об'єкт архівування - це логічна одиниця пов'язаних фізичних даних, наприклад, документи бухгалтерського обліку, основні дані банку, заявки, дані по відрядженнях або бухгалтерські відомості. В них входять і програми, необхідні для архівування даних, такі як програми редагування, читання, запису та видалення.

Після вилучення даних і збереження в файлах їх можна видалити з БД. Перед видаленням даних система автоматично перевіряє, чи можна прочитати ті, які були сформовані на етапі 1. Для цього генерується спеціальна програма. Дані видаляються тільки в тому випадку, якщо вони знаходяться в файлах, згенерованих на етапі 1. Залежно від конфігурації подібні перевірки можна виконувати автоматично після вилучення даних або вручну.

На цьому етапі згенеровані на етапі 2 файли передаються в архів.

Скільки даних архівувати

Після вибору об'єкта архівування даних потрібно визначити об'єм даних, що підлягають архівуванню. Щоб визначити, чи дасть архівування якої-небудь виграш, потрібно отримати інформацію про поточний фізичному і логічному розмірі таблиць в об'єкті архівування БД. Фізичний розмір - це фактичне простір, займане БД. Логічний розмір - це число записів у таблиці. Існує два методи аналізу розміру. Обидва вони в сильному ступені залежать від БД.

Перший метод дозволяє визначити поточний розмір таблиці, вибрати таблицю і дати команду Online Space Info. Залежно від використовуваної РСУБД і розміру таблиці це може зайняти кілька хвилин.

Другий метод аналізу розміру передбачає застосування засобу Statistics Space Info, однак воно підходить лише в тому випадку, якщо вам достатньо статистики, яка збирається оптимізатором SQL. Розміри визначаються на основі статистики не точно, а за вибіркою але час останнього оновлення статистики оптимізатора.

9. Моніторинг системи

Моніторинг системи R / 3 - одна з найбільш важливих повсякденних завдань системного адміністратора. Вона не менш важлива, ніж настройка системи, і відіграє важливе значення у безпомилкової роботи системи. За своїм характером системний моніторинг повинен бути превентивним.

Basic Monitor

Цей базовий монітор дозволяє вибирати різні монітори в ієрархічному дереві. Монітори охоплюють наступні області (на окремих серверах):

· операційну систему

· БД

· Сервіс R / 3

· Основні області R / 3

· Системний журнал

Області, що не мають відношення до сервера додатків, такі як БД, сюди не включаються. Basic Monitor і всі специфічні для замовника похідні монітори Alert Monitors складають набір додаткових моніторів - так звану колекцію моніторів.

Атрибути монітора

Листя дерева моніторингу утворюють атрибути моніторингу. Атрибути моніторингу описують тип інформації окремих контрольованих елементів системи R / 3. Кожен з них відноситься до однієї з характеристик об'єкта моніторингу. Це такі типи атрибутів моніторингу:

Лічильники. Представляють такі значення як одиниця виміру або частота подій. Якщо перевищені задані порогові значення, то колір лічильника змінюється. Цей атрибут моніторингу, застосовується, наприклад для повідомлень про продуктивність.

Індивідуальні повідомлення. При появі конкретного повідомлення спрацьовує попередження.

Контроль повідомлень. Використовуються, наприклад для моніторингу повідомлень, які розміщені в файл журналу. Попередження спрацьовує при виявленні вказаного рядка символів.

Контроль активності. Ці атрибути моніторингу застосовуються для перевірки активності, наприклад таких компонентів як сервіси R / 3. При відмові контрольованого компонента спрацьовує попередження.

Текстові атрибути. На відміну від описаних вище атрибутів моніторингу використовуються просто для збору описи елементів дерева моніторингу. Вони не викликають спрацьовування попереджень.

Користувальницька настройка

Alert Monitor дозволяє візуально спостерігати за виникненням критичних ситуацій. Залежно від встановлених параметрів змінюється колір. SAP визначає для Basic Monitor задані за замовчуванням значення, однак, щоб монітор Aiert Monitor давав осмислену інформацію по конкретній системі R / 3, їх необхідно модифікувати. Це називається користувальницької налаштуванням (Customizing).

Клас дерева моніторингу

Крім віртуальних МТЕ, які використовуються просто для формування логічної структури, кожен МТЕ описується в класі дерева моніторингу (Monitor "Tree Class). Наприклад, щоб вивести на екран або змінити Monitor Tree Class для МТЕ, виберіть МТЕ R3Servises, потім Customizing.

Монітор Tree Class включає в себе:

Описовий текст. Складається з повідомлення, номера повідомлення і тексту, який виводиться в критичній ситуації.

Значення атрибутів моніторингу. Вага, максимальне число зберігаються попереджень та тип таких попереджень (see, останнє, найстаріше або найновіше).

Засіб збору. Це засіб, що дозволяє визначити значення і поставити їх в атрибути моніторингу. У старшому класі Monitor T гея Class задається частота отримання нових значень. У прикладі для R / 3 Services дане значення дорівнює 0. Це означає, що зібрані дані є поточними.

Кожен МТЕ має унікальне ім'я - унікальний ідентифікатор (UID, Unique Identifier). МТЕ можна присвоювати до трьох типів засобів збору даних та обробки попереджень. Застосовуються такі засоби:

Засіб збору. Використовується для збору даних з метою подальшого аналізу, наприклад для вимірювання продуктивності. Всім МТЕ вже призначено засіб збору (Collecting Tool), задане за замовчуванням в Basic Monitor.

Засіб аналізу. Аналізує вхідні дані, наприклад фільтрує повідомлення. В Basic Monitor призначаються лише деякі засоби аналізу, що входять до складу стандартної системи R / 3 Release 4.0A.

Засоби OnAIeit. Якщо в результаті аналізу виявляється проблема, ці кошти реагують на неї, наприклад посилаючи повідомлення. Дані кошти може налаштовувати адміністратор або користувач з відповідними повноваженнями. SAP привласнює для них значень в Basic Monitor.

Висновки

В ході проходження преддипломної практики на підприємстві АТ “Мотор Січ” у відділі УВТІС, я поглибив та закріпив знання та набув професійні навички, отримані в процесі навчання на основі вивчення практичних ситуацій.

Ознайомишись зі структурою організації, основними функціями керівничих та виробницьких підрозділів, прийняв участь в діяльності підприємства, вибрав та систематизував матеріали.

В результаті проходження практики були виконані всі поставлені завдання.

Спиок джерел

1. Официальный сайт ОАО "Мотор Сич" [Электронный ресурс]: - Электрон. дан. - Режим доступа: http://www.motorsich.com/

2. Системное администрирование SAP R/3. Официальное руководство SAP Лиане Вилл.

Размещено на Allbest.ru

...