Бизнес - объект BOPF. Business Object Processing Framework (BOPF)

1.

Business Object Processing Framework (BOPF)
04.07.2023

2.

Раздел 1
В этом разделе будут рассмотрены следующие темы:
Введение в BOPF
• что такое бизнес объект
BOPF ?
• архитектура BOPF
• business application
• модель BOPF
• группы БО в модели BOPF
• расширения BOPF
• модель БО
• модель данных узла
• метаданные
• транзакции ведения БО
• новый БО
• добавление узлов
• практическое задание

3.

Что такое бизнес-объект BOPF?
раздел 1
Бизнес-объект BOPF – это своеобразное представление типа для уникально
идентифицируемого бизнес-объекта, описанного структурной моделью и моделью
внутреннего процесса. Реализованные бизнес-процессы работают на бизнесобъектах.
Вы можете использовать существующий бизнес-объект для реализации нового
бизнес-объекта или приложения на его основе. Например, вы можете
использовать бизнес-объект BOPF для реализации сложной конфигурации
сервисного компонента повторного использования. Вы можете расширить бизнесобъект, его характеристики и параметры конфигурации.

4.

Архитектура BOPF
Основные элементы:
Business Application
основной проводник
между данными,
связанными с ними
процессами и
пользователем.
Предоставляет набор
необходимых для
работы интерфейсов.
Модель BOPF
содержит в себе
параметры настройки
всех реализованных
бизнес – объектов (БО)
раздел 1

5.

раздел 1
Business Application
Содержит
в
себе
объекты,
обеспечивающие
конфигурирование
и
выполнение операций для каждого БО.
Обеспечивает доступ к данным БО: Buffer
Classes, Data Access Classes. Включает в
себя: determinations, validations, actions,
associations. В целом, именно эти
элементы определяют поведение БО.
Ко всему прочему, бизнес – процессы и
буферизация данных также разделены в
BOPF. Все заданные для БО бизнес
процессы протекают на верхнем уровне,
буферизация
данных
происходит
независимо от них. Бизнес процессы БО не
могут влиять на то, как и где происходит
буферизация. Однако, BOPF допускает
очистку буфера, а также использование
инстанций
различных
классов
для
получения данных.
Обращение к БО происходит через
специальную API (Service Manager). В
BOPF изменение данных и всевозможные
проверки
четко
разделены.
Не
предусмотрено инструмента, который бы
позволял, например, менять данные БО в
методах, предназначенных для проверок.
Данные в буфере и данные в БД также
разделены в BOPF (точно также, как и с
бизнес – процессами).
Это позволяет
задать поведение в работе БО как для
текущих данных в БД, так и для тех, что на
данный момент находятся в буфере
(обычно, это необходимо уже для узких
задач).

6.

Модель BOPF
Модели любой БО можно посмотреть
при
помощи
специального
инструмента BOPF Modeling Tool
(транзакция /BOBF/CONF_UI). В ней
есть список всех БО. По каждому БО
можно
посмотреть
иерархию
и
структуру узлов БО (подробнее об
этом позже), заданные конфигурации,
объекты ABAP – словаря, отдельные
элементы
узлов
(например,
Associations, Actions, Determinations,
Validations и Queries) и т.п. Также,
отсюда можно перейти к ABAP –
классам, в которых реализованы
бизнес – процессы БО (например, в
класс конкретного Action).
Бизнес – объект представляет собой
совокупность
уникально
идентифицируемых
бизнес
–
сущностей, которые описаны при
помощи структурных и процессных
моделей. Таким образом, описанные
бизнес – процессы работают в рамках
БО. Важно отметить, что большинство
БО могут быть расширены (у
стандартных
БО
могут
быть
добавлены узлы, Action и т.д.).
раздел 1

7.

Модель BOPF
раздел 1
• Consumer (Пользователь)
В
рамках
текущей
транзакции
пользователь
выполняет
ключевые
операции, доступные ему в на уровне
Transaction Layer, с экземплярами БО.
Пользовательские процессы могут быть
предоставлены как через UI, так и через
фоновые процессы.
Consumer
Transaction
Layer
BOPF Model
BOPF Runtime
Enhancement
Implementations
Buffer and
Database
• BOPF Runtime
На уровне BOPF Runtime происходит выполнение ключевых
операций, которые были запущены на уровне Transaction Layer
(создаются и вызываются экземпляры необходимых классов
различных сущностей БО). Например, когда на уровне пользователя
вызывается ключевая операция DO_ACTION, на уровне BOPF
Runtime создается и вызывается реализующий класс конкретного
Action. После выполнения Action BOPF возвращает результат
выполнения на уровень пользователя.
• БД и буфер данных
Данные БО, полученные в рамках обращений к БД, автоматически
записываются в буфер BOPF. Это необходимо для предотвращения
избыточных обращений к БД.
• Transaction Layer
Ну уровне Transaction Layer выполняются
операции инстанции объекта transaction
manager БО (например, сохранение всех
изменений экземпляров БО в рамках
транзакции). В дополнение к этому на
этом
уровне
для
каждого
БО
обеспечивается доступ к ключевым
операциям экземпляров этого БО через
инстанцию объекта service manager
(например,
операция
RETRIEVE
обеспечивает
чтение
данных
экземпляров БО).
• BOPF Model
Каждый
реализованный
БО,
как
рассматривали
ранее,
состоит
из
некоторых
сущностей
(Action,
Determination и т.п.). Например, в модели
BOPF хранится реализующий класс
конкретного Action. Модель стандартных
БО может быть дополнена средствами
BOPF Enhancement Workbench, что
учитывается на уровне BOPF Runtime.

8.

Группы БО в модели BOPF
Transportable
BO
раздел 1
Business Process Objects
Существующие объекты бизнес процессов текущей системы
Dependent objects
Используется в ля повторно используемых частей бизнес-объектов, которые сами по себе не являются
объектами, т. е. существуют только в контексте БО (хостинг-объект). Примерами являются папка
вложений, набор текста и т.д.
Master Data Objects
Большинство БО основных данных вызывают базовый уровень основных данных SCM (MDL) через
адаптер только для чтения. Содержание таких БО поддерживается посредством стандартных транзакций
в SCM Basis. В SAP EHSM доступ к основным данным осуществляется только через БО основных данных.
Примеры: «Местоположение», «Деловой партнер», «Мероприятие» и т.д.
Meta Data Objects
Данные содержащиеся в таких БО при определении принимают во внимание во время выполнения для
определения требуемого поведения бизнес-процесса.
Test Objects
Данный раздел содержит демонстрационные примеры БО
Enhancement Objects
Стандартные расширения стандартных объекты бизнес процессов текущей системы
HOME BO
Business Process Objects
Созданные Z объекты бизнес процессов текущей системы
Enhancement Object
Z расширения стандартных объекты бизнес процессов текущей системы
Local BO
Business Process Objects
Z объекты бизнес процессов не подлежащие переносу по ландшафту системы

9.

Расширения BOPF
раздел 1
• Расширение
бизнес-объекта
содержит
дополнительную информацию о бизнеслогике и модели, связанную с определенным
бизнес-объектом или расширением. Бизнесобъект в такой ситуации будет являться
базовым объектом.
• Во
время
разработки
каждое
усовершенствование
можно
отдельно
поддерживать
в
инструментальных
средствах усовершенствования BOPF. Во
время
выполнения
бизнес-логика
и
информация о модели всех улучшений
бизнес-объекта объединяются
в один
всеобъемлющий объект.
• Во время разработки базовый объект может
быть расширен более одного раза. Эти
улучшения
также
могут
иметь
дополнительные улучшения. Все улучшения
одного
базового
объекта
образуют
древовидную иерархию.
• Расширение может расширять только
сущности,
расположенные
в
базовом
объекте и определенные как расширяемые.
• Чтобы расширить сущность, она должна быть
определена как расширяемая. Вы можете
расширить узлы следующими дополнительными
объектами:
o Subnodes
o Attributes
o Determinations
o Actions
o Consistency validation
• Вы можете расширить действия следующими
дополнительными сущностями:
o Action validations
o Pre action enhancement
o Post action enhancement

10.

Модель БО
раздел 1
Ниже представлена схема, которая отображает наиболее распространенные архитектурные
решения как стандартных, так и пользовательский БО:
ROOT
Главный узел, дерево
узлов всегда начинается
с него
REVISION
Узел который находится как
правило под root и нужен для
хранения версий нижестоящих
узлов. Его добавление
опционально
STANDARD
NODE
STANDARD
NODE
Содержит данные.
Содержит подузел
Содержит данные.
Не содержит подузлы
STANDART
SUBNODE
Содержит данные
TRANSIENT
NODE
TRANSIENT
SUBNODE
Динамические
данные
REFRENCE
SUBNODE
Ссылочный узел
другого БО
Динамические
данные
REFERENCE
NODE
Ссылочный узел
другого БО
DELEGATE
SUBNODE
Узел основанный на другом
узле другого БО
DELEGATE
NODE
Узел основанный на
другом узле другого БО

11.

Модель данных узла
раздел 1
Combined Structure and Table Type
эта структура DDIC включает в себя структуру данных узла. Кроме того, он
включает в себя фиксированную структуру DDIC BOPF, которая содержит ключ
экземпляра узла (KEY), ключ экземпляра прямого родительского узла
(PARENT_KEY), а также ключ связанного экземпляра бизнес-объекта (ROOT_KEY).
Data Structure
эта структура DDIC содержит атрибуты узла, представляющие данные узла.
Data Structure (tr.)
содержит временные атрибуты узла, то есть атрибуты, которые не сохраняются, а
только заполняются и используются во время выполнения.
Database Table
таблицу базы данных, в которой хранится информация о постоянном узле.
Combined
Structure
and Table
Extension
Type
Include
Keys node
ключи root_key, parent_key, db_key
Data
Structure
(tr.)
(tr.)
Extension
Include
Data
Structure
Database
Table
Admin data
представляет собой include /BOBF/S_ADMIN, который содержит поля для хранения
пользователей и времени создания и изменения.
Admin
data
Extension Include & Extension Include (tr.)
для расширений полей на узле важно включить расширение. При этом добавляются
все поля расширения (через Append Structures), которые должны быть сохранены.
Поля расширения, которые имеют значение только во время выполнения и не
имеют отношения к сохранению, помещаются в соответствующее временное
включение расширения.
Data
Structure
Keys
node

