Я підготував статтю, яка покликана допомогти вам зрозуміти, де і як працюють розробники ABAP у проєктах з міграції SAP ERP на S4HANA. Я вибрав цю тему, щоб зібрати в одному місці доступну інформацію, якої, чесно кажучи, в інтернеті занадто багато, але знайти її складно.
Читаючи багато великих, довгих, детальних статей з великою кількістю додаткових думок, важко визначити, що саме нам, розробникам систем SAP, було б найцікавіше.
Отже, у цій статті ви знайдете відповіді на наступні запитання:
- Де ми знаходимося?
- Які інструменти використовувати?
- Це складно чи ні?
- На якому етапі ми перебуваємо?
- Коли ми потрібні?
- З ким і коли ми співпрацюємо?
Сподіваюся, цей консолідований матеріал допоможе кожному з нас.
Підготовчий етап ABAP’er
На екрані нижче представлені основні етапи міграції на HANA. У цьому документі ми зосередимося на підготовчому етапі.
Робочий список для міграції користувацького коду. Робота ABAP’а під час міграції
Все почалося з наступної ПРИМІТКИ. Мої коментарі виділені курсивом.
ПРИМІТКА SAP 2190420 – SAP S/4HANA: Рекомендації щодо адаптації конкретного користувацького коду
«Перш ніж розглядати аспекти користувацького коду SAP S/4HANA, важливо зрозуміти, що переважна більшість рекомендацій щодо користувацького коду, рекомендованих дій, заходів та інструментів, які ви, можливо, вже знаєте з SAP ERP, також актуальні для SAP S/4HANA. Аналогічно, більшість існуючих користувацьких кодів SAP ERP сумісні з SAP S/4HANA.
Тож що стосується користувацького коду в SAP S/4HANA, то дійсно є деякі відмінності на додачу до всього існуючого, про які ви повинні дізнатися і до яких потрібно адаптуватися. Але ці відмінності незначні».
Інструменти та процеси, які застосовуються для розробки користувацького коду в SAP ERP або будь-якому іншому продукті на основі ABAP, також застосовуються до SAP S/4HANA. Зокрема, необхідно:
- перевіряти та видаляти застарілий користувацький код, непотрібні модифікації та зайві клони об’єктів SAP, щоб підтримувати свою кодову базу в чистоті (супровід).
- TCODE: SCMON (Моніторинг використання користувацького коду) – як часто відбувається виклик користувацького коду.
- TCODE: CCLM (Управління життєвим циклом користувацького коду) – створення бібліотеки користувацьких кодів, яка має функціонал виведення з експлуатації того коду, який не використовується більше 12 місяців.
- виконувати усі перевірки коду, передбачені SAP (наприклад, функціональна коректність, продуктивність, безпека тощо) для вашого користувацького коду.
- Програма/SDF/RC_START_CHECK (Список елементів спрощення) – функціональний і технічний вплив конвертації системи на вашу систему. Роботу дуже важко розділити. Всі перевірки, невідповідності даних, відсутність обов’язкових підготовчих заходів, які можуть призвести до невдалої конвертації системи, перераховані тут, є завданням розробника ABAP і функціонального консультанта. Міграцію можна починати тільки тоді, коли всі перераховані записи будуть зеленими = «проблем не виявлено».
- TCODE: SYCM (Програма SYCM_DOWNLOAD_REPOSITORY_INFO – Аналізатор користувацького коду
ПРИМІТКА 2185390 – Аналізатор користувацького коду – перелік кодових об’єктів клієнтів, які не відповідають SAP S/4HANA
Посилання на БЛОГ - TCODE: ATC (тестова кабіна для ABAP)
ПРИМІТКА: 2436688 – Рекомендовані примітки SAP щодо використання перевірок користувацьких кодів S/4HANA в додатку ATC або міграції користувацьких кодів
ПОРАДА: Зосередьтеся на особливих S4HANA, таких як:
«”S4HANA_READINESS_1809» або «S4HANA_READINESS_1909» тощо. - TCODE: SCI (Code Inspector)
ПРИМІТКА: 1935918 – Перевірка варіантів інспектора кодів Downport для міграції HANA
- виконувати профілювання та оптимізацію продуктивності (як загальну, так і специфічну для SAP HANA) вашого користувацького коду – покращення продуктивності бізнес-процесів)
- TCODE: SQLMD (Моніторинг SQL) – Вказати на найбільше навантаження в системі
- TCODE: SWLT (Робочий список для налаштування продуктивності SQL) – знайти код ABAP SQL, який потенційно може підвищити продуктивність
- визначати відповідні тестові концепції та тестувати користувацький код, зокрема використовуючи можливості автоматизації тестування.
Зазвичай, процес перевіряють спеціальні функціональні консультанти (FI, SD, MM, WM) (з огляду на відсутність бюджету на окрему команду тестувальників); я ніколи не чув про автоматизацію тестування в SAP (а я провів 3 оновлення системи SAP ERP та 1 оновлення системи PI зі стеку ABAP на стек JAVA (7.31 à 7.4). Навіть дуже великі корпорації з відносно необмеженим бюджетом ніколи не створюють окрему команду тестувальників для будь-якого оновлення або міграції SAP. Тестування завжди виконує функціональний консультант спільно з розробником ABAP. Отже, насправді, розробникам ABAP доручено досить великий обсяг роботи. Їм потрібні міжмодульні знання та «м’які» комунікаційні навички.
- дотримуватись рекомендованого порядку написання користувацького коду (ABAP, SQL загалом та SAP HANA зокрема).
Це дуже велика тема для обговорення, і вона залежить від знань розробника, залученої команди, системного менеджера та команди, яка відповідає за якість коду. У більш ніж 20 проєктах, в яких я брав участь, лише в 1 компанії була команда, яка стежить за якістю коду. Зі свого досвіду скажу, що код всередині компаній у світі SAP у багатьох ситуаціях пишеться багатьма розробниками, які змінюються протягом життєвого циклу системи. Код, який додається, дуже часто відповідає вимогам, але не відповідає рекомендованому порядку дій. Тим не менш, кожен розробник повинен писати код якомога чистіше.
- виконувати коригування SPDD, SPAU, SPAU_ENH під час подій життєвого циклу:
SPDD та SPAU також є частиною міграції. Іншими словами, розробник ABAP повинен працювати з обома цими важливими етапами, і розробники ABAP тісно співпрацюють з командою SAP Basis.
SAP Basis потрібно створити SUM (Менеджер для оновлення ПЗ). Одним словом, SUM – це конвертація БД. На цьому конкретному ЗНАЧНОМУ етапі (тут можна було б провести окрему сертифікацію, і такі консультанти Basis потрібні на ринку) відбувається технічний простій, під час якого модель БД SAP ERP перетворюється на модель БД SAP S4HANA.
Один з етапів цього перетворення називається SPDD. SUM зупиняється, консультант SAP Basis телефонує розробнику ABAP і чекає, поки розробник ABAP виконає необхідну роботу. SPDD – це перевірка користувацької структури DDIC. Кожне вдосконалення стандартного елемента даних SAP з DDIC слід коригувати.
Після завершення роботи ABAP розробник повинен зателефонувати до SAP Basis і повідомити, що роботу завершено. Після цього консультанти Basis натискають в процесі «SUM» кнопку, яка позначає, що SPDD завершено, і через пару хвилин (перевірка нашої роботи) SUM знову зупиняється (якщо в роботі розробника ABAP SPDD будуть допущені помилки, SUM може бути скасовано, і весь процес доведеться повторювати заново).
Тепер нам потрібно зробити SPAU. SPAU – це все неявне коригування вдосконалення, зміна стандартного коду після ключа об’єкта, що включає в себе елементи, яких немає в стандарті. Розробнику ABAP потрібно переписати весь цей код під нову систему. SPAU може зайняти навіть пару днів роботи розробника. Перший SPAU дає первинну інформацію про те, скільки часу знадобиться розробнику ABAP для виконання робіт, коли йдеться про створення технічної SUM, яка має істотний вплив на планування часу простою у випадку міграції на S4Hana.
Архітектура S4HANA. Де присутній ABAP’er
Дуже проста та інтуїтивно зрозуміла презентація шарів SAP S4HANA.
Зверніть увагу, що інструктори з SAP називають CDS (Основні сервіси обробки даних) «екстрактором даних». Це дозволяє чітко зрозуміти, що таке CDS з точки зору архітектури. Після неймовірного скорочення БД в S4HANA до пари таблиць (MATDOC, ACDOCA, BUT00), екстрагування даних, наприклад, за допомогою CDS, відіграє роль правила інтеграції в архітектурі між рівнем бази даних та рівнем додатків.
І другий дуже важливий архітектурний момент – це ШЛЮЗ SAP (TCODE: SEGW), який інструктори з SAP називають «екстрактором у зовнішній світ». Це пояснення також дозволяє нам чітко зрозуміти місце цього елемента в архітектурі. SEGW – це наступний рівень інтеграції. Шлюз SAP може відправляти у зовнішній світ OData (файл типу IDOC), використовуючи протокол HTTP (SET, GET). OData та HTTP разом узяті є найпопулярнішими технологіями на сьогоднішній день.
Сучасний розробник ABAP працює між CDS і Екстрактором SEGW, знаючи, як створити CDS і як підготувати дані для сервісу SEGW.
How S4Hana evolved
Below pictures are great presentation on how S4Hana Looks like, and where it is going to.
Підсумок
Сподіваюся, що наведений вище короткий опис допоможе вам знайти відповіді на основні запитання, які виникають під час міграції S4HANA. Це полегшить вам подальше вивчення більш детальних аспектів зазначеного процесу. Хоча у цій статті не подано опис того, як здійснювати міграцію, у ній ви зможе знайти відповіді на багато запитань про роль розробників ABAP.
