Оглавление

Предисловие

Обзор

Описание настройки экранов (BDT)

Особенности программирования ABAP

Интерфейсы, менеджеры и фабрики

Z менеджеры, они же расширения объектов RE

Общие замечания по программированию классов – расширений

Использование интерфейса IF_RECA_MESSAGE_LIST (коллектор сообщений)

Разное

Заключение: общие проблемы разработок в RE-FX

Предисловие

Данный документ рассчитан, в первую очередь, на разработчиков, впервые приступающих к разработкам в модуле RE-FX. Также он может быть полезен и для консультантов этого модуля. Льщу себя надеждой, что опытные разработчики тоже найдут что-то для себя полезное.

Руководителям рекомендую сразу прочесть Заключение.

Обзор

Модуль RE-FX (формально относится к «Учет и Отчетность) сравнительно молод,  написан единообразно и по новейшим компьютерным технологиям. Достоинства – чрезвычайная легкость получения и изменения основных данных (о пакетном вводе и BAPI надо забыть), необычайная гибкость в изменении поведения и легкость добавления новых атрибутов в основные данные (последнее, впрочем, таит немалые опасности в руках «умелого» программиста). Данные, логика их обработки и проверки здесь полностью отделены от экранов. При правильном программировании (а оно проще неправильного) это касается и Z данных.

К недостаткам можно отнести чувствительность к большим объемам данных (например, начиная примерно с 10000 прикрепленных объектов).

Описание настройки экранов (BDT)

BDT (Business Data Tools) - это способ формирования Gui интерфейса основных данных. Он унаследован из ДП (Деловой Партнер, BP), при этом упрощён. BDT очень хорошо документирован, прежде всего в текстах к соответствующим веткам SPRO (и F1 документации к полям там). Много и в интернете, e.g. http://help.sap.com/saphelp_erp60_sp/helpdata/en/ac/af8d5377a0ec23e10000000a174cb4/frameset.htm

Разберем коротко пример. Вот как выглядит договор (транзакция RECN, рис. 1):

Рис.1 Пример объекта RE (договора)

Мы видим картотеку с 6 закладками. Заметим, что ни одной этой закладки нет в стандартной поставке Сап.

Как это устроено. Заметим, Договор принадлежит к типизированным объектам RE. ( N.B.! Типизированы далеко не все объектыRE(Договор, Архитектурный Объект, еще что-то). Но за день – два квалифицированного программирования можно ввести тип дифференциации (вид) в любой из объектов RE, e.g. Здание). Ищем тип (вид) договора, в данном случае смотрим в таблице VICNCN. Вид – ZPLN. Смотрим настройку (рис. 2) (заметим, кроме SPRO можно использовать отдельную транзакцию RECACUST):

Рис. 2 Фрагмент настройки Договора (SPRO)

Узнаем последовательность экранов – ZPLN. Смотрим дальше (рис. 3):

Рис. 3 Фрагмент настройки Договора (SPRO)

Проваливаемся в последовательности экранов (рис. 4):

Рис. 4 Экраны в последовательности экранов для нашего договора

Мы видим 1й, технический, невидимый экран и дальше 6 наших закладок (N.B.!: омонимия между экранами-закладками в BDT и ABAP экранами является источником путаницы). Дальше разберем, для примера, 1й экран, ZREPL1. Проваливаемся в Экраны (рис. 5):

Рис. 5 Фрагмент настройки Договора (SPRO)

И видим (рис. 6):

Рис. 6 Фрагменты в экране BDT

Наш экран состоит из двух фрагментов (не считая 1го, технического).

Фрагмент ZREPL1 (рис. 7):

Рис. 7 Ракурсы в фрагменте (BDT)

состоит из двух ракурсов. Ракурс ZPLN01 (рис. 8):

Рис. 8 Ракурс (BDT), подробно

Здесь мы уже добрались до ABAP экранов и ФМ. Экран, конечно, должен быть подэкраном, он вставляется вместе со всей своей логикой в Gui ведения объекта (место определено настройкой экран – фрагмент – ракурс). ФМ «перед выводом» это PBO, «после ввода» -- PAI, «перед вызовом» -- понятно. ФМ имеет предопределенный интерфейс (посмотрите сами, пример ФМ REGC_REGC_PBO), но передаваемый параметр совершенно бесполезен. Поэтому без ФМ можно легко обойтись, написав модули в PBO и PAI.

 N.B.!1  Для пущего отделения данных от экранов желательно каждый ракурс писать отдельной ГФ. Это, из-за лени, не делается, но в ГФ примера ни один большой экран не взаимодействует с другим большим экраном напрямую.

N.B.!2 На рисунке сбоку видна сущность «группа полей». Обычно в Z экранах используется dummy – пустая группа полей. Тем не менее, именно группы полей представляют наибольший интерес с ABAP точки зрения. Но это мало используется и я рекомендую разобраться в группах полей самим (как я уже писал выше, BDT прекрасно документировано, особенно внутри SPRO). Заметим, именно на уровне группы полей реализовано то, что рис.1 мы видим 6 закладок, а на рис.4 –  7 экранов BDT (одна закладка закрыта динамически).

