Scientific journal
Modern high technologies
ISSN 1812-7320
"Перечень" ВАК
ИФ РИНЦ = 0,940

ENTERPRISE RESOURCE CONTROLLING SYSTEM MATHEMATICAL MODEL DEVELOPMENT

Vysochkin A.V. 1 Portnov E.M. 1 Slyusar V.V. 1
1 National Research University of Electronic Technology
Currently, enterprise resource management systems constantly need to create and process triggers that are associated with the occurrence of certain events in the system. The problem posed in this paper is that the currently existing ERP-systems do not have sufficient capacity to create triggers within the system for certain tasks of the enterprise, because either these capabilities are limited to certain the range of objects and actions for which you can create a trigger, or there is no such functionality and all triggers must be installed during the integration of the system in the enterprise and can not be subsequently changed. In this regard, a mathematical model of the business process control algorithm for ERP-systems was developed, which allows to configure triggers within the system, not during its integration. Based on the developed mathematical model, two methods can be used to create triggers in ERP systems: creation at the program code level and creation at the database level. Using this model reduces the number of requests by 52?%, and the time spent on building and updating ERP triggers by 54?%.
ERP-systems
triggers
mathematical model
business processes
graph
speed

В настоящее время управление предприятием непрерывно связано с использованием систем планирования ресурсов предприятия (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 множества событий системы viskoc01.wmf и набора действий viskoc02.wmf . При возникновении любого события ei из множества E триггер T запускает по очереди действия wj из набора W. Каждое событие viskoc03.wmf в ERP-системе связано с объектом x системы и представляет собой изменение, создание, удаление объекта x или его атрибутов viskoc04.wmf.

Возникновение события задается функцией viskoc05.wmf, для которой h (e, x) = 1, если объект x был изменен, и 0 в остальных случаях. Действия viskoc06.wmf также представляют собой изменение, создание или удаление объектов ERP-системы и их атрибутов, причем множество изменяемых объектов Xc может пересекаться c множеством объектов событий Xе. Действие w может принимать одно из значений:

viskoc07.wmf (изменение объекта x, в результате которого часть атрибутов объекта изменяется); viskoc08.wmf (создание нового объекта y); viskoc09.wmf (удаление объекта x); w(x) = x (действие, не изменяющее объект x).

Таким образом, триггер можно задать с помощью формулы

viskoc10.wmf,

где 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). В графе потока управления каждый узел (вершина) графа соответствует базовому блоку – прямолинейному участку кода, не содержащему в себе ни операций передачи управления, ни точек, на которые управление передается из других частей программы.

Имеется лишь два исключения:

− точка, на которую выполняется переход, является первой инструкцией в базовом блоке;

− базовый блок завершается инструкцией перехода.

Направленные дуги используются в графе для представления инструкций перехода. Также, в большинстве реализаций добавлено два специализированных блока:

− входной блок, через который управление входит в граф;

− выходной блок, который завершает все пути в данном графе. Блок, не связанный со входным блоком, считается недостижимым («мёртвый» код).

visock1.tif

Рис. 1. Граф потока управления CFG в ERP-системе

Недостижимый блок может быть удален из программы. Блок, не связанный с выходным блоком, содержит бесконечный цикл. Полагаясь на это утверждение, удаётся обнаружить не все бесконечные циклы в связи с проблемой останова.

Пусть дано множество V = {vi | i = 1…n} объектов ERP-системы и отношение транзитивности над этим множеством R = V×V, где viskoc11.wmf следует зависимость для вычисления a нужно сначала вычислить b.

Тогда граф зависимостей представляет собой совокупность множеств DFG(V, T), где viskoc12.wmf и R – транзитивное замыкание T (рис. 2).

visock2.tif

Рис. 2. Граф зависимостей DFG в ERP-системе

Формализация задачи построения триггеров в ERP-системе состоит из двух критериев [7]. Данные критерии представляют собой оценку быстродействия алгоритма построения триггеров в ERP-системе.

Пусть T(n), определенная как функция над графом CFG(V, T)

viskoc13.wmf, (1)

где e(tij) – время на создание триггерной связи tij = (vi, vj), l(vj) – время на выполнение действий триггера над объектом j, представляет собой временные затраты на создание триггерных связей между объектами ERP-системы при накладываемых ограничениях.

viskoc14.wmf (2)

Тогда первый критерий быстродействия триггерного алгоритма

viskoc15.wmf (3)

где T0 – временные затраты на создание триггерных связей до применения предложенной в данной работе методики; T1 – временные затраты на создание триггерных связей после применения данной методики.

2. Пусть D(n) – определенная как функция над графом DFG(V, T)

viskoc16.wmf (4)

где d(tij) – задержка возникновения триггерной связи, возникающая при конфликте по данным (RAW, WAR). Тогда второй критерий быстродействия триггерного алгоритма – критерий быстродействия обновления графа триггеров при наличии конфликтов по данным:

viskoc17.wmf (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Е:

viskoc18.wmf (6)

При этом могут возникать конфликты по данным [10]:

1. Read after Write (RAW). Триггер TA записывает значение в переменную, которую использует триггер TВ.

2. Write after Read (WAR). Триггер TA считывает значение переменной, в которую записывает новое значение триггер TВ.

3. Write after Write (WAW). Оба триггера записывают значения в одну и ту же переменную.

Чтобы избежать появления конфликтов по данным, применяется метод топологической сортировки графа триггеров с помощью обхода графа в глубину, который обеспечивает обновление графа зависимостей триггерных связей (рис. 3).

visock3.tif

Рис. 3. Топологическая сортировка графа ERP-триггеров

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

В качестве критериев быстродействия применялись следующие:

1. Временные затраты на создание триггерных связей между объектами

viskoc19.wmf (7)

где e(tij) – время на создание триггерной связи tij = (vi, vj), l(vj) – время на выполнение действий триггера над объектом vj.

2. Временные затраты на обновление графа вызова ERP-триггеров при наличии конфликтов по данным

viskoc20.wmf (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).