Method and apparatus for managing and displaying user authorizations for a business process managed using a state machine

Abstract

A method and apparatus are disclosed for managing access control for a business process that is managed using a state machine. A domain represents the various trading mechanisms that are supported by a business process. Domains are placed at the highest level in a tree structure. Within each domain, there is one or more different flow types defined, such as flow types for buyers and sellers. Within each flow type, one or more flows or business processes may be defined. A flow defines the order of the steps required to produce an object. Each flow typically begins with a mandatory “start” state, having one or more transitions to additional states. Each transition may contain an access control guard. The guards on the transitions leading from the start state can be referenced to determine the user's authorization to access the domains, flow types, and flows. In this manner, the menu of options presented to the user may be automatically tailored to present only those actions which the particular user is authorized to perform. Thus, a navigational tool is provided that presents the various valid choices that are available to the end-user.

Description

FIELD OF THE INVENTION

[0002] The present invention relates generally to techniques for representing business processes as state machines, and more particularly, to a method and apparatus for displaying the authorized actions for a user for a business process that is managed using a state machine.

BACKGROUND OF THE INVENTION

[0003] Business processes are often used to manage various trading mechanisms, such as auctions, contracts, and requests for quotes (RFQs). At the same time, much of business revolves around making decisions and other user actions. Typically, these decisions are made by authorized individuals acting on behalf of their organizations, applying a variety of rules or guidelines. The actual decision-making logic may be simple or extremely complex depending upon the needs of the business and the decision being made. However, the demands on decision-makers are rapidly increasing along with the pace of business. This leaves the decision-makers overloaded, many times with trivial decisions, thus decreasing the amount of time that they have to focus on more important decisions. It has been found that business processes can be represented using a state machine. State machines provide a way to control the set of events and actions that may be performed by authorized users throughout the life cycle of a business object.

[0004] Among other benefits, state machines provide a means for automating some decision-making. For example, if the number of levels of approval in a business process could be configured in such a way that it appeared to dynamically change at run time to match the requirements of the user organization, then many organizations would be able to share the same business process. If this same mechanism also allowed automatic decision-making support for the more routine decisions, then the workload of the decision-makers could be eased to allow them to focus their attention on the more difficult matters. Overall, there would be increased flexibility without increased expense or complexity.

[0005] As more businesses move towards electronic commerce, especially for business-to-business transactions, the number of business processes and trading mechanisms they are using is increasing significantly. To date, most of the innovation in technology has focused on improving the business processes and trading mechanisms themselves. The management of the diverse set of business processes has been mostly ignored.

[0006] In order for the user operating within these environments to be highly productive, the user must be able to rapidly select the trading mechanism and business process required for each transaction. Too often it is easy for users to select the wrong process and erroneously follow paths which lead to a rejection after a great deal of time and effort has already been invested.

[0007] A need therefore exists for a means for organizing state machines to provide a natural flow for the users of the state machine. The navigation of a state machine is particularly challenging when the associated organizations define and use many different business processes in a variety of trading mechanisms. The selection and identification of which trading mechanism and then which business process to use for each object will likely be based upon the specific organization within the marketplace and possibly a user-selection.

SUMMARY OF THE INVENTION

[0008] Generally, a method and apparatus are disclosed for illustrating the actions that a user can perform for a business process that is managed using a state machine. A domain represents the various trading mechanisms that are supported by a business process, such as auctions, contracts, and requests for quotes (RFQs), and are placed at the highest level in a tree structure. Within each domain, there is one or more different flow types defined, such as flow types for buyers and sellers. Within each flow type, one or more flows or business processes may be defined. A flow defines the order of the steps required to produce an object, such as an RFQ, including any required steps for approval. Each flow typically begins with a mandatory “start” state, having one or more transitions to additional states. Each transition may contain an access control guard.