N.B.!3 Я не рекомендую брать за образец стандартные экраны Sap (те, которые прописаны в BDT), они переполнены макросами.

N.B.!4 Единственный нужный макрос для программирования экранов для BDT – это mac_bdt_get_okcode_subscreen (инклуд IFRECABDT). Он нужен для чтения ОК кодов (обратите внимание – они обрезаются до 22 символов).

Особенности программирования ABAP

Интерфейсы, менеджеры и фабрики

Итак, мы научились вставлять экраны, но как получать и сохранять данные? Для этого надо получить ссылку на объект, вызвав ФМ RECA_BDT_APPL_GET_BUSOBJ (этот ФМ принадлежит к верхней ГФ обеспечивающей ведение объектов RE через Gui). Если известен вид объекта (префикс OBJNR)  RE можно вызвать специфический ФМ, e.g. для договора (IS) ФМ REGC_GET_BUSOBJ.

В этих ФМ ссылка на объект имеет тип IF_RECA_BUS_OBJECT. Этот интерфейс содержится во всех объектах RE, смотри, например, интерфейс договора (IS) IF_RECN_CONTRACT.

Вот сейчас отвлечемся от Z расширения стандарта и поговорим об этих интерфейсах.

Положим, надо изменить или прочитать существующие объекты RE, e.g. договора (из реестра ли договоров, из файла excel, ещё как, но минуя Gui интерфейс). Мы должны сперва получить ссылку на нужный нам объект. Для этого существуют классы – «фабрики». В случае договора (IS) это CF_RECN_CONTRACT и общая фабрика CF_RECA_BUS_OBJECT (вообще, почти всегда если есть интерфейс IF_что-то_там, то есть и фабрика CF_что-то_там). В случае, если у нас есть БЕ и № договора – нам нужен метод FIND фабрики CF_RECN_CONTRACT, если есть INTRENO или OBJNR то лучше использовать соответствующий метод фабрики CF_RECA_BUS_OBJECT.

N.B.! При программировании в RE лучше, насколько возможно, использовать более универсальные методы, e.g. ссылку на IF_RECA_BUS_OBJECT вместо ссылки на конкретный интерфейс и т.д. Это позволяет вставлять экраны и расширения в разные объекты RE.

N.B.! Структура основных (заголовочных) таблиц объектов RE. Смотрим на примере договора – таблица VICNCN. Мы видим технический ключ – поле INTRENO, логический ключ – инклуд с именем KEY (поля BUKRS и RECNNR) и второй технический ключ – OBJNR (именно им чаще всего удобнее пользоваться).

Итак, мы получили ссылку на нужный нам договор и в нужной ACTIVITY, '03' (RECA1_ACTIVITY-DISPLAY), если нам нужно только чтение данных, или ‘02’ (RECA1_ACTIVITY-CHAGE), если нам нужно редактировать объект (если нам нужно объект создать, мы получим ссылку с ‘01’ и методом CREATE).

Теперь мы считываем данные методами нашего объекта (в нашем примере IF_RECN_CONTRACT) и меняем данные соответствующими методами. Заметим, что стандартный Gui интерфейс работает точно также (использует фабрику, получает ссылку, вызывает методы).

Но мы замечаем, что этих методов мало (сравнивая с количеством разных атрибутов на экранах ведения). Правильно, атрибуты присущие разным объектам RE и составляющие отдельную сущность ведутся через посредство менеджеров.

Вот, например, измерения (число этажей, кол-во умывальников, площадь, что хотим) присущи большинству объектов RE. И мы видим в IF_RECN_CONTRACT интерфейс IF_RECN_HAS_MEASCN. В нем есть метод GET_MEASCN_MNGR, с его помощью мы получаем ссылку на объект типа IF_RECN_MEASCN_MNGR. Используя методы этого интерфейса можно получить данные об измерениях в договоре и/или изменить эти данные.

N.B.! Пример с измерениями не самый удачный. В контракте отдельный менеджер измерений, во всех остальных объектах RE менеджер IF_REBD_MEAS_MNGR, вызывается через интерфейс IF_REBD_HAS_MEAS.

Еще отдельно хочу указать на менеджер дополнительных текстов IF_RECA_ADDITIONAL_TEXT_MNGR (через интерфейс IF_RECA_HAS_ADDITIONAL_TEXT). Дополнительные тексты существуют практически во всех объектах RE, и именно с их помощью ведутся длинные тексты, относящиеся к объекту целиком (т.е. ко всему договору, ко всему зданию etc.).

N.B.! Желающий может разобраться как устроена имплементация этого менеджера. При этом он увидит разные менеджеры и фабрики применимые (и удобные) при разработках с длинными текстами за пределами RE

Вот так и устроен изнутри объект RE – небольшой набор специфических методов и менеджеры вытаскиваемые из объекта. Естественно, при работе с менеджерами надо набить руку. Некоторые менеджеры имеют методы с неочевидным интерфейсом, ну и другие разные проблемы могут возникнуть. Но. в целом, всё это гораздо удобнее и проще разработок в классическом