BPM Plug-in Framework

BPM supports plug-in development for extending its functionality. A plug-in is used to extend design and/or runtime behavior. It modifies the behavior of various workflow components , including start, event, and done nodes; task actions; functions; message types; and so on. One example is extending the behavior of the start node being triggered by a non-XML message.

In Figure 34.13, an external application interacts with BPM by both an XML and a non-XML event. The standard way of triggering BPM is by placing an XML message on a JMS queue. A non-XML event can be made to trigger a BPM workflow by using a plug-in. BPM clients such as Studio can also use plug-ins to enhance their functionality. The plug-in manager supports the configuration, design, and runtime management of plug-ins. The plug-in manager oversees the loaded plug-ins and their interactions with the WebLogic Integration process engine and BPM clients .

Figure 34.13. BPM plug-in architecture.

The plug-in manager's functionality is exposed via the plug-in API, which consists of the following packages:

• Com.bea.wlpi.server.plugin.* ” This package contains classes providing runtime management of plug-ins during workflow execution. PluginManager , a stateless session EJB, is used to get access to the metadata of the deployed plug-ins and handle event notifications. PluginManagerCfg , a stateless session EJB, provides configuration and design management of plug-ins. This maintains configuration information and the list of plug-ins that may be registered for system event notifications.

• Com.bea.wlpi.common.plugin.* ” This package contains serializable classes providing utilities and value objects for process management.