Triggering workflows based on middleware events

[0001] This application claims foreign priority to Indian patent application No. 26/DEL/2006, dated Jan. 2, 2006, deemed to have been filed on December 30, 2005, the entire contents of which are incorporated herein by reference.

[0002] “Middleware” is a software platform aimed at enabling synchronization of data from backend systems on to remote devices (e.g., dial-up computer terminals; personal digital assistants (PDAs)). Middleware provides data consolidation from the backend, identifying what data needs to go to which users. Data is queued by the middleware. When a user comes online from a remote device, the middleware synchronizes with the remote device, downloading the queued data to the remote device.

[0003] In general, a “front-end” is a type of program or process that is responsible for collecting input from a user (e.g., a user interface), whereas a “backend” is a type of program or process that is responsible for processing the input from the front-end. A backend is not directly accessed by a user, and may carry out tasks independent of the front-end. For example, a user could request data from a database, not knowing that the data is refreshed on the backend on a daily basis. Among other responsibilities, a backend establishes virtual connections (sockets) between processes.

[0004] After synchronization between the middleware and a remote device, a user may go offline and perform various tasks. The next time the user comes online, the data is again synchronized between the remote device and the backend system through the middleware.

[0005] Middleware uses a queue or queues in order to enable fast synchronization. Until the user comes online the data remains queued. A synchronization module on the middleware and/or the remote device extracts the data from the queue and synchronizes with the remote device. Such data might include sales orders, invoices, purchase approvals, etc. If the user does not come online for days or weeks, the result may be a loss of business opportunities as the data remains waiting in the queue.

[0013] The problem of time-critical business opportunities languishing in the middleware queue can be remedied by enabling “events” in the middleware through a set of rules and call back functions. Events are time-based triggers that trigger workflows.

[0014] The middleware queues user-specific data for a plurality of users. At least some of the data may be time sensitive. As a solution to the problem of time-critical opportunities languishing in the queue, responsive to the time sensitive data being queued, a time-based trigger (“event”) is created based at least in part upon content of the time-sensitive data. If the time-sensitive data is still in the queue when the first time-based trigger expires, a destination of the time-sensitive data is changed.

[0015] The content of the data upon which the events are based may include (among other things) priority flags, attributes of the data, and rules embedded in the data. Embedded rules may include instructions to implement actions after a certain period of time.

[0016] In conjunction with the creation of events based on the content of the data, or as an alternative data management mechanism, a rules engine may provide a mechanism to define rules based on attributes of the data and to define the necessary action that needs to be initiated when the rule is fulfilled. Rules engines are software-based control systems that operate based upon defined models and rules.

[0017] The middleware executes the rules and triggers function modules as needed to execute workflows specified by the rules. A workflow is a process that manages the routing of tasks to individuals or groups of users. Workflows automate business processes by integrating tasks across departments, applications, and system boundaries. A workflow maps individual tasks needed to complete the workflow to users/groups, automatically informing users/groups of user of their role in the workflow and providing them with whatever information is required for the task. Steps which do not require user intervention may be carried out automatically.

[0018] To manage time-sensitive data, the middleware may interact with a workflow engine. A “workflow engine” is a software-based control system that manages workflows. A workflow engine may operate in conjunction with a rules engine to define the behavior of particular workflows. The backend of software platforms such as groupware (e.g., Lotus® Notes®, Microsoft® Outlook®) and collaboration systems with integrated management capabilities such as financial management, customer relationship management, and sales management (e.g. SAP® Business One) may coordinate data distribution with a workflow engine, which may operate as either an independent process or as a component of a software application.

[0019] In addition to designating to whom data needs to go, a workflow engine may monitor the progress of a workflow task, automatically send reminders, automatically move a workflow task from one user to another if action on the task is not timely, and automatically designate a next recipient or recipients to receive the workflow when a user fulfills their assigned task in the workflow. Workflow engines may integrate data from other sources to determine whether a task needs to be redistributed. For example, a workflow engine may automatically monitor things such as groupware out-of-office data to determine that a designated user for a workflow will be unavailable, such that a workflow task needs to be reassigned.

