Applications may be associated with activities to specify the action to be executed when the activity is instantiated at runtime. They are basically application programs. Multiple activities may use the same application but only one application may be executed within an activity.
There is an exception with interactive applications. You can define JFC applications, JSP Pages etc. in one interactive application to cover different application contexts (e.g. execution clients).

For details on using applications in the Eclipse Modeler and the Modeling perspective, please refer to chapter Specifying Applications in the Eclipse Modeling Guide and chapter Specifying Applications in the Business Process Modeling Handbook respectively.

Application Type

Applications are categorized by having a unique application type describing the execution semantics and custom hooks to the modeling environment to have type-specific modeling facilities. Prescribed by the application type, every application has its own specific properties to be configured.

Infinity Process Platform ships with a set of default application types for interactive and non-interactive activities as well:



Please refer to the chapter System Integration for detailed information on the usage of concrete applications. The list of default applications may be extended by writing custom application types.

Applications are a pure modeling concept. They have no persistent representation in the audit trail. As a model element, applications are first class model elements, i.e. they are shared between all process definitions.

Application Type and Target Portals

If you are using interactive applications, please note the following restrictions:

Non-Interactive Applications

Synchronous/Asynchronous Application

Applications associated with non-interactive activities, i.e. non-interactive applications, come in two different flavors:

Two very common synchronous application types deserve special attention. These are

Completion Method

Both application types are just for executing Java code at runtime - on a Session Bean or on a plain Java object. This is realized by executing one dedicated method, the completion method. See also Runtime Behavior.

As a model element non-interactive applications have the following properties:

Retry Mechanism of Non-interactive Applications

A Retry mechanism can be enabled for non-interactive applications. When specifying the retry time, you should take in account the default transaction timeout. The retry count * delay + processing time should be less than transaction timeout. The following table shows the default transaction timeout of specific application servers:

Servers Default Transaction Timeout
WebSphere 120 seconds
WebLogic 30 seconds
JBoss 300 seconds

No indication is set in the audit trail to know if an application is executed more than once, if in the end the application succeeded. To find this, you should refer to the stack traces in the log files. In case of exceptions that are thrown within the application and if retry ends at the last cycle with an exception, only this last exception is shown in the audit trail. You need to check the log files to know about other exceptions. For example, exception1 is thrown, then exception2 and finally application completes. Retry is set to 3. In another case, first exception1 is thrown, then exception2 and then exception3 interrupts activity instance. Only exception3 is reported in the audit trail. To know about execption1 and exception2, you need to refer to the log files.

If the Infinity Process Platform engine was stopped the hard way while the activity is executed, there is no difference between an application with retry configured and one without. Meaning an engine recovery will re-animate both but it is not visible to the user (except log file-scanning) if the application with retry-mechanism was already executed several times.

Per default an application retry is performed on engine side. The Eclipse modeler provides an option to determine that a retry should be performed on application side instead.

Interactive Applications

For interactive activities, workflow control is temporarily outside the engine, e.g. in a Windows client application or in a Web page. After creating an interactive activity, the current activity thread and transaction stop. Only when an activity instance is completed, control is returned to the Infinity Process Platform runtime. Nevertheless, Infinity Process Platform enables you at modeling time to store information in the associated application (interactive application) on behalf of a client.

Application Context

Because different client contexts may exist (e.g. Web-based client, native Windows client) Infinity Process Platform will maintain client-specific information in the scope of so-called application contexts, allowing for an arbitrary number of such contexts to be associated to specific interactive applications. Infinity Process Platform ships with the following application contexts:

As a model element interactive applications have the following properties:

Custom Application Types

The modeling and runtime environment can be customized to support arbitrary application types by using the Infinity Process Platform Service Provider Interface (SPI). The use of the Infinity Process Platform SPI is described in the Tutorial Infinity Process Platform SPI Programming chapter of the Programming Guide.