SOASuite12c_Tutorial.pdf

(1)

Updated: 7.9.2014 16:50:46

Page 1 of 392

SOA Suite12c Tutorial

(2)

Chapter 1: Quick Start Install Page 2 of 392

SOA Suite 12c Tutorial

SOA Suite 12c Tutorial Overview

The activities in this document aim to introduce you to key new features of SOA Suite 12c:  ‘Quick Start’ install process – Integrated Server

 Everything in JDeveloper – SOA and Service Bus  Templates

 Debugger, Testing

 REST enablement of services  New Adapters

(7)

Chapter 1: Quick Start Install

Please follow the new Developer ‘Quick Start’ install guide available at

http://www.oracle.com/pls/topic/lookup?ctx=fmw121300&id=SOAQS to complete the installation. The installer will:

 Install all components necessary for development with the core of SOA Suite (BPEL, rules, mediator, human work flow, service bus)

 Launch JDeveloper after the installation, automatically registering the IDE plug-ins for SOA and Service Bus.

Have e2e-1201-orderprocessing sample application ready for review, run and deploy.

Please note, while SOA Suite 12c greatly simplifies the initial developer install experience for SOA Suite, all the flexibility and power of domain configuration that was available in 11g is preserved.

Your environment will look like the following within your developer desktop when you are done – typically in about 30 minutes:

SOA Suite 12c Documentation

SOA Suite 12c Documentation is available to view, and download (PDF, Mobi, ePub) from: http://docs.oracle.com/middleware/1213/index.html

(8)

Oracle Confidential – Do not distribute to third parties

Page 8 of 392 Chapter 2: Validate Payment: Build SOA Composites

Chapter 2: Validate Payment

Overview

Avitek has embarked upon an IT modernization project to align with business goals of improving

customer satisfaction. A key area of improvement will be streamlining the order process to provide better visibility tracking orders through credit approvals, fulfillment, shipment and delivery. One key issue in the current system is that credit card payments are often denied for various,

sometimes minor reasons, such as expiration date, etc. Since the process to correct these issues varies across Avitek’s order entry systems, there is no consistent follow-up and resolution with customers. Orders may end up lost or delayed in the system leading to customer dissatisfaction.

The business has indicated a new credit card fraud detection system must be put in place before year’s end to thwart credit card abuses. A consistent fraud mechanism will require the credit validation process to be consolidated across all order entry systems.

The first step will be to provide a consistent interface to all order entry applications for credit validation. Initially, the consolidated credit validation service will be hosted in-house to control quality; however, once the interface is stabilized, this service will be outsourced to a 3rd party provider. In the future, when Avitek decides to outsource credit validation to an external provider, this can be accomplished without impacting existing applications.

In this chapter, you will build your first SOA Suite 12c project. At the end of this chapter, your solution will look like the following from an architectural perspective.

(9)

Page 9 of 392 Chapter 2: Validate Payment: Build SOA Composites

Prerequisites

 Developer (QuickStart) installation is complete. JDeveloper is up and running with The integrated WLS server started. If you need to stop and re-start the server, please follow the instructions in the Appendix of this document.

 Tutorial resources have been downloaded and unzipped to a directory of your choice. When referring to any resources in the following chapters (for example wsdl or sample input), we will always refer directories relative to the unzipped location as ~/e2e-1201-orderprocessing. For example ~/e2e-1201-orderprocessing/sample-input/input.xml.

Part 1: Build a SOA Composite

In this section, you will build your first Oracle SOA Suite 12c composite to validate a credit card payment.

In this composite, credit card payments will be validated and the payment status will be returned. If the payment is denied, the order will not be processed.

Once done, your project should resemble the following.

All available credit cards will be stored in the database, including payment type, card number, expiry date, card name and daily limit.

The incoming order message includes the credit card information. For example, the payment part of the order message would look like this:

<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>Daniel</soas:FirstName> <soas:LastName>Day-Lewis</soas:LastName>

<soas:AddressLine>555 Beverly Lane</soas:AddressLine> <soas:City>Hollywood</soas:City>

<soas:State>CA</soas:State>

(10)

Chapter 2: Validate Payment: Build SOA Composites Page 10 of 392

<soas:PhoneNumber>5127691108</soas:PhoneNumber> </soas:BillingAddress>

</soas:Billing>

The validation process includes three steps:

1. First, the payment information is 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.

2. If data for the credit card number is available, the expiry date in the database record is

compared to the expiry date listed in the order message. If they are not the same, the payment is also denied.

3. 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, the payment is authorized. Otherwise it’s denied.

The implementation of this service uses a BPEL process to retrieve the credit card data from the database and perform the tests outlined above. The service will return either Authorized or Denied as the payment status.

(11)

High-Level Steps

 Create a new composite application e2e-1201-composites and SOA project ValidatePayment.  Leverage the new SOA Project template to create the ValidatePayment composite.

 Review the various components of the composite.  Add a database connection to Java DB.

 Import a custom activity template with an XSLT map to determine the payment status (Authorized or Denied), based on the daily limit and the total amount of order.  Add a composite sensor PaymentStatus for the payment status

 Deploy the project

 Use Debugger in JDeveloper.  Test the project

SOA Templates

In SOA Suite 12c, we have a number of new features to improve sharing of common “code” between teams, departments or even from a partner to a customer. Part of that is the new SOA Templates feature. As the name suggests, they will be used as starting points in the development of SOA applications.

