US20080313003A1 - Designing business processes using parametric roles - Google Patents

Designing business processes using parametric roles Download PDF

Info

Publication number
US20080313003A1
US20080313003A1 US10/114,585 US11458502A US2008313003A1 US 20080313003 A1 US20080313003 A1 US 20080313003A1 US 11458502 A US11458502 A US 11458502A US 2008313003 A1 US2008313003 A1 US 2008313003A1
Authority
US
United States
Prior art keywords
role
organizational
activity
business process
value
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US10/114,585
Inventor
Felix G. Racca
Emilio L. Gabeiras
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
BEA Systems Inc
Original Assignee
BEA Systems Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by BEA Systems Inc filed Critical BEA Systems Inc
Priority to US10/114,585 priority Critical patent/US20080313003A1/en
Assigned to FUEGO, INC. reassignment FUEGO, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: GABEIRAS, EMILIO L., RACCA, FELIX G.
Assigned to BEA SYSTEMS, INC. reassignment BEA SYSTEMS, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: FUEGO, INC.
Publication of US20080313003A1 publication Critical patent/US20080313003A1/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00Administration; Management
    • G06Q10/06Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00Administration; Management
    • G06Q10/06Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063Operations research, analysis or management
    • G06Q10/0631Resource planning, allocation, distributing or scheduling for enterprises or organisations
    • G06Q10/06311Scheduling, planning or task assignment for a person or group
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00Administration; Management
    • G06Q10/06Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063Operations research, analysis or management
    • G06Q10/0631Resource planning, allocation, distributing or scheduling for enterprises or organisations
    • G06Q10/06311Scheduling, planning or task assignment for a person or group
    • G06Q10/063114Status monitoring or status determination for a person or group
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00Administration; Management
    • G06Q10/06Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063Operations research, analysis or management
    • G06Q10/0631Resource planning, allocation, distributing or scheduling for enterprises or organisations
    • G06Q10/06316Sequencing of tasks or work
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00Administration; Management
    • G06Q10/06Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063Operations research, analysis or management
    • G06Q10/0633Workflow analysis

