Меню

Техники расширений стандартной системы SAP. Обзор ситуации. Пользовательские расширения

Уважаемые коллеги!

Я начинаю публикацию на портале SAPLand цикл статей «Техники расширений стандартной системы SAP».

В первой статье будет представлен авторский взгляд на включение пользовательского кода в стандартную бизнес-логику работы программы и обзор техник расширения системы.

Последующие статьи будут посвящены методам корректного расширения системы, приёмам использования стандартных механизмов расширения, не приводящим к проблемам как в поддержке системы, так и при апгрейдах её.

Все статьи цикла приведены внизу публикации.

1. Обзор ситуации

1.1. Необходимость расширений

Система SAP развивается уже более 40 лет; за это время количество поддерживаемых бизнес процессов и вариантов их использования исчисляется, наверное, тысячами. Для конфигурирования поведения системы в рамках пользовательского бизнес процесса предоставляется специальное конфигурационное меню системы (Транзакция SPRO). Однако на практике возникают ситуации, когда конфигурирования недостаточно и требуется программное вмешательство в работу стандартных алгоритмов системы.

Разработчики системы SAP, «иногда» понимали, что они не смогут перекрыть все варианты построения бизнес-процесса клиента. Например, какие-то специфические проверки при формировании значений в полях ввода. Конечно, с одной стороны очень просто активировать маску ввода для любого поля экрана, которое не привязано к проверочной таблице. Однако, если в внутри маски, например, символы с 5 по 8 должны содержать код балансовой единицы, которую надо проверить на существование, то возникает альтернатива: реализовать на уровне системы какой-то сложный анализатор масок ввода (с привязкой к проверочным таблицам) или использовать другие механизмы проверки значений. Самым простым способом является предоставление возможности включения программного кода проверки клиенту, внедряющему у себя систему SAP. Однако, методика включения такого кода может быть очень различной.

1.2. Варианты включения пользовательского кода

Первый (простой) вариант - это разрешение модификации стандартного кода; в итоге получаем систему класса 1С без какой - либо возможность обновления версий, не позволяющей также и применение стандартных патчей, исправляющих проблемы как безопасности, так и бизнес-логики в работе приложений.

Второй вариант - это разработка механизмов включения пользовательского кода в стандартную бизнес-логику работы программы.

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

2. Пользовательские расширения

2.1. Эволюция техник расширения

В общем случае, точки, в которых пользователю можно расширить логику работы системы, называют точками пользовательского расширения системы (User Exits). Однако, в связи с тем, что система развивается и существует уже более 20 лет (имеется в виду версия SAP R/3), вместе с её изменением менялись взгляды и подходы к реализации пользовательских расширений. Поэтому к настоящему моменту система имеет множество различных вариантов использования программных расширений. При этом как техника расширения, так и возможности, определяемые вариантами использования, могут кардинально отличаться.

Исторически возможные реализации и техники пользовательских расширений (замещений) развивались и трансформировались. В общем виде можно представить следующую модель развития используемых техник (Рис.1)

Рис.1. Эволюция техник расширения системы

2.2. Доступные техники расширений

В настоящий момент в системе используются и доступны для разработчиков следующие техники расширений:

  • Field-Exit – Наверное, один из самых старых вариантов включения пользовательских расширений в логику работы программы. В общем виде, данное расширение позволяет проверить значения, введенные (в диалоге или при использовании пакетного ввода) в поля стандартных транзакций. В данном типе расширения можно только проверить введенное пользователем значение, например, на существование в каком-то справочнике или сформировать/проверить введенные данные по собственной маске. К сожалению, получить «регламентированный» доступ к значениям других полей в контексте выполнения программы, для общего анализа введенных в поле данных – невозможно. Однако, существуют механизмы, которые позволяют все - таки обойти это ограничение.
  • Customerexits (Проекты расширений) – пользовательские расширения, использующие технику проектов, транзакции CMOD/SMOD. Данная техника используется практически в любой функциональности системы. Это наиболее широкий способ использования программных расширений. Для реализации технологии, используется вызов специального функционального модуля, для этого в язык системы был введен отдельный оператор вызова функции расширения. Основная проблема данного типа расширений - это поддержка написанного кода расширения несколькими разработчиками, кроме того отсутствует возможность «регламентированного» доступа к переменным вне функционального модуля системы, т.е. разработчики заранее определили набор переменных, которые передаются для анализа и набор переменных, которые можно изменить в данном типе расширения. Как и при использовании техники Field-Exit существует механизм обхода ограничения на доступ к переменным. Решение об использовании такой техники, принимает пользователь. Разработчики SAP не используют такого рода расширений, эта техника полностью отдана на откуп клиентам. Я встречал рекомендацию: если это возможно, в общем случае, использовать именно этот механизм расширений.
  • Userexits (Пользовательские подпрограммы) – пользовательские расширения для которых требуется получение ключа разработчика, так как реализация данного расширения представляет собой модуль находящийся в пространстве имен SAP. При этом в данном модуле реализованы подпрограммы, в которые требуется добавить пользовательский код. Так как эти подпрограммы выполняются в рамках контекста

Если хотите прочитать статью полностью и оставить свои комментарии присоединяйтесь к sapland

У вас уже есть учетная запись?

Войти

Обсуждения Количество комментариев4

Комментарий от  

Василий Ковальский

  |  25 февраля 2016, 12:47

Техника Field Exit устарела и не может быть рекомендована:
 
ABAP Runtime Environment (BC-ABA)
Obsolete customer exit which can be associated with data elements in ABAP Dictionary in customer systems. If a screen field with reference to a data element of this type is defined, the event PAI calls a function module called FIELD_EXIT_dtel when data is transported from the screen to the ABAP program. dtel stands for the name of the data element. The value of the screen field can be modified in the function module. The function module of a field exit cannot currently be debugged.
 
