- В обработке диалоговых запросов на уровне прикладной области участвуют следующие компоненты::
- диспетчер;
- очереди рабочих процессов (управляемые диспетчером) для входящих запросов;
- один из диалоговых рабочих процессов;
- буферы совместной памяти, а также, возможно, файл прокрутки.
- Обработчик задач координирует работу внутри диалогового рабочего процесса. Он активизирует процессор экранов или Программирование в ABAP: (первый из которых управляет логикой последовательности экранов, а другой обработкой ABAP-операторов), а также осуществляет подкачку и откачку контекста пользователя.
- Система управления памятью различна для областей оперативной памяти, доступных только определенному рабочему процессу, и для областей памяти, которые могут использоваться всеми рабочими процессами. Область памяти, используемая только определенным рабочим процессом, сохраняет данные, специфичные для сеанса, которые должны храниться дольше, чем длится шаг работы. Эти данные становятся автоматически доступными для процесса в начале шага диалога (развертка) и сохраняются при завершении этого шага диалога (свертка). Эти данные характеризуют пользователя (являются контекстом пользователя), т.е. определяют его полномочия, административную информацию и дополнительные данные для диалогового процессора и ABAP-процессора. В этой области памяти также содержатся данные, собираемые системой при обработке шагов диалога в ходе выполнения транзакции (см. слайд, представленный ниже). Для всех процессов, обрабатываемых в совместной памяти, существуют также дополнительные области памяти, включая области для буферов производственного календаря, экранов, таблиц и программ.
- Бизнес-транзакции являются ориентированными на функции единицами обработки, которые вносят непротиворечивые изменения в базу данных, имеющие отношение к хозяйственной операции. Типичными примерами являются проводки по кредиту и дебету, которые имеют смысл только в том случае, если выполняются совместно, или создание заказа и резервирование соответствующего материaла.
- Таким образом, SAP-транзакция рассматривается как ряд согласованных, взаимосвязанных шагов диалога. Шаг диалога пользователя представлен экраном (или ДИНПРО, (динамическая программа) = маска и логика выполнения).
- При диалоговой обработке одна транзакция может использовать несколько диалоговых рабочих процессов. Асинхронное обновление используется для обработки части диалога транзакции и соответствующего обновления базы данных в разных рабочих процессах и, возможно, даже на разных хостах.
- В системе R/3 шаг диалога начинается с обработки данных, введенных пользователем (обработка после ввода (Processes After Input, PAI), и с обработки и посылки следующей маски экрана (обработка перед выводом (Processes Before Output, PBO)); система затем получает следующий экран, обработанный пользователем, и еще раз анализирует и обрабатывает данные ввода на этом экране. Шаги диалога для пользователя и системы выполняются асинхронно. Для системы шаг диалога обычно состоит из двух частей: PBO- и PAI-модулей.
- Механизмов блокирования в современных СУРБД обычно недостаточно для обработки объектов коммерческих данных (таких, как заказы клиента), которые влияют на несколько таблиц базы данных. Для координации нескольких приложений, одновременно обрабатывающих один и тот же бизнес-объект, система R/3 предоставляет свое собственное управление блокировками, контролируемыми рабочим процессом обработки очередей.
- Чтобы в системе могли выполниться запросы на блокировку необходимо сначала определить в ABAP-словаре объект блокирования. Объект блокирования содержит таблицы, записи которых должны быть заблокированы. Объект блокирования состоит из первичной таблицы. С помощью отношений по внешнему ключу можно также определить дополнительные вторичные таблицы (имя определяемого пользователем объекта блокирования должно начинаться с "EY" или с "EZ").
- Для объекта блокирования можно указать режим блокирования ("S" - совместная блокировка или "E" - монопольная блокировка). Монопольную блокировку (режим "E") можно установить только в том случае, если никакой другой пользователь уже не установил блокировку для записи данных. Этот же пользователь может запросить дополнительную блокировку "E" или "S" в последовательности вызовов программ.
- Если объект блокирования активирован, система генерирует функциональные модули ENQUEUE и DEQUEUE. Эти функциональные модули называются ENQUEUE_<имя объекта> и DEQUEUE_<имя объекта> и используются в АВАР-кодировке для блокирования и разблокирования данных.
- При запросе на блокировку в системе выполняется проверка, не противоречит ли запрошенная блокировка существующим записям в таблице блокировок. При обнаружении такой ситуации запрос на блокировку отклоняется. После чего прикладная программа информирует пользователя о том, что в настоящий момент операция не может быть выполнена. Например, будет выведено сообщение "Данные в настоящее время используются. Изменение не возможно".
- Управление блокировками (постановкой в очередь) осуществляется рабочим процессом обработки очередей, использующем таблицу блокировок. Таблица блокировок храниться в оперативной памяти сервера, на котором выполняется РП обработки очередей. Если диалоговый рабочий процесс и рабочий процесс обработки очередей выполняются на разных серверах, связь между ними осуществляется через сервер сообщений.
- Блокировки, установленные прикладной программой, сбрасываются либо самой прикладной программой, либо специальной программой обновления (во второй части SAP-LUW; см. слайд, представленный ниже).
- Транзакция соответствует логической единице обработки (LUW).
- В связи с тем, что существующие системы баз данных не поддерживают выполнение транзакций, общих для всех процессов, необходимо различать элементарные шаги обработки (LUW) в системе R/3 и эти же шаги в системе базы данных (SAP-LUW/DB-LUW). DB-LUW либо полностью выполняется, либо обновление данных не происходит (выполняется откат). DB - LUW перемещает базу данных из одного согласованного состояния в другое. Это означает, что данные должны быть логическими и корректными, как до, так и поле LUW; это справедливо, как для DB - LUW, так и SAP - LUW.
- Начало SAP-транзакции является также и началом SAP-LUW. Логические единицы обработки (SAP-LUW) завершаются выполнением ABAP-оператора "COMMIT WORK" либо завершением соответствующего асинхронного обновления (вторая часть SAP-LUW). Как было описано выше, каждый шаг диалога в SAP-LUW обрабатывается одним рабочим процессом, как и в случае с DB-LUW. Каждое изменение в базе данных выполняется в своем собственном DB-LUW.
- Асинхронное обновление, обычно используемое в SAP - LUW, позволяет системе временно накопить изменения, выполненные пользователем, а затем при завершении фазы диалога (во второй части SAP - LUW) внести изменения в базу данных посредством отдельного рабочего процесса обновления. Для обеспечения непротиворечивости данных итоговое изменение базы данных (включающее в себя каждое "изменение шага диалога") выполняется только в одном заключительном DB - LUW.
- Если при асинхронном обновлении обрабатывается ABAP-ключевое слово CALL FUNCTION “…” IN UPDATE TASK, данные изменений сохраняются как записи журнала во временных таблицах VB*. В этих системных таблицах хранятся изменения данных, выполненные пользователем на протяжении SAP-транзакции. Запись журнала содержит имена запускаемых стандартных программ обновления, а также все данные, необходимые для выполнения изменений в базе данных.
- Само обновление инициируется ABAP-оператором COMMIT WORK, который задан в последнем шаге диалога SAP-транзакции. Блокировки, установленные прикладной программой посредством рабочего процесса обработки очередей (Е-РП), передаются рабочему процессу обновления. Если во время фазы диалога пользователь отменяет SAP-транзакцию или транзакция была прервана по какой-либо другой причине, выполнение изменений в базе данных отменяется. Во второй части SAP-LUW рабочий процесс обновления (V-РП) считывает из таблиц VB* записи журнала и обновляет соответствующие прикладные таблицы в базе данных R/3 в соответствии с изменениями, буферизированными в таблицах VB*.
- Во время обновления пользователь не может в диалоговом режиме исправить ошибки. Вместо этого система завершает обработку текущих компонентов обновления. Пользователи автоматически извещаются экспресс-почтой о времени завершения обновления. После чего администратор может проанализировать причину прекращения обновления и исправить ошибку (см. раздел "Администрирование").
- Загрузка диалоговых рабочих процессов не должна осуществляться с использованием шагов диалога длительного выполнения, т.к. тогда эти рабочие процессы будут недоступны другим пользователям. Оставшимся диалоговым рабочим процессам придется обрабатывать намного большее количество пользователей, что скажется на значительном снижении времени реакции системы.