These templates will either be the foundation of a project or can be added to an existing project. From that point on it will not be visible anymore that a template has been used.

All changes made after the import point will not be reflected in the original template. The SOA templates come in three flavors:

 Project templates: They include a complete project with all components and resources used and

will be used when creating a new project in your SOA application.

 Component templates: A component with all references resources and components. For

example, a BPEL process that calls a business rule or adapter can be packaged as component template. The component does not have to be complete and does not have to compile. A component template can be added to an existing project.

Component templates will be visible in the composite palette if they’re available in the template path, configured in JDev.

 Custom activity templates: A scope in a BPEL process, which may include an invoke/receive

from/to a partnerlink, can be packaged as a custom BPEL activity. For example, an assign activity and a call to an adapter. Those custom activities will be available in the BPEL palette.

(12)

Chapter 2: Validate Payment: Build SOA Composites Page 12 of 392 In this section, we will provide the ValidatePayment composite as a SOA Project template.

In order to leverage templates, please follow the steps below:  SOA templates that are located in the default directory (e.g.

$MW_HOME\jdeveloper\integration\templates) will be recognized automatically. Additional

directories can be added.

 As the templates used for the labs have been unpacked into the

~/e2e-1201-orderprocessing/templates/ folder, we will add this directory to the list of folders that are

scanned for templates.

 In the main JDeveloper menu, please go to Tools  Preferences.

 In the Preferences window, go to SOA  Templates. (If you do not see ‘SOA’ in the

preferences, then you could create a new application, or open an existing one. This will load up SOA libraries, SOA preference will show up).

(13)

Chapter 2: Validate Payment: Build SOA Composites Page 13 of 392  Click the ‘

+

’ button, to add folder.

 Navigate to ~/e2e-1201-orderprocessing/ templates.

 Click Select to accept your choice.

(14)

Steps in Detail

Create a new composite application and project

Create a new application. There are various ways and shortcuts to do this, and in this case choose File >

New > Application… from the menu.

 From the Categories tree, click on General > Applications.  Select SOA Application from the Items field.

 Click OK.

 In the subsequent dialog for Create SOA Application, set the following fields, leaving the others with their default values:

a. Application Name: e2e-1201-composites b. Directory of your choice.

(15)

 Click Next.

 When you create a new application, you are prompted to create a new project. Set the following fields:

a. Project Name: ValidatePayment b. Keep the default Directory c. Project Features: SOA Suite

 Click Next.

 The next step allows you to pick either a ‘Standard Composite’, or a ‘SOA Template’. Choose ‘SOA Template’.

(16)

Chapter 2: Validate Payment: Build SOA Composites Page 16 of 392  Select “ValidatePaymentTemplate”. Click Finish.

 A new project “ValidatePayment” is created with some predefined components as derived from the template. You now have a canvas displaying three swim lanes: services, components, and references.

(17)

Chapter 2: Validate Payment: Build SOA Composites Page 17 of 392  On the left hand side, you will see the Application Navigator, which shows all resources

included in a SOA project.

 This Navigator has been reorganized in SOA Suite 12c to make it easier to find all files related to SOA, and also to provide the option to customize the folder structure.

 You will see a SOA folder under the project root. This is where all SOA related files and folders are stored, such as BPEL processes, schema files, WSDL files.

 The composite.xml, which defines the structure of the composite, is located directly under the

SOA folder. In previous releases, this file was just shown as composite.xml. This became

confusing when several composite.xml files from different projects were open at the same time.  In SOA Suite 12c, we now display the project name in the navigator and in the composite tab

(18)

 The SOA folder has a number of subfolders with default names, which hold common SOA artifacts viz. BPEL, XML schemas, WSDL files, transformation-related files and events.  You will see new subfolders created when creating new components.

 The structure and names of the subfolders can be customized to your liking, as long as all folders are located under SOA.

For more information about the Application Navigator, please see Getting Started with Developing SOA Composite Applications.

Concrete wsdl’s are supported for SOA composites now

Composite.xml is labeled same as the project name

(19)

Chapter 2: Validate Payment: Build SOA Composites Page 19 of 392  The composite diagram looks like this.

 The External References swim lane contains the getpaymentInformation database adapter. This step will provide the payment information from the database, using the credit card number as the key. Based on expiry date, daily limit, and total amount of order, we will then calculate whether the payment is authorized or denied.

The database adapter will process your choices, and provides a service that implements the operation specified. The WSDL file to represent that service is getPaymentInformation.wsdl. You can see the .jca file of the getPaymentInformation database adapter, together with two XML files under the Adapters subfolder and the WSDL file of the getPaymentInformation service under the WSDLs subfolder.

A schema file getPaymentInformation_table.xsd has also been created. This is used to set the input and output variable for the DB adapter call.

 In the center (components swim lane) is the validatePayment BPEL Process - it is the component in charge of the orchestration in the SOA Suite. You will add a BPEL Process

component to orchestrate a request to the service you just created with the database adapter. In SOA Suite 12c, BPEL process supports concrete wsdl. This BPEL process will make use of two resource files: ValidatePayment-concrete.wsdl and CanonicalOrder.xsd.

