Logical Unit of Work(LUW)

В реальном мире пользователь завершает транзакцию, выполняя последовательность действий, которые логически связаны друг с другом, например, бронируя рейс. Эта последовательность действий должна быть завершена вместе как единое целое, и эта единица называется логической единицей работы (LUW).

Для обеспечения правильности и полноты данных либо все данные, принадлежащие LUW, должны быть зафиксированы в базе данных вместе, либо никакие данные не должны быть зафиксированы. Например, когда вы переводите сумму в финансовый учет, один счет должен быть дебетован, а другой счет кредитован. После списания суммы с одного счета и до того, как она будет отправлена на другой счет, данные находятся в противоречивой форме. Если база данных обновляется сразу при списании со счета, но из-за ошибки в приложении кредитный счет не проводится, будет несогласованность данных, потому что сумма не отражена ни в одном счете.

Данные в логической единице должны быть зафиксированы полностью, и должен быть механизм для отката данных, если транзакция не была успешно завершена. Чтобы избежать такой несогласованности данных и гарантировать, что данные всегда непротиворечивы в конце каждой транзакции, мы реализуем концепции базы данных LUW и SAP LUW.

Database LUW

База данных LUW существует между каждым шагом диалога; он работает как единое целое с неотделимой последовательностью операций базы данных, которая заканчивается фиксацией базы данных. База данных LUW либо выполняется полностью, либо не выполняется вообще. Если в базе данных LUW возникает какая-либо ошибка, никакие данные из LUW не фиксируются в базе данных. Это гарантирует, что в конце каждой LUW базы данных данные всегда будут в согласованной форме. Другими словами, данные либо изменяются в конце LUW базы данных, либо остаются такими, какими они были до начала LUW базы данных.

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

Время между тем, как экран становится неактивным, и тем, как экран снова становится активным, когда рабочий процесс завершает обработку, называется шагом диалога. База данных LUW начинается каждый раз, когда начинается шаг диалога, и заканчивается, когда выполняется работа фиксации.

Изменения базы данных в базе данных LUW не записываются в базу данных до тех пор, пока не будет выполнена работа фиксации. Это позволяет выполнить откат, чтобы отменить изменения. Например, предположим, что вы выполнили оператор INSERT в программе, чтобы вставить данные заголовка документа, но позже в коде отсутствуют некоторые важные данные о деталях элемента документа, поэтому вы не можете обновить детали предмета.

SAP LUW позволяет управлять сложными бизнес-процессами и распределять транзакцию между несколькими рабочими процессами или даже между несколькими системами. Различные методы объединения, которые мы используем для реализации SAP LUW, обсуждаются в следующих подразделах.

Функциональный модуль обновления

Для объединения обновлений базы данных до последнего шага SAP LUW используется специальный функциональный модуль, называемый функциональным модулем обновления.

Функциональные модули обновления создаются в построителе функций путем установки типа обработки на модуль обновления в атрибутах функционального модуля.

Существует два типа обновлений: обновления с высоким приоритетом, называемые V1, и обновления с низким приоритетом, называемые V2. Обновления V1 — это те, которые описывают критические или первичные изменения, такие как создание заказов или изменение запасов материалов. Обновления V2 — это те, которые описывают менее важные, вторичные изменения, такие как статистические обновления или расчеты результатов. Обновления V1 всегда обрабатываются до обновлений V2. Обновления V1 обрабатываются на том же сервере приложений, на котором запрашивается обновление, и обрабатываются последовательно в рабочем процессе с одним обновлением; их можно откатить и они относятся к единой базе данных LUW. Обновления версии 2 выполняются вместе в отдельной LUW.

Для функционального модуля обновления можно установить следующие атрибуты:

НемедленнЗапуск

Установите этот параметр для обновлений  V1 в общей SAP LUW. Если во время обновления возникает какая-либо техническая ошибка (например, нехватка памяти), обновление откатывается и может быть перезапущено задачей обновления.

Немедл. запуск, без постобновл.

Аналогичен предыдущему варианту, но обновление не перезапускается в случае технической ошибки.

ЗапускОткладыв

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

ГруппОбработка 

Этот флаг предназначен для внутреннего использования SAP. Когда этот флаг установлен, функциональные модули обновления выполняются коллективно.

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

Операторы Open SQL, изменяющие данные, не записываются непосредственно в прикладную программу. Вместо этого данные, которые должны быть изменены, передаются функциональному модулю обновления, а операторы Open SQL для изменения данных в базе данных используются внутри функционального модуля. Другими словами, операторы обновления пишутся в функциональном модуле, а не в программе. Затем этот функциональный модуль обновления вызывается в том месте программы, в которое вы в противном случае включили бы операторы Open SQL. Функциональный модуль вызывается с использованием дополнения IN UPDATE TASK к оператору CALL FUNCTION (например, CALL FUNCTION 'XYZ' IN UPDATE TASK).

Когда функциональный модуль вызывается с использованием дополнения IN UPDATE TASK, он не выполняется немедленно; вместо этого он помечается для выполнения в специальном рабочем процессе, называемом рабочим процессом обновления. Функциональный модуль и его параметры сохраняются как запись журнала в таблице базы данных VBLOG. Когда в программе выполняется оператор COMMIT WORK, рабочий процесс обновления заботится об обновлении данных, а функциональный модуль выполняется путем чтения журнала из таблицы VBLOG.

Например, если поток транзакций включает три шага диалога и функциональный модуль обновления вызывается на первом шаге диалога, он не выполняется немедленно; вместо этого запись журнала делается в таблице VBLOG. На последнем шаге диалога, если вы используете оператор COMMIT WORK, рабочий процесс обновления обновит данные в базе данных.

Если по какой-либо причине на последнем шаге диалога вы решили не обновлять данные (из-за логической ошибки), вы можете использовать оператор ROLLBACK WORK. При использовании оператора ROLLBACK WORK запись журнала будет удалена из таблицы VBLOG, и никакие данные не будут обновлены в базе данных, поскольку функциональный модуль не будет выполнен.

Если по каким-либо техническим причинам рабочий процесс обновления не может завершить обновление, он автоматически выполнит откат и поместит запись журнала обратно в таблицу VBLOG (в зависимости от настройки функционального модуля). Затем он отправляет сообщение пользователю, который первоначально запустил рабочий процесс диалога, с информацией об ошибке. После исправления ошибки записи VBLOG можно снова обрабатывать.

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

Подпрограмма обновления

Обновление можно выполнить в подпрограммах, используя дополнение ON COMMIT с оператором PERFORM. Когда вы используете оператор PERFORM для вызова подпрограммы с дополнением ON COMMIT (например, PERFORM <xyz> ON COMMIT), подпрограмма не вызывается немедленно. Подпрограмма вызывается, когда в программе выполняется оператор COMMIT WORK.

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

RFC

Когда вы вызываете удаленный функциональный модуль, используя IN BACKGROUND TASK DESTINATION с оператором CALL FUNCTION (например, CALL FUNCTION 'ABC' IN BACKGROUND TASK DESTINATION 'QAS'), функциональный модуль регистрируется для фонового выполнения в другой системе SAP, указанной в назначение. Назначение содержит сведения об удаленной системе, такие как IP-адрес удаленной системы и учетные данные для входа. Когда программа встречает оператор COMMIT WORK, удаленный функциональный модуль выполняется в фоновом режиме в целевой системе.