[0020] In existing systems, the workflow engine loses control of data while it is sitting in a middleware queue. If the workflow engine determines that data needs to be moved while the data is sitting in the queue for delivery, the conventional recourse is for the workflow engine to send a recall notice to the same user, which itself is then added to the middleware queue for delivery to that user (together with the original data to be recalled). An analogous circumstance can be seen in Microsoft® Outlook®, where a recall notice is not acted upon until the recall notice is delivered to the user. While this data management scheme works, disadvantages include the need for the workflow engine to maintain a copy of the original workflow (if the workflow engine is enabled to recall and resend a workflow while the original task is stuck elsewhere), and the queue capacity and communication bandwidth wasted on delivering both the queued task and the recall notice to the user originally designated to receive the task.

[0021] Ordinarily, when data goes into a middleware queue, there is no way to know whether it will be acted upon after queuing. By setting an “event” within the middleware, whether queued data is acted upon can be better managed. The use of events created when data is placed in the queue, and updating or canceling the event when the data is removed from the queue or acted upon is computationally more efficient than polling the queue to determine the status of time-sensitive data.

[0022] FIG. 1 is a block diagram of an example system including middleware 120 that manages time sensitive data using events. The system includes a backend system 110, which represents the backend of a software application or process. Preferably, the backend 110 is a component of a collaboration system with integrated management capabilities, although any software process might be used. The backend 110 may coordinate with a workflow engine 112. The workflow engine 112 may be a component of a same software package as the backend 110, or may be a separate process.

[0023] Referring to FIG. 2, the backend coordinates (210) with the workflow engine 112 to create a workflow object. The information core of a workflow is a workflow object, such as a “business object”. A business object is data representing an entity in the real business world. For example, a business object can represent customers, contact persons, products, sales opportunities, sales activities, sales promotions, business transactions (e.g., a purchase order), a contract, a policy, and an application (e.g., a loan application). Each business object has elements that can be modeled to capture business data.

[0024] The inner structure of a business object is ordinarily concealed from a user. A business object may comprise persistent data (e.g., data tied to a database) and embedded business logic. The business logic is composed of machine-executable instructions which govern the behavior and properties of the object, including how the data is organized for presentation and the inter-relationship of data. Properties of the object may represent the attributes of the entity in the real business world, providing business “meaning” behind object data. For example, a Sales Order object can have properties like order number, order date, and quantity. The business logic may also include machine-executable instructions for performing specific operations such as the manipulation and validation of data. For example, the Sales Order object can have a method to calculate and get the line-items total.

[0025] When creating the business object, the coordination between the workflow engine 112 and the backend 110 and may include such things as determining to whom the object should be sent first.

[0026] Once the object has been created, it may be sent (212) to a queue 122 (i.e., data storage memory) of middleware 120 for delivery to the assigned user or users. The data remains in the queue until a user device connects to accept delivery.

[0027] To create and manage events for time-sensitive data, an event generator 128 has been added to the middleware 120. The event generator 128 selectively creates an event when data is added to the queue 122. As mentioned above, the creation of discrete time-based “events” in the middleware is considerably more efficient than periodically polling the queue.

[0028] Several methods can be used to create an event.

[0029] As a first method to create an event, a time-sensitive flag is added to the object by the backend 110 and/or workflow engine 112 before it is sent to the middleware 120. Responsive to the event generator 128 detecting the flag when the object is added to the queue 122, the event generator 128 determines (214) which rule or rules apply to the object in coordination with a rules engine 114. The rules engine 114 may be part of the middleware 120, may be the same rules engine as used by the workflow engine, or may be a another process. Once the appropriate rule is determined, an event is created (216).

[0030] The event generator 128 may extract various data from an object that is tagged as time-sensitive such as the subject matter of the object (e.g., sales order) and a due date. Based on such data, the rules engine 114 searches for a matching rule, from which an event can be created (216). For example, a rule might indicate that if a due date falls upon a weekend, to redirect the object to a different user prior to the weekend. Rules may also factor in other data available to the middleware 120. For example, if statistics are kept on the frequency with which a user connects to the middleware 120, a rule may include a heuristic to set the event trigger based in part upon such frequency statistics (e.g., if the time until the deadline is less than the statistically likely next connection to the user, advance the event to trigger at an earlier time).