Definitions

  • This invention relates generally to the field of business process design and more specifically to designing business processes using parametric roles.
  • a business process includes a series of activities that are undertaken to perform the operations of an organization.
  • a business process may describe activities for processing a sales order, such as the steps of receiving a sales order, checking the payment history, checking the inventory, and so on.
  • An organization may automate a business process by having a computer perform some activities such as receiving a sales order.
  • a business process may also be automated by having a computer remind human participants of activities that need to be performed. For example, a computer may send an email message notifying an account manager to check the payment history of a client.
  • automating a business process includes defining an activity of a business process.
  • the activity is associated with an abstract role, and the abstract role represents a user responsible for performing the activity.
  • An organizational role associated with a set of values is defined.
  • the organizational role can have a value from the set of values, where each value corresponds to a user set.
  • the organizational role is matched to the abstract role.
  • An instance of the activity is received, and the value for the organizational role is determined. The instance is routed to the user set corresponding to the determined value.
  • a technical advantage of one embodiment is that business processes may include activities with compensation tasks. Compensation tasks are executed when a task of an activity fails to execute, thus allowing for the performance of the activity to continue uninterrupted to completion. Compensation tasks may be used for automated business processes to maintain business process consistency.
  • an activity may be associated with an abstract role in order to specify users representing people responsible for performing the activity.
  • the association may provide for abstract business process modeling, which may allow for the creation of business process templates creation that may be used for different organizations.
  • Another technical advantage of one embodiment is that the processes of publishing and deploying business processes are separated. By separating the publication and deployment processes, a business process may be published and tested, without deploying the business process to users.
  • Another technical advantage of one embodiment is that persistent variables are used. Persistent variables allow a value related to an instance of a business process to be efficiently carried from one activity of the business process to another activity of the same business process or of another business process.
  • FIG. 1A is a block diagram of one embodiment of a system for automating a business process in accordance with the present invention
  • FIG. 1B is a block diagram of one embodiment of a data repository that may be used with the system of FIG. 1A ;
  • FIG. 2 illustrates one embodiment of designer screen that may be used for automating business process modeling
  • FIG. 3 illustrates one embodiment of task table that may be used for recording tasks and compensation tasks for a business process activity
  • FIG. 4 illustrates one embodiment of an activity properties screen that may be used to define tasks and compensation tasks
  • FIG. 5 is a flowchart illustrating one embodiment of a method for defining, implementing, and executing tasks and compensation tasks
  • FIG. 6 illustrates one embodiment of an organizational roles screen that may be used to configure organizational roles that can have values
  • FIG. 7 illustrates one embodiment of assign organizational roles screen that may be used to assign organizational roles to users
  • FIG. 8 illustrates one embodiment of a match roles screen that may be used to match abstract roles with organizational roles when an abstract business process model is published to an organization
  • FIG. 9 is a flowchart illustrating one embodiment of a method for defining and implementing organizational roles
  • FIG. 10 illustrates one embodiment of a publish screen that may be used to publish and deploy a business process
  • FIG. 11 is a flowchart illustrating one embodiment of a method for publishing a business process
  • FIG. 12 is a flowchart illustrating one embodiment a method for implementing an instance variable at runtime or execution time
  • FIG. 13 is a flowchart illustrating one embodiment a method for implementing an argument variable when communicating to business processes
  • FIGS. 14 through 18 illustrate distributed process flow
  • FIG. 19 illustrates polymorphic sub-processes.
  • FIG. 1A is a block diagram of one embodiment of a system 100 for automating a business process.
  • a business process includes a series of activities that are undertaken to perform the operations of an organization.
  • a business process may describe activities for processing a sales order, such as the steps of receiving a sales order, checking the payment history, checking the inventory, and so on.
  • System 100 allows an organization to automate business processes.
  • a user group 110 may access system 100 through a communication network 114 .
  • An organization may use system 100 to implement business processes to solve problems.
  • User group 110 comprises a data set of user identifiers, which may represent, for example, people who may access system 100 using computing modules such as personal computers.
  • user group 110 may include a designer 122 , which represents a person who uses system 100 to design a business process model.
  • User group 110 also includes users 124 , which represent people who may be responsible for performing activities of a business process. For example, a user 124 may be responsible for receiving a sales order and verifying its completeness.
  • System 100 allows designer 122 to design a business process model. In turn, system 100 notifies users 124 of the activities that need to be performed.
  • Users 124 may be logically organized into user sets 123 , where users 124 of a user set 123 represent people who are responsible for the execution of specific activities.
  • the logical grouping of users may be defined and stored in system 100 .
  • a user 124 may be a member of any suitable number of user sets 123 .
  • user 124 c is a member of user sets 123 a and 123 b .
  • User sets 125 may be associated with, for example, organizational roles defined within an organization, such as a salesperson role.
  • Communication network 114 may include wired telecommunications, satellite, microwave, or other suitable wired or wireless networks, or a combination of the preceding.
  • System 100 includes an interface module 116 , modules 112 , and a data repository 118 .
  • Interface module 116 may include a website 126 , an interface 128 deployed in website 126 , and a security module 129 .
  • Website 126 allows for communication of information between user group 110 and system 100 .
  • Interface 128 may comprise a hypertext markup language (HTML) interface that receives instructions through a web server deployed in website 126 in order to perform operations included in instructions from users 124 .
  • Security module 129 may provide, for example, password security, resource access security, and/or system security. Security module 129 may be used for authentication procedures and may be adapted to the security policy and infrastructure of an organization.
  • System 100 provides advantages in automating business processes.
  • System 100 generates business processes that include compensation tasks.
  • a compensation task is executed when an associated task of a business process activity fails to execute, allowing the business process to achieve a steady and consistent state before its execution is retried.
  • the business process instance may proceed to the next business process activity.
  • system 100 allows for specification of people who are responsible for performing the activities of a business process through user sets 123 defined in system 100 , thus allowing an organization to readily automate the business process.
  • system 100 separates the processes of publishing and deploying business processes. By separating the publication and deployment processes, a business process may be published and tested, without being deployed to users 124 of the production environment. Furthermore, system 100 provides persistent variables, which allow a value to be transferred from one activity to another activity of the same business process or of a different business process using process arguments.
  • Modules 112 include a catalog manager 130 , a process designer 132 , an organizational settings module 134 , an execution console 136 , and execution engines 140 coupled as shown in FIG. 1A .
  • catalog manager 130 may be used to define and specify the components or programs that can be called from a business process.
  • Process designer 132 may be used to model business processes to be deployed in an organization.
  • Organizational settings module 134 may be used as a front-end module to define business process participants and how they are going to be organized.
  • Execution console 136 may be used to manage the execution engine in which business processes are deployed, and may be accessed by users 124 of user group 110 .
  • Execution engines 140 may be used to deploy business processes, execute tasks requested by users 124 , and perform automated business process activities.
  • Modules 112 may store and retrieve data using a data repository 118 that includes an organizational data repository 150 and a transactional database 170 .
  • catalog manager 130 defines, describes, and organizes components.
  • a component may comprise a modular software routine that has been compiled, and may be used with other components or programs.
  • Catalog manager 130 stores components in data repository 118 and supplies components to process designer 132 and execution engines 140 .
  • Process designer 132 is used to design business processes, which are stored in data repository 118 once the business processes are published. While the business process is being designed using Process Designer 132 , the business process model definition may be stored in a local computer. Business processes are described in more detail in connection with FIG. 2 . Process designer 132 may also be used to publish business processes to data repository 118 as well as to deploy business processes to execution engine 140 .
  • business processes are designed on a computer by manipulating graphical icons on a computer screen.
  • An example of a computer screen that may be used to design a business process is described in connection with FIG. 2 .
  • FIG. 2 illustrates one embodiment of a designer screen 200 for automating a business process 210 on a computer.
  • Business process 210 includes a sequence of activities 212 coupled by transitions 214 .
  • business process 210 may include a sequence of activities 212 for processing a sales order.
  • Each activity 212 comprises a series of tasks that are executed to complete activity 212 .
  • an activity 212 that notifies a client of an incomplete sales order may include the task of “sending an email message to the client.”
  • Tasks may execute components catalogued using catalog manager 130 and made available through publishing and deployment.
  • Activities 212 are placed in a designer window 202 .
  • Activities 212 may have a specific semantic, which may be designated by a particular color or shape. Custom colors and shapes may be used in response to user preference.
  • activity 212 a may be an activity that is used to begin a business process, and may be designated by a triangular shape pointing in the right-hand direction.
  • Activity 212 f may be an activity that is used to end a business process, and may be designated by a triangular shape pointing in the left-hand direction.
  • Transitions 214 are used to indicate a next activity that is to be initiated after executing a previous activity.
  • transition 214 a indicates that activity 212 b is to be initiated after the execution of activity 212 a .
  • Transitions 214 may indicate multiple next activities that are to be initiated after the execution of a previous activity.
  • transitions 214 b and 214 c indicate that activities 212 c and 212 d , respectively, are to be initiated after the execution of activity 212 b.
  • either one or both activities 212 c and 212 d may be initiated after activity 212 b .
  • business process 210 may be defined such that depending upon a decision made at activity 212 b , either activity 212 c or activity 212 d is initiated after the execution of activity 212 b .
  • transitions 214 may direct multiple activities to a single next activity. For example, transitions 214 d and 214 e direct activities 212 c and 212 d , respectively, to activity 212 e.
  • Business process 210 also includes abstract roles 216 that are used at design time to represent in the abstract user sets 123 that represent people of an organization who are responsible for performing an activity 212 .
  • Abstract role 216 may be matched to an organizational role.
  • An abstract role represents in the abstract a set of users responsible for performing the activity, and the organizational role may take on values that correspond to actual users 124 of an organization.
  • an abstract role represents a salesperson in the abstract, and the organizational role describes actual salespeople of an organization.
  • abstract roles are used instead of organizational roles, such that a single business process may be used for multiple organizations, incorporating the concept of template models.
  • An organizational role may be parametric, that is, the organizational role may be assigned a value that corresponds to user set 123 , and may take on multiple values that correspond to different user sets 123 .
  • Users 124 of user set 123 represent people responsible for performing activity 212 .
  • users 124 of one user set 123 may represent salespeople from one state
  • users of another user set 123 may represent salespeople from another state.
  • An organizational role may be used to create groups of users that can be instantiated with, for example, salespeople from different states.
  • An advantage of defining parametric roles is that the assignment of a user set 123 may be determined dynamically based on business process rules.
  • Abstract roles 216 are specified for activities 212 by placing activities 212 in the appropriate abstract role column.
  • abstract role 216 a is specified for activity 212 a
  • abstract role 216 b is specified for activities 212 b and 212 e .
  • business process 210 may include activities 212 coupled by transitions 214 and associated with abstract roles that may be associated with real organizational roles stored in data repository 118 .
  • organizational settings module 134 defines the settings for an organization.
  • Organizational settings may describe user sets 123 , organizational roles and associated values if the organizational roles are parametric, and organizational units of the organization.
  • Execution engines 140 manage the execution of instances of business processes 210 .
  • An example of an instance of a business process may be processing a specific sales order using a business process for processing sales orders.
  • Execution engine 140 is used to execute an instance of business process 210 that has been deployed on it.
  • Execution engine 140 retrieves and collects business process 210 definitions from organizational data repository 150 .
  • Execution engine 140 manages the execution of a particular task of a specific business process instance requested by a user 124 if the activity is interactive.
  • Execution engine 140 automatically executes the task if the activity is an automated one.
  • Each execution engine 140 may be associated with its own transactional database 170 that may comprise, for example, a relational database management system (RDBMS).
  • RDBMS relational database management system
  • Execution console 136 defines and manages execution engines 140 .
  • execution console 136 defines port settings for execution engines 140 and database settings for transactional databases 170 associated with execution engines 140 .
  • FIG. 1B is a block diagram of one embodiment of data repository 118 of system 100 of FIG. 1A .
  • Data repository includes organizational data repository 150 and transactional database 170 .
  • Organizational data repository 150 includes information that is typically maintained through multiple executions of instances of business processes, and may be received from organizational settings 134 and execution console 136 .
  • Organizational data repository 150 may comprise, for example, a lightweight directory access protocol (LDAP) database.
  • LDAP lightweight directory access protocol
  • Organizational data repository 150 includes business process definitions 152 and organizational data 154 .
  • Business process definitions 152 include activities, transitions between the activities, and abstract roles associated with the activities.
  • Business process definitions 152 may include a task table 159 that records the tasks of an activity and their associated compensation tasks. A compensation task is executed when its associated task fails to execute. The compensation task undoes things done by the associated task to a particular business process activity, resulting in a consistent state in case a task fails.
  • Task table 159 is described in more detail in connection with FIG. 3 .
  • Organizational data 154 includes information about the organization.
  • Organizational roles 160 include information about organizational roles and associated users 124 .
  • Organizational roles 160 are matched with abstract roles 216 in order to specify users 124 representing people who are responsible for performing the activities of business processes definitions 152 .
  • Matchings 164 record the association between abstract roles and corresponding organizational roles when publishing a particular business process using system 100 .
  • Transactional database 170 includes persistent variables that record information that is typically maintained for an instance of a business process. For example, a value describing the requested quantity of goods for a specific sales order is typically maintained for the instance that processes the specific sales order. The value is generally not needed for instances that process other sales orders.
  • Persistent variables include instance variables 172 and argument variables 174 .
  • Instance variables 172 record values that may be passed from one activity of a business process to another activity of the same business process.
  • Instance variables 172 may maintain the state of the instance within the context of a business process. For example, an instance variable may maintain the activity where an instance is at a given moment in time during the lifetime of the instance in a business process.
  • Argument variables 174 record values that may be passed from one business process to another business process.
  • System 100 provides advantages in automating business processes 210 .
  • Business processes 210 may include activities 212 with tasks associated with compensation tasks. Compensation tasks are executed when an associated task of activity 212 fails to execute, thus allowing for a consistent state. Compensation tasks are described in more detail in connection with FIGS. 3 , 4 , and 5 . Additionally, activities 212 may also be associated with abstract roles that are used to specify users 124 representing people who are responsible for performing the activity 212 , thus allowing an organization to readily automate business processes 210 . Organizational roles are described in more detail in connection with FIGS. 7 , 8 , and 9 .
  • system 100 separates the processes of publishing and deploying business processes 210 .
  • Business process 210 is published by matching abstract roles with organizational roles to specify users 124 representing people responsible for performing the activities of the business process 210 .
  • business process 210 may be tested in a testing environment.
  • the tested business process 210 is then deployed to make business process 210 available to users 124 of a production environment.
  • business process 210 may be published and tested, without deploying business process 210 to users 124 of the production environment, thus reducing risk of problems in the production environment. Publication and deployment of business processes 210 are described in more detail in connection with FIGS. 10 and 11 .
  • system 100 provides persistent variables, which allow a value related to an instance to be carried from one activity to another activity within the same business process or between different business processes. Persistent variables are described in more detail in connection with FIGS. 12 and 13 .
  • FIG. 3 illustrates one embodiment of a task table 300 that records tasks 310 and compensation tasks 312 .
  • Activity 212 includes a sequence of tasks 310 that are performed in order to complete activity 212 .
  • Activity 212 may describe, for example, notifying a client of an incomplete sales order.
  • Tasks 310 may be written in any suitable computer language and may invoke components implemented in a different computer programming language such as C, C++, Fortran, Cobol, or Basic.
  • a task 310 may be associated with a compensation task 312 that is specified to be executed in task 310 .
  • Compensation task 312 is only executed if its associated task fails.
  • Task 1 which may represent “send email message to the client and to the financial department” is associated with compensation Task 3, which may represent “send a disregarding email message to the client if the email message could not be sent to the financial department”.
  • Task 3 is performed if Task 1 fails.
  • a task 310 is not required to have a compensation task 312 .
  • Task 2 which may be “send a fax to the client,” has no associated compensation task 312 . Recording tasks 310 and associated compensation tasks 312 in task table 300 provides for efficient and organized storage of tasks 310 and compensation tasks 312 .
  • FIG. 4 illustrates one embodiment of an activity properties screen 320 or task definition screen, that may be used to define tasks 310 and compensation tasks 312 of activity 212 .
  • Activity properties screen 320 includes an activity tasks section 322 and a set of available tasks section 324 .
  • Activity tasks section 322 includes windows 326 and 330 and boxes 328 and 332 that may be used to define tasks 310 and compensation tasks 312 of activity 212 .
  • the name of task 310 may be inserted in task name window 326 , and a required box 328 may be selected in order to indicate that task 310 is mandatory to complete an instance of activity 212 .
  • a mandatory task may comprise a task that must be completed in order to route an instance from one activity to another activity. In one embodiment, mandatory tasks must be completed in order to route an instance from one activity to a next activity to continue execution of activity 212 . In the illustrated example, Task 1, “send an email message to the client and to the financial department” must be completed in order to continue execution of activity 212 .
  • Compensation task 312 may be defined by inserting the name of compensation task 312 into compensation task name window 330 , and a repeatable 332 box may be selected in order to indicate that task 310 may be repeated a number of times.
  • An add button 334 a , an edit button 334 b , and a remove button 334 c may be used to add, edit, or remove tasks 310 from activity 212 . When a task is added, the new task appears in task name window 326 .
  • Tasks 310 and compensation tasks 312 for activity 212 may be selected from set of tasks section 324 .
  • Set of tasks section 324 includes a name window 334 and a description window 336 that lists the names and descriptions, respectively, of available tasks that may be selected for activity 212 .
  • Activity properties screen 320 allows designer 122 using Process Designer 132 to readily specify tasks 310 and associated compensation tasks 312 of activity 212 , thus providing for efficient design of business processes 210 .
  • FIG. 5 is a flowchart illustrating one embodiment of a method for defining and implementing tasks 310 and compensation tasks 312 of activity 212 .
  • Task 1 which is “send an email message to the client and to the financial department” is associated with compensation Task 3, which is “send a disregarding email message to the client if the email message could not be sent to the financial department”.
  • Task 3 is performed if Task 1 fails, that is, if the email message cannot be sent to the financial department, then a disregarding email message is sent to the client.
  • step 350 process designer 132 displays activity properties screen 320 , which may be used to generate tasks for activity 212 .
  • Activity properties screen 320 may be displayed in response to a user request through process designer 132 .
  • a user may, for example, click on activity 212 of designer screen 200 of FIG. 2 to request activity properties screen 320 .
  • Activity properties screen 320 may be used to specify tasks 310 and associated compensation tasks 312 of activity 212 .
  • Task 1 is “send an email message to the client and to the financial department” and Task 3 is “send disregarding email message to the client if the email message could not be sent to the financial department”.
  • tasks 310 and associated compensation tasks 312 are defined. Tasks 310 and associated compensation tasks 312 are stored in task table 159 of organizational data repository 150 at step 354 .
  • an instance of activity 212 is requested to initiate execution of a task 310 . If activity 212 is interactive, then the request is received from user 124 . If activity 212 is automatic, then execution engine 140 initiates the execution of task 310 .
  • a task 310 for example, Task 1, of activity 212 is initiated by execution engine 140 at step 358 , that is, an email message is sent to the client and to the financial department.
  • Execution engine 140 may determine that Task 1 has failed at step 360 .
  • Execution engine 140 may, for example, receive a notification that a program responsible for executing Task 1, such as an email software program, cannot be located.
  • Execution engine 140 determines compensation task 312 associated with task 310 from task table 159 .
  • task table 159 of FIG. 3 specifies that Task 3 is the compensation task 312 associated with Task 1.
  • execution engine 140 initiates compensation task 312 to compensate for failed task 310 .
  • Task 3 may be initiated by sending a disregarding email message to the client.
  • the method terminates.
  • the method provides for efficient specification of compensation tasks 312 that are executed in the event an associated task 310 fails to execute.
  • FIG. 6 illustrates one embodiment of an organizational roles screen 400 that may be used to define organizational roles and associated values for an organization.
  • the organizational roles and associated values may be stored in organizational data repository 150 .
  • Organizational roles are matched with abstract roles of activity 212 when a business process model is published into an organization.
  • An organizational role may group users 124 with the same responsibility such that users 124 associated with an organizational role may perform the same operations or functions. For example, multiple users 124 may have the ability to perform the same activity 212 .
  • An organizational role may be parametric, that is, may take on values that may be associated with categories such as subsets of the group with which the organizational role is associated.
  • an organizational role associated with a sales role may take on values associated with sales team categories within the sales role.
  • Users 124 may be associated with organizational units in order to designate other groupings of users 124 , for example, groupings by department or location.
  • Organizational units may be associated with divisions or departments within an organization context. Information about the organizational units may be stored in organizational data repository 150 .
  • an organizational unit may be associated with a particular department such as a sales department or a particular office location such as a Dallas office location.
  • Organizational units may be used to group users 124 that may access published and deployed business processes. For example, an organization develops a business process for processing a sales order that deals with operations in a sales department and no other department. The business process may be published and deployed to an organizational unit associated with the sales department such that only users 124 of this particular organizational unit, and no other users 124 , may access the business process.
  • a value may also be associated with a time period.
  • an organization may have one value for telephone operators who work during a daytime period, and another value for telephone operators who work during a nighttime period.
  • An instance of activity 212 that occurs during a particular time period may be assigned the value corresponding to the time period.
  • an instance that occurs during a daytime period may be assigned the value for telephone operators who work during a daytime period.
  • An organizational role that has no specified value is assigned a default value.
  • An advantage of the parametric roles may be that only one activity may be needed for multiple parametric values, thus avoiding the need to specify multiple activities for multiple values.
  • Another advantage may be that a user set 123 associated with an instance may be determined dynamically based on business process rules.
  • Organizational roles screen 400 includes a role name window 410 and a description window 412 , where a name and a description, respectively, of an organizational role may be inserted.
  • an organizational role, Sales is described as an organizational role for sales teams.
  • a browse button 414 may be selected in order to view available organizational roles.
  • Value windows 416 may be used to define values that the organizational role may have if the organizational role is parametric.
  • Team A, Team B, and Team C are the defined values that the Sales may have.
  • Add and remove buttons 418 may be used to add and remove, respectively, values.
  • An assign organizational role button 420 may be used to display assign organizational roles screen that may be used to assign roles to users 124 , which is described in more detail in connection with FIG. 7 .
  • FIG. 7 illustrates one embodiment of an assign organizational roles screen 430 that may be used to assign organizational roles and values to users 124 .
  • the organizational roles and values may be stored in organizational data repository 150 .
  • Organizational roles are assigned to users 124 in order to create user sets 123 corresponding to the organizational roles.
  • a user I.D. window 432 , a name window 434 , and an email address window 435 may be used to specify user 124 by inserting the user identification, name, and email address, respectively, of user 124 .
  • a browse button 436 may be used to view a list of available users 124 .
  • An organizational unit button 438 may be used to select an organizational unit 162 for user 124 referenced in user I.D. window 432 .
  • the information may be stored in organizational data repository 150 .
  • An organizational roles section 440 may be used to define organizational roles assigned to user 124 .
  • Role name windows 442 and value windows 446 may be used to specify organizational roles and values for parametric organizational roles, respectively, assigned to user 124 .
  • a Sales role having Team A value, and a Training role are specified for JDOE.
  • Permission windows 444 are used to specify the actions a user may perform in a specified role. Possible permissions may include: execute task, abort instance, suspend instance, and route instance. The permission may be assigned to a particular user 124 , which may provide for different users 124 associated with the same organizational role having different permissions.
  • Add and remove buttons 448 may be used to add or remove, respectively, organizational roles.
  • Organizational roles screen 400 and assign organizational roles screen 430 thus allow for efficient specification of organizational roles, values, and user sets 123 .
  • organizational settings module 134 may be used to define and configure users 124 , organizational roles 160 , and organizational units 162 .
  • FIG. 8 illustrates one embodiment of a match roles screen 450 that may be used to match abstract roles with organizational roles when a business process is published into an organization.
  • Match roles screen 450 includes abstract role windows 452 and organizational roles windows 454 that may be used to specify the abstract roles and organizational roles to be matched.
  • Abstract Role 1 is matched with a Sales organizational role
  • Abstract Role 2 is matched with a Training organizational role.
  • Parametric boxes 456 may be used to specify whether a role is parametric. Software based on the abstract role definition may be used to determine whether a role is parametric. If an organizational role is parametric, value windows 458 may be used to specify a value for the organizational role. In the illustrated example, a Team A value is specified for Sales, and nothing is specified for Training.
  • FIG. 9 is a flowchart illustrating one embodiment of a method for defining and implementing organizational roles.
  • assign organizational roles screen 430 is used to assign Sales and Training roles to user 124 JDOE.
  • Match roles screen 450 is used to match abstract roles of business process 210 with organizational roles defined in organization data repository 150 .
  • user 124 JDOE may have access to activities 212 a , 212 b , and 212 e because user 124 JDOE has been assigned the Sales and Training roles.
  • user 124 JDOE is allowed to participate in the execution of activities 212 a , 212 b and 212 e.
  • the method begins at step 462 , where an activity 212 is associated with an abstract role.
  • An abstract role is created using process designer 132 . Once the abstract role has been created, activity 212 can be located within the abstract role location. In this case, activity 212 belongs to a specific domain delimited by the abstract role. Activity 212 may be defined and abstract role may be specified using designer screen 200 of FIG. 2 . Activity 212 and the associated abstract role are stored with business process 210 in organization data repository 150 .
  • Organizational roles are added at step 464 using organizational settings module 134 .
  • Organizational roles screen 400 may be used to generate a request to define organizational roles. Values may be specified for a parametric organizational role.
  • users 124 are assigned to organizational roles. The assignment specifies the activities for which users 124 may participate in the execution. In the illustrated example, Sales and Training are specified for user 124 JDOE. Values may be specified for organizational roles that are parametric. In the illustrated example, a Team A is specified for Sales, and no value is specified for Training since Training is not parametric.
  • organizational settings module 134 stores the organizational notes and corresponding users 124 in organization data repository 118 .
  • Business process 210 may be published at steps 472 and 474 using process designer 132 or execution console 136 .
  • Match roles screen 450 to generate a request to match abstract roles with organizational roles is displayed.
  • a user 124 such as an administrator may use match roles screen 450 to generate a request matching the abstract role and the organizational role.
  • the request is received at step 472 .
  • the abstract role and the organizational role are matched and stored at step 474 .
  • Abstract Role 1 is matched with Sales
  • Abstract Role 2 is matched with Training.
  • the matching is stored in organization data repository 150 .
  • execution engine 140 receives a request from user 124 to determine activities 212 that user 124 has access or authorization to process. User 124 is validated and is connected to execution engine 140 . Execution Engine 140 determines the organizational role or roles associated with user 124 at step 477 .
  • execution engine 140 identifies activities that user 124 is allowed to access. If the organizational role is not parametric, user 124 may access activities associated with the organizational role assigned to user 124 . If the organizational role is parametric, the user 124 may access instances associated with values assigned to user 124 . User 124 is granted access to the allowed activities at step 480 . After granting access, the method terminates.
  • Organizational roles screen 400 , assign organizational roles screen 430 , and match role screen 450 allow for easy specification and matching of abstract roles and organizational roles.
  • the method provides for efficient definition of users 124 responsible for performing activities 212 of business process 210 .
  • FIG. 10 illustrates one embodiment of a publish screen 500 that may be used to publish business process 210 .
  • Process designer 132 and execution console 136 publish business process 210 to organization data repository 150 by matching abstract roles with organizational roles, and then storing the matched abstract roles and organizational roles in organization data repository 150 .
  • Metadata and the structure of the business process model may also be stored in organization data repository 150 .
  • Metadata describes a graphical representation of the business process model.
  • business process 210 may be deployed into a testing environment before deploying business process 210 to users 124 of a production environment.
  • Process designer 132 and execution console 136 displays publish screen 500 in order to match the abstract roles with the organizational roles.
  • Publish screen 500 includes a “publish to” section 510 , a process information section 512 , and a commands section 514 .
  • “Publish to” section 510 is used to specify the organization and organizational unit 162 for which business process 210 is to be published.
  • Publish to section 510 includes an organization window 516 and an organizational unit window 518 , where names of the organization and organizational unit 162 , respectively, may be placed.
  • Users 124 of organizational unit 162 specified in “publish to” section 510 for example, a Sales organizational unit, may be granted access to business process 210 after deployment of business process 210 to a production environment.
  • Process information section 512 includes a name window 520 that displays a name of business process 210 to be published, for example, Process 1.
  • a variation window 522 is used to show the variation of the business process to be published.
  • the variation may describe, for example, a business process published to a specific organizational unit 162 .
  • Variations may be used if variations of the same business process are to be used in the same organization. For example a business process may be implemented one way in Region 1 and may be implemented another way in Region 2. Conceptually, the business processes do the same thing, but are implemented differently.
  • Version window 524 displays the version of the variation of business process 210 to be published.
  • the version number may track the number of times business process 210 has been published. For example, a version number “1.3” may indicate that a first version of the business process has been published three times.
  • a new major version button 526 may be selected in order to adjust the version number to show that the business process to be published is a new major version. For example, version number “2.0” may be used to indicate a new major version over version number “1.0”.
  • a file window 528 is used to specify business process model location, for example, a computer associated with designer 122 .
  • a match roles button 530 may be used to display match roles screen 450 that may be used to match abstract roles with organizational roles in a manner substantially similar to the method described in connection with FIG. 9 .
  • a deploy process in test server box 532 may be selected in order to deploy business process 210 to a test environment automatically after publication.
  • Commands section 514 may be used to specify additional commands, for example, a JAVA compiler program used to generate business process metadata when publishing business process 210 .
  • a browse button 534 may be selected to list available commands that may be inserted into commands section 514 .
  • a status window 536 shows the status of the publication process. Okay and cancel buttons 538 may be used to submit or cancel, respectively, a request to publish business process 210 .
  • FIG. 11 is a flowchart illustrating one embodiment of a method for publishing business process 210 .
  • publish screen 500 is used to publish Process 1 destined for a Sales organization unit 162 in order to test Process 1.
  • Process 1 is deployed to allow users of the Sales organizational unit 162 access to Process 1.
  • the method begins at step 560 , where process designer 132 displays publish screen 500 .
  • Publish screen 500 is used to generate a request to publish business process 210 to organization data repository 150 .
  • Process 1 is published for a Sales organizational unit 162 .
  • Publish screen 500 is also used to access match roles screen 450 to generate a request to match abstract roles and organizational roles.
  • process designer 132 matches abstract roles and organizational roles at step 562 .
  • process designer 132 initiates publication generating a suitable object-based code such as Java code for the tasks of activities 212 of business process 210 .
  • the code is then compiled using a suitable compiler such as a Java compiler.
  • the code may also be packaged and compressed by using a suitable compression method such as zip compression.
  • process designer 152 completes publication by storing the code and the material abstract roles and organizational notes in organization data repository 150 .
  • the method determines whether business process 210 is to be deployed to a testing environment.
  • Designer 122 of the organization may inspect and test published business process 210 in a test environment to determine whether it is ready for deployment. If business process 210 is not ready for deployment at step 568 , the method terminates.
  • step 574 business process 210 is deployed to organizational unit 162 using execution engine 140 specified at step 560 . Users of organizational unit 162 may be granted access to business process 210 after deployment. After deploying business process 210 , the method terminates. To summarize, the method provides for publication of business process 210 that allows for inspection and testing of business process 210 without deployment of business process 210 to a production environment.
  • FIG. 12 is a flowchart illustrating one embodiment of a method for implementing an instance variable, a type of persistent variable.
  • An instance variable allows for a value associated with an instance of business process 210 to be transferred from one activity 212 to another activity 212 of business process 210 .
  • Business process 210 may include, for example, activities 212 for processing a sales order, and the instance may describe the processing of a specific sales order.
  • the instance is associated with an instance variable, which may describe, for example, a requested quantity of goods for that particular sales order.
  • the method begins at step 610 , where an instance of business process 210 is initiated.
  • a first activity 212 a of business process 210 is executed at step 612 .
  • a value corresponding to the instance variable is received.
  • the value may describe a quantity of goods.
  • Execution engine 140 records the value and the instance variable in objects at step 616 .
  • the objects may comprise, for example, a Java object.
  • the objects are serialized at step 618 so that the objects can be persisted in a data repository.
  • a serialization mechanism may be used for complex structures.
  • the objects are stored in transactional data repository 118 .
  • a second activity 212 b of business process 210 is executed.
  • Activity 212 b may require the value for the instance variable that was received during execution of first activity 212 a .
  • the objects that record the value are retrieved from transactional data 170 for use by second activity 212 b .
  • the value retrieved from transactional database 170 may be deserialized to be read by the task in second activity. After retrieving the objects, the method terminates.
  • FIG. 13 is a flowchart illustrating one embodiment of a method for implementing an argument variable, another type of persistent variable.
  • An argument variable allows for a value to be transferred from one business process 210 a to another business process 210 b .
  • a first business process 210 a may describe processing sales orders, and an instance may describe processing a specific sales order. The instance is associated with an argument variable that describes, for example, a requested quantity of goods for the particular sales order.
  • a second business process 210 b may describe determining the inventory of a type of goods, and may require information about quantities of goods requested by sales orders.
  • An argument variable allows for information about requested quantities of goods to be transferred from first business process 210 a to second business process 210 b.
  • the method begins at step 650 , where an instance of first business process 210 a is initiated by execution engine 140 with a value for a process instance variable as described in FIG. 12 .
  • First business process 210 a includes an activity that connects first business process 210 a with second business process 210 b .
  • An instance variable of first business process 210 a is associated with an argument variable used to send a value to second business process 210 b .
  • a value corresponding to the argument variable is received.
  • the value may describe a quantity of goods.
  • the value for the corresponding argument variable is recorded in objects.
  • the objects may comprise, for example, a Java object.
  • the objects are serialized at step 656 for recording the objects in a data repository.
  • the serialized objects are stored in transaction database 170 of data repository 118 .
  • a process instance variable of second business process 210 b is initiated with a default value.
  • the argument variable of first business process 210 a is mapped to the instance variable of second business process 210 b and persisted in transactional database 170 .
  • the objects that record the value for process instance variable are retrieved from transactional data 170 for use by the instance of second business process 210 b . After the objects are retrieved, the method terminates.
  • Embodiments of the present invention provide advantages for automating business processes 210 .
  • Business processes 210 may include activities 212 with compensation tasks 312 .
  • Compensation tasks 312 are executed when an associated task 310 of activity 212 fails to execute.
  • an activity 212 may be associated with an abstract role to efficiently specify users 124 representing people who are responsible for performing the activity 212 .
  • system 100 provides persistent variables, which allow a value related to an instance to be carried from one activity to another activity. Consequently, embodiments of the present invention provide effective and efficient systems and methods for automating business processes 210 .
  • FIGS. 14 through 18 illustrate embodiments of distributed process flow.
  • Distributed process flow provides for the definition of distributed processes, which may improve process design and implementation.
  • Distributed process flow may be applied to any suitable software program.
  • distributed process flow is applied to a business designer 700 .
  • business designer 700 offers the following distributed features: asynchronous process creation, synchronous process creation, process-to-process notification, external notification to processes, and process interruption.
  • Distributed process flow may be applied to any procedure, for example, process modularization, logical distribution of implementable processes, task parallelization, or notification between processes.
  • FIG. 14 illustrates an example of asynchronous process creation, which may be called non-blocking process creation.
  • Asynchronous process creation allows for a first business process to create an instance in a second business process represented by an activity of the first business process.
  • instance creation is requested by a parent business process 710 , and the instance is created in a child business process 712 .
  • An instance of parent business process 710 is not required to wait for an instance in child business process 712 and may continue flowing through parent business process 710 . Both instances may run concurrently in business processes 710 and 712 .
  • An asynchronous instance creation may occur in the same business process 710 , which involves calling business process 710 recursively.
  • Post Order child process 712 is represented by a process creation activity. Father parent process 710 is not required to wait until order processing in Post Order child process 712 is completed.
  • Each business process 710 and 712 may have incoming parameters, known as incoming arguments.
  • incoming arguments When an instance is created asynchronously in child business process 712 , parameters are passed to child business process 712 .
  • FIG. 15 illustrates an example of synchronous process creation, which may be called blocking process creation.
  • Synchronous process creation is similar to asynchronous process creation, however, an instance in a parent business process 714 waits until an instance in a child business process 716 is complete. Once the instance of child business process 716 is complete, the instance in parent business process 714 continues to flow through parent business process 714 .
  • arguments are passed to child business process 714 .
  • Father parent process 714 waits for a response from Delivery child process 716 to confirm successful delivery of goods stated in the order.
  • FIG. 16 illustrates an example of process-to-process notification and external notification.
  • Process-to-process notification and external notification allow for communication and synchronization between business processes.
  • Process-to-process notification is based on process notification and notification wait activities.
  • the process notification activity is used to send a notification to an instance at a notification wait activity of a second business process. If the instance is not at the notification wait activity, the notification is stored at the execution engine 140 . The instance is notified when it reaches the notification wait activity. If the notification wait activity has not received the notification, the instance waits until the notification arrives and is notified by the execution engine 140 , after which the instance may continue to flow through the business process.
  • a child-parent relation exists when a parent business process creates an instance in a child business process, and the child business process sends a notification to the parent business process, which is managed by business designer 700 .
  • a parent-child relation exists when a parent business process creates an instance in a child business process and the parent business process sends a notification to the child business process, which is managed by business designer 700 .
  • a process-external event relation exists when an external source sends an external notification to an instance in a notification wait activity of a business process.
  • the external source may comprising a program written in a different programming language or a process not related to the business process by a parent-child relationship.
  • the external notification uniquely identifies the instance to which it is sending the notification. Parameters are used when creating instances in a process and are passed when a notification is sent to an instance in another business process.
  • business process 718 an order at Delivery 720 to be delivered is sent asynchronously, after which processing at Review Order 722 may occur. Business process 718 waits until delivery confirmation is received.
  • FIG. 17 illustrates an example of process-to-process notification and external notification.
  • a first business process 724 notifies a second business process.
  • First business process 724 sends a notification to the second business process waiting for the delivery confirmation.
  • FIG. 18 illustrates an example of process interruption.
  • Process interruption is form of process-to-process communication.
  • Process interruption allows a first business process to interrupt a second business process in order to process an interruption or urgent event over a particular instance.
  • This notification is similar to the notification wait activity, but in this case the instance is not required to be at the notification wait activity. Once the notification is sent, the instance is taken automatically to the notification wait activity, regardless of where the instance is in the process.
  • an instance in business process 730 flows to a Credit Check activity 730 .
  • the instance is processed without error, however, a warning may be issued to indicate an abnormality with a particular instance.
  • Business process 730 receives an external notification, and the instance is automatically forwarded to a Credit Warning activity 734 and continues to flow through a Process Warning activity 736 .
  • FIG. 19 illustrates an example of polymorphic sub-processes.
  • a polymorphic sub-process creates instances in different child business processes sharing the same interface, depending on variables embedded in a parent business process.
  • a parent and child business process use the same interface to communicate between the business processes.
  • An interface may be defined by the input and output arguments of a business process and a notification wait activity.
  • the instance may be routed to the correct child business process according to predefined variables.
  • the variables may include, for example, organizational unit, organization, and country.
  • Child business Process 1 740 a , Process 2 740 b , and Process 3 740 c of parent business process 744 share a common interface 746 .
  • Common interface 746 allows a parent business process 744 to create an instance in any of the child business processes 740 .
  • a technical advantage of one embodiment is that business processes may include activities with compensation tasks. Compensation tasks are executed when a task of an activity fails to execute, thus allowing for the performance of the activity to continue uninterrupted to completion. Compensation tasks may be used for automated business processes to maintain business process consistency.
  • an activity may be associated with an abstract role in order to specify users representing people responsible for performing the activity.
  • the association may provide for abstract business process modeling, which may allow for the creation of business process templates creation that may be used for different organizations.
  • Another technical advantage of one embodiment is that the processes of publishing and deploying business processes are separated. By separating the publication and deployment processes, a business process may be published and tested, without deploying the business process to users.
  • Another technical advantage of one embodiment is that persistent variables are used. Persistent variables allow a value related to an instance of a business process to be efficiently carried from one activity of the business process to another activity of the same business process or of another business process.

