Process automation systems are used in many companies to manage the various business processes that are implemented within those companies. A process automation system may be used, for example, to manage an order fulfillment process to ensure that each and every incoming order is properly handled in accordance with a process set forth by the management of the company. Similarly, a process automation system may be used to manage an expense approval process to ensure that, before an expense is incurred, all of the proper approvals have been obtained.
In a typical process automation system, each process that the system manages is defined by a user (e.g. a manager), and comprises one or more activities. An activity represents an action or operation that is to be performed within the process. An activity may require action on the part of a user (e.g. an approval from a manager), or it may be an automated function (e.g. an automated credit check). Each activity is linked to one or more other activities by relationship information. Relationship information may specify an order in which activities are to be performed (e.g. ship an order after the customer has been billed). Relationship information may also specify decision logic for determining whether to perform an activity (e.g. bill a customer for an order only if the credit check returns a positive result; otherwise, refuse the order). Basically, the relationship information defines a flow for the process. Once the activities and relationship information for a process are fully defined, a process engine can use the process definition to automatically implement and manage the process.
As noted above, some of the activities in a process can be automated functions. These automated functions may be functionality provided by components within the automation system, or they may be services provided by service applications external to the system (e.g. service applications residing on servers outside of the company). When the process engine encounters an activity involving an automated function, the process engine causes that automated function to be invoked. In the case of a service provided by an external service application, this invocation can be somewhat complex. This is because different service applications may expect services to be invoked in different ways. For example, one application may expect a particular set of semantics and message formats to be used when invoking a service, while another application may expect a different set of semantics and message formats. That being the case, in order to properly invoke a service, the process engine needs to know specifically how the service application for that service expects the service to be invoked. For a large number of service applications, each with different requirements, this can require a large amount of additional logic to be implemented by the process engine.
To shield the process engine from the complexity of service invocations, some automation systems implement application proxies. With application proxies, a process engine does not invoke the services on the service applications directly. Instead, the process engine causes the application proxy associated with a service to be invoked. It is then up to the application proxy to invoke the service on the service application in the manner expected by the service application. In this way, the application proxy shields the process engine from the complexities of the service application, which in turn, allows the process engine logic to remain generic.
In one implementation, the functionality of an application proxy is achieved through the application of XSL (eXtensible Stylesheet Language) transformation rules. More specifically, when the process engine encounters an activity which calls for the invocation of a service provided by a service application, the process engine sends out an XML (eXtensible Markup Language) state message. This message is received by an application proxy associated with the service, and is processed by the proxy to generate a command list. To generate the command list, the proxy accesses a set of customized XSL rules for the service that is being invoked, and processes the XML state message with the XSL rules to transform the state message into the command list. Assuming the proper XSL rules are applied to the state message, the command list will comprise all of the proper steps and all of the proper semantics and formats for invoking the service. Once the command list is derived, the proxy executes each of the commands on the command list to invoke the service. The service is thus invoked without requiring the process engine to directly interact with the service application.
This approach is effective for shielding the process engine from the complexities of the service invocation process. However, it has a shortcoming in that it requires customized XSL transformation rules to be written for each different service invocation. Because of this requirement, whenever a new service is added, a new set of XSL rules needs to be developed. Whenever an existing service is changed, an existing set of XSL rules need to be amended. This need to constantly update the XSL rules can lead to increased maintenance cost for the process automation system. Also, writing XSL rules is a difficult task. Even for a person familiar with XSL, developing a set of rules that transforms a state message into a proper command list is no simple matter. As a result, a typical end user cannot configure an application proxy to work with a new service. Because of the difficulty and the high cost of developing and maintaining XSL rules, the current approach to implementing application proxies is less than optimal.