Creating a Simple BPEL Process : HelloWorld BPEL

Business Process Execution Language(BPEL) is an execution language for defining business processes. In short, it is the language for orchestrating multiple WebServices based on the business logic.

This post is about creating your first BPEL process using Oracle SOA Suite 11g

This is a simple BPEL process that gives back fullName as response, inputs being firstName & lastName

Defining your first BPEL Process

Create a new Project, name it HelloWorldBPELPrj and select Empty Composite in the next screen'

 

Define a Schema as follows

 

In the composite file, drag and drop BPEL Process component from the Component Palette into the Components swimlane of the composite.xml

This will open up a wizard where you need to give the following details

Name : HelloWorldBPEL

Template : Syncrhonous BPEL Process

Select Input and Output from the schema just created

Select the checkbox "Expose as a SOAP WebService" so that it creates a WebService with the same message types in the External References section of the composite.xml, though which external clients talk to this BPEL process

 

This will create the following in the composite.xml

 

Now that you've created the skeleton, lets implement the BPEL process.

Either open the .bpel file from the Navigator or double click the BPEL process icon in the coposite.xml - this will take you to the BPEL Component Editor where you'll implement the business logic in the BPEL process

When you look at the empty BPEL process, you'll find an incoming line from the external WS to Receive Activity, and an outgoing line from Reply Activity to the same external WS. These lines represent the flow of message to and from the WS to the BPEL Process

Note : Every operation in a BPEL process is called an Activity

Click on the "X" symbol in the boundary enclosing both the activities. The boundary is called a Scope in BPEL, which is similar to Scope in any programming language

This will open up variables section, where you'll see 2 variables (inputVariable and outputVariable). The inputVariable contains the the value coming into the BPEL process from the external WS.

In this example, inputVariable contains just a simple string, name

We need to concatenate this with 'Hello ' and assign it to the output variable. This can be done using Assign activity

Drag and drop Assign activity in between the two activities, name it AssignOutput

 

Here, we need to concatenate both the elements from the input and assign it to the output. For this, click on the Expression icon at the top right as shown

Use the concat() function from the String functions and append Hello to the name from the inputVariable, as shown

 

This will create a function icon in the middle of the Assing editor, where you need to drag this to assign it to the returnMsg of the outputVariable and click OK

With this, the outputVariable is stuffed which is sent back to the calling WS(indicated the outgoing line)

Thats it, you are done with your first BPEL process

Deploy the project as per this link and test it in Enterprise Manager

Hope this tutorial gave you a basic understanding on working with a BPEL process.

Thanks for going through my post, feel free to provide a feedback!

Deploying artifacts to MDS

Its quite often that certian artifacts like schemas, transformation files, wsdl's, etc. are used across projects. In such cases, it is not a good idea to create them in each and every project, rather such artifacts are to be shared across projects. That way, all the projects will be using the same resource without problems like duplication, out-of-sync, rework during changes to the artifacts, etc.

Oracle SOA Suite 11g provides such feature of maintaining artifacts at shared locations. Such a location is called MetaData Store(MDS).

MDS in Oracle SOA Suite 11g come in 2 flavours

• File Based : Used in development phase, easy to configure/maintain
• DB Based : Used in production environments, ideal way of sharing resources

In this article, I'll explain you how to deploy shared artifacts to MDS, so that you dont have to  duplicate the resources across projects.

Deploying artifacts to MDS involve 3 steps in total

1.  Create a deployment profile, select all the artifacts to be shared. In otherwords, select all the artifacts that you want to publish to MDS.
2. Create an Application level deployment profile of type SOA-Bundle, selecting all the profiles that you've created in step1
3. Deploy the SOA-Bundle to the SOA server

Will update this post soon with the screenshots
Thanks for going through my post, feel free to provide a feedback!

Entity Variables - Connected Variables

This blog discusses about a new kind of variables in Oracle SOA Suite 11g called Entity Variables

There are 2 kinds of variables in general
XML DOM based Variables & Entity Variables

