Часть 1  Часть 2

Содержание

12. Выравнивание расширений

13. Switch Framework

14. Что осталось за бортом

15. Заключение

12. Выравнивание расширений

Клиент может делать имплементации расширений для получения нужной ему дополнительной функциональности. Программное обеспечение, предоставляемое поставщиком время от времени меняется для наращивания функциональности, повышения производительности, исправления ошибок. Среди прочего вполне возможно, что новая версия делает как раз то, ради чего клиент и делал имплементацию. Вообще, если клиент сделал имплементацию расширения какого-либо объекта репозитария, и пришла новая версия такого объекта, может потребоваться корректировка расширения. Вот некоторые из причин, из-за которых может понадобиться сделать корректировку расширений:

-  объект репозитария (программа, класс, функциональная группа) удален;

- из объекта репозитария была удалена часть, содержащая опции расширения (подпрограмма, метод, функциональный модуль);

- удалено определение явной точки расширения или секции расширения;

- изменен ABAP-код внутри секции расширения;

- изменен ABAP-код, находящийся перед явной точкой или секцией расширения;

- функциональный модуль с опциями расширения перенесен в другую функциональную группу;

- блок обработки (подпрограмма, метод, функциональный модуль) с опциями расширения перемещен в другой инклюд;

- возник конфликт между имплементациями секции расширения (например, пришли от разных партнеров; вспомним, что секция расширения предполагает именно замену одного ABAP кода другим и потому множественная имплементация недопустима);

- опция расширения «переехала» из главной программы в инклюд или наоборот из инклюда в главную программу;

- в метод или функциональный модуль был добавлен параметр, чье имя совпало с именем, данным дополнительному параметру при имплементации (вспоминаем первую мантру: нужно вести свои разработки в собственном диапазоне имен);

- в класс был добавлен метод или событие, имена которых совпали с именами, данными при имплементации (еще раз повторим первую мантру!);

- изменилась возможность удаленного вызова функционального модуля;

Транзакция SPAU_ENH позволяет определить те имплементации расширений, которые требуется скорректировать.

13. Switch Framework

Нужна возможность одновременно включать и выключать сразу много имплементаций, нужен «общий рубильник». Вот как это сделано для расширений, объединяемых в рамках технологий Enhancement Framework.

Как и разработки, имплементации ведутся в пакетах (packages). Пакеты, объединятся в свичи (switches) с помощью транзакции SFW1. Имплементации, включенные таким образом в свич будут работать только если свич включен. Сам по себе отдельно взятый свич включить нельзя. Свичи объединяются в бизнес-функции (Business Functions). Включить и, быть может, выключить можно целиком всю бизнес-функцию со всеми ее свичами и входящими в них имплементациями. Транзакции SFW2 позволяет создавать бизнес-функции и включать в нее свичи. При создании бизнес-функции можно указать для нее свойство «отключаемая», как видно из названия, такую бизнес-функцию можно не только включить, но еще и выключить. Включать, а отключаемые бизнес-функции еще и выключать, со всеми входящими в них свичами и входящими в свичи имплементациями можно в транзакции SFW5.

Разные бизнес функции могут содержать имплементации одних и тех расширений, которые не допускают множественных имплементаций, например секций расширения или BAdI не множественного использования. Такое может случиться, если бизнес функции получены от разных партнеров. Получается, что часть имплементаций, входящих в эти бизнес-функции, не может быть одновременно активирована, а остальные могут и должны быть активированы одновременно. Нужно средство для разрешения таких конфликтов. Для разрешения таких конфликтов в транзакции SFW1 можно создать «конфликтные свичи» (conflict switches), то есть переключатели конфликтов. В случае, если возникнет конфликт, будет исполняться имплементация такого конфликтного свича.

14. Что осталось за бортом

Switches в экранной обработке. Свичи можно использовать при описании экранного элемента и элемента GUI-статуса. При этом можно указать, будет появляться этот элемент при включении или выключении свича. В заголовке модуля экранной обработки также можно указать свич. Такой модуль экранной обработки будет исполнен только, если указанный свич включен. Эти возможности в семинаре BC425 не упоминаются.

Field Exits. Для полей ввода/вывода экранов можно создать Field Exits. Каждому Field Exit соответствует функциональный модуль с именем «field_exit_<имя_field_exit>». При создании Field Exit указывается