12.

Метаданные
раздел 1
Интерфейс констант
Генерируется автоматически при создании БО. Внутри содержит guid каждого элемента дерева
структуры БО. Важно помнить, что при добавлении или удалении объекта дерева БО, нужно
обязательно перегенерировать интерфейс констант.
Структура дерева БО
Иерархическая организация данных внутри экземпляров узлов поддерживается за чет трех полей.
Они всегда присутствуют и заполнены в каждом узле. За исключением узлов, которые находятся
непосредственно под ROOT. В них не заполняется поле root_key.
o
o
o
DB_KEY – уникальный ключ каждого экземпляра узла.
PARENT_KEY – ключ на экземпляр вышестоящего узла.
ROOT_KEY – уникальный ключ каждого экземпляра БО.
Административные данные
Каждый узел может хранить информацию по созданию и изменению данных. Они прописываются
по средствам специальной детерминации реализованной на стандартном классе
/BOBF/CL_D_ADMIN_DATA. Поля:
o
o
o
o
DATETIME_CR – Дата/время создания позиции
USER_ID_CR – Объект создал
DATETIME_CH – Дата/время изменения позиции
USER_ID_CH – Объект изменил

13.

Транзакции ведения BO
раздел 1
BOBX – BOPF: Business Object Configuration
• Основная транзакция для разработки Z объектов
BOB – Business Object Builder
• Создание Z объектов с помощью мастера (помощников)
/BOBF/CONF_UI – BOPF: Business Object Configuration
• Изменение стандартных бизнес объектов. Экраны отображают больше информации, чем
BOBX
/BOBF/CUST_UI – BOPF Enhancement Workbench
• Расширение стандартных бизнес объектов
BOBT – Business Object Builder – Test
• Позволяет смоделировать обработку, заполнить данные и т.д.

14.

Новый БО
раздел 1
1.
Рекомендуется
предварительно
создать
отдельный пакет, в который будут сложены
объекты, относящиеся к БО. В нашем случае
ZINC_DEMO_BO.
Также
рекомендуется
подготовить
транспортный
запрос
при
необходимости.
2.
Открываем транзакцию BOB.
3.
Жмем «Пользовательский бизнес-объект»
4.
Открывается мастер, жмем «Дальше»
5.
Заполняем поле «Область имен» значением
«Z», вводим имя и описание БО. Жмем
«Дальше».

15.

Новый БО
раздел 1
6.
Проверяем
корректность
технического
наименования
БО,
при
необходимости
возвращаемся на предыдущий шаг и правим. При
необходимости правим наименование интерфейса
констант БО, который будет сгенерирован. Жмем
«Дальше».
7.
Необходимо предварительно создать 2 структуры
ABAP словаря. Одна структура – для постоянных
данных, одна для временных. Рекомендуется в
конце структур указывать *_D и *DT (Data и Data
Transient)
соответственно.
В
структуру
с
постоянными данными необходимо добавить
Include структуру /BOBF/S_ADMIN и как минимум
одно поле.
8.
Структуру с временными данными указывать
необязательно. Если временные данные все же
нужны, то в структуру также необходимо добавить
хотя бы одно поле.

16.

Новый БО
раздел 1
9. Имя корневого узла оставляем «ROOT», так будет правильней и
заполняем описание узла. Вводим наименование постоянной и
временной структуры узла. Жмем «Дальше».
10. Заполняем наименование комбинированной структуры узла,
наименования комбинированного типа таблиц и наименование
прозрачной таблицы (будут сгенерированы автоматически). Жмем
«Дальше».
11. Жмем
«Завершить».
Выбираем
пакет разработок и
транспорт
(диалоговое окно появится для
каждого объекта отдельно).

17.

Новый БО
12. Проверяем наличие новое БО
в транзакции BOBX.
раздел 1
13. По двойному щелчку переходим в новый БО,
проверяем наличие всех сгенерированных объектов
ABAP – словаря узла ROOT.
14. Переходим в транзакцию BOBT. В поле ввода вносим наименование
новой БО, жмем Enter.

18.

Новый БО
15. Проверим работоспособность БО, создав новый
экземпляр узла ROOT. Двойным щелчком выбираем
узел ROOT, в правом окне в тулбаре жмем «Add
Node Instance».
раздел 1
16. Выделяем добавленную строку, вводим чтонибудь в поле DUMMY_FIELD в окне внизу,
жмем Enter. Жмем Save.
17. Выходим из транзакции BOBT. Возвращаемся к
транзакции BOBX. Переходим по двойному щелчку
в прозрачную таблицу узла ROOT.
18. Проверяем наличие добавленной
записи в прозрачной таблице.
ранее

19.

Добавление узлов
раздел 1
1. Для нового узла понадобятся структуры ABAP – словаря c постоянными и с временными данным.
Необходимо предварительно создать их. В нашем примере мы создадим подузел REVISION для узла ROOT у
БО ZINC_DEMO. Для узла REVISION добавим поля STATUS (статус ревизии) и DATE_END (дата окончания
ревизии). Для обоих полей создадим отдельные элементы данных. Для поля STATUS создадим домен,
укажем подпрограмму преобразования DFVAL и добавим 2 доменных значения (01 – Активно; 02 –
Неактивно).

20.

Добавление узлов
2. Переходим в транзакцию BOB. Выбираем
нужный БО по двойному щелчку.
раздел 1
3. Жмем правой кнопкой мыши по
нужному узлу, выбираем «Создать
подузел».
4. Жмем «Дальше».

21.

Добавление узлов
5. Жмем «Дальше».
7. Заполняем
наименование
комбинированной
структуры, комбинированного
типа таблиц и
прозрачной
таблицы
(будут
сгенерированы
автоматически). Жмем «Дальше».
раздел 1
6. Вводим имя, описание узла и жмем «Дальше».
8. Жмем «Завершить». Выбираем пакет
разработок и транспорт.

22.

Добавление узлов
раздел 1
9. Переходим в транзакцию BOBX. Выбираем нужный нам БО (ZINC_DEMO) по
двойному щелчку, жмем «Display <–> Change», жмем «Check & Generate».
11. Жмем кнопку «Add Node Instance», вводим статус, и дату
окончания ревизии. Жмем «Save». Обращаем внимание на то что
поля PARENT_KEY и ROOT_KEY узла REVISION соответствуют
полю KEY узла ROOT.
10. Переходим в транзакцию BOBT, в окне ввода БО
вводим наш БО, создаем новый экземпляр узла
ROOT, разворачиваем дерево в левой части экрана
с созданной записью узла ROOT, видим
возможность
создания
узла
REVISION
по
ассоциации, жмем по ней двойным щелчком.
12. Проверяем наличие записи нового узла в
прозрачной таблице.

23.

Практическое задание
раздел 1
• Предлагаю вам создать самостоятельно новый локальный БО ZLOC_DEMO_{ваши инициалы}.
• Добавить узлы, как показано на схеме ниже.
• Для каждого узла создать все необходимые объекты словаря.
LOC_CHILD – нижестоящие МПЛ.
Вышестоящий ROOT. Тип T
Поле
Описание
Тип
Структура
key
root_key
нижестоящего
МПЛ
/BOBF/C
ONF_KEY
Постоянная
BSINF – основные данные.
Вышестоящий ROOT. Тип N.
ROOT.
Поле
Описание
Тип
Структура
Поле
Описание
Тип
Структура
Id
идентификатор
CHAR20
Постоянная
name
наименование
TEXT70
Постоянная
loc_pa
rent
вышестоящий
/BOBF/C
ONF_KEY
Постоянная
inn
ИНН
CHAR12
Постоянная
cc
БЕ
CHAR4
Постоянная
type
тип
CHAR4
Постоянная
phone
телефон
CHAR30
Временная
city
город
CHAR50
Временная
street
улица
CHAR40
Временная
LOC_PARENT – вышестоящий МПЛ.
Вышестоящий ROOT. Reference узел.
НастроЗФить ссылочный узел к
ZLOC_DEMO -ROOT
RESP – ответственные.
Вышестоящий ROOT. Тип N.
Поле
Описание
Тип
Структура
person
ответственный
CHAR20
Постоянная
role
роль
CHAR2
Постоянная
email
почта
CHAR4
Временная
INC – нижестоящие МПЛ.
Вышестоящий
BSINF.
Reference узел.
Настроить
ссылочный
узел к ZINC_DEMO-ROOT

24.

Раздел 1
Спасибо за внимание.
Вопросы?

25.

Раздел 2
В этом разделе будут рассмотрены следующие темы:
Элементы узлов и механизмы
взаимодействия
• основные элементы БО
• actions
• создание action
• determinations
• время выполнения
determination
• создание determination
• validations
• создание validation
• queries
• создание query
• associations
• основные свойства
association
• создание association
• работа с BOBT
• практическое задание

26.

Основные элементы реализации бизнес-процессов
раздел 2
Actions – элемент узла бизнес-объекта, описывающий операцию, выполняемую
на этом узле.
Determinations – элемент узла бизнес-объекта, описывающий внутреннюю
меняющуюся бизнес-логику БО. Его можно использовать для запуска бизнеспроцессов, которые должны возникать на основе внутренних изменений БО (в
отличие от Actions).
Validations – элемент узла бизнес-объекта,
внутреннюю бизнес-логику проверок БО.
Queries – представляют собой определенный набор атрибутов, таких как
параметры поиска, которые возвращают запрошенные данные экземпляров
узлов БО.
Association – это прямая однонаправленная связь между двумя узлами бизнесобъектов.
описывающий
некоторую