Abstract

Automating a business process includes defining an activity of a business process. The activity is associated with an abstract role, and the abstract role represents a user responsible for performing the activity. An organizational role associated with a set of values is defined. The organizational role can have a value from the set of values, where each value ill corresponds to a user set. The organizational role is matched to the abstract role. An instance of the activity is received, and the value for the organizational role is determined. The instance is routed to the user set corresponding to the determined value.

Description

    RELATED APPLICATIONS
  • This application claims benefit under 35 U.S.C. § 119(e) of U.S. Provisional Application Ser. No. 60/280,622, filed Mar. 30, 2001, entitled “METHOD AND SYSTEM FOR AUTOMATING BUSINESS PROCESSES.”
  • This application is related to U.S. patent application Ser. No. 09/______, entitled “DESIGNING BUSINESS PROCESSES USING DISTRIBUTED PROCESS FLOWS,” Attorney's Docket 067833.0131, filed concurrently with the present application.
  • This application is related to U.S. patent application Ser. No. 09/______, entitled “PUBLISHING AND DEPLOYING BUSINESS PROCESSES,” Attorney's Docket 067833.0132, filed concurrently with the present application.
  • This application is related to U.S. patent application Ser. No. 09/______, entitled “EXECUTING BUSINESS PROCESSES USING PERSISTENT VARIABLES,” Attorney's Docket 067833.0135, filed concurrently with the present application.
  • TECHNICAL FIELD OF THE INVENTION
  • This invention relates generally to the field of business process design and more specifically to designing business processes using parametric roles.
  • BACKGROUND OF THE INVENTION
  • Organizations typically automate their business processes to manage their operations. A business process includes a series of activities that are undertaken to perform the operations of an organization. For example, a business process may describe activities for processing a sales order, such as the steps of receiving a sales order, checking the payment history, checking the inventory, and so on. An organization may automate a business process by having a computer perform some activities such as receiving a sales order. A business process may also be automated by having a computer remind human participants of activities that need to be performed. For example, a computer may send an email message notifying an account manager to check the payment history of a client.
  • Automating business processes, however, has posed challenges. Designing automated business processes involves the use of software programs, which business process designers may find difficult to use. Moreover, testing automated business processes requires performing trial runs of a business process, which may be difficult to do without disrupting the actual users of the business process. Consequently, automating business processes has posed challenges.
  • SUMMARY OF THE INVENTION
  • In accordance with the present invention, disadvantages and problems associated with previous techniques for business process design may be reduced or eliminated.
  • According to one embodiment of the present invention, automating a business process includes defining an activity of a business process. The activity is associated with an abstract role, and the abstract role represents a user responsible for performing the activity. An organizational role associated with a set of values is defined. The organizational role can have a value from the set of values, where each value corresponds to a user set. The organizational role is matched to the abstract role. An instance of the activity is received, and the value for the organizational role is determined. The instance is routed to the user set corresponding to the determined value.
  • Certain embodiments of the invention may provide numerous technical advantages. A technical advantage of one embodiment is that business processes may include activities with compensation tasks. Compensation tasks are executed when a task of an activity fails to execute, thus allowing for the performance of the activity to continue uninterrupted to completion. Compensation tasks may be used for automated business processes to maintain business process consistency.
  • Another technical advantage of one embodiment is that an activity may be associated with an abstract role in order to specify users representing people responsible for performing the activity. The association may provide for abstract business process modeling, which may allow for the creation of business process templates creation that may be used for different organizations.
  • Another technical advantage of one embodiment is that the processes of publishing and deploying business processes are separated. By separating the publication and deployment processes, a business process may be published and tested, without deploying the business process to users. Another technical advantage of one embodiment is that persistent variables are used. Persistent variables allow a value related to an instance of a business process to be efficiently carried from one activity of the business process to another activity of the same business process or of another business process.
  • Certain embodiments of the invention may include none, some, or all of the above technical advantages. One or more other technical advantages may be readily apparent to one skilled in the art from the figures, descriptions, and claims included herein.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • For a more complete understanding of the present invention and for further features and advantages, reference is now made to the following description, taken in conjunction with the accompanying drawings, in which:
  • FIG. 1A is a block diagram of one embodiment of a system for automating a business process in accordance with the present invention;
  • FIG. 1B is a block diagram of one embodiment of a data repository that may be used with the system of FIG. 1A;
  • FIG. 2 illustrates one embodiment of designer screen that may be used for automating business process modeling;
  • FIG. 3 illustrates one embodiment of task table that may be used for recording tasks and compensation tasks for a business process activity;
  • FIG. 4 illustrates one embodiment of an activity properties screen that may be used to define tasks and compensation tasks;
  • FIG. 5 is a flowchart illustrating one embodiment of a method for defining, implementing, and executing tasks and compensation tasks;
  • FIG. 6 illustrates one embodiment of an organizational roles screen that may be used to configure organizational roles that can have values;
  • FIG. 7 illustrates one embodiment of assign organizational roles screen that may be used to assign organizational roles to users;
  • FIG. 8 illustrates one embodiment of a match roles screen that may be used to match abstract roles with organizational roles when an abstract business process model is published to an organization;
  • FIG. 9 is a flowchart illustrating one embodiment of a method for defining and implementing organizational roles;
  • FIG. 10 illustrates one embodiment of a publish screen that may be used to publish and deploy a business process;
  • FIG. 11 is a flowchart illustrating one embodiment of a method for publishing a business process;
  • FIG. 12 is a flowchart illustrating one embodiment a method for implementing an instance variable at runtime or execution time;
  • FIG. 13 is a flowchart illustrating one embodiment a method for implementing an argument variable when communicating to business processes;
  • FIGS. 14 through 18 illustrate distributed process flow; and
  • FIG. 19 illustrates polymorphic sub-processes.
  • DETAILED DESCRIPTION OF THE DRAWINGS
  • FIG. 1A is a block diagram of one embodiment of a system 100 for automating a business process. A business process includes a series of activities that are undertaken to perform the operations of an organization. For example, a business process may describe activities for processing a sales order, such as the steps of receiving a sales order, checking the payment history, checking the inventory, and so on. System 100 allows an organization to automate business processes.
  • Referring to FIG. 1A, a user group 110 may access system 100 through a communication network 114. An organization may use system 100 to implement business processes to solve problems. User group 110 comprises a data set of user identifiers, which may represent, for example, people who may access system 100 using computing modules such as personal computers. For example, user group 110 may include a designer 122, which represents a person who uses system 100 to design a business process model.
  • User group 110 also includes users 124, which represent people who may be responsible for performing activities of a business process. For example, a user 124 may be responsible for receiving a sales order and verifying its completeness. System 100 allows designer 122 to design a business process model. In turn, system 100 notifies users 124 of the activities that need to be performed.
  • Users 124 may be logically organized into user sets 123, where users 124 of a user set 123 represent people who are responsible for the execution of specific activities. The logical grouping of users may be defined and stored in system 100. A user 124 may be a member of any suitable number of user sets 123. For example, user 124 c is a member of user sets 123 a and 123 b. User sets 125 may be associated with, for example, organizational roles defined within an organization, such as a salesperson role.
  • Communication network 114 may include wired telecommunications, satellite, microwave, or other suitable wired or wireless networks, or a combination of the preceding.
  • System 100 includes an interface module 116, modules 112, and a data repository 118. Interface module 116 may include a website 126, an interface 128 deployed in website 126, and a security module 129. Website 126 allows for communication of information between user group 110 and system 100. Interface 128 may comprise a hypertext markup language (HTML) interface that receives instructions through a web server deployed in website 126 in order to perform operations included in instructions from users 124. Security module 129 may provide, for example, password security, resource access security, and/or system security. Security module 129 may be used for authentication procedures and may be adapted to the security policy and infrastructure of an organization.
  • System 100 provides advantages in automating business processes. System 100 generates business processes that include compensation tasks. A compensation task is executed when an associated task of a business process activity fails to execute, allowing the business process to achieve a steady and consistent state before its execution is retried. The business process instance may proceed to the next business process activity. Additionally, system 100 allows for specification of people who are responsible for performing the activities of a business process through user sets 123 defined in system 100, thus allowing an organization to readily automate the business process.
  • Moreover, system 100 separates the processes of publishing and deploying business processes. By separating the publication and deployment processes, a business process may be published and tested, without being deployed to users 124 of the production environment. Furthermore, system 100 provides persistent variables, which allow a value to be transferred from one activity to another activity of the same business process or of a different business process using process arguments.
  • Modules 112 include a catalog manager 130, a process designer 132, an organizational settings module 134, an execution console 136, and execution engines 140 coupled as shown in FIG. 1A. In general, catalog manager 130 may be used to define and specify the components or programs that can be called from a business process. Process designer 132 may be used to model business processes to be deployed in an organization. Organizational settings module 134 may be used as a front-end module to define business process participants and how they are going to be organized.
  • Execution console 136 may be used to manage the execution engine in which business processes are deployed, and may be accessed by users 124 of user group 110. Execution engines 140 may be used to deploy business processes, execute tasks requested by users 124, and perform automated business process activities. Modules 112 may store and retrieve data using a data repository 118 that includes an organizational data repository 150 and a transactional database 170.
  • According to one embodiment, catalog manager 130 defines, describes, and organizes components. A component may comprise a modular software routine that has been compiled, and may be used with other components or programs. Catalog manager 130 stores components in data repository 118 and supplies components to process designer 132 and execution engines 140.
  • Process designer 132 is used to design business processes, which are stored in data repository 118 once the business processes are published. While the business process is being designed using Process Designer 132, the business process model definition may be stored in a local computer. Business processes are described in more detail in connection with FIG. 2. Process designer 132 may also be used to publish business processes to data repository 118 as well as to deploy business processes to execution engine 140.
  • According to one embodiment, business processes are designed on a computer by manipulating graphical icons on a computer screen. An example of a computer screen that may be used to design a business process is described in connection with FIG. 2.
  • FIG. 2 illustrates one embodiment of a designer screen 200 for automating a business process 210 on a computer. Business process 210 includes a sequence of activities 212 coupled by transitions 214. For example, business process 210 may include a sequence of activities 212 for processing a sales order. Each activity 212 comprises a series of tasks that are executed to complete activity 212. For example, an activity 212 that notifies a client of an incomplete sales order may include the task of “sending an email message to the client.” Tasks may execute components catalogued using catalog manager 130 and made available through publishing and deployment.
  • To design business process 210, activities 212 are placed in a designer window 202. Activities 212 may have a specific semantic, which may be designated by a particular color or shape. Custom colors and shapes may be used in response to user preference. For example, activity 212 a may be an activity that is used to begin a business process, and may be designated by a triangular shape pointing in the right-hand direction. Activity 212 f may be an activity that is used to end a business process, and may be designated by a triangular shape pointing in the left-hand direction.
  • Transitions 214 are used to indicate a next activity that is to be initiated after executing a previous activity. For example, transition 214 a indicates that activity 212 b is to be initiated after the execution of activity 212 a. Transitions 214 may indicate multiple next activities that are to be initiated after the execution of a previous activity. For example, transitions 214 b and 214 c indicate that activities 212 c and 212 d, respectively, are to be initiated after the execution of activity 212 b.
  • Depending upon how business process 210 is defined, either one or both activities 212 c and 212 d may be initiated after activity 212 b. For example, business process 210 may be defined such that depending upon a decision made at activity 212 b, either activity 212 c or activity 212 d is initiated after the execution of activity 212 b. Additionally, transitions 214 may direct multiple activities to a single next activity. For example, transitions 214 d and 214 e direct activities 212 c and 212 d, respectively, to activity 212 e.
  • Business process 210 also includes abstract roles 216 that are used at design time to represent in the abstract user sets 123 that represent people of an organization who are responsible for performing an activity 212. Abstract role 216 may be matched to an organizational role. An abstract role represents in the abstract a set of users responsible for performing the activity, and the organizational role may take on values that correspond to actual users 124 of an organization. For example, an abstract role represents a salesperson in the abstract, and the organizational role describes actual salespeople of an organization. At design time, abstract roles are used instead of organizational roles, such that a single business process may be used for multiple organizations, incorporating the concept of template models.
  • An organizational role may be parametric, that is, the organizational role may be assigned a value that corresponds to user set 123, and may take on multiple values that correspond to different user sets 123. Users 124 of user set 123 represent people responsible for performing activity 212. For example, users 124 of one user set 123 may represent salespeople from one state, and users of another user set 123 may represent salespeople from another state. An organizational role may be used to create groups of users that can be instantiated with, for example, salespeople from different states. An advantage of defining parametric roles is that the assignment of a user set 123 may be determined dynamically based on business process rules.
  • Abstract roles 216 are specified for activities 212 by placing activities 212 in the appropriate abstract role column. For example, abstract role 216 a is specified for activity 212 a, and abstract role 216 b is specified for activities 212 b and 212 e. To summarize, business process 210 may include activities 212 coupled by transitions 214 and associated with abstract roles that may be associated with real organizational roles stored in data repository 118.
  • Referring back to FIG. 1A, organizational settings module 134 defines the settings for an organization. Organizational settings may describe user sets 123, organizational roles and associated values if the organizational roles are parametric, and organizational units of the organization.
  • Execution engines 140 manage the execution of instances of business processes 210. An example of an instance of a business process may be processing a specific sales order using a business process for processing sales orders. Execution engine 140 is used to execute an instance of business process 210 that has been deployed on it. Execution engine 140 retrieves and collects business process 210 definitions from organizational data repository 150. Execution engine 140 manages the execution of a particular task of a specific business process instance requested by a user 124 if the activity is interactive. Execution engine 140 automatically executes the task if the activity is an automated one.
  • The state of the instance is maintained in transactional database 170 if the task is completed successfully. Each execution engine 140 may be associated with its own transactional database 170 that may comprise, for example, a relational database management system (RDBMS). “Each” as used in this document means either each member of a set or each member of a subset of a set.
  • Execution console 136 defines and manages execution engines 140. For example, execution console 136 defines port settings for execution engines 140 and database settings for transactional databases 170 associated with execution engines 140.
  • FIG. 1B is a block diagram of one embodiment of data repository 118 of system 100 of FIG. 1A. Data repository includes organizational data repository 150 and transactional database 170. Organizational data repository 150 includes information that is typically maintained through multiple executions of instances of business processes, and may be received from organizational settings 134 and execution console 136. Organizational data repository 150 may comprise, for example, a lightweight directory access protocol (LDAP) database.
  • Organizational data repository 150 includes business process definitions 152 and organizational data 154. Business process definitions 152 include activities, transitions between the activities, and abstract roles associated with the activities. Business process definitions 152 may include a task table 159 that records the tasks of an activity and their associated compensation tasks. A compensation task is executed when its associated task fails to execute. The compensation task undoes things done by the associated task to a particular business process activity, resulting in a consistent state in case a task fails. Task table 159 is described in more detail in connection with FIG. 3.
  • Organizational data 154 includes information about the organization. Organizational roles 160 include information about organizational roles and associated users 124. Organizational roles 160 are matched with abstract roles 216 in order to specify users 124 representing people who are responsible for performing the activities of business processes definitions 152. Matchings 164 record the association between abstract roles and corresponding organizational roles when publishing a particular business process using system 100.
  • Transactional database 170 includes persistent variables that record information that is typically maintained for an instance of a business process. For example, a value describing the requested quantity of goods for a specific sales order is typically maintained for the instance that processes the specific sales order. The value is generally not needed for instances that process other sales orders.
  • Persistent variables include instance variables 172 and argument variables 174. Instance variables 172 record values that may be passed from one activity of a business process to another activity of the same business process. Instance variables 172 may maintain the state of the instance within the context of a business process. For example, an instance variable may maintain the activity where an instance is at a given moment in time during the lifetime of the instance in a business process. Argument variables 174 record values that may be passed from one business process to another business process. Methods for implementing and using persistent variables are described in more detail in connection with FIGS. 12 and 13.
  • System 100 provides advantages in automating business processes 210. Business processes 210 may include activities 212 with tasks associated with compensation tasks. Compensation tasks are executed when an associated task of activity 212 fails to execute, thus allowing for a consistent state. Compensation tasks are described in more detail in connection with FIGS. 3, 4, and 5. Additionally, activities 212 may also be associated with abstract roles that are used to specify users 124 representing people who are responsible for performing the activity 212, thus allowing an organization to readily automate business processes 210. Organizational roles are described in more detail in connection with FIGS. 7, 8, and 9.
  • Moreover, system 100 separates the processes of publishing and deploying business processes 210. Business process 210 is published by matching abstract roles with organizational roles to specify users 124 representing people responsible for performing the activities of the business process 210. After publishing, business process 210 may be tested in a testing environment. The tested business process 210 is then deployed to make business process 210 available to users 124 of a production environment. By separating the publication and deployment processes, business process 210 may be published and tested, without deploying business process 210 to users 124 of the production environment, thus reducing risk of problems in the production environment. Publication and deployment of business processes 210 are described in more detail in connection with FIGS. 10 and 11.
  • Furthermore, system 100 provides persistent variables, which allow a value related to an instance to be carried from one activity to another activity within the same business process or between different business processes. Persistent variables are described in more detail in connection with FIGS. 12 and 13.
  • Compensation Tasks
  • FIG. 3 illustrates one embodiment of a task table 300 that records tasks 310 and compensation tasks 312. Activity 212 includes a sequence of tasks 310 that are performed in order to complete activity 212. Activity 212 may describe, for example, notifying a client of an incomplete sales order. Tasks 310 may be written in any suitable computer language and may invoke components implemented in a different computer programming language such as C, C++, Fortran, Cobol, or Basic.
  • A task 310 may be associated with a compensation task 312 that is specified to be executed in task 310. Compensation task 312 is only executed if its associated task fails. For example, Task 1, which may represent “send email message to the client and to the financial department” is associated with compensation Task 3, which may represent “send a disregarding email message to the client if the email message could not be sent to the financial department”. Task 3 is performed if Task 1 fails. A task 310 is not required to have a compensation task 312. For example, Task 2, which may be “send a fax to the client,” has no associated compensation task 312. Recording tasks 310 and associated compensation tasks 312 in task table 300 provides for efficient and organized storage of tasks 310 and compensation tasks 312.
  • FIG. 4 illustrates one embodiment of an activity properties screen 320 or task definition screen, that may be used to define tasks 310 and compensation tasks 312 of activity 212. Activity properties screen 320 includes an activity tasks section 322 and a set of available tasks section 324.
  • Activity tasks section 322 includes windows 326 and 330 and boxes 328 and 332 that may be used to define tasks 310 and compensation tasks 312 of activity 212. To define a task 310, the name of task 310 may be inserted in task name window 326, and a required box 328 may be selected in order to indicate that task 310 is mandatory to complete an instance of activity 212. A mandatory task may comprise a task that must be completed in order to route an instance from one activity to another activity. In one embodiment, mandatory tasks must be completed in order to route an instance from one activity to a next activity to continue execution of activity 212. In the illustrated example, Task 1, “send an email message to the client and to the financial department” must be completed in order to continue execution of activity 212.
  • Compensation task 312 may be defined by inserting the name of compensation task 312 into compensation task name window 330, and a repeatable 332 box may be selected in order to indicate that task 310 may be repeated a number of times. An add button 334 a, an edit button 334 b, and a remove button 334 c may be used to add, edit, or remove tasks 310 from activity 212. When a task is added, the new task appears in task name window 326.
  • Tasks 310 and compensation tasks 312 for activity 212 may be selected from set of tasks section 324. Set of tasks section 324 includes a name window 334 and a description window 336 that lists the names and descriptions, respectively, of available tasks that may be selected for activity 212. Activity properties screen 320 allows designer 122 using Process Designer 132 to readily specify tasks 310 and associated compensation tasks 312 of activity 212, thus providing for efficient design of business processes 210.
  • FIG. 5 is a flowchart illustrating one embodiment of a method for defining and implementing tasks 310 and compensation tasks 312 of activity 212. In the illustrated example, Task 1, which is “send an email message to the client and to the financial department” is associated with compensation Task 3, which is “send a disregarding email message to the client if the email message could not be sent to the financial department”. Task 3 is performed if Task 1 fails, that is, if the email message cannot be sent to the financial department, then a disregarding email message is sent to the client.
  • The method begins at step 350, where process designer 132 displays activity properties screen 320, which may be used to generate tasks for activity 212. Activity properties screen 320 may be displayed in response to a user request through process designer 132. A user may, for example, click on activity 212 of designer screen 200 of FIG. 2 to request activity properties screen 320.
  • Activity properties screen 320 may be used to specify tasks 310 and associated compensation tasks 312 of activity 212. In the illustrated example, Task 1 is “send an email message to the client and to the financial department” and Task 3 is “send disregarding email message to the client if the email message could not be sent to the financial department”. At step 352, tasks 310 and associated compensation tasks 312 are defined. Tasks 310 and associated compensation tasks 312 are stored in task table 159 of organizational data repository 150 at step 354.
  • At step 356, an instance of activity 212 is requested to initiate execution of a task 310. If activity 212 is interactive, then the request is received from user 124. If activity 212 is automatic, then execution engine 140 initiates the execution of task 310. A task 310, for example, Task 1, of activity 212 is initiated by execution engine 140 at step 358, that is, an email message is sent to the client and to the financial department.
  • Execution engine 140 may determine that Task 1 has failed at step 360. Execution engine 140 may, for example, receive a notification that a program responsible for executing Task 1, such as an email software program, cannot be located. Execution engine 140 determines compensation task 312 associated with task 310 from task table 159. In the illustrated example, task table 159 of FIG. 3 specifies that Task 3 is the compensation task 312 associated with Task 1.
  • At step 364, execution engine 140 initiates compensation task 312 to compensate for failed task 310. In the illustrated example, Task 3 may be initiated by sending a disregarding email message to the client. After initiating compensation task 312, the method terminates. Thus, the method provides for efficient specification of compensation tasks 312 that are executed in the event an associated task 310 fails to execute.
  • Parametric Roles
  • FIG. 6 illustrates one embodiment of an organizational roles screen 400 that may be used to define organizational roles and associated values for an organization. The organizational roles and associated values may be stored in organizational data repository 150. Organizational roles are matched with abstract roles of activity 212 when a business process model is published into an organization. An organizational role may group users 124 with the same responsibility such that users 124 associated with an organizational role may perform the same operations or functions. For example, multiple users 124 may have the ability to perform the same activity 212.
  • An organizational role may be parametric, that is, may take on values that may be associated with categories such as subsets of the group with which the organizational role is associated. For example, an organizational role associated with a sales role may take on values associated with sales team categories within the sales role.
  • Users 124 may be associated with organizational units in order to designate other groupings of users 124, for example, groupings by department or location. Organizational units may be associated with divisions or departments within an organization context. Information about the organizational units may be stored in organizational data repository 150. For example, an organizational unit may be associated with a particular department such as a sales department or a particular office location such as a Dallas office location.
  • Organizational units may be used to group users 124 that may access published and deployed business processes. For example, an organization develops a business process for processing a sales order that deals with operations in a sales department and no other department. The business process may be published and deployed to an organizational unit associated with the sales department such that only users 124 of this particular organizational unit, and no other users 124, may access the business process.
  • A value may also be associated with a time period. For example, an organization may have one value for telephone operators who work during a daytime period, and another value for telephone operators who work during a nighttime period. An instance of activity 212 that occurs during a particular time period may be assigned the value corresponding to the time period. For example, an instance that occurs during a daytime period may be assigned the value for telephone operators who work during a daytime period. An organizational role that has no specified value is assigned a default value.
  • An advantage of the parametric roles may be that only one activity may be needed for multiple parametric values, thus avoiding the need to specify multiple activities for multiple values. Another advantage may be that a user set 123 associated with an instance may be determined dynamically based on business process rules.
  • Organizational roles screen 400 includes a role name window 410 and a description window 412, where a name and a description, respectively, of an organizational role may be inserted. In the illustrated example, an organizational role, Sales, is described as an organizational role for sales teams. A browse button 414 may be selected in order to view available organizational roles.
  • Value windows 416 may be used to define values that the organizational role may have if the organizational role is parametric. In the illustrated example, Team A, Team B, and Team C, are the defined values that the Sales may have. Add and remove buttons 418 may be used to add and remove, respectively, values. An assign organizational role button 420 may be used to display assign organizational roles screen that may be used to assign roles to users 124, which is described in more detail in connection with FIG. 7.
  • FIG. 7 illustrates one embodiment of an assign organizational roles screen 430 that may be used to assign organizational roles and values to users 124. The organizational roles and values may be stored in organizational data repository 150. Organizational roles are assigned to users 124 in order to create user sets 123 corresponding to the organizational roles.
  • A user I.D. window 432, a name window 434, and an email address window 435 may be used to specify user 124 by inserting the user identification, name, and email address, respectively, of user 124. A browse button 436 may be used to view a list of available users 124. An organizational unit button 438 may be used to select an organizational unit 162 for user 124 referenced in user I.D. window 432. The information may be stored in organizational data repository 150.
  • An organizational roles section 440 may be used to define organizational roles assigned to user 124. Role name windows 442 and value windows 446 may be used to specify organizational roles and values for parametric organizational roles, respectively, assigned to user 124. In the illustrated example, a Sales role having Team A value, and a Training role are specified for JDOE.
  • Permission windows 444 are used to specify the actions a user may perform in a specified role. Possible permissions may include: execute task, abort instance, suspend instance, and route instance. The permission may be assigned to a particular user 124, which may provide for different users 124 associated with the same organizational role having different permissions.
  • Add and remove buttons 448 may be used to add or remove, respectively, organizational roles. Organizational roles screen 400 and assign organizational roles screen 430 thus allow for efficient specification of organizational roles, values, and user sets 123. According to one embodiment, organizational settings module 134 may be used to define and configure users 124, organizational roles 160, and organizational units 162.
  • FIG. 8 illustrates one embodiment of a match roles screen 450 that may be used to match abstract roles with organizational roles when a business process is published into an organization. Match roles screen 450 includes abstract role windows 452 and organizational roles windows 454 that may be used to specify the abstract roles and organizational roles to be matched. In the illustrated example, Abstract Role 1 is matched with a Sales organizational role, and Abstract Role 2 is matched with a Training organizational role.
  • Parametric boxes 456 may be used to specify whether a role is parametric. Software based on the abstract role definition may be used to determine whether a role is parametric. If an organizational role is parametric, value windows 458 may be used to specify a value for the organizational role. In the illustrated example, a Team A value is specified for Sales, and nothing is specified for Training.
  • FIG. 9 is a flowchart illustrating one embodiment of a method for defining and implementing organizational roles. In the illustrated example, assign organizational roles screen 430 is used to assign Sales and Training roles to user 124 JDOE. Match roles screen 450 is used to match abstract roles of business process 210 with organizational roles defined in organization data repository 150. After role matching has been performed, user 124 JDOE may have access to activities 212 a, 212 b, and 212 e because user 124 JDOE has been assigned the Sales and Training roles. As a result, user 124 JDOE is allowed to participate in the execution of activities 212 a, 212 b and 212 e.
  • The method begins at step 462, where an activity 212 is associated with an abstract role. An abstract role is created using process designer 132. Once the abstract role has been created, activity 212 can be located within the abstract role location. In this case, activity 212 belongs to a specific domain delimited by the abstract role. Activity 212 may be defined and abstract role may be specified using designer screen 200 of FIG. 2. Activity 212 and the associated abstract role are stored with business process 210 in organization data repository 150.
  • Organizational roles are added at step 464 using organizational settings module 134. Organizational roles screen 400 may be used to generate a request to define organizational roles. Values may be specified for a parametric organizational role. At step 466, users 124 are assigned to organizational roles. The assignment specifies the activities for which users 124 may participate in the execution. In the illustrated example, Sales and Training are specified for user 124 JDOE. Values may be specified for organizational roles that are parametric. In the illustrated example, a Team A is specified for Sales, and no value is specified for Training since Training is not parametric. At step 468, organizational settings module 134 stores the organizational notes and corresponding users 124 in organization data repository 118.
  • Business process 210 may be published at steps 472 and 474 using process designer 132 or execution console 136. Match roles screen 450 to generate a request to match abstract roles with organizational roles is displayed. A user 124 such as an administrator may use match roles screen 450 to generate a request matching the abstract role and the organizational role. The request is received at step 472. The abstract role and the organizational role are matched and stored at step 474. In the illustrated example, Abstract Role 1 is matched with Sales, and Abstract Role 2 is matched with Training. The matching is stored in organization data repository 150.
  • At step 476, execution engine 140 receives a request from user 124 to determine activities 212 that user 124 has access or authorization to process. User 124 is validated and is connected to execution engine 140. Execution Engine 140 determines the organizational role or roles associated with user 124 at step 477.
  • At step 478, execution engine 140 identifies activities that user 124 is allowed to access. If the organizational role is not parametric, user 124 may access activities associated with the organizational role assigned to user 124. If the organizational role is parametric, the user 124 may access instances associated with values assigned to user 124. User 124 is granted access to the allowed activities at step 480. After granting access, the method terminates.
  • Organizational roles screen 400, assign organizational roles screen 430, and match role screen 450 allow for easy specification and matching of abstract roles and organizational roles. Thus, the method provides for efficient definition of users 124 responsible for performing activities 212 of business process 210.
  • Publication and Deployment
  • FIG. 10 illustrates one embodiment of a publish screen 500 that may be used to publish business process 210. Process designer 132 and execution console 136 publish business process 210 to organization data repository 150 by matching abstract roles with organizational roles, and then storing the matched abstract roles and organizational roles in organization data repository 150. Metadata and the structure of the business process model may also be stored in organization data repository 150. Metadata describes a graphical representation of the business process model.
  • After publication, business process 210 may be deployed into a testing environment before deploying business process 210 to users 124 of a production environment. Process designer 132 and execution console 136 displays publish screen 500 in order to match the abstract roles with the organizational roles.
  • Publish screen 500 includes a “publish to” section 510, a process information section 512, and a commands section 514. “Publish to” section 510 is used to specify the organization and organizational unit 162 for which business process 210 is to be published. Publish to section 510 includes an organization window 516 and an organizational unit window 518, where names of the organization and organizational unit 162, respectively, may be placed. Users 124 of organizational unit 162 specified in “publish to” section 510, for example, a Sales organizational unit, may be granted access to business process 210 after deployment of business process 210 to a production environment.
  • Process information section 512 includes a name window 520 that displays a name of business process 210 to be published, for example, Process 1. A variation window 522 is used to show the variation of the business process to be published. The variation may describe, for example, a business process published to a specific organizational unit 162. Variations may be used if variations of the same business process are to be used in the same organization. For example a business process may be implemented one way in Region 1 and may be implemented another way in Region 2. Conceptually, the business processes do the same thing, but are implemented differently.
  • Version window 524 displays the version of the variation of business process 210 to be published. The version number may track the number of times business process 210 has been published. For example, a version number “1.3” may indicate that a first version of the business process has been published three times. A new major version button 526 may be selected in order to adjust the version number to show that the business process to be published is a new major version. For example, version number “2.0” may be used to indicate a new major version over version number “1.0”.
  • A file window 528 is used to specify business process model location, for example, a computer associated with designer 122. A match roles button 530 may be used to display match roles screen 450 that may be used to match abstract roles with organizational roles in a manner substantially similar to the method described in connection with FIG. 9. A deploy process in test server box 532 may be selected in order to deploy business process 210 to a test environment automatically after publication.
  • Commands section 514 may be used to specify additional commands, for example, a JAVA compiler program used to generate business process metadata when publishing business process 210. A browse button 534 may be selected to list available commands that may be inserted into commands section 514. A status window 536 shows the status of the publication process. Okay and cancel buttons 538 may be used to submit or cancel, respectively, a request to publish business process 210.
  • FIG. 11 is a flowchart illustrating one embodiment of a method for publishing business process 210. In the illustrated example, publish screen 500 is used to publish Process 1 destined for a Sales organization unit 162 in order to test Process 1. Process 1 is deployed to allow users of the Sales organizational unit 162 access to Process 1.
  • The method begins at step 560, where process designer 132 displays publish screen 500. Publish screen 500 is used to generate a request to publish business process 210 to organization data repository 150. In the illustrated example, Process 1 is published for a Sales organizational unit 162. Publish screen 500 is also used to access match roles screen 450 to generate a request to match abstract roles and organizational roles. In response to the request, process designer 132 matches abstract roles and organizational roles at step 562.
  • At step 564, process designer 132 initiates publication generating a suitable object-based code such as Java code for the tasks of activities 212 of business process 210. The code is then compiled using a suitable compiler such as a Java compiler. The code may also be packaged and compressed by using a suitable compression method such as zip compression. At step 566, process designer 152 completes publication by storing the code and the material abstract roles and organizational notes in organization data repository 150.
  • At step 568, the method determines whether business process 210 is to be deployed to a testing environment. Designer 122 of the organization may inspect and test published business process 210 in a test environment to determine whether it is ready for deployment. If business process 210 is not ready for deployment at step 568, the method terminates.
  • If business process 210 is ready for deployment at step 568, the method proceeds directly to step 574. At step 574, business process 210 is deployed to organizational unit 162 using execution engine 140 specified at step 560. Users of organizational unit 162 may be granted access to business process 210 after deployment. After deploying business process 210, the method terminates. To summarize, the method provides for publication of business process 210 that allows for inspection and testing of business process 210 without deployment of business process 210 to a production environment.
  • Persistent Variables
  • FIG. 12 is a flowchart illustrating one embodiment of a method for implementing an instance variable, a type of persistent variable. An instance variable allows for a value associated with an instance of business process 210 to be transferred from one activity 212 to another activity 212 of business process 210. Business process 210 may include, for example, activities 212 for processing a sales order, and the instance may describe the processing of a specific sales order. The instance is associated with an instance variable, which may describe, for example, a requested quantity of goods for that particular sales order.
  • The method begins at step 610, where an instance of business process 210 is initiated. A first activity 212 a of business process 210 is executed at step 612. At step 614, a value corresponding to the instance variable is received. The value may describe a quantity of goods. Execution engine 140 records the value and the instance variable in objects at step 616. The objects may comprise, for example, a Java object. The objects are serialized at step 618 so that the objects can be persisted in a data repository. A serialization mechanism may be used for complex structures. At step 620, the objects are stored in transactional data repository 118.
  • At step 622, a second activity 212 b of business process 210 is executed. Activity 212 b may require the value for the instance variable that was received during execution of first activity 212 a. At step 624, the objects that record the value are retrieved from transactional data 170 for use by second activity 212 b. To determine the value previously set in activity 212 a, the value retrieved from transactional database 170 may be deserialized to be read by the task in second activity. After retrieving the objects, the method terminates.
  • FIG. 13 is a flowchart illustrating one embodiment of a method for implementing an argument variable, another type of persistent variable. An argument variable allows for a value to be transferred from one business process 210 a to another business process 210 b. For example, a first business process 210 a may describe processing sales orders, and an instance may describe processing a specific sales order. The instance is associated with an argument variable that describes, for example, a requested quantity of goods for the particular sales order. A second business process 210 b may describe determining the inventory of a type of goods, and may require information about quantities of goods requested by sales orders. An argument variable allows for information about requested quantities of goods to be transferred from first business process 210 a to second business process 210 b.
  • The method begins at step 650, where an instance of first business process 210 a is initiated by execution engine 140 with a value for a process instance variable as described in FIG. 12. First business process 210 a, includes an activity that connects first business process 210 a with second business process 210 b. An instance variable of first business process 210 a is associated with an argument variable used to send a value to second business process 210 b. At step 652, a value corresponding to the argument variable is received. The value may describe a quantity of goods. The value for the corresponding argument variable is recorded in objects. The objects may comprise, for example, a Java object. The objects are serialized at step 656 for recording the objects in a data repository. At step 658, the serialized objects are stored in transaction database 170 of data repository 118.
  • At step 660, a process instance variable of second business process 210 b is initiated with a default value. At step 662, the argument variable of first business process 210 a is mapped to the instance variable of second business process 210 b and persisted in transactional database 170. At step 664, the objects that record the value for process instance variable are retrieved from transactional data 170 for use by the instance of second business process 210 b. After the objects are retrieved, the method terminates.
  • Embodiments of the present invention provide advantages for automating business processes 210. Business processes 210 may include activities 212 with compensation tasks 312. Compensation tasks 312 are executed when an associated task 310 of activity 212 fails to execute. Additionally, an activity 212 may be associated with an abstract role to efficiently specify users 124 representing people who are responsible for performing the activity 212.
  • Moreover, the processes of publishing and deploying business processes 210 are separated. By separating the publication and deployment processes, business process 210 may be published and tested, without deployment of business process 210 to organizational unit 162. Furthermore, system 100 provides persistent variables, which allow a value related to an instance to be carried from one activity to another activity. Consequently, embodiments of the present invention provide effective and efficient systems and methods for automating business processes 210.
  • Distributed Process Flow
  • FIGS. 14 through 18 illustrate embodiments of distributed process flow. Distributed process flow provides for the definition of distributed processes, which may improve process design and implementation. Distributed process flow may be applied to any suitable software program.
  • According to one embodiment, distributed process flow is applied to a business designer 700. According to the illustrated example, business designer 700 offers the following distributed features: asynchronous process creation, synchronous process creation, process-to-process notification, external notification to processes, and process interruption. Distributed process flow may be applied to any procedure, for example, process modularization, logical distribution of implementable processes, task parallelization, or notification between processes.
  • Asynchronous Process Creation
  • FIG. 14 illustrates an example of asynchronous process creation, which may be called non-blocking process creation. Asynchronous process creation allows for a first business process to create an instance in a second business process represented by an activity of the first business process. According to one embodiment, instance creation is requested by a parent business process 710, and the instance is created in a child business process 712.
  • An instance of parent business process 710 is not required to wait for an instance in child business process 712 and may continue flowing through parent business process 710. Both instances may run concurrently in business processes 710 and 712. An asynchronous instance creation may occur in the same business process 710, which involves calling business process 710 recursively.
  • In the illustrated example, once an order is received and processed in a Father parent process 710, the order is sent to Post Order child process 712 for further processing. Post Order child process 712 is represented by a process creation activity. Father parent process 710 is not required to wait until order processing in Post Order child process 712 is completed.
  • Each business process 710 and 712 may have incoming parameters, known as incoming arguments. When an instance is created asynchronously in child business process 712, parameters are passed to child business process 712.
  • Synchronous Process Creation
  • FIG. 15 illustrates an example of synchronous process creation, which may be called blocking process creation. Synchronous process creation is similar to asynchronous process creation, however, an instance in a parent business process 714 waits until an instance in a child business process 716 is complete. Once the instance of child business process 716 is complete, the instance in parent business process 714 continues to flow through parent business process 714. When an instance is created synchronously in child business process 714, arguments are passed to child business process 714.
  • In the illustrated example, Father parent process 714 waits for a response from Delivery child process 716 to confirm successful delivery of goods stated in the order.
  • Process-to-Process Notification and External Notification
  • FIG. 16 illustrates an example of process-to-process notification and external notification. Process-to-process notification and external notification allow for communication and synchronization between business processes.
  • Process-to-process notification is based on process notification and notification wait activities. The process notification activity is used to send a notification to an instance at a notification wait activity of a second business process. If the instance is not at the notification wait activity, the notification is stored at the execution engine 140. The instance is notified when it reaches the notification wait activity. If the notification wait activity has not received the notification, the instance waits until the notification arrives and is notified by the execution engine 140, after which the instance may continue to flow through the business process.
  • Three types of relations between business processes: child-parent, parent-child, process-external event. A child-parent relation exists when a parent business process creates an instance in a child business process, and the child business process sends a notification to the parent business process, which is managed by business designer 700. A parent-child relation exists when a parent business process creates an instance in a child business process and the parent business process sends a notification to the child business process, which is managed by business designer 700.
  • A process-external event relation exists when an external source sends an external notification to an instance in a notification wait activity of a business process. The external source may comprising a program written in a different programming language or a process not related to the business process by a parent-child relationship. The external notification uniquely identifies the instance to which it is sending the notification. Parameters are used when creating instances in a process and are passed when a notification is sent to an instance in another business process.
  • In the illustrated example business process 718, an order at Delivery 720 to be delivered is sent asynchronously, after which processing at Review Order 722 may occur. Business process 718 waits until delivery confirmation is received.
  • FIG. 17 illustrates an example of process-to-process notification and external notification. In the illustrated example, a first business process 724 notifies a second business process. First business process 724 sends a notification to the second business process waiting for the delivery confirmation.
  • Process Interruption
  • FIG. 18 illustrates an example of process interruption. Process interruption is form of process-to-process communication. Process interruption allows a first business process to interrupt a second business process in order to process an interruption or urgent event over a particular instance. This notification is similar to the notification wait activity, but in this case the instance is not required to be at the notification wait activity. Once the notification is sent, the instance is taken automatically to the notification wait activity, regardless of where the instance is in the process.
  • In the illustrated example, an instance in business process 730 flows to a Credit Check activity 730. Under normal conditions, the instance is processed without error, however, a warning may be issued to indicate an abnormality with a particular instance. Business process 730 receives an external notification, and the instance is automatically forwarded to a Credit Warning activity 734 and continues to flow through a Process Warning activity 736.
  • Polymorphic Sub-Processes
  • FIG. 19 illustrates an example of polymorphic sub-processes. A polymorphic sub-process creates instances in different child business processes sharing the same interface, depending on variables embedded in a parent business process. According to one embodiment, a parent and child business process use the same interface to communicate between the business processes. An interface may be defined by the input and output arguments of a business process and a notification wait activity. The instance may be routed to the correct child business process according to predefined variables. The variables may include, for example, organizational unit, organization, and country.
  • In the illustrated example, child business Process 1 740 a, Process 2 740 b, and Process 3 740 c of parent business process 744 share a common interface 746. Common interface 746 allows a parent business process 744 to create an instance in any of the child business processes 740.
  • Certain embodiments of the invention may provide numerous technical advantages. A technical advantage of one embodiment is that business processes may include activities with compensation tasks. Compensation tasks are executed when a task of an activity fails to execute, thus allowing for the performance of the activity to continue uninterrupted to completion. Compensation tasks may be used for automated business processes to maintain business process consistency.
  • Another technical advantage of one embodiment is that an activity may be associated with an abstract role in order to specify users representing people responsible for performing the activity. The association may provide for abstract business process modeling, which may allow for the creation of business process templates creation that may be used for different organizations.
  • Another technical advantage of one embodiment is that the processes of publishing and deploying business processes are separated. By separating the publication and deployment processes, a business process may be published and tested, without deploying the business process to users. Another technical advantage of one embodiment is that persistent variables are used. Persistent variables allow a value related to an instance of a business process to be efficiently carried from one activity of the business process to another activity of the same business process or of another business process.
  • Although an embodiment of the invention and its advantages are described in detail, a person skilled in the art could make various alterations, additions, and omissions without departing from the spirit and scope of the present invention as defined by the appended claims.

