7 Fulfilling Orders

This chapter describes how Oracle SOA Suite addresses the business challenge of creating an order fulfillment system. Overviews of how key SOA composite application components are used to address this challenge are provided, including project templates, business rules, composite sensors, REST binding references, and Coherence adapters.

This chapter includes the following sections:

7.1 Business Challenge

Company X has a requirement to create a system that listens for orders to be processed, selects a shipping provider (for example, the United States Postal Service (USPS) or UPS), and invokes a packing and shipping service. In this scenario, the packing and shipping service to invoke is the PackAndShipService composite that was designed in Packing and Shipping Orders .

7.2 Business Solution

To address this business challenge, Company X designs a business solution that uses the components described in Table 7-1.

Table 7-1 Components That Provide the Business Solution

Component How This Component Addresses The Business Challenge Component Description

SOA composite application that includes a project template

An order fulfillment composite created from a project template listens for orders to be processed, selects a shipping provider, and invokes the packing and shipping service (PackAndShipService) created in Packing and Shipping Orders . The order fulfillment composite is triggered when an order is updated as ReadyForShip in the database. It then locates the shipping speed in the order message, determines the shipping method based on the shipping speed and shipping state, reads the preferred shipping provider from the database or Coherence cache, and calls the packing and shipping REST service.

See Table 3-1 for a description of templates.

Business rule

A business rule (decision table) decides the shipping method based on speed and shipping state. Based on the shipping method, the preferred shipping provider is retrieved from the database.

Business rules enable dynamic decisions at runtime that allow you to automate policies, computations, and reasoning while separating rule logic from underlying application code. This enables more agile rule maintenance and empowers business analysts with the ability to modify rule logic without programmer assistance and without interrupting business processes.

Composite sensor

A composite sensor tracks the order number.

See Table 3-1 for a description of composite sensors.

REST reference

The outbound REST reference delivers the order to the packing and shipping service.

See Table 6-1 for a description of REST bindings.

Coherence adapter

A Coherence adapter initially reads the correct shipping provider from the database, and from Coherence cache for subsequent read operations.

An additional Coherence adapter copies the database adapter response into Coherence cache so that the shipping provider is available in cache the next time it is looked up.

A Coherence cache is a collection of data objects that serves as an intermediary between the database and the client applications. Database data can be loaded into a cache and made available to different applications. Coherence cache reduces load on the database and provides faster access to database data.

Subsequent sections of this chapter provide more specific details about how the components in Table 7-1 are used to address the order fulfillment business challenge.

7.2.1 Creating a Project from a SOA Template

Company X frequently has business requirements for designing SOA composite applications that listen for orders to be processed, select a shipping provider, and invoke a packing and shipping service. To address this challenge, Company X created a project template named FulfillOrderTemplate with these capabilities that can be imported into multiple applications in Oracle JDeveloper, as necessary. The template can then be customized for the business requirements of that specific project. Changes made to that specific imported template are not propagated to projects previously created using this template.

As with previous templates, the FulfillOrderTemplate project template is first registered in Oracle JDeveloper by selecting Tools > Preferences > SOA > Templates, and specifying the template storage location.

Company X invokes the Create SOA Project wizard to create a new SOA project, and selects to create one based on a template. The project template is imported into the new application by selecting SOA Template in the Create SOA Project wizard, which refreshes the dialog to display existing templates for selection. FulfillOrderTemplate is selected, then the project name is shortened to FulfillOrder, as shown in Figure 7-1.

Figure 7-1 Project Template Selection

Description of Figure 7-1 follows
Description of "Figure 7-1 Project Template Selection"

When creation is complete, the composite looks as shown in Figure 7-2 with the imported project template.

Figure 7-2 Contents of the SOA Composite Application

Description of Figure 7-2 follows
Description of "Figure 7-2 Contents of the SOA Composite Application"