27.

Actions
раздел 2
Action может использоваться для обеспечения внешнего запуска бизнес-логики (в отличие от
Determination). При выполнении Action необходимо указать ключи экземпляров, над
которыми он должен выполняться (если это не статический Action), а также входные
параметры Action, если это необходимо нужны.
Action может быть выполнен только с тем количеством экземпляров, которое настроено в
параметре «Cardinality» Action. Action выполняется для всех переданных экземпляров, если в
соответствующем ему Validation не возникло ошибок. Если такие ошибки возникают, то
поведение зависит от настроек Action.
Пример вызова Action для заданного набора экземпляров БО TRQ, представленных
соответствующими ключами корневого узла (ROOT). Наименование Action в данном примере
– CONFIRM.
lo_srv_trq->do_action(
EXPORTING
iv_act_key
= lv_key_act
iv_key
= lt_key
* is_parameters = Параметры события если заданы
IMPORTING
eo_change
= lo_change
eo_message
= lo_message
et_failed_key = lt_failed_key ).

28.

Создание Action
раздел 2
1. Action предназначен для выполнения операций с узлами БО. Рассмотрим пример создания Action. Задача –
создание экземпляра узла BASIC (подчиненный узел REVISION) со специфическим заполнением данных при
вызове Action (заполнением поля BASIC_TEXT).
2. Для нового Action потребуется реализующий класс. При
создании класса используем стандартный суперкласс
/BOBF/CL_LIB_A_SUPERCLASS.
У созданного класса необходимо реализовать
метод /BOBF/IF_FRW_ACTION~EXECUTE. В
данном методе будет расположена основная
логика Action (Создание экземпляра узла
BASIC с заполненным полем BASIC_TEXT).
Код в методе будет рассмотрен подробнее
позже.
3. Также нам понадобится структура с параметрами
нового Action. Структуру ABAP словаря создаем
обычным образом (для нашего примера добавим в
структуру поле BASIC_TEXT).
4. Переходим в транзакцию BOBX. Переходим
в нужный БО, раскрываем дерево узлов БО,
жмем правой кнопкой по разделу Actions,
выбираем Create Action.

29.

Создание Action
раздел 2
5. Указываем наименование и описание Action. Указываем реализующий класс и структуру параметров Action.
Также необходимо указать Action Cardinality (0 – инстанции узла, для которого создается Action; 1 – для каждой
инстанции происходит отдельный вызов Action; 2 – возможна обработка сразу нескольких инстанций).
Exporting Parameter указывать необязательно, это необходимо в том случае, если этого требует архитектура
решения (для нашей задачи это не нужно). 1 – возвращает экземпляр узла; 2 – возвращает конкретный тип.

30.

Создание Action
раздел 2
6. Жмем кнопку «Check & Generate».
7. Чтобы проверить – в реализующем классе Action
необходимо установить внешнюю точку прерывая в
методе
/BOBF/IF_FRW_ACTION~EXECUTE.
Далее
переходим в транзакцию BOBT.
8. В транзакции создаем новый экземпляр ROOT,
далее по ассоциации переходим к узлу REVISION и
создаем его экземпляр.
9. Выделяем созданный экземпляр узла, жмем Execute
Action, выбираем созданный ранее Action. Указываем
параметры Action.
10. Видим, что дебаггер остановился на внешней
точке в реализующем классе Action. Все работает
корректно. Внизу видим сообщение об успешном
выполнении Action.
11. Возможно создание Action в транзакции BOB
средствами ассистента. Рассматривать такой пример не
будем в связи с тем, что в BOB Action создается с типом
READ_ONLY. Изменения в рамках такого Action не
фиксируются. Увидеть тип Action можно в транзакции
/BOBF/CONF_UI (2 – Exclusive Write Mode).

31.

Determinations
раздел 2
Существует два типа Determination: временный
и постоянный. Эта категоризация указывает,
изменит ли Determination постоянные или
временные данные соответствующего узла.
Determination в основном используется для
вычисления данных, которые должны быть
изменены на основе других данных.
Данные, при изменении которых происходит
вызов Determination и данные, которые
изменяются в рамках Determination могут
принадлежать как одному и тому же узлу, так и
разным узлам. Существуют также значения,
которые не зависят ни от каких других значений,
но должны определяться автоматически при
создании или изменении экземпляра узла
(например, идентификаторы).
Для
каждого
Determination
необходимо
указать,
какие
изменения
(создание,
обновление, удаление или чтение) и на каких
узлах произведут вызов Determination в
определенное
время
(Determination
вызывается в разные моменты времени,
например, After Modify, Before Save и т.п.)

32.

Время выполнения Determination
Время
исполнения
раздел 2
Пример использования
After Loading
Зависимые поля, которые не сохраняются (избыточные), должны быть пересчитаны.
Before Retrieve
Определение содержимого временных узлов перед их первым считыванием. После первого считывания экземпляра
узла Determination для этого времени выполнения не выполняются, так как изменения данных во время считывания
не допускаются.
After Modify
Пересчет полей, которые зависят от измененных полей. Это особенно полезно для производных полей извне,
требующих немедленного обновления.
After Validation
Этот момент времени можно использовать для изменения данных на основе результатов проверки консистентности
данных в рамках Determination и Validation. Типичный вариант использования — выполнение некоторых
последующих Action в зависимости от того, были ли сообщения об ошибках при проверке консистентности данных.
Before Save
(Finalize)
Определяет данные, которые не должны быть изменены до сохранения или для данных, которые не видны извне
(чтобы их определение можно было отложить до сохранения из соображений производительности).
Before Save
(Draw
Numbers)
Определяет данные, которые не должны быть изменены, пока транзакция не завершится успешно, но могут
использоваться другими бизнес-объектами. Типичным вариантом использования таких изменений является,
например, задание последовательности номеров для обеспечения нумерации без пропусков.
During Save
Определяет данные, которые не должны быть определены, пока транзакция не будет выполнены успешно.
Determination для этого времени выполнения будут выполняться не более одного раза в LUW.
After Commit
Определить данные после того, как транзакция была успешно завершена и произошел COMMIT данных. Типичным
вариантом использования этого времени выполнения является запуск асинхронных процессов.
After Failed
Save Attempt
Выполнение «откатов» изменений после того, как попытка сохранить транзакцию была отклонена на этапах
«Finalize» или «Check before Save». Determination инициируется только в том случае, если в рамках него были
запрошены экземпляры узлов и их данные были изменены.

33.

Создание determination
1. Рассмотрим пример создания детерминации. Задача – заполнять
поле статуса из постоянной структуры узла исходным значением
(Черновик) при создании нового экземпляра этого узла.
раздел 2
2. Для детерминации потребуется реализующий класс. При
создании
класса
используем
стандартный
суперкласс
/BOBF/CL_LIB_D_SUPERCL_SIMPLE.
3. Переходим в транзакцию BOBX.
4. Переходим в нужный БО, раскрываем дерево узлов БО, жмем
правой кнопкой по разделу Determinations, выбираем Create
Determination.
5. Указываем наименование детерминации, описание и
созданный ранее реализующий класс. Также указываем тип
детерминации (в нашем случае тип – P; P – работа с данными
постоянной структуры узла; T – работа с данными временной
структуры узла; A – работа с данными, необходимыми для
работоспособности BOPF).
6. Переходим на вкладку Trigger Conditions. Ставим
соответствующие галочки (в нашем случае детерминация должна
отрабатывать только при создании нового экземпляра узла
REVISION).

34.

Создание determination
7. Переходим на вкладку Evaluation Timepoints. Здесь необходимо
указать, в какой момент должна отработать данная детерминация (в
нашем случае указываем After Modify, т.к. детерминация должна
отработать сразу же в момент создания нового экземпляра узла).
раздел 2
8. В нашем случае во вкладке Determination Dependency нам
ничего указывать не нужно, т.к. у данной детерминации не будет
зависимостей от других детерминаций БО.
9. Жмем кнопку Check & Generate
10. Чтобы проверить – в реализующем классе детерминации необходимо установить внешнюю точку прерывая в методе
/BOBF/IF_FRW_DETERMINATION~EXECUTE. Далее переходим в транзакцию BOBT.
11. В транзакции создаем новый экземпляр ROOT, далее по
ассоциации переходим к узлу REVISION и создаем его экземпляр.
12. Видим, что дебаггер остановился на внешней точке в
реализующем классе детерминации. Все работает корректно.

35.

Создание determination
раздел 2
13. Рассмотрим пример создания еще одной детерминации. Задача – заполнять поле даты ревизии из постоянной структуры узла при
сохраненнии этого узла в том случае, если были изменены данные. На этот раз воспользуемся транзакцией BOB, в которой доступен
ассистент по созданию детерминаций.
14. Снова предварительно создаем реализующий класс для новой детерминации (описание смотри в пункте 2).
15. Открываем транзакцию BOB.
19. Заполняем наименование и описание детерминации.
16. Выбираем необходимый БО.
17. Выбираем узле, для которого необходимо добавить
детерминацию (в нашем случае узел REVISION).
18. Жмем правой кнопкой по узлу – выбираем «Создать
определение».
20. На следующем шаге указываем созданный ранее реализующий
класс.

36.

Создание determination
21. На следующем шаге выбираем подходящий нам вариант
настройки детерминации (Деривация зависимых данных перед
сохранением).
раздел 2
22. На следующем шаге указываем, при каких изменениях и
каких узлов необходим запуск детерминации.
23. На следующем шаге жмем «Завершить».
24.Детерминации создана, теперь необходимо перегенерировать интерфейс констант БО. Выбираем БО двойным щелчком. Жмем
«Перегенерировать».