DOM based Variables
These are XML variables that adhere to a Schema.
XML Schema defines the structure of the variable.
These are disconnected variables, meaning once the variable value is fetched, it is stored in-memory, and is stored  during dehydration. After rehydration / variable being fetched, the same value gets retrieved, irrespective of whether that variable has changed in the database during this course of tim.
All the variables that we've been using in all the samples are disconnected variables.
The problem with these kind of variables is that sometimes, these may represent stale data.

For example, lets say varX is retrieved from a database table EMPLOYEES, and after that, assume an asynchronous service has been invoked. This service, say takes an hour to respond back. During this time, the entire state information is saved to the SOA datastore(dehydration). Once the async service responds back, all the state information is retrieved from the datastore
Lets assume that the actual data in the EMPLOYEES table has been changed during this 1 hr. But this change dont reflect in the variable because it has been fetched and stored in varX an hr back
Thus, varX now represent stale data, making varX a disconnected payload

The solution to these kind of scenarios is to have a connected variable, where during dehydration, only the reference is stored but not the actual data

Entity Variable
Entity Variable in Oracle SOA Suite 11g is a connected variable, which represents the latest data, always
This is connected in the sense that only the reference to the actual data is stored to the datastore during dehydration, and while rehydration, that reference is evaluated to the actual value, thus making the variable hold the current data always

Entity variables also support SDO-formed data. However, unlike the DOM variables, the entity variable with SDO-based data enables you to bind a unique key value to data (for example, the unique id). Only the key is stored in the dehydration store, the data requiring conversion is stored with the service of the

Oracle ADF Business Component application.

Oracle ADF BC component ApplicationModule lets us create SDO variables very easily. This is explained in the blog Creating an SDO out of ADF BC

Once the SDO is created, you can make use of the BPEL Process Editor to create Entity Variables by linking it to an SDO provider

This part is covered in the blog Data Access using SDO based Entity Variables

Hope this gives you an idea on the Entity Variables
Thanks for going through my post, feel free to provide a feedback!

Service Data Object (SDO)

This blog talks about a technology that acts as a data provider service - Service Data Object - Which provides a framework as well as an API
This blog talks about SDO's in SOA context. For a complete info on SDO, you may just google!

Service Data Object(SDO) is a technology that allows data from heterogenous systems/technologies to be accessed in a uniform way.

SDO's lets the underlying data layer to be accessed in a technology-agnostic manner

SDO is a J2EE data programming model which takes care of dealing with various technologies associated with the underlying data layer, and provides the developer to focus more on the business logic

SDO's abstracts data in a Service Oriented Architecture(SOA) 

With SDO, you do not need to be familiar with a technology-specific API in order to access and utilize data. 

 You need to know only one API, the SDO API, which lets you work with data from multiple data source which includes relational databases, entity EJB components, XML, Web services, JCA, JSP, etc.

Normally, most of the data is manipulated by using XPath functions. But you can even specify BPEL data operations to be performed by an underlying data provider through use of entity variable

The data provider service performs the data operations in a data store behind the scenes and without use of other datastore related features provided by SOA Suite like the database adapter

This feature enhances performance and incorporates native features of the underlying data provider service during compilation and runtime

SDO or Service Data Objects is designed to simplify and unify the way in which applications handle data.
Oracle made it very easy with its Application Development Framework - Business Components(ADF BC) layer to make sdo webservices. You only have to edit the application module, Go the service definitions link and enable support for service definitions. Select the viewobjects and the operations you want to use. Deploy this to the Application Server and we have SDO WebService.

 Working with a data provider service can overcome the following problems

1. Extensive data conversion

IF the underlying data cannot be represented as XML, then the data have to be converted to XML format before working with SOA components. This feature affects the performance as if the data is too huge, it would take time during this conversion

2. Variables in BPEL are disconnected, in the sense that it contains a snapshot of the data. So, not always a data represents the current data, but stale data.

 