[0009] According to one aspect of the invention, the guards on each start state control access to the various possible flows by each user. Thus, the guards on the transitions leading from the start state can be referenced to determine the user's authorization to access the domains, flow types, and flows. In this manner, the menu of options presented to the user may be automatically tailored to present only those actions which the particular user is authorized to perform. Thus, according to another aspect of the invention, a navigational tool is provided that presents the various valid choices that are available to the end-user.

[0010] A more complete understanding of the present invention, as well as further features and advantages of the present invention, will be obtained by reference to the following detailed description and drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

[0011] FIG. 1 illustrates an exemplary conventional state machine having two states for managing a business process;

[0012] FIG. 2 illustrates the hierarchical nature of a marketplace where organizations interact to conduct business-to-business actions in an online marketplace;

[0013] FIG. 3 illustrates exemplary code that may be utilized as a guard for a start state in a state machine in accordance with the present invention;

[0014] FIG. 4 illustrates an exemplary user interface that allows a user to select a domain and flow for a given business object in accordance with one embodiment of the present invention;

[0015] FIGS. 5A and 5B are samples tables that are employed to help increase the speed of filtering the set of flows and transitions that are checked in accordance with the present invention; and

[0016] FIG. 6 illustrates an exemplary network environment in which the present invention can operate.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

[0017] The present invention provides a navigational tool for illustrating the actions that a user can perform for a business process that is managed using a state machine. A business process management system is disclosed that classifies the trading mechanisms that are managed and extends access control capabilities to filter the set of options presented to a user. As discussed further below, the hierarchy of trading mechanisms is presented to the user as a tree structure. However, the view for the users in any one organization operating within a given marketplace may be a fairly heavily pruned tree.

[0018] Domains represent the various trading mechanisms that are supported, such as auctions, contracts, and requests for quotes (RFQs), and are placed at the highest level in the tree structure. Within each domain, there is one or more different flow types defined. Many of the trading mechanisms will actually have two flow types defined, one for the buyer and one for the seller. For example, a request for quotes trading mechanism typically defines business processes for managing the creation and processing of the request for quotes itself, as well as for managing any responses to the request for quotes.

[0019] Within each flow type, one or more flows or business processes may be defined. A flow defines the order of the steps required to produce an object, such as an RFQ, including any required steps for approval. Typically, there are a number of possible business processes from which an organization may select. Each flow typically begins with a mandatory “start” state. From the start state, there may be one or more transitions to additional states. Each transition may contain an access control guard and optionally a business control guard.

[0020] According to one feature of the present invention, the guards are used to control access to the flows by each user. Furthermore, the guards are used to drive the available options presented to users when navigating through the selection of trading mechanisms and flows. In this manner, the menu of options presented to the user may be automatically tailored by the business flow manager of the present invention to present only those actions which the particular user is authorized to perform. In other words, if the organization to which the user belongs only utilizes, for example, the auction and request for quotes trading mechanisms, and the user has been authorized by the organization administrator to operate in these environments, then those options are the only options provided to the user, when a trading mechanism must be selected.

State Machine Terminology

[0021] Business processes can be represented using a state machine. State machines provide a way to control the set of events and actions that may be performed throughout the life cycle of a business object. The Unified Modeling Language (UML) provides a standardized syntax for describing state machines. FIG. 1 illustrates an exemplary state machine 100 having two states 110, 120 with a single transition 115 leading from the Start state 110 to the Active state 120. The transition 115 is composed of three parts. First, there is an event 130 that defines what may cause this transition 115 to be attempted. Second, one or more guards 140 determine whether or not the transition 115 may be taken based upon some predefined criteria, such as the authority of the user or certain values associated with the business object. Finally, the action 150 provides a means for identifying logic that may act upon, or on behalf of, the object being managed by the state machine 100. Thus, if the transition 115 is allowed according to the guards 140, then the action 150 is performed and the object moves into the Active state 120. The various components of a transition 115 can be expressed using the notation “event [guard] action.”

