Меню

Консистентное обновление базы данных при помощи функционала Any Tab Update Task

В статье предлагается решение по быстрому написанию консистентного обновления базы данных в ABAP (хотя подход может быть применен и к другим языкам). Описанный в статье подход является результатом субъективного опыта автора.

Оглавление

Предисловие и предупреждение

Описание проблемы. Важность решения

Транзакционность в SQL-базах данных

Обеспечение консистентности данных в SAP NetWeaver в ABAP/4

Использование функциональных модулей обновления в ABAP

Использование функционала Any Tab Update Task для обновления БД в ABAP-приложениях

Предисловие и предупреждение

Предлагаемое решение является частью более широкого направления для исследования «стабильности систем и скорости их разработки/изменений».

Описание проблемы. Важность решения

Для упрощения понимания под «консистентным обновлением таблиц» в базе данных будем понимать такое обновление, при котором данные из SAP-транзакции записываются в базу либо все одновременно, либо не записываются вовсе. Можно сказать, что такие данные имеют «внутреннюю согласованность».

Рассмотрим пример: пусть модель данных некоторого документа состоит из заголовка (ZDOC_H) и позиции (ZDOC_I). Ситуация, когда в базу одновременно записываются данные и в ZDOC_H и ZDOC_I, является консистентным обновлением. А вот если же данные в ZDOC_H не записались, а записались только в ZDOC_I, то такое обновление не является консистентным. При этом, если по каким-то причинам одну из таблиц обновить нельзя (например, есть физическая блокировка или логический статус записи в таблице это сделать не позволяет), то и другая таблица обновляться не должна; это также является признаком консистентного обновления.

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

А как решается эта задача на уровне базы данных?

Транзакционность в SQL-базах данных

Для того, чтобы обеспечить консистентность данных (т.е. их внутреннюю согласованность между собой) есть понятие транзакционности (либо запись/изменение всех данных либо ничего). А вот для транзакционности (то есть выполнения нескольких операций БД в рамках одного шага) имеются специальные операторы. В популярных БД – это операторы START TRANSACTION и COMMIT (Рис.1). С помощью START TRANSACTION СУБД дается указание, что нужно обновить все в рамках одного шага и «шаг наполняется» нужными SQL-операциями (insert, delete, update). (пример для postgres, для ORACLE, для MySQL, для HANA). Вот этот «шаг работы базы данных» имеет название «Unit of work» или Database Unit of Work (в переводе часто используют термин Единица работы). Наполнение шага обновления диктуется исключительно логикой модели данных и поэтому используют также понятие Database Logical Unit of Work, или DB LUW (Рис.1).

Для того, чтобы обеспечить транзакционность на уровне базы данных мы открываем «логический шаг» с помощью START TRANSACTION, наполняем нужными SQL-Операциями и завершаем шаг командой COMMIT (Рис.1.). Если в течение одной из SQL-операций будет ошибка - то COMMIT не произойдет, а будет ROLLBACK, то есть отмена всех операций. Такой механизм гарантируется базой данных. Обращаю внимание, что именно таким образом, работает механизм на уровне базы, а не на уровне приложения.

Рис. 1 Объединение отдельных SQL-операций в DB LUW (транзакция на уровне БД)

Транзакция базы данных (или DB LUW) представляет собой неделимую последовательность SQL-операций. В случае ошибки хотя бы в одной из них, база данных восстанавливает состояние по всем операциям (выполняется DATABASE ROLLBACK); в случае же успешного выполнения каждой SQL-операции: выполняется DATABASE COMMIT и данные записываются в нужные поля нужных таблиц. Это подход, обеспечивающий целостность данных на уровне БД.

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

Давайте рассмотрим, как обеспечивается консистентное обновление в рамках ABAP-приложений.

Обеспечение консистентности данных в SAP NetWeaver в ABAP/4

В ABAP/4 работа непосредственно с SQL-командами базы данных не ведется. Используется ABAP SQL (open SQL). Вводится понятие SAP LUW. По факту, SAP LUW – это и есть та самая «корректная» подготовка данных внутри нашего приложения (какой бы то ни было сложности) для базы данных. При этом от SAP LUW мы получаем не только консистентность данных, но и управление транзакционностью «любой базы» (таким образом, ABAP может работать с любой базой и корректно подготавливать данные для БД, объединяя SQL-операции в транзакции) (Рис.2).

Рис. 2 Соотнесение SAP LUW и выделенного DB LUW в ABAP-программе с точки зрения SQL-операций (символ "кружочек" на схеме)

Приложение на языке ABAP/4 может быть разделено на несколько частей, которые могут обрабатываться в различных рабочих процессах на сервере приложений (Application Server). ABAP-приложение НЕ подразумевает под собой один-единственный DB LUW. В рамках ABAP-приложения может быть несколько явных DB LUW; более того, каждый рабочий процесс (work process) завершается неявным DB LUW (Рис.2).

Чтобы управлять консистентностью данных, ABAP-приложение не выполняет запись в базу данных сразу же (не передает команду БД), а откладывает их для отдельного процесса, который может быть выполнен по завершении SAP LUW (Рис.2). Завершается же SAP LUW ABAP-командой COMMIT WORK или ROLLBACK WORK. Объединение требуемых обновлений в процессе работы SAP LUW для отдельного процесса DB LUW называется bundling (группирование / «объединение в кучу»). Подробнее об этом описано в справке к SAP LUW.

Если хотите прочитать статью полностью и оставить свои комментарии присоединяйтесь к sapland

У вас уже есть учетная запись?

Войти