Debugging of business flows deployed in production servers

• US 8,122,292 B2
• Filed: 12/29/2009
• Issued: 02/21/2012
• Est. Priority Date: 08/19/2009
• Status: Active Grant

• Current Assignee: Oracle International Corporation (Oracle Corporation)
• Original Assignee: Oracle International Corporation (Oracle Corporation)
• Inventors: Nanjundaswamy, Vijay Kyathanahalli
• Primary Examiner(s): Baderman, Scott
• Assistant Examiner(s): PATEL, KAMINI B
• Application Number:
  US12/648,310
• Publication Number:
  US 20110047415A1
• Time in Patent Office: 784 Days
• Field of Search: 714/34
• US Class Current: 714/34
• CPC Class Codes: G06F 11/3636 by tracing the execution of the program

Abstract

Facilitating debugging of business flows deployed on a production server. An aspect of the present invention processes some service requests (received from a client system) in a normal mode and some other service requests in a debug mode concurrently, all according to a business flow. According to another aspect, the debug mode supports a single step debug operation, in which each step corresponds to a single activity of the business flow. Accordingly, an administrator of the production server is enabled to better determine, the problems in the execution of business flows deployed on a production server at runtime.

Claims

1. A method of processing service requests according to a business flow deployed on a production server, said method being performed in said production server, said method comprising:

receiving a first service request and a second service request to be processed according to said business flow;

receive data representing a set of break points associated with said second service request, each break point corresponding to one of a plurality of activities defining said business flow;

processing concurrently said first service request in a normal mode and said second service request in a debug mode according to said business flow in said production server,

wherein a set of activities are performed according to an execution flow while processing said second service request in said debug mode,

wherein a control block in said production server monitors said execution flow and pauses said execution flow to transfer control to said control block at each of the activities corresponding to said set of break points, wherein execution is resumed after each pause only upon receiving a user input,

wherein said execution flow of processing of said second service request is not paused and control is not transferred to said control block at the remaining ones of said set of activities that do not correspond to any of said set of breakpoints.

2. The method of claim 1, wherein said debug mode supports a single step debug operation, wherein each step corresponds to a single activity of said business flow.

3. The method of claim 2, wherein said first service request is processed using a first instance of said business flow in said normal mode and said second service request is processed using a second instance of said business flow in said debug mode.

4. The method of claim 3, further comprising:

specifying, by said user, a breakpoint at a first activity in said business flow;

creating said second instance upon receiving said second service request;

maintaining a second data structure indicating a second set of breakpoints for said second instance, wherein said breakpoint is included in said second set of breakpoints;

examining, before performing an activity, said second data structure for presence of a corresponding breakpoint identifying said activity; and

entering said debug mode for said second service request at said activity if the corresponding breakpoint identifying said activity is present in said second data structure,

whereby said second instance enters said debug mode at said first activity.

5. The method of claim 4, wherein the data forming said first service request and said second service request are received from an external client system.

6. The method of claim 2, wherein said business flow comprises a plurality of activities, wherein said processing in said single step debug operation comprises:

pausing before execution of each activity in an execution path; and

waiting for a user input to continue execution of the paused activity in said execution path.

7. The method of claim 6, wherein each of said activities is either a basic activity or a compound activity, wherein said compound activity comprises multiple basic activities, said method further comprising:

receiving a second user input indicating whether a step is to equal entire compound activity or each basic activity in the compound activity; and

if said second user input indicates that the step equals each basic activity, performing said pausing before execution of each basic activity in a compound activity when processing said second service request according to said business flow,

if said second user input indicates that the step equals entire compound activity, performing all the basic activities contained in the compound activity, and then only performing said pausing.

8. The method of claim 2, wherein said business flow is specified according to web service business process execution language (BPEL).

9. The method of claim 3, further comprising:

generating a plurality of activity blocks containing the program logic to perform a plurality of activities forming said business flow; and

executing said plurality of activity blocks concurrently as said first instance in said normal mode and as said second instance in said debug mode,

wherein said plurality of activity blocks contain no additional instructions for facilitating execution in said debug mode.

10. A non-transitory machine readable storage medium storing one or more sequences of instructions for causing a production server to facilitate processing of service requests according to a business flow deployed on said production server, said business flow comprising a plurality of activities, said one of more sequences of instructions comprising:

a first set of instructions representing a plurality of activity blocks, each activity block contains program logic to perform one of said plurality of activities in said business flow; and

a second set of instructions representing an activity execution block to execute said plurality of activity blocks to process a service request,