[0031] As a second method, the rules for the creation of events may be incorporated into the object by the backend 110 and/or workflow engine 112. Such rules might include an instruction to be interpreted by the event generator 128, or to invoke a particular function module of the middleware 120. Such an object may or may not include a time-sensitive flag. The logic for the creation of events may be included in the object by the backend 110 or workflow engine 112 specifically for execution by the event generator 128 in the middleware 120, or may be logic that is included in the object without consideration that the event-aware middleware 120 is in the communications chain with the user. As an example of the latter, the workflow engine 112 may embed detailed logic for the entire workflow (e.g., the sequence of recipients, due dates, reminder dates, alternate recipients) within an object without consideration of the event-aware middleware 120, which the event generator 128 may use to generate an event.

[0032] As a third method, the event generator 128 may inspect objects submitted to the queue 122 and determine whether an event should be generated based on whether a rule or rules apply. In other words, even if no time-sensitive tag or event logic is embedded in the object, the event generator can make a determination as to whether the creation of an event is appropriate. As described above, the event generator 128 may extract data from the object, determine (214) if there is a rule for such an object in coordination with a rules engine 114, and generate an event (216) in accordance with the rules.

[0033] As a simpler implementation, the event generator 128 may create the event by simply extracting a due date from the object and setting the event trigger to the due date.

[0034] These methods may all be applied by a same event generator 128. In practice, the queue 122 may be receiving data from a variety of different backends 110 capable of varying levels of integration with the middleware 120. While the middleware 120 application programming interface (API) may signal to a backend 110 that event generation is available, the particular application may or may not be set up to tag data as time-sensitive, etc. Accordingly, the middleware 120 may determine which event-generation method to apply based upon the source application and/or format of the object. This may be determined, among other ways, by inspecting the object to determine the source application or format, by monitoring the origin of the transaction providing the object to the middleware 120 for queuing, or based on whether an object includes a time-sensitive field (even if the field indicates that the object is not time-sensitive). In addition, the event generator may impose a default rule on all objects not otherwise being assigned an event, such as a rule to make sure that no object remains in the queue for more than a threshold length of time (e.g., return to sender all data remaining in the queue for more than a month).

[0035] When an event is triggered (220), the event generator may again apply a rule to determine what action is required. A rule designation may have been included with the event when the rule was created (216) indicating which rule to apply if the event is triggered; rule-based logic may be embedded with the event when the event is created; a new rule lookup may be performed (222) to determine which rule should be applied contemporaneous with event triggering (220); and/or the rule or rules to apply upon triggering (220) may be embedded in the object itself. If an action specified in a rule (embedded or otherwise) is unsuccessful, the event generator may iteratively apply rules from the rules engine 114 until there is a successful execution.

[0036] For example, in FIG. 2, execution (230) of a rule may indicate that the event generator 128 should invoke a function module within the middleware 120 to designate that the object should be queued for a different user (232), update the event (236), and notify (234) the workflow engine 112 about the change. The workflow engine 112 is notified of changes for the object so that (among other reasons) accurate workflow status information is available.

[0037] If, however, a rule indicates that the object should be queued for a different user, but a user registrar 126 of the middleware indicates that the user is not affiliated with the middleware 120, then another rule may be executed (e.g., 330 in FIG. 3). In particular, this can occur when logic or data embedded in the object indicates to whom the workflow should be routed, but that user is not registered with the user registrar 126.

[0038] For example, a registrar-miss might occur if the middleware 120 is a subscriber-based communications channel and is only one of the communications channels available to the backend 110. The middleware 120 may exist to sync with a certain subset of users (e.g., PDA users), whereas the backend 110 may also have use of other channels such as e-mail.

[0039] As illustrated in FIG. 3, a rule upon execution (330) may instruct the event generator 128 to invoke a function module within the middleware 120 to bounce (332) the object out of the queue and clear (338) the event. When an object is bounced from the queue, it is deleted from the queue and sent back to the workflow engine 112, backend 110, or where ever else the rule may designate.

