JDeveloper
Oracle BPEL Process Manager (including Human Workflow)
ESB
Oracle Business Rules
Oracle Application Server
Specifically, the following applications comprise the SOA Order Booking application:
CreditService: Validates customer credit information
CustomerService: Represents an existing customer relationship management (CRM) application within the Global Company enterprise. CustomerService is implemented using EJB 3.0.
DHLShipment: Ships the order using DHL. It is a SOAP service.
FulfillmentESB: Routes order information to a shipping vendor for shipment. Uses ESB content-based routing to invoke the correct vendor, such as Fedex or USPS, depending on the price of the order. In Chapter 4, you will utilize the DHLShipment service, so orders can be also be shipped by DHL. Also, demonstrates that messages can be routed using a variety of adapters for writing to a database, a file, and a JMS queue.
OrderBookingESB: Routes order information from the Web client and invokes the Order Booking BPEL process (SOAOrderBooking).
RapidService: Provides a price for a given order (to compete with the price from SelectManufacturer). This service is used to demonstrate invoking a synchronous process from BPEL.
SelectManufacturer: Provides a price for a given order (to compete with the price from RapidService). This service is used to demonstrate invoking an asynchronous process from BPEL.
SOADEMO-CLIENT: Web-based application that enables end users to register themselves as customers, and then order electronics online from Global Company.
SOAOrderBooking: Processes the order and orchestrates all necessary services within the enterprise to complete the order.
At the center of the SOA Order Booking application is the SOAOrderBooking BPEL process. It orchestrates all the existing services in the enterprise for order fulfillment with the right supplier, based on the business rules in the process.
When a new customer registers in the Web client, the Web client sends the customer's information to the internal customer service application (CustomerService), which then stores the customer information in a database. The authenticated customer can then browse products, add them to their online shopping cart, and place the order.
When a registered customer attempts to log on to the Web client, the customer service application (CustomerService) is invoked and provides authentication.
When a new order is placed, the following occurs:
The Web client sends a message to the Order Booking ESB project (OrderBookingESB). ESB then routes the message to any service that has registered an interest in these messages. In this case, it is only the Order Booking BPEL process (SOAOrderBooking) that gets notified, thereby invoking the BPEL process.
The BPEL process sets the order to pending, and writes the order to the order database tables.
The registration process sets the default customer status to Gold. The database administrator can apply one of the following statuses to registered customers:
Platinum
Gold
Silver
The BPEL process calls the customer service (CustomerService) to retrieve customer ID, name, address, and credit card information.
The BPEL process then checks the identified customer against the credit service (CreditService) to verify the customer's credit card is valid. The credit service returns the relevant rating for the customer.
If credit is not approved, the process cancels the order.
If credit is approved, the process takes the order amount, customer status, and runs the Oracle Rules Engine to determine if the order requires approval by management.
The BPEL process uses a decision service (Oracle Rules Engine) to determine.
The decision service uses rules in the Oracle Rules Engine that state the following:
If the customer has a Platinum status, then no manual approval is required.
If the customer has a Gold status, then manual approval is only required for orders over $1000.
If the customer has a Silver status, then manual approval is required for all orders, regardless of the order amount.
These decisions could also have been implemented in the BPEL process, but a rules engine was used instead so that changes could be made at runtime without have to make a design-time change or re-deploy. Moreover, business analysts or non-technical, non-administrator type people can change the rules.
For those orders requiring manual approval, the BPEL process invokes the human workflow, which routes a message to a manager.
If the order is approved, it is sent to two suppliers for their price quotes.
The select manufacturer service (SelectManufacturer) tends to quote a lower price, because it is a direct manufacturer, but has slow turnaround times for a response. It sends the quote asynchronously.
The rapid manufacturer service (RapidService) tends to quote a higher price, because has an automated response service for price quotes. It sends the quote synchronously.
The BPEL process collects the quotes and selects the lowest quoted price as the supplier to which to award the order.
The BPEL process invokes the Fulfillment ESB project (FulfillmentESB), which in turn uses a message flow to complete the order as follows:
If the order is less than $500, the order information is sent to USPS. Their system picks up orders from a directory so we use the file adapter to write the order to a file in the specified directory.
If the order is equal to or greater than $500, the order information is sent to Fedex. The Fedex system waits for rows to appear in a table, so the database adapter is used to write the order to the specified table in their database.
All orders, regardless of the shipping vendor, are stored in a temporary queue and uploaded to the fulfillment system in batch mode overnight. The JMS adapter is used to write the order information to the specified JMS queue.
Once the order is fulfilled, the BPEL process sets the order to complete, and starts a notification service, which sends the customer an email with the purchase order information.
No comments:
Post a Comment