Business object (BO) is a representation of a business entity used in a software solution, e.g., an employee, a customer, a purchase order, and a supplier invoice, etc. Typically, the BO includes data related to the business entity and one or more functions (processes) performed by the business entity. Each business object has various statuses or states, e.g., ‘new,’ ‘obsolete,’ ‘active,’ ‘in preparation,’ etc. The BO may switch from one status to another status, i.e., a transition from one status to another. A transaction may involve an action call, i.e., a call or operation to be performed on the BO to switch the BO from one status to another. For example, if the BO is in ‘active’ status then a destroy operation may be performed on the BO to bring it to ‘deleted’ status. Usually, a user specifies a desired status (target status) for the BO. The target status may be specified or provided by the user through a Web service at runtime. A sequence of transitions may be required to attain the target status. For example, if the user desires to create a new BO (e.g., a customer) in the ‘active’ status then the following sequence of transitions (e.g., T1-T3) may be required to attain the ‘active’ status from the ‘new’ status:
Transition (T1): new→in preparation;
Transition (T2): in preparation→review;
Transition (T3): review→active.
Usually, all valid transitions from one status (e.g., ‘new’) to another status (e.g., ‘active’) are defined in a status schema or a state diagram of the BO. The transitions following the status schema are valid transitions. Typically, a software developer consults the status schema to hardcode all valid paths from one status to another status in a Web service. The Web service receives the target status from the user and identifies the source or current status of the BO from a variable associated with the BO. Based upon the target status and the source status, the Web service selects a first valid hardcoded path from the source status to the target status. The Web Service executes the selected hardcoded path to attain the target status.
However, it may be a waste of resources, time, and effort to explicitly code (hardcode) all valid paths or transitions. Further, hardcoding all possible paths is an error prone process. Moreover, if the status schema is revised or updated, e.g., a new status added, an old status is edited or deleted, etc., then the hardcoded paths are also required to be revised by the software developer. Again, it requires an extra effort to keep track on the changes and hardcode the paths manually. Additionally, the hardcoded path selected by the Web Service to attain the target status may not be efficient (i.e., may not be a shortest path). Also, since each transition requires time consuming action calls, the number of action calls and hence the number of status transitions should be minimized. Finally, if the status schema includes a loop or a circular transition, e.g., status A→B, B→C, C→B, and C→D, and the Web Service executes an algorithm (e.g., greedy algorithm) for determining the path from the source to the target status then it might be possible that the BO goes into infinity loop between B→C and C→B repeatedly. Typically, the BO could not identify any paths between A→D and might display an error message stating that the target status cannot be attained.
Various embodiments of systems and methods for determining optimal sequence of status transitions for business objects are described herein. In one aspect, the method executed by one or more computers in a network of computers includes receiving a target status for a business object, identifying a source status of the business object, identifying a status schema including one or more transitions from the source status to the target status, parsing the status schema to retrieve the one or more transitions from the source status to the target status, generating a graphical representation illustrating the transitions from the source status to the target status, executing an algorithm upon the graphical representation to determine an optimal sequence of transitions from the source status to the target status, and processing the business object based upon the optimal sequence of transitions to attain the target status.
These and other benefits and features of embodiments of the invention will be apparent upon consideration of the following detailed description of preferred embodiments thereof, presented in connection with the following drawings.
The invention is illustrated by way of example and not by way of limitation in the figures of the accompanying drawings in which like references indicate similar elements. The embodiments of the invention, together with its advantages, may be best understood from the following detailed description taken in conjunction with the accompanying drawings.
Embodiments of techniques for optimal sequences of status transitions for business objects are described herein. In the following description, numerous specific details are set forth to provide a thorough understanding of embodiments of the invention. One skilled in the relevant art will recognize, however, that the invention can be practiced without one or more of the specific details, or with other methods, components, materials, etc. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the invention.
Reference throughout this specification to “one embodiment”, “this embodiment” and similar phrases, means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, the appearances of these phrases in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.
The target status 230 is a desirable status of the BO specified by the user or consumer. Typically, the target status 230 is specified through the Web services or the Web server. The user may define the target status 230 for an existing BO or a newly created BO. Once the target status 230 is specified, the OPD module 210 identifies the source status 220 of the BO. The source status 220 of the BO may be identified from the BO. Typically, the BO includes a field indicating a status variable (e.g., a lifecycle status variable) that indicates the source or current status 220 of the BO. In one embodiment, various transitions related to the source status 220 of the BO may be stored in the metadata repository 240.
Typically, the metadata repository 240 includes the status schema 250 related to the BO. The status schema 250 may illustrate various statuses (e.g., list-of-status 310) for the BO and various valid transitions (e.g., list-of-valid transitions 320) for each status of the BO, as illustrated in
The status schema 250 may be parsed or read to identify or retrieve one or more valid sequences of transitions to attain the target status 230 from the source status 220. For example, if the source status 220 is ‘A’ and the target status 230 is ‘E’, then the following sequences of transitions may be retrieved to attain the target status 230 (i.e., E) from the source status 220 (i.e., A):
i.) A→B→C→D→E; and
ii.) A→D→E.
In one embodiment, the OPD module 210 is associated with a graph generating module 400 (shown in
The graphical representation may be any suitable data structure illustrating the one or more sequences of transitions (e.g., i and ii) from the source status 220 (i.e., A) to the target status 230 (i.e., E). For example, the graphical representation may be a graph 500 (
In one embodiment, as illustrated in
Once the graphical representation (e.g., the graph 600 or 500) is generated, the OPD module 210 executes an algorithm 410. Typically, the algorithm 410 is executed upon, e.g., the graph 500 to determine the optimal path or status of transitions from the source status 220 (i.e., A) to the target status 230 (i.e., E). The algorithm may be a breadth first search algorithm (e.g., Dijkstra's algorithm). Typically, the Dijkstra's algorithm may find a shortest path (sequence of transitions or actions) from the source status ‘A’ to the target status ‘E.’ For example, the Dijkstra's algorithm may determine the transition A→D→E as the shortest transition or optimal sequences of transitions from the source status A to the target status E. Similarly, with respect to
Typically, each transition involves the action or operation to be performed on the BO. For example, for the transition from ‘in preparation’ to ‘active,’ the action ‘activate’ has to be performed on the BO. Similarly, for the transition from ‘active’ to ‘deleted’ the action ‘destroy’ has to be performed on the BO. Therefore, for the sequence of transition ‘in preparation’→‘active’→‘deleted,’ a corresponding sequence of actions ‘activate’ and ‘destroy’ has to be performed on the BO. Once the optimal path (sequence of transitions) from the source status 220 to the target status 230 is determined, the corresponding sequence of actions are executed to attain the target status 230. Typically, the shortest sequence of actions is determined to attain the target status 230.
In one embodiment, one or more predefined conditions may be fulfilled before attaining the target status 230 (i.e., E). For example, if the source status 220 (i.e., A) is ‘New’ for the BO (e.g., customer) and the target status 230 (i.e., E) is ‘Active’ then the information (e.g., name, address, etc) related to the BO or customer must be provided before reaching the target or ‘Active’ status (active status being the status ready to be used in a software solution). Typically, a Web Service (not shown) may determine if one or more predefined conditions are fulfilled or satisfied before reaching or achieving the target status 220.
In another embodiment, if the one or more predefined conditions are not fulfilled, an error message may be displayed on a user interface (UI). For example, the error message may be a prompt for entering required information (e.g., name and address) related to the BO. Once the target status 220 is attained, an XML response may be sent to the user or a confirmation message may be rendered on the UI. Further, the lifecycle status variable of the BO may be updated. For example, if the target status 230 is ‘active’ then the lifecycle status variable may be updated as ‘active.’ Typically, the status variable may be updated or keeps on changing as the status of the BO changes.
The embodiments enable the execution of the shortest path or the shortest sequence of action that requires less number of time consuming and costly calls. For example, the shortest path from the source status 220 (e.g., A) to the target status 230 (e.g., E) may be determined as A→D→E that requires only two calls (A→D and D→E) instead of A>B→C→D→E that requires four calls (A→B, B→C, C→D, and D→E). Importantly, it may be appreciated that if 2000 BOs are required to be transferred from one system to another in the target status 230 (i.e., E) from the source status 220 (i.e., A) then the system may require only 2*2000 or 4000 calls instead of 4*2000 or 8000 calls.
The embodiments provide optimal (e.g., shortest) path or sequence of transitions to attain the target status. The execution of the optimal path provides an efficient response time and enhance performance. Further, the optimal path requires less number of time consuming action calls which saves time and resources. Additionally, the automatic determination of the optimal path using a generic algorithm (e.g., Dijkstra's algorithm) obviates the need to explicitly hardcode the paths. Moreover, the embodiments provide robustness against the changes or extension of the status schema. For example, if the status schema is revised (e.g., the new status is added, old status is revised/edited or deleted), it is not required to manually hardcode new paths. Rather, the paths are automatically determined using the generic algorithm based upon the revised status schema.
Some embodiments of the invention may include the above-described methods being written as one or more software components. These components, and the functionality associated with each, may be used by client, server, distributed, or peer computer systems. These components may be written in a computer language corresponding to one or more programming languages such as, functional, declarative, procedural, object-oriented, lower level languages and the like. They may be linked to other components via various application programming interfaces and then compiled into one complete application for a server or a client. Alternatively, the components maybe implemented in server and client applications. Further, these components may be linked together via various distributed programming protocols. Some example embodiments of the invention may include remote procedure calls being used to implement one or more of these components across a distributed programming environment. For example, a logic level may reside on a first computer system that is remotely located from a second computer system containing an interface level (e.g., a graphical user interface). These first and second computer systems can be configured in a server-client, peer-to-peer, or some other configuration. The clients can vary in complexity from mobile and handheld devices, to thin clients and on to thick clients or even other servers.
The above-illustrated software components are tangibly stored on a computer readable storage medium as instructions. The term “computer readable storage medium” should be taken to include a single medium or multiple media that stores one or more sets of instructions. The term “computer readable storage medium” should be taken to include any physical article that is capable of undergoing a set of physical changes to physically store, encode, or otherwise carry a set of instructions for execution by a computer system which causes the computer system to perform any of the methods or process steps described, represented, or illustrated herein. Examples of computer readable storage media include, but are not limited to: magnetic media, such as hard disks, floppy disks, and magnetic tape; optical media such as CD-ROMs, DVDs and holographic indicator devices; magneto-optical media; and hardware devices that are specially configured to store and execute, such as application-specific integrated circuits (“ASICs”), programmable logic devices (“PLDs”) and ROM and RAM devices. Examples of computer readable instructions include machine code, such as produced by a compiler, and files containing higher-level code that are executed by a computer using an interpreter. For example, an embodiment of the invention may be implemented using Java, C++, or other object-oriented programming language and development tools. Another embodiment of the invention may be implemented in hard-wired circuitry in place of, or in combination with machine readable software instructions.
A data source is an information resource. Data sources include sources of data that enable data storage and retrieval. Data sources may include databases, such as, relational, transactional, hierarchical, multi-dimensional (e.g., OLAP), object oriented databases, and the like. Further data sources include tabular data (e.g., spreadsheets, delimited text files), data tagged with a markup language (e.g., XML data), transactional data, unstructured data (e.g., text files, screen scrapings), hierarchical data (e.g., data in a file system, XML data), files, a plurality of reports, and any other data source accessible through an established protocol, such as, Open DataBase Connectivity (ODBC), produced by an underlying software system, e.g., an ERP system, and the like. Data sources may also include a data source where the data is not tangibly stored or otherwise ephemeral such as data streams, broadcast data, and the like. These data sources can include associated data foundations, semantic layers, management systems, security systems and so on.
In the above description, numerous specific details are set forth to provide a thorough understanding of embodiments of the invention. One skilled in the relevant art will recognize, however that the invention can be practiced without one or more of the specific details or with other methods, components, techniques, etc. In other instances, well-known operations or structures are not shown or described in details to avoid obscuring aspects of the invention.
Although the processes illustrated and described herein include series of steps, it will be appreciated that the different embodiments of the present invention are not limited by the illustrated ordering of steps, as some steps may occur in different orders, some concurrently with other steps apart from that shown and described herein. In addition, not all illustrated steps may be required to implement a methodology in accordance with the present invention. Moreover, it will be appreciated that the processes may be implemented in association with the apparatus and systems illustrated and described herein as well as in association with other systems not illustrated.
The above descriptions and illustrations of embodiments of the invention, including what is described in the Abstract, is not intended to be exhaustive or to limit the invention to the precise forms disclosed. While specific embodiments of, and examples for, the invention are described herein for illustrative purposes, various equivalent modifications are possible within the scope of the invention, as those skilled in the relevant art will recognize. These modifications can be made to the invention in light of the above detailed description. Rather, the scope of the invention is to be determined by the following claims, which are to be interpreted in accordance with established doctrines of claim construction.