WO2004097696A1

WO2004097696A1 - Automated definition and implementation of business processes

Info

Publication number: WO2004097696A1
Application number: PCT/GB2004/001809
Authority: WO
Inventors: Darren Harding; Ian Carr; Dave Pick; Rhydian Morris
Original assignee: Focus Business Solutions Limited
Priority date: 2003-05-02
Filing date: 2004-04-29
Publication date: 2004-11-11
Also published as: GB0310089D0; EP1623373A1; GB2401212A

Abstract

A method and apparatus for defining and implementing a process such that it can be executed across multiple computer system environments and with different resources. The process is defined by generating process definition data specifying a process intent as a function of an ordered series of activities, each activity being associated with at least one action invoked by a defined event occurring during execution of that activity, each activity being executable in at least one computer system environment and including at least one data input and/or data output step. The execution is defined by generating configuration definition data identifying at least one specification of computer system environment and resource required for execution of each of the respective activities in the process definition data. During run time, the process intent specified by the process definition data is executed using a number of resources in different computer system environments by reference to the configuration definition data.

Description

AUTOMATED DEFINITION AND IMPLEMENTATION OF BUSINESS PROCESSES

The present invention relates to methods and apparatus for the electronic definition and execution of processes, such as the display, collection and manipulation of data used in business and commerce.

Many organisations throughout industry and commerce, such as banking, insurance, finance, healthcare etc, have a common requirement to define complex business processes and procedures that form the core of their business activities, and to implement those processes and procedures on a variety of physical information processing systems.

These information processing systems may be very diverse. They could include any one or more of: word processors for generating forms, data sheets and correspondence; spreadsheet applications for collating and presenting data; databases and database management systems for entering, maintaining and outputting business records; web servers for receiving information from customers or other organisations, and for providing information to such customers and other organisations, tele-sales networks for input and output via a human customer interface with customers and many others.

In a general sense, it will be recognised that the business processes are distributed across a number of machines and / or a number of software applications, usually running on one or more independent computing platforms. The business processes are generally also distributed across different people and departments within an organisation or within a number of separate organisations and, of course, may be distributed in time. Existing implementations of business processes have used several possible approaches to automation or computerisation of the processes, procedures and corporate rules embodied therein.

In one known implementation, as depicted in figure 26, an entire business process is analysed by a specialist analyst (eg. application designer 10) to define a model 27 of that process. This model is used by the specialist programmers (eg. application developer 28) to produce an integrated system that comprises program code 260 that executes on a specific computing platform 261. With reference to figure 27, the specialist programmers 28 may rewrite the program code 262 in order that it can execute on a second specific computing platform 263. In this way, the business process can be defined separately on a set of computing platforms.

A significant disadvantage of this approach is its inflexibility. The system cannot be implemented by the business professionals, but requires specialist analysis and programming skills from the IT sector in order to implement the process. Another disadvantage is that making changes to the process as the business requirements evolve is a difficult task that again must be implemented by the specialist analysts and programmers rather than by the business professionals. Yet another disadvantage is that the system is often platform specific and cannot be implemented cross-platform or simultaneously on multiple different platforms without further IT specialist programming skills. Changes to the process must be reflected in each version of the implementation on each platform.

In another known implementation, depicted in figure 28, various different generic or 'off-the-shelf software applications 272, 273 may be used, which each have user interfaces 270, 271 that allow a degree of modification by the business user 275 to implement various stages or 'transactions' in their overall business process and to customise the application to their specific business process needs without advanced programming skills.

A disadvantage with the generic application approach of figure 28 is that such programs are generally platform specific, eg. adapted only for execution on a specific platform 276, 277. For example, part of a business process may be defined and implemented on a Microsoft desktop application such as Microsoft Access. If it becomes necessary to implement that part of the business process in another technology or environment such as an on-line Java-based environment, then that part of the business process has to be redefined using the new environment.

Typically, each generic application, such as spreadsheet, word processor, database management system etc implements only a small part of the organisation's overall business process, eg. a single transaction or several transactions within the overall business process. The different applications must communicate with one another or link, during execution of the business process - for example, by using shared databases and / or passing files therebetween.

To achieve this communication between applications, customised interfaces must be programmed in a manner specific to the applications and to the business process. This again requires specialist programming and IT skills. These interfaces usually need to accommodate different platforms on which the various generic applications run, different data formats and input / output requirements and again introduce a level of inflexibility and difficulty in effecting changes as the business process evolves.

These prior approaches to the automation of business processes and corporate rules and procedures embodied therein have resulted in implementations that tie up the processes in a set of complex computer logic that is neither transparent to the business user, nor readily adaptable to changing business circumstances. They also lead to development times which may be too long in modern business environments.

Implementing change in the automated procedures to effect required changes in business practice is an activity that generally requires involvement of both the business professional and IT specialists, thereby increasing costs and delays and an increased risk that changes do not truly reflect the needs of the business professional.

In all of the prior art approaches, the intent of the business process (eg. that which is defined by the business professional in the context of his or her business) is inextricably linked with the platform and/or environment of execution on the computer system (eg. that which is defined by the computer programming specialist). It is this fact at least which contributes to the inflexibility and restrictive nature of providing a business process implementation in a computing environment.

It is an object of the present invention to provide an improved method and apparatus for implementing business processes and enabling their adaptation to evolving business needs.

According to one aspect, the present invention provides an apparatus for defining a process for execution on a computer system including: means for generating process definition data specifying a process intent as a function of an ordered series of activities, each activity being associated with at least one action invoked by a defined event occurring during execution of that activity, each activity being executable in at least one computer system environment and including at least one data input and/or data output step, and means for generating configuration definition data identifying at least one specification of computer system environment and resource required for execution of each of the respective activities in the process definition data.