each of said plurality of activity blocks to generate a token indicating a next activity which is to be performed, wherein each of said plurality of activity blocks is designed to execute the corresponding program logic to perform corresponding activity only upon availability of a corresponding token from said activity execution block,

said activity execution block to withhold availability of said token for said next activity until reception of a continue indication from a user if a breakpoint is specified for said next activity, and to make available said token for said next activity otherwise.

11. The non-transitory machine readable storage medium of claim 10, wherein said production server further comprises a breakpoint table to store a set of breakpoints, each breakpoint specifying the identifier of a corresponding one of a set of activities at which the execution of said business flow is required to be paused, said set of activities being contained in said plurality of activities,

wherein said activity execution block withholds availability of said token for said next activity if the identifier of said next activity matches the identifier of one of said set of activities stored in said breakpoint table, and to make available said token for said next activity if there is no match.

12. The non-transitory machine readable storage medium of claim 11, wherein a corresponding breakpoint table is maintained for each instance of said business flow processing a corresponding service request,

wherein the breakpoint table corresponding to a first instance is empty, whereby said first instance processes a first service request without entering a debug mode,

wherein the breakpoint table corresponding to a second instance stores the identifier of at least one activity, whereby said second instance enters said debug mode while processing a second service request.

13. The non-transitory machine readable storage medium of claim 12, wherein said first service request is processed concurrent with said second service request when said second instance is in said debug mode.

14. The non-transitory machine readable storage medium of claim 11, wherein said one or more sequences of instructions further comprising a third set of instructions representing a debug control block, said debug control block to receive identifier of each activity at which the execution of said business flow is required to be paused, and to store said identifier as one of the identifiers in said breakpoint table.

15. The non-transitory machine readable storage medium of claim 14, wherein said debug control block is further designed to receive said continue indication from said user and to remove the identifier of said next activity in said breakpoint table to cause said activity execution block to make available said token for said next activity, thereby causing continuation of execution of said business flow from said next activity.

16. The non-transitory machine readable storage medium of claim 15, said debug control block is further designed to check whether said continue indication is a single-step indication, if said continue indication is said single-step indication, said debug control block to add the identifier of said next activity to a single step table,

on completion of execution of said next activity by a next activity block, said activity execution block to determine whether the identifier for said next activity is in said single step table and a second token for a subsequent activity is generated by said next activity block, wherein subsequent activity is to be executed following said next activity,

if said identifier for said next activity is determined to be in said single step table and said second token for said subsequent activity is generated by said next activity block, said activity execution block further designed to insert the identifier of said subsequent activity in said breakpoint table such that said activity execution block withholds availability of said second token for said subsequent activity until reception of a corresponding continue indication,

whereby said business flow is executed in a single step debug operation.

17. The non-transitory machine readable storage medium of claim 10, wherein said activity execution block is a part of a run-time environment shared for execution of multiple business flows deployed in said production server,

wherein processing of said service request enters a debug mode upon encountering said breakpoint in an execution path,

wherein a sequence of procedures executed within each of said activity blocks is the same, whether processing of said service request enters said debug mode or not.

18. A production server facilitating debugging of a business flow executing in said production server, said business flow defined using a plurality of activities, said production server comprising:

a processor;

a random access memory (RAM); and

a machine readable medium storing a plurality of instructions, which when retrieved into said RAM and executed by said processor causes said production server to process a second service request in a debug mode according to said business flow in said production server, said plurality of instructions comprising;

a first set of instructions representing a logic for performing each of said plurality of activities;

a second set of instructions to receive data representing said business flow and to generate a third set of instructions designed to invoke said first set of instructions to perform each of a set of activities according to an execution flow while processing said second service request in said debug mode, said set of activities being contained in said plurality of activities and representing said business flow;

a fourth set of instructions representing a control block, said control block to receive data representing a set of break points, each break point corresponding to one of said set of activities in said execution flow,

wherein said control block monitors said execution flow and pauses said execution flow to transfer control to said control block at each of the activities corresponding to said set of break points,

wherein said execution flow of processing of said second service request is not paused and control is not transferred to said control block at the remaining ones of said set of activities that do not correspond to any of said set of breakpoints.

19. The production server of claim 18, wherein said second service request is processed in a second instance formed by execution of said third set of instructions, and a first service request is processed in a first instance formed by execution of said third set of instructions,

wherein said first instance executes in a normal mode concurrently with said second instance executing in said debug mode.

