To build on the example in Working with a Single EJB Object Instance, suppose that instead of returning a single EJB in the Results array, the CreateEJB 2.1 or FetchEJB 3.0 adapter service instance returns multiple EJB instances. In this case you use the LOOP step in Designer to make the flow service iterate over the contents of the array, and invoke one (or more) methods on each EJB in the array.

Any given instance of a CreateEJB 2.1 adapter service will invoke a single method on the javax.ejb.EJBHome interface. This method is called to construct an instance of the actual EJB remote class and return it to the caller. This remote EJB instance is the EJB and is where the business methods of the EJB are found.

It is possible for a home interface method to return multiple remote EJB objects (“finder” methods on entity beans, for example). The CreateEJB 2.1 adapter service accounts for this with the Results array.

Similarly, for any given instance of a FetchEJB 3.0 adapter service, the service fetches the EJB based on the selected JNDI Name and returns the EJB Object to the caller.

The same principle applies to instances of CreateInvokeEJB 2.1 and FetchInvokeEJB 3.0 as well. However, it is somewhat more restrictive. CreateInvokeEJB 2.1 or FetchInvokeEJB 3.0 will automatically loop over each EJB returned and call the same business method on each. However, if you must be able to call more than one business method, you need to configure the necessary CreateEJB 2.1 or FetchEJB 3.0 and the corresponding InvokeEJB 2.1 or InvokeEJB 3.0 services and incorporate them into a flow service.

Regardless of how many EJB objects are returned by CreateEJB 2.1 or FetchEJB 3.0, each object is of the same remote EJB class. That is, they are the same type. Therefore, any invocation of a CreateEJB 2.1 or FetchEJB 3.0 adapter service will return one or more remote EJB objects of the same class.

This is important to note when designing flows. Because any given CreateEJB 2.1 or FetchEJB 3.0 instance is configured to work with a single EJB class, you can only expect to call the business methods exposed by that class. If in your flow you need to access some other EJB type, you will need to configure a separate CreateEJB 2.1 or FetchEJB 3.0 service for that type. If you attempt to pass an EJB object of one class into a corresponding InvokeEJB 2.1 or InvokeEJB 3.0 service configured for an entirely different class, you will see run-time exceptions.

The following example shows how to use the LOOP step in Designer to implement this processing. To begin, you configure a CreateEJB 2.1 or FetchEJB 3.0 adapter service instance (services.fetch.FindLargeAccountEJBs) that may return one or more EJBs in its Results array. You want to execute the same InvokeEJB 2.1 or InvokeEJB 3.0 adapter service against each EJB returned. However, you do not know how many EJBs might be returned.

For information about configuring CreateEJB 2.1 and FetchEJB 3.0 adapter services, see Configuring CreateEJB 2.1 Services and Configuring FetchEJB 3.0 Services respectively.

You must first define an Object list in the outbound pipeline immediately following FindLargeAccountEJBs. This list can have any valid name but it cannot be nested inside any other structure (for example, a Document). Create a link between the Results array and the new Object list in the outbound pipeline as shown in the figure below.

Now insert a LOOP between the two adapter service instances (services.fetch.FindLargeAccountEJBs and services.invoke:GetAccountBalance). In this example there is a single child step to be executed within the body of the LOOP step: this is the InvokeEJB 2.1 or InvokeEJB 3.0 adapter service instance (services.invoke.GetAccountBalance).

The loop should iterate once for each EJB found in the Beans array (the Object list defined earlier). To do this, enter the array's name (without the leading forward slash-Designer inserts this) in the Input array field in the Properties view.

You can see the steps for inserting a LOOP and entering the array’s name in the figure below.

Finally, complete the flow by selecting the services.invoke.GetAccountBalance service and creating a link between the Beans parameter (Designer automatically generated this parameter for you) and the input EJB parameter to the service as shown in the figure below.