According to another aspect, the present invention provides a method for defining a process for execution on a computer system comprising the steps of: generating process definition data specifying a process intent as a function of an ordered series of activities, each activity being associated with at least one action invoked by a defined event occurring during execution of that activity, each activity being executable in at least one computer system environment and including at least one data input and/or data output step, and generating configuration definition data identifying at least one specification of computer system environment and resources required for execution of each of the respective activities in the process definition data.

According to another aspect, the present invention provides an apparatus for executing a process on a computer system using a plurality of different applications programs, comprising: means for retrieving process definition data specifying a process intent as a function of an ordered series of activities, each activity being associated with at least one action invoked by a defined event occurring during execution of that activity, each activity being executable in at least one computer system environment and including at least one data input and/or data output step; means for determining a current activity scheduled to be executed; means for checking configuration definition data identifying at least one specification of computer system environment and resources required for execution of the current activity; and means for invoking execution of each current activity in an available execution environment specified for the current activity, as determined from the configuration definition data.

According to another aspect, the present invention provides a method for executing a business process on a computer system, execution of the business process requiring a plurality of different applications programs, comprising the steps of: retrieving process definition data specifying a process intent as a function of an ordered series of activities, each activity being associated with at least one action invoked by a defined event occurring during execution of that activity, each activity being executable in at least one computer system environment and including at least one data input and/or data output step; determining a current activity scheduled to be executed; checking configuration definition data identifying at least one specification of computer system environment and resources required for execution of the current activity; and executing the current activity in one of the available specified execution environments.

Embodiments of the present invention will now be described by way of example and with reference to the accompanying drawings in which:

Figure 1 shows a schematic overview of an application build and deploy system for definition and execution of a process according to the present invention;

Figure 2 shows elements which make up a process defined using the system of figure 1 ; Figure 3 shows a flow diagram illustrating execution of a process defined using the system of figure 1;

Figure 4 shows elements which make up a merge map used during execution of a process using the system of figure 1 ; Figure 5 shows elements which make up a configuration definition using the system of figure 1 ;

Figure 6 shows a series of activities forming an exemplary business process for the provision of vehicle insurance quotes to the public;

Figures 7 to 15 show screenshots from the application build and deploy system of figure 1, at various stages in the defining of a business process;

Figure 16 shows a flowchart of an exemplary insurance quote business process defined according the system of figure 1 ;

Figures 17 to 25 show screenshots from the application build and deploy system of figure 1, at various stages in the execution of a business process defined thereon;

Figure 26 shows a prior art application development system; and

Figure 27 shows a prior art application design system.

Figure 1 shows an application build and deploy system 100 comprising two distinct layers: a definition layer 1 and an execution layer 2. The system enables a computer-implemented process to be defined 5 in a generic language, such as XML, with separation of the 'intent' 3 of the process and the implementation of the process. The direct interpretation of the process intent is implemented at an execution layer 2. By process intent, we mean the functionality of the process flow without reference to specific implementation on any particular computer environment or platform.

The separation of a process intent definition 19 from an implementation definition 18 enables the computer-implemented process to be effected across multiple environments and technologies, as shown as environment 'A' 6 and environment 'B' 22.

The system 100 has the ability to call both internal systems 21 and external systems 7 (described hereinafter) and to transform data between them, thereby enabling disparate systems 9 to be used together in a co-ordinated manner.

Once the process defined by the process intent definition 19 is deployed, it can generally be maintained without requiring specialist technical resources to effect any changes required. For example, a business process application can be maintained by a business analyst acting as an application designer 10 to accommodate legislation changes or other changes in business practice without requiring intervention of specialist computer programmers and analysts.

The definition layer 1

In a preferred arrangement, the definition layer 1 uses XML dialects 11 which enable the intent 3 of a process to be defined in a declarative manner, resulting in the generation of XML definition documents 5.

These XML dialects 11 include a process XML dialect 101 (figure 2) used to create the process intent definition 19 and a configuration XML dialect 102 (figure 5) used to create the configuration definition 18.

While the preferred embodiments of the invention described herein are illustrated with use of XML-based dialects to create XML-based process definition and configuration definition documents, it will be recognised that the invention could be applied using other forms of dialects and definition files or documents that are, or may become, available. The process XML dialect 101 that is used to create the process intent definition 19 that defines the process flow is shown in figure 2. It uses abstracted objects to define the process intent, including: Activities 12, Views 13, Events 14, Services 15, MergeMaps 39 and Transformations 16, each of which will be further described hereinafter.

The configuration XML dialect 102 that defines the physical implementations of the computer-implemented process across multiple technologies and environments is shown in figure 5.

The use of these two XML dialects 11 enables the application designer 10 to separate their intent 3 for the process from the execution 2 of that process. Furthermore, the process can be re-deployed in different technologies / environments 6, 22 without redefinition or alteration of the process specification.

One or more visual user interfaces 17 abstract the application designer 10 from the need to create raw XML specification documents 18 and 19 from the above dialects 1 1 and from the need to write in program script language. This greatly simplifies application program construction, alteration and maintenance.

Multiple XML configuration definition documents 18 can be created so that a single process can be executed in multiple environments / technologies 6, 22 without having to redefine the process for each instance.

Execution Layer

The execution layer 2 includes an operational runtime software application 23 for each computing environment (technology / platform 6, 22), referred to here as a 'process controller' or just 'runtime' 23. Preferably, the process controller 23 for each computing environment is operationally identical. Each process controller 23 uses the XML definition documents 18, 19 generated in the definition layer 5 to effect the intent 3 of the application process, by direct interpretation and execution.

The XML process definition document 19 determines the process flow of the application process.

The XML configuration definition document 18 details the electronic services that are used, determining the technologies and the environment, eg. Java, Microsoft, online, offline or combinations thereof.

