Working with Split-Join

This section provides instructions for creating and configuring Split-Joins. Following are the primary topics in this section:

Introduction to Split-Join

The Split-Join is a mediation pattern that can be used by a transport typed business service in an Oracle Service Bus message flow. Split-Join allows you to send message requests to multiple services concurrently, thus enhancing performance in comparison to sending them sequentially. Split-Join achieves this task by splitting an input message into individual messages, routing them concurrently to their destinations, and then aggregating the responses into one overall message.

You design a Split-Join in the Workshop for WebLogic Split-Join editor, then export it to the Oracle Service Bus console for testing and production.

There are two types of Split-Join pattern: static Split-Join and dynamic Split-Join, as described in Designing a Split-Join.

For more information on invoking a business service from an Oracle Service Bus message flow, see Proxy Services: Message Flow in the Oracle Service Bus console help system.

Designing a Split-Join

There are two Split-Join patterns, the Static Split-Join and the Dynamic Split Join.

The Static Split-Join can be used to create a fixed number of message requests (as opposed to an unknown number). For instance, a customer places an order for a cable package that includes three separate services: internet service, TV service, and telephone service. In the Static use case, you could execute all three requests in separate parallel branches to improve performance time over the standard sequential execution.

The Dynamic Split-Join can be used to create a variable number of message requests. For instance, a retailer places a batch order containing a variable number of individual purchase orders. In the Dynamic use case, you could parse the batch order and create a separate message request for each purchase. Like the Static use case, these messages can then be executed in parallel for improved performance.

Initial Setup

Split-Joins potentially include the following tasks as part of their initial setup:

Creating/Importing a WSDL Containing the Base Operation

Every Split-Join is based upon a WSDL operation. When you first create a Split-Join, you will be asked to browse to the appropriate WSDL file and to select this operation as part of the creation process. You can create this WSDL file in Workshop for WebLogic.

Creating/Importing a Business Service to Use the Split-Join

Every Split-Join will be used by a transport typed business service, which, in turn, is invoked by a proxy service. You cannot export or test your Split-Join until you have created this business service. If it already exists, you can import it into Workshop for WebLogic, or, if it does not exist, you can create it in Workshop for WebLogic or the Oracle Service Bus console. If you want to get started on your Split-Join before you create the business service, you can generate the business service automatically after you create the Split-Join.

Designing a Static Split-Join

Suppose you want to design a new Split-Join called Service Availability that handles orders for a telco’s cable service package including TV, phone, and internet service. The idea is for the Split-Join to receive an incoming package order and to reply with an order acknowledgement for each type of service. In this case, Service Availability is designed as a Static Split-Join because there are three message requests per order, one for each type of service. In this particular example the customer requests only TV and DSL service.

Creating the Service Availability Split-Join may include the following tasks:

1. Creating a New Split-Join

2. Adding an Assign

3. Adding a Parallel Node

4. Adding an Assign for Each Branch

5. Adding an Invoke Service

6. Adding an Assign for Each Branch

7. Exporting and Testing the Split-Join

1. Creating a New Split-Join

Create a new Split Join based on the WSDL operation you want to use for placing the order. In this case the WSDL operation we want is called “telecom.”

After you select the WSDL operation, a skeleton of the newly created Split-Join appears in the Split-Join editor, as shown in the following figure. It consists of a Start Node, a Receive, a Reply. The labels are then edited in the general properties tab to better reflect the specific function of each node in this particular Split-Join.

The Start Node contains both a Request Variable and a Response Variable that have been determined by the WSDL operation initially selected. The Receive receives the incoming request message (in this case for the three or fewer different kinds of cable service), and the Reply generates a response message and sends it back to the client.

2. Adding an Assign

The first Assign, Prepare Output Message, contains an Assign operation that prepares the Response Variable in a form such that the later nodes can work on the data within it (that is, Copy/Insert/Assign/Replace/Delete/Java Callout/Log the data). This output message is relayed to the final Reply node in the Split-Join and, in turn, returned to the original client.

3. Adding a Parallel Node

The Parallel Node contains two main branches, one to check cable TV availability and one to check DSL availability. Each branch is composed of a number of actions, the sequence and general configuration being the same for both branches.

4. Adding an Assign for Each Branch

The first Assign in each Parallel Branch, Prepare Input Address, copies the incoming customer address data into a Variable that is referenced to check the availability of the service at that location. The Assigns are the same for each branch and would be for additional branches as well.

5. Adding an Invoke Service

An External Service is then invoked to check whether the requested service type is available at the customer’s location. Each branch contains one Invoke Service, Check Cable TV Availability and Check DSL Availability. Each invocation calls an External Service, which compares the customer’s address (stored in the Variable initialized in the previous step) to the availability of the service at that location. The result is then stored in an output Variable that is passed on to the final Assign in the Branch below.

6. Adding an Assign for Each Branch

The final two Assigns, Update Cable TV Status in Output Message and Update DSL Status in Output Message, take the results of the external service invocations and put them into the output message using a Replace operation. The aggregated response are then sent to the original client in the final Reply node, which requires no further configuration.

