2.5 Taking a Closer Look at the SOA Order Booking Application

You run the SOA Order Booking application by running the SOADEMO-CLIENT application. This application uses JavaServer Faces (JSF) as the view technology, and relies on backing beans to invoke the web services for the other applications.

To launch the client, open a browser and enter the following URL:

http://<host_hame>:<port_number>/soademo

For example:

http://localhost:8888/soademo

Once the login page launches, you can use a valid email/password combination to enter the web site, or you can choose to register as a new customer. The SOA Order Booking application ships with predefined customer data. You can use one of these customers' email and password to log in, or you can register as a new customer. Table 2-2 shows the preregistered customers.

Table 2-2 Preregistered Customers in the SOA Order Booking Application

Email	Password	Customer Status	Notes
[e-mail]	welcome1	Gold	Requires manual approval for orders over $1,000.
[e-mail]	welcome1	Platinum	Has an invalid credit card number.
[e-mail]	welcome1	Silver	Requires manual approval for all orders.

Creating an order invokes the ESB that then invokes the BPEL process flow that handles the order. Once the order is in-flight, you can use the ESB console to view the status of the ESB, and the BPEL console to view the status of the process flow. You can also use Oracle Enterprise Manager to view the status of the entire system.

While the SOA Order Booking application does not by default have any security constraints placed on the services, you can secure the services using Oracle Web Services Manager (Oracle WSM). This application contains a tool to define security for your services, as well as a console that allows you to monitor your services. For more information about using Oracle WSM, see Chapter 10, "Securing the System".

2.5.1 Registration Process

When a user registers as a customer, the web client collects the needed information, and then sends that information to the Customer Service application by invoking the Customer Web service. Figure 2-19 shows the Registration page.

Figure 2-19 Registration Page

When the user clicks the Register button, the data is collected by a method on the Register.java backing bean, which then invokes the CustomerService web service. The CRM application then persists the data to the Customer tables.

Where to Find Implementation Details

Following are the sections of Oracle SOA Suite Developer's Guide that describe how to develop the components used in the registration process:

• Collecting information on a web page: The registration page collects information by binding JSF input components to properties on a backing bean. The page was designed to collect the needed information as described by the CustomerService web service. For information about creating web pages that collect information needed by web services, see Section 9.6, "Collecting Data for Use by a Web Service".

• Invoking a web service from a web page: The register.java JSF backing bean contains a method that invokes a web service and populates the web service with the registration data. For more information, see Section 9.6.3, "How to Invoke a Service Using a Backing Bean".

2.5.2 The Login Process

When a registered user logs into the web client, the user name and password are compared with the credential information stored in the customer service database. Figure 2-20 shows the Application Login page for the web client.

Figure 2-20 Application Login Page

When the user clicks the Login button, the associated Login.java backing bean collects that information and invokes the CustomerService web service, which then verifies the user information in the database.

2.5.3 The Ordering Process

The ordering process begins in the web client application where a user can shop for and order products. The web application kicks off an ESB flow, which in turn invokes a BPEL flow. The BPEL flow handles the actual ordering process.

2.5.3.1 The Web Client

Registered users can shop for products by clicking the Browse products link on the Welcome page, which displays directly after users log in, as shown in Figure 2-21.

Figure 2-21 Application Welcome Page

This link displays the Browse Items page, which lists all products available for sale, as shown in Figure 2-22. The product information is stored in the PRODUCT table, in the client application's database. That data is displayed in a table that uses ADF data binding.

Figure 2-22 Booking Browse Items Page

When the user selects a product, and clicks the View Details button, the Item Details page displays the product details, as shown in Figure 2-23. This page displays detailed information about the product, and allows the users to select a quantity to add to their cart.

Figure 2-23 Item Details Page

When the user clicks the Go to Shopping Cart link, the Cart page displays the added items, as shown in Figure 2-24.

Figure 2-24 The SOA Order Booking Cart Page

