Business Process Automation with Runtime API Binding
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing business process automation systems face inconvenience and complexity due to the need to update and redeploy design information whenever application programming interface (API) information of legacy systems changes, leading to potential execution errors.
Innovation Solution
A business process automation system that includes a connect manager to register and manage API information using management identifiers, a process execution engine to execute tasks, and a connect broker to acquire API information at runtime, allowing tasks to be processed without redeploying the business process even when API information changes.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If API information of legacy systems changes, then the system needs to update and redeploy business process design information, but this causes increased operational complexity and potential execution errors
Solution Approach 1:
The patent segments the business process management system into distinct components: process definition elements (which remain stable) and API information elements (which can change independently). This is achieved by allowing process designers to define tasks with abstract interfaces while separating the concrete API implementations, so that API changes do not propagate to process definitions.
Solution Approach 2:
The patent introduces an intermediary layer between the business process definition and the legacy system APIs. This intermediary consists of service interfaces and adapters that translate between the stable process definition and the changing API implementations, allowing API information to change without affecting the core business process logic.
2Productivity
If API information is embedded in business process design information, then the system can execute tasks directly, but this requires frequent updates and redeployments when APIs change
Solution Approach 1:
The patent applies preliminary action by pre-defining service interfaces and task templates during the process design phase, independent of specific API implementations. This allows the business process logic to be prepared and validated in advance, so that when APIs change, only the implementation layer needs updating while the pre-defined process structure remains valid and can execute efficiently.
3Ease of operation
If design information includes detailed API information, then the system can directly coordinate with legacy systems, but this increases the difficulty of maintaining and updating processes
Solution Approach 1:
The patent segments design information into two distinct layers: process logic definitions (which are easy to maintain and understand) and API binding information (which handles the complexity of system coordination). This segmentation allows process designers to work with simplified abstractions while the system maintains the detailed API connections, thus improving both ease of operation and ease of manufacture.
Solution Approach 2:
The patent uses copying by creating abstract service interface definitions that represent the essential contract between processes and legacy systems. These interface definitions serve as templates or copies that can be instantiated with different actual API implementations, allowing the same process design to work with multiple API versions without modification.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
Provided are a system for business process automation and a method thereof. The system according to some embodiments may include a connect manager configured to register and manage application programming interface (API) information for services, a process execution engine configured to execute a target business process comprising a particular service task, which is a task using a particular service provided by a service module, and a connect broker configured to acquire API information for the particular service, registered through the connect manager, during execution of the target business process in response to a request from the process execution engine, and process the particular service task by sending a request for the particular service to the service module using the acquired API information.