7. Exporting and Testing the Split-Join

After you design the Split-Join, you can export it to the Oracle Service Bus console for testing and production.

Related Topics

Designing a Dynamic Split-Join

Suppose that you want to design a Split-Join that handles a batch order from a retailer containing a variable number of individual purchase orders (as opposed to a fixed number of orders). The idea is for the Split-Join to receive the batch order and to reply with an order acknowledgement for each order within. This would be a Dynamic Split-Join because the number of individual purchase order requests is variable and unknown at design time.

Creating this Split-Join may include the following tasks:

1. Creating a New Split-Join

2. Adding an Assign

3. Adding a For Each

4. Adding an Assign

5. Adding an Invoke Service

6. Adding an Assign

7. Adding an Error Handler

8. Exporting and Testing the Split-Join

1. Creating a New Split-Join

Create a new Split Join based off of the WSDL operation you want to use for placing the order. In this case the WSDL operation we want is called “batchOrders.”

After the operation is selected, a skeleton of the newly created Split-Join appears in the Split-Join editor consisting of a Start Node, a Receive, a Reply. The labels are then edited in the general properties tab to better reflect the specific function of each node in this particular Split-Join.

The Start Node, Order Placement, contains both a request variable, inputVar, and an response variable, outputVar. The Receive, Receive Batch Order Request, will initialize the contents of the Request Variable (in this case purchase orders), and the Reply, Reply Order Placement, will send a response, based on the order acknowledgements aggregated into the Response Variable, back to the client. In this example Order Placement also contains a callout to an External Service, “Order” that will be invoked to approve individual orders.

2. Adding an Assign

The first Assign, Prepare Output Message, contains an Assign operation that prepares the response variable (here labeled an “Output Message” for readability) in a form such that the later nodes can work on the data captured within it (that is, Copy/Insert/Assign/Replace/Delete into the Variable). In this case, that data would consist of order acknowledgments and/or errors.This Output Message is relayed to the final Reply node in the Split-Join and, in turn, returned to the original client.

3. Adding a For Each

The For Each, Iterate Through Orders, contains logic that will parse through each order in the batch, send it to an external proxy for approval, and capture an order acknowledgment in response. If there is a problem with an order, an error is sent from the invoked proxy and captured in the Error Handler. The following figure depicts the entire scope of the For Each logic.

4. Adding an Assign

The Assign, Prepare Purchase Order, copies the incoming purchase order requests into a variable that is referenced to check approval of the order in the next step.

5. Adding an Invoke Service

An external service, Check Order Availability, is then invoked to approve each individual purchase order. If the order is accepted, the service responds with an order acknowledgment. If the order is not accepted, the service responds with an error.The result is then stored in an output variable that is passed on to the final Assign in the next step.

6. Adding an Assign

The final Assign, Update Order Status in Output Message, takes the results of the external service invocation and copies them into the output message using an Insert operation. The aggregated response is then sent to the original client in the final Reply node, which requires no further configuration.

7. Adding an Error Handler

The Error Handler captures any Errors returned by the invoked service. It takes these errors and inserts them into the output message using an Assign operation.

8. Exporting and Testing the Split-Join

After you design the Split-Join, you can export it to the Oracle Service Bus console for testing and production.

Related Topics

Creating a New Split-Join

In order to create a new Split/Join, you must have access to a WSDL containing the operation upon which to base the Split-Join. The Split Join must be created in an existing Oracle Service Bus project within an existing Oracle Service Bus configuration project.

To create a new Split-Join:

A basic Split-Join is created and visually represented as a diagram in the Design View. By default, it consists of a Start Node, a Receive, and a Reply. The Start Node contains the Request and Response Variables introspected from the WSDL operation. The Receive is used to receive incoming request messages. The Reply is used to send response messages.

Related Topics

Configuring the Start Node

The Start Node is generated automatically whenever you create a new Split-Join. It is the starting point from which all the other nodes proceed. Configuring a Start Node can include the following tasks:

Related Topics

Adding General Information

General information is useful for making a node more legible. It includes the ability to add a unique identifier, or Label, to the node and to supplement it with notes, or Documentation. General information is optional.

Defining Global Variables

Variables in the Start Node store data that can be referenced globally, that is by any node in the Split-Join. By default, every Start Node is assigned both a request and a response variable when the Split-Join is initially created. From the Start Node, you can either create a new global variable or edit an existing global variable.

To create a new global variable:

If it is not already open, expand the content area to the left by clicking the arrow to the left of the Start Node icon. The newly created variable appears in the Variables field along with any other global variables. To view the details of any variable, simply select it and its structure will appear in the Properties view.

To edit an existing global Variable:

If it is not already open, expand the content area to the left of the Start Node icon. The newly created variable appears in the Variables field along with any other global variables. To view the details of any variable, simply select it and its structure will appear in the Properties view.

Viewing External Services

The External Services listed in the Start Node are those invoked outside of the context of the Split-Join. They are specified in an Invoke Service but listed here for convenience.

