Linking business processes and enterprise services together using IBM Business Process Manager Advanced

This article uses a scenario to illustrate how to separate the business and technical layers in a typical BPM solution implemented in IBM® Business Process Manager Advanced, with special focus on the Advanced Integration Services (AIS) capability. The article assumes the reader is already familiar with the concepts of IBM BPM Advanced and wants to understand how best to combine a BPM solution with SOA services using AIS. This content is part of the IBM Business Process Management Journal.


Fintan McElroy (, Senior Managing BPM Consultant, IBM

Fintan McElroy photoFintan McElroy is a senior consultant for IBM Software Services for WebSphere (ISSW), whose mission is to assist IBM’s customers in their adoption of WebSphere products. Fintan has 18 years IT experience in a variety of roles including Infrastructure Architecture and Design, Application Architecture, Business Analysis, and Application Development. He has been a leading proponent of BPM with SOA since its inception and before that had been a practitioner of object-oriented architecture and design methods. He currently provides consultancy to IBM's customers on enabling agility in their enterprise through the adoption of IBM Business Process Manager and related products.

26 September 2012


This article describes how to separate the business and technical concerns in a typical business process management (BPM) solution implemented in IBM Business Process Manager Advanced (hereafter referred to as BPM Advanced). It first describes the logical architectural layering, where processes executing in a BPM orchestration layer consume provided business services, which in turn aggregate various lower-level technical services. It then uses a scenario to illustrate how to achieve the goals of the architectural layering using BPM Advanced, focusing on the Advanced Integration Services (AIS) capability.

We tested the scenario described in this article on both the V7.5.1 and V8 versions of BPM Advanced. The article refers to the steps used in V8, but the code is also provided for V7.5.1. The sample solution is included in which is available for download with this article. For best results, we recommend that you install the code sample and follow the article by referring to your own installed copy of the sample.

Business service specification

A common rule of thumb to distinguish between a business process and a business service is to assess how the business views the activity. Asking "would the business ever be interested in monitoring the steps involved in this activity?" can help define whether the activity should be considered a process or a service. If the business has no desire to understand the mechanics of the activity, that suggests it should be defined as a service. If the business wants to monitor or drive the individual steps involved in the activity, that is an indicator of a process rather than a black-box service. In addition, the granularity of a service that is used by a business process should be something that has meaning in business terms. There may be many lower levels of granularity that expose technical functions necessary to contribute to a business service, but these are not of interest to the business and therefore should not be referenced by a business process.

Separation of business and technical services

Following the advice above, there is a logical layering in a BPM built on service-oriented architecture (SOA) in which each layer has defined responsibilities and consumes the services provided by layers below it. Figure 1 shows an example of an SOA-layered architecture. At the Consumers layer, a client channel interacts with a business process or, if appropriate, directly consumes business services in the Services layer (green indicates business services as defined above while orange denotes lower level of granularity technical services).

Figure 1. SOA layered architecture
SOA layered architecture

Taking this architecture in the context of BPM Advanced, business processes (and linked sub-processes) are implemented as business process diagrams (BPDs) and any business services that are to be consumed by BPDs should be exposed as AIS services, as shown in Figure 2. The example business service shown is directly consumed by the channel and does not need to be exposed as an AIS; instead it might be exposed as a SOAP-based web service or a RESTful web service.

Figure 2. Role of AIS in architecture
Role of AIS in architecture

Now let's look at the lower-level technical services that are composed in order to expose the business service. These technical services (Figure 3 shows an example of one such service) should be implemented in Integration Designer and are not exposed to the business process (BPD) and therefore do not need to be associated with the Process Center.

Figure 3. Example of a technical service
Example of a technical service

In the rest of this article, we'll look at how to achieve this separation of concerns in BPM Advanced through an illustrative scenario.

AIS specification in Process Designer

We've already discussed the differentiation between business and technical services. This section shows you how to define an AIS that complies with the recommended approach described previously. Note that an AIS is a bit of a misnomer – what it is really providing is an Advanced Integration Service Operation because it provides the ability to define a single operation of a service. Having followed a service design exercise, a logical service may then result in a number of related AIS definitions, one for each operation.

As the AIS is a service with relevance to the business, the business author is likely to define the service interface in Process Designer, potentially taking input from a technical integration specialist about recommended practices for good service design. The mapping between this business-level service and the lower-level technical service implementations will be performed later by the integration specialist using IBM Integration Designer.

If you haven't already done so, you should go ahead and import the relevant .twx file into your environment so that you can examine the referenced components described in this section (either Order_Facade_TK 8.0 – v1.1.twx or Order_Facade_TK 7.5.1 –v1.0.twx depending on the version of BPM Advanced you're using).

