Business process model debugger

Methods, systems, and computer program products for performing the method are provided. The method includes collecting specified events generated during a run-time operation of a designed computing process flow having a model that defines, at a service-oriented architecture level, which of several predefined computing services are used in the computing process flow and relationships among the predefined computing services that are used in the process flow. The method also includes generating, on a display device, a visual display that shows visual representations of all or a portion of the service-oriented architecture-level model for the computing process flow, and of the collected specified events and where, relative to the model, the collected specified events were generated.

TECHNICAL FIELD

This invention relates to, for example, debugging business process models.

BACKGROUND

As businesses and other large organizations attempt to increase efficiency and reduce costs by streamlining their processes, some have modeled their business processes using software models. Certain of these software models use Service-oriented architecture (SOA) to describe business processes. Developers can use SOA architecture to graphically display a modeled business at a conceptual level above a language-specific implementation that includes particular class objects and methods. This higher conceptual level describes business tasks, or “services,” that are repeated by the business, such as loading or unloading stock, updating inventory, etc.

During a debugging or reengineering phase for the software, the software can be executed in real-time, and the events that result from the execution are captured. In some systems developers make modifications to the executed software based on the captured events. In some systems, however, the developers abandon the previously generated SOA model used to design the software in favor of focusing on run-time events directly. One reason for this may be that there is no convenient integration between the run-time events generated by the business processes and the previously designed SOA software model that describes these processes.

SUMMARY

This document discloses methods, systems, and computer program products for capturing events related to the run-time execution of business service processes, and displaying those events in a graphical and textual format so that a user may visualize the event with the associated service.

In one aspect, this document discloses a computer-implemented method of providing a visual display of a run-time operation of a computing process flow. The method includes collecting specified events generated during a run-time operation of a designed computing process flow, which has a model that defines, at a service-oriented architecture level, which of several pre-defined computing services are used in the computing process flow, and relationships among the predefined computing services that are used in the process flow. The method further includes generating, on a display device, a visual display that shows visual representations of all or a portion of the service-oriented architecture-level model for the computing process flow, and of the collected specified events, and where, relative to the model, the collected events were generated.

In various implementations of the computer-implemented method, one or more of the following features may be included. The generated visual display may be understandable without user knowledge of a software programming language. The user may specify run-time events to collect, and the run-time events may be executed across multiple application system instances, and on multiple server systems. Collected run-time events may be analyzed to determine if they were generated by a particular user. The user may modify the computing process flow or relationships among the predefined services based on the generated visual display.

In addition, the method may use metadata associated with the computing process flow to link the collected events with a corresponding computing process flow by matching a run-time method identifier with design-time metadata. The collected events may be translated into a universal programming language, such as extensible mark up (XML) language. The method may allow generating the visual display so that events are displayed in real-time upon the corresponding computing process flow. Collected specified events and the computing process flow may be displayed on a user interface that includes graphical indicators that highlight the computing process flow related to the collected events. Further, the method may display a process sequence of multiple computing process flow components with a collected specified event, allowing the user to select a level of process flow granularity at which the collected specified events and the computing process flow are displayed.

The visual display may show the interpolation of collected run-time events, the software models, and the interactions based on a filter criteria, based on associations occurring during a time period, associations between selected business objects, associations related to a selected business process, and associations occurring during a selected connection session.

In another aspect, this document further discloses a system for monitoring run-time events in association with process models. The system includes an event monitor to collect run-time events generated by system components represented using software models, a server for associating the monitored run-time events with the software models and interactions between the software models at a service-oriented architecture level, and an interface for transmitting an output for display comprising the associations between the collected run-time events, the software models, and the interactions.

In yet another aspect, a computer program product is provided that is tangibly embodied in an information carrier. The computer program product includes instructions that, when executed, perform operations for providing a visual display of a run-time operation of a computing process flow. The operations include collecting specified events generated during a run-time operation of a designed computing process flow, which has a model that defines, at a service-oriented architecture level, which of several predefined computing services are used in the computing process flow and relationships among the predefined computing services that are used in the process flow. The operations further include generating, on a display device, a visual display that shows visual representations of all or a portion of the service-oriented architecture-level model for the computing process flow, and of the collected specified events and where, relative to the model, the collected specified events were generated.

In various implementations, the computer program product may operate to perform one or more of the method features described in connection with the computer-implemented method.

DETAILED DESCRIPTION