To view External Services, expand the content area to the left of the Start Node by clicking the arrow to the left of the Start Node icon. When an External Service is selected, a dashed blue arrow appears pointing to the Invoke Service associated with the service, and the service’s location appears in the Properties view.

Configuring a Receive

A Receive is generated automatically whenever you create a new Split-Join. The purpose of the Receive is to place incoming request data in a variable and make the contents available for later nodes to use. Configuring a Receive can include the following tasks:

Related Topics

Viewing the Operation

The Operation is based upon the initial WSDL selection for the overall Split-Join. It is displayed in the Properties View for reference.

Defining the Receive Variable

You must define the Incoming Message Variable the Receive will initialize.

Note that Message Type Namespace and Message Type are displayed automatically on the Properties page once the variable is defined.

Adding General Information

General information is useful for making a node more legible. It includes the ability to add a unique identifier, or Label, to the node and to supplement it with notes, or Documentation. General information is optional.

Creating an Assign

The Assign is used for data-manipulation including initializing and updating a variable. It is composed of a set of one or more operations that can be added from the Assign toolbar. Configuring an Assign can include the following tasks:

Related Topics

Adding and Configuring Assign Operations

Assign operations include Assign, Copy, Delete, Insert, Java Callout, Log, and Replace. Every Assign is composed of one or more of these operations, which you can add to the Assign using the Design Palette view.

A brief explanation of each operation follows:

Adding an Operation to an Assign

Adding an operation to the Assign involves the following steps:

You can edit an operation by selecting it and modifying the properties in the Properties view.

Adding a Copy Operation

The Copy operation lets you copy the information specified by an XPath 1.0 expression from a source document to a destination document. It is an operation unique to the Split-Join editor. Adding a Copy operation to the Assign involves the following steps:

Adding General Information

General information is useful for making a node more legible. It includes the ability to add a unique identifier, or Label, to the node and to supplement it with notes, or Documentation. General information is optional.

Invoking a Service

The Invoke Service is used to invoke external, WSDL-based business services, WSDL-based proxy services, and Split-Joins. Configuring an Invoke Service can include the following tasks:

Related Topics

Selecting an Operation

An operation must be selected upon which to base the Invoke Service. You must select this operation before you can configure Input and Output variables. To select an operation:

Defining Input and Output Variables

An Invoke Service requires both an Input Variable and an Output Variable, unless it is a one-way invocation. The procedure to configure these variables is essentially the same. Either type of variable can be global (that is, available within the entire Split-Join) or local (that is, available within a particular context Scope.) To define either an Input or Output variable:

To create a new Message Variable:

Message Type Namespace and Message Type are displayed automatically on the Properties view once a variable is defined.

Adding General Information

General information is useful for making a node more legible. It includes the ability to add a unique identifier, or Label, to the node and to supplement it with notes, or Documentation. General information is optional.

Creating a Parallel

The Parallel creates a fixed number of configured parallel branches. Each branch has its own Scope which in turn can contain any number of nodes. Configuring a Parallel can include the following tasks:

Related Topics

Adding Nodes

The Parallel is essentially a placeholder for a fixed number of processing branches, each with its own scope. Two branches are automatically generated by default. An individual scope may contain unique processing logic according to your construction; simply drag the appropriate nodes into the Scope. You may add additional branches with the Add Scope button.

Adding General Information

General information is useful for making a node more legible. It includes the ability to add a unique identifier, or Label, to the node and to supplement it with notes, or Documentation. General information is optional.

Creating a For Each

The For Each is used to create conditional logic for iterating through a variable number of requests. It is primarily used to create dynamic Split-Joins. Configuring a For Each can include the following tasks:

Related Topics

Defining the For Each Logic

To define the For Each logic:

Adding General Information

General information is useful for making a node more legible. It includes the ability to add a unique identifier, or Label, to the node and to supplement it with notes, or Documentation. General information is optional.

Creating an If Activity

The If Activity is used to provide conditional logic within a Split-Join. It is composed of a number of nodes that determine the behavior for the overall If activity. Each node must be individually configured. When you create an If activity, an If and an Else are automatically generated within it. You can add an unlimited number of Else If nodes with the Add Else If button.

Configuring an If Activity can include the following tasks:

Related Topics

Configuring the If

The If provides a unit of conditional logic within the overall If activity. It is automatically generated when you create an If activity. Configuring an If can include the following tasks:

Related Topics

Writing the logic of the condition

The If Activity executes conditional logic defined by an XPath 1.0 expression. Enter this condition in the Condition text field of the Condition tab, or click the browse button to launch and write the expression in the expression builder.

Adding resulting nodes

If the condition in the If logic is met, a subsequent node or string of nodes will result. Add and configure any resulting nodes by dragging them in sequential order to a drop point beneath the If icon.

Adding General Information

General information is useful for making a node more legible. It includes the ability to add a unique identifier, or Label, to the node and to supplement it with notes, or Documentation. General information is optional.

Adding and Configuring Else If

The Else If is used to provide additional logic within the context of an overall If. You can add an Else If every time you press the “Add Else If” button.

Configuring an Else If can include the following tasks:

Related Topics

Writing the Logic of the Condition