When the user clicks the Place Order button, the purchase order is created and sent into the OrderBookingESB flow.

Where to Find Implementation Details

Following are the sections of the Oracle SOA Suite Developer's Guide that describe how to develop the web client components used in the order process:

• Displaying data using ADF data binding: The product data on the Browse Items page is displayed using ADF data binding, which allows you to declaratively bind components on a web page to your data source. For more information, see Section 9.5, "Displaying Collection and Detail Data Using ADF Data Binding".

• Invoking an ESB flow from a web page: The ShoppingCart.java backing bean contains a method that invokes a web service and populates the web service with the order data, in much the same way as the registration process. For more information, see Section 9.6.3, "How to Invoke a Service Using a Backing Bean".

2.5.3.2 The OrderBookingESB Flow

When the user clicks the Place Order button, the OrderBookingESB flow is invoked. That, in turn, invokes the SOAOrderBooking BPEL flow. Figure 2-25 shows the ESB flow, as viewed in Oracle JDeveloper.

Figure 2-25 The OrderBookingESB Flow

Where to Find Implementation Details

The OrderBookingESB flow invokes a web service for a BPEL flow. For more information, see Section 6.7, "Adding SOAP Services to Oracle Enterprise Service Bus".

2.5.3.3 SOAOrderBooking BPEL Flow

The SOAOrderBooking BPEL flow then handles the order process, as shown in Figure 2-26.

Figure 2-26 The SOAOrderBooking BPEL Flow

Each scope activity icon (gray box with a flow) represents a higher-level view of a detailed portion of the flow. The following sections describe each step in the flow, including the details within each scope activity. The first activity (receiveInput) is not included, as it simply serves as the entry point into the flow.

2.5.3.3.1 InsertOrderIntoDB Scope

The InsertOrderIntoDB scope includes the following activities:

• GetOrderId: Gets the order ID using a database adapter to access the Order sequence.

• AssignOrderStatus: Copies the order ID and status (pending) and assigns those values to variables.

• TransformOrder: Transforms the order data into an orderRequest variable.

• InsertOrder: Inserts the order into the ORDER table using a database adapter.

Figure 2-27 shows the InsertOrderIntoDB scope in detail.

Figure 2-27 InsertOrderIntoDB Scope

Where to Find Implementation Details

Following are the sections of the Oracle SOA Suite Developer's Guide that describe how to develop the types of components used in the InsertOrderIntoDB scope:

• Assigning values to variables: The AssignOrderStatus activity assigns the order ID number and status to variables that will be used within the scope. For more information about using and assigning variables, see Section 7.4, "Using an Assign Activity".

• Transforming data: The order data is transformed from the message content, as received from the ESB flow, to data that the database adapter accepts. For more information about transforming data, see Section 7.5, "Creating a Transformation".

• Invoking a service: The Order database service is invoked, which allows the order data to be persisted to the database. For more information about using a database adapter, see Section 7.6, "Communicating with a Database".

2.5.3.3.2 CustomerService Scope

The CustomerService scope includes the following activities:

• AssignRequest: Copies the customer's ID and assigns the value to a variable.

• GetCustInfo: Invokes the Customer service synchronously, using the customer ID to obtain customer information.

• AssignInitialCustomerResponse - Copies the purchase order from the ESB flow to a variable in the BPEL flow.

• AssignCustomerResponse: Copies the customer's first and last name and assigns the values to variables.

Figure 2-28 shows the CustomerService scope in detail.

Figure 2-28 CustomerService Scope

Where to Find Implementation Details

Following are the sections of the Oracle SOA Suite Developer's Guide that describe how to develop the types of components used in the CustomerService scope:

• Sychronously invoking a service: The GetCustInfo activity uses a synchronous call to the CustomerService web service to obtain the customer's first and last name, given the customer ID. For more information about creating a synchronous call to a service, see Section 7.3, "Invoking a Web Service".