In prev releases, any access to the datastore is done using the database adapter. And this data is stored to the dehydration store when the instance is dehydrated, thus duplicating the data. And if there was any change in the database meanwhile, we do not have the latest one, rather the one stored in the dehydration store which is now stale. And, data is in DOM form.

This is overcome in the current release where when we use the Entity Variable to fetch the data, while dehydration, the data is not stored but rather the key(done by using the bindEntity activity) to it is persisted(like a pointer). So, when this data is required after rehydration, current data is fetched using that key

This way of doing things aviods duplication as well as always you are made sure of having the latest data. Data in EV is in SDO form, which provides for a simpler conversion compared to DOM, especially when the data provider service understands SDO forms. Basically in this case, data is maintained outside the BPEL process(in this case, in an Oracle ADF BC component). Just a reference key is maintained in the BPEL process to deal with the data.

Only BPEL service components can understand SDO forms in the current release. If you wire a SDO provider service to a mediator, the data form defaults to DOM.

Hope this gave you a basic understanding of SDO. The next step is to know about EnityVariables in Oracle SOA Suite 11g, after which we would be working with SDO's in BPEL

Thanks for going through my post, feel free to provide a feedback!

Creating a SDO based on ADF Business Component

SDO's provide a way to access the underlying data layer in an implementation agnostic manner

Oracle's Application Development Framework(ADF) gives a way to create an SDO based on its Business Component in a very easy manner

This tutorial shows you how to create an SDO out of ADF BC

This tutorial requires a basic understanding of ADF BC

In this, we'll create a SDO for accessing a custom table in hr schema

First create an Generic Project, name it ADFBussCompForSDO

 

Rt click on the project --> new --> ADF Business Components --> Business Components from Tables

 

In the next screen, create a connection to the database, test it

 

Now, the Create Business Components from Tables wizard opens up where you'll create Entity Object, View Object, Application Module

 

No Read-Only VO's in this case, so just press next

 

Press next and finish

This step will create all the three business components of ADF

Now, open the AppModule, go to Service Interface tab --> click on "+"

Click next to go to Service View Instances

Shuttle EmployeesVO1 to the right. When you do this, multiple methods will show up at the bottom, where you need to select the methods that you want to expose

Select all the methods, meaning you want to expose all the operations to the external clients through a WebService

 

Click on finish. This will generate a set of files which would expose operations on the underlying table as WebService operations. You can see the .wsdl file generated under the serviceinterface folder

Next, create a deployment profile for this project. Please note that this is not mandatory, this is just to check the WebService endpoint.

Rt click on the project --> properties --> deployment --> New --> select archive type as Business Components Service Interface

 

Deploy the project

Application(Menu option) --> deploy --> <currentProject_profileName>

 

(Since this is an ADF/Web prj, this needs to be done from the Application level unlike the SOA composites where we do it from the prj rt click)

After the deployment, url for the same can be found in the wsdl file generated earlier. You need to modify the portnumber in the url to point to the one you have deployed this to.

Thats it! You're done with creating an SDO that can be used to work to the underlying db layer

Hope this gave you a clear picture on creating the SDO using ADF-BC
Thanks for going through my post, feel free to provide a feedback!

Importing a SOA Composite into JDev

 

This tutorial shows you how to import an existing project into your workspace

Before anything, you need to have the project/jar file of the composite in your local directory

Open Jdev, File --> Import --> SOA Archive into SOA Project

Provide an appropriate project name

Import the jar file and finish

This will import all the project resources from the jar file into your current project

You may now update the project to incorporate your new changes, or just deploy it to test


Thanks for going through my post, feel free to provide a feedback!

Deploying a SOA composite - Using JDeveloper

This tutorial shows how to deploy a SOA Composite using JDev

This tutorial assumes you've already built a SOA composite

Before anything, create a an Application Server Connection as explained in this blog 
Rt click on the project --> deploy

 

  Select the server that you've created in the resource palette

 

This step will list out all the Managed Servers configured in the domain.

Select the partition. Partitions are explained in this blog

 