By default, the system 100 preferably contains pre-defined information in the configuration definition 18 for 'core' electronic services - including a data capture and rules engine. The application designer 10 can extend the application to utilise and exchange data with any electronic service 9 that exposes an interface through which data input and output 8 may be exchanged.

In this manner, the process controller 23 can, under instruction of the defined process in the XML process definition document 19, call both internal 21 and external 7 systems and exchange data 8 with them. As such the present system 100 enables disparate computer systems 9 to be used together in a co-ordinated manner.

The process controller 23 itself can also operate in multiple environments / technologies by means of multiple versions of the same process controller software application for each environment / technology as required. In this manner, a defined process 19 can have multiple XML configuration definition documents 18, and can be deployed and executed in multiple technologies and environments 6, 22.

Process XML dialect 101

Figure 2 illustrates the process XML dialect 101 that is used to define the XML process definition document 19 which represents the intent 3 of the process. The process definition is intent-based because it references, by uniform resource identifier (URI), abstract objects such as Activities 12, Views 13, Events 14, Services 15 and Transforms 16, while the actual physical descriptions and locations of those objects are held in the separate XML configuration definition document 18.

With reference to figures 2 and 3, an application process as defined in the process definition document 19 consists of a series of activities 12. Each activity 12 has one or more views 13 that present data to, and/or capture data from, the user.

Each Activity 12 can have an entry action 32, an exit action 33 and transitions 31 to other activities 12, which are invoked by defined events 14 associated with the specific activities, such as when the user clicks a submit button on a form.

In essence, it is the combination of activities, events and transitions that form a defined process flow.

Transitions 31 and events 14 can have actions 34, 35 associated with them, that perform processing, such as such as testing a condition, calling an external service, merging XML data, calling another action or transition, etc. All actions 32, 33, 34, 35 may use a suitable scripting language to define the action. The action may, for example, define the evaluation of a condition. For example, the scripting language may be capable of manipulating XML within XML documents, including such functions as: a) create and destroy XML, eg. elements, attributes, tags, sections b) support use of XML query language such as xPath c) invoke XML-based application services including web services, SOAP services, and pass and receive XML to/from these services d) use XSLT to translate or transform XML e) merge two XML documents according to a separate merge definition.

Furthermore, the scripting language is preferably extensible so that new and user-defined functionality can be incorporated and used as part of the language, eg. user defined functions. Such functionality may require the use of external references, such as the merge functionality which references a merge definition.

Activities 12

Activities 12 may contain one or more activities, in a sequence.

An activity 12 represents a step, stage or state in the process during which the process controller 23 presents an associated view 13 to a user. The process controller performs a series of actions 32, 33, 34, 35 within an activity 12 as follows.

1. Execute any entry actions 32 specified for the activity 12 when transitioning into the activity. 2. Present an associated view 13 specified for the current activity 12 and wait for the user's interaction with that view 13 to trigger one or more events 14 associated with the current activity.

3. Evaluate conditions specified as criteria for effecting any transitions 31 specified for the current activity to see if any such transitions are or should be triggered by the triggered events 14. If the conditions are met, then the associated actions 34 specified for such transitions are executed.

4. Execute the exit actions 33 when transitioning out of the current activity 12.

5. Transition 31 out of the current activity 12 and into a target activity 12 as specified by the process definition document 19.

Actions 32, 33, 34, 35

Actions may contain a sequence of one or more instructions, eg. scripts 30 in the scripting language, to execute. A script 30 is an operation or construct for evaluating, creating and changing data, consisting of the following operands:

Node - used to create and manipulate XML documents and nodes including namespaces;

Assign — used to assign values to Variables;

Service Invocation - used to call operations on external Services; Parameter - used to pass parameters to operations on Services;

Evaluate - used to evaluate XPath expressions and assign to Variables and Parameters;

Merge - used to combine different XML documents and node sets resulting from Variables and XPath expressions. The behaviour of the merge, i.e. whether to insert or update Nodes, is determined by a separate map document, as shown in figure 4;

Conditional - an 'If... Then... Else' construct with conditional XPath expression evaluation used to determine one or more True & False Actions; Block, Catch & Exception - a 'Try... Catch... Exception' handling construct used to handle and recover from errors.

Transitions 31

Transitions 31 may contain a sequence of one or more transitions 31 out of the current activity 12 to another.

A transition 31 is the process of moving from one Activity (12) to another, or more specifically the move from the current activity 12 to the target activity 12. A transition 31 is triggered when a named event 14 is received from a view 13 (ie. by user input) and an optional condition is met. In the preferred arrangement, only one transition 31 out of an activity 12 can be triggered at any one time. However, multiple events 14 can target the same activity 12. Any actions 34 associated with the transition 31 are executed before the transition 31 occurs.

Events 14

Events 14 may contain a sequence of one or more events that can be received by the application process.

An event 14 is a means of enabling received data, captured by a view 13, and storing it within a storage location from where it can be accessed by the next activity 12. Each event 14 has a unique name and can have an associated event decoder 40 to indicate the format and mechanism for decoding the received data into XML from the resulting event. For example, the received data could be from a form submission in HTML format. When the process controller 23 receives an event 14, any event actions 35 associated with it are executed before it is passed on to the current activity 12 and used to potentially trigger a transition 31.

Variables 36

Variables 36 may contain a sequence of one or more variable definitions.

A variable 36 is a uniquely named container for storing XML data so that it can be examined and manipulated by script statements in actions 32, 33, 34, 35. Once defined, variables can be referenced throughout the process in any XPath Expression or script 30 statement.

Environment 37

The environment 37 is a sequence of references to the views 13, services 15, transforms 16, name spaces 38 etc making up the resources used by the application, as defined in the XML configuration specification document 18.

^• Views 13

Views 13 may contain a sequence of one or more references to view 13.