[0022] For a more detailed discussion of techniques for managing business processes using a state machine, see, for example, U.S. patent application Ser. No. 09/818,719, filed Mar. 27, 2001, entitled “E-Market Architecture for Supporting Multiple Roles and Reconfigurable Business Processes,” August-Wilhelm Scheer, Aris—Business Process Modeling, Springer Verlag, 1999 or Peter Muth et al., Enterprise-Wide Workflow Management Based on State and Activity Charts, in A. Dogac, L. Kalinichenko, T. Ozsu, A. Sheth (Editors), Workflow Management Systems and Interoperability, Springer Verlag, 1998, each incorporated by reference herein.

[0023] With this basic understanding of the UML syntax, consider an overview of an exemplary online marketplace, such as the marketplace 200 shown in FIG. 2. FIG. 2 shows the hierarchical nature of a marketplace 200 where organizations interact to conduct business-to-business actions in an online marketplace. The marketplace 200 may consist of multiple markets, each with its own set of trading mechanisms (domains). Each domain may then consist of one or more flow types, and each flow type may consist of one or more flows (business processes). The business processes themselves may be used within multiple markets

[0024] In this example, the marketplace 200 includes companies that deal with clothing-related items. In Market_A, the clothing manufacturers may interact with suppliers of fabric and other clothing accessories. Meanwhile, in Market_B, the clothing manufacturers may interact with wholesale clothing distributors who will purchase their finished goods.

[0025] In this example, Market_A supports trading mechanisms for Requests For Quotes (RFQs) and Auctions, while Market_B supports only Auctions. A trading mechanism, such as an RFQ or auction, is referred to herein as a domain. Within a domain, there are typically two different perspectives, referred to herein as flow types, one for the buyer and one for the seller, each with its own set of business processes. In the example of FIG. 2, the buyers use RFQ Requests in the RFQ domain and Bids in the Auction domain, while the sellers use RFQ Responses and Auction Item. Each flow type will in turn include one or more business processes or flows, designated RFQreq101 and RFQrsp01 in FIG. 2. These two flows are specific implementations of an RFQ request and RFQ response, respectively. Although FIG. 2 displays the complete set of options available within the exemplary marketplace 200, not all organizations may choose to operate within all markets or domains. Nor may organizations necessarily use all of the defined flows. This choice is reserved for each organization to make, based upon its own particular business needs. Continuing the clothing example of FIG. 2, a wholesale distributor may have no need to operate within Market_A, so it would only want its employees to have access to Market_B. In addition, since the organization may not intend to sell anything within Market_B, the company would probably restrict access to the Bid flow type within the Auction domain. Moreover, the company may wish to only use Dutch Auctions. This means that all of their employees may only use business processes (flows) in the Bid flow type that supported Dutch Auctions. In this example, there is only one such flow, AucDut02. Other organizations in this marketplace, of course, will also likely want to restrict access to markets, trading mechanisms, flow types and business processes according to their own needs.

[0026] Now consider a clothing manufacturer that operates within both Market_A and Market_B. Overall, this company may use more of the available domains and flow types and a different set of the provided flows than the wholesale distributor does. However, the company may not want to allow all of its employees to have access to all domains, flow types or flows. Therefore, it is likely that each user, or group of users, in the company may have a slightly different view of the overall marketplace.

[0027] According to another aspect of the invention, a navigational tool is provided that presents the various valid choices that are available to the end-user. Each business process (flow) begins with a start state. The guards on the transitions leading from the start state will be referenced to determine the users' access to the domains, flow types, and flows. The guards defined by the creator of the business flows, combined with the user roles assigned by the organization administrator from their company, along with any additional controls from the access control and business guards, are used to filter the set of flows made available to any given user.

[0028] Once a set of options available to the user have been identified, the user is presented with only a set of valid and permissible choices. For example, out of the many options defined in the marketplace, one user may only be allowed to work with Auction Items. Meanwhile, another user may be able to work with Auction Bids and RFQ Requests. By limiting the list of options presented to the user to those which the user is allowed to perform, the frustration of wasting time pursuing options which will ultimately lead to failure or denial is avoided.

