A business process is a sequence of activities being either interactive activities or performed batch processes. In case of batch processes the business process engine calls an application and the acting thread of the engine does not leave the call of the application before it is finished. In case of an interactive activity the application is not called directly but a user is being notified to start this application. The integration of the application in the business process makes sure that after termination of a task the process engine gets a feedback message so the next task can be started.

The definitions of the processes are written in XPDL. Libra delivers the process definitions of the different fields of application with the applications. In the introductory phase the definitions can be adapted to the individual organisation and its needs and get modified later on in full operation. XPDL is an open format standard that is fully supported by the Libra process engine which makes open source tools like JaWE (Java Workflow Editor) suitable for editing the process definitions.

A process oriented application communicates with the process engine as a client. Typical calls are:

• Create Workflow Process
• GetNextActivityInstanceWithLock
ReleaseActivityInstance
• Complete Activity

All API are implemented in the "Stateless Session Bean". For calls which can take a long time to complete, you can use an asynchronous call. This asynchronous call is called „behind“ the Session Bean and its processing is invisible for the API Client.

The API is devised so as to ensure that an interactive Application saves the state of an object relating to its possible processing in the workflow state. It returns the next open activity instance. An activity instance is „Open“, meaning created, if another one was closed so that a new process was started. If more than one activity instance is open only one is returned. Theoretically all open activity instances could be returned but then there would be an asymmetry to the termination calls returning further data like the completion code for each activity instance. The transmission of the next open acitivity instance is combined with a lock. The lock is placed on the activity instance and the whole process.

The API is devised so as to ensure that an interactive Application saves the state of an object relating to its possible processing in the workflow state. It returns the next open activity instance. An activity instance is „Open“, meaning created, if another one was closed so that a new process was started. If more than one activity instance is open only one is returned. Theoretically all open activity instances could be returned but then there would be an asymmetry to the termination calls returning further data like the completion code for each activity instance. The transmission of the next open acitivity instance is combined with a lock. The lock is placed on the activity instance and the whole process.

When an „Exit“ activity (there are no transitions after) is terminated the whole workflow process is terminated depending on other open activities that should be terminated.Outstanding activities should be terminated via the API. Running applications are continuing. If new activities are requested via the API none are returned (without exception). On termination of an activity all notifications for the same are cleared, analogously this applies for a process.

Upon process creation all data items and all formal parameters are created. If the names of data items and formal parameters are identical the formal parameter is ignored. Formal parameters don’t have any initializers, so straight „OUT“ parameters should be initialized by creating a data item with the same name.

If the process is a subprocess the „actual“ parameters of the parent activity are used. So straight „IN“ parameters are evaluated and assigned to the attribute of the subprocess. This attribute is identified through the formal parameter matching the ordinal number. For „IN-OUT“ parameters the actual parameter is not evaluated but represents the name of a data item of the parent process. Its value is assigned to the attribute of the subprocess which is defined with the formal parameter having the same ordinal number. That means either the nth actual parameter evaluates for IN directly to a value or it evaluates for IN-OUT by reference to a data item. This value is assigned to a attribute of the subprocess. The name (and possibly the type) of the attribute is clear from the nth formal parameter of the subprocess. On termination of the subprocess the values of all attributes of the subprocess being identified by an IN-OUT and OUT parameter of its formal parameter list are copied to attributes of the parent process. The attribute of the parent process is determined by the actual parameter list of the calling activity: the nth formal parameter equals the nth actual parameter that contains the name of the attribute of the parent process.