A View 13 is a set of visual components, ie. presentations and data captures, that are displayed on the screen for a user to interact with while the process controller waits in the current activity 12. A view 13 can be one or more presentations or data captures or combination of these. For example, a standard HTML page may contain images and text or a complex data capture component such as an XForm or similar, or an embedded applet of some kind or even the product of an XSLT transformation of XML data. Each view definition has a unique name and a uniform resource identifier (UPvI) that is used to reference an actual view definition in the separate XML configuration definition document.

Services 15

Services 15 may contain a sequence of one or more references to service.

A service 15 is a reference to an external component or application 7 that exists outside the system 100 but supports a well-defined interface with operations that can be called to consume and produce data. For example, these services could include a Rules Engine, a Quotes or Underwriting Engine, a database, a queue, a web service or a DLL. The named service 15 and its physical location are defined in the separate XML configuration definition document 18.

Transforms 16

Transforms 16 may contain a sequence of one or more references to transform.

A transform 16 may comprise a reference to an XSLT transform that can be used by script 30 statements in actions 32, 33, 34, 35 and XPath expressions to transform XML data from one format to another. The named transform 16 and its physical location are defined in the separate XML configuration definition document 18.

Merge Maps 39

Merge Maps 39 may contain a sequence of one or more references to Merge Map documents as shown in figure 4. The Merge Map 39 is a reference to an XML Merge document that can be used by the Merge component to guide it (or Map) through the process of merging two pieces of XML together. This can be actioned using a suitable scripting language. The named Map document and its physical location are defined in the separate XML configuration definition document 18.

Event Decoders 40

Event Decoders 40 may contain a sequence or one or more Event Decoders 40.

An Event Decoder 40 is referenced by events to specify the specialist component that is used to decode data received from an event 14. For example, data from a data capture component may be in a pre-defined format and a decoding component is needed to transform it into a more generic XML document.

Name Spaces 38

Name Spaces 38 may contain a sequence of one or more Name Space definitions.

A Name Space (38) is a definition of a unique name space and prefix for outputting name spaced XML documents.

Configuration Dialect 102 The configuration dialect 102 is used to define the physical implementation of an application process that is defined in the process definition document 19. A single defined application process can have multiple configuration documents enabling multiple implementations in different technologies / environments and/or using different computing resources. For example, different implementations of the process could be on a windows desktop platform, an online browser platform, an offline browser platform, or in the same environments but with a different service offering / availability.

Each configuration definition document 18 will hold a reference to the process definition document 19 to which it applies.

The configuration definition document 18 provides a list of definitions of all the resources required by the process during execution in a specific environment. These resources may include services 15, views 13, event decoders 40, MergeMaps 39, and transforms 16 to be used by the process in a specific environment 37.

Each resource definition, eg. view 13, includes the URI used by the process to identify it, and the physical location of that resource in the form of a file path, URL (for Web Services etc), class name, or component name.

The process controller 23 simply uses the configuration document 18 to lookup the URI and call for use of the relevant resource.

With reference to figure 5, the specific components of the configuration dialect 102 are as follows.

Configuration 48

The configuration definition 48 is the root node that contains the configuration details. The purpose of the configuration definition 48 is to specify how the process defined in the process definition document 19 is implemented in this configuration. The configuration may include the hardware and software environment, computing platform, type of available resource, eg. online, offline, etc. Applications 49

Applications 49 may contain one or more application 50.

The application 50 maps the URI of an external application specified in the process definition document 19 to the calling location of the physical application in the specific operating environment. For example a configuration definition document 18 for an online environment may specify use of an online web application to perform a specific task. In this case, the URI specified in the process definition document 19 to invoke that application is interpreted by the configuration definition document 18 to call the online web application. Similarly, another configuration definition document 18 for an offline environment may specify use of local application to perform the same or equivalent task. In this case, the URI specified in the process definition document 19 is interpreted by the configuration definition document to call a local application, such as standard Win32 application.

Services 51

Services 51 may contain any number of services 52.

A Service 52 is similar to an application 50 in that it maps the URI specified in the process definition document 1 to the location of an external service 7, so that the service can be invoked according to the environment. However a service can be one of the following types:

a) ReqResp SOAP Service 53 - Request a simple object access protocol (SOAP) service and wait for a response from that service; b) OneWaySOAPService 54 - Request a SOAP service, but do not wait for or process a response; c) RulesetService 55 - Request a ruleset to be processed by a rules engine, such as iLog; d) XmlSortService 56 - Request an XML document to be sorted; e) XmlResourceService 57 - retrieve an XML document from a URL (web server), for example load a web page optionally passing data and receiving a response in XML; and f) Handlerobject 58 - Request a Java class object to be called.

Decoders 59

A decoder 59 may contain any number of decoders 60.

A decoder 60 translates the response data from an external call to an application 50, 7, 21 or service 52 into XML in order that it can be processed, handled or stored as required. An example decoder is an HTML- to-XML decoder that translates the response from an http web page into XML.

MergeMaps 61

MergeMaps 61 may contain a sequence of one or more references to

MergeMap documents 62.

The Mergemap 62 is a reference to a Merge XML document that can be used by the Merge operand of a script action 30 to guide it (or Map) through the process of merging two pieces of XML together. The use of Mergemap in the configuration XML dialect is to reference (by URI) the named Map document and its physical location.

Merge maps may be used by a merge keyword in a script action and as such form part of executing an action, ie. merging two XML documents together. Therefore, a Mergemap may be considered part of the process definition.

Resources 63 A resource 63 may contain one or more resources 64.

A resource 64 is a named reference (URI) to the physical location of resource files used by the application. For example, these resources may be a data capture component; an XSLT document used to alter an XML document, a style sheet used to alter the style of a view, etc.

Process Controller 23