FIG. 1contains elements of a system for debugging business process models100, according to one implementation. The system100may comprise an application user interface (UI)102with which a user101interacts with a computer program, a frontend server105which provides access to an application system110, a monitor observer125which performs tasks relating to event capture and distribution, a monitor server150which receives, merges, and manages events, a monitor frontend180which captures events from the monitor server150, and a monitor UI190which displays event information to the user101.

In general, a user101may use the application UI102to interact with modeling programs, such as those that create business process models. In one implementation, the business process models may be of the Service Oriented Architecture type; an architectural programming style that provides businesses the ability to generate process flows among interacting software agents with an easy-to-use interface. A ‘service’ as used herein may be a unit of work done by a service provider module to achieve desired end results. The frontend server105may act as a link between the application UI102and the modeling program, which may exist as part of an application system110. The application system110maybe comprised of system components115, such as: an enterprise service framework, a process agent framework117, a system components tracer120that keeps a detailed record of the steps undertaken during execution, and a monitor observer125. The process agent framework allows the formation of integration scenarios by coupling process components via process integration logic. The integration logic is implemented within the process agent and is not distributed across application coding.

In one implementation, the monitor observer125may comprise three main elements: an event capture130, an event queue135, and an event distributor140. The monitor observer125may run independently on every application system instance and can perform the function of watching (‘listening’) for new integration events logged by the system component tracer120. In general, the types of integration events from the system component trace120may include: integration between UI and BO (business object), BO and BO, BO and outbound process agent (PA), PA to BO, and PA to PA. Event capture130may capture and analyze new integration events for a registered scenario test (e.g., a test for which a user101has set up). In a particular embodiment, the monitor observer125may conclude that one process agent sent information to another process agent (an ‘event’) by matching a run-time method ID with design-time metadata. The event queue135queues the interaction events and passes them to the event distributor140, and the event distributor posts the events to the monitor server150.

Overall, the monitor server150can function as a listener for receiving the events from the monitor observer125, and may do so on a continual basis or intermittently, at predefined times or time delays. The monitor server150comprises four main elements: an event merger160, an event log generator170, an event log interface165, and a project integration manager (PIM)155. Once the monitor server150receives events from the monitor observer125, the event merger160may merge all integration events from different application systems into a merged event log. The event log generator170may compile the merged events in a pre-defined structure for use by the event log interface165. Event logs may comprise scenario test integration events composed of the following elements: active components, integration events, and active sessions. Active components may include a list of the components that were activated during the scenario test, such as UI, BO, or PA component types. Integration events may include events between active component types (e.g., UI to BO, BO to BO, BP to PA, PA to BO, PA to PA); each integration event may comprise a ‘from’ and ‘to’ active component identification, as well as other information, such as service type (e.g., ‘modify,’ ‘action,’ ‘PA call’) and service name (e.g., ‘create,’ ‘delete,’ ‘action name’).

The event log interface165may receive events from the event log generator170; the interface may comprise a module that parses an event log into a user-friendly structure for requested scenarios. To provide for universal program language interoperability, the PIM manager module155may translate captured events in the monitor server150into a well defined extensible mark-up language (XML) interface. XML promises a standard data format that can be shared easily across applications and especially by different organizations that need to share data. The PIM manager155may send XML-based event logs175to the monitor frontend180which generates the monitor UI190. The PIM manager155may also receive XML-based event logs from the monitor frontend180during a test set-up; thus the PIM manager155serves as an XML translator and functions as an interface between the monitor UI and event logs, independent of programming language.

The system100may be used as a round-trip engineering debugging tool, where a user can design a process flow, monitor events in run-time, and redesign the process flow based on the visually displayed monitored events. For example, a user101can begin the debugging by activating the monitor observer125. The user may execute an application that implements a previously designed process on a UI102; the monitor observer125captures events related to the application, passes them to the monitor server150, which in turn, can pass an XML-based log of captured events to a monitor front-end180. The monitor front end180can then visually interpolate graphical or textual indications of captured events as associated with the service that spawned the event upon a modeling program monitor UI190.

