Workflow Framework There are many open-source workflow frameworks available such as: –OS Workflow - –Open For Business - 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. –Response defines 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

Example ‘Dispense’ Workflow Rules

Workflow Framework Overview Workflows contain X..rules. Rules are comprised of action/response attributes. Item B to be Scrubbed by Workflow Y 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. Rule1 Rule2 Rule3 Rule4…. Item A to be Scrubbed by Workflow X Rule1 Rule2 Rule3…. WorkflowManager, RulesManager and ActionManager classes comprise workflow processing

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.