The process controller 23 is a runtime software application that uses the XML documents generated in the definition layer 1 to effect the intent 3 of the process defined in the process definition document 19, by direct interpretation and execution. Identically operational process controllers 23 exist for each technology / platform 6, 22 so that a single definition can be executed in multiple environments.

The process controller 23 uses the process definition document 19 to determine the process flow of the application.

The configuration document 18 is used by the process controller 23 to control the electronic services required in the technology / environment in which it is executing. These can include Java, Microsoft, online, offline or combinations thereof.

Use of the application build and deploy system 100 of the present invention will now be described with reference to a specific process example. The example given here describes the creation / definition of a quote procedure for motor insurance, and the execution of that definition in an online environment and alternatively in an offline environment. The execution of the process in two different environments is effected by means of a separate configuration document for each of the offline and online environments, each using a respective process controller 23.

Figure 6 shows a schematic block diagram of the quote procedure 600 to be implemented. A first activity 601 comprises running a data capture application that presents a data capture screen to a user to enable relevant personal details to be captured. An event within that activity 601 (ie. the user entering a post code into one of the data capture fields) may trigger a transition to another activity 602, namely that of verifying or resolving an address using a post code. Completion of this activity, ie. providing an address, or verifying an address already given, may trigger a transition back to the personal details capture activity 601. The post code resolve activity may be carried out by a separate application running in a different environment, eg. a HTML-based application.

After capturing the personal details (step 601), the process transitions to a basic vehicle details data capture activity 603, again using an appropriate data capture application. Completion of this activity triggers a transition to a vehicle check application 604, which may be, for example, a web-based service for checking vehicle details against a vehicle registration number and / or chassis serial number and possibly returning make, model colour etc.

The next activity 605 displays vehicle details as obtained or verified by the web service application 604 and prompts the user to check details and /or enter further details / confirmation. Step 606 effects a checking of these vehicle details to ensure that the specified vehicle is capable of being insured according to business rules and / or policy. This activity may be executed on a suitable rule-checking application / platform. Where the rule checking step 606 determines that the vehicle cannot be accepted for insurance, a rejection activity 607 executes, using for example an HTML environment to return the information to an online user.

Where the rule checking step 606 determines that the vehicle can, in principle, be accepted for insurance, the process continues with a further data capture application 608 to collect driver details. Upon receipt of driver details, a driver details summary / update / correction activity 609 executes, using for example an HTML environment to communicate with an online user.

On completion of the data capture for driver details, application 610 effects a checking of these vehicle details to ensure that the specified driver / vehicle combination is capable of being insured according to business rules and / or policy. This activity 610 may be executed on a suitable rule- checking application / platform.

Where the rule checking step 610 determines that the driver / vehicle combination cannot be accepted for insurance, a rejection activity 611 executes, using for example an HTML environment to return the information to an online user.

Where the rule checking step 610 determines that the vehicle can, in principle, be accepted for insurance, the process continues with a quotation calculation activity 612, which may execute on a suitable rule checking / calculating application. A quotation presentation activity 613 follows, using for example an HTML environment to communicate with an online user. In addition, the process could then specify further routines to be executed. These might include, for example, collection of payment which could require execution of activities on web-based systems to communicate with the customer, payment transaction applications provided by financial service institutions, and sales transaction applications executing within the insurers own computer systems. Further, the process could then define activities executing to execute applications that generate paper correspondence necessary to confirm to the customer the insurance, such as generation of certificates of insurance and covering correspondence.

The first stage in the creation of the application process is a definition stage, using the user interface 17 of definition layer 1.

Figure 7 shows a main design window 110 of the system 100. This is used to define the intent of the application process and create the process definition data 19 using visual representations of the main activities and transitions.

Pane 111 provides the user with a selection of template elements 25 corresponding to activities 12, transitions 31 and end points 24. The user can drag and drop these elements 25 onto the process model display pane 112, and configure them to define the application process using the properties pane 113. The left hand pane 114 automatically shows the contents of the current process, split into main categories, namely: activities, events, variables, environment, views, services, transforms, mergemaps, event decoders and namespaces.

As the application is defined using this user interface, the resulting process definition data file or document in XML is automatically generated and updated by the system. Figure 8 shows a screen shot of the XML process definition pane 115 which displays the automatically generated process definition document 19. Once the basic process flow is defined by the user, the process definition document including the following: properties for activities, entry and exit actions for activities, definition of events that occur as the user interacts with the application, definition of actions called by events and the transitions between activities.

In the example application of providing a motor insurance quotation, there may be a number of activities as shown in the process model display pane 112 and as defined in the contents pane 114. The activities contain one or more views with which the user interacts, typically an on-screen form for data capture and presentation of information to the user.

The entry actions define the activity when it is presented to the user, and the exit actions define the activity when the user dismisses the screen, eg. completes the form. As the user interacts with each view, events occur such as a button press or mouse click.

With reference to figure 9, the list of views as defined by the user may be presented in a view list pane 116. In the example, these views may include: an initialisation activity start view, VW_INTT to introduce the user to the insurance quotation application; a personal details capture view, VW PER DET CAP, to provide the user with a form in which to fill in personal details; a cancel view, VW_CANCEL_SUM, displayed when the user presses cancel; a vehide details capture view, VW_VEH_DET_SUM, to provide the user with a form in which to fill in vehicle details; a vehicle rejection view, VW_REJ_SUM; a driver details capture view, VW_DRV_DET_CAP, to provide the user with a form in which to fill in driver details; a driver rejection view, VW_REJ_SUM; and a quote summary view, V W_QUOTE_SUM, for presenting the user with the details that form the basis of the quotation.

These views are referenced by the application using the URI's as specified in the view list pane 1 16.

