80 likes | 99 Views
This workflow framework provides granular control over triggering actions on custom messages, with static and dynamic routing capabilities. It allows users to define rules, actions, and responses for event triggering in a flexible and embedded application control environment.
E N D
Workflow Framework • There are many open-source workflow frameworks available such as: • OS Workflow - http://www.opensymphony.com/osworkflow • Open For Business -http://www.ofbiz.org • These solutions were investigated. Although robust and open-source(free), without additional custom changes, these solutions did not provide the granularity to trigger on custom messages like SCRIPT as well as provide static and dynamic routing of messages within the ePostRx framework. Therefore, to provide greater flexibility and embedded application control, the option of developing a home-grown solution was selected.
Workflow Framework (Con’t) • Rules are the basic building blocks of the ePostRx Rules Engine. Rules allow users to build criteria for workflow event triggering. Each rule is comprised of two (2) distinct parts: • Action defines what type of action to perform such as validate specific EDI data elements, or call functions. • There are various actions the user can define to trigger events. • Responsedefines the post event to perform after the initial action is successful. • There are various response the user can define to trigger events.
Workflow Framework (Con’t) • Each trading partner can have multiple, unique workflow types assigned, with each workflow containing multiple assigned rules. • Event driven model: • Unlike the traditional single-daemon process where users “drop” transactions into a processing bucket and external threads poll for specific events, this model provides greater scalability and management of transactions. • Each thread owns an instance of the Rule-Workflow Object and can control the functionality necessary to process a message or order request until completion.
Each trading partner (location) can have multiple, unique workflow types assigned, with each workflow containing multiple assigned rules
Workflow Framework Overview Item B to be Scrubbed by Workflow Y • Workflows contain X..rules. • Rules are comprised of action/response attributes. Rule1 Rule2 Rule3 Rule4…. Item A to be Scrubbed by Workflow X Rule1 Rule2 Rule3…. WorkflowManager, RulesManager and ActionManager classes comprise workflow processing Each item (line) to be processed is bound to a Rule Workflow class. All user defined rule action/responses are executed against the item. Depending upon each rule response, processing may continue to next rule or stop if error occurs. Rule execution state is maintained in the database.
Workflow Framework (Con’t) • Specific transactions can be synchronous which the user waits for a response. Other transactions will be asynchronous and continue background processing independent of the user’s initial request. • Asynchronous requests will be handled by Message Driven Beans (MDB) within the Application Server (AS) Container.
Workflow Framework (Con’t) • All workflow state is persisted in database tables. • All Rule Engine transactions are applied to an item of processing (i.e. Order line, SCRIPT message).. • Once a Rule Action is found to be TRUE, the corresponding Rule Response is invoked and the engine is released for the associated execution thread. • Rule business logic contained in java objects. Common interface to access rule objects from framework via ClassForName call.