The imported project template consists of the following components:

  • The first database adapter (ReceiveOrdersReadyForShipment) listens for orders with a status of ReadyForShip, reads the record out of the database, and triggers a new BPEL process for each order. To prevent the order from being read again, it changes the status to ReadyForPack.

  • The second database adapter (getShippingProvider) reads the shipping provider from the database, using the shipping method ID as a primary key. A list of preferred shipping providers per shipping method is maintained in the database. For example, USPS is used for USAFirstClass shipment (shipping method ID =1), UPS is used for USAPriority shipment (shipping method ID =2), and so on.

  • The receiveOrderToShip BPEL process is open and displayed in Figure 7-3. This process is invoked by the ReceiveOrdersReadyForShipment database adapter service. An XSLT map transforms the message into a canonical order message. The fulfillOrder BPEL process is invoked with the canonical order message as input.

    Figure 7-3 receiveOrderToShip BPEL Process Contents

    Description of Figure 7-3 follows
    Description of "Figure 7-3 receiveOrderToShip BPEL Process Contents"
  • The fulfillment BPEL process is shown in Figure 7-4. The incoming order message includes the shipping speed selected by the customer:

    • One-day shipping

    • Two-day shipping

    • Standard shipping: 3-5 business days

    • Shipping speed does not matter

    A business rule determines the shipping method based on shipping speed and shipping address. The shipping method ID is used as input to the database call to retrieve the shipping provider.

    Figure 7-4 fulfillment BPEL Process Contents

    Description of Figure 7-4 follows
    Description of "Figure 7-4 fulfillment BPEL Process Contents"

7.2.2 Determining the Shipping Method with a Business Rule

Business rules enable dynamic decisions to be made at runtime. This enables you to automate policies, computations, and reasoning while separating rule logic from underlying application code.

Company X adds a business rule to determine the shipping method ID. The rule takes as input the shipping state and the requested shipping speed and returns the shipping method ID. For example, USPS is used for USAFirstClass shipment (shipping method ID =1), UPS is used for USAPriority shipment (shipping method ID =2), and so on.

Company X drags a Business Rule icon from the Components section of the Components window into the SOA composite application. After configuration is complete, the Create Business Rules dialog looks as shown in Figure 7-5.

Figure 7-5 Input and Output Facts of Defined Business Rule

Description of Figure 7-5 follows
Description of "Figure 7-5 Input and Output Facts of Defined Business Rule"

Both the input and output facts shown in Figure 7-5 are defined with the Shipping element type in the schema file, as shown in Figure 7-6. Facts are the objects on which rules reason. Each fact is an instance of a fact type.

Figure 7-6 Shipping Element Type

Description of Figure 7-6 follows
Description of "Figure 7-6 Shipping Element Type"

After business rule creation, the business rule service component in the composite is clicked to access the Rules Editor. Within the Rules Editor, a decision table is defined, as shown in Figure 7-7. A decision table is an alternative business rule format that is more compact and intuitive when many rules are needed to analyze many combinations of property values. You can use a decision table to create a set of rules that covers all combinations or where no two combinations conflict.

The following rule conditions are defined for speed of delivery. A rule condition represents the IF part of a statement. A rule condition is like a query over the available facts in the Rules Engine, and for every row returned from the query, the rule is activated. The rule condition activates the rule whenever a combination of facts makes the conditional expression true.

  • One-day shipping

  • Two-day shipping

  • Standard shipping: 3-5 business days

  • Do not care (shipping speed does not matter). For this delivery method, a state condition of TX (for Texas) is set. No other rule conditions have a state set; delivery speed is the only requirement.

The following shipping method ID rule actions are defined for each rule condition. A rule action represents the THEN part of a statement. The THEN part contains the actions that are executed when the rule is fired. A rule is fired after it is activated and selected among the other rule activations using conflict resolution mechanisms such as priority.

  • 1 - USPS is used for USAFirstClass shipping

  • 2 - UPS for USAPriority shipping

  • 3 - USA free mail

  • 4 - UPS next day air

Figure 7-7 Decision Table in Rules Editor

Description of Figure 7-7 follows
Description of "Figure 7-7 Decision Table in Rules Editor"

The business rule is integrated by dragging a Business Rule icon from the SOA Components section of the Components window into the fulfillment process, as shown in Figure 7-8.

Figure 7-8 Business Rule Integrated into fulfillment BPEL Process

Description of Figure 7-8 follows
Description of "Figure 7-8 Business Rule Integrated into fulfillment BPEL Process"

Company X selects the dictionary invoked by this activity. The input and output facts are also defined. For the input copy rule, ShippingType is copied from the process inputVariable to the dsIn (input fact) variable of the business rule. Figure 7-9 provides details.

For the output copy rule, ShippingMethod is copied from the dsOut (output fact) variable of the business rule to the shippingMethodID process variable. Figure 7-10 provides details.

Figure 7-10 Output Copy Rule

Description of Figure 7-10 follows
Description of "Figure 7-10 Output Copy Rule"