For the example scenario, the business author has specified the AIS interface contract (Get Customer Invoice AIS), as shown in Figure 4.

Figure 4. AIS definition
AIS definition

(See a larger version of Figure 4.)

The interface represents the retrieval of an invoice for a customer where the customer number and the order number are supplied and the returned data is modeled in the data structure InvoiceDetails.

Figure 5 shows the detail of the data structure. The fields added are those the business author has identified as being necessary based on the requirements of the business process that will make use of these fields downstream of the call to the backend systems. You'll see later that this structure will be constructed by making various calls to existing services and mapping from this business-relevant data to the existing data structures provided. You'll also see that there are additional data elements provided in existing technical services that are not needed by the business service and so do not need to be mapped.

Figure 5. Business object referenced by AIS
Business object referenced by AIS

Associating AIS with technical implementation

This section covers in detail the technical services that are used to implement the AIS. In order to follow the description, you should import the relevant Project Interchange file into a new Integration Designer workspace and then associate the Order Façade Toolkit with the components imported into Integration Designer. Depending on your environment the file to use will either be or Figure 6 shows how your workspace should look after importing the Project Interchange zip.

Figure 6. Integration Designer after PI import
Integration Designer after PI import

You need to associate the Order Façade Toolkit with the workspace (first make sure that you have added the necessary access rights to the toolkit using the Process Center Admin console). In Integration Designer, switch to the Process Center perspective and then select to Open in workspace as shown in Figure 7.

Figure 7. Associate toolkit with Integration Designer workspace
Associate toolkit with Integration Designer workspace

(See a larger version of Figure 7.)

After Integration Designer completes the build process, you should have the Order Façade Toolkit along with the other previously imported modules. You can now publish to the Process Center, as shown in Figure 8.

Figure 8. Publish to Process Center
Publish to Process Center

Back-end technical services implementation