This process will first generate a jar file of the composite and place it under <projectWorkingDirectory>/deploy, and deploy the same to the selected Managed Server

Note : You can get the prj working directory from Edit --> Copy Path

Thanks for going through my post, feel free to provide a feedback!

One time setup to create SOA Server Connection

Setting up Application Server Connection

Create an application server connection to the Admin Server in your SOA Doamin so that you can deploy directly to any of the soa managed servers residing in that domain

Follow the steps given below to setup an application server connection

Resource Pallette --> New Folder icon at the top --> New Connection --> Application Server

 

Provide Admin Server details

Provide Admin Server credentials

Provide Admin Server details and domain name of the SOA Environment used

 

Test and Finish

Going forward, you'll use this connection name during deployments through Jdev

Working with a Mediator : Echo Pattern

This blog shows you how to work with a Mediator component in Oracle SOA Suite 11g.

This example uses the Echo pattern of the Mediator. An Echo is a simple "reply to the caller" pattern where the requestor immediately gets back a response.

This is typically used in use cases where a certain message has to be enriched, or some filtering to be done, etc.

Creating a Mediator

Create a new SOA Project, name it MediatorEchoPattern, select empty template

  

Defining the Schema

To begin with, define the message structures that will be used in the example.

In this tutorial, we will send in a message {firstName, lastName} and get back {fullName}. Based on this, define the xsd file

Rt click on xsd folder --> new --> All technologies --> xml schema --> name it EchoPatternSchema

 

 

Define the schema as shown below

Creating the Mediator

Open composite.xml, drag and drop the Mediator component from the component palette to the components swimlane of the composite.xml

Name it EchoMediator, template as Define Interface Later. This interface will be created when we create a WebService and wire it to this, later.

 

This step creates an empty mediator.

Create a service endpoint

Mediator exists in the Components swimlane which is not directly exposed to the external world. In order to access it, we need to create a service endpoint through which external clients can access this component.

Here, we create a WebService with request and response types as defined in the schema earlier

To create a WebService, drag and drop the Web Service from the component palette to the Exposed Services swimlane of the composite.xml

Name it EchoMediatorClient

In the WSDL url, select the second option Generate WSDL from Schema.

This will open a WSDL generation wizard where we need to select the Interface type and the message types for input and output. Select them as shown below

 

This will create a WebService in the composite.xml

Now, wire the Webservice to the mediator as shown

 

Creating the Echo Pattern

Now that the wiring is done, the only thing remaining is to define the message flow

In this example which is an echo pattern, the request comes from the WebService, goes to the mediator, undergoes some transformation in the mediator, and finally is routed back to the WebService.

Hence, we need to create a routing rule in the mediator with an Echo Pattern

Double click on the mediator component in the composite.xml which will open a .mplan file which is the heart of the mediator component where all the operations of the mediator as defined in the other blog are to be defined.

For this tutorial which is more like a HelloWorld example, just a transformation file would be sufficient.

Click on the + icon of the Routing Rules --> Static Routing Rule --> Echo

This will add a Routing rule section in the file.

Here, we add a transformation file to transform the input message to the output message. Transformation file is mandatory for any type of mediator as that is the link that connects the input to the output within the mediator.

Click on the button at the end of the Transform Using, create a new mapper file and accept the default name

 

This will open up a new wizard, where we can do all the transformations.

In this example, we need to concatenate the firstName & lastName, append hello to it, and assign it to the output

Concat function is available in the component palette at the right when you open the transformation file. Drag and drop this function to the middle section of the wizard,

then drag a line from each of the inputs to it, then double click on the concat function to add hello, and finally map it to the fullName at the right, as shown below

 

Thats it, you're done!

Deploy this project. How to deploy is mentioned in this blog

EM URL : http://<host>:<adminPort>/em

Select the project under SOA-->soa_infra, click on test

Hope this tutorial helped you introduce working with a Mediator component in Oracle SOA Suite 11g

You can download the entire example(jar) from this location

Thanks for going through my post, feel free to provide a feedback!