Figure: Specifying a Plain Java Application
Both Plain Java applications and Session Bean applications are designed to execute Java code:
In both cases this method to be executed is called completion method.
As already explained for Workflow Data, all IN data mappings are executed before the completion method and all OUT data mappings are executed after the completion method. For data mappings it is possible to use all getter and setter methods in the sense of section Java Style Data Types on the underlying object. This object will be the same for the whole life time of activity instance execution. Especially, it is guaranteed that for a stateful Session Bean application all data mappings and the completion method will operate on the same Session Bean instance.
Plain Java applications allow to instantiate any Java class with at least one public constructor and execute a method on it. To achieve this, at modeling time you have to specify
These settings are accessed in Plain Java application types in the Process Workbench.
To specify a plain Java application in the Process Workbench:
Please refer to chapter Specifying Applications for general questions on working with applications in the Process Workbench.
Figure: Specifying a Plain Java Application
Detailed information on integrating Java applications can be found in the System Integration part.
The return value of the completion method, if any, will be exposed as an OUT access point returnValue : <type>.
Figure: Return Value Access Point
The constructor and completion method parameters will be exposed by the arguments of the methods in the format <argument> : <type>.
For example using the following completion method with parameters arg1 and arg2:
public class TestAppl
{
public TestAppl()
{
}
public void notifyCustomer(int arg1, String arg2)
{
}
}
would result in the provided access points arg1 : int and arg2 : String.
Figure: Access Points for completion method
When connecting a data to an application activity, the data mapping is created automatically. Please refer to the section Automatic Completion of Data Mappings of the chapter Specifying Data Mappings for detailed information on the preset of parameters for automatic completed data mappings.
Stardust provides the following two annotations that can be used to retrieve access points via parameter names:
@ParameterNames ({@ParameterName("count"), @ParameterName("name"), ...})
public int method(int arg1, String arg2);
For example, if you set the following annotations for your completion method:
import org.eclipse.stardust.common.annotations.ParameterName;
import org.eclipse.stardust.common.annotations.ParameterNames;
public class TestAppl
{
public TestAppl()
{
}
@ParameterNames({@ParameterName("Element Count"), @ParameterName("Customer Name")})
public void notifyCustomer(int arg1, String arg2)
{
}
}
instead of the arguments, you see the annotation settings for ParameterNames in the list of access points:
Figure: Access Points with Annotation Usage
For an application that you like to import in the Web modeler, you can also use the @ParameterName in the parameter list directly, as in the following example:
import org.eclipse.stardust.common.annotations.ParameterName;
public class TestAppl
{
public TestAppl()
{
}
public void notifyCustomer(@ParameterName("Element Count") int arg1, @ParameterName("Customer Name") String arg2)
{
}
}
Please note that this usage is not supported in the Eclipse modeler itself yet!
The configurable retry mechanism provides the facility to retry the operation in case the target service is temporarily unavailable.
For more information, please refer to Retry Mechanism of Non-interactive Applications section of the Applications chapter.
For example, you have added a synchronous application to the model. In the Property page of the application, you can enable the retry, specify number of retries and time between retries. However, note that maximum 10 retries and 60 seconds between two retries are allowed. So, the application will retry for the defined number of times with a pause of the defined number of seconds, until it has success. If the application still fails after the defined number, it will no longer retry.
Session Bean applications allow to instantiate a stateful or stateless Session Bean and execute a method on it. To achieve this, at modeling time you have to specify
The create method parameters will be exposed as IN access points named x InitParam n where x is the first letter of the class name and n is a consecutive number, starting with 1.
The completion method parameters will be exposed as IN access points named x Param n where x is the first letter of the class name and n is a consecutive number, starting with 1. The return value of the completion method, if any, will be exposed as an OUT access point returnValue. Let's consider a Session Bean ProcessInvoice used in a Session Bean application with the following create method and completion method chosen:
public interface ProcessInvoiceHome extends EJBHome
{
ProcessInvoice create (Invoice invoice, java.util.Date receivingDate);
...
public interface ProcessInvoice extends EJBObject
{
Invoice addItem(InvoiceItem item);
This will result in the following access points for create method parameters and completion method parameters:
These settings are accessed in Session Bean application types in the Process Workbench.
To specify a Session Bean application in the Process Workbench:
Please refer to the section System Integration for detailed information on integrating session beans.
Choose the property values for:
Note that for accomplishing this step it is necessary to have the home interface and remote interface classes in the class path of the Process Workbench.
To test a local class as a mock Session Bean, check the Local Binding check box. There has to be an implementation of the home interface.
Figure: Specifying EJB 2.x Session Beans
The property page for EJB 3.x contains the Eclipse class browser entry Bean Class to enter the bean class.
Fill in the values for the following entries:
Figure: Specifying EJB 3.x Session Beans
Arbitrary classes can be selected. If the selected class does not satisfy the EJB 3.0 beans requirements, an error status is displayed.
A combo box for the Business Interface is provided with:
Once an appropriate bean class has been selected, the combo box is populated accordingly, applying the rules regarding business interfaces of EJB 3.0 session beans:
Instead of entering the business interface via browsing of bean classes, it can be entered directly or via browsing.
The JNDI path can be entered if it cannot be derived from the bean class properties.
A combo box for the selection of the Completion Method is provided as well as a combo box for the Initialization Method. Both methods will be invoked at runtime.
The configurable retry mechanism provides the facility to retry the operation in case the target service is temporarily unavailable.
For more information, please refer to Retry Mechanism of Non-interactive Applications section of the Applications chapter.
For example, you have added an application to the model. In the Property page of the application, you can enable the retry, specify number of retries and time between retries. However, note that maximum 10 retries and 60 seconds between two retries are allowed. So, the application will retry for the defined number of times with a pause of the defined number of seconds, until it has success. If the application still fails after the defined number, it will no longer retry.