20. The production server of claim 19, wherein said third set of instructions comprises a set of activity blocks corresponding to said set of activities,

wherein each of said set of activity blocks, upon execution, generates a token indicating a next activity which is to be performed, wherein each of said set of activity blocks performs corresponding activity only upon availability of a corresponding token,

wherein said control block comprises a debug control block and an activity execution block,

wherein said debug control block receives said set of breakpoints and stores the received breakpoints in a breakpoint table,

wherein said activity execution withholds availability of the token for a next activity until reception of a continue indication from a user if a breakpoint is stored for said next activity in said breakpoint table, and to make available the token for the next activity otherwise.

21. The production server of claim 20, wherein said debug mode supports a single step debug operation, wherein each step corresponds to a single activity of said business flow, wherein said processing of said second service request in said single step debug operation comprises:

pausing before execution of each activity in an execution path; and

waiting for a user input to continue execution of the paused activity in said execution path.

22. The production server of claim 21, wherein said pausing is designed to pause before execution of an activity if the corresponding identifier is present in said breakpoint table,

wherein each activity upon execution indicates a next activity to be executed in said execution path, said processing of said second service request in said single step debug operation further comprising:

inserting into said breakpoint table, the identifier of said next activity after indication of said next activity,

whereby execution is paused before said next activity, thereby executing said business flow in said single step debug operation.

23. A non-transitory machine readable storage medium storing instructions, which when executed by a production server causes the production server to process service requests according to a business flow deployed on a production server, wherein execution of said instructions by one or more processors contained in said production server causes said production server to perform the actions of:

receiving a first service request and a second service request to be processed according to said business flow;

receive data representing a set of break points associated with said second service request, each break point corresponding to one of a plurality of activities defining said business flow;

processing concurrently said first service request in a normal mode and said second service request in a debug mode according to said business flow in said production server,

wherein a set of activities are performed according to an execution flow while processing said second service request in said debug mode,

wherein a control block in said production server monitors said execution flow and pauses said execution flow to transfer control to said control block at each of the activities corresponding to said set of break points, wherein execution is resumed after each pause only upon receiving a user input,

wherein said execution flow of processing of said second service request is not paused and control is not transferred to said control block at the remaining ones of said set of activities that do not correspond to any of said set of breakpoints.

24. The non-transitory storage medium of claim 23, wherein said debug mode supports a single step debug operation, wherein each step corresponds to a single activity of said business flow.

25. The non-transitory storage medium of claim 24, wherein said first service request is processed using a first instance of said business flow in said normal mode and said second service request is processed using a second instance of said business flow in said debug mode.

26. The non-transitory storage medium of claim 25, further comprising:

specifying, by said user, a breakpoint at a first activity in said business flow;

creating said second instance upon receiving said second service request;

maintaining a second data structure indicating a second set of breakpoints for said second instance, wherein said breakpoint is included in said second set of breakpoints;

examining, before performing an activity, said second data structure for presence of a corresponding breakpoint identifying said activity; and

entering said debug mode for said second service request at said activity if the corresponding breakpoint identifying said activity is present in said second data structure,

whereby said second instance enters said debug mode at said first activity.

27. The non-transitory storage medium of claim 26, wherein the data forming said first service request and said second service request are received from an external client system.

28. The non-transitory storage medium of claim 24, wherein said business flow comprises a plurality of activities, wherein said processing in said single step debug operation comprises:

pausing before execution of each activity in an execution path; and

waiting for a user input to continue execution of the paused activity in said execution path.

29. The non-transitory storage medium of claim 28, wherein each of said activities is either a basic activity or a compound activity, wherein said compound activity comprises multiple basic activities, said actions further comprising:

receiving a second user input indicating whether a step is to equal entire compound activity or each basic activity in the compound activity; and

if said second user input indicates that the step equals each basic activity, performing said pausing before execution of each basic activity in a compound activity when processing said second service request according to said business flow,

if said second user input indicates that the step equals entire compound activity, performing all the basic activities contained in the compound activity, and then only performing said pausing.

30. The non-transitory storage medium of claim 24, wherein said business flow is specified according to web service business process execution language (BPEL).

31. The non-transitory storage medium of claim 25, said actions further comprising:

generating a plurality of activity blocks containing the program logic to perform a plurality of activities forming said business flow; and

executing said plurality of activity blocks concurrently as said first instance in said normal mode and as said second instance in said debug mode,

wherein said plurality of activity blocks contain no additional instructions for facilitating execution in said debug mode.