Escolar Documentos
Profissional Documentos
Cultura Documentos
Services
If a service-oriented architecture is to be effective, we need a clear understanding of the term service. A
service is a function that is well-defined, self-contained, and does not depend on the context or state of
other services.
Connections
The technology of Web services is the most likely connection technology of service-oriented
architectures. Web services essentially use XML to create a robust connection.
The following figure illustrates a basic service-oriented architecture. It shows a service consumer at the
right sending a service request message to a service provider at the left. The service provider returns a
response message to the service consumer. The request and subsequent response connections are
defined in some way that is understandable to both the service consumer and service provider. How
those connections are defined is explained in Web Services explained. A service provider can also be a
service consumer.
Service components
Wires
WARNING: Always save your changes by selecting Save All from the tool bar menu.
Then...
Has no applications
In the Application Navigator in the upper left, click New Application > SOA
For example, you are
Application.
opening Oracle JDeveloper
for the first time.
If Oracle Jdeveloper...
Then...
From the File main menu:
4.
Click OK.
Value
Application Name
Directory Name
Notes: On a UNIX operating system, it is highly recommended that you enable Unicode support
by setting the LANG and LC_All environment variables to a locale with the UTF-8 character set.
SOA components may function in an unexpected way. For example, a non-ASCII file name can
make the file inaccessible and cause an error. Oracle does not support problems caused by
operating system constraints.
In a design-time environment, if you are using Oracle JDeveloper, select Tools >
Preferences > Environment > Encoding > UTF-8 to enable Unicode support. This is also
applicable for runtime environments.
o
Do not create applications and projects in directory paths that have spaces (for example,
c:\Program Files).
2. Accept the default values for all remaining settings, and click next.
The Project Name page of the Create SOA Application wizard appears.
3. Enter a name for the project (for this example, My SOA Project), and click Next. Note that SOA is
automatically selected as the project technology to use.
Note: Composite and component names cannot exceed 500 characters.
A project deployed to the same infrastructure must have a unique name across SOA composite
applications. This is because the uniqueness of a composite is determined by its project name.
For example, do not perform the actions described. During deployment, the second deployed
project (composite) overwrites the first deployed project (composite).
Restrictions on Naming an SOA Project
Application1
Project1
Application2
Project1
The Project SOA Settings page of the Create SOA Application wizard appears.
You drag service components into the designer to invoke the initial property editor. This action enables
you to define the service interface (and, for asynchronous BPEL processes, an optional callback
interface).
The above Figure describes the available service components.
Starting Service Component Editors
Dragging This Service
Component...
Invokes The...
BPEL Process
Create BPEL Process dialog: Enables you to create a BPEL process that
integrates a series of business activities and services into an end-to-end
process flow.
Business Rule
Create Business Rules dialog: Enables you to create a business decision based
on rules.
Human Task
Create Human Task dialog: Enables you to create a workflow that describes the
tasks for users or groups to perform as part of an end-to-end business process
flow.
Mediator
Create Mediator dialog: Enables you to define services that perform message
and event routing, filtering, and transformations.
The following example describes the procedures to perform when a BPEL process is dragged into the
designer.
To add a service component:
1. From the Component Palette, select SOA.
2. From the Service Components list, drag a BPEL Process into the designer.
The Create BPEL Process dialog appears.
3. Enter the details shown in
Table 4-5 Create BPEL Process Dialog Fields and Values
Field
Value
Name
Namespace
Template
For more information about available templates, see the online help.
Field
Value
Expose as a
SOAP Service
Deselect this checkbox. This creates a standalone BPEL process. If you select this
checkbox, a BPEL process and inbound web service binding component are each
created and connected.
BPEL Constructs: Displays core activities (also known as constructs) provided by standard BPEL
1.1 and 2.0 functionality. The activities in this category are displayed under additional
subcategories of Web Service, Activities, and Structured Activities in BPEL 1.1 and Web Service,
Basic Activities, and Structured Activities in BPEL 2.0.
Oracle Extensions: Displays extension activities that add value and ease of use to BPEL 1.1 and
2.0 functionality
1.Assign Activity
This activity provides a method for data manipulation, such as copying the contents of one variable to
another. Copy operations enable you to transfer information between variables, expressions, endpoints,
and other elements.
One of the ways you can copy data from source to target in a BPEL Process.
<assign name=Assign_1>
When you Double Click the Activity Icon. Assign popup window will appear
you can perform following operation
Copy operation
2.Compensate Activity
This activity invokes compensation on an inner scope activity that has successfully completed. This
activity can be invoked only from within a fault handler or another compensation handler. Compensation
occurs when a process cannot complete several operations after completing others. The process must
return and undo the previously completed operations. For example, assume a process is designed to
book a rental car, a hotel, and a flight. The process books the car and the hotel, but cannot book a flight
for the correct day. In this case, the process performs compensation by unbooking the car and the hotel.
The compensation handler is invoked with the compensate activity, which names the scope on which the
compensation handler is to be invoked.
Below Figure shows the Compensate dialog in BPEL 1.1. You can perform the following tasks:
Click the General tab to provide the activity with a meaningful name.
Select the scope activity on which the compensation handler is to be invoked.
In BPEL 2.0, the Compensate dialog does not include a Skip Condition tab.
3. Email Activity
This activity enables you to send an email notification about an event.
For example, an online shopping business process of an online bookstore sends a courtesy email
message to you after the items are shipped. The business process calls the notification service with your
user ID and notification message. The notification service gets the email address from Oracle Internet
Directory.
Figure A-11 shows the Email dialog in BPEL 1.1 and BPEL 2.0.
Figure A-11 Email Dialog
4. Empty Activity
This activity enables you to insert a no-operation instruction into a process. This activity is useful when
you must use an activity that does nothing (for example, when a fault must be caught and suppressed).
Figure a-12 Empty Dialog
In BPEL 2.0, the Empty dialog includes a Documentation tab and does not include a Skip Condition tab.
5. Flow Activity
This activity enables you to specify one or more activities to be performed concurrently. A flow activity
completes when all activities in the flow have finished processing. Completion of a flow activity includes
the possibility that it can be skipped if its enabling condition is false.
For example, assume you use a flow activity to enable two loan offer providers (United Loan service and
Star Loan service) to start in parallel. In this case, the flow activity contains two parallel activities the
sequence to invoke the United Loan service and the sequence to invoke the Star Loan service. Each
service can take an arbitrary amount of time to complete their loan processes.
Figure A-14 shows an initial flow activity with its two panels for parallel processing. You drag activities into
both panels to create parallel processing. When complete, a flow activity looks like that shown in Figure
A-15.
Figure A-14 Flow Dialog (At Time of Creation)
You can also synchronize the execution of activities within a flow activity. This ensures that certain actives
only execute after other activities have completed.
Note: Oracles BPEL implementation executes flows in the same, single execution thread of the BPEL
process and not in separate threads.
6. FlowN Activity
This activity enables you to create multiple flows equal to the value of N, which is defined at runtime
based on the data available and logic within the process. Index variable increments each time a new
branch is created, until the index variable reaches the value of N.
Figure A-16 shows the FlowN dialog.
Figure A-16 FlowN Dialog
7. Invoke Activity
This activity enables you to specify an operation you want to invoke for the service (identified by its
partner link). The operation can be one-way or request-response on a port provided by the service. You
can also automatically create variables in an invoke activity. An invoke activity invokes a synchronous
web service or initiates an asynchronous web service.
The invoke activity opens a port in the process to send and receive data. It uses this port to submit
required data and receive a response. For synchronous callbacks, only one port is needed for both the
send and the receive functions.
The invoke activity supports the bpelx: inputProperty and bpelx: outputProperty that facilitate the passing
of properties through the SOAP header and the obtaining of SOA runtime system properties for useful
information such as the tracking.compositeInstanceId and tracking.conversationId.
Figure A-20 shows the Invoke dialog in BPEL 1.1. You can perform the following tasks:
Automatically create a variable or select an existing variable in which to transport the data
(payload).
This activity enables you to add custom Java code to a BPEL process using the
Java BPEL exec extension <bpelx:exec>.
When user double clicks on the Java embedding icon, popup window will appear
and user can enter the java code on it.
9. Notification Activities
This activity enables you to send notification about an event to a user, group, or
destination address.
You can send a notification by e-mail, voice mail, fax, pager, or short message
service (SMS).
onAlarm (does not automatically display; you must manually add this branch by selecting the Pick
activity icon and clicking the Add OnAlarm icon)
Contains the code for a timeout, for example, after one minute.
Whichever branch completes first is executed; the other branch is not executed. The branch that has its
condition satisfied first is executed.
Figure A-25 shows the OnAlarm dialog of the pick activity in BPEL 1.1.
Figure A-25 OnAlarm Branch Dialog of a Pick Activity
Note: You can also create onMessage branches in BPEL 1.1 scope activities and onAlarm branches in
BPEL 1.1 and 2.0 scope activities. Expand the Scope activity in Oracle JDeveloper, and browse the icons
on the left side to find the branch you want to add.
If you add correlations to an OnMessage branch, the correlations syntax is placed after the assign activity
syntax. The correlation syntax must go before the assign activity.
As a work around, perform the following steps:
1. Create a correlation set in Oracle JDeveloper.
2. Assign this to the OnMessage branch.
3. Complete the remaining design tasks.
4. Before making or deploying the BPEL process, move the correlation syntax before the assign
activity in the BPEL
12. Receive Activity
This activity specifies the partner link from which to receive information and the port type and operation
for the partner link to invoke. This activity waits for an asynchronous callback response message from a
service, such as a loan application approver service. While the BPEL process is waiting, it is dehydrated
(compressed and stored) until the callback message arrives. The contents of this response are stored in a
response variable in the process.The receive activity supports the bpelx:property extensions that facilitate
the passing of properties through the SOAP header, and the obtaining of SOA runtime system properties
for useful information such as tracking.compositeInstanceId and tracking.conversationId.
Figure A-26 shows the Receive dialog in BPEL 1.1. You can perform the following tasks:
Automatically create a variable or select an existing variable in which to transport the callback
response.
complex structured activity, with many nested activities within it to arbitrary depth. The scope is shared by
all the nested activities.
Fault handling is associated with a scope activity. The goal is to undo the incomplete and unsuccessful
work of a scope activity in which a fault has occurred. You define catch activities in a scope activity to
create a set of custom fault-handling activities. Each catch activity is defined to intercept a specific type of
fault.
Figure A-34 shows the Add Catch icon inside a scope activity. Figure A-35 shows the catch activity area
that appears when you click the Add Catch icon. Within the area defined as Drop Activity Here, you drag
additional activities to create fault handling logic to catch and manage exceptions. For example, a client
provides a social security number to a Credit Rating service when applying for a loan. This number is
used to perform a credit check. If a bad credit history is identified or the social security number is
identified as invalid, an assign activity inside the catch activity notifies the client of the loan offer rejection.
The entire loan application process is terminated with a terminate activity.
Figure A-34 Creating a Catch Branch
A reply message with the final approval status of the request is sent back to the customer in a
reply activity.
A sequence activity makes the assumption that the request can be processed in a reasonable amount of
time, justifying the requirement that the invoker wait for a synchronous response (because this service is
offered as a request-response operation).
When this assumption cannot be made, it is better to define the customer interaction as a pair of
asynchronous message exchanges.
When you double-click the Sequence icon, the activity area shown in Figure A-36 appears. Drag and
define appropriate activities inside the sequence activity.
Figure A-36 Sequence Activity
Click the second icon (the Add icon) to the right of the Mapper File field to access the XSLT
Mapper for creating a new XSL file for graphically mapping source and target elements. Click the
Edit icon (third icon) to edit an existing XSL file.
.
21. Wait Activity
This activity allows a process to specify a delay for a certain period or until a certain deadline is reached.
A typical use of this activity is to invoke an operation at a certain time. This activity enables you to wait for
a given time period or until a certain time has passed. Exactly one of the expiration criteria must be
specified.
Figure A-46 Wait Dialog
In a one-way message, or fire and forget, the client sends a message to the service, and the service does
not need to reply. Figure 12-1 provides an overview.
Figure 12-1 One-Way Message
3. Asynchronous Interaction
In an asynchronous interaction, a client sends a request to a service and waits until the service replies.
Figure 12-3 provides an overview.
Each section of Oracle BPEL Designer enables you to perform specific design and deployment tasks.
Application Navigator
Design window
Source window
History window
Component Palette
Property Inspector
Structure window
Log windowNote:
To learn more about these sections, you can also place the cursor in the appropriate section and press F1
to display online Help.
Introduction to Partner Links
A partner link enables you to define the external services with which the BPEL process service
component is to interact. You can define partner links as services or references (for example, through a
JCA adapter) in the SOA Composite Editor or within a BPEL process service component in Oracle BPEL
Designer. Figure 5-8 shows the partner link icon (in this example, named WriteRecord).
Figure 5-8 PartnerLink Icon
Description
Name
A unique and recognizable name you provide for the partner link.
Process
Field
Description
WSDL URL The name and location of the Web Services Description Language (WSDL) file that you
select for the partner link. Click the SOA Service Explorer icon (second icon from the left
above the WSDL URL field) to access a window for selecting the WSDL file to use.
Partner
Link Type
Partner
Role
My Role
The role performed by the BPEL process service component. In this case, the BPEL process
service component does not have a role because it is a synchronous process.
Note:
The Partner Link Type, Partner Role, and My Role fields in the Create Partner Link dialog are defined and
required by the BPEL standard.
Creating a Partner Link
The method by which you create partner links within the BPEL process in Oracle BPEL Designer impacts
how the partner link displays above in the SOA Composite Editor. This section describes this impact. The
WSDL file can be on the local operating system or hosted remotely (in which case you need a URL for the
WSDL).
Likewise, creating and wiring a service or reference binding component to a BPEL process service
component in the SOA Composite Editor causes a partner link to display in Oracle BPEL Designer.
Figure 5-12 shows how this method of creation appears in the SOA Composite Editor.
Figure 5-12 SOA Composite Editor Impact
Partner Links from an Existing Human Task, Business Rule, or Oracle Mediator
Table 5-8 Impact of Partner Link Creation on the SOA Composite Editor
Creating the Following for a BPEL Process in Oracle Displays the Following in the SOA
BPEL Designer...
Composite Editor...
A partner link by dragging an existing human task,
business rule, or mediator service component from the
Resource Palette to the BPEL process
A web service operation cannot complete successfully, and the service returns a fault
An internal process error occurs, and a standard BPEL fault is thrown. Refer to the list of BPEL
Standard Faults for more information.
A <throw> or <rethrow> activity throws a fault
A platform-specific fault, such as a communication failure, occurs in a BPEL process instance
Fault handling can be global or local: you can add fault handlers to the process as a whole or to a scope
within the process.
When a fault occurs, normal processing is terminated, and control is transferred to the corresponding fault
handler, as defined in the <faultHandlers> section of the process or scope.
Note that the process does not enable compensation for a scope in which a fault handler is invoked.
Fault handlers do not rely on state to determine which nested scopes have completed successfully.
The code segment in Example 12-1 defines the fault handler for this operation in the BPEL file:
Example 12-1 Fault Handler Definition
<faultHandlers>
<catch faultName="services:NegativeCredit" faultVariable="crError">
<assign name="crin">
<copy>
<from expression="-1000">
</from>
<to variable="input" part="payload"
query="/autoloan:loanApplication/autoloan:creditRating"/>
</copy>
</assign>
</catch>
</faultHandlers>
The faultHandlers tag contains the fault handling code. Within the fault handler is a catch activity, which
defines the fault name and variable, and the copy instruction that sets the creditRating variable to -1000.
When you select web services for the BPEL process service component, determine the possible faults
that may be returned and set up a fault handler for each one.
Introduction to BPEL Standard Faults
The Business Process Execution Language for Web Services Specification defines the following standard
faults in the namespace of http://schemas.xmlsoap.org/ws/2003/03/business-process/:
bindingFault
conflictingReceive
conflictingRequest
correlationViolation
forcedTermination
invalidReply
joinFailure
mismatchedAssignmentFailure
remoteFault
repeatedCompensation
selectionFailure
uninitializedVariable
Business faults
Runtime faults
Business Faults
Business faults are application-specific faults that are generated when there is a problem with the
information being processed (for example, when a social security number is not found in the database). A
business fault occurs when an application executes a throw activity or when an invoke activity receives a
fault as a response. The fault name of a business fault is specified by the BPEL process service
component. The messageType, if applicable, is defined in the WSDL. A business fault can be caught with
a faultHandler using the faultName and a faultVariable.
This section provides an overview of the components that comprise the fault management framework.
The fault management framework catches all faults (business and runtime) for an invoke activity.
A fault policy file defines fault conditions and their corresponding fault recovery actions. Each fault
condition specifies a particular fault or group of faults, which it attempts to handle, and the
corresponding action for it. A set of actions is identified by an ID in the fault policy file.
A set of conditions invokes an action (known as fault policy).
A fault policy bindings file associates the policies defined in the fault policy file with the following:
o SOA composite applications
o BPEL process and Oracle Mediator service components
o Reference binding components for BPEL process and Oracle Mediator service
components
The framework looks for fault policy bindings in the same directory as the composite.xml file of
the SOA composite application or in a remote location identified by two properties that you set.
Note:
A fault policy configured with the fault management framework overrides any fault handling
defined in catch activities of scope activities in the BPEL process. The fault management
framework can be configured to rethrow the fault handling back to the catch activities.
The fault policy file (fault-policies.xml) and fault policy bindings file (fault-bindings.xml) are placed
in either of the following locations:
o In the same directory as the composite.xml file of the SOA composite application.
o In a different location that is specified with two properties that you add to the
composite.xml file. This option is useful if a fault policy must be used by multiple SOA
composite applications. This option overrides any fault policy files that are included in the
same directory as the composite.xml file. Example 12-3 provides details about these two
properties. In this example, the fault policy files are placed into the SOA Metadata
Service (MDS) shared area.
Example 12-3 Fault Policies used by Multiple SOA Composite Applications
<property
name="oracle.composite.faultPolicyFile">oramds://apps/faultpolicyfiles/
fault-policies.xml
</property>
<property
name="oracle.composite.faultBindingFile">oramds://apps/faultpolicyfiles/
fault-bindings.xml</property>
The catch activity works within a scope to catch faults and exceptions before they can throw the
entire process into a faulted state. You can use specific fault names in the catch activity to
respond in a specific way to an individual fault.
The catchAll activity catches any faults that are not handled by name-specific catch activities.
Adapters enable you to integrate the BPEL process service component (and, therefore, the SOA
composite application as a whole) with access to file systems, FTP servers, database tables, database
queues, sockets, Java Message Services (JMS), MQ, and Oracle E-Business Suite. This wizard enables
you to configure the types of adapters shown in Figure 5-17 for use with the BPEL process service
component:
Figure 5-17 Adapter Types
Database
Oracle Applications
Oracle B2B
Sockets
Third Party
ADF-BC Service
This service connects Oracle Application Development Framework (ADF) applications using SDOs with
the SOA platform.
AQ Adapter
This adapter acts as both a dequeue (inbound) and enqueue (outbound) messaging adapter. In the
inbound direction, the adapter polls the queues for messages to dequeue from a destination. In the
outbound direction, the adapter enqueues messages to the queue for subscribers to dequeue.
Oracle B2B
This adapter enables you to browse B2B metadata in the Metadata Service (MDS) repository and select
document definitions.
Oracle B2B is an e-commerce gateway that enables the secure and reliable exchange of transactions
between an organization and its external trading partners. Oracle B2B and Oracle SOA Suite are
designed for e-commerce business processes that require process orchestration, error mitigation, and
data translation and transformation within an infrastructure that addresses the issues of security,
compliance, visibility, and management.
Oracle BAM Adapter
This adapter integrates Java EE applications with Oracle BAM Server to send data. This adapter is used
as a reference binding component in a SOA composite application.
Database Adapter
This adapter enables a BPEL process to communicate with Oracle databases or third-party databases
through JDBC. To access an existing relational schema, you use the Adapter Configuration Wizard to do
the following:
While your BPEL process deals with XML and invokes web services, database rows and values are
queried, inserted, and updated.
Direct Binding Service
This service uses the Direct Binding API to invoke a SOA composite application in the inbound direction
and exchange messages over a remote method invocation (RMI). This option supports the propagation of
both identities and transactions across JVMs and uses the T3 optimized path. Both synchronous and
asynchronous invocation patterns are supported.
You can also invoke an Oracle Service Bus (OSB) flow or another SOA composite application in the
outbound direction.
EJB Service
This service enables you to send and receive messages through Enterprise JavaBeans (EJBs).
File Adapter
This adapter acts as both an inbound and outbound adapter. In the inbound direction, the adapter polls for
files in a directory to retrieve and process. In the outbound direction, the adapter creates files in a
directory.
FTP Adapter
This adapter acts as both an inbound and outbound adapter. In the inbound direction, the adapter polls for
files in a directory to retrieve and process. In the outbound direction, the adapter creates files in a
directory.
HTTP Binding
This service enables you to integrate SOA composite applications with HTTP binding. This service
enables you to invoke SOA composite applications through HTTP POST and GET operations, and invoke
HTTP endpoints through HTTP POST and GET operations.
JMS Adapter
This adapter acts as both a consume (inbound) and produce (outbound) messaging adapter. In the
inbound direction, the adapter polls (consumes) messages from a JMS destination. In the outbound
direction, the adapter sends (produces) messages to a JMS destination.
MQ Adapter
This adapter provides message exchange capabilities between BPEL processes and the IBM MQSeries
messaging software.
Oracle Applications
This adapter provides comprehensive, bidirectional, multimodal, synchronous, and asynchronous
connectivity to Oracle Applications. The adapter supports all modules of Oracle Applications in Release
12 and Release 11i, including selecting custom integration interface types based on the version of Oracle
E-Business Suite. The adapter provides real-time and bidirectional connectivity to Oracle Applications
through interface tables, views, application programming interfaces (APIs), and XML Gateway. The
adapter inserts data into Oracle Applications using interface tables and APIs. To retrieve data from Oracle
Applications, the adapter uses views. In addition, it uses XML Gateways for bidirectional integration with
Oracle Applications. XML Gateways are also used to insert and receive Open Application Group
Integration Specification
Socket Adapter
This adapter enables you to model standard or nonstandard protocols for communication over TCP/IP
sockets. You can use this adapter to create a client or server socket, and establish a connection. The data
that is transported can be text or binary.
Third Party Adapter
This adapter enables you to integrate third-party adapters into a SOA composite application. These thirdparty adapters produce artifacts (WSDLs and JCA files) that can configure a JCA adapter.
Mediators:
Introduction to Oracle Mediator
Oracle Mediator provides a lightweight framework to mediate between various components within a
composite application. Mediator converts data to facilitate communication between different interfaces
exposed by different components, which are wired together to build a SOA composite application. For
example, a Mediator can accept data contained in a text file from an application or service, transform it to
a format appropriate for updating a database that serves as a customer repository and then route and
deliver the data to that database.
Oracle Mediator facilitates integration between events and services, where service invocations and
events can be mixed and matched. You can use a Mediator component to consume a business event or
to receive a service invocation. A Mediator component can evaluate routing rules, perform
transformations, validate, and either invoke another service or raise another business event. You can use
a Mediator component to handle returned responses, callbacks, faults, and timeouts.
This section provides an overview of Oracle Mediator features:
Oracle Mediator provides support for setting rules based on message payload or message
headers. You can select elements or attributes from the message payload or the message header
and based on the values, you can specify an action. For example, Mediator receives a file from
an application or service containing data about new customers. Based on the country mentioned
in the customer's address, you can route and deliver data to the database storing data for that
particular country. Similarly, you can route a message based on the message header.
Transformations
Oracle Mediator supports data transformation from one XML schema to another. This feature
enables data interchange among applications using different schemas. For example, you can
transform a comma-delimited file to the database table structure.
Validations
Oracle Mediator provides support for validating the incoming message payload by using a
Schematron or an XSD file. You can specify Schematron files for each inbound message part and
Oracle Mediator can execute Schematron file validations for those parts.
Java Callout
Oracle Mediator provides support for Java callout. Java callouts enable the use of Java code,
together with regular expressions.
Event Handling
An event is message data sent because of an occurrence of an activity in a business
environment. Oracle Mediator provides support for subscribing to business events or raising
business events. You can subscribe to a business event that is raised when a situation of interest
occurs. For example, you can subscribe to an event that is raised when a new customer is
created and then use this event to start a business process such as sending confirmation email.
Similarly, you can raise business events when a situation of interest occurs. For example, raise a
customer created event after completing the customer creation process.
Dynamic Routing
Dynamic Routing separates the control logic, which determines the path taken by the process,
from the execution of the process. You can create a dynamic routing rule from the Mediator
Editor.
Error Handling
Oracle Mediator supports both fault policy-based and manual error handling. A fault policy
consists of conditions and actions. Conditions specify the action to be carried out for a particular
error condition.
Mediator serves the purpose of a bus. It can be best utilized when used for routing. It can do routing
based on many parameters and the best part is, the routing rules can be modified at runtime, thus giving
the flexibility to choose the target at any point in time.
BPEL
1) Complex Logic
2) Good Support language in form ofactivities
3) Performance wise very slow
4) Support of Dehydration and Instance Monitoring
5) For Long Running process BPEL is the Right Solution
6) To implement the controlled Transactions
Integration of Rules Engine and Human Workflow
7) To implement the service virtualization BPEL is not the right approach
Mediator
1) Less Complex Logic
2) Less Support
3) Three times faster than BPEL
4) No support of de hydration
5) For Long Running process not a proper solution
6) You cannot control the transactions in Mediator.
7) Mediator is the right approach for the service virtualization
Virtualization Service virtualization provides companies with the ability to create virtual services that
offer a stable interface (location, transport, standards, policies, messages) even when the physical
service changes. Virtualization offers high-availability and load-balancing, performance and SLA
monitoring and management, routing, versioning, and mediation capabilities to mitigate the impact of
change at the provider on service consumers.
Mediator is used for Transformation and Routing.
Routing------------------Static routing and Dynamic Routing
Static----------------Serviced Based & Event Based
Dynamic------------Business Rules
After acquisition of BEA its role is to provide mediation services between SOA Suite
components
In 11g this will be known as the Mediator and acts as a component in an SCA assembly
the preferred platform for service virtualization and interactions external to the SOA Suite
Currently OSB is only available on WebLogic server but the intention is provide it on other
platforms as well in the future
Limited to simple Mediator functionality for the implementation of the VETRO pattern
V alidade
E nrich
T ransform
R oute
O perate
Value Mapping and Cross-Reference Table for supporting the canonical datamodel
Message Throttling
Service Pooling
Reliable Messaging
This might be less of a problem when using both the Oracle SOA Suite together with the Oracle
Service Bus in a larger architecture. In this case, the responsibility for mapping these values can
be delegated to the SOA Suite 11g Mediator component, where the DVM functionality is
available.
But if only the OSB is used standalone, then such value mappings would be nice in the OSB as
well. With the help of XQuery the DVM functionality can be implemented in a similar way, so that
if the feature is later available in a new version of OSB, it can be replaced by that with minimal
work involved. This blog entry shows the custom DVM functionality implemented for the Oracle
Service Bus.
CityName
BELG_MN_STLouis
BelgradeStLouis
BELG_NC
BelgradeNorthCarolina
BO
Boston
NP
Northport
CityCode
CityName
KN_USA
KensingtonUSA
KN_CAN
KensingtonCanada
Each domain value map typically holds a specific category of mappings among multiple applications. For
example, one domain value map may hold mappings for city codes and another may hold mappings for
state codes.
Domain value map values are static. You specify the domain value map values at design time using
Oracle JDeveloper, and then at runtime, the domain value map columns are looked up for values.
MDS
MDS is used as a repository for managing and reusing shared resources like XSD, WSDL, XSL files.
MDS should be implemented from day 1 of development otherwise developers will run into XSD
mismatch, also during production it will be very tough to keep the XSD same.
The concept is very simple, rather than each project picking the xsd (any other file) from there project's
'xsd' folder, pick it from the common/shared folder.
Oracle SOA suite 11G provides Central MDS and Local MDS.
Central MDS is present inside the SOA server
*** Ideally all the artifacts should be inside the central MDS.
XRef Tables :
The Xref tables we create is a one-time activity and we can refer to any XREF table from oramds, if it is
properly populated in XREF_DATA. We will be using BPEL process for populating the data.
Rules Designer
Navigation Tab
Description
Facts
Functions
Globals
Bucketsets
Links
Decision Functions
A ruleset provides a unit of execution for rules and for Decision Tables. A
Decision Table provides a mechanism for describing data processing tasks.
Human interactions with processes, including assignment and routing of tasks to the correct
users or groups
Deadlines, escalations, notifications, and other features required for ensuring the timely
performance of a task (human activity)
Presentation of tasks to end users through a variety of mechanisms, including a worklist
application (Oracle BPM Worklist)
Organization, filtering, prioritization, and other features required for end users to productively
perform their tasks
Reports, reassignments, load balancing, and other features required by supervisors and business
owners to manage the performance of tasks
Creating and modeling a human task service component in the SOA Composite Editor
Associating it with a BPEL process
Generating the task form for displaying the human task during runtime in Oracle BPM Worklist.
3. On the right side of the Parameters section, click the Add icon to specify the task payload.
The Add Task Parameter dialog is displayed. You now create parameters to represent the
elements in your XSD file. This makes the payload data available to the workflow task.
4. Select Element.
5. To the right of the Element field, click the Search icon.
Description: Employee information is sent to BAM Example Process (BPEL). BPEL sensors sends
this information through BAM Adapter to populate Employee Data Object in BAM. Employee Dashboard
report will capture this information and show in the form of a 3D Bar chart.
Steps to implement use-case:
1.
2.
3.
4.
Click on "Create Data Object" and enter "Employee" in the name field.
Click on "Add Field" and add following fields: id (Auto-incrementing Integer), name (String),
department (String).
Click on "Create Data Object" to finish creation. You can optionally create a sub-folder to hold
Employee object.
Make sure Employee object is visible under Data Objects section.
Select "Employee" object from Data Objects section at the bottom and click on Next button.
Select Department in Group By section, id in Chart Values and Count in Summary
Function(s). Click on Next and then Finish button.
Save this report and it will be visible through "Recent Reports" in Home tab. This report now
shows Employee count grouped by Department.
We can see predefined connection pools for RMI and SOAP connections. Expand both
connection factory links. We need to configure these connection pools to use BAM server.
Open eis/bam/rmi link and enter Outbound connection properties as follows. Replace
connection parameters as per your installation. Hit Enter key after entering each property value.
Click on Save once youve finished.
Open eis/bam/soap and enter connection parameters as follows. Hit Enter key after entering
each property value. Click on Save once youve finished.
Note: The UserName field should contain an Oracle BAM user who is a member of application-level role
Administrator or Report Architect. weblogic user by default is an Administrator.
Change Evaluation Time to Completion. This will activate sensor after the completion of
receiveInput activity. Select Employee element for inputVariable as shown below.
From BAM Example Process Structure window, right click on Sensor Actions and Creatte > BAM
Sensor Action
Select ActivitySensor_1 for Sensor property. Choose Employee Data Object from BAM Data
Object Chooser.
Select Insert as Operation type. One other interesting operation is Upsert that stands for
Update/Insert. This operation creates an object if one does not exist or updates an existing one.
Ensure BAM Connection Factory JNDI value is eis/bam/rmi. We can specify eis/bam/soap in
case BAM and BPEL servers are separated by a Firewall.
Create a new mapping between BAM data object and BPEL input variable as shown below.
Enter Oracle1 and ORACLE for name and department respectively. Click on Test Web Service.
Open BAM Active Viewer. Click on Select Report and choose Employee Dashboard report we
saved earlier. We can see the updated graph. Experiment with different values.
Implementing Correlation:
a.) Creating Correlation Sets:
In Structure Window of the JDeveloper IDE, right click on the Correlation Sets and choose 'Create
Correlation Set'
Provide a name for your correlation set being created.
In the properties section, select 'Add' to display the property chooser window
Choose 'Create' to create a property on which the correlation has to be initiated. Provide a name and type
for the property.
b.) Associating the Correlation set on receive/invoke, pick activities
Go the the correlations tab on the activity (invoke/receive/pick) on which you need to set & validate the
correlation
Add the created correlation set to the activity
Initiate Attribute: (Value Set - yes, no)
When set to yes, correlation set is initiated with the values of the properties available in the message
being transferred
When set to no, correlation set validates the value of the property available in the message
Pattern Attribute: (Value Set - in, out, in-out)
When the value is 'in', it means that the correlation property is set/validated on the incoming message
When the value is 'out', it means that the correlation property is set/validated on the message going out of
BPEL
In case of 'in-out', the property will be set/validated on both incoming & outgoing messages
c.) Creating Property Alias:
In the Structure Window of the JDeveloper, right click on the 'Property Aliases' and select 'Create Property
Alias'
Select the message type that you want to set to the correlation property (already created)
Now, correlation design is complete. However, correlation will not be established unless we reference the
correlations on the WSDL file of the BPEL process. To do this, import the correlation WSDL file (created
under the project) in the BPEL process main WSDL.
At times you have mutiple service end points and you dont want to design your bpel based on each
service.
You can have a single invoke for all the service endpoints using dynamic bining.
</copy>
<copy>
<from variable="service_type"/>
<to variable="partnerReference"
query="/ns2:EndpointReference/ns2:ServiceName"/></copy>
5) Assign partnerReference to Partner Link
<copy>
<from variable="partnerReference" query="/ns2:EndpointReference"/>
<to partnerLink="PartnerWebS"/>
</copy>
Thats it , you can also have a general service in place just for binding at first place.
flow and some internal objects that help route logic throughout the flow).
(v)dlv_message:-Stores incoming (invocation) and callback messages upon receipt. This table only
stores the metadata for a message (for example, current state, process identifier, and receive date).
(vi)dlv_subscription:-Stores delivery subscriptions for an instance. Whenever an instance expects a
message from a partner (for example, the receive or onMessage activity) a subscription is written out for
that specific receive activity.
(vii)document_ci_ref:-Stores cube instance references to data stored in the xml_document table.
(viii)document_dlv_msg_ref:-Stores references to dlv_message documents stored in the
xml_document table.
(ix)schema_md:-Stores metadata about columns defined in the Oracle BPEL Process Manager schema
(orabpel).
(x)task:-Stores tasks created for an instance. The TaskManager process keeps its current state in this
table.
(xi)work_item:-Stores activities created by an instance. All activities in a BPEL flow have a work_item
table. This table includes the metadata for the activity (current state, label, and expiration date (used by
wait activities)).
(xii)xml_document:-Stores all large objects in the system (for example, dlv_message documents). This
table stores the data as binary large objects (BLOBs). Separating the document storage from the
metadata enables the metadata to change frequently without being impacted by the size of the
documents.
(xiii)Header_properties:-stores headers and properties information
Durable and Transient Processes:-There are two types of processes in Oracle BPEL Process Manager.
These processes impact the dehydration store database in different ways.
(i)Transient processes:- this process type does not incur any intermediate dehydration points during
process execution. If there are unhandled faults or there is system downtime during process execution,
the instances of a transient process do not leave a trace in the system. Transient processes are typically
short-lived, request-response style processes. The synchronous process you design in Oracle
JDeveloper is an example of a transient process.
(ii)Durable processes:- this process type incurs one or more dehydration points in the database during
execution because of the following activities:
* Receive activity
* OnMessage branch in a pick activity
* OnAlarm branch in a pick activity
* Wait activity
Instances of durable processes can be saved in-flight (whether they complete normally or abnormally).
These processes are typically long-living and initiated through a one-way invocation.
Properties that can effect the Dehydration Store:(i)idempotent BPEL Property:-Idempotent Activities:-An idempotent activity is an activity that can be
retried (for example, an assign activity or an invoke activity).
Oracle BPEL Server saves the instance after a nonidempotent activity.A BPEL invoke activity is by default
an idempotent activity, meaning that the BPEL process does not dehydrate instances immediately after
invoke activities. Therefore, if idempotent is set to true and Oracle BPEL Server fails right after an invoke
activity executes, Oracle BPEL Server performs the invoke again after restarting.
If idempotent is set to false, the invoke activity is dehydrated immediately after execution and recorded in
the dehydration store. If Oracle BPEL Server then fails and is restarted, the invoke activity is not repeated,
because Oracle BPEL Process Manager sees that the invoke already executed.
When idempotent is set to false, it provides better failover protection, but at the cost of some
performance, since the BPEL process accesses the dehydration store much more frequently. This setting
can be configured for each partner link property.Setting this parameter to true can significantly improve
throughput. Some examples of where this property can be set to true are read-only services (for example,
CreditRatingService) or local EJB/WSIF invocations that share the instance's transaction.
(ii)BPEL Properties Set Inside a Composite:ex:<property name="bpel.config.inMemoryOptimization">true</property>
<property name="bpel.config.completionPersistPolicy">faulted</property>
(a)inMemoryOptimization:-This property indicates to Oracle BPEL Server that this process is a transient
process and dehydration of the instance is not required. When set to True, the completionPersistPolicy is
used to determine persistence behavior. This property can only be set to True for transient processes or
processes that do not contain any dehydration points such as receive, wait, onMessage and onAlarm
activities. The inMemoryOptimization property is set at the BPEL component level.
Values:
This property has the following values:
False (default): instances are persisted completely and recorded in the dehydration store database.
True: The completionPersist policy is used to determine persistence behavior.
(b)completionPersistPolicy:This property configures how the instance data is saved. It can only be set at the BPEL component level.
The completionPersistPolicy property can only be used when inMemoryOptimization is set to be True
(transient processes). Note that this parameter may affect database growth and throughput (due to
reduced I/O).
Value
(i)On (default):-The completed instance is saved normally
(ii)Deferred:-The completed instance is saved, but with a different thread and in another transaction.
(iii)Faulted:-Only the faulted instances are saved.
(iv)Off:-No instances of this process are saved.