SOA Suite 12c supports BPEL 1.1 and BPEL 2.0 and the default version is BPEL 2.0.

 The Exposed Service validatepaymentprocess_client_ep is the external client web service that will provide input to the BPEL process.

(20)

Create a database connection for adapter to retrieve payment information

Note: Make sure your integrated server is running before doing this step, otherwise Java DB will not be available.

 The first step will provide the payment information from the database, using the credit card number as the key. Based on expiry date, daily limit, and total amount of order, we will then calculate whether the payment is authorized or denied.

 The database adapter getpaymentInformation will connect to the SOA database. In order to do that, it needs a connection which contains all the details needed to connect to the database. The template does not carry the connection information – it leverages the connection(s) configured for the application.

(21)

 In the Create Database Connection dialog, enter the following details



Create Connection In: Application Resources



Connection Name: SOA

(22)

Chapter 2: Validate Payment: Build SOA Composites Page 22 of 392  Server Name (localhost), Port (1527) and Database (soainfra) for the preconfigured Java DB are

filled in automatically.

 Click the Test Connection button and verify that your connection works.  You should see “Success!” like in the screenshot below

 Click OK.

(23)

Chapter 2: Validate Payment: Build SOA Composites Page 23 of 392  Now build your project:

o Click on Build in the main menu o Select Make ValidatePayment.jpr

 You will see the build result in the Messages – Log window (at the bottom of JDeveloper)  If you get an error like the one below, then something is wrong in your composite and it

needs to be fixed.

(24)

Review the validatePayment BPEL process

 _{Double-click the BPEL process to open the BPEL designer.}

Notice the getPaymentInformation partnerlink already in the Partner Links swim lane. It is also connected via the Invoke activity.

 The input and output variables for the adapter call are also defined. They are leveraged when the DB adapter is invoked.

 _{We use Invoke activities when communicating with services, like adapters and web services.}



When defining an invoke activity, you can have the input (and output) variable created

automatically. You can review these invoke activity and the variables using the new Property

(25)



If the Property Inspector window is not open, go to Window  Properties.



If the window is open on the right hand side, you may want to drag and drop it into the middle at the bottom. On the left hand side of the property inspector you will see the same tabs as you would see when opening the activity for editing.

The variable designated for the input will contain the data (the credit card number) that will be sent to the service when it is invoked. It is automatically created with the correct type expected by the service.

The name of the variable is fairly long as it’s a concatenation of the partner link name, the operation and “InputVariable”.

Similarly inspect the Output Variable by changing to the Output tab.

 These variables will be used when interacting with the getPaymentInformation service. The output variable will be populated when the service returns a result, but you need to populate the input variable yourself.

(26)

Chapter 2: Validate Payment: Build SOA Composites Page 26 of 392 In the BPEL process, just above the invoke activity, is the Assign activity setCreditCardNumber. You use an Assign activity to assign data to a variable. In this case, the credit card number is assigned that was passed into the BPEL process to the getPaymentInformation service.

 The assign activity is one of the few activities where you cannot define everything in the property inspector. We need to launch the Assign Editor.

 It assigns the credit card number in the incoming payment information (in the process input variable) to the input variable of the database adapter.

 On the left hand side (source), expand the variable Variables > Process > Variables > inputVariable >

paymentInfo > ns3:PaymentInfo > ns3:CardNum

 On the right hand side (target), expand Variables > Process > Variables >

getPaymentInformation_getPaymentInformationSelect_InputVariable > getPaymentInformationSelect_inputParameters > ns4:ccnb

 Note the mapping from ns3:CardNum on the left to ns4:ccnb on the right.  This creates a new copy rule, which can be seen at the bottom of the editor.

 Click OK to return to the BPEL process.

We don’t need an assign activity for the output variable as we will define an XSLT map to determine if the payment is valid, based on the information returned by the database adapter.

(27)

Calculate payment status using an XSLT map (custom activity template)

 We provide an XSLT transformation to determine if the payment is valid, based on the daily

limit (retrieved from the database) and the total order amount (authorization amount in the

order message, which has been calculated in the process order project by multiplying price and amount of every order item and adding them up).

 The total amount of the order has to be smaller than the daily limit on the credit card.

In this module, the XSLT transformation is provided as a custom activity template.

In order to use the customer BPEL activity template, the directory should be included in the Tools  Preferences  SOA  Templates. We already mapped the folder in a prior section when project template was used.

 In your BPEL process, expand the Custom Activity Templates section in the BPEL activity palette.  If you don’t see the template, close and reopen the BPEL process.

 You should see the CalculatePaymentStatusScope template in the list.

 Drag and drop the CalculatePaymentStatusScope template under the getPaymentInformation invoke activity in the validatePaymentProcess BPEL process.

(28)

Chapter 2: Validate Payment: Build SOA Composites Page 28 of 392  The template dialog shows you the Name and the Description of the template and all artifacts

that are included. You will also see a list of conflicts: The template includes the

CanonicalOrder.xsd, getPaymentInformation_table.xsd, and getPaymentInformation.wsdl

(29)

Chapter 2: Validate Payment: Build SOA Composites Page 29 of 392  You have the option to skip all conflict files, meaning you keep the ones in the composite, or

overwrite all with those in the template. You can also make this decision individually.

 In this case we know that the files are identical and will skip all:

 Select “Skip All” and click OK.

 Adding the custom activity template creates a new scope, which includes an XSLT transformation calculatePaymentStatus.xsl.

 Select the transform activity calculatePaymentStatus, and check out the property inspector window. When you click on the transform activity, it might give the following error message:

