Я люблю, щоб мій код був елегантним і ефективним. Логіка повинна бути досить прямолінійною, щоб помилок було важко сховатися; залежності - мінімальними, щоб спростити супровід; обробка помилок - повної відповідно до виробленої стратегією; а продуктивність - близькою до оптимальної, щоб не спокушати людей забруднювати код безпринципними оптимізаціями. Чистий код добре вирішує одну задачу.
Сідорочкін Михайло
Dmitriy Vedmid
Марія
Сідорочкін Михайло
Дмитро Карпов
Дуже часто в процесі розробки необхідно надати гнучкість програмного рішення, в залежності від будь-яких вимог, визначених тими чи іншими настройками. Подібна гнучкість в SAP системах традиційно вирішується шляхом визначення налаштувань в транзакції SPRO. У статті буде розглянуто спосіб визначення своїх налаштувань на базі ведення багаторівневого кластера ракурсів і створення посилання на нього в SPRO.
Транзакція SPRO відкриває заздалегідь визначену ієрархічну структуру, в якій настройки розділені щодо функціональності:
Як видно з малюнка, настройка являє собою кластер ракурсів (набір ракурсів) об'єднаних для ведення в рамках однієї настройки:
У кластері присутня 5 вкладених ракурсів: часові пояси, правила для часових поясів, правила для літнього часу і ін. Кластери не пов'язані один з одним ієрархією, вони не залежні один від одного.
Зустрічаються і такі кластери ракурсів, де один ракурс, може бути залежним від іншого ракурсу, в такому випадку, щоб перейти у відання залежного, потрібно вибрати запис з ракурсу на рівні вище, приклад:
Для того щоб перейти на зміну в «Привласнення логічний шлях - фізичний шлях» необхідно вибрати запис в ракурсі «Визначення логічних шляхів до файлу»:
Визначення кластера ракурсів
Як простий приклад створимо кластер ракурсів, що складається з трьох ракурсів, перші два будуть залежними, третій буде сам по собі.
Першим кроком йде визначення Z таблиць (тр. SE11).
Для всіх таблиць проставимо наступні параметри поставки:
Визначимо домен ZCUSD_LOGIN_TYPE:
Для домену задамо діапазон значень:
Визначимо елемент на базі домену:
Після створення таблиць і елементів даних необхідно підготувати ракурси ведення для кожної з таблиці (тр. SE11). Але перед цим створимо групу функцій, що відповідає за зберігання згенерованих до ракурсам ФМ по оновленню даних і екранів. Назвемо її ZFG_UCONF. Створити групу функцій можна в транзакції SE80.
У кластері ракурсів ракурс ZCUST_V_INF буде залежним від ракурсу ZCUST_V_LOG, таким чином, поля LOGIN і MANDT через настройку залежності будуть автоматично заповнюватися за обраною записи вище за ієрархією.
Далі для всіх ракурсів будемо генерувати ракурс ведення, Меню -> Програми -> Генератор ведення таблиць:
Так як група функцій у нас буде одна, екрани повинні мати різні назви для кожного ракурсу: 101 - для ZCUST_V_LOG, 102 - ZCUST_V_INF і т.д. Якщо наші настройки повинні автоматично потрапляти в запит на перенесення, для цього необхідно проставити галочку - «Стандартна програма записи» (після генерації екрану).
Крім того, виберемо однорівневий тип ведення і групу повноважень без перевірки на повноваження. Різниця між типами ведення лише в тому, що при дворівневому типі під час редагування ви провалюєтесь в окремий екран ведення обраної записи, коли як в однорівневій, редагування відбувається на екранної таблиці.
Після визначення всіх ракурсів необхідно об'єднати їх в кластері. Створення кластера ракурсів відбувається в транзакції SE54 -> Обробка кластера ракурсів. Назвемо наш кластер ZCUST_VC_CONF:
Обробка ієрархічної операції ведення може набувати таких значень:
Показувати діалогове вікно. Якщо ви міняєте запис в ракурсі, від якої залежать інші записи в залежному ракурсі, буде з'являтися діалогове вікно, в якому необхідно буде вибрати рішення того, що робити з залежними записами:
Без діалогу зі зміною залежних записів. В цьому випадку всі залежні записи будуть так само видалені (змінені).
Без діалогу і без зміни залежних записів (обмеження на один рівень). Зовсім записі не будуть порушені.
Вид зчитування відповідає за те, як будуть зчитуватися записи з БД. Якщо стоїть перший варіант, всі дані для всіх кластерів будуть прочитані відразу. Якщо другий варіант, дані будуть прочитані тільки для першого ракурсу і залежних від нього. Решта будуть зчитуватися в міру необхідності. Зазвичай другий варіант виставляється для оптимізації при великій кількості даних в ракурсах.
Перейдемо до структури об'єкта. У структурі кластера прописуються всі ракурси, з яких він складається:
Крім того вказується залежність ракурсів, в нашому випадку ракурс ZCUST_V_INF залежимо від попереднього ZCUST_V_LOG, а ракурс ZCUST_V_MAILS ні від кого не залежить. Залежність може мати кілька типів:
- R - Без залежностей
- S - Залежність від одного запису в головному ракурсі.
- M - Залежність від декількох записів в головному ракурсі. Цей тип можна застосувати тоді, коли щодо кількох записів в головному ракурсі, необхідно редагувати всі від них залежні в залежному ракурсі. Приклад такого ракурсу: T804.
Для настройки залежностей необхідно виділити рядок з ракурсом ZCUST_V_INF і перейти в налаштування залежності і прописати залежні поля (якщо будуть прописані зовнішні ключі в таблицях і на попередньому екрані натиснути на кнопку «залежність поля», виділивши залежний ракурс, система пропише залежність за вас):
Після настройки кластера ракурсу, його необхідно активувати, робиться це по кнопці у визначенні заголовка (перший екран ведення ракурсу). Після активації можна вийти на попередній екран і протестувати наш кластер:
У підсумку ми можемо завести облікові дані (логіни):
Щодо кожної облікового запису завести людей, які ними користуються і до якого типу вони належать:
Створення гілки в SPRO
Так як ракурсів в рамках різних завдань може бути безліч, а запам'ятати їх на пам'ять не представляється можливим, необхідно їх згрупувати у вигляді гілки в SPRO і бажано супроводити необхідною документацією.
Зазвичай створення своїх гілок відбувається через транзакцію SIMGH. але в нашому випадку ми будемо розширювати стандарт (транзакція SPRO відображає певну заздалегідь IMG структуру), тому скористаємося транзакцією S_IMG_EXTENSION:
Насамперед вибираємо стандартну IMG структуру:
Далі необхідно створити ID розширень:
Після створення ID розширення, вибираємо його і натискаємо кнопку «Розширити структуру», в результаті потрапляємо на екран ведення стандартної структури SPRO.
Створимо вузол на тому ж рівні:
Далі вставимо нову операцію, при створенні операції бажано документувати її, створивши документ опису:
На закладці об'єкти ведення необхідно прописати наш кластер:
Зберігши операцію, вийдемо і збережемо ієрархію. Після чого можна переконатися в наявності нашої гілки, запустивши SPRO:
додаткова інформація
Якщо раптом виникає бажання перевірити, яким чином налаштоване дію в IMG структурі, зробити це можна перейшовши по меню до технічної інформації:
Однорівневі ракурси ведення відображають для редагування екранну таблицю, але при великій кількості полів потрібно прокручувати таблицю, так як таблиця не розтягується на весь екран:
Виходу з цієї ситуації 2, можна відредагувати згенерований екран, але це треба буде виконувати кожен раз, при його генерації. Другий спосіб більш зручний, необхідно скористатися подіями в генераторі ведення, докладніше тут.
Після створення кластера може знадобитися створення транзакції до його відання, зробити це можна через створення транзакції з параметрами до SM34:
На малюнку створена транзакція Z01MAPT_VC буде запускати на ведення ракурс з тим же ім'ям, прописаним в значеннях за замовчуванням.
Офіційна документація по кластерам і генератору ведення доступна по посиланню.