В настоящее время управление предприятием непрерывно связано с использованием систем планирования ресурсов предприятия (ERP), которые позволяют автоматизировать процессы управления бухгалтерским учетом, инвентаризацией, менеджментом и другими отделами предприятия, интегрируя все это в одну систему [1, 2].
При работе в таких системах постоянно возникает потребность в выполнении определенных действий при наступлении некоторых событий, т.е. триггеров (например, добавление товаров в систему учета при поступлении их на склад). В большинстве ERP-систем настройка триггеров происходит отдельно для каждого предприятия при интеграции системы, связана с большими временными и финансовыми затратами и не может быть в дальнейшем использована при интеграции системы на других предприятиях.
Ниже приведен пример запроса для создания триггера на языке SQL, который добавляет в таблицу values запись об изменении таблицы example:
CREATE OR REPLACE TRIGGER ExampleUpdatedTrigger
AFTER UPDATE ON example
BEGIN
insert into info values ('table "example" has changed');
END;
При появлении новых бизнес-процессов на предприятии добавление в ERP-систему новых триггеров также требует отдельной настройки системы и связано с дополнительными затратами, а существующие в системе триггеры, объекты триггеров или действия, исполняемые триггерами при вызове, не могут быть изменены или расширены, либо их модификация ограничена возможностями системы [3, 4].
Цель исследования: повышение быстродействия процессов построения и вызова триггеров управления бизнес-процессами предприятия в ERP-системах.
Материалы и методы исследования
Разработаем математическую модель триггеров ERP-системы и представим триггерные связи, возникающие при создании, изменении и удалении объектов ERP-системы, в виде графов – графа потока управления CFG и графа зависимостей DFG.
Триггер в рамках ERP-системы – это совокупность T множества событий системы 
и набора действий 
. При возникновении любого события ei из множества E триггер T запускает по очереди действия wj из набора W. Каждое событие 
в ERP-системе связано с объектом x системы и представляет собой изменение, создание, удаление объекта x или его атрибутов 
.
Возникновение события задается функцией 
, для которой h (e, x) = 1, если объект x был изменен, и 0 в остальных случаях. Действия 
также представляют собой изменение, создание или удаление объектов ERP-системы и их атрибутов, причем множество изменяемых объектов Xc может пересекаться c множеством объектов событий Xе. Действие w может принимать одно из значений:
(изменение объекта x, в результате которого часть атрибутов объекта изменяется); 
(создание нового объекта y); 
(удаление объекта x); w(x) = x (действие, не изменяющее объект x).
Таким образом, триггер можно задать с помощью формулы
,
где e1, e2, en – события триггера, w1, w2, wn – действия триггера, f: 2W – функция, равная 1 в случае успешного выполнения последовательности действий w = w1 w2… wn = 1, и 0 в случае неудачи.
Для отображения триггерных связей между объектами ERP-системы удобно воспользоваться графовыми структурами, такими, как граф потока управления и граф зависимостей [5, 6].
Граф потока управления представляет собой совокупность CFG(V, T), где V = {vi | i = 1…n} – множество действий над объектами ERP-системы, а T = {tij = (vi, vj) | i = 1…n, j = 1…n} – множество триггерных связей между объектами ERP-системы (рис. 1). В графе потока управления каждый узел (вершина) графа соответствует базовому блоку – прямолинейному участку кода, не содержащему в себе ни операций передачи управления, ни точек, на которые управление передается из других частей программы.
Имеется лишь два исключения:
− точка, на которую выполняется переход, является первой инструкцией в базовом блоке;
− базовый блок завершается инструкцией перехода.
Направленные дуги используются в графе для представления инструкций перехода. Также, в большинстве реализаций добавлено два специализированных блока:
− входной блок, через который управление входит в граф;
− выходной блок, который завершает все пути в данном графе. Блок, не связанный со входным блоком, считается недостижимым («мёртвый» код).
Рис. 1. Граф потока управления CFG в ERP-системе
Недостижимый блок может быть удален из программы. Блок, не связанный с выходным блоком, содержит бесконечный цикл. Полагаясь на это утверждение, удаётся обнаружить не все бесконечные циклы в связи с проблемой останова.
Пусть дано множество V = {vi | i = 1…n} объектов ERP-системы и отношение транзитивности над этим множеством R = V×V, где 
следует зависимость для вычисления a нужно сначала вычислить b.
Тогда граф зависимостей представляет собой совокупность множеств DFG(V, T), где 
и R – транзитивное замыкание T (рис. 2).
Рис. 2. Граф зависимостей DFG в ERP-системе
Формализация задачи построения триггеров в ERP-системе состоит из двух критериев [7]. Данные критерии представляют собой оценку быстродействия алгоритма построения триггеров в ERP-системе.
Пусть T(n), определенная как функция над графом CFG(V, T)
, (1)
где e(tij) – время на создание триггерной связи tij = (vi, vj), l(vj) – время на выполнение действий триггера над объектом j, представляет собой временные затраты на создание триггерных связей между объектами ERP-системы при накладываемых ограничениях.
(2)
Тогда первый критерий быстродействия триггерного алгоритма
(3)
где T0 – временные затраты на создание триггерных связей до применения предложенной в данной работе методики; T1 – временные затраты на создание триггерных связей после применения данной методики.
2. Пусть D(n) – определенная как функция над графом DFG(V, T)
(4)
где d(tij) – задержка возникновения триггерной связи, возникающая при конфликте по данным (RAW, WAR). Тогда второй критерий быстродействия триггерного алгоритма – критерий быстродействия обновления графа триггеров при наличии конфликтов по данным:
(5)
где D0 – временные затраты на обновление графа вызова триггеров до применения предложенной в данной работе методики; D1 – временные затраты на обновление графа вызова триггеров после применения данной методики.
Результаты исследования и их обсуждение
Исходя из разработанной математической модели, для создания триггеров в ERP-системах можно применять два способа: создание на уровне программного кода и создание на уровне базы данных. На основе данной модели была разработана методика построения триггеров управления бизнес-процессами в ERP-системах.
На первом этапе в отношении любой ERP-системы необходимо определить набор общих стандартных моделей (например, моделей организации), объектов (например, планы и списки поставщиков) и процессов (например, управление заказами).
Если ранее для каждого предприятия нужно было учитывать существующую на ней структуру и организацию данных, то при использовании ERP-системы необходимым и достаточным является использование одних и тех же моделей для каждой организационной единицы [7, 8]. Качество выбранных моделей оказывает огромное влияние на общий успех интеграции ERP-системы на предприятии.
В рамках языка программирования событие – это сообщение, которое возникает в различных точках исполняемого кода при выполнении определённых условий. Для решения поставленной задачи создаются обработчики событий: как только программа попадает в заданное состояние S, т.е. как только произойдет изменение, создание или удаление соответствующего объекта ERP-системы, происходит событие, посылается сообщение, а обработчик перехватывает это сообщение и выполняет действия w1, w2,…, wn∈W.
В общем случае в обработчик не передаётся ничего, либо передаётся ссылка на объект, инициировавший (породивший) обрабатываемое событие. В особых случаях в обработчик передаются значения некоторых переменных или ссылки на какие-то другие объекты, чтобы обработка данного события могла учесть контекст возникновения события. Таким образом, создание триггера на уровне программного кода позволяет запускать любые действия при вызове их обработчиков.
Аналогично, как и в случае обработчиков событий, как только база данных перейдет в состояние S, при котором произойдет изменение каких-либо объектов x ERP-системы, запускается хранимая процедура, соответствующая измененным объектам, и исполняются действия w1, w2,…, wn∈W. Однако в связи с тем, что внутри хранимой процедуры в БД можно указывать только действия, связанные с БД, то такой способ построения триггеров не дает возможности исполнять действия триггера вне базы данных [6].
Объединив два перечисленных способа, в работе применяется смешанный подход, состоящий в хранении триггера в сериализованном виде в базе данных, что одновременно обеспечивает и портируемость созданных ERP-триггеров, и возможность задавать любые действия, выполняемые при вызове триггера. При создании триггера все запросы к БД и другие действия в ERP-системе сериализуются и помещаются в БД. При вызове триггера данные десериализуются, оттуда извлекаются и запускаются действия триггера [9, 10].
Из построенной модели триггеров следует, что при вызове триггера могут изменяться данные объектов, использующиеся при вызове других триггеров. Такая ситуация может произойти, если в результате действий w∈W множество изменяемых объектов Xc пересекается c множеством объектов событий XЕ:
(6)
При этом могут возникать конфликты по данным [10]:
1. Read after Write (RAW). Триггер TA записывает значение в переменную, которую использует триггер TВ.
2. Write after Read (WAR). Триггер TA считывает значение переменной, в которую записывает новое значение триггер TВ.
3. Write after Write (WAW). Оба триггера записывают значения в одну и ту же переменную.
Чтобы избежать появления конфликтов по данным, применяется метод топологической сортировки графа триггеров с помощью обхода графа в глубину, который обеспечивает обновление графа зависимостей триггерных связей (рис. 3).
Рис. 3. Топологическая сортировка графа ERP-триггеров
Для оценки быстродействия разработанных методики и алгоритмов были проведены испытания по построению графа ERP-триггеров в системе планирования ресурсов предприятия Greensight ERP.
В качестве критериев быстродействия применялись следующие:
1. Временные затраты на создание триггерных связей между объектами
(7)
где e(tij) – время на создание триггерной связи tij = (vi, vj), l(vj) – время на выполнение действий триггера над объектом vj.
2. Временные затраты на обновление графа вызова ERP-триггеров при наличии конфликтов по данным
(8)
где d(tij) – задержка возникновения триггерной связи, возникающая при конфликте по данным (RAW, WAR), l(vj) – время на выполнение действий триггера над объектом vj.
В табл. 1 и 2 приведены результаты испытаний.
Таблица 1
Быстродействие операций построения триггеров до применения разработанных алгоритмов
|
Количество объектов |
Число запросов |
Временная задержка, мс |
|
10 |
15 |
13 |
|
100 |
31 |
85 |
|
1000 |
75 |
400 |
|
10000 |
130 |
7600 |
|
100000 |
738 |
15700 |
Таблица 2
Быстродействие операций построения триггеров после применения разработанных алгоритмов
|
Количество объектов |
Число запросов |
Временная задержка, мс |
|
10 |
2 |
7 |
|
100 |
7 |
37 |
|
1000 |
19 |
250 |
|
10000 |
88 |
570 |
|
100000 |
170 |
3600 |
Выводы
Проведено исследование современных подходов построения триггеров в ERP-системах. На основе данных исследования был выбран подход, объединяющий триггеры как хранимые процедуры особого типа в базах данных и триггеры как обработчики событий.
В работе была разработана математическая модель и методика построения триггеров управления бизнес-процессами в ERP-системах. В рамках данного подхода триггеры хранятся в сериализованном виде в базе данных, что одновременно обеспечивает и портируемость созданных ERP-триггеров, и возможность задавать любые действия, выполняемые при вызове триггера. Проведены испытания для оценки быстродействия построения и обновления графа ERP-триггеров с помощью разработанной модели, в результате которых получено уменьшение числа запросов на 52 %, а временных затрат на построение и обновление ERP-триггеров – на 54 %.
Работа выполнялась при финансовой поддержке РФФИ (договор № 18-07-00079\18).