• Creating a partner link to a service: The CustomerService partner link accesses the CustomerService web service in order to retrieve customer information. For more information about creating partner links, see Section 7.3.1.1, "Creating a Partner Link".

2.5.3.3.3 CreditService Scope

The CreditService scope includes the following activities:

• InitializeRequest: Copies the credit card type and number from the customer data and assigns the values to variables.

• InvokeCreditService: Invokes the CreditValidatingService web service with a synchronous call that includes the credit card number and type. The service replies with either a valid or not valid response.

• Generic switch activity: An expression in the switch task states that if the service returns a response stating that the card is not valid, an error must be thrown. The switch contains the following two activities:

  • AssignFault: Assigns the value "Credit Problem" to the status variable.

  • ThrowCreditFault: Invokes the OrderBookingFault. For more information, see Section 2.5.3.3.11, "OrderBookingFault Scope".

Figure 2-29 shows the CreditService scope in detail.

Figure 2-29 CreditService Scope

Where to Find Implementation Details

Following are the sections of the Oracle SOA Suite Developer's Guide that describe how to develop the types of components used in the CreditService scope:

• Creating a conditional branch using a switch activity: The switch activity allows you to create conditional cases. The flow follows that path that evaluates to true. For more information about creating conditional branches, see Section 7.7, "Creating Conditional Branching Using a Switch Activity".

• Handling a fault: When the credit service returns a message stating that the card is invalid, the flow must handle this as a fault, because the flow will not be able to continue. For more information about handling faults, see Section 7.10, "Handling Faults".

2.5.3.3.4 RequiresManualApproval Scope

The RequiresManualApproval scope includes the following activities:

• BPEL_Header: Gets information about the BPEL flow and assigns that information to variables.

• BPEL_Var_To_Rule_Facts: Assigns purchase order price and customer status variable value to facts that will be used by a rule to determine whether the order needs manual approval.

• Facts_To_Rule_Service: Assigns the facts to a variable.

• Invoke: Invokes the Decision Service, which in turn, invokes the rule to determine whether the order needs to be manually approved.

• Rule_Service_To_Facts: Takes the response (whether or not the order requires manual approval), and sets the value to a rule fact.

• Facts_To_BPEL­_Var: Assigns value of the rule fact to a variable.

Figure 2-30 shows the RequiresManualApproval scope in detail.

Figure 2-30 RequiresManualApproval Scope

Where to Find Implementation Details

Following are the sections of the Oracle SOA Suite Developer's Guide that describe how to develop the types of components used in the RequiresManualApproval scope:

• Creating business rules: The flow uses a business rule to determine whether or not an order requires manual approval. If the customer's status is platinum, no approval is required. If the customer's status is gold, and the order is over $1,000, the order requires manual approval. If the customer is silver, the order requires manual approval. For more information about creating rules, see Chapter 8, "Creating and Using Rules for a Decision Service".

• Using the Decision Service to invoke business rules: While you can create rules that can be invoked throughout an application, the rules in the SOA Order Booking application are invoked from the BPEL flow using the Decision Service. For more information about using the Decision Service, see Section 7.8, "Using Business Rules and a Decide Activity".

2.5.3.3.5 RequiresApproval Switch

The RequiresApproval switch is executed only if the decision service determines that the order requires manual approval. It contains the following activities:

• ApproveOrder_AssignTaskAttributes: Takes order attribute values needed to approve the order and assigns the values to variables.

• ApproveOrder_AssignSystemTaskAttributes: Takes process flow attribute values required for approval and assigns the values to variables.

• InitiateTask_ApproveOrder: Invokes a human workflow with an asynchronous call to the TaskService web service.

• ReceiveCompletedTask_ApproveOrder: The response from the human workflow is received.

• Switch task: Determines the flow based on whether or not the order was approved.

  • Outcome is Reject: If the order was rejected, the flow throws the Order Booking fault.

  • Outcome is Approve: If the order was approved, the flow simply continues.

  • Otherwise: Used if the task outcome is expired, stale, withdrawn, or rejected.