[0029] There are a number of ways to implement each of the aspects behind this overall design. First, to determine the set of options available to the user, all of the transitions which lead out of the Start states of all of the business processes are identified and the guards are executed for each of them. The transitions which have guards which would be satisfied are returned to be presented to the user interface. For example, the exemplary logic shown in FIG. 3 may result in a given user, such as User A, being determined to have access to the RFQ and Auction trading mechanisms. An appropriate user interface is shown in FIG. 4 for the example of FIG. 3. It is noted that the Contract trading mechanism is indicated in FIG. 4 with a strike-through, indicating that the Contract trading mechanism is not available to this user. Furthermore, for the RFQ trading mechanism, the user is authorized to participate in Fast RFQs, Multiround RFQs and Standard RFQs. Likewise, for the Auction trading mechanism, the user is authorized to participate in Dutch Auctions, Reverse Auctions and Standard Auctions.

[0030] FIGS 5A and 5B illustrate exemplary databases (or additional columns to existing database tables) that can be employed to increase the speed of filtering the set of flows and transitions that are checked in accordance with the present invention. FIG. 5A illustrates an organizational flow database 500 that provides organizational information. The organizational flow database 500 allows quick reference of the markets and domains used by an organization (using the organization ID), thus allowing you to quickly limit the flow search. The table 500 can be searched for all flows where the OrgEntity_Id matches the user's organization, and then only the guards for this set of flows has to be checked. Likewise, FIG. 5B is a sample table from a flow database that includes a Role column. In this manner, the table 550 can be searched for all flows where the Role is equal to the role of the current user and thereby limit the number of guards that need to be checked.

[0031] Once the business process manager has determined the set of flows which a user may access, it can provide a list of the valid choices to the user interface, perhaps a Java Server Page, as shown in FIG. 4 for the example of FIG. 3. For example, the user interface could display only the valid choices in some form (e.g., using a menu, buttons, or drop down list) or graying out and making options which are not supported for this user non-selectable. Using either one of these options, the user is allowed only to make choices that are valid to their identity or role. Although a sophisticated user may try to bypass the limited choices which are presented by their graphic user interface (GUI) by trying to construct and submit a prohibited choice, our system would prohibit the action(s) since the guards on the transition would reject access. Therefore, the user will be stopped from executing any restricted commands.

[0032] FIG. 6 illustrates an exemplary network environment 610 in which the present invention can operate. As shown in FIG. 6, a web server 620 communicates over a network 610 with a user terminal 660. For example, the user 660 may submit an order for goods or services to the web server 620. The process that determines whether a given user has sufficient authorization to perform a certain task may be managed in accordance with a business process navigational tool 650 incorporating features of the present invention, as discussed above. The network 610 can be any wired or wireless network for transferring information, such as a data network or a telephone network.

[0033] Memory 640 will configure the processor 630 to implement the methods, steps, and functions disclosed herein. The memory 640 could be distributed or local and the processor 630 could be distributed or singular. The memory 640 could be implemented as an electrical, magnetic or optical memory, or any combination of these or other types of storage devices. The term “memory” should be construed broadly enough to encompass any information able to be read from or written to an address in the addressable space accessed by processor 630. With this definition, information on a network 610 is still within memory 640 of the web server 620 because the processor 630 can retrieve the information from the network 610.

[0034] As is known in the art, the methods and apparatus discussed herein may be distributed as an article of manufacture that itself comprises a computer readable medium having computer readable code means embodied thereon. The computer readable program code means is operable, in conjunction with a computer system, to carry out all or some of the steps to perform the methods or create the apparatuses discussed herein. The computer readable medium may be a recordable medium (e.g., floppy disks, hard drives, compact disks, or memory cards) or may be a transmission medium (e.g., a network comprising fiber-optics, the world-wide web, cables, or a wireless channel using time-division multiple access, code-division multiple access, or other radio-frequency channel). Any medium known or developed that can store information suitable for use with a computer system may be used. The computer-readable code means is any mechanism for allowing a computer to read instructions and data, such as magnetic variations on a magnetic media or height variations on the surface of a compact disk.