37.

Создание determination
раздел 2
Иногда возникают некоторые аномалии, поэтому лучше дополнительно перегенерировать интерфейс констант в транзакции BOBX.
Переходим в транзакицию BOBX, выбираем необходимый БО, переходим в режим редактирования и жмем «Check & Generate»
(повторяем шаг 9).
25. Повторяем шаг 10 – 11. Далее жмем «Save». Видим, что при сохранении дебаггер остановился на внешней точке в реализующем
классе детерминации. Все работает корректно.
26. Таким образом, было рассмотрено 2 разных способа создания детерминаций.
Для создания детерминаций будет более предпочтительным использование транзакции BOBX, т.к. в ассистенте отсутствуют некоторые
гибкие настройки, которые доступны в BOBX уже в момент создания детерминации.

38.

раздел 2
Validations
• В результате выявленных ошибок при срабатывания проверки, мы должны увидеть ошибочное или
предупреждающее сообщение в объекте EO_MESSAGE и список ключей ошибочных node в таблице
ET_FAILED_KEY. Если проверка является новым Z-объектом, то использование описанных выше выходных
параметром является обязательным условием корректной работы проверки.
Validation Consistency
Validation on Action
o
позволяет проверять на непротиворечивость
весь бизнес-объект в зависимости от
добавленных, удаленных или измененных
данных текущего узла (на котором настроена
проверка).
o
может быть назначена action, специфичным
для объекта (созданные разработчиком), а
также
стандартным
action
создания,
обновления, удаления и сохранения.
o
можно настроить триггер запуска проверки
так, чтобы она срабатывала и для других
узлов в рамках текущего БО.
o
выполняется, до выполнения action. Если
некоторые проверки не пройдены, действие
не выполняется для экземпляров узлов, в
которых проверка не удалась.
o
имеет отличительную иконку в структуре
дерева БО
.
o
Имеет отличительную иконку в структуре
дерева БО
.

39.

Создание Validation
раздел 2
1. Validation предназначен для выполнения различных проверок в рамках БО. Рассмотрим пример создания Validation для созданного
ранее Action REV_CREATE_BASIC. Задача – проверить, имеется ли уже подузел BASIC у узла REVISION; если узел уже имеется – не
разрешать запуск Action.
2. Для детерминации потребуется
/BOBF/CL_LIB_V_SUPERCL_SIMPLE.
реализующий
класс.
При
создании
класса
используем
стандартный
суперкласс
У
созданного
класса
необходимо
реализовать
метод
/BOBF/IF_FRW_VALIDATION~EXECUTE. В данном методе будет
расположена основная логика Validation (проверка необходимости
создания экземпляра узла BASIC).
Код в методе будет рассмотрен подробнее позже.
3. Переходим в транзакцию BOBX.
4. Переходим в нужный БО, раскрываем дерево узлов БО, жмем правой кнопкой по разделу Validations, выбираем Create Validation, далее
Action Validation.
Отметим, что эту валидацию можно также создать при помощи транзакции BOB (подробнее
создание валидации в транзакции BOB рассмотрим примере создания Consistency Validation
ниже).
5. Указываем наименование Validation, описание и созданный ранее реализующий класс.

40.

Создание Validation
6. На вкладке Trigger Actions указываем Action, для которого
необходимо
запускать
проверку
(в
нашем
случае
REV_CREATE_BASIC).
9. В транзакции создаем новый экземпляр ROOT, далее по
ассоциации переходим к узлу REVISION и создаем его
экземпляр.
раздел 2
7. Жмем кнопку «Check & Generate».
8. Чтобы проверить – в реализующем классе валидации
необходимо установить внешнюю точку прерывая в
методе /BOBF/IF_FRW_ACTION~EXECUTE. Также для
рассматриваемого примера необходимо установить
внешнюю
точку
прерывая
в
методе
/BOBF/IF_FRW_ACTION~EXECUTE реализующего класса
Action REV_CREATE_BASIC. Далее переходим в
транзакцию BOBT.
10. Выделяем созданный экземпляр узла, жмем Execute
Action, выбираем созданный ранее Action. Указываем
параметры Action.

41.

Создание Validation
11. Видим, что дебаггер остановился сначала на внешней точке
в реализующем классе Validation и уже потом в реализующем
классе Action. Таким образом, если проверка в Validation
сообщит об ошибке – реализующий класс Action не будет
вызван, а BOPF вернет соответсвующее сообщение об ошибке.
Если же проверка завершена без ошибок (как в нашем случае),
BOPF вызовет реализующий класс Action. Все работает
корректно.
раздел 2
12. Рассмотрим пример создания еще одного Validation, та этот
раз это будет Consistency Validation. Задача – проверить, имеется
ли ошибки при сохранении узла BASIC, когда создается новый
экземпляр узла BASIC или обновляются данные на текущем; если
данные неверны – не разрешать сохранение.
13. Снова предварительно создаем реализующий класс для
новой Validation (описание смотри в пункте 2).
14. Открываем транзакцию BOB. Отметим, что подобную
валидацию можно также создать и в транзакции BOBX. Одно из
различий создания в BOB и BOBX будет рассмотрено ниже.
15. Выбираем необходимый БО.
16. Выбираем узел, для которого необходимо
детерминацию (в нашем случае узел BASIC).
17. Жмем правой кнопкой по узлу – выбираем «Создать
проверку непротиворечивости».
18. Указываем наименование и описание Validation.
добавить

42.

Создание Validation
19. На следующем шаге указываем реализующий класс
Validation.
раздел 2
20. Указываем, при каких изменениях на узле должна отрабатывать
валидация.
21. На следующем шаге отметим ключевое отличие создания валидации при помощи транзакции BOB.
Видим, что на этом шаге можно вернуть сообщение об ошибке, если
она возникает в Validation и запретить сохранение данных (наш
пример). Также можно вернуть сообщение об ошибке и допустить
сохранение.

43.

Создание Validation
22. На следующем шаге жмем «Завершить».
23. Детерминации создана, теперь необходимо перегенерировать
интерфейс констант БО. Выбираем БО двойным щелчком. Жмем
«Перегенерировать».
Иногда возникают некоторые аномалии, поэтому лучше
дополнительно
перегенерировать
интерфейс
констант
в
транзакции BOBX. Переходим в транзакицию BOBX, выбираем
необходимый БО, переходим в режим редактирования и жмем
«Check & Generate» (повторяем шаг 7).
24. Отметим, что момент проверки (при сохранении) необходимо
будет
обработать
при
помощи
кода
в
методе
/BOBF/IF_FRW_VALIDATION~EXECUTE реализующего класса
валидации. В нашем случае дебаггер упадет во внешнюю точку,
установленную в методе валидации, сразу при создании узла
BASIC, а также при любом изменении данных узла и в момент
сохранения.
25. Переходим в транзакцию BOBT.
раздел 2
26. В транзакции создаем новый экземпляр ROOT, далее по
ассоциации переходим к узлу REVISION и создаем его
экземпляр, у созданного экземпляра REVISION по
ассоциации переходим к узлу BASIC и создаем его
экземпляр.
27. Видим, что дебаггер падает во внешнюю точку при
создании данных BASIC, внесении изменений данных у узла
BASIC, а также при сохранении.

44.

раздел 2
Queries
Запросы являются начальной точкой доступа к бизнес-объектам. Запросы выполняют функции поиска по
бизнес-объекту для получения ключей или данных конкретных или всех экземпляров узла на котором и
реализован query. Query может иметь структуру поиска и результирующую структуру для вывода связанных
данных помимо найденных ключей.
BOBF Enhancement Workbench позволяет создавать новые запросы трех разных типов:
Тип query
Критерии ввода/
поиска
Результат
Реализация
класса
Node Attribute Query
Тип данных с атрибутами из
узла BO, которому назначен
запрос.
Список ключей экземпляров
узлов БО, соответствующих
критериям поиска (и данные
узлов этих экземпляров).
Не требуется
Custom Query
Произвольный тип данных с
атрибутами,
представляющими
критерии поиска.
Список ключей экземпляров
узлов БО, соответствующих
критериям поиска (и данные
узлов этих экземпляров).
Требуется
Custom Query (Generic
Result Query)
Произвольный тип данных с
атрибутами,
представляющими
критерии поиска.
Произвольный тип данных
результата и тип связанной
таблицы, представляющий
данные результата
Требуется

45.

раздел 2
Queries
o
Node Attribute Query
Параметры поиска соответствует структуре узла,
на котором создан запрос.
o
Критерии поиска могут состоять из сравнения
значений и диапазонов значений атрибутов
узлов.
o
Запрос возвращает экземпляры назначенного
узла (ключи), чьи атрибуты соответствуют
предоставленным параметрам поиска.
o
Такие запросы рекомендуются для всех случаев,
когда не требуется сложная логика запроса
(когда поиск осуществляется в рамках одного
узла).
o
В отличие от пользовательских запросов, Node
Attribute Query только моделируются и,
следовательно, не должны реализовываться
(они реализуются общим способом).
o
Custom Query
Такой тип Query осуществляет запрос, в котором
происходит специфичная для бизнес-процесса
логика (отличная от Node Attribute Query). Логика
работы такого Query реализована в специальном
ABAP классе.
o
Результат работы (структура данных Query) такого
Query может быть произвольным. То же самое
касается и критериев поиска такого Query.
o
Custom Query (Generic Result Query)
В дополнение к принципам Custom Query, результат
Generic Result Query может быть как произвольного
типа, так и ссылающимся на соответствующую
структуру.
o
Начиная с версии NetWeaver 7.31 Service Pack 06 (а
также NetWeaver 7.02 Service Pack 11) и выше BOPF
Enhancement Workbench позволяет создание таких
Query.
o
Ключевой особенностью такого Query является,
например,
присвоение
Query
узлу
ROOT.
Результатом же такого Query могут являться ключи
или экземпляры подчиненных ему узлов.