In the example, the activities as shown in the process model display pane 1 12 (figure 7) have entry and exit actions, which may include: initialisation activity, entry action that constructs an empty data model for storing the data that is captured during the application process; personal details, entry action checks for any existing data from a previous session, and if found this data is used to pre-populate the personal details capture view; cancel view, no entry or exit actions; vehicle details, no entry or exit actions; vehicle rejection, no entry or exit actions; driver details, entry action checks for any existing data from a previous session, and if found this data is used to pre-populate the driver details capture view; driver rejection, no entry or exit actions; and quote summary, no entry or exit actions.

In the example, there are a number of events which are trapped by the application and trigger further actions or activities. Exemplary events are shown in the events display pane 117 of figure 10. These may include, for example, an add driver event, EV ADD DRV, which detects a user input indicating that details for more than one driver need to be entered; and a verify post code event, EV_PAC_VERIFY_POSTCODE, which detects a user input of a post code which should be used to check or supply address details. Some the events have event decoders associated with them, to decode the data from the event into XML so that it can be used by the application (shown as undefined in figure 10, pane 117). Once data is converted to XML it can be used to add data to the data model, or alter data in the data model by actions using merge maps described below.

Events can also call actions. In the example screenshot of figure 11, the left hand pane 118 reveal shows in a hierarchical tree structure that the activity ACT_VEH_DET_SUM has two event actions, V_QUOTE_REQUEST and V_QUOTE_FILTER.

Action properties can be displayed by clicking on an action to reveal the action properties in the (bottom left) action properties pane 119 and the action script in the (bottom right) action script pane 120.

Actions can be assigned to events, transitions or activity entry and exit points. In the example screenshot in figure 12 the assignment of actions to transitions and events is shown in the (left) action assignment pane 120. Clicking on an action therein reveals the action properties in the (bottom left) action properties pane 121 and the action script in the (bottom right) action script pane 122.

Merge maps are used by a merge map keyword in a script action to merge two XML documents together. In the example, there are two merge maps defined that are used to merge the data resulting from activities, such as driver and vehicle details capture, to the overall data model which is populated as the application proceeds. With reference to figure 13, the merge maps can be displayed by selection, from the hierarchical tree representation in the left hand pane 123. The URIs of the merge maps are indicated in the top right pane 124 and the properties are specified in the (bottom right) merge map properties pane 125.

In the example, there is only one namespace defined, which is used in the resulting XML data model generated from the application process. The namespace identifies the XML document and provides a reference to the schema, as shown in figure 14, top right pane 126.

Variables are used as simple XML containers within script actions to make manipulating XML easier. In the example, there are a number of variables defined, as shown in figure 15.

Figure 16 shows an overview of the process, as now defined by the process definition document 19. Execution of this process, according to the environment as defined by the configuration definition document 18 proceeds as follows.

1. The initial activity (element 201) includes an entry action to create an empty data model to act as container for the data as it is collected and updated for a car insurance quote throughout the application process. The activity displays the opening view to the user as shown in figure 17.

2. When the user clicks the link, a defined event occurs. If the event = EV_START (element 202) then the Activity ACT_PER_DET_CAP (element 203) is called.

3. The Activity ACT_PER_DET_CAP (element 203) displays the view Personal Details data capture form, shown in figure 18. The user can enter their personal details. When the user clicks a button, an event (element 204) occurs.

4. If the event = EV_PAC_SUBMIT (element 204), then a Pass condition (element 205) is called. If not, then the event EV_PAC_CANCEL (element

206) is called.

5. If the event = EV_PAC_CANCEL (element 206), then the activity ACT_CANCEL_SUM (element 207) is called. Otherwise, control returns to activity ACT_PER_DET_C AP (element 203 ) .

6. The activity ACT_CANCEL_SUM (element 207) is called by the event EV PAC CANCEL (element 206), which displays a view (figure 19) asking the user to confirm. The user interaction with this view causes an event to occur.

7. If the event = EV_CONFIRM from element 207, then End the application. If this was not the event called, then return to element 207.

8. The data from activity ACT_PER_DET_CAP (element 203) is validated against a pass condition which tests that the result of the validation is true, then control is passed to activity ACT_VEH_DET_CAP (element 208). The transition to this activity calls actions that use merge maps to merge the data resulting from the previous activity into the data model for the car insurance quote.

9. If the data from activity ACT_PER_DET_CAP (element 203) fail the pass condition, ie. data validation failed, then control is passed to element 206. 10. The activity ACT_VEH_DET_CAP (element 208) displays the view Vehicle Capture Details form to the user as shown in figure 20. The user can enter the vehicle details. When the user clicks a button, an event occurs.

1 1. If the event = EV_SUBMIT (element 209), then a Pass condition is called (element 210). If this was not the event, then event EV_PAC_CANCEL (element 21 1) is called.

When the user presses the submit button, the data is validated by the rules / conditions within the activity itself. The result of this validation (true / false) is tested in element 210.

12. If the event = EV CANCEL (element 211) from activity ACT_VEH_DET_CAP (element 208), then the activity ACT_CANCEL_SUM (element 212) is called. If this was not the event called, then return to activity ACT_VEH_DET_CAP (element 208).

13. The result of the data capture validation that occurs when the submit button is pressed (event 209) is tested by a pass condition. If the pass condition is true (ie the data was validated by the data capture rules / conditions), then control is passed to activity ACT_VEH_DET_SUM (element 213).

14. If data validation fails the pass condition, then control is passed to element 211.

15. During the transition between elements 210 and 213, a DVLA web service is called that checks the registration number of the vehicle and returns additional vehicle information, including make, model, colour, etc. This information is passed to the next activity, ACT_VEH_DET_SUM (element 213).

16. The activity ACT_VEH_DET_SUM (element 213) displays the same data capture view as in element 208; however this time the information from element 210 is also displayed as shown in figure 21. The user can correct this information as desired.

