Provides the application programming interface (API) for managing process-related objects in the ProcessChoreographer. You can create application programs that use the API to manage runtime information related to processes. You can:

The API contains a stateless session bean BusinessFlowManager for local and remote access. The BusinessFlowManagerService interface describes the functions that can be called locally and remotely. It exposes the functions that can be called by an application program. The application program can be any Java program, including another EJB.

The application program accesses the BusinessFlowManager session bean through the bean's home and remote or local interfaces. A reference must be added to your application deployment descriptor. For example, for client applications such as a J2EE client application add the reference to the application-client.xml, for a Web application to the web.xml, and for an EJB application to the ejb-jar.xml.

Add the reference to the remote interface as in the following example:

   <ejb-ref>
     <ejb-ref-name>ejb/BusinessFlowManagerHome</ejb-ref-name>
     <ejb-ref-type>Session<ejb-ref-type>
     <home>com.ibm.bpe.api.BusinessFlowManagerHome</home>
     <remote>com.ibm.bpe.api.BusinessFlowManager</remote>
   </ejb-ref>

Add the reference to the local interface as in the following example:

   <ejb-local-ref>
     <ejb-ref-name>ejb/LocalBusinessFlowManagerHome</ejb-ref-name>
     <ejb-ref-type>Session<ejb-ref-type>
     <local-home>com.ibm.bpe.api.LocalBusinessFlowManagerHome</local-home>
     <local>com.ibm.bpe.api.LocalBusinessFlowManager</local>
   </ejb-local-ref>

If you are using the remote interface, then the generated API stubs must be packaged with your application:

Note: If you are using the remote interface, then the XSD's describing your messages must be on the classpath.

The BusinessFlowManager home interface is then made available to the client through JNDI by the container where the BusinessFlowManager session bean is deployed. To access the remote interface:

   // Obtain the default initial JNDI context
   Context initialContext= new InitialContext();

   // Lookup the remote home interface of the BusinessFlowManager bean
   Object result= initialContext.lookup("java:comp/env/ejb/BusinessFlowManagerHome");

   // Convert the lookup result to the proper type
   BusinessFlowManagerHome processHome= (BusinessFlowManagerHome)javax.rmi.PortableRemoteObject.narrow(result,BusinessFlowManagerHome.class);
To access the local interface:
   // Obtain the default initial JNDI context
   Context initialContext= new InitialContext();

   // Lookup the local home interface of the BusinessFlowManager bean
   LocalBusinessFlowManagerHome processHome= (LocalBusinessFlowManagerHome)initialContext.lookup("java:comp/env/ejb/LocalBusinessFlowManagerHome");

The home interface contains a create method that returns the BusinessFlowManager session bean's remote or local interface. For example, access the remote interface of the session bean:

   BusinessFlowManager process= processHome.create();
For example, access the local interface of the session bean:
   LocalBusinessFlowManager process= processHome.create();

When the BusinessFlowManager session bean is accessed, the application program can call any of the business functions exposed by the API. For example:

   process.initiate("MyProcessModel",input);

Note:
Access to the BusinessFlowManager session bean does not guarantee that all functions can be executed; the caller must also be authorized for the functions and objects.

When an instance of the BusinessFlowManager session bean is created, the container associates a session context with the instance of the session bean. The session context contains the caller's principal ID and an indication whether the caller belongs to the group of BPE system administrators or monitors. This is used by both the container and the process engine to check the caller's authorization for each call.

Authorization is always checked by the Business Flow Manager, even when checking global security is unset. In the latter case, the caller's principal ID is 'UNAUTHENTICATED' and handled like a normal user ID.

Calls are executed as transactions. A transaction is either established and ended explicitly by the application program, or established by the container when the application progam calls the process engine and ended by the container when the application program receives the result (the deployment descriptor specifies TX_REQUIRED). For example, the application program can establish and end a transaction as follows:

   // Obtain user transaction interface
   UserTransaction transaction= (UserTransaction)intialContext.lookup("jta/usertransaction");

   // Begin a transaction
   transaction.begin();

      // Process calls ...

   // On successful return, commit the transaction
   transaction.commit();
Design your own transactions to prevent database deadlocks when multiple transaction instances are running concurrently. For example, the following transaction may result in database deadlocks when run concurrently:
   UserTransaction transaction= (UserTransaction)intialContext.lookup("jta/usertransaction");
   transaction.begin();

     process.getActivityInstance(aiid); // read-locks the task
     process.claim(aiid);               // write-locks the task to update the state

   transaction.commit();