Click OK. We will resolve this error message few steps later.

 You will see that the transformation expects two input variables: The output variable of the database adapter, which includes the payment information stored in the database, and the input variable of the BPEL process, which includes the total order amount.

 The output is the status field in the process output message, which will either be set to “Denied” or “Authorized”.

(30)

Chapter 2: Validate Payment: Build SOA Composites Page 30 of 392  If you want to see the definition of the XSLT file, click the edit button at the bottom:

 This opens the mapper file.

 Click Expand All Child Nodes on Source and Target and click on the little plus sign next to the function in the middle.

(31)

Chapter 2: Validate Payment: Build SOA Composites Page 31 of 392  The XSLT map checks whether

o expireDate in order input and DB are the same AND

o AuthorizationAmount (= total order price) is smaller than daily limit on credit card  Save All and close the XSLT Map.

 Now you need to do one more step to get the map to work (remember the error message?)  You may have noticed that the transformation activity uses scope variables, not global variables,

as source and target. That is the case because all variables used in a template are converted into scope variables.

 As the BPEL process already includes variables that can be used in this transformation, you will edit the transform activity to use global variables instead of scope variables.

 Select the transform activity in the BPEL process and in the property inspector, select the first source variable and click the pencil icon to edit:

(32)

Chapter 2: Validate Payment: Build SOA Composites Page 32 of 392  Select the browse button next to the Source Variable field.

 Select the global variable

getPaymentInformation_getPaymentInformationSelect_OutputVariable in the Variable Chooser.

 Click OK.

(33)

Chapter 2: Validate Payment: Build SOA Composites Page 33 of 392  Click OK.

 Repeat the same for the second source variable by replacing it with the process inputVariable.  To edit the target variable, click the browse button next to the Target Variable field.

 The Variable Chooser dialog will be displayed. Select the scope variable outputVariable. This variable will include the payment validation status.

 Click OK.

(34)

Chapter 2: Validate Payment: Build SOA Composites Page 34 of 392  Open the Variables window by clicking the Property Structure icon on top of the BPEL process

and choosing Variables.

 Delete the three scope variables by choosing the variables one by one and clicking the red “X” icon:

(35)

Chapter 2: Validate Payment: Build SOA Composites Page 35 of 392  Repeat this for all three scope variables.

 Close the variables window.

 Save all changes by clicking the Save All icon on top of JDeveloper.

(36)

Chapter 2: Validate Payment: Build SOA Composites Page 36 of 392  If you see errors in the Messages - Log window at the bottom, indicating that a variable doesn’t

exist, make sure the transformation uses the three global variables instead of the scope variables you deleted.

(37)

Add a composite sensor for payment status

Composite sensors provide a method for implementing track able fields on messages. Composite sensors enable you to perform the following tasks:

 Monitor incoming and outgoing messages.

 Locate particular instances by searching for specific sensor details in the EM console.  Publish JMS data computed from incoming and outgoing messages.

 Track composite instances initiated through business event subscriptions.

You define composite sensors on service and reference binding components or on service components that have business event subscriptions in Oracle JDeveloper. This functionality is similar to variable sensors in BPEL processes. During runtime, composite sensor data is persisted in the database.

By adding a composite sensor for payment status, we provide the ability to search for all authorized or denied payments.

 Close the BPEL editor to return to the composite editor.  Right-click on the SOAP service and choose Configure Sensors.

 Choose the validatepaymentprocess_client_ep service.  Click on the blue plus sign to create a new composite sensor.

(38)

 Name it “PaymentStatus”.  Choose the operation “validate”.

 Leave the Enterprise Manager check box selected.

(39)

 Choose Variables.

(40)

(41)

 We won’t define a filter for this sensor.  Click OK.

 _{You now see the sensor in the list.}

 Click OK again.

(42)

 _{When you mouse over, you can see the sensor definition.}

Deploy the SOA composite

The first design iteration is complete and you are now ready to deploy the composite.

Please deploy the application following the steps outlined in section Deploy SOA Projects to the

(43)

Debug a SOA project in JDeveloper

In SOA Suite 12c, we have the ability to set breakpoints in the composite editor, BPEL process and

Service Bus pipeline.

You’re able to stop at breakpoints, look at the data, step into, step out and so on. In a BPEL process, you’re also able to change the value of a variable while debugging.

Set breakpoints in the composite by right clicking on an interface and create a Request or Reply

Breakpoint or both. For one-directional interfaces, you only get one option.

 The breakpoints are little red icons with an arrow pointing in the direction of the flow.

 In a BPEL process, right-click on an activity and choose Toggle Breakpoint. This will set a breakpoint is there is none and remove if there is already a breakpoint.

(44)

Chapter 2: Validate Payment: Build SOA Composites Page 44 of 392  These breakpoints are red dots only without arrow as the flow is always in one direction:

 Set as many breakpoints as you want.  Important:

To make debugging easier for now, you should have a breakpoint at the beginning of every BPEL process to make sure the debugger stops there.

Now start the debugger for your project:

(45)

Chapter 2: Validate Payment: Build SOA Composites Page 45 of 392  You can debug local or remote. When the debugger is started, a window pops up asking which