The Else If uses conditional logic defined by an XPath 1.0 expression. Enter this condition in the Condition text field of the Condition tab or click the browse button to launch and write the expression in the expression builder.

Adding Resulting Nodes

If the condition in the Else If logic is met, a subsequent node or string of nodes will result. Add and configure any resulting nodes by dragging them in sequential order to a drop point beneath the Else If icon.

Adding General Information

General information is useful for making a node more legible. It includes the ability to add a unique identifier, or Label, to the node and to supplement it with notes, or Documentation. General information is optional.

Configuring the Else

The Else provides a final case of logic within the context of an overall If. It is automatically generated when an If is created. Configuring an Else can include the following tasks:

Related Topics

Adding Resulting Nodes

As the final case in the If’s logic, the Else requires no conditions to be met in order to execute. It will automatically execute resulting activities when invoked. Add and configure any resulting nodes by dragging them in sequential order to a drop point beneath the Else icon.

Adding General Information

General information is useful for making a node more legible. It includes the ability to add a unique identifier, or Label, to the node and to supplement it with notes, or Documentation. General information is optional.

Creating an Error Handler

The Error Handler receives and handles errors. If it is attached to a Start Node, it is a “global” Error Handler and serves as a catch-all for the output of all local Raise Error nodes. If it is attached to a Scope, it only handles errors raised locally. To create an Error Handler:

The basic Error Handler is now configured, but you may need to add additional Assign, If, and/or Reply nodes to it depending on whether you wish to execute logic upon the received faults before sending a response.

Related Topics

Creating a Raise Error

The Raise Error generates an error that causes the Split-Join to stop normal processing. If the error is not handled using an Error Handler, the Split-Join will terminate and a Fault will be sent to the Oracle Service Bus message flow. Configuring a Raise Error can optionally include documenting the nature of the error in the General Information tab.

You can also add a Re-Raise Error operation to an Error Handler. Configuration involves modifying Label and adding Documentation.

Related Topics

General information is useful for making a node more legible. It includes the ability to add a unique identifier, or Label, to the node and to supplement it with developer notes, or Documentation. General information is optional.

Configuring a Reply

A global Reply is generated automatically whenever you create a new Split-Join. The purpose of the global Reply is to send a response back to the invoking Oracle Service Bus message flow. However, you may also create a Reply elsewhere in the Split-Join, including within Error Handlers. Configuring the Reply can include the following tasks:

Related Topics

Viewing the Operation

The operation is based upon the initial WSDL selection for the overall Split-Join. It is displayed in the Properties view for reference.

Defining the Reply Variable

The Reply can either send a Response or a Fault back to the client depending on how you configure the variable. The Fault options available vary depending upon whether the Reply is global or local.

Given the available options as outlined above, select either a Response or a Fault for your Reply Variable.

If you select Response, you must define the Message Variable the Response will be assigned to. This can be done in two ways:

To create a new Message Variable, select Create Message Variable from the Message Variable menu. The Create Message Variable Dialog appears:

Note that Message Type Namespace and Message Type are displayed automatically in the Properties view once the variable is defined.

If you select Fault, you must specify either a WSDL Fault or propagate a SOAP Fault.

If you select a WSDL Fault, you must specify the Fault by name and define the Message Variable that it will be assigned to.

To create a new Message Variable, select Create Message Variable from the Message Variable menu. The Create Message Variable Dialog opens:

Message Type Namespace and Message Type are displayed automatically on the properties page once a variable is defined.

If you select Propagate SOAP Fault, the SOAP Fault specified in the parent Error Handler will automatically be propagated in the Reply. There is nothing else to configure.

Adding General Information

General information is useful for making a node more legible. It includes the ability to add a unique identifier, or Label, to the node and to supplement it with notes, or Documentation. General information is optional.

About Scope

A Scope is a container that groups various elements together. The container creates a context that influences the behavior of its enclosed elements. Local Variables and the Error Handler defined within the Scope are restricted to this context. However, some nodes within the scope may operate both locally (that is, within the Scope) and globally (that is, outside of the Scope.) For instance, an Invoke Service within a certain Scope might call upon an service external to the Scope’s context.

Related Topics

Exporting and Testing a Split-Join

You can export and test a Split-Join on an Oracle Service Bus server provided that it is associated with a transport typed business service. Exporting and testing a Split-Join can include the following tasks:

Creating a Transport Typed Business Service

A Split-Join is used by a particular transport typed business service. If you do not have an appropriate business service, you must create one before you can export or test your Split-Join. There are two ways to create a business service:

After you create the business service, you can export the Split-Join provided that it has no errors.

Exporting the Split-Join Files

Split-Joins without errors can be exported to an Oracle Service Bus server.

There are three ways to export a Split-Join:

Exporting from the Business Service Menu

It is possible to export a Split-Join directly from the Business Service menu. However, because exporting by this method automatically launches the Oracle Service Bus Test Console, it is useful if you want to both export and test. Exporting from the Business Service menu involves the following steps:

Auto-export

A Split-Join can be auto-exported to an Oracle Service Bus server. If you use this method, you must manually launch the Oracle Service Bus console in order to test the exported files. Auto-exporting involves the following steps:

