Reusable Business Sub-processes Runtime Assembly
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current business process orchestration languages, such as BPEL, restrict the use of sub-processes and lack flexibility, requiring them to be deployed as standalone executable processes, which limits re-usability and increases the divide between business process models and implemented models due to differing skill sets between business architects and IT designers.
Innovation Solution
A method that allows the design of business processes using sub-processes, where services are assembled at runtime into an executable process, enabling re-usability and abstraction from underlying IT infrastructure, without the need for deployment, using a web-based administration interface to define and invoke services dynamically.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If sub-processes are deployed as standalone executable processes in traditional orchestration languages like BPEL, then the process can be executed reliably, but the flexibility and re-usability of sub-processes is restricted
Solution Approach 1:
The patent segments the business process into reusable sub-processes that can be independently defined and assembled. Sub-processes are broken down into service components that can be dynamically selected and combined at runtime, allowing the same sub-process to be reused across multiple parent processes without requiring separate deployments for each usage scenario.
Solution Approach 2:
The patent introduces dynamic assembly of executable processes at runtime based on process definitions stored in a database. Instead of static deployment, the system dynamically constructs executable processes by assembling service components from sub-processes according to the defined business process logic, enabling flexible reconfiguration without redeployment.
2Ease of manufacture
If IT designers develop BPEL processes using orchestration languages, then the process can be executed technically, but the resulting process may not align with the business architect's original model due to different skill sets
Solution Approach 1:
The patent introduces a process definition system that acts as an intermediary between business architects and IT designers. Business architects can define processes using a high-level process model that is then translated into executable form by the system, preserving the original business intent without requiring IT designers to interpret and recreate the logic from scratch.
Solution Approach 2:
The patent enables direct copying of process definitions from the business process model to the executable process implementation. The process definition stored in the database serves as a faithful copy of the business architect's model, which is then used to assemble the executable process, eliminating the need for manual reinterpretation by IT designers.
3Reliability
If sub-processes require special treatment such as error handling and partner links, then the process can be executed correctly, but the complexity of process definition and deployment increases
Solution Approach 1:
The patent creates a universal sub-process definition structure that handles multiple functions including error handling, partner links, and service invocation within a single standardized framework. This universal approach allows the same sub-process definition to be used across different parent processes without requiring duplicate error handling or partner link configurations for each usage scenario.
Solution Approach 2:
The patent merges previously separate concerns (error handling, partner links, service invocation) into a unified sub-process definition structure. By combining these elements into a single standardized sub-process template, the system eliminates the need for repetitive configuration and reduces overall process definition complexity while maintaining execution correctness.
Data Source
AI summary
Particular embodiments provide a method for orchestrating an order fulfillment business process that includes a sub-process. In one embodiment, abstraction of business processes from an underlying information technology (IT) infrastructure is provided. An orchestration process can be designed using sub-processes such that the sub-process is assembled at run-time into an executable process. The sub-process may be defined in an interface as a single step. A plurality of services as then assembled as steps in the executable process at run-time.