server you want to use for debugging. It also asks for the debug port (default is 5004 for SOA,

but can be changed) and the timeout for the debugger when inactive.

 Debugger properties are stored per project. If you previously imported a solution from a different machine, the HOST will most likely have to be changed.

 These values can also be stored in the JDeveloper properties and you can skip this dialog in the future if you always want to use the same options.

 Choose your host and leave the defaults.  Click OK.

 If you’ve made changes to your project, it needs to be redeployed. This includes setting of breakpoints.

(46)

Chapter 2: Validate Payment: Build SOA Composites Page 46 of 392  The debugger is ready when you see this message:

 Every web service endpoint now shows a message that you can use the context menu to initialize WS debugging:

 Right-click on the WS interface and choose Initiate WS Debugging

 This opens HTTP Analyzer.

 Fill in all fields or choose HTTP Content at the bottom to be able to copy and paste an xml file instead.

(47)

Chapter 2: Validate Payment: Build SOA Composites Page 47 of 392  Use the sample file provided: PaymentInfoSample_Authorized_soap.xml.

(48)

Chapter 2: Validate Payment: Build SOA Composites Page 48 of 392  Hit Send Request.

 If everything goes well, you should now see the debugger stop at your first breakpoint:

 The active breakpoint turns blue and starts pulsing

(49)

Chapter 2: Validate Payment: Build SOA Composites Page 49 of 392  Step over (F8) to start your BPEL process.

 Step through the BPEL process one activity at a time, using F8, and see how the variable values change.

 If you step through an assign activity, you will see the debugger step through the copy rules that are included in the assign

 If you set a breakpoint at the database adapter, it will jump out of BPEL and back to the composite

(50)

Chapter 2: Validate Payment: Build SOA Composites Page 50 of 392  Note the values that come back from the adapter.

 After the calculate payment activity, the payment status has been set:

(51)

Chapter 2: Validate Payment: Build SOA Composites Page 51 of 392  On the left hand side, you also see the stack trace:

 Finish the debugger by stepping to the end of your BPEL process.  Back in HTTP Analyzer, you can see the result:

NOTE:

Please make sure to terminate the debugger before you continue with the implementation. As long as the debugger is running, you will not be able to edit.

(52)

Chapter 2: Validate Payment: Build SOA Composites Page 52 of 392 Choose Terminate in the pop up window:

For more information on SOA Debugger, please see Debugging SOA Composite Applications with the

(53)

Test the SOA composite

You can test your project following the steps in Test the SOA project with EM FMWC in the Appendix section of this document.

Please also check the audit level on the server, following the steps outlined in section Check the audit

level on the SOA Server in the Appendix section of this document.

When testing in EM FMWC you need to add a SOAP envelope to the test message. In order to make testing easier, we already added the soap envelope to the test messages.

There are two sample message available in “~/e2e-1201-orderprocessing/sample_input to test the validatePayment project: PaymentInfoSample_Authorized _soap.xml,

(54)

Chapter 2: Validate Payment: Register Composite on Service Bus Page 54 of 392

Part 2: Register Composite on Service Bus

Now that you have completed the validatePayment composite, you will register it on Service Bus. Service Bus will protect consumers of the validatePayment composite from routine changes such as deployment location and implementation updates. Service Bus will help scale the service to handle higher volume of requests and provide resiliency for the service if it needs to be taken down for routine maintenance.

You will start by first creating a Business Service to register the composite URI. You will then add a simple Pipeline and Proxy. Pipelines contain actions performed on the Service Bus, typically reporting, data transformation and validation, before invoking the backend service. Consumers of

validatePayment service will invoke via the Proxy rather than connect directly to the composite,

allowing more agility and flexibility in managing change.

If you need documentation help during this section, please consult the Service Bus Documentation. After completing this section, your Service Bus application should look like the following.

View of Service Bus project after Part 2 is complete.

High-Level Steps

During this lab, you will accomplish the following tasks:

 Create a new Service Bus application and new project ValidatePayment.  Create folders and import WSDL and XSD resource.

 Configure a business service for the ValidatePayment composite and review properties.  Create proxy and pipeline and wire to the business service.

(55)

Steps in Detail

Create a new service bus application and project

Create a new Service Bus application. There are various ways and shortcuts to do this, and in this case choose File > New > Application… from the menu.

 _{From the Categories tree, click on General > Applications.}

 Select Service Bus Application with Service Bus Project from the Items field.

 Click OK.

 In the subsequent Create Service Bus Application With Service Bus Project dialog, set the following fields, leaving the others with their default values:

a. Application Name: e2e-1201-servicebus b. Directory of your choice

(56)

 Click Next.

 When you create a new application, you are prompted to create a new project. Set the following fields on Step 2 of 2:

a. Project Name: ValidatePayment

(57)

 Click Finish.

 Double-click the ValidatePayment icon in the Application Navigator on the left-hand side, the Services Bus Overview editor will open on the right.

(58)

Chapter 2: Validate Payment: Register Composite on Service Bus Page 58 of 392 The Overview Editor is a new view for Service Bus in SOA Suite 12c, and modeled from the SOA

Composite Editor.

This view allows you to construct Service Bus projects using a top-down, drag and drop approach. You can create Proxy, Pipeline, and Business Services by dragging icons from the Component Palette on the right, to the lanes of the canvas.