Manual export

A Split-Join can be manually exported to an Oracle Service Bus server. If you use this method, you must manually launch the Oracle Service Bus console to test the exported files. Manually exporting involves the following steps:

Testing the Split-Join in the Test Console

You can test a Split-Join by executing the business service that uses it in the Oracle Service Bus Test Console. This can either be done within the Split-Join editor or by exporting the Split-Join to an Oracle Service Bus server. To test the Split-Join within the IDE, you need to export the files using the menu for the business service that uses the Split-Join.

Exporting from the Business Service Menu

You can export and test a Split-Join directly from the Business Service menu. If you use this method, the export happens in the background while the Oracle Service Bus Test Console launches. Exporting from the Business Service menu involves the following steps:

Click Finish, and the Oracle Service Bus Test Console will launch. You can now test the business service.

Configuring Business Services using the HTTP Transport

You must select HTTP as the transport protocol when you configure any type of business service based on HTTP and the endpoint URI is of the form:

http://<host:port/someService>

where:

Table 1-2 describes all the parameters you can specify to configure HTTP transport for a business service.

For more information on how to configure this transport, see Transport Configuration in Using the Oracle Service Bus Console.

REST Support

The HTTP transport provides support for working with REST (Representational State Transfer) environments through Oracle Service Bus, whether you have REST clients that need to interact with non-REST service providers, non-REST clients that need to interact with REST-based service providers, or REST-to-REST services you want to expose through Oracle Service Bus.

In a REST pattern, you invoke HTTP methods (such as GET, PUT, HEAD, POST, and DELETE) on resources that are located at specific URLs. For example, when a user updates his own profile information in a Web application that uses REST, a POST action updates the user information in the database through the service’s REST API.

Oracle Service Bus provides the following placeholder variables for handling REST-based requests for inbound and outbound communication:

REST in Proxy Services

With an Oracle Service Bus proxy service, you have the flexibility to interact with REST patterns, whether you are receiving REST-based requests or generating REST-based actions.

For example, if your team wants to develop REST-based applications and invoke services in a non-REST service provider, you can send REST operations through a proxy service and transform those operations into a format the service provider understands; or you could transform a non-REST request into a resource URL and invoke an operation in a REST-based service provider.

XQuery Examples

Following are XQuery examples of URI parsing using HTTP variables in a proxy server.

Relative-URI

A proxy service has a URI http://localhost:7001/weather, and you want to capture the relative URI parts of a request. You create the following XQuery:

<relative-URI>

{

for $c in

fn:tokenize($inbound/ctx:transport/ctx:request/http:relative-URI, "/")

where fn:string-length($c) != 0

return

<part>

{$c}

</part>

}

</relative-URI>

If a request comes with the URI of http://localhost:7001/weather/temperature/35457, the relative-URI will be /temperature/35457, and the XQuery output will be:

<relative-URI>

    <part>temperature</part>

    <part>35457</part>

</relative-URI>

Query-String

A proxy service has a URI http://localhost:7001/weather, and you want to capture the URL query string. You create the following XQuery:

<query-params>

{

for $c in

fn:tokenize($inbound/ctx:transport/ctx:request/http:query-string, "&amp;")

return 

<param name="{fn:substring-before($c,"=")}"

value="{fn:substring-after($c,"=")}"></param>

}

</query-params>

If a request comes with a URI of http://server:7001/weather?operation=temperature&pincode=35457, the query-string will be operation=temperature&pincode=35457, and the XQuery output will be:

<query-params>

    <param name=’operation’ value=’temperature’/>

    <param name=’pincode’ value=’35457’/>

</query-params>

REST in Business Services

With an Oracle Service Bus business service, you can invoke REST-based services.

For REST operations, the HTTP transport uses the value in the $outbound/transport/request/http:http-method variable. If that variable does not supply an HTTP method, the HTTP transport lets you select one of the following HTTP Request Methods in the transport configuration: POST, PUT, HEAD, GET, AND DELETE.

Using the $outbound/transport/request-http/http-method variable, you can also supply your own methods. For example, you can use COPY, MOVE, and LOCK for WebDAV environments (Web-based Distributed Authoring and Versioning).

Use the following guidelines for setting $outbound variables:

Response Codes for HTTP Business Services

The HTTP transport provides the following response codes for HTTP methods:

Integrating PeopleSoft Integration Broker and Oracle Service Bus

By srikant.subramaniam on October 9, 2008 10:00 AM

Integrating PeopleSoft HCM with BPA Suite and SOA Suite

By srikant.subramaniam on February 17, 2009 2:14 PM

The tutorials will showcase these capabilities:

• Modeling a business process and exporting it to the development environment.
• Round trip integration between the modeling and the development environments.
• Creation of executable software and integration with the backend application.

Use Case

Consider a benefits enrollment process where an employee has a qualifying event (the birth of a child, for instance) and now needs to enroll this new born child for health benefits and also make changes to the employee's payroll withholding to account for the new dependent.

While a typical benefits enrollment is often more complex than the above description, this tutorial focuses on a simplified scenario to illustrate the principal concepts and for ease of implementation and demonstration.