46.

Создание Query
раздел 2
1. Query предназначен для выбора данных БО. Рассмотрим пример создания Query. Задача – выбрать данные узлов ROOT, REVISION и
BASIC в рамках работы одного Query.
2. Для Query потребуется структура ABAP словаря для результата поиска
БО. В структуре необходимо указать поля и элементы данных (ЭД) в
соответствии с полями и ЭД данных, которые мы выбираем. Например,
на узле ROOT есть поле ID_INC_DEMO с ЭД ZEINC_DEMO_ROOT_ID. В
структуре укажем поле с аналогичным наименование и ЭД. Таким
образом, в нашей структуре результата Query будут следующие поля:
3. Для Query потребуется тип таблиц, основанный на
структуре результата Query. Создаем его также
средствами ABAP словаря (STANDARD TABLE WITH
NON-UNIQUE DEFAULT KEY).
4. Для Query потребуется структура ABAP словаря для критериев поиска. В структуре необходимо указать поля и элементы данных (ЭД)
в соответствии с полями и ЭД данных, которые мы выбираем (по аналогии с пунктом 2). Таким образом, в структуре критериев поиска
Query будут следующие поля:

47.

Создание Query
5. Для нового Query потребуется реализующий класс. При
создании класса используем стандартный суперкласс
CL_EHFND_Q_SEARCH. Пока не будет переопределять
необходимые
методы,
мы
рассмотрим
подробнее
некоторые из них в рамках другого раздела.
раздел 2
6. Переходим в транзакцию BOBX. Создавать Query будем на узле
ROOT (в целом, если создаются Query, в которых выбираются
данные нескольких узлов, лучше создавать такой Query на самом
«верхнем» узле).
7. Переходим в нужный БО, раскрываем дерево узлов БО, жмем
правой кнопкой по разделу Queries, выбираем Create Query.
8. Указываем наименование и описание Query, далее
указываем реализующий класс и структуру с критериями
поиска Query. Жмем Enter.

48.

Создание Query
9. Появляются поля для ввода структуры и типа
таблиц результата работы Query, заполняем их.
раздел 2
10. Жмем кнопку «Check & Generate».
11. Чтобы проверить – переходим в
транзакцию BOBT.
12. Жмем кнопку «Load Node
Instances», далее «By Query»,
далее выбираем наш новый Query.
13. Пока не указываем никакие критерии поиска, в
следующем окне просто жмем Enter. (Стоит отметить, что
BOBT отобразит строку с результатом только в том случае,
если хотя бы одно из полей будет заполнено данными).
Сравним результат работы Query с данными в таблице БД.
В нашем примере выбираемые данные в БД заполнены только на
узле ROOT и только у 4 записей (у трех заполнено поле
ID_INC_DEMO, у одной заполнено поле INC_TYPE).
Результат работы Query:
Все работает корректно. Отметим, что данные автоматически
заполнены в нужных полях результата поиска.

49.

Создание Query
14. Запустим Query второй раз, на этот раз укажем критерий
поиска ID_INC_DEMO = ‘00000000000000000001’. Перед
запуском Query в окне критериев поиска на критерии поиска
ID_INC_DEMO жмем «Open». Добавляем данные по аналогии с
селект-опцией.
.
раздел 2
17. Для данного примера не понадобится ничего предварительно
создавать, сразу открываем транзакцию BOB.
18. Выбираем необходимый БО.
19. Выбираем узле, для которого необходимо добавить Query (в
нашем случае узел REVISION).
Жмем Enter и запускаем Query.
15. Видим, что Query вернул только одну запись
по заданному критерию поиска.
20. Жмем правой кнопкой по узлу – выбираем
«Создать запрос».
16. Рассмотрим пример создания еще одного Query, но уже в
транзакции BOB. Ключевое отличие заключается в том, что при
помощи транзакции BOB можно создавать Query разных типов
(подробнее смотри в теоретическом разделе). Задача –
создать Query, который будет выбирать данные строго в
рамках одного узла (выборка данных такого Query отличается
от обычного, данные берутся из буфера BOPF конкретного
узла, лишних обращений к БД нет).

50.

Создание Query
21. В открывшемся ассистенте по созданию Query жмем
«Дальше».
раздел 2
24. Жмем «Завершить»
22. Указываем наименование и описание Query.
25. Query создан, теперь необходимо перегенерировать
интерфейс констант БО. Выбираем БО двойным щелчком. Жмем
«Перегенерировать».
23. Выбираем тип «Запрос атрибута узла».
Иногда возникают некоторые аномалии, поэтому лучше
дополнительно перегенерировать интерфейс констант в
транзакции BOBX. Переходим в транзакицию BOBX, выбираем
необходимый БО, переходим в режим редактирования и жмем
«Check & Generate» (повторяем шаг 10).

51.

Создание Query
раздел 2
26. Проверяем работу нового Query по аналогии с предыдущим примером.
Выборка всех данных без критериев поиска:
Выборка с критерием поиска STATUS = ‘01’:
Все работает корректно
27. Важно отметить, что введенные критерии поиска в Query работают строго как логическое «И». BOPF не предоставляет
возможности настроить простым способом работу критериев как логическое «ИЛИ».

52.

Associations
раздел 2
Ассоциации можно использовать для связи двух узлов в четко определенном направлении.
Ассоциацию можно использовать для перехода от одного узла (исходного узла) к
связанному узлу (целевому узлу). Связанные узлы могут быть узлами в одном бизнесобъекте или в разных бизнес-объектах (ассоциация между бизнес-объектами).
Ассоциации могут иметь параметры для фильтрации результатов связанных узлов. Они
могут быть определены только между двумя узлами и в одном определенном направлении.
Кроме того, они имеют определенную мощность, которая дает информацию о
существовании ассоциации и количестве связанных узлов.
Мощность ассоциации (association cardinality) определяет максимальное количество
экземпляров целевого узла, на которые влияет связь между двумя узлами. В зависимости от
мощности ассоциации система возвращает определенное количество экземпляров при
отслеживании ассоциации.
Технически ассоциация представляет собой реализацию класса результатом которого
является таблица мепинга ключей исходного узла к ключам целевого узла.

53.

Основные свойства Association
Cardinality:
1:0...1 Существует один или ни одного целевого экземпляра
• Соответствует 1 в свойствах ассоциаций
1:1
Существует ровно один целевой экземпляр
• Соответствует 2 в свойствах ассоциаций
1:0...n Нет или много целевых экземпляров
• Соответствует 3 в свойствах ассоциации
1:1...n Существует один или несколько целевых экземпляров
• Соответствует 4 в свойствах ассоциации
Resolving node:
Ассоциации разрешаемые источником
• Исходный узел содержит информацию, необходимую для разрешения ассоциации. Соответствует 0 в свойствах
ассоциации
Ассоциации с разрешением цели
• Целевой узел содержит информацию, необходимую для разрешения ассоциации. Соответствует 1 в свойствах
ассоциации
Association binding:
Позволяет явно задать условие мепинга узлов без реализации класса ассоциации
• Необходимо на одноименной вкладке задать поле целевого узла, условие, поле исходного узла
раздел 2

54.

Создание Associations
раздел 2
Давайте создадим ассоциацию для получения текущего узла revision. Назовем ассоциацию current_revision.
1. Добавим для этого поле версии в постоянную структуру REVISION.
2. Далее проставим в BOBT версии вручную. Для наглядности заполним поле DESC_TEXT.
3. Создадим класс ассоциации.

55.

Создание Associations
раздел 2
4. Реализуем метод RESOLVE. Суть метода заключается в том, что мы читаем все возможные версии и оставляем
только одну с максимальной версией.
5. Прописываем наш класс в ассоциацию
6. Чтобы убедиться в корректности проверим результат в
BOBT. При переходе по новой ассоциации видим, что
результат выдает только одну строку с версией = 2

56.

Работа с BOBT
раздел 2
1. Открываем транзакцию BOBT. Транзакция предназначена для тестирования функциональности БО. По большому счету она эмулирует
Service Manager BOPF.
2. В данном окне указываем наименования БО, которое хотим протестировать, жмем Enter.
3. Предварительно во всех нужных местах, относящихся к логике БО можно поставить внешние точки останова (детерминации, Query и
т.д.). Для начала нужно считать данные необходимых узлов. Сделать это можно либо с помощью Query, либо с помощью ввода
конкретного ключа экземпляра узла (если он известен). Для этого жмем кнопку «Load Node Instances» и выбираем нужный вариант
4. В левой части появляется дерево ключей загруженных экземпляров узлов. Правее расположены данные.

57.

Работа с BOBT
5. Выше данных расположены кнопки, при помощи которых можно
оперировать
загруженными
данными
(добавлять
новые
экземпляры, менять и удалять существующие, запускать Action
для выбранных инстанций и т.п.).
раздел 2
6. Можем выделить запись, нажать кнопку «Test Edit», поменять в
нижней области данные узла и нажать Enter. Данные изменятся.
7. Для перехода к подузлу воспользуемся деревом объектов.
Выбираем нужную ассоциацию двойным щелчком. После этого
загрузятся инстанции подузла (если они существуют).
8. При нажатии кнопки «Save» вызывается событие
сохранения всех изменений, произведенных в рамках БО.

58.

