Stepping Component Automation Framework for Software Workflow Robustness
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Software workflows, such as test automation, face challenges in robustness due to errors in components leading to premature workflow termination and high costs in time and computing resources, as re-running the entire workflow is often necessary to reproduce and fix errors.
Innovation Solution
A framework that wraps software components in a common interface, enabling retry and debug capabilities, allowing for selective retry of failed components with retained outputs and persistent action context data for quick debugging, thereby reducing the need to re-execute all components.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If the entire software workflow is re-executed to reproduce and resolve errors, then error reproduction and resolution are achieved, but time and computing resources are significantly consumed
Solution Approach 1:
The patent segments the workflow into individual executable components with unique identifiers. When an error occurs, only the failed component and its dependencies are re-executed rather than the entire workflow. This is achieved by identifying the specific component that failed and restarting execution from that component, preserving the outputs of successfully executed components.
Solution Approach 2:
The system performs preliminary actions by executing components ahead of time and storing their outputs. When a component fails, the stored outputs from previously executed components are reused, eliminating the need to re-execute them. This preliminary execution and storage of results directly reduces the time and resources needed for error resolution.
2Reliability
If the entire software workflow is re-executed to reproduce and resolve errors, then error reproduction and resolution are achieved, but computing resources are significantly consumed
Solution Approach 1:
The patent extracts and stores the outputs of successfully executed components separately. When an error occurs, only the failed component is re-executed while the extracted outputs from other components are reused. This extraction mechanism prevents unnecessary re-computation and reduces computing resource consumption during error resolution.
Solution Approach 2:
The system creates copies of the workflow state including component outputs and execution context. When an error occurs, the system can restore to a previous valid state or re-execute only the necessary portion, using copied data rather than regenerating it. This copying approach conserves computing resources by avoiding redundant execution.
3Reliability
If a common interface is introduced to wrap software components for retry and debug capabilities, then robustness and debuggability are improved, but device complexity increases
Solution Approach 1:
The patent introduces a universal common interface that wraps all software components, providing standardized retry and debug capabilities across different component types. This single interface handles multiple functions including error detection, retry logic, and debugging support, reducing the need for component-specific error handling code and actually simplifying the overall system architecture.
Solution Approach 2:
The common interface acts as an intermediary layer between the workflow execution engine and individual software components. It mediates error handling, retry logic, and debugging operations, isolating the complexity of robustness mechanisms from both the execution engine and the components themselves. This intermediary approach improves reliability while managing complexity through abstraction.
Data Source
AI summary
A framework for improving robustness in the execution of software workflows is described herein. One such workflow is a testing scenario, where multiple testing modules are to be executed sequentially, with some of the modules receiving as input the output of other modules. Many types of modules are contemplated, such as Application Program Interface (API) modules, User Interface (UI) modules, Database (DB) modules, and the like. Each of these modules may invoke, respond to, and/or extract data from various subjects of the testing scenario, among other operations. One aspect of the invention wraps each of these modules in a software component, such that disparate module types can be operated on with a common interface. In one embodiment, the common interface enables a test executor to retry and/or debug the software components in novel ways.