Figure 2-31 shows the RequiresApproval switch in detail.

Figure 2-31 RequiresApproval Switch

Where to Find Implementation Details

When an order requires manual approval, the BPEL flow invokes the TaskService web service to start the human workflow to approve the order. This service is invoked asynchronously, sending information into the workflow. This workflow provides a web-based interface that allows a user to complete the assigned task. Figure 2-32 shows the web page that allows the manager to approve the order. Once the order is approved, information is sent back into the BPEL flow, again using an asynchronous call. For more information about using the Task Service, see Section 7.12, "Creating a Human Workflow Task".

Figure 2-32 Workflow Web Page

2.5.3.3.6 SelectSupplier Scope

The SelectSupplier scope contains parallel flows that send information to two different suppliers. The suppliers each return a price for the order. A switch activity then determines which supplier will be used to fulfill the order based on an evaluated condition. The SelectSupplier scope includes the following activities:

• GetSelectMfrQuote: A flow that sends order information in an asynchronous call to Select Manufacturer. This flow includes the following activities:

  • TransformSelectRequest: Takes order information and transforms it into parameters needed by Select Manufacturer in order to complete a quote.

  • InvokeSelectManufacturer: Invokes the SelectService web service, sending the information as transformed in the previous activity.

  • ReceiveSelectManufacturer: Receives the asynchronous response from Select Manufacturer and stores it as a variable.

• CallRapidManufacturer: A flow that sends order information in a synchronous call to Rapid Manufacturer. This flow includes the following activities:

  • TransformRapidRequest: Takes order information and transforms it into parameters needed by Rapid Manufacturer in order to complete a quote.

  • InvokeRapidManufacturer: Invokes the RapidService web service to obtain a quote from Rapid Manufacturer.

• SelectByPrice Switch: An expression determines which manufacturer will be assigned the order. If the Select Manufacturer price is less than the Rapid Manufacturer price, the order is assigned to Select Manufacturer. Otherwise, it is assigned to Rapid Manufacturer. Depending on the outcome, one of the following activities is invoked:

  • AssignSelectManufacturer: Assigns the value for the price and Select Manufacturer to variables.

  • AssignRapidManufacturer: Assigns the value for the price and Select Manufacturer to variables.

Figure 2-33 shows the SelectSupplier scope in detail.

Figure 2-33 SelectSupplier Scope

Where to Find Implementation Details

Following are the sections of the Oracle SOA Suite Developer's Guide that describe how to develop the types of components used in the SelectSupplier scope:

• Creating parallel flows: The two flows that call out to the suppliers happen simultaneously. For more information about creating parallel flows, see Section 7.9, "Creating a Parallel Flow".

• Asynchronously invoking a service: The flow invokes the SelectService web service using an asynchronous call. The service then sends a separate reply back into the flow.

2.5.3.3.7 PostFulfillmentReq Scope

The PostFulfillmentReq scope invokes an ESB flow used to determine the shipping vendor. It contains the following activities:

• InitializeRequest: Assigns the value of a variable that represents the purchase order to a variable that will be used in an ESB flow.

• PostFulfillmentReq: Invokes the OrderFulfillment ESB flow, passing in the variable value. For more information about this ESB flow, see Section 2.5.3.4, "OrderFulfillmentESB Flow".

Figure 2-34 shows the PostFulfillmentReq scope in detail.

Figure 2-34 The PostFulfillmentReq Scope

Where to Find Implementation Details

The PostFulfillmentReq activity invokes an ESB flow. For more information about invoking an ESB flow, see Section 7.3, "Invoking a Web Service".

2.5.3.3.8 SetFinalOrderStatus Scope

The SetFinalOrderStatus scope uses a database adapter to update the status of the order in the ORDERS table. The SetFinalOrderStatus scope includes the following activities:

• AssignOrderStatus: Copies the order ID and status (completed) and assigns those values to variables.

• UpdateOrderStatus: Invokes the database adapter and uses the variables to update the status of the order.

Figure 2-35 shows the SetFinalOrderStatus in detail.

Figure 2-35 SetFinalOrderStatus Flow

Where to Find Implementation Details

The Order database service is invoked, which allows the order data to be persisted to the database. For more information database adapters, see Section 7.6, "Communicating with a Database".

2.5.3.3.9 NotifyCustomer Scope

The NotifyCustomer scope invokes the Notification service to let customers know that their order has been fulfilled. The NotifyCustomer scope includes the following activities:

• Assign: Assigns order and customer variable values to variables that will be used by the Notification service to create the email.

• NotifyCustomer: Invokes the Notification service to send the email.

Figure 2-36 shows the NotifyCustomer scope in detail.

Figure 2-36 NotifyCustomer Scope

Where to Find Implementation Details

The NotifyCustomer activity invokes the Notification service, passing in variables that will be used to create an email notification. The Notification service then sends the email. For more information about the Notification service, see Section 7.13, "Creating an Email Notification".

2.5.3.3.10 CallbackClient Activity

The CallbackClient activity invokes the web client, as shown in Figure 2-37. This activity sends a response message back to the client, with the status of the order.

Figure 2-37 CallBackClient Scope

2.5.3.3.11 OrderBookingFault Scope

The OrderBookingFault scope is a generic fault that is invoked whenever a fault is encountered in the flow. The OrderBookingFault scope includes the following activities:

• AssignOrderStatus: Assigns variable values for the order and status.

• SetFaultedOrderStatus: Sets the status of the order to Cancelled, using a database adapter.

Figure 2-38 shows the OrderBookingFault scope in detail.

Figure 2-38 OrderBookingFault

Where to Find Implementation Details

The OrderBookingFault scope is used to handle all exceptions and errors thrown in the process flow. For more information about creating a fault for the flow, see Section 7.10, "Handling Faults".

2.5.3.4 OrderFulfillmentESB Flow

The OrderFulfillmentESB flow determines which vendor (USPS or Federal Express) will ship the order. The determination is made based on routing rules. This flow includes the following services:

• OrderFulfillment routing service: Routes order information to the Shipment routing service. It also routes a message to the FulfillmentBatch JMS adapter.

• Shipment routing service: Routes order information to FedEx when the order total is greater than $500. Routes order information to the USPS when the order is less than $500. It then transforms the information into a message understood by FedEx or USPS, as appropriate.

• FedexShipment database adapter: Sends order information to FedEx, and inserts it into the FEDEXSHIPMENT database table.

• USPSShipment database adapter: Sends order information to USPS.

• FulfillmentBatch JMS adapter: Uses the JMS adapter to send a completion message back into the BPEL flow.

Figure 2-39 shows the OrderFulfillmentESB flow in detail.

Figure 2-39 OrderFulfillmentESB Flow

Where to Find Implementation Details

Following are the sections of the Oracle SOA Suite Developer's Guide that describe how to develop the components used in the OrderFulfillmentESB flow:

• Routing messages to endpoints: The Shipment routing service is used to determine which vendor to use based on a set of rules. For information about adding a routing service to ESB, see Section 6.9, "Adding Routing Services to Oracle Enterprise Service Bus".

• Populating database tables: Database adapter services can be used to populate or query database tables. For more information, see Section 6.8, "Adding Adapter Services to Oracle Enterprise Service Bus".

• Placing messages on a JMS queue or topic: JMS adapter services can be used to consume or produce messages and place them in the JMS queue. For more information, see Section 6.8, "Adding Adapter Services to Oracle Enterprise Service Bus".

2.5.4 Adding Security to the System

While the SOA Order Booking application does not incorporate security, you can use Oracle WSM to protect web services and process flows in a service-oriented environment, without having to modify either client applications or web services.