(см. тут: help.sap.com/saphelp_glossary/en
и тут wiki.scn.sap.com/wiki/display )
 
Доступ к управлению Field Exit убран из всех меню (но возможен из отчета RSMODPRF). Обычно (и по умолчанию) конфигурационный параметр abap/fieldexit установлен в 'no', что отключает все Field Exit
 
Не надо сожалеть о ереси и тем более не следует пытаться обойти ограничения, защищающие пользовательские данные от еретических вторжений.
 
Олег, Вы уж, пожалуйста, не учите плохому. И на мастер-классах тоже.

Комментарий от  

Олег Точенюк

  |  25 февраля 2016, 12:58

Техника Field Exit устарела и не может быть рекомендована:
 
ABAP Runtime Environment (BC-ABA)
Obsolete customer exit which can be associated with data elements in ABAP Dictionary in customer systems. If a screen field with reference to a data element of this type is defined, the event PAI calls a function module called FIELD_EXIT_dtel when data is transported from the screen to the ABAP program. dtel stands for the name of the data element. The value of the screen field can be modified in the function module. The function module of a field exit cannot currently be debugged.
 
(см. тут: help.sap.com/saphelp_glossary/en
и тут wiki.scn.sap.com/wiki/display )
 
Доступ к управлению Field Exit убран из всех меню (но возможен из отчета RSMODPRF). Обычно (и по умолчанию) конфигурационный параметр abap/fieldexit установлен в 'no', что отключает все Field Exit
 
Не надо сожалеть о ереси и тем более не следует пытаться обойти ограничения, защищающие пользовательские данные от еретических вторжений.
 
Олег, Вы уж, пожалуйста, не учите плохому. И на мастер-классах тоже.

Все в этом мире относительно и должно использоваться к месту. Я эту технику использовал всего один раз, так как других вариантов там особо нормальных небыло. Мне помогло, может еще кому поможет, хотя согласен, если папа сказал руками не трогать, то лучше руками не трогать :-), но хоть знать то что там нельзя трогать надо, ну хотя бы с позиции что просто интересно же.

Комментарий от  

Николай Кронский

  |  26 февраля 2016, 17:12

Могу еще посоветовать темы, связанные с расширениями:
1) пользовательские процедуры в стандартном диалоге ведения таблиц;
2) расширение стандартного средства поиска;
3) расширение блока контировки (CI_COBL) - все-таки, несмотря на связь с расширением объектов СД, требуются свои притопы;
4) RW-интерфейс, расширение его пользовательскими процессами.
 
Также на основе Enhancеmеnt'ов есть тема расширения функциональности стандартных классов и ФМ'ов - тоже вроде бы не упомянуто...
 
На закуску любопытно посмотреть на совмещение Enhancement и BAdI, внедрив собственное расширение на основе BAdI. Получается интересно - "модификации" минимальны, точка входа одна, контроль наличия расширений стандартен.
 
В целом - все это интересно, но 95% потребностей заказчика можно покрыть 30% возможностей АБАП-разработчика в части расширений :)

Комментарий от  

Олег Точенюк

  |  26 февраля 2016, 19:30

Могу еще посоветовать темы, связанные с расширениями:
1) пользовательские процедуры в стандартном диалоге ведения таблиц;
2) расширение стандартного средства поиска;
3) расширение блока контировки (CI_COBL) - все-таки, несмотря на связь с расширением объектов СД, требуются свои притопы;
4) RW-интерфейс, расширение его пользовательскими процессами.
 
Также на основе Enhancеmеnt'ов есть тема расширения функциональности стандартных классов и ФМ'ов - тоже вроде бы не упомянуто...
 
На закуску любопытно посмотреть на совмещение Enhancement и BAdI, внедрив собственное расширение на основе BAdI. Получается интересно - "модификации" минимальны, точка входа одна, контроль наличия расширений стандартен.
 
В целом - все это интересно, но 95% потребностей заказчика можно покрыть 30% возможностей АБАП-разработчика в части расширений :)

>>95% потребностей заказчика можно покрыть
Это можно закрыть без ABAP стандартной функциональностью :-) что и будет с моей точки зрения правильным.
 
>>1) пользовательские процедуры в стандартном диалоге ведения таблиц;
Ну это все таки не расширения, это генерация ракурсов/кластеров ведения.
 
>>2) расширение стандартного средства поиска;
Стандартное средство поиска, я бы сам послушал как можно расширить без ключа. А если имелись в виду комплексные то там вроде как и особо ничего такого нет, сделал элементарное и присвоил его комплексному.
 
>>3) расширение блока контировки (CI_COBL) - все-таки, несмотря на связь с расширением объектов СД, требуются свои притопы;
Согласен там есть свои тонкости.
 
>>4) RW-интерфейс, расширение его пользовательскими процессами.
Ну для нас SAP вроде как сделал BTE - Business Transaction Events. А включать в цепочку стандартных ФМ для RW свои модули, наверное будет не кошерно.
 
>>Также на основе Enhancеmеnt'ов есть тема расширения функциональности стандартных классов и ФМ'ов - тоже вроде бы не упомянуто...
Там много чего есть кроме ФМ, об этом будет написано в теме Enhancements spot/section, там же и про расширение классов и т.д.
 
>>На закуску любопытно посмотреть на совмещение Enhancement и BAdI,
Типа сделать довесок используя Enhancement к классу реализующему BADI? Если исходить из того, что классы для BADI это классы, то как их расширять будет описано в теме Enhancеmеnt'ов.