ERROR HANDLING IN INTEGRATION WORKFLOWS

• Published in: Nauchnyĭ vestnik MGTU GA (Online) Vol. 20; no. 3; pp. 149 - 156
• Main Authors: A. M. Nazarenko, A. A. Prokhorov
• Format: Journal Article
• Language: Russian
• Published: Moscow State Technical University of Civil Aviation 01-06-2017
• Subjects: error handling; process automation; process integration; workflow; workflow patterns
• ISSN: 2079-0619; 2542-0119

Simulation experiments performed while solving multidisciplinary engineering and scientific problems require joint usage of multiple software tools. Further, when following a preset plan of experiment or searching for optimum solu- tions, the same sequence of calculations is run multiple times with various simulation parameters, input data, or conditions while overall workflow does not change. Automation of simulations like these requires implementing of a workflow where tool execution and data exchange is usually controlled by a special type of software, an integration environment or plat- form. The result is an integration workflow (a platform-dependent implementation of some computing workflow) which, in the context of automation, is a composition of weakly coupled (in terms of communication intensity) typical subtasks. These compositions can then be decomposed back into a few workflow patterns (types of subtasks interaction). The pat- terns, in their turn, can be interpreted as higher level subtasks.This paper considers execution control and data exchange rules that should be imposed by the integration envi- ronment in the case of an error encountered by some integrated software tool. An error is defined as any abnormal behavior of a tool that invalidates its result data thus disrupting the data flow within the integration workflow. The main requirementto the error handling mechanism implemented by the integration environment is to prevent abnormal termination of theentire workflow in case of missing intermediate results data. Error handling rules are formulated on the basic pattern level and on the level of a composite task that can combine several basic patterns as next level subtasks. The cases where workflow behavior may be different, depending on user's purposes, when an error takes place, and possible error handling op- tions that can be specified by the user are also noted in the work.