Please take a few moments to browse the Application navigator on the left of the screen and the Component palette on the right.

On the Component Palette, notice the Resources category contains Pipeline and Split-Join icons. These are the components for a Service Bus application. In this release, the Pipeline has been split from the Proxy to allow it to be a re-usable component.

Other Palette categories, Technology, Adapters and Advanced, contain adapters and transports for building Business Services (External References) and Proxy (Exposed Services).

If your Properties window is on the bottom right of the JDeveloper screen, please drag and position it to the bottom center as shown in the above diagram. This will make editing properties of Pipeline actions easier.

(59)

Create folders and import artifacts.

In Service Bus applications, Folders are leveraged to organize artifacts within a Project. For brand new applications, we encourage you to create folders that align with the default folders in your Composite application. Folders will not be automatically created in Service Bus applications so that backward compatibility of Service Bus projects imported from previous releases is maintained.

For this project, we will keep the structure simple since there are only a few artifacts to manage. As your projects grow in subsequent chapters, you will add folders for categorizing artifacts into Business

Service, Proxy and Templates.

 From the ValidatePayment project icon, select New> From Gallery.

(60)

 _{Click OK.}

NOTE: This is only necessary the first time you add a Folder, thereafter it will be listed on the menu

by default.

 When prompted fill in the following properties. a. Folder Name: Schemas

b. Directory: Leave as Default

(61)

 Create WSDLs folder in the same way. When complete your Application Navigator should resemble the following.

 Select the WSDLs folder that you just created in the left-hand navigation pane. We will now import artifacts to build our services.

There are many ways to share artifacts between Service Bus and Composite applications, e.g. source control, MDS backed by source control, etc. For today’s work, you will import the artifacts from the file system.

(62)

Chapter 2: Validate Payment: Register Composite on Service Bus Page 62 of 392  Select File-> Import…

 From the Import dialog, choose Service Bus Resources.

 Click OK.

 A wizard takes you through the steps of importing resources into your project. The title bar of the wizard dialog shows the step number.

(63)

Chapter 2: Validate Payment: Register Composite on Service Bus Page 63 of 392  Import Service Bus Resources - Step 1 of 3, select Resources from URL.

 Click Next.

 Import Service Bus Resources - Step 2 of 3, next to Source URL, click the browse button .

 Be sure you selected the WSDLs folder in your project, then from the WSDL chooser, navigate to ~/e2e-1201-orderprocessing/resources/wsdl folder on your disk and select

(64)

Chapter 2: Validate Payment: Register Composite on Service Bus Page 64 of 392  NOTE: This WSDL assumes that you have unzipped the resources as instructed in prior module

(ValidatePayment SOA composite), and the Schemas folder is at the same level as the wsdl folder containing the CanonicalOrder.xsd. You will need this directory structure to successfully import the WSDL.

 Click OK.

 Click Next.

(65)

Chapter 2: Validate Payment: Register Composite on Service Bus Page 65 of 392  Click Finish. Your left-hand navigation tree should resemble the following:

Configure Business Service for validatePayment composite.

In this section, you will configure a Business Service to represent your validatePayment composite. There are different ways to create artifacts in Service Bus in JDeveloper:

 right-click menu from the left-hand Application Navigator (traditional approach)  drag and drop icons from the Component Palette on to the overview canvas (new)  right click directly on the overview canvas to insert artifacts (new)

We will use the drag and drop Component Palette to build our first Service Bus project; however, feel free to experiment with other mechanisms.

(66)

 Drag and drop the icon from the right Component Palette on to the External References Lane.

A wizard will walk you through the steps of configuring the Business Service. The title bar of the wizard dialog shows the step number.

 Create Business Service - Step 1 of 3 Service Name: ValidateBS

Location : Leave as default

(67)

 Create Business Service - Step 2 of 3:

Select Service Type: WSDL

 Select the icon on the right of the WSDL choice.

 _{When the WSDL chooser appears, first, confirm that Application icon on the top is selected and} expand Application node Application -> ValidatePayment -> WSDLs.

 Select ValidatePayment-concrete.wsdl

(68)

 Confirm that ValidationPaymentPort is selected in the Port field when you return back to the wizard.

 _{Click Next.}

 Create Business Service - Step 3 of 3:

 Confirm http is selected in the Transport field.

 Confirm Endpoint URI is set to your validatePayment composite, it should look similar to this:

(69)

Chapter 2: Validate Payment: Register Composite on Service Bus Page 69 of 392 Click Finish. Your canvas should now resemble the following:

Tip and Trick – How to find composite deployment URI

 _{NOTE: There are several ways to check your deployed endpoint of a Composite. One way is to visit} the EM console (http://localhost:7101/em) and navigate to your composite.

 Click the Test icon on the top right of screen. This will bring up a Web Service test page that lists your deployed endpoint.

 If you need to update your endpoint URI, you can do this as you review the Business Service properties below in the Transport tab.

(70)

Review Business Service Properties

Double-click on your new Business Service in the overview and review the settings for your new business service. There are settings for Performance (Result Caching), Policies for Security. We won’t be settings these right now but you might want to explore what is available.

 General Properties  Transport

 Transport Details  Performance  Security Policy

(71)

Configure Proxy and Pipeline

Now we will create the Proxy and Pipeline to invoke the ValidateBS Business Service. The Proxy will be the interface to the service from external consumers. The Pipeline contains actions that must be performed before invoking the composite. Typical actions are data transform and validation, reporting with error handling; however, for your first Pipeline we will keep it simple.

 Locate the Pipeline icon under Resources on the Component palette. Drag and drop the Pipeline icon from the right onto the middle of the canvas, labeled the “Pipelines/Split Joins” lane.

The Pipeline wizard will walk you through the next steps. The title will show you what step you are on.  Create Pipeline Service - Step 1 of 2:

(72)

 Click Next.

 Create Pipeline Service - Step 2 of 2: Service Type: Select WSDL

 Click on the WSDL chooser icon on the right. Navigate to Application -> ValidatePayment ->

(73)

 Click OK.

 _{Once back on Create Pipeline Service Step 2 of 2:}

a. Ensure the Expose as Proxy Service checkbox is selected. This is the default.

(74)

 Click Finish.

 _{Your canvas should now look like the following – we are almost done!}

 Now we will simply wire the Pipeline to invoke the Business Service.  Select ValidatePP and drag arrow to ValidateBS.

(75)

 The Routing action is automatically configured for you in the Pipeline. Normally you would add some actions to the Pipeline to validate, transform the payload or report for auditing. We will practice this in subsequent chapters. For now let’s go test your first Service Bus application end to end!

 Click the Save All icon on top left of your screen.

Deploy and Test

We are ready to deploy and test end-to-end. Make sure your Integrated Server is running.  _{Bring Overview Editor back into focus. You can do this by double-click your project icon}

in the Application Navigator or by selecting the ValidatePayment tab on top center.

 _{This will bring up your overview and refresh your canvas.}

(76)

 The Test Console will activate as one of your windows in JDeveloper on Windows. On Linux, this may start a new browser window outside of JDeveloper. Make this window active by clicking on the title bar.

By default, a sample payload will be generated for you; however, we will test with a specific file.  Click the Choose File button. This may show up as a Browse button on Linux.

 Navigate to ~/e2e-orderprocessing/sample_input/ and select PaymentInfoSample_Authorized.xml

(77)

 On the Test Console, click on the Execute button.

 On the next screen, scroll down and hopefully your payment has been authorized!

You can also debug the Service Application leveraging the Debugger as was done in chapter 2A.

(78)

Chapter 3: Process Order – Overview Page 78 of 392

Chapter 3: Process Order

Overview

In this chapter, you will build the basis of the new order processing system for Avitek, referred to as ProcessOrder.

Recall a few of the business requirements for Avitek ‘s new order processing system:

 Many different types of clients will access it over different protocols and data formats, including mobile devices.

 With a mobile app launch in progress, next year at the latest, the new order processing system must support access via RESTful API.

 It must allow existing systems to place orders using xml files and CSV files. These should be processed and fulfilled using the same new order provisioning infrastructure.

 It must interface with trading partners and provide EDI support.

In this chapter, you will see templates, a new feature in SOA Suite, at work in BPEL as well as Service Bus. You will leverage the validatePayment service you built in Chapter 2.

At the end of this chapter, your solution will look similar to the following (from an architectural perspective).

(79)

Chapter 3: Process Order – Overview Page 79 of 392

Prerequisites

 Chapter 2: Validate Payment should be complete or the chapter solutions deployed. If you did

not complete Chapter 2, please deploy the solutions. The Deploy Chapter Solutions section in

the Appendix gives detailed instructions for deploying solutions.

 Tutorial resources have been included and unzipped to a directory of your choice. When referring to any resources in the following chapters, we will always refer to directories relative to the unzipped location as orderprocessing. For example

~/e2e-1201-orderprocessing/sample-input/input.xml.

 When referring to resources in the following text, we will always assume the location you unzipped e2e-1201-orderprocessing and has structure as follows:

o WSDLs o Schemas o sample input o templates

(80)

Chapter 3: Process Order: Build Process Order Composite Page 80 of 392

Part 1: Build Process Order Composite

You will now create another SOA application that will accept new purchase orders, approve them and forward them to the fulfillment system. You will use a project template to implement the basic order processing scenario, add a call to the payment validation service built in chapter 2 and update the order status in the database based on the outcome of the payment validation.

The order status update will be converted to a BPEL subprocess to make it easily re-usable.

Once completed, your composite will look like this:

High-Level Steps

 Import SOA template.

 Before the order is processed, the credit card payment is validated using the validatePayment service built in Chapter 2.

 If the payment is denied, the order status is set to Denied and the processing is stopped.  If the payment is authorized, the order status is set to Authorized and the order is processed.  When the order processing is finished, the order status is set to ReadyForShip.

(81)

Steps in Detail

Import template

We will start by importing a SOA project template with a number of components already predefined. These components can:

 Receive an order through a web service call.

 Create order number, set order date to current date and set order status =’New’.  Calculate the total order amount.

 Save the order in the database with status=’New’.

 Return an acknowledgement to the client with the order number.

The template has been provided as part of the resources for the labs, and should be located in the

templates folder.

In the previous chapter, we added this location to the list of folders where JDeveloper looks for templates. If you haven’t done that yet, please follow the steps:

 In the main JDeveloper menu, select Tools - Preferences  In the Preferences window, select SOA - Templates  Click Add

 Navigate to the templates folder

 Click Select to accept your choice

(82)

Create a new project ProcessOrder from a project template

In chapter 2, you used project template to accelerate building the Validate Payment service, as well as a custom activity template for the XSLT transformation.

In this section, you will create the ProcessOrder composite (order processing service) based on the provided project template in the e2e-1201-composites application.

Open the e2e-1201-composites application:  Choose File > New > Project… from the menu.  Choose SOA Project

 Click OK

 Set the following fields:

o Project Name: ProcessOrder

o Directory: Keep the default directory

 Click Next

 In the next step, choose Start from SOA Template.

 If you can’t see ProcessOrderTemplate in the list, click the “+” button to add the folder where your template is located.

(83)

 Choose ProcessOrderTemplate.  Click Finish.

 A new project with predefined components is created.

 _{Double-click the components and services/references and discover what they do.}

 Deploy and test the project and make sure there are no errors, following the steps in the section “Test the SOA project with EM FMWC” in the Appendix.

 Use OrderSample_soap.xml (in the sample_input folder) for testing the web service interface. Please note that this sample file includes the soap envelope needed for testing.

(84)

Add the payment validation

The order will only be processed if the payment is valid.

Remember that we already implemented the payment validation in the previous lab. Now we will add a call to invoke this payment validation from process order.

Looking at the ProcessOrder composite, you will see that the BPEL process receiveOrder only sets the order number (which is provided back to the client) and the order date, and then calls

validateAndProcessOrder to validate and process the order.

SOA Suite provides a mechanism to browse services that are deployed in a SOA or Service Bus project in the integrated or a remote application server. The process is detailed below.

There are additional ways to find WSDL services that are available on the file system, in the repository or in other locations.

In this lab, we will browse to the ValidatePS.proxy service, which has been deployed in the same integrated server as the SOA composites.

First, we define a reference to the validate payment service.

 In the composite drag-and-drop a SOAP web service into the External References swimlane.

 Name it validatePaymentService

(85)

Chapter 3: Process Order: Build Process Order Composite Page 85 of 392  Make sure you select the app server where you deployed the ValidatePayment project.

 Select the ValidatePS proxy service

 Click OK

 The port is chosen automatically

 Check the box to copy the WSDL file and its dependant artifacts into the project. By doing this, we ensure that the designer does not throw an error when the Service Bus service is not available because the server is down or the service is not deployed.

(86)

Chapter 3: Process Order: Build Process Order Composite Page 86 of 392  Click OK

(87)

Chapter 3: Process Order: Build Process Order Composite Page 87 of 392  Uncheck “Maintain original directory structure for imported files” and “Rename duplicate

files”

 Click OK

 Now we need to wire the validateAndProcessOrder BPEL process to the newly created SOAP reference

(88)

Chapter 3: Process Order: Build Process Order Composite Page 88 of 392 Open the validateAndProcessOrder BPEL process and add the call to validatePaymentService.

 You will see that there is now a new partnerlink in the BPEL process for the payment validation. But let’s first have a look at what has already been defined in the process.

 After assigning the order to a process variable, validateAndProcessOrder calculates the total order amount, which is used to validate the payment. Remember, this was an input to the payment validation service.

(89)

Chapter 3: Process Order: Build Process Order Composite Page 89 of 392  An assign activity then adds the total order amount to the order message.

(90)

Chapter 3: Process Order: Build Process Order Composite Page 90 of 392  If the payment is denied, we will cancel the order and update the order status in the database

accordingly.

 The last step in the predefined process is to update the status in the database with the value of the status element in the order message. This will be re-used several times in this process:

o To update the order status with the outcome of the payment validation (Denied or

Authorized)

o To update the status to ReadyForShip if the payment has been authorized and the order process has been completed.

Now add the remaining activities to the BPEL process. Before you do that, collapse the scopes to make the design look less crowded.

 Add an invoke activity between the writeOrderScope and the updateOrderStatusScope. It should be after the Dehydrate activity. The dehydrate activity is needed in the BPEL after the Order is created, and before the validate Payment service is invoked. This will assist in properly handling an error situation if ValidatePayment composite is down, restarted, and failed

SOASuite12c_Tutorial.pdf

SOA Suite12c Tutorial

SOA Suite 12c Tutorial

Table of Contents

SOA Suite 12c Tutorial Overview

Chapter 1: Quick Start Install

SOA Suite 12c Documentation

Chapter 2: Validate Payment

Overview

Prerequisites

Part 1: Build a SOA Composite

High-Level Steps

SOA Templates

+

Steps in Detail

Create a new composite application and project

Create a database connection for adapter to retrieve payment information





Review the validatePayment BPEL process







Calculate payment status using an XSLT map (custom activity template)

Add a composite sensor for payment status

Deploy the SOA composite

Debug a SOA project in JDeveloper

Test the SOA composite

Part 2: Register Composite on Service Bus

High-Level Steps

Steps in Detail

Create a new service bus application and project

Create folders and import artifacts.

Configure Business Service for validatePayment composite.

Tip and Trick – How to find composite deployment URI

Review Business Service Properties

Configure Proxy and Pipeline

Deploy and Test

Chapter 3: Process Order

Overview

Prerequisites

Part 1: Build Process Order Composite

High-Level Steps

Steps in Detail

Import template

Create a new project ProcessOrder from a project template

Add the payment validation