Claims (22)

1. A method for automating a business process, said method comprising:
defining a business process by using a graphical user interface (GUI), said business process including one or more activities coupled by a set of transitions, each activity including one or more tasks;
defining an activity of the business process, the activity associated with an abstract role, the abstract role representing a user responsible for performing the activity;
associating a compensation task with at least one task of said activity;
defining a parametric organizational role that specifies a group of users within an organization wherein the organizational role is associated with a parametric value;
matching the organizational role and the abstract role;
executing an instance of the activity;
determining the parametric value for the organizational role at runtime;
routing the instance to a subset of the group of users of the organizational role according to the determined parametric value such that the organizational role can take on different subsets of the group of users depending on the parametric value determined at runtime;
determining that the task associated with the compensation task has failed in execution; and
executing the compensation task associated with the task that has failed in execution by un-doing one or more actions performed by the task up to a particular activity, thereby resulting in a consistent state of the business process.
2. The method of claim 1, further comprising:
displaying a screen for generating a request;
receiving the request describing the organizational role and the abstract role; and
matching the organizational role and the abstract role in response to the request.
3. The method of claim 1, further comprising:
displaying a screen for generating a request;
receiving the request describing a value and a user set; and
associating the value and the user set in response to the request.
4. The method of claim 1, further comprising:
displaying a screen for generating a request;
receiving the request describing the organizational role and the set of values; and
associating the organizational role and the set of values in response to the request.
5. The method of claim 1, further comprising:
associating each value with a time period; determining a time period; and
determining the value according to the determined time period.
6. The method of claim 1, further comprising:
associating each value with a category;
assigning a category to the instance; and
determining the value according to the assigned category.
7. The method of claim 1, wherein routing the instance to the user set comprises transmitting a notification to one or more members of the user set.
8. A system for automating a business process, the system comprising:
a process designer operable to:
define an activity of a business process, activity associated with an abstract role representing a user responsible for performing the activity, said activity including one or more tasks; and
associate a compensation task with at least one task of the activity;
a data repository coupled to the process designer and operable to store the business process;
an organizational settings module coupled to the data repository and operable to:
define a parametric organizational role that specifies a group of users within an organization wherein the organizational role is associated with a parametric value; and
match the organizational role and the abstract role; and
an execution engine coupled to the data repository and operable to:
receive an instance of the activity;
determine the parametric value for the organizational role at runtime; and
route the instance to a subset of the group of users of the organizational role according to the determined parametric value such that the organizational role can take on different subsets of the group of users depending on the parametric value determined at runtime;
determine that the task associated with the compensation task has failed in execution; and
execute the compensation task associated with the task that has failed in execution by un-doing one or more actions performed by the task up to a particular activity thereby resulting in a consistent state of the business process.
9. The system of claim 8, wherein the organizational settings module is operable to:
display a screen for generating a request;
receive the request describing the organizational role and the abstract role; and
match the organizational role and the abstract role in response to the request.
10. The system of claim 8, wherein the organizational settings module is operable to:
display a screen for generating a request;
receive the request describing a value and a user set; and
associate the value and the user set in response to the request.
11. The system of claim 8, wherein the organizational settings module is operable to:
display a screen for generating a request;
receive the request describing the organizational role and the set of values; and
associate the organizational role and the set of values in response to the request.
12. The system of claim 8, wherein:
the organizational settings module is operable to associate each value with a time period;
the execution engine is operable to:
determine a time period; and
determine the value according to the determined time period.
13. The system of claim 8, wherein:
the organizational settings module is operable to associate each value with a category;
the execution engine is operable to:
assign a category to the instance; and
determine the value according to the assigned category.
14. The system of claim 8, wherein the execution engine is operable to transmit a notification to one or more members of the user set.
15. Software for automating a business process, the software embodied in a medium and when executed operable to:
define a business process by using a graphical user interface (GUI), said business process including one or more activities coupled by a set of transitions, each activity including one or more tasks;
define an activity of a business process, the activity associated with an abstract role, the abstract role representing a user responsible for performing the activity;
associate a compensation task with at least one task of said activity
define an organizational role associated with a set of values, the organizational role operable to have a value from the set of values, each value corresponding to a user set;
define a parametric organizational role that specifies a group of users within an organization wherein the organizational role is associated with a parametric value; match the organizational role and the abstract role;
execute an instance of the activity;
determine the parametric value for the organizational role at runtime;
routing the instance to a subset of the group of users of the organizational role according to the determined parametric value such that the organizational role can take on different subsets of the group of users depending on the parametric value determined at runtime;
determine that the task associated with the compensation task has failed in execution; and
execute the compensation task associated with the task that has failed in execution by un-doing one or more actions performed by the task up to a particular activity, thereby resulting in a consistent state of the business process.
16. The software of claim 15, operable to:
display a screen for generating a request;
receive the request describing the organizational role and the abstract role; and
match the organizational role and the abstract role in response to the request.
17. The software of claim 15, operable to:
display a screen for generating a request;
receive the request describing a value and a user set; and
associate the value and the user set in response to the request.
18. The software of claim 15, operable to:
display a screen for generating a request;
receive the request describing the organizational role and the set of values; and
associate the organizational role and the set of values in response to the request.
19. The software of claim 15, operable to:
associate each value with a time period;
determine a time period; and
determine the value according to the determined time period.
20. The software of claim 15, operable to:
associate each value with a category;
assign a category to the instance; and
determine the value according to the assigned category.
21. The software of claim 15, operable to route the instance to the user set comprises transmitting a notification to one or more members of the user set.
22. A system for automating a business process, the system comprising:
a process designer operable to:
define an activity of a business process, the activity associated with an abstract role, the abstract role representing a user responsible for performing the activity, said activity including one or more tasks; and
associate a compensation task with at least one task of the activity;
a data repository coupled to the process designer and operable to store the business process;
an organizational settings module coupled to the data repository and operable to:
display a first screen for generating a first request;
receive the first request describing a parametric organizational role and a set of parametric values;
associate the organizational role and the set of values in response to the first request, the organizational role operable to have an value from the set of values;
display a second screen for generating a second request;
receive the second request describing a value of the set of values and a user set;
associate the value and the user set in response to the second request;
associate the value with a time period;
display a third screen for generating a third request;
receive the third request describing the organizational role and the abstract role; and
match the organizational role and the abstract role in response to the third request; and
an execution engine coupled to the data repository and operable to:
receive an instance of the activity;
determine the time period;
assign the value to the determined time period at runtime;
route the instance to a subset of users from the user set according to the determined time period that is assigned to the value;
transmit a notification to one or more members of the user set;
determine that the task associated with the compensation task has failed in execution; and
execute the compensation task associated with the task that has failed in execution by un-doing one or more actions performed by the task up to a particular activity, thereby resulting in a consistent state of the business process.
US10/114,585 2001-03-30 2002-04-01 Designing business processes using parametric roles Abandoned US20080313003A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US10/114,585 US20080313003A1 (en) 2001-03-30 2002-04-01 Designing business processes using parametric roles

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US28062201P 2001-03-30 2001-03-30
US10/114,585 US20080313003A1 (en) 2001-03-30 2002-04-01 Designing business processes using parametric roles

