В языке АВАР/4 для обеспечения непротиворечивости данных в сложных приложениях принята концепция сложной транзакции, не зависящая от используемой СУБД. Например, если в туристическом агентстве бронируются места на авиарейс, то должна быть уверенность в том, что клиент получит в день отправления посадочный талон. С другой стороны, если все места забронированы, сотрудник туристического агентства должен сообщить клиенту, на какой рейс он может заказать билет. Очень важно, чтобы другие агентства, занимающиеся бронированием мест на тот же самый рейс, имели правильную информацию о числе свободных мест на момент заказа. Это позволит избежать бронирования одних и тех же мест различными агентствами.

Под транзакцией понимается диалоговая программа (использующая один или более экранов), которая изменяет объекты в базе, сохраняя при этом непротиворечивость данных. Программная логика транзакции может быть разделена на один или несколько логических рабочих блоков (Logical Units of Work, LUW). При возникновении ошибки все изменения в пределах текущего LUW отменяются, в результате содержимое таблиц базы данных всегда остается непротиворечивым. Механизмы блокировки транзакций гарантируют, что в каждый момент времени только один пользователь может изменять некоторый объект данных. Блокировки устанавливаются или отменяются с помощью стандартных функций, которые АВАР/4 Development Workbench создает автоматически. Срок действия блокировки ограничивается одним LUW.

С помощью АВАР/4 Development Workbench можно создавать транзакции, работающие в распределенных средах клиент/сервер. Часто самым "узким" местом в системе является сервер базы данных. Update Task — специальное задание по изменению данных — позволяет минимизировать время ответа для всех диалоговых программ и гарантирует непротиворечивость данных. Концепция транзакции и использование рабочих логических блоков (LUW) — подход, хорошо известный среди разработчиков и пользователей. Подчеркнем, что система R/3 поддерживает различные СУБД и имеет трехуровневую архитектуру, поэтому в АВАР/4 реализованы специальный механизм блокировки и концепция LUW, отличная от общепринятой.

Логический рабочий блок (LUW)

В примере программы бронирования мест (см. главу 19) предприняты некоторые меры, гарантирующие целостность данных. Например, проверка таблиц не позволяет забронировать места на несуществующие авиарейсы. Кроме того, отдельная подпрограмма проверяет наличие достаточного количества свободных мест. Если два (или более) туристических агентства одновременно используют эту программу бронирования, то возможна ситуация бронирования сверхнормативного числа мест. Во избежание такого нарушения непротиворечивости данных можно использовать механизмы блокировки АВАР/4 Development Workbench.

Механизм блокировки системы R/3

Для блокировки объекта можно вызвать стандартную функцию, создающую специальную запись (так называемый элемент блокировки) в глобальной системной таблице. Блокировка снимается при вызове другой стандартной функции или при инициализации системного разрешения на снятие блокировки по концу транзакции. Если пользователь пытается блокировать уже заблокированный объект, то функция блокировки возвращает исключение. Фактически, механизм блокировки определяет LUW. Начало LUW соответствует созданию записи блокировки (элемента блокировки) в системной таблице, а конец — снятию блокировки,

Механизм блокировки R/3 распространяется на все поддерживаемые системой базы данных. Разработчик может свободно определять блокируемые объекты, не заботясь об организации данных в таблицах базы. В отличие от R/3, многие СУБД блокируют весь набор записей таблицы, хотя достаточно заблокировать отдельную запись. Следствием этого являются ситуации, когда конечный пользователь не может получить доступ к объекту базы, так как должен ждать завершения блокировки. Иногда это приводит к тупиковым взаимным блокировкам. Данные проблемы разрешаются путем блокирования небольшого объема данных с помощью механизма блокировки R/3.

Система R/3 рассчитана на многопользовательские приложения (до нескольких тысяч пользователей), поэтому она должна уметь распределять общие ресурсы между ними. Очевидно, что к таким ресурсам относится и база данных. Множество реальных пользователей R/3 должно отображаться на единственного "пользователя" базы данных, а фактическое обновление данных должно происходить каждый раз при передаче экрана одному из пользователей R/3. Другими словами, LUW системы R/3 состоит из одного или нескольких LUW базы данных. Для того чтобы гарантировать непротиворечивость данных приложения, зсе изменения в базе должны выполняться в пределах одного LUW базы данных. Для этого допускается использование одного из двух способов организации выполнения транзакции:

Рис. 21.3

Определение транзакции

кий поясняющий текст, имя программы и номер начального экрана, отображаемого при вызове данной транзакции.

Кроме диалогового типа, средства Development Workbench поддерживают и другие типы транзакций. Например, транзакция отчета (Report Transaction) осуществляет запуск отчетов, которые используют стандартный экран выбора и создают список данных (см. главы 15-18). Транзакция вариантов (Variant Transaction) выводит на экран значения полей вариантов транзакции, используемых для одного или нескольких экранов. Аналогично вариантам отчета, варианты транзакций позволяют сделать экранные поля только отображаемыми и даже отменить их (закрыть доступ). Использование этой технологии обеспечивает внесение необходимых требований пользователя без изменения исходных текстов.

Для вызова транзакции из диалогового экрана следует создать функцию меню типа Т. используя экран сопровождения статусов интерфейса. Например, код транзакции SAAB (см. главу 19) добавляется к элементам меню (см. рис. 21.4).

Рис. 21.4

Добавление транзакции к элементам меню