Розширення системи (Enhancement Framework)

Розширення системи (Enhancement Framework). Частина 1

Я продовжую публікацію на порталі SAPLand циклу статей«Техніки розширень стандартної системи SAP».

Примітка:Починаючи з версії ECC 6.0 з'явився чудовий механізм розширення функціональності системи (Enhancementspot/section), однак, це і найпростіший спосіб «поламати систему об коліно», оскільки ніякого контролю за тим, що і як ви реалізуєте в точці розширення, система не здійснює.

Загальні концепції.

Enhancements spot/section – Техніка розширення, що дозволяє практично виконати впровадження коду користувача в будь-якому місці стандартної бізнес-транзакції. Enhancement-и в системі поділяються на «явні» та «не явні». Явні точки розширення аналогічно техніці Customer-exits використовують спеціально введений оператор, неявні фактично присутні на початку і кінці логічно завершених блоків коду або структур даних. Техніка Enhancements spot/section дозволяє впроваджувати код користувача в контекст виконання стандартного коду системи. Ви отримуєте доступ до всіх змінних і можете фактично повністю перевизначити логіку роботи системи, що є дуже небезпечним, оскільки може призвести до серйозних збоїв у роботі стандартних транзакцій у разі некоректної реалізації коду розширення. На даний момент це, з одного боку - дуже потужний механізм розширення функціональності, а з іншого боку - найнебезпечніший з усіх типів розширень. Загальна рекомендація від компанії SAP: якщо існує можливість використання будь-якого іншого типу розширення - використовуйте його, техніку Enhancements - використовуйте тільки в тому випадку, якщо інших можливостей впливу на код, що виконується.

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

  • Розширення класів — можливе додавання нових необов'язкових параметрів у методи, додавання методів pre і post до існуючого методу, які викликаються перед викликом самого методу, та й загальне перевизначення методу з використанням інструкції overwrite.
  • Розширення функцій — Додавання нових необов'язкових параметрів до функції. При цьому, звичайно ж, потрібно буде використовувати функціональність «розширення коду», тому що додані вами параметри потрібно комусь і якось обробляти.
  • Розширення вихідного коду як можливість вставки своєї логіки у певні позиції вихідного коду, так і заміщення частини коду своєї логікою роботи. Власне кажучи, цей механізм здається мені найчастіше застосовуваним на практиці, тому приклади у статті побудовані для демонстрації роботи саме цього розширення.
  • Розширення web-екранів — дозволяє додавати нові елементи на екрани інтерфейсу користувача. З цим розширенням я поки не стикався, але якщо комусь це цікаво і потрібно, то йдемо на www.help.sap.com, оскільки маються на увазі web-екрани, що базуються на парадигмі контролера ракурсів моделі (Model View Controller, MVC) .
  • Нові BADI — технологія BADI впроваджень була реалізована, починаючи з версії 4.6, проте з появоюТехнології розширень, принцип технічної реалізації BADI став інший, тобто на вигляд використання залишилося фактично таким же, але розробники SAP кажуть, що нові BADI стали працювати швидше. Технологія BADI стала працювати, використовуючи так звані точки розширення засновані на техніці Enhancement Spot.

Завдяки появі техніки Enhancement, у системі стала доступна техніка бізнес-розширень функціональності, тобто. коли ви заходите в транзакцію SFW5,Малюнок 1: SFW5-01.png і активуєте необхідну вам бізнес-функцію, знайте, що фактично у вашій системі відбувається активація іноді сотень точок розширень, які реалізують функціональність даної бізнес-фукції .

класу

Мал. 1: SFW5-01.png

Розширення класів

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

системи

Мал. 2: CL-01.png

Ім'я розширення, як і ім'я контейнера, створюється відповідно до стандартних користувальницьких угод, тобто. Z або Y,Малюнок 3: CL-02.png. Якщо для класу вже існує розширення, тоді вам буде видано перелік існуючих розширень, і ви зможете або вибрати зміну вже існуючого або створити нове розширення, однак якщо це розширення компанії SAP, то, звичайно ж, ви не зможете його використовувати для включення своїх змін.

Мал. 3: CL-02.png

Після підтвердження створення розширення ви отримаєте можливість доповнювати клас новими атрибутами або методами, як бачимоМалюнок 4: CL-03.png ; у таблицях відкрилися поля для введення необхідної інформації щодо розширення класу. Ви повиннірозуміти, що якщо ви додаєте новий атрибут або метод класу, то ви повинні забезпечити його реалізацію. Обмеження за іменами ніякого немає, але я рекомендую не виходити за стандартну угоду за іменами, оскільки, можливо, розробник також захоче розширити свій клас, і при черговому оновленні ви зіткнетеся з проблемами збігу імен. Тому я б називав свої додані атрибути або методи починаючи з префікса «ZZ_». Так би мовити. для надійності,Малюнок 5: CL-04.png. Як бачимо. після додавання нового методу система бачить, що в даному випадку метод знаходиться в розширенні ZI_CL_SALV_TABLE.

enhancement

Мал. 4: CL-03.png

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

розширення

Мал. 5: CL-04.png

системи