In one implementation, a user101may be engineering a business model using object-oriented programming methods. The user101may open a monitor UI190and specify a landscape to monitor, as well as a time interval to check for events that occur during run-time. The user101would then execute the business model on an application UI102. As the business model executes, the monitor observer125may collect integration events and pass them to the monitor server150. The monitor server150may filter the events captured by the monitor observer125and pass only those that occurred within the specified landscape of the logistic execution unit to the monitor frontend180. The user101may then view captured events on the monitor UI190, wherein the events are graphically represented on or near the programming object that caused the events to occur. Armed with this information, the user101may re-engineer the business model for improved functionality.

FIG. 2is a sequence flow diagram200outlining events of the business process model debugger. The diagram200comprises rows201representing three actions, according to one implementation: ‘registration,’ ‘activation,’ and ‘view;’ and columns202that represent the person or process that perform actions, according to one implementation: ‘user,’ ‘PIM frontend,’ ‘PIM server,’ and ‘application system instance.’

The process200may begin by a user accessing a registration module205in which they may set various parameters, for example, the types of events they wish to capture, the frequency of capture, and the length of capture. This information may be passed to the monitor manager210on the PIM frontend module, which then sends appropriate information to register the scenario215and the landscape220for the events captured on the PIM server; i.e., the scenario and landscape define the limits of the events to be captured with respect to the type of data that the user desires.

Next, at step225, the user may start (or end) the monitoring process as part of the activation step, which activates (or deactivates) the monitor manager230on the PIM frontend180and the monitor server235. The activation step can turn the debugger ‘on’ in preparation for executing a model application, step237, for which events are to be captured.

Once the application is running on the application system, events may be captured. To view the events, step240, the user may utilize a monitor UI on the PIM frontend, step245, which may be constantly updated with events in real time from the event log, or, alternatively, the user may wait until the application on the application system has finished executing to view results. On the monitor server at step260, the monitor process manager may set the parameters for event collection. Next, at step265, the event collector module may begin to receive events generated on the application system from the system component traces (step270). At step275, an event analyzer may scrutinize the contents of captured events to determine whether they should be included as set by the registration parameters; if they are to be included, the events are merged, step280. Finally, at step290, the merged events may be converted to an XML language interface for integration into the visual representation of the application.

FIG. 3is a screen snapshot300of the UI for setting up and collecting integration events through the PIM, according to one implementation. The exemplary screen snapshot300comprises four main sections. Section302includes user-selectable fields and executable buttons for performing the function of setting up the test registration and activation, including creating or deleting a test, attaching the system landscape, starting and finishing a test, showing the event log window, attaching filtering rules, and downloading event logs as XML files, according to one implementation. Section320comprises the system landscape definition, including the application system (e.g. deployable unit (DU)) name, the system name, and the client and backend user name, according to one implementation. A DU may be a piece of software, i.e., it can be operated with the foundation layer on a separate physical system, isolated from other deployment units, and typically contains a set of process components. Examples may be “Purchasing” or “Customer Invoicing.” Section350comprises a screen area for event log results, where a visualization of the test event log may be created in real-time. Upon first opening the screen300, section350may be blank.

A user may initiate a debugging test by first defining a new system landscape which may or may not be based on an existing landscape. This may be accomplished, for example, by highlighting, such as by selecting with a pointing device (e.g. a mouse), the ‘Systems’ field321as shown in section320. In the next step of setting test parameters, the user may add a DU to the system landscape by accessing fields associated with the system landscape321, for example, by right-clicking with a mouse on the ‘Systems’ field321. In this case, the user may be prompted with an option to add a DU, for example, from a list of pre-defined DU's that may appear in a pop-up window. The user may select from the list of DU's and add it to the test parameters. Examples of DU's may include ‘Catalogue Authoring,’ ‘Credit Management,’ ‘Logistics Execution,’ and ‘Purchasing’ services. A new test scenario may then be created, for example, by selecting graphical icons of the type shown in305which have executable functions attached to them and are triggered by events such as a mouse click over the icon. In this example, the user may click icon306, which may present a dialog box containing fields into which the user may enter information such as a ‘test ID’ and description. The screen-snapshot300indicates multiple test ID's in section302, which may allow the user easy access to those test results by highlighting the appropriate test ID. Examples in section302of independent test runs are “TEST1”304and “DON'T_DELET”.