Практическое задание
раздел 2
• Предлагаю вам доработать созданный вами БО в первом разделе.
• Ниже описаны элементы узлов, которые нужно добавить. Необходимо создать только сами элементы.
Реализовать вы их сможете только после третьего раздела.
ROOT:
Тип
Наименование
Описание
Пояснения
Детерминация
ROOT_DRAW_ID
Получить ID
Унаследовать CL_EHFND_D_DRAW_ID и реализовать метод
GET_NAME_NUM_RANGE_OBJ. В методе прописать свой диапазон номеров
Детерминация
ROOT_FILL_DOWN_LOC
Нижестоящие МПЛ
Наследовать класс /BOBF/CL_LIB_D_SUPERCL_SIMPLE. Категория: T.
Подобрать параметры запуска при загрузке текущего МПЛ .
Query
SELECT_Q_DLOC_ELEM
Поиск МПЛ
Не требует реализации.
Query
SELECT_Q_DLOC_ENTRY
Поиск МПЛ c
условием
Реализация в задании третьего раздела.
Тип
Наименование
Описание
Пояснения
Детерминация
BSINF_SET_ATTR
Заполнить
временные
атрибуты
Наследовать класс /BOBF/CL_LIB_D_SUPERCL_SIMPLE. Категория: T. Trigger
Conditions: create, update, load. Evaluation timepoints: after loading, after modify.
Событие
BSINF_SET_INN
Сменить ИНН
Наследовать класс /BOBF/CL_LIB_A_SUPERCLASS. Добавить структуру с
входящим параметром ИНН.
Валидация по
действию
BSINF_CHECK_INN
Проверка ИНН
Наследовать класс /BOBF/CL_LIB_V_SUPERCL_SIMPLE. Настроить при
вызове BSINF_SET_INN.
Ассоциация
BSINF_DINC_BASIC
Ассоциация
Создать ассоциацию к ZINC_DEMO->BASIC. Добавить класс ( наследует
/BOBF/CL_LIB_C_SUPERCLASS ).
Тип
Наименование
Описание
Пояснения
Детерминация
BSINF_SET_ATTR
Заполнить
временные
атрибуты
Наследовать класс /BOBF/CL_LIB_D_SUPERCL_SIMPLE. Категория: T. Trigger
Conditions: create, update, load. Evaluation timepoints: after loading, after modify.
Валидация
консистентная
RESP_CHECK_DUPL
Проверка
уникальности
Наследовать класс /BOBF/CL_LIB_V_SUPERCL_SIMPLE. Проверка
уникальных имен.
BSINF:
RESP:

59.

Раздел 2
Спасибо за внимание.
Вопросы?

60.

Раздел 3
В этом разделе будут рассмотрены следующие темы:
Менеджеры / инструменты
стандартных БО
• транзакционная модель
• чтение данных
• чтение данных. query
• изменение данных
• пользовательские сообщения
• проверка полномочий
• text collection
• создание программы ведения
• практическое задание

61.

Транзакционная модель
раздел 3
• Вы можете разделить обработку информации на неделимые единицы, называемые транзакциями. Все
изменения, сделанные во время транзакции, должны быть либо очищены, либо сохранены. Процесс обычно
состоит из нескольких последовательно выполняемых транзакций. Модель транзакций BOPF делит
выполняемые транзакции на несколько этапов.
Interaction Phase
Save Phase
Finalization
Check Before
Save
Save
Cleanup Phase
Interaction Phase
В начале транзакции пользователь может получить доступ
к произвольным бизнес-объектам с помощью набора
операций БО. Например, пользователь может запросить
определенный экземпляр карточки происшествия, а затем
запустить создание новой ревизии происшествия.
• Cleanup Phase
Пользователь может очистить текущую транзакцию. В этом
случае система отменяет все изменения, сделанные на
сегодняшний день в текущей транзакции.
Save Phase
Как только пользователь сохраняет текущую транзакцию,
фаза взаимодействия завершается и начинается фаза
сохранение. На этом этапе пользователь не может
вызывать основные службы. Сама фаза сохранения
разделена на следующие фазы.

62.

Транзакционная модель
o Finalization
На этапе завершения каждый
бизнес-объект, участвующий в
текущей транзакции, подготовлен к
фиксации в базе данных. Если
хотя бы один бизнес-объект
отклоняет эту финализацию, фаза
сохранения
прерывается,
и
транзакция возвращается к фазе
взаимодействия.
На
этапе
окончательной
обработки
выполняются
определения,
настроенные
в
шаблоне
Получение зависимых данных
перед сохранением.
o Check Before Save
На этом этапе каждый бизнесобъект, участвующий в текущей
транзакции, проверяется на
предмет можно спасти. Если
хотя бы один бизнес-объект
выходит
из
строя,
этап
сохранения прерывается, и
взаимодействие
фаза
начинается снова. На этом
этапе
все
проверки
непротиворечивости влияют на
получение зависимых данных.
перед сохранением.
раздел 3
o Save
На
этом
этапе
система
сохраняет
все
изменения
экземпляров бизнес-объектов в
базе
данных.
Кроме
того,
потребитель может очистить
текущую транзакцию. В этом
случае система отменяет все
изменения
сделано
на
сегодняшний день в текущей
транзакции.
После завершения вызовов основной службы пользователь может очистить или сохранить изменения, внесенные
в текущую транзакцию. В обоих случаях экземпляр диспетчера транзакций должен быть получен из класса
/BOBF/CL_TRA_TRANS_MGR_FACTORY=>GET_TRANSACTION_MANAGER.
После
этого
можно
вызвать
соответствующий метод экземпляра CLEANUP или SAVE. Службы транзакций, предлагаемые диспетчером
транзакций, не должны вызываться в реализациях сущностей. Только пользователь имеет право контролировать
транзакцию. В следующем примере показано, как сохранить транзакцию после завершения фазы взаимодействия.
DATA lo_transaction_manager TYPE REF TO /bobf/if_tra_transaction_mgr.
» начать фазу взаимодействия
…
» начать фазу сохранения
lo_transaction_manager = /bobf/cl_tra_trans_mgr_factory=>get_transaction_manager().
lo_transaction_manager->save().

63.

Чтение данных
раздел 3
Можно выделить несколько подходов и механизмов чтения данных из БО и узлов:
• Service Manager
Можно использовать повсеместно. Как в объектах БО, так и во внешних программах. Для реализации необходимо
получить инстанцию service manager для нужного ключа БО. Помним что, все необходимые константы связанные с
БО хранятся в интерфейсе констант.
DATA lo_tra_service_manager TYPE REF TO /bobf/if_tra_service_manager.
lo_tra_service_manager = /bobf/cl_tra_serv_mgr_factory=>get_service_manager( iv_bo_key = ZIF_INC_DEMO_C=>sc_bo_key ).
• QUERY
Наиболее правильный метод, для первичного получения
данных.
DATA:
lt_sel_parameters TYPE /bobf/t_frw_query_selparam,
lt_data type {тип результирующей таблицы}
lo_tra_service_manager ->query(
EXPORTING
iv_query_key
= ZIF_INC_DEMO_C =>sc_query-rootselect_entry
iv_fill_data
= abap_true
it_selection_parameters = lt_sel_parameters
IMPORTING
et_data
= lt_data ).
• RETRIEVE
Метод чтения узлов напрямую, когда есть db_key
lo_tra_service_manager->retrieve(
EXPORTING
iv_node
= zif_inc_demo_c=>sc_node-revision
it_key
= lt_rev_key
iv_fill_data
= abap_true
IMPORTING
et_data
= lt_basic
eo_message = eo_message
et_failed_key = et_failed_key ).

64.

Чтение данных
раздел 3
• RETRIEVE_BY_ASSOCIATION.
Метод чтения узлов напрямую через ассоциацию, когда нет db_key.
lo_tra_service_manager->retrieve_by_association(
EXPORTING
iv_node_key = zif_inc_demo_c=>sc_node-revision
it_key
= lt_rev_key
iv_association = zif_inc_demo_c=>sc_association-revision-basic
iv_edit_mode = /bobf/if_conf_c=>sc_edit_read_only
iv_fill_data
= abap_true
IMPORTING
et_data
= lt_basic
eo_message = eo_message
et_failed_key = et_failed_key ).
• CL_EHFND_ENA_NODE
Можно получить интересующую вас node. И уже используя ассоциации проходиться по иерархии БО и получать
инстанцию каждого узла.
DATA(lo_root_node) = lo_tra_service_manager->get_root_single(
EXPORTING
iv_key = iv_key
iv_edit_mode = /bobf/if_conf_c=>sc_edit_exclusive ).
lr_s_root ?= lo_root_node->get_row( 1 ).
DATA(lo_rev_node) = lo_root_node->get_node_by_assoc(
EXPORTING
iv_assoc_key = zif_inc_demo_c=>sc_association-root-current_revision ).
lo_rev_node->reset_index( ).
WHILE lo_rev_node->has_more_rows( ).
lr_s_rev ?= lo_rev_node->get_next_row( ).
…
ENDWHILE.

65.

Чтение данных
раздел 3
• IO_READ
Интерфейс для чтения данных.
Такой интерфейс присутствует во всех элементах узлов (описанных во втором разделе). Позволяет без
дополнительных манипуляций считывать данные. Методы прямого чтения или чтения по ассоциации аналогичные
вызываемым через service manager. Сам объект io_read имеет ограниченный набор методов.
io_read->retrieve_by_association(
EXPORTING
it_key
= it_key
iv_node
= is_ctx-node_key
iv_association = zif_inc_demo_c=>sc_association-root-basic
IMPORTING
et_target_key = DATA(lt_basic_key)
eo_message = eo_message
et_failed_key = et_failed_key ).
• ACTION
Использование событий с выходными параметрами.
Желательно проверить перед вызовом, может ли быть выполнено действие бизнес-объекта. Вызвать событие можно как из
под объектов node, используя io_modify (do_action), так и через service_manager (do_action)

66.