Publications (1)

Publication Number Publication Date
US20080313003A1 true US20080313003A1 (en) 2008-12-18

Family

ID=39678806

Family Applications (4)

Application Number Title Priority Date Filing Date
US10/114,146 Active 2025-09-10 US7412399B1 (en) 2001-03-30 2002-04-01 Designing business processes using distributed process flows
US10/114,493 Abandoned US20080300928A1 (en) 2001-03-30 2002-04-01 Publishing and deploying business processes
US10/114,491 Active 2026-10-18 US8478602B2 (en) 2001-03-30 2002-04-01 Executing business processes using persistent variables
US10/114,585 Abandoned US20080313003A1 (en) 2001-03-30 2002-04-01 Designing business processes using parametric roles

Family Applications Before (3)

Application Number Title Priority Date Filing Date
US10/114,146 Active 2025-09-10 US7412399B1 (en) 2001-03-30 2002-04-01 Designing business processes using distributed process flows
US10/114,493 Abandoned US20080300928A1 (en) 2001-03-30 2002-04-01 Publishing and deploying business processes
US10/114,491 Active 2026-10-18 US8478602B2 (en) 2001-03-30 2002-04-01 Executing business processes using persistent variables

Country Status (1)

Country Link
US (4) US7412399B1 (en)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050249337A1 (en) * 2004-03-18 2005-11-10 Ordille Joann J Method and apparatus for just in time education
US20130047090A1 (en) * 2004-10-01 2013-02-21 Salesforce.Com, Inc. Multiple stakeholders for a single business process
US8510392B2 (en) 2002-05-14 2013-08-13 Avaya Inc. Method and apparatus for automatic notification and response
WO2013126826A1 (en) * 2012-02-24 2013-08-29 Winshuttle, Llc Dynamic web services workflow system and method
US9129238B2 (en) 2010-05-12 2015-09-08 Winshuttle, Llc Dynamic web services work flow system and method
US10178050B2 (en) 2004-05-19 2019-01-08 Salesforce.Com, Inc. Techniques for providing connections to services in a network environment
US11070626B2 (en) 2001-03-30 2021-07-20 Salesforce.Com, Inc. Managing messages sent between services