17. If the event = EV_PAC_SUBMIT (element 214) from activity 213, then a Pass condition is called (element 215). If this was not the event called, then event EV REENTER (element 216) is called.

When the user presses the submit button, the data is validated by the rules / conditions in the data capture application itself. The result of this validation (true / false) is tested in element 215.

18. If the event = EV_REENTER (element 216), then the activity ACT_VEH_DET_CAP (element 208) is recalled. If this was not the event called, then event EV_CANCEL (element 217) is called.

19. If the event = EV_CANCEL (element 217), then the activity ACT_CANCEL_SUM (element 218) is called. If this was not the event called, then return to element 213.

20. The result of the data capture validation process that occurs when the submit button is pressed at event 214 is tested by a- pass condition (element 219). However this pass condition has further logic (AND) which tests a rejection value. If the rejection value is not empty (ie. there was a rejection), then the activity ACT_REJECT_SUM (element 220) is called. If the rejection value is empty, then control is passed to another pass condition (element 219).

21. The pass condition determined that the vehicle details were rejected, which results in this activity presenting the view as shown in figure 22.

22. If the event = EV_CONFIRM (element 221) from activity 220, then End the application. If this was not the event called, then return to activity 221.

23. If the pass condition of element 220 fails, ie. there was no rejection value, then control is passed to this pass condition which checks that validation of the data set in activity 213 was true. If so then a transition action uses merge maps to merge the data resulting from the previous activity into the data model for the car insurance quote. Finally control is passed to activity ACT DRV DET CAP (element 222). If the pass condition fails then pass control to 223.

24. This pass condition tests that the dataset validation in activity ACT_VEH_DET_SUM (element 213) was false. If so, control is passed back to activity 213 for the user to correct. Otherwise, control is passed to event 216.

25. The activity ACT_DRV_DET_SUM (element 213) displays the driver details data capture activity to the user, as shown in figure 23.

The user can enter the vehicle details. When the user clicks a button, an event occurs. 26. It the event = EV_SUBMIT (element 224) trom activity ill, men a Pass condition is called (element 225). When the user presses the submit button, the data is validated by the rules / conditions in the data capture application itself. The result of this validation (true / false) is tested in condition elements 225 and 226.

27. The result of the data capture validation that occurs when the submit button is pressed (event 224) is tested by a pass condition. However this pass condition has further logic (AND), which tests a rejection value. If the rejection value is not empty (ie. there was a rejection), then the activity ACT_REJΕCT_SUM (element 227) is called. If the rejection value is empty, then control is passed to another pass condition (element 226).

28. If the pass condition in 225 fails, ie. there was no rejection value, then control is passed to this pass condition which checks that validation of the dataset in activity 222 was true. If so then a transition action uses mergemaps to merge the data resulting from the previous activity into the data model for the car insurance quote. Finally control is passed to activity ACT_QTE_SUM (element 228). If the pass condition fails then control is passed to pass condition 229.

29. This pass condition tests that the dataset validation in activity 222 was false. If so, control is passed back to activity 222 for the user to coπect. Otherwise, control is passed to event 230.

30. If the event = EV_PAC_CANCEL (element 230) from activity 222, then the activity ACT_CANCEL_SUM (element 231) is called. If this was not the event called, then control returns to activity 222. 31. The activity ACT_QTE_SUM (element 228) displays the i_πιote Summary details to the user, as shown in figure 24.

This screen presents data to the user. There is only one interaction available with the user, which is to start the application again from the beginning (element 232).

In real world use, the user could be asked at this point if they want to proceed with an application for motor insurance based on this quote. If they answer yes to this question, then the XML data model containing all the details resulting from this application process could be passed to another application.

32. If the event = EV CONFIRM (element 232), then the application ends with a call to restart the application from the beginning. Any other type of event passes control back to activity 228.

33. The pass condition determined that the driver details were rejected, which results in this activity presenting the view as shown in figure 25.

The application illustrated above implemented an online solution using an appropriate configuration definition document 18. However, it readily be modified to operate in an offline environment by creating a separate configuration document 18 for the offline environment. This configuration document specifies offline equivalents of views and online services that are used, such as a local postcode lookup component instead of a web service post code lookup.

In cases where there is no such offline equivalent, such as a vehicle lookup service, the configuration definition document 18 can specify exception handling. In this way, the application can operate in an offline environment without altering the process definition document 19. An example of this is the vehicle details lookup web service that uses the online DVLC web service to locate vehicle details based on the vehicle registration. There is no such offline equivalent to this service, so the offline configuration XML document specifies exception handling that enables the application to continue without failing. In this case the service fails, but no error is generated. The application continues as normal except that vehicle details are not populated automatically by the application, instead the user is required to complete them manually.

In the example, the online views are handled by an existing online viewer application using a web browser. For operation in an offline environment, an offline container would be created so that it could operate offline, without affecting the process definition document.

Other embodiments are intentionally within the scope of the accompanying claims.

Claims

1. Apparatus for defining a process for execution on a computer system including: means for generating process definition data specifying a process intent as a function of an ordered series of activities, each activity being associated with at least one action invoked by a defined event occurring during execution of that activity, each activity being executable in at least one computer system environment and including at least one data input and/or data output step, and means for generating configuration definition data identifying at least one specification of computer system environment and resource required for execution of each of the respective activities in the process definition data.

2. The apparatus of claim 1 further including means for defining an entry action associated with an activity that defines data processing steps to be executed upon commencement of the associated activity.

3. The apparatus of claim 1 further including means for defining an exit action associated with an activity that defines data processing steps to be executed upon completion of the associated activity.

4. The apparatus of claim 1 further including means for defining one or more transition conditions associated with an activity that trigger a transition to another activity.

5. The apparatus of claim 1 further including means for specifying one or more data display and/or data collection operations implemented during execution of an activity.