Чтение данных. Query
раздел 3
• Использование query обычно нужно для поиска данных в целевых БО. Оно дает возможность гибко на стороне
целевого БО получать необходимые данные в нужном виде. Т.е. по сути это аналогия инкапсуляции в ООП.
Обработка данных БО храниться только в самом БО. Все запросы из вне обрабатываются на уровне целевого
БО.
• Query работает по принципу пересечения. Т.е. если в условии заданы данные из трех узлов(таблиц), то по факту
будет выполнено 3 разных select по каждой таблице. Искаться будет всегда ROOT_KEY. Далее после каждого
запроса анализируются пересечения между полученными данными(ROOT_KEY) и остаются ключи которые был
найдены в каждом из запросов.
• Давайте рассмотрим более детально, что из себя представляет QUERY и его возможности. Рассмотрим на
примере custom query.
• Как вы помните для custom query требуется реализовать класс обработчик. Рассмотрим основные методы такого
класса:
Метод
Пояснение
/BOBF/IF_FRW_QUERY~QUERY
Запускает query
MODIFY_SEARCH_PARAMETERS
Изменение критериев поиска. Изменение параметра CT_PARAMETERS
PREPARE_SEARCH_PARAMETERS
Подготовка параметров поиска. Динамически формируется строка с условием
для поиска исходя из переданных условий.
PROVIDE_TABLE_DEF_HINTS
Возвращает все соответствия полей. Т.е. происходит объявление какое поле
поиска соответствует какому полю БД.
GENERATE_RESULT
Обработка полученного результата. Можно выбрать данные, которые
необходимо предоставить в результатах query.
SEARCH
Запуск процесса поиска. Внутри представляет из себя цикл по таблицам поиска.
PERFORM_SELECT
Выполнение динамического SQL запроса. Поля выбора, источник выбора и
условие задаются входящим параметрами метода.
MODIFY_RESULT_KEYS
Изменение найденных ключей результата. Запускается после каждого запроса.

67.

Изменение данных
раздел 3
Можно выделить несколько подходов и механизмов изменения данных из БО и узлов:
• Service Manager
Можно использовать повсеместно. Как в объектах БО, так и во внешних программах. Для реализации
необходимо получить инстанцию service manager для нужного ключа БО. Помним что, все необходимые
константы связанные с БО хранятся в интерфейсе констант.
DATA lo_tra_service_manager TYPE REF TO /bobf/if_tra_service_manager.
lo_tra_service_manager = /bobf/cl_tra_serv_mgr_factory=>get_service_manager( iv_bo_key = ZIF_INC_DEMO_C=>sc_bo_key ).
DATA lt_mod TYPE /BOBF/T_FRW_MODIFICATION.
APPEND INITIAL LINE TO lt_mod ASSIGNING FIELD-SYMBOL(<ls_mod>).
<ls_mod>-NODE
= ZIF_INC_DEMO_C =>SC_NODE-BASIC.
<ls_mod>-KEY
= /BOBF/CL_FRW_FACTORY=>GET_NEW_KEY( ).
<ls_mod>-DATA
= lr_data
<ls_mod>-CHANGE_MODE = 'C'.
*<ls_mod>-NODE_CAT
*<ls_mod>-CHANGED_FIELDS
*<ls_mod>-ASSOCIATION
*<ls_mod>-SOURCE_NODE
*<ls_mod>-SOURCE_KEY
*<ls_mod>-ROOT_KEY
lo_tra_service_manager_rtn->modify(
EXPORTING
it_modification = lt_mod
IMPORTING
EO_CHANGE
= lo_chng
EO_MESSAGE
= lo_msg ).

68.

Изменение данных
раздел 3
• IO_MODIFY
Интерфейс для изменения данных.
Такой интерфейс присутствует во всех элементах узлов, которые архитектурно могут изменять данные. А именно
determination и action. Объект io_modify имеет методы CREATE, UPDATE, DELETE. Так же есть метод DO_MODIFY,
который по сути объединяет все три метода. На вход подается таблица с модификацией по аналогии с описанным
выше методом и указывается тип изменений. Так же io_modify позволяет вызвать событие (do_action), в котором
так же может быть прописана логика для изменения данных БО.
• CL_EHFND_ENA_NODE
Позволяет изменять данные в объекте полученной ранее node. Чтение node мы рассматривали выше. Разница в
том, что после считывания данных, мы можем сразу изменить интересующие данные и запустить один из методов
на изменение. После вызова транзакционного commit, все изменения (если нет противоречий) зафиксируются в
БД. Можно выделить основные методы: insert, update, delete.
DATA(lo_root_node) = lo_tra_service_manager->get_root_single(
EXPORTING
iv_key = iv_key
iv_edit_mode = /bobf/if_conf_c=>sc_edit_exclusive ).
lr_s_root ?= lo_root_node->get_row( 1 ).
DATA(lo_rev_node) = lo_root_node->get_node_by_assoc(
EXPORTING
iv_assoc_key = zif_inc_demo_c=>sc_association-root-current_revision ).
lo_rev_node->reset_index( ).
WHILE lo_rev_node->has_more_rows( ).
lr_s_rev ?= lo_rev_node->get_next_row( ).
* манипуляции с данными
lo_rev_node-> update(ls_s_rev).
ENDWHILE.

69.

Пользовательские сообщения
раздел 3
• Большинство основных служб возвращают пользователю объект сообщения (EO_MESSAGE), который содержит
сообщения, созданные исполняемыми объектами BOPF. Чтобы использовать их, должны применяться
следующие атрибуты сообщений:
o В зависимости от времени жизни, срок действия сообщения либо ограничивается текущим вызовом службы
(lifetime transaction), либо продолжается до тех пор, пока несоответствие не будет исправлено (lifetime state).
o Серьезность сообщения выражается серьезностью сообщения. Он подразделяется на ошибку, предупреждение
и информацию.
o Местоположение источника определяет, к какому экземпляру относится сообщение.
o Ниже представлен пример по добавлению сообщения в EO_MESSAGE. Экземпляр объекта сообщений если он
пуст, должен быть получен из класса /BOBF/CL_FRW_FACTORY. Входными параметрами для добавления
сообщения являются: класс, идентификатор и номер сообщения. А так же ключ узла (из интерфейса констант
БО) на которой для которой нужно вывести сообщение и ключ записи в узле.
DATA eo_message TYPE REF TO /BOBF/IF_FRW_MESSAGE.
eo_message = /bobf/cl_frw_factory=>get_message( ).
eo_message->add_message( is_msg = VALUE #( msgty = sy-msgty
msgid = sy-msgid
msgno = sy-msgno )
iv_node = node_key
iv_key = data_key ).

70.

Проверка полномочий
раздел 3
• В концепции авторизации и ролей SAP можно проверить, разрешено ли пользователю выполнять определенную
деятельность в целом, или проверить, разрешено ли пользователю манипулировать определенными данными.
• Условно можно разбить на два вида проверок. Первая проверка статическая. Поскольку она не зависит от
конкретных значений данных. Вторая проверка экземплярная. Так как результат проверки зависит от данных
конкретного узла: пользователю может быть разрешено работать с происшествиями своего делового партнера,
но не с деловыми партнерами его коллег.
• Оба типа проверок поддерживаются BOPF одним и тем же объектом авторизации. Он просто должен содержать
предопределенные поля авторизации ACTVT и BO_SERVICE. Эти поля используются для статических проверок
и проверок на основе экземпляров. В случае проверок на основе экземпляров вам необходимо определить поля
для проверяемых значений. В нашем примере это тип происшествия.
• В таблице представлен обзор того, как методы службы BO связаны с полями авторизации ACTVT и
BO_SERVICE. Например, если пользователь запускает метод MODIFY своим пользовательским вводом,
платформа проверяет разрешения для операций создания, изменения и удаления. Если он хочет выполнить
действие, система проверяет разрешения для полей ACTVT с выполнением действия и BO_SERVICE с именем
действия.

71.

Проверка полномочий
раздел 3
БО метод
Поле ACTVT
CHECK_ACTION
DISPLAY (03)
CHECK_AND_DETERMINE
CHANGE (02)
CHECK_CONSISTENCY
CHECK (39)
CONVERT_ALTERN_KEY
DISPLAY (03)
DO_ACTION
EXECUTE (16)
MODIFY
CREATE/CHANGE/DELETE
(01/02/06)
RETRIEVE
DISPLAY (02)
RETRIEVE_BY_ASSOCIATION
DISPLAY (02)
RETRIEVE_CODE_VALUE_SET
DISPLAY (02)
RETRIEVE_DEFAULT_ACTION_PA
RAM
DISPLAY (02)
RETRIEVE_DEFAULT_NODE_VAL
UES
DISPLAY (02)
RETRIEVE_DEFAULT_QUERY_PA
RAM
DISPLAY (02)
RETRIEVE_PROPERTY
DISPLAY (02)
QUERY
QUERY
BO_SERVICE
<action_name>
<query_name>

72.

Проверка полномочий
раздел 3
Рассмотрим основные шаги создания авторизации БО.
1. Необходимо в SU20 (определение полей полномочий) и в SU21 (определения объектов полномочий) создать поле и объект полномочий
соответственно. Создадим поле ZDEMO_INCT (тип происшествия) и объект полномочий Z_DEMO_INC. Далее необходимо назначить поля
авторизации ACTVT, BO_SERVICE и ZDEMO_INCT в наш объект блокировки ZDEMO_EINC.
2. Далее необходимо назначить объект полномочий бизнес объекту и сопоставить поля. Объекты авторизации назначаются узлу —
обычно корневому узлу, но это зависит от ваших бизнес-требований. Каждому узлу можно присвоить объекты авторизации. Если вы
назначаете объект авторизации узлу, он применяется ко всему поддереву, если нет другого назначения дочернему узлу. Встроенные
авторизации — это расширенная функция, которую нельзя определить в транзакции BOB, но необходимо использовать транзакцию
BOBX. Так же необходимо установить флажок “Бизнес-объект имеет проверки авторизации”. Этот флаг включает проверки авторизации.

73.

