4 Creating an Order Processing System
This chapter includes the following sections:
4.1 Business Challenge
Company X must design an order processing system that addresses the following business challenges:
-
Many different types of clients access the system over different protocols and in different data formats, including mobile devices.
-
The new order processing system must support access through REST interfaces (to prepare for a transition to an in-development mobile application).
-
Existing systems must be able to place orders using XML and comma-separated value (CSV) files. These must be processed and fulfilled using the same new order provisioning system.
-
The system must interface with trading partners and provide electronic data interchange (EDI) support.
4.2 Business Solution
To address these business challenges, Company X designs a business solution that uses the components described in Table 4-1.
Table 4-1 Components That Provide the Business Solution
| Component | How This Component Addresses The Business Challenge | Component Description |
|---|---|---|
|
SOA composite application |
A SOA composite application is designed to accept new purchase orders, authorize or deny them, and forward the authorized orders to an order fulfillment system. The composite consists of the following components, each of which is briefly described below:
|
See Table 3-1 for a description of SOA composite applications. |
|
SOA project template |
A SOA project template is imported. The template is used to create the SOA composite application. The predefined components in the composite implement the basic scenario:
The following occurs:
|
See Table 3-1 for a description of SOA project templates. |
|
Inline BPEL subprocess |
The inline BPEL process (through use of a call activity) invokes the payment validation system in Creating a Credit Validation System to update the order status in the database based on the outcome of the payment validation. |
A subprocess is a fragment of BPEL code that can be reused within a composite by separate processes. The subprocess extension provides the following benefits:
|
|
Composite sensor |
A composite sensor tracks the order number. |
See Table 3-1 for a description of SOA composite sensors. |
|
Oracle Service Bus proxy service, pipeline, and business service |
An Oracle Service Bus makes the order processing composite available over many protocols and data formats, and validates the order. |
See Table 3-1 for a description of Oracle Service Bus. |
Figure 4-1 provides an overview of how this business solution is implemented.
Subsequent sections of this chapter provide more specific details about how the components in Table 4-1 are used to address the order processing business challenge.
4.2.1 Creating a SOA Composite Application From a SOA Project Template
As described in Calculating Payment Status with XSLT Transformations, templates enable you to reuse existing composites, service components, and custom activities. Company X frequently has business requirements for designing SOA composite applications that accept new purchase orders, approve them, and forward them to an order fulfillment system. For this reason, Company X created a project template named ProcessOrderTemplate 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.
The ProcessOrderTemplate project template is registered in Oracle JDeveloper by selecting Tools > Preferences > SOA > Templates, and specifying the template storage location. The template is provided as a JAR file. This makes the template visible for selection in Oracle JDeveloper.
The project template consists of a number of predefined components and provides the following functionality:
-
Receives an order from a SOAP web service.
-
Creates an order number, sets the order date to the current date, and sets the order status to a value of New.
-
Calculates the total order amount.
-
Saves the order in the database with a status value of New.
-
Returns an acknowledgement to the client with the order number.
Company X invokes the Create SOA Project wizard to create a new SOA project. While running the wizard, Company X selects to create a project 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. ProcessOrderTemplate is selected, then the project name is shortened to ProcessOrder. Figure 4-2 provides details.
Figure 4-2 Selection of SOA Composite Template in the Create SOA Project Dialog
Description of "Figure 4-2 Selection of SOA Composite Template in the Create SOA Project Dialog"
When imported, the project and its predefined components looks as shown in Figure 4-3.
-
The receiveOrder_client service receives an order from a customer.
-
The receiveOrder BPEL process service component sets an order number (which is provided back to the client) and order date, and calls the validateAndProcessOrder BPEL process service component.
-
The validateAndProcessOrder BPEL process service component assigns an order to a variable and calculates the total amount of the order used to validate the payment. It invokes three partner links as part of validating and processing the order.
-
The writeOrderToFile file adapter reference writes the order to a file using a file adapter.
-
The writeOrderToDatabase reference writes the order to the database using a database adapter.
-
The updateOrderStatus reference updates the order status to Denied or Authorized in the database according to the value returned.
-
Figure 4-3 Imported Template of a SOA Composite Application
Description of "Figure 4-3 Imported Template of a SOA Composite Application"
4.2.2 Customizing the Contents of the SOA Project Template
The validateAndProcessOrder BPEL process of the template assigns the order to a variable and calculates the total order amount used to validate the payment. The activities in the process shown in Figure 4-4 perform the following tasks:
-
An XSLT transform activity calculates the total order amount.
-
An assign activity adds the total order amount to the order message.
-
A scope activity (collapsed below) includes all activities involved in updating the order status in the database and in a file.
Figure 4-4 Key Activities of the validateAndProcessOrder BPEL Process
Description of "Figure 4-4 Key Activities of the validateAndProcessOrder BPEL Process"-
If the payment is denied, the order is cancelled and the order status is updated in the database.
-
If the payment is authorized, the order status is updated in the database and file, and the order is processed. When processing is complete, the status is updated to ReadyForShip.
-
An order only requires processing if payment has first been validated. The ProcessOrder composite does not include this functionality. However, Company X created the validatePayment composite in Creating a Credit Validation System. Company X customizes the imported composite template to invoke the validatePayment composite to validate the payment. If the payment is authorized, the ProcessOrder composite then processes the order. This customization to the imported template is not propagated to users of this template in other projects.
Company X customizes the ProcessOrder composite by dragging a SOAP web service into the External References swimlane to invoke the Create Web Service dialog. From this dialog, Oracle SOA Suite enables you to browse services deployed in an Oracle SOA Suite or Oracle Service Bus project on the integrated server in Oracle JDeveloper or on a remote application server. You can browse for the following:
-
Select WSDL URLs.
-
Read WSDLs from a file system, Oracle Metadata Services Repository (MDS Repository), UDDI registry, or web services inspection language (WSIL) file.
The Oracle Service Bus proxy service for validatePayment is selected by clicking the icon to the right of the WSDL URL field. Selecting this icon enables you to browse for services. The ValidatePS proxy service created in Registering SOA Composite Applications with is selected, as shown in Figure 4-5.
Figure 4-5 Selection of ValidatePS Proxy in the WSDL Chooser Dialog
Description of "Figure 4-5 Selection of ValidatePS Proxy in the WSDL Chooser Dialog"
The new web service (named validatePaymentService) invokes the validatePayment proxy service defined in Registering SOA Composite Applications with . The port type is automatically added. Figure 4-6 provides details.
Figure 4-6 Call of validatePayment Proxy WSDL File
Description of "Figure 4-6 Call of validatePayment Proxy WSDL File"
The validateAndProcessOrder BPEL process is then wired to the new validatePaymentService SOAP web service in the SOA Composite Editor, as shown in Figure 4-7.
Figure 4-7 Invocation of validatePaymentService SOAP Web Service
Description of "Figure 4-7 Invocation of validatePaymentService SOAP Web Service"
Company X further customizes the validateAndProcessOrder BPEL process by adding the following:
-
An invoke activity (named validatePayment) to invoke the validatePaymentService partner link.
-
An assign activity before the validatePayment invoke activity for assigning the correct values to the input variable for the web service call.
-
An assign activity after the invoke activity to assign the payment status reply from the web service call to the order message. Figure 4-8 provides details.
Figure 4-8 Customizations to the validateAndProcessOrder BPEL Process of the Composite Template
Description of "Figure 4-8 Customizations to the validateAndProcessOrder BPEL Process of the Composite Template"
The completed composite is shown in Figure 4-9.
4.2.3 Updating Order Status with an Inline BPEL Subprocess
Company X has a requirement to use the order status update part of the validateAndProcessOrder BPEL process at least once more in the same BPEL process. One method is to create the same assign and invoke activities already used. However, this is an error prone process and every time a change is necessary, it must be made in all those places. To avoid this, Company X uses a BPEL subprocesses. There are two types:
-
Standalone: A fragment of a BPEL process, which includes a number of activities to reuse. Standalone subprocess do not have an interface and are only called from another BPEL process. A standalone process can have partner links across a number of other BPEL processes.
-
Inline: For groups of activities that are reused within a single BPEL process. An inline process is part of the parent BPEL process code and is not visible in the composite view. You use a call activity for inline subprocesses.
The inline subprocess is ideal for Company X's business requirements.
Within the validateAndProcessOrder BPEL process, the scope activity responsible for updating the order status, named updateOrderStatusScope, is right-clicked, and Convert to a Subprocess is selected. This invokes the Create Inline Subprocess dialog. Company X renames the subprocess and selects to automatically replace the scope activity with a subprocess call activity. Figure 4-10 provides details.
This converts the scope activity into a call activity. A call activity executes referenced subprocess code in standalone and inline subprocesses. The call activity is also added to the Subprocesses part of the Components window. You can drag and drop this call activity as needed into other locations in the BPEL process. Figure 4-11 provides details.
Figure 4-11 Call Activity in the BPEL Process and in the Components Window
Description of "Figure 4-11 Call Activity in the BPEL Process and in the Components Window"
4.2.4 Tracking the Order Number with Composite Sensors
Company X added a composite sensor for tracking the status of order payments in Tracking Payment Status with Composite Sensors.
Company X now has an additional requirement for a composite sensor to track the order number. The SOAP web service receiveorder_client included in the imported composite template shown in Figure 4-3 returns the orderNumber in the order acknowledgement message. Company X defines a composite sensor on this service that includes an XPath expression to track the order number, as shown in the Create Composite Sensor dialog in Figure 4-12.
Figure 4-12 Expression Defined on Composite Sensor
Description of "Figure 4-12 Expression Defined on Composite Sensor"
The Enterprise Manager check box of the Create Composite Sensor dialog is also selected, as shown in Figure 4-13. This enables you to track composite sensor names and values (for example, OrderNumber=1234) on the Flow Instances page or the Flow Trace page for a specific business flow instance in Oracle Enterprise Manager Fusion Middleware Control. Oracle Enterprise Manager Fusion Middleware Control is a web browser-based, graphical user interface that you use to monitor and administer your deployed composites.
Figure 4-13 Enterprise Manager Check Box for Composite Sensors
Description of "Figure 4-13 Enterprise Manager Check Box for Composite Sensors"
The composite sensor definition is displayed by placing the cursor over the icon on the receiveorder_client SOAP web service binding component. Figure 4-14 provides details.
4.2.5 Updating Order Status After Payment Authorization
If the payment is valid, the order status is set to ReadyForShip in the database. This status update triggers the order fulfillment process described in Fulfilling Orders .
Company X further customizes the validateAndProcessOrder BPEL process by adding an if activity. An if activity defines conditional behavior for specific activities to decide between the execution of two or more branches. Only one activity is selected for execution from a set of branches. The if activity for this business scenario consists of the following branches:
-
If the payment is authorized, the order continues. An assign activity in the if branch updates the order status to ReadyForShip in the database.
-
If the payment is denied, processing ends and an email is sent to the customer informing them about the unauthorized payment.
Figure 4-15 provides details. The if activity is added below the updateOrderStatusSP call activity that was created in Updating Order Status with an Inline BPEL Subprocess.
An expression is defined on the if branch if the payment is authorized, as shown in Figure 4-16.
If payment is authorized, the processing of the order is complete. An assign activity is added to the if branch to update the order status to ReadyForShip in the database. The contents of the copy rule in the assign activity are shown in Figure 4-17.
The XPath expression contents in the copy rule assign activity are shown in Figure 4-18.
An else branch is not necessary and is deleted because order processing stops if the payment has been denied.
4.2.6 Deploying and Testing in Oracle Enterprise Manager Fusion Middleware Control
Company X deploys and creates a business flow instance of the project. In the Flow Trace page in Oracle Enterprise Manager Fusion Middleware Control, the two composite sensor names and values are displayed. Payment has been authorized, and the project is sent to the order fulfillment system. Figure 4-19 provides details.
Figure 4-19 Composite Sensor Names and Values on Flow Trace Page
Description of "Figure 4-19 Composite Sensor Names and Values on Flow Trace Page"
The audit trail indicates that the order is marked as Authorized and ReadyForShip. Figure 4-20 provides details.
Figure 4-20 Flow of Business Flow Instance
Description of "Figure 4-20 Flow of Business Flow Instance"
4.2.7 Registering the ProcessOrder Composite on Oracle Service Bus
As with the validatePayment composite in Creating a Credit Validation System, Company X uses Oracle Service Bus to register the ProcessOrder composite to make it available to external customers.
Oracle Service Bus makes the ProcessOrder composite available over different protocols and data formats without disrupting the core business logic in the composite. Oracle Service Bus also validates the order data and performs auditing.
Company X updates the Oracle Service Bus application created in Registering SOA Composite Applications with to include additional projects. These projects use a pipeline template.
Pipeline templates are used to design prototype message flows for proxy services. A pipeline template defines the general shape or pattern of the message flow. Concrete pipelines can then be generated out of the pipeline template. All concrete pipelines use the message flow defined by the pipeline template with designated places where custom logic can be inserted.
Company X imports the template by right-clicking the Oracle Service Bus application, selecting Import, and selecting Service Bus Resources. Figure 4-21 provides details.
Figure 4-21 Oracle Service Bus Resources Selection
Description of "Figure 4-21 Oracle Service Bus Resources Selection"
This invokes the Import Service Bus Resources dialog for selecting the pipeline template to use. When complete, the imported template is displayed in the Applications window, as shown in Figure 4-22.
Figure 4-22 Imported Oracle Service Bus Pipeline Template in Applications Window
Description of "Figure 4-22 Imported Oracle Service Bus Pipeline Template in Applications Window"
4.2.7.1 Registering the ProcessOrder Composite as a Business Service
Company X registers the composite as a business service by right-clicking in the External References column and selecting Insert Transports > HTTP, as shown in Figure 4-23.
This action invokes the Create Business Service wizard in which Company X sets the following:
-
HTTP as the transport type
-
ProcessOrder concrete WSDL as the service type
-
The WSDL file
-
The composite as the endpoint URI. Oracle Service Bus also enables you to have multiple endpoints for your business service to support application load balancing and failover.
4.2.7.2 Creating a New Pipeline with a Proxy Using the Pipeline Template
Company X then creates a pipeline template (SharedSB) by dragging a Pipeline icon from the Component window into the Components section of Oracle JDeveloper, as shown in Figure 4-24.
This invokes the Create Pipeline Service dialog for selecting the imported pipeline template to use. During configuration, you select the template for WSDL-based services, the specific WSDL to use for the pipeline (shown in Figure 4-25), and to expose the pipeline as a proxy service.
When configuration is complete, the Create Pipeline Service dialog looks as shown in Figure 4-26.
Figure 4-26 Completed Create Pipeline Service Dialog
Description of "Figure 4-26 Completed Create Pipeline Service Dialog"
The pipeline is displayed in the application, as shown in Figure 4-27. The yellow icon in the pipeline indicates that it requires additional configuration before it is fully implemented.
Double-clicking ProcessPP displays it for editing, and includes some features partially preconfigured (for example, data validation, routing, reporting, error condition alerts, and error handling). Red flags indicate areas that require additional configuration. The Your Request Stages message indicates areas in which the pipeline provides placeholder information for Company X to customize (such as transformations and message enrichment). Figure 4-28 provides details.
Figure 4-28 Preconfigured Pipeline Template
Description of "Figure 4-28 Preconfigured Pipeline Template"
The template also enables you to define an error handler for pipelines, as shown in Figure 4-29. The predefined error handler reports error back to the caller with details and send an alert to Oracle Enterprise Manager Fusion Middleware Control indicating that something is wrong with processing.
Figure 4-29 Error Handling in the Pipelines Template
Description of "Figure 4-29 Error Handling in the Pipelines Template"
Company X configures data validation by opening the Data Validation stage and selecting the Validate action. This part enables Company X to validate the incoming payload against the Order schema element type expected by the ProcessOrder composite. Validating in Oracle Service Bus saves resources in the back end that are processing good orders. Company X only needs to select the Order type against which to validate, since all other details are preconfigured.
Company X configures the Report action in the Auditing stage of the response flow shown in Figure 4-28 to report on the Order number returned from the composite, as shown in Figure 4-30. The template already saves a copy of the incoming order in case of an error and reports it to Oracle Enterprise Manager Fusion Middleware Control.
Company X also configures the routing node by double-clicking the Routing icon in the template in Figure 4-28, selecting the Routing tab in the Property Inspector, and selecting the ProcessBS business service. Figure 4-31 provides details.
When configuration is complete, the Oracle Service Bus application looks as shown in Figure 4-32.
Figure 4-32 Oracle Service Bus Application
Description of "Figure 4-32 Oracle Service Bus Application"
4.2.8 Testing the Pipeline Template
Company X tests by right-clicking the ProcessPS service in the left swim lane and selecting Run, as shown in Figure 4-33. Good and bad orders are sent during the test phase.
4.3 Related Documentation
Table 4-2 provides references to documentation that more specifically describes the components and features described in this chapter.
Table 4-2 Related Documentation
| For Information About... | See... |
|---|---|
|
Creating a SOA composite application |
"Creating a SOA Application" of Developing SOA Applications with Oracle SOA Suite |
|
Creating and using composite templates and inline subprocesses |
"Oracle SOA Suite Templates and Reusable Subprocesses" of Developing SOA Applications with Oracle SOA Suite |
|
Creating composite sensors |
"Defining Composite Sensors" of Developing SOA Applications with Oracle SOA Suite |
|
Creating a business service in Oracle Service Bus |
"Creating and Configuring Business Services" of Developing Services with Oracle Service Bus |
|
Using pipeline templates |
"Working with Pipeline Templates" of Developing Services with Oracle Service Bus |