SOASuite12c Tutorial PDF
SOASuite12c Tutorial PDF
2014 16:50:46
Page 1 of 392
Page 2 of 392
Page 3 of 392
Page 4 of 392
Page 5 of 392
Templates
Debugger, Testing
New Adapters
More
Page 6 of 392
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:
Page 7 of 392
Page 8 of 392
Prerequisites
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.
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>
<soas:ZipCode>12345</soas:ZipCode>
Page 9 of 392
<soas:PhoneNumber>5127691108</soas:PhoneNumber>
</soas:BillingAddress>
</soas:Billing>
Page 10 of 392
High-Level Steps
Leverage the new SOA Project template to create the ValidatePayment composite.
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.
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 theyre 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.
Page 11 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:
As the templates used for the labs have been unpacked into the ~/e2e-1201orderprocessing/templates/ folder, we will add this directory to the list of folders that are
scanned for templates.
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).
Page 12 of 392
Page 13 of 392
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.
Click OK.
In the subsequent dialog for Create SOA Application, set the following fields, leaving the others
with their default values:
a.
b.
Page 14 of 392
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.
Page 15 of 392
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.
Page 16 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
label. It is displayed as ValidatePayment here.
Page 17 of 392
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.
Page 18 of 392
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.
Page 19 of 392
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.
Page 20 of 392
Page 21 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.
Click OK.
Make sure you save all changes by clicking the Save All icon at the top of JDeveloper.
Page 22 of 392
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.
Page 23 of 392
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
Inspector (see How To Edit BPEL Activities in the Property Inspector in soa-dev-guide.pdf).
Page 24 of 392
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 its a concatenation of the partner link name, the
operation and InputVariable.
Page 25 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.
We dont 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.
Make sure to save everything before you continue.
Page 26 of 392
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 your BPEL process, expand the Custom Activity Templates section in the BPEL activity palette.
If you dont see the template, close and reopen the BPEL process.
Page 27 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
which are already present in the composite:
Page 28 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:
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.
Page 29 of 392
If you want to see the definition of the XSLT file, click the edit button at the bottom:
Click Expand All Child Nodes on Source and Target and click on the little plus sign next to the
function in the middle.
Page 30 of 392
AuthorizationAmount (= total order price) is smaller than daily limit on credit card
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:
Page 31 of 392
Click OK.
Page 32 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.
Page 33 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:
Confirm the delete action by clicking Yes in the Delete Variables window.
Page 34 of 392
Save all changes by clicking the Save All icon on top of JDeveloper.
Build your project by choosing Build Make ValidatePayment.jpr in the JDeveloper main menu.
Page 35 of 392
If you see errors in the Messages - Log window at the bottom, indicating that a variable doesnt
exist, make sure the transformation uses the three global variables instead of the scope
variables you deleted.
Page 36 of 392
Locate particular instances by searching for specific sensor details in the EM console.
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.
Page 37 of 392
Name it PaymentStatus.
Page 38 of 392
Choose Variables.
Page 39 of 392
Click OK.
Page 40 of 392
Click OK.
Click OK again.
Page 41 of 392
When you mouse over, you can see the sensor definition.
Page 42 of 392
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.
Page 43 of 392
These breakpoints are red dots only without arrow as the flow is always in one direction:
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.
Page 44 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.
Click OK.
If youve made changes to your project, it needs to be redeployed. This includes setting of
breakpoints.
You will be lead through the deploy wizard step by step if that is the case.
Page 45 of 392
Every web service endpoint now shows a message that you can use the context menu to
initialize WS debugging:
Fill in all fields or choose HTTP Content at the bottom to be able to copy and paste an xml file
instead.
Page 46 of 392
Be aware that this sample message already includes the SOAP envelope needed for testing.
Page 47 of 392
If everything goes well, you should now see the debugger stop at your first breakpoint:
Go to the Data tab at the bottom of JDeveloper and look at your variable values:
Page 48 of 392
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
Page 49 of 392
After the calculate payment activity, the payment status has been set:
Page 50 of 392
On the left hand side, you also see the stack trace:
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.
To stop the debugger, click the big red icon in the Tools section and choose your project.
Page 51 of 392
For more information on SOA Debugger, please see Debugging SOA Composite Applications with the
SOA Debugger in soa-dev-guide.pdf.
Page 52 of 392
Page 53 of 392
High-Level Steps
During this lab, you will accomplish the following tasks:
Page 54 of 392
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.
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
Page 55 of 392
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
b. Directory of your choice
Page 56 of 392
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.
Page 57 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.
Page 58 of 392
Select Folder.
Page 59 of 392
Click OK.
NOTE: This is only necessary the first time you add a Folder, thereafter it will be listed on the menu
by default.
Click OK.
Page 60 of 392
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 todays work, you will import the artifacts from the
file system.
Page 61 of 392
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.
Page 62 of 392
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 ValidatePaymentconcrete.wsdl
Page 63 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.
Page 64 of 392
Click Finish. Your left-hand navigation tree should resemble the following:
drag and drop icons from the Component Palette on to the overview canvas (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.
Page 65 of 392
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.
Click Next.
Page 66 of 392
Select the
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
Click OK.
Page 67 of 392
Confirm that ValidationPaymentPort is selected in the Port field when you return back to the
wizard.
Click Next.
Confirm Endpoint URI is set to your validatePayment composite, it should look similar to this:
http://localhost:7101/soainfra/services/default/ValidatePayment/validatepaymentprocess_client_ep
Page 68 of 392
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.
Page 69 of 392
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 wont be settings
these right now but you might want to explore what is available.
General Properties
Transport
Transport Details
Performance
Security Policy
Page 70 of 392
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.
Page 71 of 392
Click Next.
Page 72 of 392
Click OK.
Page 73 of 392
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.
Page 74 of 392
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 lets go test your first Service Bus application end to
end!
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.
Page 75 of 392
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.
Click Open.
Page 76 of 392
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.
You have just completed your first SOA Suite 12c application!
Page 77 of 392
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.
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).
Page 78 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 ~/e2e-1201-orderprocessing. For example ~/e2e-1201orderprocessing/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
Schemas
sample input
templates
Page 79 of 392
High-Level Steps
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.
The Fulfill Order process to pick up orders that are ready to be fulfilled will use this status.
Page 80 of 392
Steps in Detail
Import template
We will start by importing a SOA project template with a number of components already predefined.
These components can:
Create order number, set order date to current date and set order status =New.
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 havent done that yet, please follow the steps:
Click Add
Page 81 of 392
Click OK
Click Next
If you cant see ProcessOrderTemplate in the list, click the + button to add the folder where your
template is located.
Page 82 of 392
Choose ProcessOrderTemplate.
Click Finish.
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.
Page 83 of 392
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
Click on the icon next to the WSDL URL field to find the validatePayment WSDL.
Page 84 of 392
Make sure you select the app server where you deployed the ValidatePayment project.
Click OK
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.
Page 85 of 392
Click OK
Page 86 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
Page 87 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 lets 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.
Page 88 of 392
An assign activity then adds the total order amount to the order message.
The writeOrderScope includes all activities involved in writing the order to the database.
Page 89 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)
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.
Page 90 of 392
You can choose to continue editing in this dialog or close the dialog and edit in the property
editor.
Page 91 of 392
Lets use this dialog for now to make you aware of both options. Youll be able to decide later
which option you prefer.
Click the + sign next to Input to automatically create the input variable for the invoke activity
Click OK
Page 92 of 392
Click OK
Click OK
Page 93 of 392
Before the web service can be invoked, the right values must be assigned to the input
variable for the web service call.
Page 94 of 392
Open the Copy Rules tab and launch the Assign Editor
Assign the payment information (Billing) from the order variable to the input variable of the
validatePayment service (validatePayment_validate_inputVariable) by dragging a map
from left to right.
Page 95 of 392
Click OK
If you see a warning attached to the assign, click the validate check box on top of the BPEL
editor. The warning should now go away.
We now assign the reply from the web service call - the payment status - to the order
message.
Call it setPaymentStatus
Page 96 of 392
In the Assign Editor, map the payment status in the output variable of the invoke activity to
the status in the order variable.
The last step in the BPEL process will update the order status in the database with the payment
validation result.
Chapter 3: Process Order: Build Process Order Composite
Page 97 of 392
This is a good point to deploy and test the project again. Feel free to also debug the project, and the
BPEL processes to get a feel for what theyre doing.
Please follow the steps outlined in Test the SOA project with EM FMWC in the Appendix section.
Use OrderSample_soap.xml as sample message.
When you now open the flow instance in EM FMWC and choose the Composites tab, you will see both
composites within one flow instance:
ValidatePayment is participating.
You will also see the service bus proxy service as part of the flow trace.
Make sure there are no errors in the flow trace.
Change the sample message to cause the payment validation to be denied (increase the
order items to extend the daily limit of the credit card, the daily limit is $1000).
Page 98 of 392
This invocation of the database adapter will now update the order status to Denied or Authorized,
according to the return value of validatePayment.
Page 99 of 392
To avoid this, we introduced a new feature in SOA Suite 12c called a BPEL subprocess.
BPEL sub-processes come in two flavors standalone, and inline.
This is a fragment of a BPEL process, which includes a number of activities that will be re-used
across a number of other BPEL processes.
The standalone subprocess doesnt have an interface and can only be called from another BPEL
process, but it can have partner links.
In the composite view, the wire to a subprocess is shown as dotted line to indicate that this is
not a wire between actual components.
In the first release of SOA Suite 12c, we only support subprocesses in the same composite
For groups of activities that are re-used within just one BPEL process, you can use an inline
subprocess.
Its part of the parent BPEL process code and not visible in the composite view.
You can either define parameters to be set or use the process parameters.
At run-time, the subprocess code is re-entrant and re-usable only one copy is stored in
memory, even if it is called 20 times.
To learn more about BPEL subprocesses, please see chapter Oracle SOA Suite Templates and Reusable
Subprocesses in soa-dev-guide.pdf.
The order status update scope will be converted into an inline BPEL subprocess as its only used within
the same BPEL process.
Leave Replace Scope with Subprocess Call checked. This will automatically replace the current
scope with a Call activity
Optionally set a label, comment and choose an image for your new subprocess.
Click OK
You can also see the subprocess in the palette under Subprocesses
You can see and edit the definition of the subprocess when switching from Main Process to the
subprocess on top of the BPEL editor
You can see all partner links that are available in the main process, in case you want to add
another invoke.
You can make changes to this subprocess, which will be reflected in every call.
Before we test the process, lets change the name of the call activity.
Select the call activity and change the name in the property inspector to updateOrderStatus.
Deploy, test and debug the process again, the actual result should not change.
You will notice that you now see the call activity in your audit trail with the activities included in the
subprocess:
Similarly, in the flow trace, we also show the call activity and all activities included in the subprocess
below it:
Choose receiveorder_client_ep
Name: OrderNumber
Click OK
Make sure Enterprise Manager is checked, so that you can see the sensor in the flowtrace
Click OK
Click OK
Check to see if the sensor is set in the Flow Trace of the new instance together with the
payment status sensor.
Update the order status to ReadyForShip if the payment has been authorized
If the payment is valid, the order status is set to ReadyForShip in the database. This status update will
trigger the order fulfillment process, which will be built in a latter chapter.
If the payment is not valid, processing ends here.
First we add an If statement. The order will only continue if the payment was authorized. Otherwise
processing is stopped and an email is sent to the customer informing him of his unauthorized payment.
If in BPEL 2.0 is the equivalent of switch in BPEL 1.1.
Add an If under the sub process call. (You find the If activity under BPEL Constructs Structured
Activities)
Select the If construct and open the property inspector window, if its not already open.
Edit the condition by clicking the icon for the XPath Expression Builder
Expand the variable order and enter the status element into the Expression field by clicking
Insert Into Expression
Add = Authorized
Back in the BPEL process, change the If label to Authorized by clicking on the label
Click OK
The else branch is not necessary, as the processing will just stop if the payment has been
denied. Delete the else branch:
If the payment has been authorized, the processing of the order is complete and we update the
order status to ReadyForShip
Name it assignReadyForShipStatus
Expand the order variable on the right hand side to the Status element and drag an Expression
on top of the Status element
Enter ReadyForShip
Save All
Add a call to the subprocess (the one we just created) after the assign to update the order
status in the database. As previously, it reads the status form the order message, so no
additional assign activities are needed. Do you see how easy that is?
Deploy, and test the project. The order status in the database should be either Denied or
ReadyToShip.
High-Level Steps
Steps in Detail
Open existing service bus application and import template resources
Open your e2e-1201-servicebus application from Chapter 2. If already open, then navigate to it.
Click OK
Click Next.
Import Service Bus Resources- Step 2 of 3, Click the browse icon to the right of Jar Source.
When the Configuration Jar chooser appears, navigate to where your resources are located on
disk and select pipeline-template-resources.jar from the Templates directory.
Click Open
Click Next
Import Service Bus Resources- Step 3 of 3 - Review exactly what is being imported into your
application.
Service Bus supports the ability to import and export artifacts and projects at fine-grain level.
You may import artifacts individually, such as a WSDL or schema, or whole projects. You may
control whether dependencies are included or not.
By default, when importing individual artifacts, Service Bus will attempt to import all
dependencies declared in the artifact. For example, if a WSDL includes a schema, the schema
will also be imported if the paths are relative.
Also note you can control if environmental settings, security policies, and credentials are
preserved on import. If you are bringing artifacts from a production environment for testing
and editing you may not want all the same policies applied in your development environment
for example.
Click Finish.
This will bring up the same Business Service dialog that you leveraged in Chapter 2. Hopefully these
dialogs will be familiar to you now so we will just give you the settings.
on
Click Next.
From the WSDL Chooser, select from the Application and then navigate to find WSDL.
ProcessOrderSB->WSDLs->ProcessOrder-concrete.wsdl
Click OK.
Click Next.
If you need to change the endpoint URI, you could do this from this dialog or wait until later and
change under the Business Service -> Transport tab. Service Bus also allows you to have multiple
endpoints for your Business Service to support application load-balancing and failover.
Click Finish.
Before you proceed, why not quickly test your new Business Service and make sure the endpoint is a
good one. Do you remember how to do this? One simple way is directly from the overview canvas.
Right-click ProcessBS icon on the External Services lane and select Run from the menu.
icon.
Once the Test Console is displays, Click on the Browse (Linux) or Choose File button (Windows) and
navigate to ~/e2e-1201-orderprocessing/sample_input and select OrderSample.xml.
You can also select the XML tab, and select the OrderSample_soap.xml
You should receive a response document that contains an OrderNumber from your ProcessOrder
composite. You are ready to build your Pipeline and Proxy!
First, make sure your overview editor is active by double-clicking on the ProcessOrderSB icon
on top center or in the left-hand Application Navigator.
Locate the Pipeline icon on the Component palette and drag onto the middle of your canvas.
The Create Pipeline dialog will appear. This is the same dialog as you used to create your Pipeline in
Chapter 2; however, this time you will select to Create the Pipeline from a Template.
Create Pipeline Step 1 of 2
a.
b.
c.
Click OK
Click Next
Click OK
Check the box for Expose as Proxy Service and set Proxy Name: ProcessPS. Leave rest of the values
to their defaults.
Click Finish.
On your canvas you will now see your new Pipeline created from a Template.
The pipeline created still needs some work so it may show an error or a warning (example of an error
in the diagram below).
Double-click on the ProcessPP Pipeline and lets drill down to take a closer look.
This Pipeline looks different than the one weve worked with before. Notice that the background is
grey. This indicates we are working with a Pipeline derived from a Template. The Template
Designer has made some items editable and others not.
This Pipeline has all kinds of good stuff already built for you Data Validation, Routing, Error
Handling - all you need to do is fill in the blanks. What blanks need to be filled in? Notice the
flags these indicate areas that still need to be filled in to have a valid Pipeline. Service Bus
has strong design-time validation so it will help you keep track when the Pipeline has been
completely filled out.
Notice the Your Request Stages. This is where the Template Designer has left a placeholder for you
to customize the Pipeline to do any additional work like transformations, message enrichment
before the data Validation action will be performed, likewise on the Response Pipeline.
Also, notice the Error Handler at the top right. Best practice is to always have an Error Handler
defined for Pipelines. This pre-defined Error Handler will report the error back to the caller with
good details and also send up an Alert to the EM console that something is wrong with processing.
Likely we may have invalid Order data incoming.
Before editing the derived Pipeline, select the Configuration tab at the bottom of the canvas.
Review the instructions given by the Template Designer in the Description area before proceeding.
This is where documentation of how to use the Template should be captured and shared by the
Template Designer to the Developer using the template.
Re-select the Design tab, and lets now fill in the template and complete our Pipeline.
First, lets get rid of those
flags.
Open the Data Validation stage and select the Validate action. You will validate the incoming
payload against the canonical Order element type that the ProcessOrder composite is expecting. By
validating in Service Bus, you save precious resources in the backend that are actually processing
good orders.
We only need to fill in the type to validate against. The location has already been provided by the
Template Designer. Since this is a WSDL based service, Service Bus knows our data types and can help
us easily fill in the blanks.
Click on the magnifying glass on the right to bring up the XML Schema/WSDL chooser.
Click OK
Notice the red flag is gone! Notice the different Actions you can take when you Validate.
You may raise an error (default) or simply assign the value to a variable that you can check in your
Pipeline. Perhaps you have a service that fixes common data entry type mistakes.
New Feature: Dynamic validation is supported in this release, so you can determine at runtime the
schema type to check based on an expression.
Move to the Reporting action in the Auditing stage of the response flow. Lets customize to report
on the Order number that is returned from our composite. The template already saves a copy of
the incoming Order in case of an error and reports it to EM.
Click on the
Key: OrderNo
Variable: Select body
XPath: Click on the little icon to the right to pop-up the expression editor.
XPath Expression Builder, navigate to Variables tab in the middle of the screen and navigate to
Body>process>$ body response > OrderAck > OrderNumber
Double-click the Routing node and select the Route finger tab in the Property inspector.
Click on the magnifying glass on the right and navigate to the ProcessBS Business Service.
Click OK
to refresh
Test end-to-end
Click on the ProcessPS service on the left swim lane and select Run
~/e2e-1201-orderprocessing/sample_input/OrderSample.xml
~/e2e-1201-orderprocessing/sample_input/BadOrderSample.xml
What happens? Are the results sent back to you enough to understand what the problem is?
Enterprise
Manager
Console
Service Bus
Console
Prerequisites
Resources have been downloaded and unzipped to the home directory ~/. When referring to
any resources in the following chapters (for example WSDLs or sample input), we will always
assume the home directory location. For example, sample input files are expected in ~/e2e1201-orderprocessing/sample_input.
High-Level Steps
Steps in Detail
Configure Proxy for File Adapter
Drag the File Adapter onto the Service Bus Overview editor in the Proxy Services lane.
Name: ProcessPS_File
Click Next.
Click Next.
Click Next.
Click Next.
Click Next.
Click Next.
Keep defaults.
Click Next.
NOTE: On this step you have a choice, you can proceed to Part 4 Advanced: Build the
translations from scratch of this chapter and build the nXSD from scratch or you may select an nXSD
that has been provided for you that will convert comma-delimited orders in valid canonical XML
format. Your choice if you are running ahead of schedule, we would encourage you to build from
scratch.
When the Type Chooser appears, navigate to Application Schema Files - > ProcessOrderSB ->
Schemas -> nXSD_Order.xsd -> Order
Click OK.
Then click Next after validated your choice looks like below notice the Schema Element is set to
Order.
Click Next.
Click Finish.
Click on the
on your new Proxy and drag over to the existing ProcessPP pipeline.
We are able to re-use the ProcessPP Pipeline we built in Chapter 2. Take a few minutes to browse
the properties of your Proxy services, Pipeline and Business Services. Ask any questions that you
might have.
Save everything. Right-click and then select Run from the menu to deploy your artifacts.
If you should see a policy error in the Test Console, go change this Policy setting in your Proxy
General tab. Set to No Policies and Run again.
After a few moments, the file should be gone meaning that it has been processed.
Before proceeding to the next section, test your ProcessPS SOAP/HTTP proxy with good and bad
data, we will use these results to review the Enterprise Manager console.
Good Data: ~/e2e-1201-orderprocessing/sample_input/OrderSample.xml
Bad Data: ~/e2e-1201-orderprocessing/sample_input/BadOrderSample.xml
Recall in Chapter 3, you used a Pipeline template to create your Pipeline. This pipeline had an
Application Alert defined in the error handling to warn if a service was failing.
High-Level Steps
Steps in Detail
Bring up Enterprise Manager and navigate to Service Bus
Navigate to the Service Bus folder on left side of the navigation tree and select the Operations tab.
Notice no services are displayed by default. You must first select the Search button on the right.
This has been done to optimize performance when there may be 100s or 1000s of services, you can
display only those services of interest by refining your search.
Select Search on the right. This is a new operational view, which will allow you to set operational
parameters across a select group of services that fit a specific pattern.
In this case, we are searching for all services in the ProcessOrderSB project. Select ProcessOrderSB
in the left navigation tree.
Press the Search button on the right and all the services in ProcessOrderSB will be displayed.
Click on the checkbox at the top of the Monitoring column and select apply. By default, monitoring
is not enabled on services in Service Bus until you explicitly turn monitoring on. You may turn
monitoring on for just the ProcessSB services or by selecting the entire tree on the left; you may
turn of monitoring for all services.
Click Apply.
Note that you can also quickly filter by type of service Proxy, Business Service, Pipeline by selecting
the Type drop-down box.
Selecting Proxy and Business Services will display only those types of services in the
ProcessOrderSB project. We can further refine with the attribute drop-downs on the right to show
only the active services or those with SLA Alerts.
Now that monitoring is enabled, we can browse for other interesting data.
Click back on the top level of service bus in the left-hand navigation tree, this will remove the search
filter. Browse along the tabs
Global Settings
Operations (remember to hit Search!)
Faults
Service Health
Alert History
Dashboard
If you have been testing with good and bad order data, navigate to the Alert History tab.
Press Search button. You should see a few critical alerts that were thrown from your service.
Click on one of the alerts and browse the data contained there.
Click on the Properties tab to set the Aggregation Interval to 8 hours. By default its 10 minutes.
Click the Service Bus drop-down at the very top of the screen.
Then press the Search button. You should see a listing of all the Reporting from running your
services.
Click on a few of the items and inspect the properties and details captured by the reporting action.
Click on one of the OrderNo entries, and then select Report Details on the next page.
You can then see any payload that was captured by the service.
In a future lab, we will show a new future that can redact sensitive data from reporting and logs in
SOA Suite. Continue browsing.
Finally, browse back to the top-level and select the Dashboard tab. You can see a visual of the
Pipeline Alerts generated by your service by selecting PipeLine Alerts in the drop-down box.
If you dont see any alerts, change the Alert History Duration on the right to be 8 hours.
High-Level Steps
Right-click your Pipeline or Proxy from the canvas and select the Debug option.
Steps in Detail
Double-click on the project icon in the left-hand navigation window to bring your overview into
focus.
Select the Reporting action and right-click and select Toggle Breakpoint from the menu.
Navigate back to your overview canvas. Right-click on the Proxy and select Run.
In a short while, you should you should see your JDeveloper screen flashing and be able to review
your variable and step through your Pipeline.
Click on the Data window at the bottom center of your screen. Introspect $body.
Invoke the Native Format Builder from the File Adapter Configuration Wizard (Step 8 of 9)
Steps in Detail
Bring up the Native Format Builder
When you click the Define Schema for Native Format button in the Messages page of the Adapter
Configuration Wizard shown in Figure below, the Native Format Builder wizard is displayed. The
Messages page is the last page that is displayed in the Adapter Configuration Wizard before the Finish
page.
In this use case, the Native Format Builder uses FileOrderSample.csv, a complex file type which contains
multiple records such as credit card information, billing address, shipping address and items. Also, using
this use case, you can generate the NXSD and test it. Perform the following steps to run this use case:
File Adapter Configuration Wizard Step 8 of 9, click on the icon to the right of the URL choice
(see red box above)
Launch the Adapter Configuration Wizard and navigate to the Messages page, as displayed in
Figure 1, and click Define Schema For Native Format.
The Native Format Builder Welcome page is displayed, as shown in Figure 2 below.
Click Next.
Enter the FileName for the nxsd schema as shown below:
Select Complex Type (Contains records whose fields may themselves be records having
multiple delimiter types)
Click Next. The Native Format Builder File Description page is displayed.
Click Browse and select the FileOrderSample.txt file, and enter Order in the Root Element and
TargetNamespace as http://www.oracle.com/soasample.
We will now create the complex types for data corresponding to address, billing, shipping, and
item. Let us first start by creating complex type for address. Select Order element and click on
Add Complex Type icon (2nd from the left):
Drag and drop the address line from the right pane for Sample File onto the AddressType :
Click on Generate Fields button; this will generate the schema elements corresponding to the
fields in the data file.
Now, you will need to rename the auto-generated elements C1,C2,C7 to element names that
we expect in the generated xml. Select each of the elements and click on the Pencil icon to
open the Edit Field Details screen(shown below) in order to update each field. Please ensure
that Terminated By field for each of the fields is set to , except for the last field which should
be set to ${eol} (e.g. end of line). Please ensure that the Style is set to terminated.
C1 FirstName
C2 LastName
C3 AddressLine
C4 City
C5 State
C6 ZipCode
C7 PhoneNumber
Shown below is the Edit Field Details screen for the first element:
Once the details are filled in, the screen should look like this:
Now we will create the complex type for BillingType. The BillingType consists of Credit Card
Information and the Billing Address. Select Order element from the left pane and click on Add
Complex Type; name it as BillingType. Select BillingType and drag and drop the first line of
data from the Sample File pane onto the Billing Type.
Select Delimited by as Comma(,) and click on Generate Fields. Now map the auto generated
columns C1,C2,C3, and C4 to CardPaymentType, CardNum, ExpireDate, and CardName
respectively. Ensure that CardPaymentType, CardNum, ExpireDate fields are terminated by
Comma(,) and CardName is terminated by ${eol}. The Style for CardPaymentType might be set
to blank; please ensure that Style is set to terminated. Once done, your screen should look as
shown below:
Now we need to add another field to this list. Click on the Green button (plus sign) to add a new
field. Name of the element as BillingAddress and select AddressType as its type. Leave Style
as blank. Click on OK. Now your Define Schema screen looks as below:
Now, we will create the type information for the order line item. Select Order and create a new
complex type called ItemType and drag and drop the first order line onto this :
This will open the Complex Type Detail window. Select Delimited by as Comma(,) and click on
Generate Fields. Rename C1,C2,C3,C4,C5,C6 and C7 to SKU, Quantity, UnitPrice, Brand, Model,
Category, and Description respectively. Make sure that all the fields except Description have
Terminated By set to Comma(,); Description field will be Terminated By ${eol}(e.g. end of line).
Click OK. Youre back at the screen for Design Schema as shown
Add a new complex type ShippingType under Order element. Right-Click on ShippingType
and select Add Element as shown.
Right click on ShippingType and add another element ShippingSpeed. You can use Right
click, or Add element Button.
Select ShippingSpeed element and click on pencil icon on the top to edit the element. This will
open the Edit Field Details screen. Select terminated as style and add Terminated By as
Comma(,) manually as shown:
Select Order element and create another complex type with name ItemsType. Select ItemsType
and create a new element item as shown below:
Now select item element and click on pencil icon to edit the element, select type as
ItemType, Max Occurs as UNBOUNDED, check Array button and put Array Separator as
${eof} (e.g. end of file)
Click OK. Youre back on the screen for Design Schema shown below
Now, its time to create the elements. Select Order element and click on Add Element icon
at the top and create 4 elements, Billing, Shipping, Email and items. Your screen will look like
this:
Now drag and drop BillingType on Billing , ShippingType on Shipping, and ItemsType on items.
Select Email element. Click on pencil icon on the top to edit the information. You will see the
Element Detail screen.
Click on Edit Properties. You will be presented with a screen to edit the Field details. Enter
Style as terminated, type as string and Terminated By as ${eol}
Click Next. Youll be able to see the generated schema. Ensure that your top level Order
elements looks as shown below. Reorder the elements if they do not occur in the exact order as
shown below:
Click on Generate XML button as shown, you should be able to see the generated xml as
shown:
Prerequisites
The integrated server in JDeveloper is up and running with at least Chapter 3 completed. Make
sure the debugger has been terminated.
If you did not complete Chapter 3, obtain and deploy the solution, following the steps below:
To deploy solutions:
-
Locate ~/e2e-1201-orderprocessing/solutions/ch4-addOrderInputChannels
Unzip e2e-1201-composites_ch3.zip to a location of your choice (the SOA composite did not change
in chapter 4, thats why youll use the chapter 3 solution)
Open JDeveloper
Open the previously unzipped application by selecting Application Open from the main JDeveloper
menu
Alternatively, if you already have an application e2e-1201-composites and only need to import specific
projects
Locate from the following list of projects the ones you want to import in ~/e2e-1201orderprocessing/solutions/ ch4-addOrderInputChannels/SOAProjects:
-
ValidatePayment_ch2zip
ProcessOrder_ch3.zip
Locate ~/e2e-1201-orderprocessing/solutions/ch4-addOrderInputChannels
Open JDeveloper
Open the previously unzipped application by selecting Application Open from the main JDeveloper
menu
Introduction
In this chapter, you will build the pack and ship service.
The pack and ship service is defined with a REST interface and accepts a Shipping resource (part of the
canonical order message). It initiates the packing and shipping of one order and notifies the customer
that the order has shipped.
It also updates the order status in the database to Shipped.
Once done, your project will look like this.
High-level steps
send an email to the customer that the order has been shipped.
Steps in Detail
Create the Packing Service project
Oracle Service Bus provided REST support in 11g, but Oracle SOA Suite 11g had very limited support
through HTTP binding only.
SOA Suite 12c provides the following REST support:
For more information, please see Integrating REST Operations in SOA Composite Applications in soadev-guide.pdf.
Please follow the steps below to create a SOA Suite 12c REST service:
Create a new SOA project PackAndShipService with an empty composite in the application e2e1201-composites.
Click OK
Click Next
Click Finish
Drag and drop a REST Binding Adapter into the Exposed Services lane
Name: packingService
Click the green + sign next to Resources to open the Create REST Resource dialog
Click OK
Now add an operation binding by clicking the + sign next to Operation Binding
Operation: packAndShip
Resource: /shipping/
Request:
o
Import the CanonicalOrder.xsd schema from the ProcessOrder project or from the resources folder
Click OK
Click OK
The REST Operation Binding dialog provides the ability to generate a sample payload.
Create a new folder SampleInput under SOA by clicking the Create new subdirectory icon.
Click OK
Click OK
Add a description.
Name: packAndShipOrder
Template: Define Service Later (The interface will be defined when we wire this process
to the REST binding, later in the procedure.)
Click OK
Click OK when asked to set the transaction properties of the BPEL service
There is no receive activity defined yet, but the partner link for the REST service is already
available.
Wire the REST partnerlink to the Receive activity (Start the wire at the Receive activity and drag
it to packingService).
Name it receiveShippingInfo
Check Create Instance (when receiving this request, a new BPEL instance will be created).
Click OK twice
Rename it to replyShipping
This service initiates the packing and shipping, based on shipping provider and shipping method, which
are both determined by the order fulfillment service.
To simulate the packing and shipping, we will add an empty activity to the BPEL process.
But first we create two new variables for orderNumber and orderStatus. These will be used
later and will be assigned in the next step.
Open the Variables view by clicking the Property Structure icon on top of the BPEL editor
Select Variables Process Variables and click the + sign to add a new variable
Name the variable orderNumber and browse to the simple type string
Click OK
Click OK again
Name it setOrderStatusToShipped.
Set the status in the input shipping method to Shipped by using the expression builder as you
did several times before.
Also assign the order number and order status to the variables we just created.
o
The order status element in the input message is optional. Right-click on the right hand side of
the copy rule (which assigns the order status to the input variable) and choose
insertMissingToData
In a similar way, the order number in the input message is optional. Right-click on the right hand
side of the copy rule (which assigns the order number to the order number variable) and choose
ignoreMissingFromData
Click OK
Now we still have to set the output variable for the BPEL process.
Name it assignShippingReply
In the Assign Editor, set the value of the input variable (with the updated status) to the output
variable.
Deploy this project, following the same steps as you did previously
Testing a REST service is different than testing a SOAP service. The details will be explained
in the next section.
Open EM FMWC: Error! Hyperlink reference not valid., substitute your own host name and port
number.
This opens the Service WADL and Text Description URL window:
Copy the WADL URL to a place where youll be able to retrieve it in a later step. You will need it
for testing the service in JDeveloper.
Go back to JDeveloper.
From the menu in the main JDeveloper window, select Tools HTTP Analyzer
Press Return
You will now see the WADL file which includes the POST method
If the WADL file opens in source view and you dont see a design tab, close and restart
JDeveloper.
Within the WADL file design view, click Test in the POST method
Copy and paste the sample message you created previously (SampleShipping.xml)
After a little while, you should see a response message with order status Shipped
If you havent done so already in chapter 2, add the path to the templates folder to the list of folders
that are scanned for templates.
Open Tools Preferences and choose SOA Templates:
The following steps describe how to add the updateOrderStatusSP template to the pack and ship
project.
In the Components palette, scroll to the bottom where you see the Component Templates
Drag and drop the template in the middle of the component palette
A window opens providing an overview of all artifacts bundled with the template.
You can see all artifacts necessary for the database adapter and the subprocess. None of the
artifacts are optional.
Click OK to accept
You will notice an assign activity and an invoke activity to the database adapter.
The assign takes an order number and an order status and assigns it to the input variable of the
adapter.
The call to the updateOrderStatusSP subprocess is available in the BPEL constructs palette
under Subprocesses - Standalone
In the property inspector you can see the arguments for the subprocess.
Select the orderNumber and click on the small area behind the value to select the input.
Click OK
Click OK
In order to test this service, you must use an existing order number value for orderNumber. The easiest
way to do this is to run ProcessOrder first and make note of the order number.
When you have an order number, test the PackAndShipService, using the ShippingSample.xml sample
file, replacing the orderNumber with the ProcessOrder output.
Check the flow trace to make sure there was no error:
Choose the ShippingProvider Name in the Shipping method in the incoming message
Click OK
Deploy and test the service and check out the sensor values in EM FMW by opening the flow trace
of the just-created instance and choosing the sensor tab:
Use sample messages with different Shipping Providers to see how the sensors values change.
For this drag and drop the UMS Adapter from the palette into the right swimlane.
Name it NotifyUser.
Click Next
Click Next
Leave the Outbound Send Notification checked and accept the default for the
SendNotification.
Click Next
In the next screen, leave Email selected as the type of notification. Specify the Subject Your
order has been shipped and the correct email address (see below) in the From and To fields.
Click Next
Click Next
Click Finish
Add an Invoke activity before the Reply activity to invoke the email adapter
Next, build the message payload by dragging an Assign activity just before the Invoke activity.
Name it assignNotification
In the Assign Editor, add an expression to the payload child element of the input variable of the
invoke activity that wires to the UMS Adapter.
Use the following expression to populate the payload by extending the output variable and
concatenating the order number and shipping provider.
Note: The namespace prefixes could be different for you so dont just copy and paste the expression!
Click OK
Please deploy and test the process again and make sure you receive an email notification.
This will retrieve the first message. If no message has been received yet, you will see -ERR Message (1)
does not exist.
Here is an example.
You can also run list to see how many emails have been received.
Go to the Section "Apache James 2.3.2 is the stable version" on the page
Click on the link for "Binary (ZIP Format)" to download a zip distribution of Apache James to the
AdapterConfig folder for windows or linux.
Type telnet localhost 4555. (Use localhost or wherever you have james set up and running)
Login as root/root.
Type shutdown.
Note: You could also force stop the James server by pressing Ctrl+C on the console where James was
started in.
Ensure that MW_HOME is set. For example execute the following command on windows: set
MW_HOME=D:\oracle\Middleware\soa12c or on linux setenv MW_HOME
/oracle/Middleware/soa12c, using the correct path for your installation
Open up the target_adapters.py file and check the host/port, userName, password and the
server name.
The script uses the default values and should work if you havent made any changes to the
defaults. If you didnt use the default values, please change the file accordingly
host: localhost
port: 7101
username/password: weblogic/welcome1
Server Name: DefaultServer
You should now be able to see that the adapters are in Active state in the WLS Admin Console.
Navigate to Error! Hyperlink reference not valid. where host/port are the admin server host
and port values (default is http://localhost:7101/console).
You should see the Coherence Adapter and UMS Adapter in the table on the right. You may
have to press Next a few times or customize the table to see all entries.
Coherence Adapter
UMS Adapter:
The actually domain name is created dynamically by concatenating system and a string of
numbers, e.g. system12.1.2.0.40.66.59 and will be located in your user directory. Please make
sure you copy the correct path into the script.
The location of the domain directory depends on the value of JDEV_USER_DIR when
you created the default domain. It will look like
$JDEV_USER_DIR/system12.1.2.0.40.66.59/DefaultDomain
If you cannot find your domain home, open EM FM Control Error! Hyperlink reference
not valid., where host/port are the admin server host and port values, e.g.
http://localhost:7101/em with username/password: weblogic/welcome1.
This will open a window with information about your environment, including your
Domain Home:
After setting <DomainPath> with the path to your domain directory open up a command
prompt and navigate to the AdapterConfig folder.
Run the script config_emails.bat if you are on windows, or config_emails.sh if you are on linux.
After restarting the server, you should see the updated configuration on the UMS Messaging
driver configuration page in EM FMW Control.
To verify this, go to Error! Hyperlink reference not valid., where host/port are the admin server
host and port values, e.g. http://localhost:7101/em.
Make sure you see the same values as in the screenshot below:
Prerequisites
If you did not complete Chapter 5, obtain and deploy the solution, following the steps below:
To deploy SOA solutions:
-
Locate e2e-1201-orderprocessing/solutions/ch5-packAndShip
Open JDeveloper
Open the previously unzipped application by selecting Application Open from the main JDeveloper
menu
Alternatively, if you already have an application e2e-1201-composites and only need to import specific
projects.
Locate from the following list of projects the ones you want to import in e2e-1201orderprocessing/solutions/ch5-packAndShip/SOAProjects:
-
ValidatePayment_ch2zip
ProcessOrder_ch3.zip
PackAndShipService_ch5.zip.
Locate e2e-1201-orderprocessing/solutions/ch5-packAndShip
Open JDeveloper
Open the previously unzipped application by selecting Application Open from the main JDeveloper
menu
Introduction
In this chapter, you will build the order fulfillment service.
The service is triggered when an order is updated as ReadyForShip in the database. It then locates the
shipping speed in the order message, determines the shipping method based on shipping speed and
shipping state, reads the preferred shipping provider from the database or cache, and calls the pack and
ship REST service.
When its completed, your project will look like this.
High-Level Steps
The DB adapter polls the order table for orders that are ready for shipment. (This will be used
later for the ESS use case where we activate this adapter only at certain times of the day.).
It receives a single order and transforms it into a fulfillment order (using XSLT).
A business rule (decision table) is used to decide the shipping method based on shipping speed
and shipping state.
Based on the shipping method, the preferred shipping provider is retrieved from the database.
The Order is sent to the packing service via SOA REST outbound.
The coherence adapter puts the shipping provider into the cache, so that it can be retrieved
from the cache instead of the database.
Steps in Detail
Create the FulfillOrder project from SOA project template
Click OK
Click Next
The composite name is automatically retrieved from the project name you entered earlier
Importing the project template creates a new project with two database adapters and a BPEL
process
The first database adapter listens to orders with status ReadyForShip, reads the record out of the
database and triggers a new BPEL process for each order.
In order to prevent the order from being read again, it changes the status to ReadyForPack.
The second database adapter reads the shipping provider from the database, using the shipping
method ID as primary key.
As part of the database setup, we keep a list of preferred shipping providers per shipping method.
For example, USPS is used for USAFirstClass shipping (shipping method ID =1), UPS for USAPriority
(shipping method ID =2), and so on.
The message provided from the database adapter is in a format specific to the database adapter.
An XSLT map is used to transform the message into a canonical order message
The fulfillOrder BPEL process is invoked with the canonical order message as input.
The incoming order message includes the shipping speed selected by the customer:
Two-Day shipping
One-Day shipping
The shipping method ID is hard-coded at the moment to 2 (=USAPriority). This will be replaced by a
business rule that determines the shipping method based on shipping speed and shipping address.
This shipping method ID is used as input to the database call to retrieve the shipping provider.
One of the following sections will describe how to invoke the previously defined packAndShip REST
service.
The last section will explain how to use the coherence cache for the shipping provider instead of
reading it from the database every time its needed.
In the composite editor, drag and drop a Business Rule component to the Components swim
lane
Name it DetermineShippingRules
Click OK
Again, expand CanonicalOrder.xsd under Project Schema Files and select Shipping
Click OK
Click OK
A new view opens where we can specify the conditions and actions to take based on those
conditions
You will see a drop down list where you can select the specific elements you want to define
conditions for
Add a second condition for shipping state by clicking on the + sign and selecting Condition:
Click on the ? in the R1 column. A list appears that allows us to select from the valid values for
shippingSpeed.
Click OK
For R4, select Specify Value as Dont Care. For this rule, shipping speed does not matter
Add a condition for state in R4: TX. Make sure to hit enter after entering the value.
For the other rules we dont care about the state, only shipping speed matters.
Select ShippingType as the type were going to modify and shipMethod as the element
Click OK
Now define the specifics of the actions for each Rule column:
Here is a broader perspective of what your decision table should now look like
Notice there is a conflict the dictionary shows you that more than one rule can fire for certain
input values. Double-click the Rule 4 conflict and have it override rules 1 and 2.
Click OK
Before adding the business rules activity to the BPEL process, change the name of the decision
table to DetermineShippingMethod by clicking on the name on top
From the composite view double click the fulfillOrder BPEL process
In the BPEL Process editor, drag a Business Rule (in SOA Components) under the receiveInput
activity
Select the Dictionary or Business Rule that this activity invokes in the Edit Rule window. In this
case its the DetermineShippingRules Dictionary.
Next define the Copy Rules for the Input and Output Facts.
You will copy the ShippingType from the process inputVariable to the dsIn variable of the
Business Rule.
For the output were going to copy the ShippingMethod from the dsOut variable of the
Business Rule to the shippingMethodID process variable
On the left we have the source or From. On the right we have the destination or To
On the right, under Scope Rule1 - Variables, expand dsIn payload callFunctionStateless parameterList and select Shipping
Click OK
Click OK
Click OK
In the Flow Trace you will now see the business rule:
In the BPEL process audit trail, you can see that the business rule activity consists of a number
of other activities
This reflects what you see when you expand the activity in the BPEL editor.
In the test message, state is CA and shipping speed is standard. The result of the business rule is
3.
As we did in previous chapters, we will add a composite sensor for the orderNumber
With the database service selected, click the blue + sign to create a new sensor
Choose the orderNumber in the input message by expanding the in node, select orderNumber
and click Insert Into Expression
Click OK again
Open the composite editor and drag and drop a REST binding into the External References
swimlane.
Name it packAndShipOrder
Add the operations based on the WADL file created in the previous chapter:
Click the green + sign to the right of Operations Bindings and choose Add operations based
on WADL Service
Expand the SOA node and find the PackAndShipService REST interface
Click OK again
Uncheck Maintain original directory structure for imported files and Rename duplicate
files
Click OK
Click OK
Automatically create input and output message and keep the default names
Create a new assign activity before the invoke to set the input message for the REST service
Name it assignShipping
In the Assign Editor, map the shipping element in the process input variable to the shipping
element in the input variable for the REST service
(invokePackAndShipOrder_packAndShip_InputVariable)
As the shipping method is optional in Shipping, make sure to right-click on the copy rule and
choose insertMissingToData, which will create the element
The shipping element in the original order does not include the order number, which is needed
for the order confirmation email in the PackAndShipService. Map the order number in the input
variable to the order number in the shipping element.
Make sure you also choose insertMissingToData as the order number in shipping is optional.
The BPEL process is one-way, so there is no need to assign the return value of the REST service.
Deploy and test/debug the FulfillOrder project by running the ProcessOrder composite. This will cause
an order in the database to be updated to ReadyForShip, which triggers the FulfillOrder project.
In EM FMWC, you will now see the FulfillOrder and the PackandShipService composites.
When you extracted the soabeta.zip file, it created an AdapterConfig folder under e2e-1201orderprocessing/scripts. This folder includes the scripts necessary for the UMS setup.
On linux, you may have to change permissions for the script files. Please make sure you can
execute them..
Ensure that MW_HOME is set. For example execute the following command on windows: set
MW_HOME=C:\Middleware\0610\soabeta or on linux setenv MW_HOME
/user/sgeib/0610/soabeta, using the correct path for your installation
Open up the target_adapters.py file and check the host/port, userName, password and the
server name.
The script uses the default values and should work if you havent made any changes to the
defaults. If you didnt use the default values, please change the file accordingly
host: localhost
port: 7101
username/password: weblogic/welcome1
Server Name: DefaultServer
You should now be able to see that the adapters are in Active state in the WLS Admin Console.
Navigate to Error! Hyperlink reference not valid. where host/port are the admin server
host and port values (default is http://localhost:7101/console).
Click on Deployments on the left hand side.
You should see the Coherence Adapter in the table on the right.
Next, we will incorporate the coherence lookup. For this, we must structure the database call so that it is
invoked only if the data is not found in the cache.
Invoke Get on the coherence cache via coherence adapter (lookup by Shipping Method
ID)
If data was returned, populate the Shipping Provider within the Shipping variable from
the coherence lookup response.
Execute the database adapter interaction to retrieve the Shipping provider details.
Invoke Put on the coherence cache via coherence adapter. The key would be the
ShippingMethodID and the value would be the XML returned by the coherence
adapter.
Populate the Shipping Provider within the Shipping variable from the database
lookup response.
Drag and drop the coherence adapter (under Technology Adapters) into the External
References swimlane of the composite.
Name it queryCoherence.
Click Next
Click Next
Click Next
We will use the prebuilt internal coherence cache for this demo. Set Cache Name to adapterlocal
You will populate the Key using a jca.coherence.Key property later. Leave it empty, click Next
and ignore the warning.
Pick up the database lookup response Schema definition as the XML Schema. The response from
the database lookup will be directly stored in the coherence cache.
Click OK
Click Next.
Click Finish.
You do not need to specify any input data into this invocation except for the jca.coherence.Key
property on the invocation.
Drag and drop an invoke activity before the assignShippingMethodForDBAdapter assign activity
to wire to the QueryCoherence partnerlink.
Name it queryCoherence
Automatically create the Input and Output variable as you did previously
Select the Properties tab and click the green + sign to add a new property
Browse to the variable that is used as key value in the coherence cache
This will populate the shippingMethodID variable contents into the property and pass it on the
invocation to the adapter.
Click OK
Note that you dont need to create an assign statement and assign an input value to the coherence
query interaction. The only input value required to query is the Key which, as shown above, is
passed in as a property to the invocation.
Drag and drop an If activity into the BPEL code after the invoke activity.
Double click on the If to specify the condition as shown below. Use the XPath Expression
Builder to create the expression.
Click OK
Click OK
Name it assignShippingProvider
Use the Assign Editor to assign the shipping provider name from the coherence query output
variable to the shipping provider name in the process input variable (in the shipping element).
This will later be used as input for the pack and ship service.
Ensure that you specify insertMissingToData on this statement by right-clicking the highlighted
expression in the bottom part of the Edit Assign window so that the Name is inserted into the target
document if it does not already exist.
Next, move the database adapter invocation (getShippingProvider), including its two assign
activities (assignShippingMethodForDBAdapter and assignShippingProvider) into the Else
block.
Drag and drop another coherence adapter into the right swimlane and name if
putIntoCoherence
Click Next
Click Next
Click Next
Enter the Key value as shippingMethodKey. We will override this value in the BPEL Process.
Click Next
Click Next
Click Finish
Double click the fulfillOrder BPEL process to open the BPEL editor
Drag and drop an invoke activity into the else branch below the assign activity
Name it putIntoCoherence
Select the Properties tab and click the green + sign to add a new property
Browse to the variable that is used as key value in the coherence cache
This will populate the shippingMethodID variable contents into the property and pass it on the
invocation to the adapter
Click OK
Following this, drag and drop an assign activity before the invoke to populate the input variable
of the coherence adapter with the output variable of the database call.
Name it assignCoherenceInput
You will see that initially both coherence adapters are executed. QueryCoherence returns and empty
variable as nothing has been put into the coherence cache yet. PutCoherence then puts the content into
the coherence cache:
Once the message has been put into the coherence cache, you will see that the audit trail has changed:
QueryCoherence returns the shipping method variable and the database doesnt need to be queried
anymore:
Introduction
This document outlines how to deploy a project for SOA composites and Service Bus, how to debug and
different ways to test within JDeveloper and Enterprise Manager Fusion Middleware Control.
It also describes how to open JDeveloper and how to start and stop the Integrated WebLogic Server.
Appendix
You will see a new tab at the bottom Running: IntegratedWebLogicServer Log, which shows
the server log file
The server is up and running when you see the following message:
[IntegratedWebLogicServer started.]
Appendix
Click on the red Terminate icon on top of your JDeveloper window and choose
IntegratedWebLogicServer
Appendix
Audit tracking enables you to select the level of information to be collected by the message tracking
infrastructure.
Off: No logging is performed. Composite instance tracking information and payload tracking
information are not collected.
Production: Minimal information for SOA composite application instances is collected. For
example, the BPEL process and Oracle Mediator service engines do not capture the payload.
Therefore, the payload details are not available in the flow audit trails. The BPEL process service
engine collects payload details for all activities except assign activities. This level is optimal for
most standard operations and testing.
Development: Complete information for SOA composite application instances is collected. This
option allows both composite instance tracking and payload tracking. This setting may have an
impact on performance because the payload is stored at each step in the message flow. This
setting is useful for debugging purposes.
For our labs, we need to make sure that the audit level is set to Development.
Right-click on soa-infra (Default Server) and choose SOA Administration > Common Properties.
Appendix
Click Apply
You will see a confirmation that the change has been made:
Appendix
Appendix
Open JDeveloper
Open the previously unzipped application by selecting Application Open from the main JDeveloper
menu
Alternatively, if you already have an application e2e-1201-composites and only need to import a chapter
project:
Locate the following project in /solutions/ch3-processOrder/SOAProjects:
-
ProcessOrder_ch3.zip
Appendix
Locate /solutions/ch2-validatePayment
Open JDeveloper
Open the previously unzipped application by selecting Application Open from the main JDeveloper
menu
Appendix
Right-click on the project name in the project menu - select Deploy and your project name. Make
sure you have the project menu and not the application menu in order to see this option.
Click Next.
The SOA Deployment Configuration dialog opens. When deploying a project, you have to choose
the Revision ID. If you previously deployed the same project with the same Revision ID, the
deployment will fail, unless you choose to overwrite an existing project with the same ID.
If you deploy with a new Revision ID, this will become the default.
For our labs, we will deploy with Revision ID 1.0 and check the box to Overwrite any existing
composites with the same revision ID.
This will now be your default deployment profile, until you change it.
Appendix
Click Next.
If you previously configured additional application servers, you will see all of them in this list.
The SOA Server is looked up to make sure that the server you chose is indeed a SOA server and that
the server is running. If that is not the case, you will get an error.
Appendix
Click Next.
Next the application is built and deployed. If there are no compilation errors, you will see on the
SOA log, at the bottom of JDeveloper, BUILD SUCCESSFUL and then the deployment starts.
Appendix
Wait for your application to be deployed and then you can run and test it.
Appendix
If Enterprise Manager is not open, go to http://localhost:7101/em (adapt your host and port if
necessary).
Navigate to the composite home page or soa-infra node through following best practices
Select the ValidatePayment composite (or the composite you want to test).
On this page, you can see the Recent Instances, Fault Instances, Component Metrics, and the
Services and References Metrics.
Appendix
Appendix
You can see the WSDL location, Operations list, and two tabs, Request and Response for the test
message.
Scroll down to the Input Arguments section
Specify your values for the payload. You can use the HTML form on the Tree View, which is default, or
the XML source on the XML View. For smaller amounts of the data, using the HTML form view is
probably easier. But for large payloads, it's easier to copy-and-paste your data into the XML View.
Appendix
Enter the data or switch to XML view and use the PaymentInfoSample_Authorized_soap.xml
sample message. This message already includes the SOAP envelope needed for the web service
test.
When the composite completes, the screen switches to the Response tab and the returned
value is shown.
Appendix
Click Launch Flow Trace. The Flow Trace screen opens and you can see the flow of your
composite and the status of each service, component and reference.
Click on the BPEL process to drill down into the instance details of the component
Appendix
Appendix
With the ValidatePayment composite open, choose the tab Flow Instances
For better performance, we dont show any flow instances when the view is opened. We leave it to
the user to decide how many instances he wants to see.
Appendix
Click Search to see all Flow Instances that were created in the last day.
Appendix
Bring the search options back and change the time to 2 days or change the state of the instances
you want to see. By default, you see all active instances.
Click on the Flow ID for one of the instances to open the Flow Trace window.
The first tab on this page shows all faults in the instance if there are any.
Appendix
Cause faults in your composite and come back here to see the list of faults. There will be a later lab
where this is explained in detail.
The second tab shows Sensor Values in your instance. Here you can see the sensor for the payment
status.
The third tab shows the composites that are part of this instance. Once you finish chapter 3, you will
see two composites here.
Appendix
You will see the name of the composite, sequence in flow (e.g. initiating or participating) and the
time when the flow entered the composite.
In this example we only have one composite, which initiates the flow.
Well get back to this view when more than one composite are involved.
Appendix
You will notice that in the audit trail, one assign is shown per copy rule, even if all copy rules are
done in one assign activity in the BPEL process.
Click on the Flow tab to get a graphic view of the BPEL process.
Appendix
Click on any node to get the details of what happened in the activity.
Appendix
The Sensors tab shows all activity sensors in the instance. We have not defined any activity sensors
yet, only composite sensors.
Appendix
Appendix
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.
Appendix
These breakpoints are red dots only without arrow as the flow is always in one direction:
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.
Appendix
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.
Click OK.
If youve made changes to your project, it needs to be redeployed. This includes setting of
breakpoints.
You will be lead through the deploy wizard step by step if that is the case.
Appendix
Every web service endpoint now shows a message that you can use the context menu to
initialize WS debugging:
Fill in all fields or choose HTTP Content at the bottom to be able to copy and paste an xml file
instead.
Appendix
Be aware that this sample message already includes the SOAP envelope needed for testing.
Appendix
If everything goes well, you should now see the debugger stop at your first breakpoint:
Go to the Data tab at the bottom of JDeveloper and look at your variable values:
Appendix
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
Appendix
If you set a breakpoint at the database adapter, it will jump out of BPEL and back to the
composite
After the calculate payment activity, the payment status has been set:
Appendix
On the left hand side, you also see the stack trace:
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.
To stop the debugger, click the big red icon in the Tools section and choose your project.
Appendix
For more information on SOA Debugger, please see Debugging SOA Composite Applications with the
SOA Debugger in soa-dev-guide.pdf.
Appendix
Open the Application Servers window if not already open from Window Application Servers
Expand Application Servers IntegratedWebLogicServer (or a different server if youre not using
integrated server) SOA Default Server (or your server name) default ValidatePayment
[Default 1.0] validatepaymentprocess_client_ep (ws)
Right-click on the service you want to test (validatepaymentprocess_client_ep (ws)) and choose
Test Web Service
Appendix
There you can enter the request message and test the service:
Use 0316 as ExpireDate for a valid credit card, any other value for an invalid credit card
Fill out the rest of the fields like in the screenshot below:
Appendix
Appendix
If everything goes well, you will see the reply in the right window:
Appendix
Appendix
The test framework supports testing at the SOA composite application level. In this type of testing,
wires, service binding components, service components (such as BPEL processes and Oracle Mediator
service components), and reference binding components are tested.
Test suites consist of a logical collection of one or more test cases. Each test case contains a set of
commands to perform as the test instance is executed. The execution of a test suite is known as a test
run. Each test corresponds to a single SOA composite application instance.
Emulations enable you to simulate the behavior of the following components with which your SOA
composite application interacts during execution.
Assertions enable you to verify variable data or process flow. You can perform the following types of
assertions.
As part of the composite tests, you can also automate the testing of an individual BPEL process service
component. These test cases enable you to simulate the interaction between a BPEL process and its web
service partners before deployment in a production environment.
You can create variable and fault assertions on BPEL process activities and fast forward on a wait
activity.
For more information, please see Automating Testing of SOA Composite Applications in soa-devguide.pdf.
In SOA Suite 12c, we add the ability to run the tests in JDeveloper (in addition to EM FMWC and
command-line). When making a change to a SOA composite or a test before running it, they are first
deployed. You can run the same test multiple times without changes.
You can also see the results after running the tests in JDeveloper, including assertions, and access the
history of the test results.
In addition we also made usability improvements to the test creation.
Gallery access and toolbar access is now provided and a test create wizard guides you to the creation of
simple tests in one shot. We also support the JDeveloper property inspector to create and edit test
metadata.
Two gallery items named 'Composite Test' and 'Composite Test Suite' have been introduced under the
category ' SOA Tier -> Tests' to create a test and a test suite respectively, as shown below:
Appendix
Creating a new Composite Test is also directly available in the shortcut menu from New and the
context menu:
Appendix
The test creation button is also exposed from the composite editor's toolbar as shown below (note the
composite test image button). You can directly create tests from within the composite editor:
Appendix
In this section, you will define and run tests for the ValidatePayment composite in JDeveloper.
Choose File > New > From Gallery from the menu.
Click OK.
In the subsequent Create Composite Test dialog, set the Test Name field to ValidatePaymentTest.
Click the Create Test Suite icon on the right of the Test Suite field. From here, you can create a new
test suite or select an existing test suite.
Appendix
Click OK.
Click Next.
Browse to PaymentInfoSample_Authorized.xml (dont pick the file with the soap envelope).
Appendix
Click Next.
Browse to PaymentInfoOutput.xml.
Appendix
Click Finish.
Once the Finish button is clicked, the test creation wizard closes and the test is created.
Additional test metadata like emulations can be added if necessary. If the current test is done, you
can continue to create another test by clicking the test image button from the editor's toolbar.
There are different ways to issue the run command. You can right-click the test suites or tests from
the JDeveloper navigator and select the corresponding run menu items.
If the test is already open in its test editor, you can also press the green arrow button from the test
editor's toolbar to run the open test.
Once the test run command is issued, it will first ask what test server to use to run the test if the test
server is not configured in JDev Tools -> Preferences -> SOA or is configured but has been set to ask
every time.
You enter the test server host name and can optionally check the 'Do not ask again' checkbox to
save the test server host name in JDev Tools -> Preferences -> SOA.
If the checkbox is checked, then this dialog will not pop up again next time you run tests until you go
to JDev Tools -> Preferences -> SOA to change the configuration.
The Test Run dialog pops up. In the test run dialog, you specify the test run name and can select or
deselect tests to run. The Test Run dialog also allows you to specify the timeout for running the tests
on the test server.
Appendix
Click OK.
Once the 'OK' button is clicked, we will check if the composite (which includes the tests) has been
deployed on the test server. If the composite has been never deployed on the test server or youve
made changes to the composite or the test since it was deployed last, the composite needs to be
deployed to the test server first before we the tests can be run on the test server.
The deployment wizard is the same one as when you just deploy the composite without tests
involved.
The composite test starts automatically when the deployment has finished.
If the tests ran successfully, the test result overview editor will open to show the test results.
Appendix
The test result overview editor is per test server and composite DN (unique identifier). We show the
test server URL (the SOA server hostname and the port number) and composite DN on the top right
corner of the editor to indicate the context. Due to space limitation, we do not this info on the
editor tab name. The editor tab name is in form of 'Test Results: <Composite-Name>'.
The test result overview editor also provides a toolbar button to go to the composite editor.
The test results are shown in three collapsible tables from master to details. The three tables are the
Test Run Table, the Test Case Table and the Assert Result Table.
The Test Run Table shows the current test run and its status summary if you just submitted a test
run from the test UI. If you just queried the test server for test runs, then the table shows all test
runs matching your query criteria.
The Test Case Table shows all test cases and their statuses of the selected test run from the Test
Run Table.
The Assert Result Table shows all assert results of the selected test case from the Test Case Table.
Click XML link in the Assert Result table to check the result. This will be more meaningful when you
cause a fault and compare the expected XML with the Actual XML.
Appendix
Make changes that will make the test fail or create new tests and check out the test result overview
editor.
To change the input message, right-click on the SOAP interface and choose Edit Initiate Messages
Appendix
The expected output message counts as an assert. To change it, right-click on Asserts and Emulates
and choose Edit Asserts and Emulates
Appendix
Open Enterprise Manager: http://localhost:7101/em (adapt your host and port if necessary) if not
already open.
The first time these screens are run after starting the server they will be slow as they are unpacked,
compiled, and loaded into memory.
The SOA composites are listed under the SOA folder in the Target Navigator.
Navigate to the composite home page or soa-infra node through following best practices
Select your composite from the list of composites. The composite page opens.
Appendix
The view opens with the composite Dashboard where you can see all Services and References
You can switch between Design and Source view and zoom in and out
Appendix
Open EM at http://localhost :7001/em (substitute your own host and port if necessary) and go
to your composite.
Navigate to the composite home page or soa-infra node through following best practices
Appendix
Check the box behind the test you previously created: ValidatePaymentTest.xml and click on
Execute
Appendix
Clicking on XML link of Expected\Actual value column shows that Actual value matched with
Expected value.
Appendix
Launch the flowtrace and see its execution and the sensor values
In the flow-instance tab of soa-infra\composite, the instances executed as part of unit tests are
marked with a yellow dot as shown below
Appendix
Appendix
Appendix
Click Show WADL and Text description URL icon on the top.
You can see the Text description URL and the Service WADL.
Appendix
You can access those tables directly from JDeveloper by following the steps below.
Right click on the connection SOA, which has been created in chapter 2, lab 1, and click Open in
Databases Window.
Appendix
In the database window, right click on the connection and choose Open SQL Worksheet
Appendix
You can check on the order tables by entering something like select * from E2E_1201_ORDERS;
and click on the Run Statement button
You will see the result of the query under Query Results
Appendix
Appendix
In order to deploy to other servers, local or remote, the following steps are necessary.
In the New Gallery, in the Categories tree, select General, and then Connections.
Appendix
Enter MyAppServerConnection in the Connection Name field and select WebLogic 10.3 from
the Connection Type list.
Appendix
Enter weblogic for the User Name and the password (welcome1) for that administrator in the
Password field.
Appendix
If the test is unsuccessful, ensure that Oracle WebLogic Server status is RUNNING, and retry the test.
Appendix
Appendix