The process model is setup to accept all the relevant information (Employee ID, payroll withholding information, dependent's name, birth date, etc) upfront. The appropriate business processes (Insert Dependents, Insert W4) are subsequently invoked using this input data.

Implementation

The figure below summarizes the interaction between the business analyst and the process developer. The business repository contains the shared metadata and helps to keep the modeling and the development environments in sync.

There are three distinct phases in the implementation process (click on the links below for detailed instructions):

• Step 1: Create the business process model using Oracle BPA Suite and generate the metadata (referred to as the process blueprint).
• Step 2: Use Oracle JDeveloper to generate the BPEL model from the previously created process blueprint; round trip integration between the modeling (Oracle BPA Suite) and the development (Oracle JDeveloper) environments.
• Step 3: Using Oracle JDeveloper, the BPEL partner links created in Step 2 are modified to invoke the corresponding PeopleSoft CI service and the appropriate BPEL artifacts are added to create the executable software. The BPEL project file that was used is available here.

  Additional information on generating a web service from the PeopleSoft CI is available at the PeopleSoft Best Practice Center.

Creating an Account in Siebel Using BPEL and Web Services

Purpose

This tutorial shows you how to create, deploy, and test a BPEL process to create customer accounts in a Siebel Application.

Time to Complete

Approximately 1 hour

Topics

This tutorial covers the following topics:

	Overview
	Prerequisites
	Log in to Siebel Call Center
	Generate WSDL for an Inbound Web Service
	Create,deploy, and test a BPEL Process to create a customer account in Siebel
	Log in to Siebel Call Center to view the new customer account created through the BPEL Process
	Summary

Viewing Screenshots

Place the cursor over this icon to load and view all the screenshots for this tutorial. (Caution: This action loads all screenshots simultaneously, so response time may be slow depending on your Internet connection.)

Note: Alternatively, you can place the cursor over an individual icon in the following steps to load and view only the screenshot associated with that step. You can hide an individual screenshot by clicking it.

Overview

Siebel applications are built on a rich technology stack, and have been supporting web services starting from version 7.5.3 . Major web services support came in version 7.8 and in 8.0 it was expanded to support numerous out of the box web services for Customer Order Management. Hence if you are working with any version later than 7.8, then you can typically use direct web services for integration. BPEL Process Manager is certified with Siebel v 7.8.2 onwards. This tutorial demonstrates how to use BPEL Process Manager to consume a Siebel generated WSDL to invoke an inbound Siebel Account Web Service (also known as Siebel ASI - Application Service Interface)

Back to Topic List

Prerequisites

Before you perform this tutorial, you should:

Back to Topic List

Log in to Siebel Call Center

Log in to Siebel Call Center using appropriate credentials. Perform the following steps:

Back to Topic List

Generate WSDL for an Inbound Web Service

In this topic, you select an inbound Web Service that exposes a Siebel account called Customer Account and generate WSDL for it. To do this, perform the following steps:

Back to Topic

In this topic, you create, deploy, and test a BPEL process. To do this, perform the following steps:

Back to Topic List

Create and Deploy a BPEL Process

In this topic, you learn to create a BPEL process and deploy it to the default Application Server connection. Perform the following steps:

	Prerequisites
	Create a BPEL Process
	Deploy a BPEL Process

Prerequisites:

Perform the following prerequisite steps:

Create a BPEL Process

In this task, you create a BPEL Process based on a .xsd file that contains structure of a Siebel customer account sample. You extracted this file from a previous step in this tutorial. Perform the following steps to complete this task:

	Create a BPEL Process
	Create a Partner Link
	Deploy an Invoke Activity
	Create a Transform Activity
	Create an Assign Activity

Create a BPEL Process

Create a Partner Link

In this task, you create a partner link that is based on the WSDL file generated from a Siebel Inbound Web service earlier in this tutorial. Perform the following steps to complete this task:

Create an Invoke Activity

Create a Transform Activity to Send Input Request Data to The Invoke activity

Create an Assign Activity to Send Output Data from the Invoke activity

Deploy and Test the BPEL Process

In this topic, you create a connections to an application server and to an Integration server to whcih you deploy your BPEL process and then test the process. To do this task, perform the following steps:

a. Create a Connection to the Application Server and to the Integration Server:

In this task, you create connection to the Integration server to which you deploy the BPEL process. This inturn requires a connection made to the Application Server where the SOA Suite is installed.

b. Deploy BPEL Process to the Integration Server:

In this topic, you deploy the BPEL Process SiebelCustomerAccount.bpel to the Integration Server SOAConnection. To complete this task, perform the following steps:

c. Test the deployed BPEL process using BPEL Control:

In this step you test the BPEL process created in this tutorial and enter details to insert a customer account through the BPEL Control. Perform the following tasks:

Back to Topic

Summary

In this tutorial, you learned how to:

	Generate a WSDL file from Siebel Call Center
	Create, deploy, and test a BPEL process to insert a Siebel customer account.

Improving Service Performance with Split-Join

Oracle Service Bus’s advanced mediation feature, called Split-Join, helps you improve service performance by concurrently processing individual messages in a request. This topic, which describes Split-Join, includes the following sections:

 Split-Join으로 불리는 OSB의 향상된 중개 특징은 요청에서 다발적으로 발생되는 각각의 메시지를 처리함으로서서비스 성능을 향상할수 있도록 도와줄 것이다. 이주제는 아래와 같은 두가지 섹션을 포함한다.

   - Split-Join의 소개

   - Split-Join의 개발

Introduction to Split-Join

Oracle Service Bus’s Split-Join feature lets you split a service payload, such as an order, into individual messages for concurrent processing. Concurrent processing, as opposed to sequential processing, greatly improves service performance. Split-Join achieves this task by splitting an input message payload into sub messages (split), routing them concurrently to their destinations, and aggregating the responses into one overall return message (join). This process of payload splitting and response aggregation is called a Split-Join pattern.

Split-Joins are particularly useful for optimizing overall response times in scenarios where payloads delivered by faster systems are being directed to responding services on slower systems. Without Split-Join, individual messages in a payload are normally resolved in sequential order by the recipient, which can take a long time if the responding system is slow. (The overall response time is the sum of the individual response times for each message.) With Split-Join, multiple messages are processed simultaneously, which reduces burden on the responding system and greatly enhances response times. (The overall response time is roughly that of the longest individual message’s response time plus some minor system overhead.)

There are two patterns supported by the Split-Join feature:

Static Split-Join

The static Split-Join branches from the main execution thread of an Oracle Service Bus message flow by splitting a payload into a fixed number of new branches according to the configuration of the Split-Join. At design time you determine the number and variety of services to be invoked.

Static Split-Join – Sample Scenario

A telco company might want to employ static Split-Join when processing a customer’s order for a communications services package. In this case, the customer might sign up for DSL and voice services all at once. Rather than executing each request in the payload separately in order, the telco can execute the messages in parallel using a callout from the Oracle Service Bus message flow to a Split-Join employing the static Split-Join pattern.

Static Split-Join is the ideal pattern in this case because the developer knows there will always be exactly two incoming service requests for this particular service package: DSL and voice. Splitting the requests into parallel branches allows them to be processed concurrently, which improves the overall response time for processing the payload. After all messages have been processed, the generated responses are aggregated back into one reply in the execution thread.

Figure 4-1 illustrates a static Split-Join that splits two known service requests, DSL activation and phone activation, processes each request in parallel, and joins the responses into a single reply.

Dynamic Split-Join

The dynamic Split-Join branches from the main execution thread of an Oracle Service Bus message flow by dynamically creating new branches according to the contents of the incoming payload. The dynamic Split-Join uses conditional logic to determine the number of branches to create. All requests are handled simultaneously, and the responses are aggregated into a single reply.

Dynamic Split-Join – Sample Scenario

A company might want to use dynamic Split-Join when placing automated stationery orders for its employees. If the orders are automatically placed every week based on employee submissions, there is no way of knowing how many individual orders are placed in any one weekly order. Rather than placing each order separately, the company could use dynamic Split-Join to place the orders concurrently using a callout from the Oracle Service Bus message flow to a Split-Join employing the dynamic Split-Join pattern.

Dynamic Split-Join is the ideal pattern in this case, because the developer has no way of knowing how many orders will be submitted each week. The dynamic Split-Join loops through all the orders and places them in parallel. The developer can also limit the number of orders processed. After all of the orders have been processed, the generated order responses are aggregated back into one reply in the execution thread.

Figure 4-2 illustrates a dynamic Split-Join that splits 15 orders, processes them concurrently, and joins the responses into a single reply.

Split-Join Framework

A Split-Join, which takes the form of a .flow file in Workshop for WebLogic, is based on a WSDL operation. The Split-Join is wrapped in a WSDL-based business service that communicates across a FLOW transport, which is a dedicated transport for Split-Joins. The business service is invoked from a proxy service. Figure 4-3 illustrates the Split-Join framework.

Developing Split-Joins

You create and configure Split-Joins in Workshop for WebLogic, then import them into the Oracle Service Bus Console for use in run-time configuration. For information on developing Split-Joins, see Working with Split-Join in the Workshop for WebLogic help system.

Split-Join Resource Type and Environment Variable

If you reference Split-Joins in any scripts or custom code, use the values in Table 4-1:

Using REST with Oracle Service Bus

By james.bayer on July 29, 2008 6:12 AM

{

   "Status":"Submitted",

   "OrderID":"123",

   "OrderDetailID":"345",

   "CustomerID":"234"

}

org.json.JSONObject j = org.json.XML.toJSONObject( xmlStringBuffer.toString() );

System.out.println( j.toString() );

SOA Archives

September 30, 2008

WS asynchrony models (BPEL Vs JAX-WS)

By Iñaki Martín on September 30, 2008 4:57 PM

• Introduction
• Asynchronous model implementations
• BPEL asynchronous model
• JAX-WS asynchronous model
• Adapting a JAX-WS WSDL for BPEL
• Adapting the portType definition
• Adapting the binding definition
• Adapting the service definition
• WS-Addressing
• Sending http://www.w3.org/2005/08/addressing WS-Addresing headers
• Receiving http://www.w3.org/2005/08/addressing WS-Addresing header in Oracle BPEL PM

Introduction

In the Web Services world an asynchonous call means sending a message to a remote service and then wait for it to send the response back to the caller

(a.k.a. callback). Talking in HTTP terms this means two different HTTP connections: one from the client to the service provider and the other from the

provider to the client. As the same client can call several times to an asynchonous service the incoming callbacks must be correlated with the invocations.
WS-Addressing [WSA] is the standard used for this correlation. This standard defines a set of SOAP headers needed to achieve

correlation. The most important ones are:

	Fig. 1 - Asynchonous invocation message interchange

Asynchronous model implementations

Each SOAP stack provides it's own implementation of the asynchonous model and problems may occurr when the client and the provider use different SOAP stack.

This document describes the specific case of invoking a JAX-WS asynchronous service from Oracle BPEL 10.1.3.1. Let's take a look to both models to see the

difference.

BPEL asynchronous model

In BPEL the asynchonous model is implemented via two Web Services. An asynchronous BPEL service exposes two services in it's WSDL as shown in the following

pictures:

Fig. 2 - BPEL process asynchronous WSDL (request highlighted)

Fig. 3 - BPEL process asynchronous WSDL (response highlighted)

The former is to be implemented by the service itself to receive the invocation. The later is to be implemented by the client in order to receive the

callback.

JAX-WS asynchronous model

As you can see in the picture below a JAX-WS asynchonous service does only expose one service. The asynchrony affects only to the implementation and not to

the service description itself. The runtime behaviour is the same as in the BPEL case. The only difference is in the way they service is described.

	Fig. 4 - JAX-WS asynchronous WSDL

Adapting a JAX-WS WSDL for BPEL

The target is to create a WSDL equivalent to the JAX-WS one but adapted to the BPEL style so the runtime behaviours get equal.

Adapting the portType definition

As we saw previously as there's only one portType in the JAX-WS WSDL it has to be broken down into two. The output of the original portType has to be removed

from it. The new portType has the original one's output as input as it's going to be used for callback.

	Fig. 5 - JAX-WS sample portType tag
	Fig. 6 - JAX-WS sample portType tag (Modified)

Adapting the binding definition

We have to act the same way with the binding. It has to be broken down into two bindings following the same rules used for the portType. First, the output

must be removed from the original binding. Then a binding has to be created for the callback portType. Again, the ouput from the original one becomes the

input of this one.

	Fig. 7 - JAX-WS sample binding tag
	Fig. 8 - JAX-WS sample binding tag (Modified)

Adapting the service definition

Finally, a new service has to created. It has to be associated to the recently created portType and binding. The location needs not to have a existing URL as

the WS-Addresing headers will tell the remote service where to send the callback message.

	Fig. 9 - JAX-WS sample service tag
	Fig. 10 - JAX-WS sample service tag (Modified)

WS-Addressing

There are several addresing headers and all of them are valid. Oracle BPEL PM 10.1.3.1 uses the ones in the

http://schemas.xmlsoap.org/ws/2003/03/addressing namespace. In order to use different addressing headers (E.g. the ones in the

http://www.w3.org/2005/08/addressing namespace) the following has to be done:

Sending http://www.w3.org/2005/08/addressing WS-Addresing headers

Some messages have to be defined to send out the theese addressing headers. One for each header we want to be included.

	Fig. 11 - http://www.w3.org/2005/08/addressing messages

The bindings have also to be modified to indicate the headers we want to be sent and received. Each header declaration points to the correspondent message

from the described above.

	Fig. 12 - Bindings including headers

Receiving http://www.w3.org/2005/08/addressing WS-Addresing header in Oracle BPEL PM

As, by default, Oracle BPEL PM searchs only for the http://schemas.xmlsoap.org/ws/2003/03/addressing headers for correlation a specific handler has to be

deployed. The code shown here is a header handler. It looks for the addressing header and in case it finds it sets the conversation ID (the attribute used

for correlation) with the header's value.

In order to develop a BPEL header handler the com.collaxa.cube.engine.handlers.IMessageHandler interface has to be implemented. To compile it the Jar files

located at the Oracle BPEL PM library folder have to be in the classpath.

	Fig. 13 - http://www.w3.org/2005/08/addressing header handler source code

To deploy it to the Oracle BPEL PM engine just copy the class (with the required folder structure) to the $BPEL_HOME/system/classes folder. Then, edit the

message-handlers.xml file located at $BPEL_HOME/domains//config folder. Include a new message-handler tag for the handler and include it in the

inbound-flow tag. After restarting BPEL the handler will start working.

	Fig. 14 - Message handler configuration

Additional Resources

[WSA] W3C WS-Addressing Core

WLS 9/10 에서 JMX MBean 브라우저 jconsole 사용하기 기술자료

2008/05/06 13:37

http://blog.naver.com/javalove93/130031031944

이 포스트를 보낸곳 ()