Abstract: A system is provided for handling an error by identifying an activity that generated the error. The system determines whether the activity has an associated user-defined error handling process. If the activity has an associated user-defined error handling process, then the system executes the associated user-defined error handling process. If the activity does not have an associated user-defined error handling process, then the system executes a default error handling process. A particular activity my have multiple associated user-defined error handling processes. The system selects among the multiple user-defined error handling processes using one or more error handling parameters. The system includes an activity execution module configured to execute process definitions and identify errors that occur when executing process definitions.

Abstract: A mechanism is provided for reporting errors in a computer system. The mechanism detecting an error in the computer system. The mechanism identifies a first error message associated with the error and a second error message associated with the error. The first error message and the second error message are then reported by the mechanism. The error messages provide different details regarding the error such that the first error message provides a general description of the error and the second error message provides a detailed description of the error. The mechanism is capable of displaying the first error message and the second error message on the computer system. The first error message can be associated with a first software module and the second error message can be associated with a second software module. An error message stack is used to store the first error message and the second error message.

Abstract: A method for executing a workflow that requires input from a role is disclosed. A workflow is executed in a first process until an operation requiring input from a role is detected. Continuation information is stored indicating the workflow operation requiring input from the role. The request for input from the role is then communicated to a computer-user identified with the role. Later, after receiving input from the computer user, execution of the workflow is resumed in a second process based on the continuation information, starting at the operation that required input from the role. The operation that required input from the role is executed based on the response received from the computer-user identified with the role.

Abstract: A method for protecting seed data according to an access hierarchy is disclosed. A seed data entity is resolved into a plurality of seed data units each having an associated protection level and customization level. When a request to modify a seed data unit is received, an access level is determined for the request. The seed data is modified in accordance with the request if the access level determined for the request is superior or equal to the protection level of the seed data unit and inferior or equal to the customization level of the seed data unit. If the seed data is modified or replaced, the access level determined for the request is assigned to the customization level of the seed data unit.

Abstract: A system is provided for resetting a process from a first activity to a second activity, in which the second activity was previously performed. The system identifies activities that were previously performed after the second activity. Each identified activity (including the second activity) is then executed in a cancel mode of operation. The execution of the activities is performed sequentially from the first activity to the second activity. The system then executes the second activity in a run mode of operation. The cancel mode of operation cancels the changes that were implemented by a particular activity during a previous execution of the activity. The activities can maintain information regarding the last change implemented by the activity, which is used by the activity in the cancel mode of operation to cancel the last change implemented by the activity. The system may include a loop reset counter associated with the first activity and the second activity.

Abstract: A method and system for regression testing of application logic within a software system. Software architecture can be separated into a presentation layer (e.g., user interface), an application layer (e.g., business logic), and a data/storage layer. Within the novel testing system, communication interfaces between the presentation layer and the application layer are identified such that user initiated commands ("events") passed from the presentation layer to the application layer are recorded into a test playback event file. During test playback event recordation, differences in the state of the application layer of a reference program are collected into a reference state log file. To test a program, the recorded events of the test playback event file are played back and applied directly to its application layer. After each event, the differences in the state of the program are collected into a test state log file.