[0040] FIG. 4 illustrates the operations of the event-aware middleware 120 when a client connects to synchronize data. The user device 160 opens (452) a communication session with the middleware 120 via network 132. Data in the queue 122 for the user, including an object associated with an event, is downloaded to the device 160, and data from the device 160 is uploaded (456) to the middleware (456). At some point thereafter, the communication session between the device 160 and middleware 120 is closed (458).

[0041] The event generator 128 may monitor the queue 122 or the inbound/outbound handler 124 to determine when an object associated with an event is transmitted, or the inbound/outbound handler 124 may be modified to determine when an object associated with an event is transmitted. The event associated with the object is cleared (338) and an automatic notification may be sent (234) to the workflow engine 112 for workflow tracking purposes.

[0042] The event-aware middleware 120 may relay data to a user via a remote communications station 140 (FIG. 1). A communication station 140 provides a local data store 144. When the remote devices 160 come online, the data is fetched from the local data store 144 instead of from the middleware 120. Synchronization using the remote communication station 140 may be more efficient for the user than if the user established a communication session directly with the middleware 120 of a central system. For example, in geographic regions where long-distance communications are slow or erratic, being able to synchronize with a local data store accelerates performance.

[0043] The data can either be pushed to the communication station 140 from the middleware 120 or the data can be pulled from the middleware 120 by the communication station 140. In either case, communication sessions preferably occur at periodic intervals.

[0044] Among other advantages, remote communications stations 140 permit data to be aggregated for multiple users and downloaded when the user devices 160 are offline, while enabling the session to be scheduled at non-peak hours (e.g., when there are lower telecom costs or less network traffic). For example, if the communication station is in the United States and the middleware server is in Europe, the data can be downloaded to the communication station at night time of the United States when the network traffic is less and additionally when all the clients in the United States connect in the morning, they utilize only the local network providing fast and speedy synchronization. Downloading to the communication station 140 also facilitates high data volumes at synchronization.

[0045] The middleware 120 aggregates data from a backend system or systems 110 in the queue 122 for a plurality of users. Referring to FIG. 5, after a communication session is opened (562), the data in the queue 122 is transmitted to the communications station 140 from the middleware 120 over the network 130. The communication session may be opened (562) by either the middleware 120 or the communications station 140. The opening of the communication session (562) may be periodically initiated, may be initiated based on the quantity of data filling the queue 122 and/or local store 144, and/or may be based upon the urgency of data held in the queue 122 and/or local store 144 (e.g., a rule may indicate that if extremely time-sensitive data is added to the queue 122 or local store 144, a session should be opened at a non-scheduled time).

[0046] A server communication handler 142 within the communications station 140 handles transactions with the middleware 120. Aggregated data received (564) from the middleware 120 is held in a local store 144.

[0047] After the communication session between the middleware 120 and the communications station 140 closes (568), if a remote device 160 connects to the communications station 140 via network 150, a client communication handler 146 downloads (570) data from the local store 144 to the device 160. The client communication handler 146 also uploads (572) any data on the device 160 intended for the middleware 120 and queues it in the local store 144. Pooled data uploaded from the devices 160 will be transmitted (566) to the middleware 120 during the next session between middleware 120 and the communication station 140.

[0048] To optimize bandwidth, if duplicate data is needed on a plurality of remote devices 160 associated with a particular communications station 140, it can be transmitted once during a session with the communications station 140 and then copied by the communications station as needed during individual sessions with the remote devices 160. This also facilitates using a smaller local store 144 in the communications station 140. The communications station 140 may use a unique site identifier which the middleware 120 associates with all of the users assigned to that station 140.

[0049] If duplicate data is downloaded only once for a plurality of users, the unique data to download to a specific user may include a pointer (e.g., a uniform resource identifier) mapped to where the shared data will be stored in the local store 144.

[0050] Once unique data is downloaded from the local store 144 to the device 160 for a user, the unique data may be flushed from the local store 144. Likewise, once data from a user held in the local store 144 is uploaded to the middleware 120, it may be flushed from the local store 144.

[0051] Which users are associated with which communications stations 140 may be centrally defined in the user registrar 126 of the middleware 120.