When design is complete, the fulFillment process looks as shown in Figure 7-11.

Figure 7-11 Invocation of Rules Dictionary

Description of Figure 7-11 follows
Description of "Figure 7-11 Invocation of Rules Dictionary"

7.2.3 Tracking the Order Number with Composite Sensors

As performed in previous chapters, Company X adds a composite sensor for tracking fields on messages. For this scenario, the status of the order number is tracked. The sensor is set on the ReceiveOrderReadyForShipment database adapter service. Figure 7-12 provides details.

Figure 7-12 Composite Sensor

Description of Figure 7-12 follows
Description of "Figure 7-12 Composite Sensor"

The definition includes an XPath expression to track the order number, as shown in the Composite Sensor dialog in Figure 7-13.

Figure 7-13 Composite Sensor Dialog

Description of Figure 7-13 follows
Description of "Figure 7-13 Composite Sensor Dialog"

The Enterprise Manager check box of the Create Composite Sensor dialog is also selected. This enables you to track composite sensor names and values on the Flow Instances page or the Flow Trace page for a specific business flow instance in Oracle Enterprise Manager Fusion Middleware Control. Figure 7-14 provides details.

Figure 7-14 Composite Sensor Name and Value on Flow Trace Page

Description of Figure 7-14 follows
Description of "Figure 7-14 Composite Sensor Name and Value on Flow Trace Page"

7.2.4 Delivering the Order to the Packing Service with the REST Interface

A REST service was used as an alternative to web services in Exposing a REST Service with a Packing BPEL Process. REST uses HTTP requests to post data (create and update), get data (for example, make queries), update data, and delete data.

For this business scenario, Company X uses a REST reference to call the PackAndShip service created in Packing and Shipping Orders . Company X drags a REST binding into the External References swimlane of the composite and defines the following details:

  • A REST outbound interface.

  • A shipping REST resource.

  • A packandShip operation binding based on a WADL file with a POST HTTP verb. WADL provides a readable XML description of HTTP-based web applications (typically REST web services). WADL simplifies the reuse of web services based on the existing HTTP architecture of the web. When you select a WADL file, all operation binding details are automatically populated in the Create REST Binding dialog. Figure 7-15 provides details.

When configuration is complete, Company X connects the fulfillOrder BPEL process to the REST reference, as shown in Figure 7-16.

Figure 7-16 BPEL Process Connected to REST Reference

Description of Figure 7-16 follows
Description of "Figure 7-16 BPEL Process Connected to REST Reference"

To complete configuration, Company X adds the necessary activities to the fulfillOrder process:

  • An invoke activity invokes the PackAndShipOrder partner link and defines the necessary input and output variables.

  • An assign activity maps the shipping element in the input variable to the shipping element in the input variable for the REST reference.

Because the BPEL process is one-way, there is no need to assign the return value of the REST service.

Figure 7-17 provides details.

Figure 7-17 fulFillment BPEL Process Contents

Description of Figure 7-17 follows
Description of "Figure 7-17 fulFillment BPEL Process Contents"

7.2.5 Reading the Shipping Provider from Cache with the Coherence Adapter

The database adapters used in this composite regularly access the database. To reduce load on the database and to provide faster access to database data, Company X integrates a Coherence adapter into the composite. The Coherence adapter initially puts the data into the cache after it reads from the database the first time.

A Coherence cache is a collection of data objects that serves as an intermediary between the database and client applications. Database data can be loaded into a cache and made available to different applications. The Coherence adapter enables you to perform useful Coherence operations such as adding an item to Coherence cache, obtaining an item, removing an item, and querying items.

Company X drags a Coherence icon from the Technology section of the Components window into the External References swimlane of the composite. The Adapter Configuration Wizard guides you through configuring the following Coherence adapter details.

  • The JNDI name of the Coherence connection.

  • The operation to perform. In this case, a get operation is selected to get data from Coherence cache.

  • The cache type (XML).

  • The cache name.

  • The key type (string) (Populated later with the jca.coherence.Key property in an invoke activity.).

  • The database lookup response schema file (Stores the response from the database lookup directly in Coherence cache.).

When adapter configuration is complete, the fulfillOrder BPEL process is connected to the Coherence adapter, as shown in Figure 7-18.

Figure 7-18 fulfillOrder BPEL Process Connected to Coherence Adapter