There are many possible technical approaches to expose existing functionality as services available in BPM Advanced. A range of add-on adapters are available for exposed packaged application logic (such as SAP® or Oracle® E-Business Suite, as well as technical adapters for connecting to existing operational systems exposed via, for instance, JDBC or JMS messaging. You could also consume existing SOAP-based web services either internal or external to the organization. For this scenario, we'll show how to expose existing functionality defined in Java™ Enterprise Edition (JEE) Enterprise Java Beans (EJBs) using an intermediary composite service defined as a Business Process Execution Language (BPEL) micro-flow (the BPEL micro-flow will effectively provide the implementation for the AIS and hide the lower-level details of the individual EJBs).

EJB implementation

The AIS service contains a mixture of business data related to both a customer and to orders the customer has placed. In order to provide the necessary data to construct InvoiceDetails there will need to be operations invoked on two EJBs – one related to Customer and the other related to Order. Figure 9 shows the UML diagram of the CustomerService session EJB with a number of operations exposed on the remote / local interface. You'll need to switch to the JEE perspective in Integration Designer to view the class diagram in the CustomerEJB project.

Figure 9. Customer Service EJB
Customer Service EJB

Similarly, the OrderService EJB provides operations for interacting with an Order, as shown in Figure 10.

Figure 10. Order Service EJB
Order Service EJB

In normal circumstances, the session EJBs would use a persistence framework such as Java Persistence Architecture 2.0 (JPA). In that case, the session EJBs would call various JPA entity beans that would interact with a persistent store like a DB2® database. However, for the purposes of simplicity in this demonstration scenario, I've just modeled the data as plain old Java objects (POJOs). The Order POJO seen in Figure 11 shows a more detailed structure, including a contained array of ProductItem business objects than is needed at the business level as described previously. It's common to find that the technical service implementations provide more detail than services at the business level really need, so mediation is required between the business and technical views.

Figure 11. EJB referenced POJO
EJB referenced POJO

(See a larger version of Figure 11.)

Façade pattern design

In order to make a clean separation between the business-level services that are required to be surfaced in the BPM layer and the more technical services in the SOA layer, we'll use a façade pattern to hide the more technical detailed services from being exposed to the business process in the form of an AIS.

You've already seen the toolkit design in Process Designer where the AIS interface was specified by the business author. The toolkit is opened in Integration Designer in order to make it visible to the integration specialist working in the tool. The service is exposed in a toolkit so that it can be reused by multiple process applications that have a need to access the Customer Invoicing service. Note that in this example scenario a very simplified BPD is also included in the toolkit for the purpose of illustrating how to use the AIS service, but in reality the consumer of the AIS would be a BPD inside a process application that includes the toolkit as a dependency.

The important aspect of implementing the façade pattern is that the toolkit itself only effectively contains the AIS interface, which in turn delegates to the real implementation that resides in an SCA module that is not managed as part of Process Center. This SCA module therefore provides the bridge between the business service defined in the AIS and the lower-level technical services that have been exposed.

We've created an SCA module that will integrate with the EJBs and orchestrate the logic of the individual EJBs using a short-running BPEL process (micro-flow). Because that SCA module will ultimately be used to provide the AIS implementation it needs to have the AIS interface made available to it. In order to achieve that, we added the toolkit library as a dependency of the SCA module as shown in Figure 12.

Figure 12. SCA module dependency on toolkit library
SCA module dependency on toolkit library

Assembly of components

In the implementation SCA module once the toolkit library has been added the AIS interface is then visible and can be referenced. The AIS interface is added as an SCA Export (it will later be consumed from within the Toolkit) as shown in Figure 13. The two EJBs have been made available in the assembly diagram by importing them. For illustration here we have decided to orchestrate the calls to the EJBs with a BPEL process (“OrchestrateInvoiceData”). In order to compose the data structure needed for the AIS response some additional logic is required in addition to the EJBs. In this example we have implemented the additional logic as a simple local Java component within the SCA module (ShippingService) – however it could well have been an SCA import from some further module that may have had a Mediation flow calling out to one or more other endpoint services. The important point is that the BPEL process is surfacing our AIS service by providing a new composite service made up of many existing lower level technical atomic services.

Figure 13. SCA assembly diagram
SCA assembly diagram

(See a larger version of Figure 13.)

BPEL implementation

The BPEL implementation itself is a relatively straightforward micro-flow that involves a sequence of calls to the various provided services, as shown in Figure 14.

Figure 14. BPEL sequencing of calls to EJB operations
BPEL sequencing of calls to EJB operations

(See a larger version of Figure 14.)

Figure 15 shows the detail of one of the calls to the EJB services. In this case, we're using the getOrder operation of the OrderService EJBM (earlier you saw that the EJB exposed several operations; however this is the only one we need for our purposes). Notice also how the operations parameters on the EJB are mapped to variables within the BPEL process (for instance the Order POJO return type is mapped to a corresponding variable).

Figure 15. BPEL example of Invoke partner service
BPEL example of Invoke partner servic

In the next step in the BPEL process, shown in Figure 16, an Assign is used to map some parameters that are going to be needed in a subsequent Invoke of another partner service.

Figure 16. BPEL Assign
BPEL Assign

In the next step, a Java snippet, shown in Figure 17, is used to perform some simple mapping and data manipulation in order to complete the population of some specific data fields that are needed in the response object (the InvoiceDetails business object that was defined in Process Designer by the business author).

Figure 17. BPEL Java snippet
BPEL Java snippet

The last step in the process involves using another Assign to map the various data fields from various sources into the target InvoiceDetails structure, which will then be returned to the invoking service in the Reply. Figure 18 shows the Assign.

Figure 18. BPEL assign to construct AIS response
BPEL assign to construct AIS response

Note that we've used combinations of Java snippets and Assigns in the BPEL in this example for expedience. For a more reusable approach you would normally use data maps or even a call out to a mediation flow where the data mapping is visually constructed.

Toolkit implementation

Let's turn again to the toolkit that is now visible in the Integration Designer workspace. The Assembly Diagram in Figure 19 shows that the AIS Export is connected directly to an SCA Import, which corresponds to the Export previously shown in the SCA module.

Figure 19. Toolkit implementation delegates to SCA module
Toolkit implementation delegates to SCA module

The toolkit implementation is extremely lightweight – effectively delegating to the real implementation in the separate SCA module. This reduces the overhead of Process Center having to manage a lot of technical detail in the implementation module that is not appropriate to be surfaced to the BPM layer.

Consume AIS in the business process

In order to demonstrate that all the pieces work together, in Process Designer a simple illustrative BPD has been provided in the toolkit, as shown in Figure 20. The BPD provides a human service to allow a user to enter the data to search against, then it calls the AIS as the implementation of a system lane service, and finally a further human service is used to display the resulting invoice that is returned from the AIS.

Figure 20. Example BPD invoking AIS in system lane
Example BPD invoking AIS in system lane

Solution installation and testing

In order to test the solution we've implemented, you now need to install the various components on the runtime environment. In this example, all components including the EJBs are installed on BPM Advanced; in a production environment the EJBs are more likely to be installed separately onto a WebSphere Application Server node and called using their remote interface from the SCA module running on BPM Advanced.

Installation of technical services components

Because the EJBs and SCA module are to be managed outside of the Process Center, they to be explicitly installed into the runtime server (as opposed to the toolkit, in which the current or version is active and ready to be tested on the Process Center server). First you can install the EARs containing the EJBs using the WebSphere administrative console (you could also use the wsadmin command scripting environment if you prefer). The EAR files would have been exported out of the Integration Designer workspace in order to allow them to be installed onto the server (versions of the EAR files for both V8 and V7.5.1 of BPM Advanced are provided for download in the zip file included with this article).

Figure 21 shows the Enterprise Applications section of the administration console, where existing enterprise applications are listed and you can install additional ones.

Figure 21. Administration console showing enterprise applications
Administration console showing enterprise applications

Figure 22 shows the summary of the installation wizard before installing the first EAR file (in this example, the CustomerEJB EAR file).

Figure 22. Example of an enterprise application installation wizard
Example of an enterprise application installation wizard

(See a larger version of Figure 22.)

After installing the enterprise application containing an EJB, the console output should look similar to Figure 23. Next you can start the enterprise application so that the EJB contained in it is available to receive requests. For the example scenario, you need to repeat the process to install the other enterprise application (OrderEJB EAR).

Figure 23. Console showing enterprise application successfully installed
Console showing enterprise application successfully installed

(See a larger version of Figure 23.)

The SCA module is also exported from Installation Designer and you should install it into BPM Advanced using the WebSphere administration console. Figure 24 shows the output from the console when the installation has succeeded (the supplied EAR is OrderSCAClient_8_0.EAR or OrderSCAClient_7_5_1.EAR depending on your product version).

Figure 24. Console showing SCA module successfully installed
Console showing SCA module successfully installed

(See a larger version of Figure 24.)

Start this SCA module as you did with the enterprise applications so that it is available to serve requests. You can either start the EAR in the enterprise applications or you can access the SCA module and start it as shown in Figure 25.

Figure 25. Start SCA module
Start SCA module

(See a larger version of Figure 25.)

Executing a process invoking the AIS

Now that all the back-end components are installed and started, you can run an end-to-end test to prove the AIS connects to the EJBs via the SCA module and BPEL micro-flow. Figure 26 shows the Process Inspector view of Process Designer, showing the completion of the first human service with some sample values.

Figure 26. Process Inspector view showing search criteria provided
Process Inspector view showing search criteria provided

(See a larger version of Figure 26.)

After completing the initial human service, the process then invokes the AIS and provides the result data to the next human service. The Coach displays the results of the invoice data that was fetched from the BPEL (and in turn the EJBs), as shown in Figure 27.

Figure 27. Process Inspector showing data returned from AIS call
Process Inspector showing data returned from AIS call

(See a larger version of Figure 27.)

You've now successfully executed the end-to-end scenario for a BPD process through an AIS to a BPEL micro-flow orchestrating calls to some EJBs.


This article described a logical architectural layering and separation of concerns between business processes in the BPM layer and provided SOA services. It introduced how to implement such an architecture in BPM Advanced, focusing on managing the correct level of detail in the correct tool using Process Designer and Integration Designer.

The article presented a detailed working scenario supported by an executable solution that demonstrated the role of AIS in providing the link between business processes and aggregations of lower-level technical services.


The author would like to thank Andy Garratt for his valuable review and contributions to this article. Andy is a Certified Consulting IT Specialist and the United Kingdom and Ireland BPM Practice Lead in IBM Software Services for WebSphere.


Sample solution filesAISExemplarSource.zip1.6MB



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into Business process management on developerWorks

Zone=Business process management, WebSphere
ArticleTitle=Linking business processes and enterprise services together using IBM Business Process Manager Advanced