Проверка полномочий
3. Назначим объект авторизации корневому узлу Выберите
корневой узел и установите флажок У узла есть собственные
проверки.
Система
предложит
класс
библиотеки
/BOBF/CL_LIB_AUTHORITY_CHECK, примите его. Сохраните
определение.
раздел 3
4. В панели навигации выберите папку Объекты авторизации и в
контекстном меню выберите функцию Назначить объект
авторизации. Введите ZDEMO_EINC в качестве объекта
авторизации для BO и сохраните определение.
5. Далее мы можем связать поля объекта авторизации с полями BO. Это необходимо для вызова проверки авторизации с правильными
данными узла во время выполнения. Поля ACTVT и BO_SERVICE сопоставляются автоматически. Фреймворк использует это назначение
для статических проверок. Вам нужно только сопоставить поля, определенные вами для проверок на основе экземпляров. Выберите
«Сопоставление полей авторизации» на панели навигации и выберите «Создать сопоставление полей авторизации» в контекстном меню.
Выберите объект авторизации ZDEMO_EINC в раскрывающемся списке для Объекта авторизации для BO и поле ZDEMO_INCT в
раскрывающемся списке для Поле авторизации для BO. Выберите тип происшествия INC_TYPE, элемент постоянной структуры
корневого узла, в качестве целевого атрибута. Сохраните определение.

74.

Проверка полномочий
раздел 3
Также можно следить за ассоциацией. Это полезно для определения проверок авторизации с атрибутами другого узла — например,
для проверки того, что пользователям разрешено отображать коммерческие предложения только деловых партнеров в определенном
регионе. Регион является атрибутом делового партнера, а не корневого узла коммерческого предложения.
Проверки авторизации выполняются фреймворком. Далее рассмотрим как BO связан с профилем пользователя. Поведение во время
выполнения зависит от профиля пользователя.
Если пользователю не назначена роль или профиль, у пользователя нет полномочий для BO. Таким образом, любое действие
останавливается с сообщением об ошибке, например, «Нет полномочий для отображения происшествия».
В зависимости от профиля пользователя, пользовать может к примеру видеть происшествия только производственные или только
экологические или оба, в зависимости от настройки.
На уровне BOPF Runtime были реализованы различные стратегии по оптимизации: основная заключается в сокращении времени
чтения данных за счет их буферизации. Также были реализованы определенные соответствия групп проверок, при помощи которых
одни и те же данные экземпляров БО проверяются только один раз. Помимо этого, стандартная реализация предполагает в первую
очередь проверку доступа к тем или иным операциям. Таким образом, выполнение различных запросов и чтение данных происходит
строго после проверок полномочий, относящихся к этим данным и операциям. Проверки полномочий для одних и тех же данных также
выполняются только один раз.
• Так же существует вариант(облегченный) добавление проверок полномочий, без явного мэпинга полей. Чтобы его реализовать нужно:
1. Создать детерминацию CHK_AUTH с категорией С (Authority Check). Создать и прописать класс реализации на основе классе
CL_EHFND_V_D_AUTH_PROP (класс для EHSM).
2. На вкладке Trigger Conditions поставить галку на LOAD. На вкладке Evaluation Timepoints проставить галку на AFTER_LOADING.
3. Реализовать метод GET_AUTHORITY_DATA.
4. Создать валидацию CHK_AUTH с категорией 1 (Action Check) с таким же классом реализации.

75.

раздел 3
Text collection
Предназначается для ведения длинных текстов, длина которые как правильно превышает 255
символов.
Суть работы длинных текстов заключается в хранение текстов в стороннем БО. Данный БО
представляет готовый инструмент для ведения текста на стороне BOBF.
DESC_KEY_REF
Взаимодействие БО длинных текстов организовано на основании двух детерминаций:
DESC_TEXT
DESC_KEY
o
Так же необходимо добавить делегированный подузел для узла в котором планируется вести текст.
Делегированный подузел должен основываться на БО EHFND_TEXT_COLLECTION основанный на
/BOBF/TEXT_COLLECTION
Нужно добавить поля в постоянную и временную структуры с определенным наименованием {имя
делегированного узла после ‘_’ }{ варианты описанные ниже }. Нужно это для динамического
определения соответствия полей узла и text collection стандартными классами. В частности такой
механизм используют стандартные классы для детерминации (указанные выше)
Нужно добавить поля в постоянную и временную структуры с определенным наименованием {имя
делегированного узла}{варианты описанные ниже}. Нужно это для динамического определения
соответствия полей узла и text collection. В частности такой механизм используют стандартные классы
для детерминации (указанные выше)
DESC
READ_TEXT
READ_TEXT
WRITE – для записи текста в text collection. Существует стандартный класс
реализации
CL_EHFND_D_TXC_READ. При чтении узла детерминации по полю *_key_ref определяет root
коллекции и далее работают внутренние механизмы для получения текста.
o
READ – для чтения текста из text collection. Существует стандартный класс реализации
CL_EHFND_D_TXC_WRITE. При записи узла создается инстанция узла ROOT text collection и её
DB_KEY сохраняется в поле *_key_ref.
NODE
WRITE_TEXT
Пользовательский БО
/BOBF/TEXT_COLLECTION
ROOT
TEXT
Поле
Структура
Описание
*_KEY_REF
Постоянная
Хранятся root ключи БО длинных текстов
*_KEY
Временная
Динамически определяется DB_KEY узла TEXT БО длинных текстов
*_TEXT
Временная
Динамически определяется TEXT узла TEXT_CONTENT БО длинных текстов
TEXT_CONTENT

76.

раздел 3
Text collection
Ниже представлены шаги для добавления длинного текста для узла REVISION БО ZINC_DEMO.
1. Добавим поля в постоянную и временную структуры
2. Добавим делегированный узел и детерминации для
чтения и записи на узел REVISION
3. Детерминация на чтение имеет категорию P, так как осуществляет
работы с постоянными данными
4. Детерминация на запись имеет категорию Т, так как
осуществляет работы с временными данными

77.

раздел 3
Text collection
5. Далее можно проверить будут ли работать наш длинный текст
используя BOBT. Для этого перейдем в revision и наберем текст в
поле DESC_TEXT. Далее нажмем сохранить.
6. Чтобы убедиться, что текст сохранился посмотри на таблицу
узла REVISION. Видим что в поле DESC_KEY_REF добавился
ключ.
Ключ добавленный в поле DESC_KEY_REF является ROOT_KEY в
таблице text_collection /BOBF/D_TXCROOT.
Сам текст можем
/BOBF/D_TXCCON.
увидеть
в
таблице
text_collection

78.

Создание программы ведения
Далее представлен пример программы ведения БО с некоторым наиболее распространенными кейсами.
раздел 3

79.

Создание программы ведения
Подпрограмма чтения БО по введенному ключу ROOT.
раздел 3
Создание нового экземпляра БО (создание узла ROOT)

80.

Создание программы ведения
Подпрограмма изменения статуса карточки.
раздел 3

81.

Практическое задание
раздел 3
• Предлагаю вам реализовать созданные во втором разделе объекты в БО.
• Ниже описаны требования к реализациям.
ROOT:
Тип
Наименование
Описание
Пояснения
Детерминация
ROOT_FILL_DOWN_LOC
Нижестоящие МПЛ
Реализовать поиск через вызов query всех нижестоящих местоположений. И
заполнить временный узел LOC_CHILD всеми найденными
местоположениями.
Query
SELECT_Q_DLOC_ENTRY
Поиск МПЛ c
условием
Реализовать поиск МПЛ по следующим фильтрам: ROOT-ID, ROOTLOC_PARENT, BSINF-INN, BSINF-CC, RESP-PERSON. В результатах
выводить все поля всех узлов. В том числе и ZINC_DEMO->BASIC используя
ассоциацию BSINF_DINC_BASIC.
Тип
Наименование
Описание
Пояснения
Детерминация
BSINF_SET_ATTR
Заполнить
временные
атрибуты
Реализовать заполнение временных атрибутов
Событие
BSINF_SET_INN
Сменить ИНН
Реализовать изменение поля INN на в значение входящего параметра.
Проверить реализацию через BOBT.
Валидация по
действию
BSINF_CHECK_INN
Проверка ИНН
Реализовать проверку поля INN. Проверять новое значение на наличие не
числовых значений. В случае успеха выдавать ошибку типа E.
Ассоциация
BSINF_DINC_BASIC
Ассоциация
Реализовать ассоциацию к узлу ZINC_DEMO->BASIC. Сделать ограничение
внутри ассоциации, чтобы мэпинг происходил только с происшествием с
текущим статусом = ‘01’ (Активно).
Тип
Наименование
Описание
Пояснения
Детерминация
BSINF_SET_ATTR
Заполнить
временные
атрибуты
Реализовать заполнение временных атрибутов
Валидация
консистентная
RESP_CHECK_DUPL
Проверка
уникальности
Реализовать проверку на уникальные значения в поле person. В случае
нахождения повторяющихся выдавать ошибку с типом E.
BSINF:
RESP:

82.

Раздел 3
Спасибо за внимание.
Вопросы?

83.

Оглавление
Введение в BOPF
• что такое бизнес объект
BOPF ?
• архитектура BOPF
• business application
• модель BOPF
• группы БО в модели BOPF
• расширения BOPF
• модель БО
• модель данных узла
• метаданные
• транзакции ведения БО
• новый БО
• добавление узлов
• практическое задание
Элементы узлов и
механизмы
взаимодействия
• основные элементы БО
• actions
• создание action
• determinations
• время выполнения
determination
• создание determination
• validations
• создание validation
• queries
• создание query
• associations
• основные свойства
association
• создание association
• работа с BOBT
• практическое задание
Менеджеры /
инструменты
стандартных БО
• транзакционная модель
• чтение данных
• чтение данных. query
• изменение данных
• пользовательские сообщения
• проверка полномочий
• text collection
• создание программы ведения
• практическое задание