6. The apparatus of claim 1 further including means for defining one or more events associated with an activity, each event specifying input data conditions required to trigger a predetermined action.

7. The apparatus of claim 1 further including means for defining one or more variables associated with each activity, each variable specifying a data source or sink to be used in association with execution of the associated activity.

8. The apparatus of claim 1 further including means for specifying a sequence of script actions to be executed for each activity.

9. The apparatus of claim 1 further including means for specifying a list of references to resource types to be used by each activity in the series of activities, each resource type corresponding to one or more physical resources in the configuration definition data.

10. The apparatus of claim 1 in which the means for generating the configuration definition data includes means for specifying a plurality of possible platform specifications for execution of an activity.

11. The apparatus of claim 1 in which the means for generating the configuration definition data includes means for specifying a plurality of possible applications programs for execution of an activity.

12. The apparatus of claim 1 in which the process definition data is generated as an XML document.

13. The apparatus of claim 1 in which the configuration definition data is generated as an XML document.

14. The apparatus of claim 1 in which the configuration definition data defines one or more of views, services, transforms, merge maps, decoders or name spaces comprising the resources required during execution of the activities in the process definition data.

15. The apparatus of claim 14 in which the process definition data specifies a uniform resource indicator (URI) for each activity which URI is not specific to a computer system environment, and in which the configuration definition data specifies at least one physical uniform resource locator (URL) which is specific to a computer system environment for each URI.

16. A method for defining a process for execution on a computer system comprising the steps of: generating process definition data specifying a process intent as a function of an ordered series of activities, each activity being associated with at least one action invoked by a defined event occurring during execution of that activity, each activity being executable in at least one computer system environment and including at least one data input and/or data output step, and generating configuration definition data identifying at least one specification of computer system environment and resources required for execution of each of the respective activities in the process definition data.

17. Apparatus for executing a process on a computer system using a plurality of different applications programs, comprising: means for retrieving process definition data specifying a process intent as a function of an ordered series of activities, each activity being associated with at least one action invoked by a defined event occurring during execution of that activity, each activity being executaoie in at least one computer system environment and including at least one data input and or data output step; means for determining a current activity scheduled to be executed; means for checking configuration definition data identifying at least one specification of computer system environment and resources required for execution of the current activity; and means for invoking execution of each current activity in an available execution environment specified for the current activity, as determined from the configuration definition data.

I

18. The apparatus of claim 17 further including means for executing, in the invoked execution environment, an entry action associated with the current activity, which entry action defines data processing steps to be executed upon commencement of the associated activity.

19. The apparatus of claim 17 further including means for executing, in the invoked execution environment, an exit action associated with the current activity, which exit action defines data processing steps to be executed upon completion of the associated activity.

20. The apparatus of claim 17 further including means for executing, in the invoked execution environment, one or more transition conditions associated with the current activity, which transition condition triggers a transition to another activity.

21. The apparatus of claim 17 further including means for executing, in the invoked execution environment, one or more data display and/or data collection operations during execution of the activity.

22. The apparatus of claim 17 further including means tor evaluating, in the invoked execution environment, input data conditions specified by one or more events associated with the current activity, to determine whether a predetermined action should be triggered.

23. The apparatus of claim 17 further including means for reading or storing data associated with each activity in accordance with a variable specifying a data source or sink to be used in association with execution of the associated activity, the variable providing a reference to the data source or sink by way of the configuration definition data.

24. The apparatus of claim 17 further including means for executing, in the invoked execution environment, a sequence of script actions to be executed for each activity.

25. The apparatus of claim 17 further including means for determining which of a plurality of possible resource types useable by the current activity and listed in the configuration definition data is to be used by the current activity in the present computer system environment.

26. A method for executing a business process on a computer system, execution of the business process requiring a plurality of different applications programs, comprising the steps of: retrieving process definition data specifying a process intent as a function of an ordered series of activities, each activity being associated with at least one action invoked by a defined event occurring during execution of that activity, each activity being executable in at least one computer system environment and including at least one data input and/or data output step; determining a current activity scheduled to be executed; checking configuration definition data identifying at least one specification of computer system environment and resources required for execution of the current activity; and executing the current activity in one of the available specified execution environments.

27. The method of claim 26 further comprising the step of checking for the presence of an available execution environment for execution of the current activity prior to executing the activity.

28. The method of claim 26 further including the step of executing an entry action associated with the current activity, which entry action defines data processing steps to be executed upon commencement of the associated activity.

29. The method of claim 26 further including the step of executing an exit action associated with the current activity, which exit action defines data processing steps to be executed upon completion of the associated activity.

30. The method of claim 26 further including the step of executing one or more transition conditions associated with the current activity, which transition condition triggers a transition to another activity.

31. The method of claim 26 further including the step of executing one or more data display and/or data collection operations during execution of the activity.

32. The method of claim 26 further including the step of evaluating input data conditions specified by one or more events associated with the current activity, to determine whether a predetermined action should be triggered.

33. The method of claim 26 further including the step of reading or storing data associated with each activity in accordance with a variable specifying a data source or sink to be used in association with execution of the associated activity, the variable providing a reference to the data source or sink by way of the configuration definition data.

34. The method of claim 26 further including the step of executing a sequence of script actions to be executed for each activity.

35. The method of claim 26 further including the step of determining which of a plurality of possible resource types useable by the current activity and listed in the configuration definition data is to be used by the current activity in the present computer system environment.

36. A computer program product, comprising a computer readable medium having thereon computer program code means adapted, when said program is loaded onto a computer, to make the computer execute the procedure of any one of claims 16 and 26 to 35.

37. A computer program, distributable by electronic data transmission, comprising computer program code means adapted, when said program is loaded onto a computer, to make the computer execute the procedure of any one of claims 16 and 26 to 35.