Oracle WSM secures your services environment with these key components:

• Oracle WSM Policy Manager: Allows you to define policies that reflect operational best practices and requirements. It includes a browser-based tool for creating and maintaining security and management policies for web services and business processes, using prebuilt or custom policy steps

• Oracle WSM Gateways: Gateways provide a nonintrusive mechanism for policy enforcement.

• Oracle WSM Agents: Also serving as policy enforcement points, agents are lightweight components that run in the same "container" or application server environment as the web service. Oracle Web Services Manager provides two types of agents, a client agent and a server agent:

• Oracle WSM Monitor: The Oracle WSM Monitor component manages collection and aggregation of web services traffic data and provides alerts and notifications. For an overview of the monitor, see Section 2.5.5.4, "Oracle Web Services Manager Monitor".

For more information about using Oracle WSM, see Chapter 10, "Securing the System".

2.5.5 Monitoring the System

Once an order is in-flight, you can monitor its process through the ESB and BPEL process flow using Oracle Enterprise Service Bus Control and Oracle BPEL Control. You can also view the status of the system in general, using Oracle Enterprise Manager. If you apply security to any services in the SOA system, you can monitor that security using Oracle Web Services Manager Control Console.

2.5.5.1 Oracle ESB Control

Oracle ESB Control is a browser-based tool that allows you to monitor message instance processing across an ESB flow in a schematic diagram that is a representation of the ESB flow. Using this diagram, you can:

• View all connections to the ESB

• View details of the ESB, including the URLs required to call ESB services from applications that are external to ESB

• View error conditions within a schematic, including any messages that did not reach their destination

• Correct error conditions, including resubmitting failed messages

Figure 2-40 shows the ESB Control as it might be used to view a successful message processing.

Figure 2-40 ESB Console - Instances View

Description of "Figure 2-40 ESB Console - Instances View"

For more information about using Oracle ESB Control, see Chapter 12, "Monitoring Oracle Enterprise Service Bus".

2.5.5.2 Oracle BPEL Control

Oracle BPEL Control is a browser-based tool for managing the life cycle of a BPEL process. Using Oracle BPEL Control, you can:

• View deployed, running, and completed processes

• Manage the process life cycle, including recovery of any failed messages within an instance, and initiate processes

• Enter test data and directly initiate processes, thus allowing you to test processes before deploying to the SOA system

• View process instances

• View process activities

Figure 2-41 shows the BPEL Control displaying an SOAOrderBooking process instance, as it waits for manual approval.

Figure 2-41 SOA Order Booking Instance in Oracle BPEL Control

For more information about using Oracle BPEL Control, see Chapter 13, "Monitoring Oracle BPEL Process Manager".

2.5.5.3 Oracle Enterprise Manager Control Console

Oracle Enterprise Manager 10g Application Server Control Console is a web-based user interface that allows you to monitor applications within OC4J. Using Enterprise Manager, you can monitor:

• An OC4J instance

• The cluster topology

• Deployed applications

• Web module and EJB module performance

• JVM metrics

Figure 2-42 shows Enterprise Manager as it might be used to monitor performance of the J2EE container.

Figure 2-42 Container Performance

For more information about using Enterprise Manager to monitor the system, see Chapter 15, "Monitoring SOA Applications with Enterprise Manager".

2.5.5.4 Oracle Web Services Manager Monitor

Oracle Web Services Manager Monitor is a browser-based tool that allows you to monitor the status and performance of the managed services used within your SOA system, including extensive features that enable you to monitor the operational health of the components (gateways and agents) that you set up to secure your web services.

Using Web Services Manager Monitor, you can:

• View execution metrics

• View security statistics

• View service statistics

• View alarms

• Manage security roles

Figure 2-43 shows Web Services Manager Monitor, as it might be used to monitor security statistics.

Figure 2-43 Monitoring Security