[0035] It is to be understood that the embodiments and variations shown and described herein are merely illustrative of the principles of this invention and that various modifications may be implemented by those skilled in the art without departing from the scope and spirit of the invention.

Claims

1. A method for managing a business process using a state machine, said method comprising the steps of: defining one or more trading mechanisms for said business, each of said trading mechanisms having one or more different flow types; defining one or more flows within each of said flow types, each of said flows defining an order of steps to perform on an object, each of said flows commencing with a start state having one or more transitions to additional states, each of said transitions including a guard that determines whether said corresponding transition may be taken to another state; and evaluating said guards to present a list of available options to a user.

2. The method of claim 1, wherein said list of available options presented to a user presents only valid options.

3. The method of claim 1, wherein said list of available options presented to a user is presented using a graphical user interface.

4. The method of claim 3, wherein a user can select a valid option from said list.

5. The method of claim 3, wherein said graphical user interface makes invalid options non-selectable.

6. The method of claim 1, wherein said flow types include flow types for a buyer and a seller.

7. The method of claim 1, wherein said evaluating step further comprises the steps of identifying all of the transitions leading out of a start state of all possible flows and executing the guards for each of said transitions.

8. The method of claim 7, further comprising the step of presenting all transitions corresponding to guards that are satisfied.

9. The method of claim 7, wherein said evaluating step further comprises the steps of storing organizational information to increase a speed of filtering said set of flows and transitions that are checked.

10. The method of claim 7, wherein said evaluating step further comprises the steps of storing user role information to increase a speed of filtering said set of flows and transitions that are checked.

11. A system for managing a business process using a state machine, comprising: a memory that stores computer-readable code; and a processor operatively coupled to said memory, said processor configured to implement said computer-readable code, said computer-readable code configured to: define one or more trading mechanisms for said business, each of said trading mechanisms having one or more different flow types; define one or more flows within each of said flow types, each of said flows defining an order of steps to perform on an object, each of said flows commencing with a start state having one or more transitions to additional states, each of said transitions including a guard that determines whether said corresponding transition may be taken to another state; and evaluate said guards to present a list of available options to a user.

12. The system of claim 11, wherein said list of available options presented to a user presents only valid options.

13. The system of claim 11, wherein said list of available options presented to a user is presented using a graphical user interface.

14. The system of claim 13, wherein a user can select a valid option from said list.

15. The system of claim 13, wherein said graphical user interface makes invalid options non-selectable.

16. The system of claim 11, wherein said flow types include flow types for a buyer and a seller.

17. The system of claim 11, wherein said processor is further configured to identify all of the transitions leading out of a start state of all possible flows and execute the guards for each of said transitions.

18. The system of claim 17, further comprising the step of presenting all transitions corresponding to guards that are satisfied.

19. The system of claim 17, wherein said processor is further configured to store organizational information to increase a speed of filtering said set of flows and transitions that are checked.

20. The system of claim 17, wherein said processor is further configured to store user role information to increase a speed of filtering said set of flows and transitions that are checked.

21. An article of manufacture for managing a business process, comprising: a computer readable medium having computer readable code means embodied thereon, said computer readable program code means comprising: a step to provide conditional logic in said entry action, said entry action causing an automatic transition to another state if said conditional logic is satisfied.

22. An article of manufacture for managing a business process using a state machine, comprising: a computer readable medium having computer readable code means embodied thereon, said computer readable program code means comprising: a step to define one or more trading mechanisms for said business, each of said trading mechanisms having one or more different flow types; a step to define one or more flows within each of said flow types, each of said flows defining an order of steps to perform on an object, each of said flows commencing with a start state having one or more transitions to additional states, each of said transitions including a guard that determines whether said corresponding transition may be taken to another state; and a step to evaluate said guards to present a list of available options to a user.