Workflow Toolkit Integrates Applications via Mediator
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Integrating specialized software applications is resource-intensive and time-consuming, especially when APIs change or when one application needs to be updated to accommodate new features, leading to inefficiencies and increased costs due to the complexity of traditional software development processes.
Innovation Solution
The Workflow Toolkit provides a graphical development environment for creating an Extensible Workflow, allowing developers to integrate applications in a visual, declarative, and plug-and-play manner, using a graphical user interface to drag and drop components and metadata, which serves as an intermediary to manage interactions between applications, reducing the need for extensive software coding and enabling easy updates.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Productivity
If traditional software coding techniques are used to integrate applications, then integration can be achieved, but the process is time-consuming and resource-intensive
Solution Approach 1:
The patent introduces a workflow engine as an intermediary layer between applications. This workflow engine provides a standardized interface that mediates interactions between applications, allowing integration without direct coding between application boundaries. The workflow engine handles the complexity of communication protocols, data formats, and error handling, thereby reducing integration time and resource requirements.
Solution Approach 2:
The workflow engine serves multiple functions: it acts as a communication mediator, provides standardized interfaces for various applications, handles data transformation, and manages error handling. This multi-functionality eliminates the need for separate integration solutions for each application pair, significantly improving integration productivity.
2Adaptability or versatility
If applications are integrated using traditional coding methods, then integration can be established, but updates become complex and time-consuming when APIs change
Solution Approach 1:
The workflow engine serves as a buffer between applications and the integration layer. When APIs change, only the workflow engine needs to be updated to accommodate the new interface, while the connected applications remain unchanged. This intermediary approach isolates changes and prevents ripple effects through the entire system, reducing update time and improving adaptability.
Solution Approach 2:
The integration architecture is segmented into independent components: applications, workflow engine, and communication protocols. This segmentation allows the workflow engine to be updated independently without affecting application code, enabling faster adaptation to API changes while maintaining application stability.
3Adaptability or versatility
If specialized applications use custom protocols for communication, then application functionality is optimized, but integration complexity increases
Solution Approach 1:
The workflow engine acts as a protocol translator and mediator between applications using different custom protocols. It receives data from one application format, transforms it into the required format for another application, and handles the communication. This abstraction layer hides the complexity of custom protocols from the integration layer, maintaining application functionality while reducing integration complexity.
Solution Approach 2:
The workflow engine manages parameter transformations between different application protocols. It automatically converts data types, formats, and communication parameters between applications, allowing each application to maintain its optimized functionality while the integration layer handles the complexity of parameter reconciliation.
Data Source
AI summary
A framework for integrating applications using the Workflow Toolkit provides a graphical development environment for developing an Extensible Workflow. The Workflow Toolkit may include a user interface displaying a first list of application programming interface (API) services provided by a first application and a second list of API services provided by a second application. The Workflow Toolkit may then generate an integration component in response to a user selecting both a first API service from the first list and a second API service from the second list. The integration component can then be called from the first API service, and the integration component in turn calls the second API service. In response to the second API service being called, the second API service may return a result. When this result is received by the integration component, the integration component may return an integration result based on the result received from the second API.