Що потрібно знати з області базису. Ландшафт. Транспортна система. Ролі.
Розглянемо основні поняття з області базису.
Система (центральна інстанція) - являє собою сервер додатків разом з СУБД.
Мандант (клієнт). - це організаційно незалежна частина в системі R / 3. Кожен мандант має власну середу даних, тобто власні основні і змінні дані, присвоєні основні записи користувачів, плани рахунків і специфічні параметри настройкі.В системі може бути кілька мандант. Майже у всіх таблицях БД з одними даними і налаштуваннями є поле, що є частиною ключа, яке містить номер мандант. Коли програма запитує будь-які дані з такої таблиці, до запиту автоматом дописується щось на зразок and mndt = НомерМандантаКудаВиВошлі
На практиці це означає, що в кожному мандант може працювати окреме підприємство не заважаючи працюючим в інших мандант. Але програми на ABAP / 4, формуляри (звітні форми) при цьому є загальними для всіх мандант однієї системи.
Репозитарій - сховище всіх ABAP-програм і опису структури даних і таблиць, з якими працюють програми. Репозитарій є загальним для всіх мандант системи.
Запит на перенесення (транспорт) - містить програми або настройки, які можна переносити між мандант або системами. Деблокувати запит являє собою кілька файлів, що містять необхідну інформацію.
Деблокувати - цей термін в SAP означає «затвердження», відправку в роботу. Поки запит, документ не деблоковані вони вважаються чернетками, їх можна змінювати і ніяких дій вони не викликають.
Ландшафт - це кілька систем, між якими можна переносити налаштування та програми. Кілька систем потрібні для забезпечення процесу розробки та налаштування. SAP рекомендує наступний ландшафт: [ADM325, BC325]
1 - система розробки. Містить 3 мандант (Ви можете телефонувати інші).
- 300 - в ньому можна змінювати налаштування і програми. При цьому будь-яка зміна відразу потрапляє в запит на перенесення.
- 400 - міняти в ньому нічого не можна. Використовується для попереднього грубого тестування програм (вряди "виникають" там одночасно з 300) і налаштувань (можна перенести запит без деблокування за допомогою транзакції scc1)
- 200 - пісочниця (Sandbox). Призначений для експериментування з настройками. Поміняли настроечку - відразу там же подивилися, як змінилася робота користувальницької транзакції. Запити на перенесення з пісочниці не формуються і відповідно експерименти ніяк не можуть зашкодити іншим мандант в цій та інших системах.
2 - контроль якості
У цій системі зазвичай два мандант:
- 500 - використовується для навчання користувачів
- 600 - призначений для перевірки коректності розробки або налаштування.
Налаштування або розробка може потрапляти в цю систему після деблокування. Ви повинні ретельно перевірити, що все працює, як задумано, перш ніж переносити запит в продуктив.
3 - продуктивна система
Зазвичай один мандант, в якому працюють користувачі. Згідно з вимогами SAP, група впровадження взагалі не повинна мати доступу до цієї системи. Якщо у вас є доступ до продуктивний, слід дотримуватися крайню обережність т. К. Помилкові дії ведуть до дуже тяжких наслідків. Також іноді на продуктивний системі роблять копію продуктивного мандант (на різних проектах за цим можуть стояти різні цілі).
Запит переносять в продуктив базіснікі на підставі заявки, підписаної керівниками модуля і проекту (зрозуміло, все може бути реалізовано по безпаперової технології, наприклад з використанням Solution Manager - суть це не міняє)
«Навіщо потрібно поділ в системі розробки на настроювальний (300) і тестовий (400) мандант? Чому не можна все відразу пробувати у 300? »
Це викликано технічними обмеженнями. При введенні в 300 деяких даних може скластися ситуація при якій настройку можна буде змінити або видалити т. К. Вона пов'язана з цими даними.
- Роль (окрема) - описує, які саме дії може здійснювати користувач в системі.
- Роль (групова) - складається з окремих ролей. Використовується для полегшення роботи з ролями.
Ролі є мандантозавісімимі, створюються і переносяться так само, як настройки.
Роль може містити в собі: [ADM940]
1) додаток до меню користувача, тобто транзакції з назвами, які буде бачити користувач;
2) об'єкти повноважень - описують, що саме може робити користувач. Наприклад, які транзакції він має право запускати, які саме операції над даними може виконувати для даного підрозділу і т. П.
Слід мати на увазі, що якщо користувачеві присвоєні кілька ролей, в яких є один і той же об'єкт повноважень з різними параметрами, користувач отримає максимальні права з двох можливих (відповідає логічній операції "або"). Тому слід бути уважними при налаштуванні об'єктів повноважень в нових ролях - "несуттєвий" параметр, якому ви надасте значення "*" (дозволено все) може "відгукнутися" для іншої транзакції і ролі.
На програмному рівні об'єкт повноважень є спеціальним елементом мови ABAP / 4 і перевіряється при виконанні програми. Залежно від результатів перевірки програма може здійснювати різні дії, наприклад, видавати повідомлення "Недостатньо повноважень"
Профіль повноважень - це скомпільована (наведена в машинний вигляд) роль. Власне система працює саме з профілями, ролі користувачу можна і не привласнювати (якщо немає потреби в меню). На практиці консультант зазвичай оперує ролями.
Версії компонентів. Оновлення.
Поточна ієрархія версій найбільш популярного продукту SAP виглядає наступним чином:
(ECC - Enterprise Central Core)
(WEB AS - WEB Application server)
Більш повна інформація по платформі NetWeaver
Якщо клацнути на пункті меню Система -> Статус -> «Лупа», можна побачити версії системи.
- SAP_APPL = 470 (для системи SAP версії 4.7)
- SAP_APPL = 46С (для системи SAP версії 4.6С)
[У кого є можливість, перевірте для інших систем]
Число в наступному стовпчику показує номер останнього встановленого пакета підтримки (містить всі виправлення помилок і доповнення, випущені до деякої датою). Коли ви дивитеся ноти, слід звертати увагу на версію системи, для якої вона призначена і рівень пакета, в який ця нота входить (може бути вже встановлена в системі). Оновлення цього компонента (оновлюється ABAP-код) зачіпає більшість стандартних модулів.
- C-CEE це «російський Add-on» ( «додаток») Випускається Московським відділенням SAP. Забезпечує набір програм і транзакцій для підтримки специфіки вітчизняного бухобліку. Починаючи з версії> ECC 5.0, для Росії не він потрібен (потрібна ставити тільки на Україні і в Казахстані), оскільки функціональність, спочатку включена в додаток, тепер входить в стандартну поставку системи.
- SAP_BASIS, SAP_ABA - ці компоненти забезпечують функціонування «базису». Їх оновлення не так сильно помітно в системі.
Що потрібно знати про програмування на ABAP / 4
Незнання мови програмування не є фатальним. Можна ставити грамотні технічні завдання розробникам і без цього. Потрібно вміти переглядати таблиці (транзакції SE11, SE16). Як називається цікавить вас поле, і в якій таблиці вона перебуває, можна визначити наступним чином:
1) Знаходимо його на екрані, ставимо туди курсор.
2) Тиснемо F1, потім кнопочку «Технічна інформація».
До речі, там же можна знайти ще багато корисної інформації.
Щось працює не так як треба або не працює взагалі. Вирішуємо проблему.
В першу чергу треба обов'язково переконатися, що має місце помилка. Найважче лагодити те, що не зламалося. Якщо 2 * 2 не дорівнює чотирьом, насамперед уточніть: може бути, ми бачимо суму з ПДВ. 99% звернень користувачів з приводу "помилки системи" лікуються читанням інструкції і вправлення мізків.
Нота (note) - "замітка" (в самій системі, наприклад, в транзакції snote ноти називаються "вказівками", ньому. Hinweis), що випускається SAP, що описує проблему і способи її вирішення. Крім текстової частини може містити виправлення (коректури) для програм на ABAP / 4. Ноти слід шукати на service.sap.com. Необхідні для входу ім'я і пароль ви можете отримати у базісніков або керівника проекту. Установкою нот займаються базіснікі.
Якщо стандартна транзакції видає повідомлення про помилку з кодом:
1) читаємо уважно повідомлення (краще увійти в систему англійською мовою), думаємо, перевіряємо настройки, перечитуємо хелп і курси.
2) шукаємо ноту за кодом помилки.
3) шукаємо ноту за кодом транзакції і ключові слова англійською мовою, що описує проблему. Наприклад "migo save error".
4) скаржимося в SAP з того ж сайту service.sap.com. Якщо питання не стосується вітчизняних доробок (російського аддона), то питання краще формулювати по-англійськи: зростають шанси отримати швидкий і компетентну відповідь.
5) якщо чекати немає можливості або хочеться самостійно розібратися в причині - запускаємо транзакцію під отладчиком. Це складно і довго. Необхідно мати повноваження на налагодження. Необхідно добре знання ABAP / 4. Налагодження запускається введенням команди / h
6) шукаємо, не обговорювалося подібний відповідь на форумах. (Там завжди є кнопка «пошук»).
7) задаємо чітко сформульоване питання на форумі.
Як налаштовувати (допрацьовувати) систему під клієнта
В першу чергу систему приводять у відповідність з вимогами бізнесу шляхом зміни налаштувань. Запустивши транзакцію SPRO, можна отримати доступ до всіляких налаштувань. Власне, ця транзакція є зручною оболонкою (меню) для величезної кількості транзакцій, що працюють з конкретними настройками.
Варіанти транзакцій - це ще один спосіб підгонки системи під вимоги клієнта. Дозволяє ховати або робити обов'язковими для введення окремі поля, вкладки і т. П.
Часто існуючих звітних форм недостатньо. В цьому випадку пишуть свою програму (транзакцію) на ABAP / 4, яка вибирає і виводить дані в необхідній формі.
При необхідності можна створювати свої таблиці з назвою на Z * і додавати в стандартні таблиці нові поля з назвою на Z *.
У багатьох ABAP-програмах передбачені спеціальні місця, куди можна вписувати додатковий код на ABAP / 4 з метою виконання транзакцією деяких додаткових дій. Це customer-exit (фактично - виклик функції з параметрами, тіло функції ми пишемо самі), user-exit (фактично include - місце для вставки довільного коду) і BADI (близьке за змістом до customer-exit, але реалізовано методами об'єктно-орієнтованого програмування ). [BC425]. Інформацію про можливість скористатися розширенням можна знайти в SPRO, клацнувши на "листочку" з описом налаштувань. Там же зазвичай вказується, в який момент буде відпрацьовувати ваш код. Слід дотримуватися обережності, тому що помилки можуть привести до порушення в роботі стандартних транзакцій аж до втрати даних.
Іноді "хотілки" користувачів такі, що реалізувати їх можна, тільки змінивши стандартний код системи. Незважаючи часом на легкість і незначність змін ( "ось тут одну стрічечки поміняти"), слід мати на увазі, що в довгостроковій перспективі це призводить до ВЕЛИКИМ проблем з ймовірністю в 99%. Мистецтво консультанта, в тому числі, складається і в умінні переформулювати вимоги користувачів таким чином, щоб їх можна було реалізувати в системі прийнятним способом.
Постановка грамотних ТЗ на розробку
ТЗ (технічне завдання) - це документ, в якому постановник (консультант) описує, що саме повинен зробити (запрограмувати) розробник (абапер). "Як саме" він повинен реалізовувати ТЗ, вказувати не потрібно, за винятком самих загальних моментів.
Також ТЗ повинно містити:
1) мета розробки.
2) контрольний приклад - дані, за допомогою яких можна грубо перевірити коректність роботи програми.
3) настройки, які потрібно зробити в системі.
4) коротку інструкцію з використання розробки.
"Чому в SAP все реалізовано так складно, я знаю як зробити простіше і краще"
У SAP акумульовано багаторічний досвід організації бізнесу в багатьох країнах, в першу чергу в Німеччині. Німецька пунктуальність, чітка організованість у всьому аж до дрібниць (і ці дрібні, "несуттєві", обов'язкові для введення, дані в транзакціях часом так дратують) є відомими рисами національного характеру і відповідно бізнесу. У Німеччині цеглу на будівництво повинен доставлятися не «20.08.07", а "20.08.07 о 12:30" і машина дійсно приїжджає в зазначений час (відповідно перед цим, завод в потрібний час отримує сировину, виробляє необхідну кількість продукції, машина не чекає своєї черги на завантаження і т. д. і т. п.) хто знає чи може посперечатися по організованості і ефективності з німецьким бізнесом - хіба що японці. (Російські однозначно мовчки курять в стороні :)
Звичайно SAP незважаючи на величезні можливості по адаптації, не може 100% ідеально (ефективно) відповідати вимогам бізнесу даного конкретного підприємства. Але можна з упевненістю стверджувати, що після грамотного реінжиринг бізнес-процесів, система задовольнить вимогам мінімум на 95%. Ви вважаєте, що цього мало і треба спробувати досягти більшого? Далеко не факт, що ви зможете переплюнути SAP. Можете спробувати при дотриманні наступних умов:
1) Ви геній.
2) В п. 1 Вам вдалося переконати олігарха - проект щедро фінансується
3) Коли зумієте відібрати в SAPа 1% світового ринку, візьміть мене будь ласка до себе на роботу :)
Де шукати більше інформації