1 - A3_Вступление

[Uukrul]

Общий обзор

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

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

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

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

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

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

• Field-Exit – Наверное один из самых старейших вариантов включения пользовательских расширений в логику работы программы. В общем виде данное расширение позволяет проверить введенные значения в полях стандартных транзакций, в диалоге или при использовании пакетного ввода. В данном типе расширения можно только проверить введенное пользователем значение, например на существование в каком-то справочнике или сформировать/проверить введенные данные по собственной маске. К сожалению, получить «регламентированный» доступ к значениям других полей в контексте выполнения программы, для общего анализа введенных в поле данных – невозможно. Однако, существуют механизмы, которые позволяют все таки обойти это ограничение.
  
• Customerexits (Проекты расширений) – пользовательские расширения, использующие технику проектов, транзакции CMOD/SMOD. Данная техника используется практически в любой функциональности системы. Это наиболее широкий способ использования программных расширений. Для реализации технологии, используется вызов специального функционального модуля, для этого в язык системы был введен отдельный оператор вызова функции расширения. Основная проблема данного типа расширений, это поддержка написанного кода расширения несколькими разработчиками, а так же невозможность «регламентированного» доступа к переменным вне функционального модуля системы, т.е. разработчики заранее определили набор переменных, которые передаются для анализа и набор переменных которые можно изменить в данном типе расширения. Аналогично технике Field-Exit существует техника обхода ограничения на доступ к переменным. Хотя, использование данной техники, полностью лежит на разработчике. Разработчики SAP не используют расширений, данная техника полностью отдана на откуп клиентам. В общем случае я встречал рекомендацию, если это возможно, то использовать именно этот механизм расширений.
  
• Userexits (Пользовательские подпрограммы) – пользовательские расширения для которых требуется получение ключа разработчика, так как реализация данного расширения представляет собой модуль находящийся в пространстве имен SAP при этом в данном модуле реализованы подпрограммы в которые требуется добавить пользовательский код. Так как эти подпрограммы выполняются в рамках контекста основной системной программы, то требуется очень аккуратно обрабатывать доступные глобальные переменные основной программы. Данная техника достаточно активно применяется в функциональности SD.
  
• Замещения – Технология замещений используется в некоторых модулях системы, например FI и позволяет автоматически выполнить заполнение параметров документов при сохранении. Например, задачи замещения контрольного счета кредитора при проводке счета логистики или сложные алгоритмы замещения объектов контировок. В общем виде данная техника замещений предназначается для работы без какого-либо кодирования на языке ABAP. Но, в одном из вариантов реализации замещений можно использовать программные вставки кода. Данная техника расширений представляет пользователю довольно гибкий механизм управления значениями полей в документах. Техника позволяет, как выполнять проверки в ходе сохранения документа, так и выполнять изменения в значениях полей. Одним из плюсов данной техники, является то, что после работы замещения, структура сохраняемого документа еще раз проходит функции проверки значений для полей документа. Соответственно если вы некорректно выполните замещение поля, например, подставите в ходе замещения номер счета главной книги, которого нет в системе, то получите стандартное сообщение об ошибке. Это в некоторой мере страховка от не правильной реализации кода замещения.
  
• BTE - Business Transaction Events – техника расширения позволяющая выполнить дополнительную проверку данных в момент ввода документа в систему или  же выполнить обновление данных в собственных таблицах при формировании определенных типов операций в функциональности главной книги FI-GL, учете дебиторской и кредиторской задолженности (FI-AR и FI-AP) и модуле сбыта (SD). Появление данной техники должно было сгладить некоторые проблемы использования одной точки расширения разными разработчиками. В некотором роде для событий проверки значений это удалось сделать, однако реализация события обновления может быть только одна. Техника бизнес событий используется как разработчиками SAP, партнерами SAP, так и клиентами, хотя для клиентов, часть событий ограничена к использованию.
  
• BADI – Технология внедрения бизнес расширений в код стандартных транзакций - данная техника доступна в любых модулях системы, фактически эта технология принята заместить технику Userexits, используя объектно-ориентированный подход к реализации расширений системы. На данном этапе существуют два варианта реализации технологии BADI, это так называемы старые и новые BADI расширения, которые отличаются способом реализации классов расширения. На первый взгляд техника новых и старых BADI кажется одинаковой, хотя если разобраться, то различия существенны и не понимание этих различий приводит к не правильному использованию новых BADI. Технология BADI призвана решить основную проблему использования точки расширения несколькими пользователями с изоляцией вызовов. Причем, именно новая технология BADI, предоставляет полную изоляцию каждой инстанции.
  
• Enhancements spot/section – Техника расширения доступная с версии 6.0,  позволяющая практически выполнить внедрение пользовательского кода в любом месте стандартной бизнес-транзакции. Enhancement-ы в системе разделяются на «явные» и «не явные». Явные точки расширения аналогично технике Userexits используют специально введенный оператор, неявные же фактически присутствуют в начале и конце логически завершенного блока. Данная техника позволяет внедрять пользовательский код в контекст выполнения стандартного кода системы. Вы получаете доступ ко всем переменным и можете фактически полностью переопределить логику работы системы, что является очень не безопасным, так как это может привести к серьезным сбоям в работе стандартных транзакций, в случае не корректной реализации кода расширения. На данный момент это с одной стороны очень мощный механизм расширения функциональность, а с другой стороны самый не безопасный из всех типов расширений. Общая рекомендация от компании SAP, если существует возможность использования любой другой тип расширения – используйте его, технику Enhancements – используйте, только в том случае, если других возможностей влияния на выполняемый код нет.
  
• Расширение объектов словаря данных - система позволяет частично модифицировать некоторые элементы словаря данных без получения ключа на объект. К таким модификациям относится создание вторичных индексов к таблицам БД, создание новых значений к доменам системы и расширение стандартных структур и таблиц системы.