The user may attach the newly-defined landscape to the newly created test, ‘TEST1’304, by clicking on the ‘attach’ button307which creates an association between the two entities and completes the set-up procedure for this example. The selected test304may be initiated, and monitoring of the DU may begin by the user ‘starting’ the marked test304; in this example, the screen300contains a button308for the purpose of starting the test. As soon as the monitoring begins, the screen area350may start to fill with events captured by the PIM once the related application is executed. Similarly, a template may appear comprising sections which may be filled with events upon application execution. In the example screen snapshot300, the area350is shown after many integration events have been captured. The uppermost text355in area350may contain header information relating to the process being run and identifying attributes such as a ‘scenario_id.’ Listed below the header information355are three categories of elements: active component elements360, integration event elements367, and active session elements375. These categories may initially be empty and subsequently fill when appropriate events are captured by the monitor observer125.

On a separate UI than that used for setting up the parameters of the PIM, a user may execute the program that is being monitored for events. For example, the user may start a scenario test on a Source Code Control (SCC) system, choose SCC BO ‘Site Logistics Requisition,’ and subsequently, create a new requisition header. Immediately, this interaction may be captured by the PIM and displayed in the event log area350of the screen300. The captured BO element may be added to the captured active component element list360as a new entry361, and a ‘Modify’ event369may be added to the list of integration event elements367corresponding to the user's interaction with the application system.

The user may further save their interaction (on the application system UI), the associated events of which may be captured and displayed on the PIM UI in the event log window350. For example, an outbound PA event362may be added to the active component element list; the ‘invoke’ event of the BO that called to a PA371may be added to the integration event element list367; after releasing the XI queue, the inbound PA event363may be added to the active component element list360; finally, the ‘modify’ event of LEX BO SLR372that is called by the inbound PA event363may be added to the integration event element list367.

The user may further continue their application system test by entering an LEX system and selecting a BO such as ‘site logistics confirmation,’ and entering a new confirmation header. This information may be immediately captured and displayed in the event log window350: the SL ‘confirmation’ BO364is added to the active component element list360, and the ‘modify’ event373corresponding to the creation of a new SL confirmation is added to the integration event elements list367.

At this point, the user may wish to stop capturing events related to the application system which they are testing. This may result, for example, from finished execution, or errors which prohibit further commands from being executed. In any case, the user may use a ‘stop’ button309to halt recording of events. Subsequently, the user may wish to download the contents of the event log window350onto a recording media for further analysis or to assimilate the results on to their programming schema, which they may do by selecting an appropriate action button, for example, button310.

FIG. 4Ais a screen snapshot400of a business process integration model based on ESA (an exemplary SOA software UI). ESA software may allow a programmer to link services between process components across DU's together in a window401(such as ‘supply chain control’ modeling object402) that support the requirements of the programmer, as is commonly known in object-oriented programming. Services inter- and intra-operate according to predefined rules or definitions that, when put together may support complex enterprise systems and architectures. Modeling objects may exist within one another, such as the ‘logistics execution control’ object404; the number of modeling objects contained within a modeling entity describes the overall granularity of the entity. For example, the supply chain control entity402may comprise three objects, ‘supply and demand matching405,’ ‘customer requirement processing403,’ and ‘logistics execution control404,’ whereas the ‘financial accounting’ entity406may only contain one object, ‘accounting’407. In this example ‘supply chain control’402may be considered to be of higher granularity due to its greater number of objects within a single entity.

The screen400comprises a smaller navigation window430, with which one may select an individual object or entity to work on, a shortcut list of business objects440in a directory-like fashion, and a ‘monitor’ window450that may contain event log entries from a test execution like that described inFIG. 3. The console window451may allow a user to see detailed information about a particular event selected in the monitor window450.

FIG. 4Bis a screen snapshot453that comprises many of the same functional characteristics as screen snapshot400, such as a window452to view services, a navigation pane460to view the current granularity and location of the contents in the window452, and a monitor window454. In the example screen snapshot453, the user has selected a particular event from the monitor window454, ‘BOBO—Modify’455, a BO to BO interaction. Upon doing so, the window453contents have changed from that inFIG. 4Ato show the services that were involved when the event455was captured. ‘Supply chain control’ service402now shows detailed services structure at a higher granularity than inFIG. 4A, and includes sub-units ‘site-logistic requisition’456and ‘request site logistics processing from site log req to site logistics processing’457. Interoperability is indicated between the ‘supply chain control’402and ‘logistics execution’410services by a connecting line459. The line459may indicate the flow of information from one service to another, at any level of granularity and may include objects such as BO's, for example. The services shown for this event indicate the exact processes that were involved when the event occurred and was captured, thus allowing an operator to visually identify the exact chain of events that led up to, and followed the event. In this example, information may have begun from ‘site logistics requisition’456and ultimately passed to ‘account notification’469and ‘business partner’475BO's.

