WebSphere consultant Paul Pacholski answers your questions on using WebSphere Integration Developer v6.0 to build, test, debug, and deploy integration solutions. WebSphere Integration Developer is an Eclipse-based tool for developing integration solutions that deploy to WebSphere Process Server and WebSphere Enterprise Service Bus. For more information, see the developerWorks WebSphere Business Integration zone and the WebSphere Process Server and WebSphere Integration Developer resource page.
Question: How do you write a small simple Java™ snippet in WebSphere Integration Developer, like the addition of two numbers?
Answer: A Visual Snippet for adding two numbers of type "double" already exists in the Visual Snippets folder as shown in Figure 1.
Figure 1. Visual Snippet folder
You can also easily create your own version. Suppose you want to create a Java Snippet, my_add, to add two numbers of type "int". Here are the steps to do this:
- Use the New Wizard and select Custom Visual Snippet as shown in Figure 2.
Figure 2. New Wizard
- Next, enter Visual Snippet details as shown in Figure 3.
Figure 3. Visual Snippet details
- When you click Finish, two things will happen:
- The my_add snippet will open in the Visual Snippet Editor.
- It will also appear in the Visual Snippet folder as shown in Figure 4.
Figure 4. my_add snippet
- In the Visual Snippet Editor, first create input and output variables of type "int" as shown
in Figure 5.
Figure 5. Input and output variables
- Next, you need to build the logic for the my_add Customer Visual Snippet:
- From the palette, drag and drop Expression Primitive.
- In the expression, type
num1 + num2.
- Drag and drop the Return primitive.
- Connect the expression "num1 + num2" to "return".
Figure 6. Connecting the expressions
- You can use the custom Visual Snippet in any component. For example, Figure 7 shows where you can use the
my_add Custom Visual Snippet in a BPEL Process component to implement the addition of two numbers in a
BPEL Java Snippet.
Figure 7. Add Process for two numbers
Question: Please explain the differences between the products IBM Rational Application Developer and WebSphere Integration Developer. I'm working both as a Java and an integration developer. I want to develop and wrap some EJB Session beans as Web services, and then finally link them together with BPEL. Should I use both products or just Integration Developer?
Answer: WebSphere Integration Developer (hereafter called Integration Developer) is almost a superset of Rational Application Developer. Some of the features of the Rational Developer that are not available in the Integration Developer are listed below:
- EGL (Enterprise Generation Language) Development
- IBM WebSphere Portal Development
- Ability to generate Java Beans from JCA Adapters. Instead, Integration Developer generates Service Component Architecture (SCA) components from JCA Adapters.
- Integrated WebSphere Test Environments and Integrated WebSphere Portal test environments. Integration Developer includes only WebSphere Process Server and WebSphere Enterprise Services Bus Test environments.
To develop an EJB Session bean and expose it as a Web service, you can use Integration Developer. First, enable Web services and EJB "capabilities" in Integration Developer. To do this, select from the main menu bar Windows -> Preferences -> Workbench -> Capabilities, and then select the Advanced J2EE capability as shown in Figure 8.
Figure 8. Advanced J2EE capability
This action enables the J2EE and the Web perspective provided by the Application Developer. Once you develop the Web Service, drag and drop the WSDL file anywhere in the Navigator view of the Business Integration perspective. Suppose you drop a WSDL file polyglot.wsld as shown in Figure 9.
Figure 9. Drag and drop the WSDL file
This action creates several artifacts:
- The Polyglot Interface
- The business objects, one for the Web service input (Input) and one for Web service output (Output)
- The Web Service Port.
To use the Web Service from your BPEL process, drag and drop the Polyglot Web Service Port to the Assembly Editor. This creates a Web Service Import Component. To invoke the Polyglot Web Service from your BPEL process, wire the BPEL Process Component to the Web Service Import Component as shown in Figure 10.
Figure 10. Wiring the components
Question: WebSphere Process Server solutions built with Integration Developer can access SCA native components such as process, rule group, or state machine. Which external services can I access from SCA native components?
Answer: Using an appropriate binding, you can wire external services to SCA components via Component Imports to reuse the following IT asset types:
- Enterprise Java Beans
- Java classes
- Web services (JSR 109/JAX-RPS based)
- WebSphere Adapters (J2EE JCA 1.5)
- All Adapters that are J2EE JCA 1.0 or 1.5 level
- WebSphere Business Integration Adapters
- JMS messages
Integration Developer tools assist programmers in creating the Component Imports. For example, by leveraging WebSphere Adapters, the Enterprise Service Discovery Wizard (as shown in Figure 10a) can introspect a "live" EIS system, and generate business objects, interfaces, and component imports and exports.
Figure 10a. Enterprise Service Discovery Wizard
Question: Integration Developer offers two types of implementation types for defining business processes: BPEL and state machine. What criteria should I use to choose between these two business process implementation types?
Answer: You should use the BPEL process when most steps in the process are sequential, with only limited number of loops or event handlers. Loops and event handlers usually imply that the control flow is going back, which suggests that state machine is a more suitable implementation.
Use the state machine implementation if the process logic is event driven. Specifically, if your BPEL implementation requires more than one Receive activity, and you start defining correlation sets, then seriously consider a state machine implementation. If your process logic is heavily event-driven and handling of these events is state dependent (different depending on where you are in the process logic) and the process logic can revert back to executed activities, then definitely use state machine.
For example, examine the Vending Machine state machine as shown in Figure 11.
Figure 11. Vending machine state machine
Note that the process logic is heavily event driven. Note that the process reverts to previous states (Depositing to Idle states) and that event handling is state dependent (deposit event can be received in both Idle and Depositing states).
Question: Integration Developer provides tools for implementing different component types. One of the component types is the human task component. What are the functional specifications of the human task component?
Answer: A human task component implements a task done by a person. It represents the involvement of a person in a business process.
Occasionally, people need to intervene in a business process. For example, a customer wants to purchase an item that is above his or her credit limit. A human task lets you intervene and override a business rule that prevents the customer from making the purchase. The human task component recognizes the reality that many processes require human intervention for tasks like reviewing, researching, and approving.
The human task component enables people to become involved in both business processes (BPEL and state machine) and in arbitrary service choreographies (invoking a human task from a business rule). A human task has several attributes, such as setting the owner of the task, and providing an escalation process in the case where the human specified is not available.
There are four types of human tasks:
- A participating task (Machine to Human – M2H) is a human interaction that is invoked from another service
as shown in Figure 12.
Figure 12. Machine to Human task
A M2H task is invoked by a client asynchronously. When a request arrives, the task starts in the ready state. The potential owner can see ready tasks on their work lists. When a potential owner checks out the task to work on it, the task state changes to "claimed", and the task disappears from other potential owners' work lists. While working on a task, the user may choose to save its state. Upon completion, the Human Task Manager responds to the task's caller indicating that the task is finished.
- An originating task (Human to Machine – H2M) is a human interaction that invokes another service.
Figure 13. Human to Machine task
A H2M task is a client component that asynchronously invokes long-running services. After a task is created, a user obtains its instance ID for subsequent communication with it. Starting the task also sends a request to start the long running service with which the task is associated. The user can either poll the task's state using the Instance ID, or await a notification returning the result of a finished task.
- A purely human task (Human to Human – H2H) is a service component that is originated by, and received from a
person. Often a person creates an H2H task for one or more persons to perform, commonly in an ad-hoc style without
prior installation or deployment. For example, an employee creates an H2H task to request a travel approval from his
or her manager.
Figure 14. Human to Human task
- An administrative task is created by components that want to offer an interface for a human administrator. An
example is a long-running business process that, once created, wants to give a dedicated set of users
the right to perform administrative actions such as suspend, resume, and repair on it.
Associated with the work item concept is the capability to manage staff directory. Human task manager supports LDAP, WebSphere member manager (when used together with WebSphere Portal), and WebSphere user registry out of the box.
There is a Web client, the Business Process Choreographer Explorer, that allows you to interact with tasks, such as working with tasks assigned to you, or to manage and repair tasks.
Question: Which features of WebSphere Process Server enable changes to a solution to be made dynamically without having to recompile or republish?
Answer: Both the Selector and Business Rule components add dynamicity to WebSphere Process Server (hereafter called Process Server) solutions.
The Selector component provides a selection mechanism for invoking components that have the same interface. The component selection mechanism is based on some defined set of criteria, data or logic (such as current date and time). More importantly, the components are invoked using a late binding approach. Using a special user interface in the Process Server Admin Console, you can dynamically update the Selector Component. For example, you can add or change the invocation target, or update the invocation selection criteria. You can then export these changes from the runtime and move them back into the Integration Developer project, if required.
The Business Rule Group component is a collection of related business rules, which you can express as decision tables or if-then rule sets. Using Integration Developer's Business Rule Editor, you define the business rules and design a user interface to expose the rules at runtime for dynamic updates. At runtime, using the Business Rules Manager application, you can change, add, or delete business rules without stopping and republishing the client application that uses the business rules. You can export these changes from the runtime and move them back into the Integration Developer project, if required.
Question: WebSphere Integration Developer provides an overall authoring experience for developers and integration specialists, including a unit test and debugging environment. What are the key features and functions of the unit test environment?
Answer: In Integration Developer, you can use the integration test client to test your modules and components and report the results of your test. All testing is performed on the interface operations of your components, which allows you to determine whether the components are correctly implemented and the references are correctly wired. The test client features a sophisticated user interface that allows you to easily manage and precisely control your tests.
To test a component, from the Detailed Properties pane:
- Select Module -> component -> interface -> operation. Next, in the Initial request parameter pane,
enter the input data and click Continue.
Figure 15. Testing a component
- The test client automatically deploys the selected module to the integrated test environment runtime support for
Process Server, and invokes the component via the selected interface and operation. The results are displayed in
the Events pane and in the Return parameters pane as shown in Figure 16.
Figure 16. Test results
The Events pane displays a hierarchal execution trace for the events that are generated during a test. For each executed operation, there is a request and response entry. The test client allows you to examine the input and output parameters associated with an executed operation. For example, if you click the Response or Return entry in the Events page, the Return parameters page containing the returned business object is displayed.
Question: WebSphere Integration Developer provides an overall authoring experience for developers and integration specialists, including a unit test and debugging environment. What are the key features and functions of the debugging environment?
Answer: In Integration Developer, using the integration debugger, you can visually debug local or remote business integration components, such as business object data maps, business processes, state machines, mediation flows, business rule sets, decision tables, and visual snippets. The integration debugger is primarily controlled from the Debug perspective as shown in Figure 17.
Figure 17. Debug perspective
- Debug View Toolbar: The toolbar contains buttons that control execution flow logic in a component. You can step into, step over, or step out of various elements in a component instance.
- Variable View: This view displays the values of the variables in the selected component. For example, in the case of the Process components, the variables view shows the BPEL variables and Partner Links.
- Variable Editor: While stopped on a breakpoint, you change the values of component variables.
- Breakpoint View: The Breakpoints view lists all the breakpoints you have set in the component. You can double-click a breakpoint to display its location in the editor. You can also enable or disable breakpoints, delete them, or add new ones.
- Process Editor: In a component editor you can add, disable, enable, or remove breakpoints. For example, in the Process Editor, you can control breakpoints on the BPEL elements in your process.
- Breakpoint: You can set breakpoints component editors either before or after the execution of the breakpoint target. During the execution, when a breakpoint location in the component's logic is reached, the execution is stopped. You can then use the component's debugger perspective to examine the state of your component.
Question: How can applications that are not defined as SCA components (for example, JavaServer Pages) invoke SCA components?
Answer: They do so through the use of the stand-alone references. Stand-alone references have the practical value of allowing you to use your existing applications together with SCA components created in Integration Developer. SCA components are packaged in SCA service modules. An SCA module is not just another type of package. In WebSphere Process Server, an SCA service module is equivalent to a J2EE EAR file. A non-SCA application can invoke a SCA component using the SCA API, providing that it is packaged in the same J2EE EAR as the SCA component.
Suppose a JSP, packaged in a Dynamic Web Project (JSPWAR), needs to invoke an SCA component. Here are the steps to do this:
- Create the Dynamic Web Project JSPWAR.
- From the Business Integration perspective, open the Module Dependency Editor. Add the WAR file as a J2EE
Figure 18. Adding a WAR file
- In the Assembly Editor and the Stand-alone Reference to the SCA components, invoke from your JSP.
Figure 19. Assembly Editor
- Open the Properties page of the Stand-alone Reference to note the reference name and the operation name.
Figure 20. Properties page
- In the JSP, use the SCA API to invoke the SCA component. The code should look similar to the code shown in Figure 21.
Figure 21. SCA component
Question: In WebSphere Integration Developer, a long-running process component is implemented as BPEL processes. Typically, long running-process instances may run for hours, days, or even months. What if we need to change our logic to support a business need? What will happen to the process instances that were "in-flight" when we made the change?
Answer: WebSphere Process Server and Integration Developer provide a simple and elegant solution: process versioning. Process versioning allows you to keep multiple definitions of an existing process template. Process Server uses the process template to start process instances. Existing instances will continue to run according to their original process template, whereas new instances will pick up the new definition.
In Process Server, versioning is done through the concept of the Valid From date. Process Server uses the Valid From date to decide which deployed versions of the process template to use when creating a new process instance. More importantly, once the instance is created, it runs against that version of the template, regardless of when other versions of the process template are subsequently deployed.
To understand the concept versioning, lets examine the following scenario.
- Suppose we created and deployed a process template called "Process" with the Valid From date of Apr 01, 2006 19:22:39.
Figure 22 shows the BPEL Editor in Integration Developer.
Figure 22. BPEL Editor
- Next, deploy the process component to the Process Server. Since the Valid From date of 4/1/06 1:22:39 is earlier
than the current date of Apr 08, 2006, the above template is used for starting new instances of Process.
Figure 23 shows the My Process Templates page in the Business Process Explorer console.
Figure 23. My Process Template page
- Use this process template to start three instances of Process.
Examining the Business Process Explorer console, you see three active instances as shown in Figure 24.
Figure 24. Process Instance List
- Create a new version of the process with the Valid From date of Apr 08, 2006 01:23:16.
Figure 25 shows the BPEL Editor in Integration Developer.
Figure 25. BPEL Editor
- Deploy the new version of the process to the Process Server.
Examining the Business Process Explorer console, you see that only the newer version of the process template, Process,
is available for starting new instances. Note the Valid From date of 4/7/06 9:23:16 PM.
Figure 26. New process template
Since the date example is 4/9/26 2:45:29 PM, all new instances will be started with the new process template, while the three running instances will continue to execute with the same template they started with.
- Learn about WebSphere Integration Developer in IBM WebSphere Developer Technical Journal: A guided tour of WebSphere Integration Developer -- Part 1.
- Learn how to build a complete working sample of a BPEL application in Develop a comprehensive BPEL application using service-oriented architecture with IBM WebSphere Business Integration products, Part 1: Business modeling.
- Learn how to develop WebSphere Process Server applications and manage resources in Team development with WebSphere Integration Developer and WebSphere Process Server: Developing applications using CVS.
- Find product information and other resources on the WebSphere Integration Developer site.
- Visit the developerWorks WebSphere Business Integration zone for technical and how-to information.
- Visit the developerWorks WebSphere Process Server and WebSphere Integration Developer resource page for technical resources.
- Participate in the developerWorks WebSphere Integration Developer discussion forum.
- Participate in the developerWorks WebSphere Process Server discussion forum.