Аналіз та порівняльне дослідження архітектурних рішень програмних роботів для процесів з великою кількістю транзакцій

Abstract

Аналіз нової області в сфері інформаційних технологій - RPA показав одну з актуальних завдань генерації рішення автоматизації бізнес процесів. Це визначення архітектурного рішення, яке визначає функціонування робота. Аналіз вище наведених прикладів показав переваги і недоліки кожної з схем рішень в ситуації автоматизації процесу з великою кількістю транзакцій. Розкрита сутність та актуальність теми RPA, а також існуючих архітектурних рішень програмних роботів та представлені переваги та недоліки в існуючих рішеннях в ситуації процесів з великою кількістю транзакцій. В висновку запропоноване можливе вирішення проблеми з виділенням переваг та недоліків. Якщо розглядати шаблон Multiple Instances Requiring Synchronization, то архітектурне рішення підпроцесу можна описати подібно вище наведеної машині станів, таким чином взявши властивість стійкості до збоїв, але при цьому робота кожної транзакції буде незалежна один від одного, тобто паралельне виконання. Таким чином, з’являється можливість зменшити час виконання процесу і зникає дублювання виконання елементів архітектурного рішення всього процесу. Але варто враховувати, що кожен екземпляр B (описаний як машина станів) повинен бути незалежний один від одного (тобто не перебувати в послідовності). Недоліком природно є збільшення ресурсів на виконання, тобто збільшення кількості локальних машин, на кожній з яких виконується одна транзакція. Тому такий підхід доречний для великих процесів з великою кількістю транзакцій.Анализ новой области в сфере информационных технологий - RPA показал одну из актуальных задач генерации решение автоматизации бизнес процессов. Это определение архитектурного решения, которое определяет функционирование работа. Анализ приведенных выше примеров показал преимущества и недостатки каждой из схем решений в ситуации автоматизации процесса с большим количеством транзакций. Раскрыта сущность и актуальность темы RPA, а также существующих архитектурных решений программных роботов и представлены преимущества и недостатки в существующих решениях в ситуации процессов с большим количеством транзакций. В заключении предложено возможное решение проблемы с выделением преимуществ и недостатков. Если рассматривать шаблон Multiple Instances Requiring Synchronization, то архитектурное решение подпроцесса можно описать подобно выше приведенной машине состояний, таким образом взяв свойство устойчивости к сбоям, но при этом работа каждой транзакции будет независимая друг от друга, то есть параллельное выполнение. Таким образом, появляется возможность уменьшить время выполнения процесса и исчезает дублирование выполнения элементов архитектурного решения всего процесса. Но стоит учитывать, что каждый экземпляр B (описан как машина состояний) должен быть независим друг от друга (т.е. не находиться в последовательности). Недостатком естественно является увеличение ресурсов на выполнение, то есть увеличение количества локальных машин, на каждой из которых выполняется одна транзакция. Поэтому такой подход уместен для больших процессов с большим количеством транзакций.Analysis of the new area in the field of information technology - RPA has shown one of the most urgent tasks of generating business automation solutions. This is the definition of the architectural solution that determines the functioning of the robot. The analysis of the above examples showed the advantages and disadvantages of each of the decision schemes in a situation of automation of the process with a large number of transactions. The essence and relevance of the RPA topic, as well as existing architectural solutions of software robots, are revealed, and the advantages and disadvantages of existing solutions in situations involving processes with a large number of transactions are presented. The conclusion suggests a possible solution to the problem with the allocation of advantages and disadvantages. If you consider the Multiple Instances Requiring Synchronization template, then the architectural subprocess solution can be described just like the above machine states, thus taking the property of stability to failures, but the work of each transaction will be independent of each other, that is, parallel execution. Thus, it is possible to reduce the time of execution of the process and disappear duplication of the implementation of elements of the architectural decision of the entire process. But it should be borne in mind that each instance B (described as a state machine) must be independent of each other (that is, it does not have to be in sequence). A disadvantage naturally is an increase in resources for execution, that is, an increase in the number of local machines, each of which executes one transaction. Therefore, this approach is appropriate for large processes with a large number of transactions.