Мал. 6: CL-05.png

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

METHOD zz_display. CHECK me-r_controller IS BOUND.

Як бачимо, я звертаюся до змінної, яка є внутрішньою у класі,Малюнок 7: CL-06.png, і система не видає жодної помилки.

Мал. 7: CL-06.png

Розширення "перед" або "після" виклику стандартного методу.

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

Отже, розширюємо клас шляхом додавання коду, який виконується перед викликом стандартного методу класу. Для цього стаємо в полі методу, що цікавить нас, і по меню вибираємо: «Клас» – «Розширити», а так як у нас вже є одне розширення класу, то система попросить нас вибрати ім'я розширення, в рамках якого проводитимемо модифікацію,Малюнок 8: CL-07.png.

Мал. 8: CL-07.png

Далі встановлюємо курсор на ім'я методу DISPLAY і по меню вибираємо: "Обробити" - "Операції розширення" - "Додати попереднє. метод»,Малюнок 9: CL-08.png.

класу

Мал. 9: CL-08.png

Якщо проблем з додаванням не буде, то в колонці «PreExit» буде додано кнопку переходу до коду методу,Малюнок 10: CL-09.png

Мал. 10: CL-09.png

Оскільки реалізації ми ще не створювали, то в останній колонці «Впровадження розширень» поки що пусто, але як тільки ми перейдемо до введення коду, в колонці буде підставлено ім'я нашого впровадженого розширення. При першому вході у ведення попереднього методу система згенерує новий клас, що реалізує даний метод. Код класу буде наступним:

CLASS LCL_ZI_CL_SALV_TABLE DEFINITION. PUBLIC SECTION. CLASS-DATA OBJ TYPE REF TO LCL_ZI_CL_SALV_TABLE. DATA CORE_OBJECT TYPE REF TO CL_SALV_TABLE . INTERFACES IPR_ZI_CL_SALV_TABLE. METHODS: CONSTRUCTOR IMPORTING CORE_OBJECT TYPE REF TO CL_SALV_TABLE OPTIONAL. ENDCLASS. CLASS LCL_ZI_CL_SALV_TABLE IMPLEMENTATION. METHOD CONSTRUCTOR. ME->CORE_OBJECT = CORE_OBJECT. ENDMETHOD.

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

Особливості реалізації класів для Pre, Post або Overwrite методів.

Параметри даних методів завжди дорівнюють оригінальним параметрам заміщуваних методів, які ви перевизначаєте, дотримуючись вимог:

  • Pre-метод – Не повинен мати вихідних параметрів
  • Post-метод – Не повинен мати вхідних параметрів, при цьому вихідні параметри (EXPORT) оригінального методу стають змінними параметрами (CHANGING) у Post-методі. Параметри, що повертаються (RETURNING) стають так само змінюваними параметрами (CHANGING).
  • Overwrite – Реалізація параметрів не змінюється.

Додати або змінити набір параметрів, що передаються не можна, а те, що ви отримуєте у своєму локальному класі посилання на оригінальний об'єкт, в цьому якраз і криється заснована проблема такого методу розширення класу. Вона полягає в тому, що ви маєте доступ лише до задекларованих методів та атрибутів класу. Ніякі атрибути чи методи, зазначені як внутрішні, вам у цій реалізації розширення не доступні, тому область використання цього типу розширення значно звужується. Особливо мені не дуже зрозуміла схема перевизначення OverwriteExit. Оскільки зазвичай всередині методу викликається код, що працює з внутрішніми змінними, доступу до яких ми всередині своєї реалізації класу не маємо. Що ми там можемо робити у цій ситуації, мені важко сказати. Я схиляюся до думки, що ці розширення потрібні самим розробникам SAP; коли потрібно повністю змінити реалізаціюметоду, вони пишуть новий метод, наприклад DISPLAY_2. Далі, щоб не поламати весь код, який використовує старий виклик плюс це може бути код партнерів, вони просто реалізують заміщення методу DISPLAY, всередині якого викликають новий метод DISPLAY_2; таким чином, не ламаючи використання цього класу ніде за системою, і тим самим забезпечують безпроблемне оновлення програм.

Розширення функцій.

системи

Мал. 11: FM-01.png

Після вибору команди розширення будуть доступні поля введення власних параметрів в інтерфейс функціонального модуля. Угода за іменами параметрів рекомендую таку ж, як і розширення класів, тобто. починаємо найменування полів із префікса ZZ. Усі параметри, що додаються, матиму атрибут – «не обов'язковий», щоб не порушити виклики даного модуля у вже існуючих текстах програм.

Розширення вихідного коду.

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

Історія однієї проблеми: Років п'ять тому попросили в одній системі пошукати причину, чому для певної групи матеріалів у продуктивній системі під час прогону ППМ не створювалися планові заявки на закупівлю. До мене там з цією проблемою ходили місцеві фахівці, потім тиждень шукали фахівці з SAP AG,власне один із них і підключив мене. Те, що потрібно було терміново, стало зрозумілим буквально через годину після того, як мені дали параметри

Обмежений доступ

Для прочитанняповної версіїстатті необхідно зайти якзареєстрований користувач.