Description of Figure 7-18 follows
Description of "Figure 7-18 fulfillOrder BPEL Process Connected to Coherence Adapter"

To complete configuration, Company X adds and configures the necessary activities in the fulfillOrder process:

  • An invoke activity is configured as follows:

    • Invokes the QueryCoherence partner link.

    • Defines input and output variables.

    • Assigns the jca.coherence.Key property to the shippingMethodID value (under the Properties tab). This value is sent as the input variable upon invocation of the adapter and eliminates the need to create an assign activity statement in which an input value is assigned to the Coherence query invocation.

  • An if activity is configured as follows:

    • The if part assigns the shipping provider name from the Coherence query output variable to the shipping provider name in the process input variable (in the shipping element). This is used later for the PackAndShipService designed in Packing and Shipping Orders .

    • An else part includes the getShippingProvider database adapter invocation and its two assign activities.

When complete, configuration looks as shown in Figure 7-19.

7.2.6 Copying the Database Adapter Response into Coherence Cache

Company X adds another Coherence adapter to the External References swimlane of the composite. This adapter copies the database adapter response into Coherence cache so that the shipping provider is available in cache the next time it is looked up.

The Coherence adapter is configured as follows:

  • The JNDI name of the Coherence connection.

  • The operation to perform. In this case, a put operation is selected to put an item into cache.

  • The cache type (XML).

  • The cache name.

  • The key type (string).

  • The key value of shippingMethodKey.

  • The database lookup response schema file.

To complete configuration, Company X connects the fulfillment process to the new Coherence adapter, as shown in Figure 7-20.

Figure 7-20 BPEL Process Connected to Second Coherence Adapter

Description of Figure 7-20 follows
Description of "Figure 7-20 BPEL Process Connected to Second Coherence Adapter"

To complete configuration, Company X adds the necessary activities to the fulfillOrder process:

  • An invoke activity is configured as follows:

    • Invokes the putIntoCoherence partner link.

    • Defines input and output variables.

    • Assigns the jca.coherence.Key property to the shippingMethodID value (under the Properties tab). This value is sent as the input variable upon invocation of the adapter and eliminates the need to create an assign activity statement in which an input value is assigned to the Coherence query invocation.

  • An assign activity populates the input variable of the Coherence adapter with the output variable of the database call.

When configuration is complete, the fulfillment process looks as shown in Figure 7-21.

Figure 7-21 fulfillment BPEL Process Contents

Description of Figure 7-21 follows
Description of "Figure 7-21 fulfillment BPEL Process Contents"

Figure 7-22 shows how this completed business solution appears in the SOA Composite Editor.

Figure 7-22 Completed SOA Composite Application

Description of Figure 7-22 follows
Description of "Figure 7-22 Completed SOA Composite Application"

7.2.7 Deploying the Composite and Testing the Coherence Adapters

Initially both Coherence adapters are executed. The queryCoherence reference returns an empty variable because nothing has been put into Coherence cache yet. The putCoherence reference then puts the content into Coherence cache. Figure 7-23 provides details.

Once the message has been put into Coherence cache, the audit trail changes. Figure 7-24 provides details.

Figure 7-24 Flow Trace with Changes

Description of Figure 7-24 follows
Description of "Figure 7-24 Flow Trace with Changes"

The queryCoherence reference returns the shipping method variable and the database does not need to be queried again. Figure 7-25 provides details.

Figure 7-25 Shipping Method Variable Returned

Description of Figure 7-25 follows
Description of "Figure 7-25 Shipping Method Variable Returned"

7.3 Related Documentation

Table 7-2 provides references to documentation that more specifically describes the components and features described in this chapter.

Table 7-2 Related Documentation

For Information About... See...

Adding a project template

"Oracle SOA Suite Templates and Reusable Subprocesses" of Developing SOA Applications with Oracle SOA Suite

Designing a business rule

"Overview of Oracle Business Rules" of Designing Business Rules with Oracle Business Process Management

"Getting Started with Oracle Business Rules" of Developing SOA Applications with Oracle SOA Suite

"Working with Decision Tables" of Designing Business Rules with Oracle Business Process Management

Creating a composite sensor

"Defining Composite Sensors" of Developing SOA Applications with Oracle SOA Suite

Adding a REST reference

"Integrating REST Operations in SOA Composite Applications" of Developing SOA Applications with Oracle SOA Suite

Configuring Coherence adapters

"Oracle JCA Adapter for Coherence" of Understanding Technology Adapters