3 Creating a Credit Validation System
This chapter includes the following sections:
3.1 Business Challenge
Company X has embarked upon a project to improve customer satisfaction. A key area for improvement is the need to streamline the ordering process to provide better order tracking visibility through the following parts of the ordering life cycle:
-
Credit approvals
-
Fulfillment
-
Shipment
-
Delivery
A key issue in their current system is that credit card payments are often denied for minor reasons. Since the process to correct these issues varies across Company X's order entry systems, there is no consistent follow-up and resolution to customers. Orders become lost and delayed in the system, causing customer dissatisfaction.
Company X has determined that a new credit card fraud detection system must also be in place at year's end to eliminate credit card abuses. A consistent fraud mechanism requires the credit validation process to be consolidated across all order entry systems.
The first step is to provide a consistent interface for all order entry applications for credit validation. The consolidated credit validation service is to be initially hosted in-house to control quality. However, once the interface is stabilized, this service is to be outsourced to a third party provider. In the future, when Company X decides to outsource credit validation to an external provider, this can be accomplished without impacting existing applications.
3.2 Business Solution
To address this business challenge, Company X designs a business solution that uses the components described in Table 3-1.
Table 3-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 validate payments and return status. If payment is denied, an order is not processed. The composite consists of the following components, each of which is briefly described below:
|
SOA composite applications consist of the following:
|
|
The BPEL process (and its activities) orchestrates the validation of credit card payments and returns a payment status (invokes a database adapter). |
BPEL processes provide a comprehensive and easy-to-use infrastructure for creating, deploying, and managing business processes. BPEL is the standard for assembling discrete services into an end-to-end process flow. BPEL processes orchestrate and build process automation. |
|
The database adapter stores and retrieves credit card payment information from the database, including payment type, card number, expiration date, card name, and daily limit. If the credit card number is not available in the database, payment is denied. |
The database adapter enables Oracle SOA Suite and Oracle Fusion Middleware to communicate with database endpoints. These include Oracle database servers and any relational databases that follow the ANSI SQL standard and provide JDBC drivers. |
|
A BPEL scope activity template is imported that includes a transformation activity that determines the payment status (authorized or denied) based on the daily limit and total order amount. |
A SOA template is a reusable part of an Oracle SOA Suite project that you use to create new projects. There are three types of templates:
|
|
The composite sensor tracks credit card payment status. |
Composite sensors provide a method for implementing trackable fields on messages. |
|
Oracle Service Bus |
Oracle Service Bus provides the following composite registration and security benefits:
|
Oracle Service Bus is a configuration-based, policy-driven enterprise service bus. It provides highly scalable and reliable service-oriented integration, service management, and traditional message brokering across heterogeneous IT environments. |
Figure 3-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 3-1 are used to address the credit validation business challenge.
3.2.1 Creating a Credit Validation Composite
The business solution is designed in a SOA composite application that validates a credit card payment and returns a payment status. If the payment is denied, the order is not processed. The implementation of this service uses a BPEL process to invoke a database adapter to retrieve the credit card data from the database and perform the validation. The service returns a payment status of either authorized or denied.
Figure 3-2 provides an overview of the credit validation composite. Customer requests come through the validatepaymentprocess service. The SOA composite application (named validatePayment) takes these requests and invokes a database adapter reference named getPaymentInformation to retrieve credit card information from the database. The database adapter is configured with the Adapter Configuration Wizard.
The following example shows the content of an inbound order message. The customer provides their credit card number, expiration date, card type, and billing address.
<soas:Billing >
<soas:CardPaymentType>1</soas:CardPaymentType>
<soas:CardNum>1234123412341234</soas:CardNum>
<soas:ExpireDate>0316</soas:ExpireDate>
<soas:CardName>AMEX</soas:CardName>
<soas:BillingAddress>
<soas:FirstName>Joe</soas:FirstName>
<soas:LastName>Smith</soas:LastName>
<soas:AddressLine>555 Beverly Lane</soas:AddressLine>
<soas:City>Hollywood</soas:City>
<soas:State>CA</soas:State>
<soas:ZipCode>12345</soas:ZipCode>
<soas:PhoneNumber>5127691108</soas:PhoneNumber>
</soas:BillingAddress>
</soas:Billing>3.2.2 Retrieving Credit Card Payment Information from the Database
All available credit card details are stored in a database, including payment type, card number, expiry date, card name, and daily limit. The database adapter retrieves credit card payment information from the database, using the customer's credit card number as the key.
The validation process includes three steps:
-
The payment information is first retrieved from the database, using the credit card number quoted in the order message as the key. If there is no data available with this credit card number, payment is denied.
-
If data for the credit card number is available, the expiration date in the database record is compared to the expiration date in the order message. If they are not the same, the payment is also denied.
-
The last check compares if the total order amount is less than the daily limit on the credit card in the database.
If all tests are successful, payment is authorized. Otherwise, payment is denied.
To invoke the Adapter Configuration wizard, the database adapter is dragged from the Components window into the External References swimlane of the SOA Composite Editor. This action invokes the Adapter Configuration Wizard for configuring the database adapter.
3.2.2.1 Configuring the Database Adapter with the Adapter Configuration Wizard
The following database adapter configuration tasks are performed during execution of the Adapter Configuration Wizard.
-
The option to create a connection to the database in which the credit card information is stored is selected, as shown in Figure 3-3. This enables the database adapter to access the database and retrieve the appropriate credit card information.
-
The Select database option is chosen to create a database query, as shown in Figure 3-4.
-
The appropriate credit card information table is imported from the database, as shown in Figure 3-5.
Figure 3-5 Table with Credit Card Information Imported
Description of "Figure 3-5 Table with Credit Card Information Imported" -
The appropriate credit card filtering information to use in creating the Select operation database query is enabled, as shown in Figure 3-6.
-
Expiration date
-
Daily limit
-
Current limit
-
-
The appropriate credit card criteria for the Select operation is specified, as shown in Figure 3-7. The ccnb parameter is provided for the customer's credit card number that is specified in the inbound message (
CardNum), as shown in Creating a Credit Validation Composite. The database adapter retrieves credit card payment information from the database, using the credit card number as the key.The database adapter processes the selections and generates a reference that implements the operation specified. The SOA composite application now contains the WSDL file to represent the database adapter reference: getPaymentInformation.wsdl. The composite diagram shown in Figure 3-2 shows the getPaymentInformation reference.
3.2.3 Invoking the Database Adapter from the BPEL Process
Company X creates a BPEL process service component in the SOA composite application. The BPEL process orchestrates the logic of the business solution. An invoke activity in the BPEL process invokes the database adapter as a partner link to retrieve credit card information from the database. Figure 3-8 provides details.
Figure 3-8 BPEL Process Invocation of the getPaymentInformation Reference
Description of "Figure 3-8 BPEL Process Invocation of the getPaymentInformation Reference"
Within the BPEL process, the invoke activity calls the database adapter (named getPaymentInformation), as shown in Figure 3-9. You can create and edit invoke activities details from the Property Inspector below the designer or by double-clicking the invoke activity.
-
Name
-
Partner link to invoke (for this example, the database adapter)
-
Port type
-
Operation to perform
-
Input variable under the Input tab (contains the credit card number to send to the database adapter)
-
Output variable under the Output tab (returns the results from the database adapter)
Figure 3-9 Invoke Activity Invoking the Database Adapter
Description of "Figure 3-9 Invoke Activity Invoking the Database Adapter"
An assign activity is used to populate the input variable in the invoke activity. In the Copy Rules tab of the assign activity (named setCreditCardNumber), the credit card number passed into the BPEL process as CardNum is assigned to the ccnb parameter of the getPaymentInformation database adapter. Figure 3-10 provides details.
Figure 3-10 Credit Card Number Assigned to the Input Variable
Description of "Figure 3-10 Credit Card Number Assigned to the Input Variable"
An XSLT map determines if the payment is valid based on the information returned by the database adapter.
3.2.4 Calculating Payment Status with XSLT Transformations
Company X requires a mechanism for determining if payment status is authorized or denied. To address this requirement, an XSLT transform activity determines if the payment is valid based on the following information returned by the database adapter.
-
The daily limit (retrieved from the database)
-
The total order amount (authorization amount in the order message, which has been calculated in the process order project by multiplying the price and amount of every order item and adding them). The total amount of the order must be smaller than the daily limit on the credit card.
XSLT transformation design can be packaged in the following ways:
-
Within an individual transform activity in a BPEL process
-
As part of a template. Templates enable you to share common code between applications, composites, and processes. You create a template once, then share it as needed. The template can be reused multiple times. Three types of templates are supported:
-
Project templates that provide a complete project with all components and resources.
-
Service component templates such as a BPEL process with all references and components.
-
Custom activity templates that consist of a BPEL process scope activity.
-
Company X decides to use a template. For this example, a custom activity template is created and then imported that consists of a scope activity with a transform activity.
You create and design templates in Oracle JDeveloper. After creation, templates are displayed in the Components window for selection and use, as shown in Figure 3-11. The custom activity template can be dragged into a BPEL process, as needed.
The custom scope activity consists of the transform activity. The transformation for this example expects two input variables, as shown in the Sources section of Figure 3-12.
-
An output variable of the database adapter, which includes the payment information stored in the database.
-
An input variable of the BPEL process, which includes the total order amount.
The output is in the status field of the output message, as shown in the Target Part section of Figure 3-12. This field is either set to Denied or Authorized.
The mapping in the XSLT Map Editor is shown in Figure 3-13.
Figure 3-13 Transformation in the XSLT Map Editor
Description of "Figure 3-13 Transformation in the XSLT Map Editor"
3.2.5 Tracking Payment Status with Composite Sensors
Company X must be able to track the status of order payments (either authorized or denied). To address this requirement, composite sensors are used. Composite sensors provide a method for implementing trackable fields on messages. Composite sensor data is persisted in the database during runtime, enabling you to search for all authorized or denied payments.
Composite sensors enable you to perform the following tasks:
-
Monitor incoming and outgoing messages.
-
Locate particular instances by searching for specific sensor details in Oracle Enterprise Manager Fusion Middleware Control.
-
Publish JMS data computed from incoming and outgoing messages.
-
Track composite instances initiated through business event subscriptions.
The composite sensor is defined on the inbound SOAP web service binding component, as shown in Figure 3-14. You can also define composite sensors on reference binding components and service components that have business event subscriptions.
Figure 3-14 Composite Sensor Definition on a SOAP Service Binding Component
Description of "Figure 3-14 Composite Sensor Definition on a SOAP Service Binding Component"
The Create Composite Sensor dialog shown in Figure 3-15 shows that an XPath expression is defined to track the payment status (authorized or denied). The Enterprise Manager check box is also selected. This enables you to view composite sensor names and values (for example, Status=Authorized) in the Flow Instances page of Oracle Enterprise Manager Fusion Middleware Control.
The sensor is displayed as an icon on the validatepaymentprocess SOAP web service binding component. When you place your cursor over the icon, the composite sensor definition is displayed. Figure 3-16 provides details.
3.2.6 Deploying the validatePayment Composite
Company X deploys the validatePayment composite in Oracle JDeveloper, as shown in Figure 3-17.
Figure 3-17 validatePayment Composite Deployment
Description of "Figure 3-17 validatePayment Composite Deployment"
During the deployment process, the composite is deployed to the server on which an application server connection was created in Configuring the Database Adapter with the Adapter Configuration Wizard. Figure 3-18 provides details.
Figure 3-18 Deployment to the Application Server
Description of "Figure 3-18 Deployment to the Application Server"
If there are no compilation errors, the build is successful and deployment starts. Figure 3-19 provides details.
Figure 3-19 Deployment Success Message in Oracle JDeveloper Log Window
Description of "Figure 3-19 Deployment Success Message in Oracle JDeveloper Log Window"
3.2.7 Registering SOA Composite Applications with Oracle Service Bus
Company X must be able to protect validatePayment composite users from routine changes such as deployment location and implementation updates. To address this requirement, Company X registers the validatePayment composite with Oracle Service Bus. Oracle Service Bus scales the service to handle higher volumes of requests and provides resiliency for the service if it is taken down for routine maintenance.
Company X begins by creating an Oracle Service Bus application in which to perform registration. Figure 3-20 provides details. Company X can create proxies, pipelines, and business services by dragging icons from the Components window on the right into the designer. In the Components window, pipeline and split-join icons are displayed. In Release 12c, the pipeline is separated from the proxy to enable it to be a reusable component. Adapters and transports are also displayed for building business services (in the External References swimlane) and proxies (in the Exposed Services swimlane).
Figure 3-20 Oracle Service Bus Application Ready for Design Registration
Description of "Figure 3-20 Oracle Service Bus Application Ready for Design Registration"
When design registration is complete, the business solution looks as shown in Figure 3-21.
Figure 3-21 Oracle Service Bus Application Registration
Description of "Figure 3-21 Oracle Service Bus Application Registration"
The following sections provide an overview of Oracle Service Bus application registration:
3.2.7.1 Sharing Resources with Folders
Company X creates folders into which resources such as XSD and WSDL files are imported. This action is performed by right-clicking the Oracle Service Bus application and selecting New > From Gallery > Folder to invoke the Create Folder wizard.
Oracle Service Bus folders categorize resources and are aligned with the default Schema and WSDL folders that are displayed in the Applications window for the SOA composite application. Folders provide a way to share resources between Oracle Service Bus and the SOA composite application.
After folder creation, Company X imports the artifacts from the file system for building services by selecting File > Import > Service Bus Resources to invoke the Import Service Bus Resources wizard. When artifact selection is complete, the wizard looks as shown in Figure 3-22.
Figure 3-22 Import Service Bus Resources Wizard - Configuration Page
Description of "Figure 3-22 Import Service Bus Resources Wizard - Configuration Page"
When wizard configuration is complete, Figure 3-23 shows the artifacts in the Applications window.
Figure 3-23 Oracle Service Bus Imported WSDL and Schema File Resources
Description of "Figure 3-23 Oracle Service Bus Imported WSDL and Schema File Resources"
3.2.7.2 Registering the Composite URI of the SOA Composite Application
A business service (named ValidateBS in Figure 3-21) registers the composite URI of the SOA composite application and provides a representation of the validatePayment composite. Configuration is performed by dragging an HTTP icon from the Components window into the External References swimlane of the Oracle Service Bus application, as shown in Figure 3-24.
This action invokes the Create Business Service wizard for configuring the following:
-
HTTP as the transport type
-
WSDL as the service type
-
The WSDL file
-
The endpoint URI is set to the validatePayment composite. The endpoint URI format is based on the transport protocol you selected (HTTP). For example:
http://localhost:7101/soainfra/services/default/ValidatePayment/ validatepaymentprocess_client_ep
Company X double-clicks the ValidateBS business service to review the general, transport, performance (result caching), and security policy settings.
3.2.7.3 Configuring Pipelines and Proxies
A pipeline (named ValidatePP in Figure 3-21) contains actions performed on the service bus such as error handling reporting, data transformation, and validation before invoking the composite.
Users invoke the validatePayment composite through a proxy (named ValidatePS in Figure 3-21) rather then connecting directly to the composite. This provides for more agility and flexibility in managing changes. The proxy is the interface to the service from external consumers.
Pipeline and proxy configuration is performed by dragging a Pipeline icon from the Components window into the Components section of the Oracle Service Bus application. This action invokes the Create Pipeline Service wizard for pipeline and proxy configuration. During configuration, Company X selects the WSDL file, as shown in Figure 3-25.
The Expose as Proxy Service check box is also selected on subsequent pages of the wizard. Figure 3-26 provides details.
Figure 3-26 Expose as a Proxy Service Check Box
Description of "Figure 3-26 Expose as a Proxy Service Check Box"
Figure 3-27 shows the ValidatePP pipeline in the Components section and the ValidatePS proxy in the Exposed Services swimlane.
Figure 3-27 Proxy and Pipeline Configuration in the Components Section
Description of "Figure 3-27 Proxy and Pipeline Configuration in the Components Section"
3.2.8 Deploying and Testing
After application design is complete, Company X deploys and tests the application end-to-end by right-clicking the ValidatePS proxy and selecting Run. Figure 3-28 provides details.
The Test Console is displayed from which you can select a payload for testing. A sample payload is generated for you. Figure 3-29 provides details.
Company X tests with a sample authorize payment file, as shown in the following example:
<ns1:PaymentInfo xmlns:ns1="http://www.oracle.com/soasample"> <ns1:CardPaymentType>0</ns1:CardPaymentType> <ns1:CardNum>1234123412341234</ns1:CardNum> <ns1:ExpireDate>0316</ns1:ExpireDate> <ns1:CardName>AMEX</ns1:CardName> <ns1:BillingAddress> <ns1:FirstName>Joe</ns1:FirstName> <ns1:LastName>Smith</ns1:LastName> <ns1:AddressLine>555 Beverly Lane</ns1:AddressLine> <ns1:City>Hollywood</ns1:City> <ns1:State>CA</ns1:State> <ns1:ZipCode>12345</ns1:ZipCode> <ns1:PhoneNumber>5127691108</ns1:PhoneNumber> </ns1:BillingAddress> <ns1:AuthorizationAmount>100</ns1:AuthorizationAmount> </ns1:PaymentInfo>
After importing the sample file, Company X clicks Execute.
Credit validation design and testing is now complete.
3.3 Related Documentation
Table 3-2 provides references to documentation that more specifically describes the components and features described in this chapter.
Table 3-2 Related Topics
| For Information About... | See... |
|---|---|
|
Creating a SOA composite application |
Creating a SOA Application in Developing SOA Applications with Oracle SOA Suite |
|
Creating a database connection |
Creating an Application Server Connection for Oracle JCA Adapters in Developing SOA Applications with Oracle SOA Suite |
|
Configuring a database adapter with the Adapter Configuration wizard |
Oracle JCA Adapter for Database in Understanding Technology Adapters. |
|
Designing transformations with the XSLT Map Editor |
Creating Transformations with the XSLT Map Editor in Developing SOA Applications with Oracle SOA Suite |
|
Creating composite sensors |
Defining Composite Sensors in Developing SOA Applications with Oracle SOA Suite |
|
Creating Oracle SOA Suite templates |
Oracle SOA Suite Templates and Reusable Subprocesses in Developing SOA Applications with Oracle SOA Suite |
|
Creating a business service in Oracle Service Bus |
Developing Service Bus Applications in JDeveloper in Developing Services with Oracle Service Bus
|
|
Adding a pipeline |
Working with Oracle Service Bus Pipelines in Developing Services with Oracle Service Bus |
|
Creating a proxy |
Creating and Configuring Proxy Services in Developing Services with Oracle Service Bus |