[0052] In order to avoid time-managed data languishing in the local store 144 of the communications station 140, event management can also be enabled in the communications station.

[0053] Event generation and management in the communications station 140 may operate on the same principles described herein for the middleware 120. The communications station 140 may employ an event generator 148 having capabilities as described above for event generator 128, creating events (516) based on an analysis of an object received from the middleware 120, logic embedded in the object, and/or the application of locally stored rules to the object.

[0054] After the middleware 120 downloads (564) the aggregated data including at least some time-sensitive objects to the communications station 140, a notification may be sent (590) by the middleware 120 to the workflow engine 112 for tracking purposes.

[0055] During each session between the communications station 140 and a user device, the event generator 148 clears (538) the events for the data downloaded to the user.

[0056] Then, during the next session between the communications station 140 and the middleware 120 after a user downloads time-sensitive data from the communications station 140, a delivery notification or notifications are sent (580) from the communications station 140 to the middleware 120, and may then be forwarded (592) to the workflow engine 112.

[0057] FIGS. 6 and 7 illustrate an event trigger 620 occurring on the communications station 140 when an object is left sitting in the local store 144 without pick-up.

[0058] In FIG. 6, as specified by a rule, the event generator 148 reroutes (632) the workflow object to another subscriber of the same communications station. The communication station 140 also replaces (636) the event to reflect the change. During the next session between the communications station 140 and the middleware 120, the communications station 140 notifies (684) the middleware that the object has been rerouted. The notification may then be relayed (694) to the workflow engine 112.

[0059] In FIG. 7, as specified by a rule, the event generator 148 bounces (786) the workflow object back to the middleware 120 and clears (538) the corresponding event. Bouncing might occur as the result of a first rule, or might be invoked when a first rule (e.g., FIG. 6) can not be carried out. The bounced message sent to the middleware 120 is preferably relayed to a target destination (e.g. backend 110; workflow engine 112) like ordinary data without processing.

[0060] If rules are stored on the communications station 140, they are preferably provided via the middleware 120 during a communication session. The rules stored on the communications station 140 can be a subset of the rules available to rules engine 114.

[0061] A rule may specify whether actions (e.g., 684, 786) dictated by the rule on the communications station 140 are communicated to the middleware 120 during a scheduled session, or whether a more-immediate session is initiated.

[0062] While the event generator 148 on the communications station 140 may operate in a similar manner to event generator 128, there may also be coordination between rules engines, lowering the processing requirements at the communications station 140 to manage events. For example, the event generator 128 in the middleware 120 can create a data file or files comprising events for particular users and transmit the data to the communications station 140 during a communication session. The rules and functions needed for execution upon the triggering of each event may also be included with the data.

[0063] If the middleware 120 or communications station 140 change the destination of a workflow object, a message may be sent to the original assignee that the task/job/order was reassigned.

[0064] While the examples use workflow objects as the time-sensitive data, the system can be configured to work with any kind of data. Even if the attributes of the data are not called out within the data itself, rules may be applied to determine whether an event should be generated.

[0065] The various components of the middleware 120 and/or the communications station 140 described herein may each be implemented as one or more processes on one or more computer systems. Each computer system may include a storage component for storing machine-readable instructions for performing the various processes described above. The storage component may be any type of machine readable medium (i.e., one capable of being read by a machine) such as a compact disk, hard drive memory, flash memory, floppy disk memory, DVD-ROM, CD-ROM or any type of machine readable (computer readable) storing medium. Each system or systems may also include addressable memory (e.g., random access memory, cache memory) to store data and/or sets of instructions that may be included within, or be generated by, the machine-readable instructions when they are executed by a processor on the respective system. The queue 122, local store 144, and user registrar 126 each include memory that may be selected from addressable memory (e g., random access memory, cache memory) and a rewritable storage component (e.g., hard drive memory, flash memory, floppy disk memory).

[0066] Several embodiments of the invention are specifically illustrated and/or described herein. However, it will be appreciated that modifications and variations of the invention are covered by the above teachings and within the purview of the appended claims without departing from the spirit and intended scope of the invention.