Objects related to the selected event may appear visually distinct (e.g., highlighted) in the model, such as objects457,461,465, and467, and may change as the programmer scrolls through the captured events displayed in the monitor window454. The programmer may navigate the directory of ESA process modeling objects available470, and add them to the active model, such as by ‘dragging and dropping’ selected items from the list470. In this manner, the programmer may visualize other inter- or intra-operability of services as they relate to the selected event455. In addition, the programmer may select a comfortable level of granularity, or abstraction level, when viewing the process model and the associated event. For example, programmer may highlight two process components on an integration scenario model at a level similar to that shown inFIG. 4A; in this case, the highlighted objects may include ‘logistics execution control’404and ‘site logistics processing’408. The details or sub-objects that make up the parent class (supply chain control'402and ‘logistics execution’410respectively) may not be necessary to view for some events.

FIG. 5is a block diagram of a computing device500that may be used to implement the systems, methods and tools described in this document, as either a client or as a server(s), or a combination of the two. The computing device500is intended to represent various forms of digital devices, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, or other appropriate computers or devices.

The computing device500includes a processor502, memory504, a storage device506, a high-speed interface connecting to memory504and high-speed expansion ports (not shown), and a low speed interface (not shown) connecting to a low speed bus (not shown) and storage device506. Each of the components502,504, and506are interconnected using various busses (e.g., bus550), and may be mounted on a common motherboard or in other manners as appropriate. The processor502can process instructions for execution within the computing device500, including instructions stored in the memory504or on the storage device506to display graphical information for a GUI on an external input/output device, such as display516coupled to the high speed interface. In other implementations, multiple processors and/or multiple buses may be used, as appropriate, along with multiple memories and types of memory. Also, multiple computing devices500may be connected, with each device providing portions of the necessary operations (e.g., as a server bank, a group of blade servers, or a multi-processor system).

The high speed controller manages bandwidth-intensive operations for the computing device500, while the low speed controller manages lower bandwidth-intensive operations. Such allocation of functions is exemplary only. In one implementation, the high-speed controller is coupled to memory504, display516(e.g., through a graphics processor or accelerator), and to the high-speed expansion ports, which may accept various expansion cards (not shown). In the implementation, the low-speed controller is coupled to storage device506and the low-speed expansion port. The low-speed expansion port, which may include various communication ports (e.g., USB, Bluetooth, Ethernet, wireless Ethernet) may be coupled to one or more input/output devices, such as a keyboard, a pointing device, a scanner, or a networking device such as a switch or router, e.g., through a network adapter.

The computing device500may be implemented in a number of different forms, as shown. For example, the computing device500may be implemented as a standard server520, or multiple times in a group of such servers. The computing device500may also be implemented as part of a rack server system524. In addition, the computing device500may be implemented in a personal computer such as a laptop computer522. Each of such devices may contain one or more of computing device500and an entire system may be made up of multiple computing devices500communicating with each other.

FIG. 6is a flowchart600that generalizes the processes described herein and summarizes the utility of the process model debugger. Beginning at step610, the system100may receive a user-selected process flow to be monitored. The process flow may be, in a preferred embodiment, a SOA-type business process flow model that may generate real-life events during the execution of the model.

Next, at step620, the system100may receive user-specified events that may be defined within the process flow, and that may be collected during real-time execution of the process flow. At step625, a user may execute the process flow to be monitored.

The system100may begin collecting events during run-time at step630. The captured events may be stored in memory or within a log of captured events. Next, at step640, the system100may receive a request to display a process model monitor view. At step650, the system100may generate a visual display that may contain all or parts of the SOA-level process flow component(s), and the captured events interpolated upon the model.

At step660, the user of the process model debugger may refine the model for computing process flow, based on the results of the captured events. In another embodiment, the user may revise the underlying processes in general, to generate the most effective model for their particular business needs.

A number of embodiments of the invention have been described. Nevertheless, it will be understood that various modifications may be made without departing from the spirit and scope of the invention. For example, the monitor server has largely been described as functioning in a “push” mode, but may be implemented in a pull mode as well. In this case, the server may be actively responsible for fetching and analyzing the new events frequently from every monitored DU. Accordingly, other embodiments are within the scope of the following claims.