Families Citing this family (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7523133B2 (en) * 2002-12-20 2009-04-21 Oracle International Corporation Data model and applications
CA2442799A1 (en) 2003-09-26 2005-03-26 Ibm Canada Limited - Ibm Canada Limitee Generalized credential and protocol management of infrastructure
US20060195798A1 (en) * 2005-02-28 2006-08-31 Chan Hoi Y Method and apparatus for displaying and interacting with hierarchical information and time varying rule priority
US20060200489A1 (en) * 2005-03-03 2006-09-07 Microsoft Corporation Company modeling
US7900152B2 (en) * 2005-03-03 2011-03-01 Microsoft Corporation Adaptable user interface for business software
US20070033080A1 (en) * 2005-08-04 2007-02-08 Prolify Ltd. Method and apparatus for process discovery related applications
US8095531B2 (en) * 2006-10-03 2012-01-10 Salesforce.Com, Inc. Methods and systems for controlling access to custom objects in a database
US20080114627A1 (en) * 2006-11-15 2008-05-15 Sap Ag System and Method for Capturing Process Instance Information in Complex or Distributed Systems
WO2008067309A2 (en) * 2006-11-27 2008-06-05 Sourcecode Technology Holding, Inc. Methods and apparatus for tokenizing workflow process objects
JP4843532B2 (en) * 2007-03-14 2011-12-21 株式会社リコー Display processing apparatus, display processing method, and display processing program
US8424011B2 (en) * 2007-05-31 2013-04-16 Sap Ag Multiple instance management for workflow process models
US20100107165A1 (en) * 2008-10-24 2010-04-29 Oskari Koskimies Method, system, and apparatus for process management
US20100169487A1 (en) * 2008-12-30 2010-07-01 Daptiv Dynamic data processing applications with multiple record types and work management
US9904898B2 (en) * 2010-03-05 2018-02-27 Oracle International Corporation Distributed order orchestration system with rules engine
US10789562B2 (en) 2010-03-05 2020-09-29 Oracle International Corporation Compensation patterns for adjusting long running order management fulfillment processes in an distributed order orchestration system
US10061464B2 (en) 2010-03-05 2018-08-28 Oracle International Corporation Distributed order orchestration system with rollback checkpoints for adjusting long running order management fulfillment processes
US9805314B2 (en) * 2010-08-26 2017-10-31 Red Hat, Inc. Storing a business process state
US9658901B2 (en) 2010-11-12 2017-05-23 Oracle International Corporation Event-based orchestration in distributed order orchestration system
US8707248B2 (en) * 2011-03-26 2014-04-22 Accenture Global Services Limited Transformation framework
US10552769B2 (en) 2012-01-27 2020-02-04 Oracle International Corporation Status management framework in a distributed order orchestration system
US9672560B2 (en) 2012-06-28 2017-06-06 Oracle International Corporation Distributed order orchestration system that transforms sales products to fulfillment products
US9519879B1 (en) * 2012-08-24 2016-12-13 Tibco Software Inc. Just in time compilation (JIT) for business process execution
JP6582467B2 (en) * 2015-03-18 2019-10-02 キヤノンマーケティングジャパン株式会社 Program, workflow system and processing method
US11823261B2 (en) 2021-12-10 2023-11-21 Bank Of America Corporation Process orchestration and dynamic data acquisition system

Citations (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5214756A (en) * 1989-03-10 1993-05-25 International Business Machines Corporation Direct manipulation of icons via conversational linking
US5862379A (en) * 1995-03-07 1999-01-19 International Business Machines Corporation Visual programming tool for developing software applications
US5892948A (en) * 1996-02-19 1999-04-06 Fuji Xerox Co., Ltd. Programming support apparatus and method
US6054986A (en) * 1996-09-13 2000-04-25 Yamatake-Honeywell Co., Ltd. Method for displaying functional objects in a visual program
US6225998B1 (en) * 1997-12-02 2001-05-01 Aspect Communications Visual design of workflows for transaction processing
US6278977B1 (en) * 1997-08-01 2001-08-21 International Business Machines Corporation Deriving process models for workflow management systems from audit trails
US20010044738A1 (en) * 2000-03-22 2001-11-22 Alex Elkin Method and system for top-down business process definition and execution
US6338074B1 (en) * 1997-07-23 2002-01-08 Filenet Corporation System for enterprise-wide work flow automation
US6366300B1 (en) * 1997-03-11 2002-04-02 Mitsubishi Denki Kabushiki Kaisha Visual programming method and its system
US6507875B1 (en) * 1997-01-08 2003-01-14 International Business Machines Corporation Modular application collaboration including filtering at the source and proxy execution of compensating transactions to conserve server resources
US20030078957A1 (en) * 2001-08-29 2003-04-24 Cheeniyil Lakshmi Kutty Migration of a workflow system to changed process definitions
US6725445B1 (en) * 1999-07-08 2004-04-20 International Business Machines Corporation System for minimizing notifications in workflow management system
US20040098154A1 (en) * 2000-10-04 2004-05-20 Mccarthy Brendan Method and apparatus for computer system engineering
US6751657B1 (en) * 1999-12-21 2004-06-15 Worldcom, Inc. System and method for notification subscription filtering based on user role
US6766324B2 (en) * 2001-07-20 2004-07-20 International Business Machines Corporation System and method for defining, configuring and using dynamic, persistent Java classes
US7024669B1 (en) * 1999-02-26 2006-04-04 International Business Machines Corporation Managing workload within workflow-management-systems
US7027997B1 (en) * 2000-11-02 2006-04-11 Verizon Laboratories Inc. Flexible web-based interface for workflow management systems

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5469562A (en) * 1992-06-26 1995-11-21 Digital Equipment Corporation Durable atomic storage update manager
US5832203A (en) * 1995-01-23 1998-11-03 Tandem Computers Incorporated Method for providing recovery from a failure in a system utilizing distributed audit
US5944781A (en) * 1996-05-30 1999-08-31 Sun Microsystems, Inc. Persistent executable object system and method
US5940804A (en) 1996-12-18 1999-08-17 Turley; William N. Computer executable workflow resource management system
US5895492A (en) * 1997-05-28 1999-04-20 International Business Machines Corporation Processor associated blocking symbol controls for serializing the accessing of data resources in a computer system
US6185577B1 (en) * 1998-06-23 2001-02-06 Oracle Corporation Method and apparatus for incremental undo
US6295610B1 (en) * 1998-09-17 2001-09-25 Oracle Corporation Recovering resources in parallel
US6286028B1 (en) 1998-12-01 2001-09-04 International Business Machines Corporation Method and apparatus for conducting electronic commerce
US7062749B2 (en) 2000-12-15 2006-06-13 Promenix, Inc. Measuring, monitoring and tracking enterprise communications and processes

Patent Citations (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5214756A (en) * 1989-03-10 1993-05-25 International Business Machines Corporation Direct manipulation of icons via conversational linking
US5862379A (en) * 1995-03-07 1999-01-19 International Business Machines Corporation Visual programming tool for developing software applications
US5892948A (en) * 1996-02-19 1999-04-06 Fuji Xerox Co., Ltd. Programming support apparatus and method
US6054986A (en) * 1996-09-13 2000-04-25 Yamatake-Honeywell Co., Ltd. Method for displaying functional objects in a visual program
US6507875B1 (en) * 1997-01-08 2003-01-14 International Business Machines Corporation Modular application collaboration including filtering at the source and proxy execution of compensating transactions to conserve server resources
US6366300B1 (en) * 1997-03-11 2002-04-02 Mitsubishi Denki Kabushiki Kaisha Visual programming method and its system
US6338074B1 (en) * 1997-07-23 2002-01-08 Filenet Corporation System for enterprise-wide work flow automation
US6278977B1 (en) * 1997-08-01 2001-08-21 International Business Machines Corporation Deriving process models for workflow management systems from audit trails
US6225998B1 (en) * 1997-12-02 2001-05-01 Aspect Communications Visual design of workflows for transaction processing
US7024669B1 (en) * 1999-02-26 2006-04-04 International Business Machines Corporation Managing workload within workflow-management-systems
US6725445B1 (en) * 1999-07-08 2004-04-20 International Business Machines Corporation System for minimizing notifications in workflow management system
US6751657B1 (en) * 1999-12-21 2004-06-15 Worldcom, Inc. System and method for notification subscription filtering based on user role
US20010044738A1 (en) * 2000-03-22 2001-11-22 Alex Elkin Method and system for top-down business process definition and execution
US20040098154A1 (en) * 2000-10-04 2004-05-20 Mccarthy Brendan Method and apparatus for computer system engineering
US7027997B1 (en) * 2000-11-02 2006-04-11 Verizon Laboratories Inc. Flexible web-based interface for workflow management systems
US6766324B2 (en) * 2001-07-20 2004-07-20 International Business Machines Corporation System and method for defining, configuring and using dynamic, persistent Java classes
US20030078957A1 (en) * 2001-08-29 2003-04-24 Cheeniyil Lakshmi Kutty Migration of a workflow system to changed process definitions

Cited By (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11070626B2 (en) 2001-03-30 2021-07-20 Salesforce.Com, Inc. Managing messages sent between services
US8510392B2 (en) 2002-05-14 2013-08-13 Avaya Inc. Method and apparatus for automatic notification and response
US9124643B2 (en) 2002-06-26 2015-09-01 Avaya Inc. Method and apparatus for a publish-subscribe system with templates for role-based view of subscriptions
US8495163B2 (en) 2004-03-18 2013-07-23 Avaya, Inc. Method and apparatus for a publish-subscribe system with templates for role-based view of subscriptions
US8516045B2 (en) 2004-03-18 2013-08-20 Avaya Inc. Method and apparatus for automatic notification and response based on communication flow expressions having dynamic context
US20050249337A1 (en) * 2004-03-18 2005-11-10 Ordille Joann J Method and apparatus for just in time education
US10178050B2 (en) 2004-05-19 2019-01-08 Salesforce.Com, Inc. Techniques for providing connections to services in a network environment
US10778611B2 (en) 2004-05-19 2020-09-15 Salesforce.Com, Inc. Techniques for providing connections to services in a network environment
US11483258B2 (en) 2004-05-19 2022-10-25 Salesforce, Inc. Techniques for providing connections to services in a network environment
US9645712B2 (en) 2004-10-01 2017-05-09 Grand Central Communications, Inc. Multiple stakeholders for a single business process
US9792002B2 (en) * 2004-10-01 2017-10-17 Salesforce.Com, Inc. Multiple stakeholders for a single business process
US11042271B2 (en) 2004-10-01 2021-06-22 Salesforce.Com, Inc. Multiple stakeholders for a single business process
US20130047090A1 (en) * 2004-10-01 2013-02-21 Salesforce.Com, Inc. Multiple stakeholders for a single business process
US9129238B2 (en) 2010-05-12 2015-09-08 Winshuttle, Llc Dynamic web services work flow system and method
WO2013126826A1 (en) * 2012-02-24 2013-08-29 Winshuttle, Llc Dynamic web services workflow system and method

Also Published As

Publication number Publication date
US7412399B1 (en) 2008-08-12
US8478602B2 (en) 2013-07-02
US20080306746A1 (en) 2008-12-11
US20080300928A1 (en) 2008-12-04

Similar Documents

Publication Publication Date Title
US7412399B1 (en) Designing business processes using distributed process flows
US7096222B2 (en) Methods and systems for auto-instantiation of storage hierarchy for project plan
AU2001249273B2 (en) Method and system for top-down business process definition and execution
US8032635B2 (en) Grid processing in a trading network
US6968343B2 (en) Methods and systems for integrating process modeling and project planning
US9632768B2 (en) Exchanging project-related data in a client-server architecture
US5734837A (en) Method and apparatus for building business process applications in terms of its workflows
US20030195789A1 (en) Method for incorporating human-based activities in business process models
US7403948B2 (en) Workflow system and method
US7653566B2 (en) Systems and methods for automating a process of business decision making and workflow
US7836103B2 (en) Exchanging project-related data between software applications
US20020188597A1 (en) Methods and systems for linking tasks to workflow
US20040187140A1 (en) Application framework
US20030189600A1 (en) Defining an approval process for requests for approval
AU2001249273A1 (en) Method and system for top-down business process definition and execution
CN113692582A (en) User interface for establishing data privacy pipeline and contract agreement to share data
US7469217B2 (en) Product toolkit system and method
US20210103862A1 (en) Methods and apparatus for exposing workflow process definitions as business objects
EP2249295A2 (en) Using composite systems to improve functionality
US8863132B2 (en) Using abstraction layers to facilitate communication between systems
WO2002099637A1 (en) Methods and systems for auto-instantiation of storage hierarchy for project plan
Groiss et al. Business Process Management with@ enterprise
Guide Oracle r Workflow

Legal Events

Date Code Title Description
AS Assignment

Owner name: FUEGO, INC., TEXAS

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:RACCA, FELIX G.;GABEIRAS, EMILIO L.;REEL/FRAME:013021/0592;SIGNING DATES FROM 20020604 TO 20020610

AS Assignment

Owner name: BEA SYSTEMS, INC., CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:FUEGO, INC.;REEL/FRAME:018976/0693

Effective date: 20070301

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION