Tutorial

Getting Started with Oracle SOA Suite Development

ShannyAnoep
oracle-logo-1

C2B2’s Shanny Anoep shows us how to get going with Oracle’s integration service software, SOA Suite.

C2B2’s Shanny Anoep
shows us how to get going with Oracle’s integration service
software, SOA Suite.

Introduction

Oracle SOA Suite allows
you to build integration services to connect different types of
systems: File-based, Database, SOAP Services etc. 

You can build these services as an SCA Composite with Oracle
JDeveloper using the Mediator, BPEL processes, Business Rule and
Spring components of the SOA Suite. 

The completed SCA composite can then be deployed to a SOA Suite
environment to start processing.

In this tutorial we will use JDeveloper to build a simple
integration service that will poll a directory for incoming XML
files, delete the files and write the files to another location,
using the Mediator component.

Prerequisites

In order to complete this tutorial, you’ll need to have the
following software installed:

- JDK 6u21 / 7u10 or higherAfter installing the JDK, make sure
so set the JAVA_HOME environment variable to the install
location.

-
Oracle JDeveloper  Studio Edition
 11.1.1.17
 (Note: the latest version is JDeveloper
12c, but this version does not support SOA Suite development
yet.)

-  SOA Extension for JDeveloper 11.1.1.7.0 After installing
JDeveloper, you can install the SOA Suite extension by opening
JDeveloper and navigating the menu bar to Help > Check for
Updates to install “Oracle SOA Composite Editor”.

Creating the JDeveloper SOA Composite Project

The first step is to create a new JDeveloper Application that
will contain a new SOA Composite project.

1. Open JDeveloper with the Default Role

2. Use File > New to open the New Gallery and select the “SOA
Application”

You can name the Application however you want, it will serve as
a container for the JDeveloper projects that contain the actual
code. If the “SOA Application” is not present, you need to install
the SOA Extension first.

3. After naming the Application, you’re asked to name your
project; we’ll choose “FileProcessor”. Here you can see “SOA” is
already selected, so the SOA libraries will be available and a
composite.xml will be generated on completion of the wizard.

4. In the “Project SOA Settings” screen, you’re asked what the
Composite should contain. Choose the “Composite with Mediator”
option. The Mediator is the simplest component listed here and is
typically used to validate, transform and route requests between
components in the SOA Suite.

5. After creating the project, the first screen showed is the
“Create Mediator” screen. Name it “FileMover” and keep the template
on “Define Interface Later”.

You’ll now have a SOA Suite project opened, with a composite.xml
that defines the entire application and the .mplan file that
contains the Mediator’s configuration.

Creating the File Adapter

6. Open the composite.xml from the Application Navigate
screen.

If you open the composite.xml file,
you’ll see that the Mediator is the only component present. There
is nothing that puts messages through the Mediator and there is no
output. Let’s add File Adapters to poll for files, pass them
through the Mediator and send them off again.

7. Drag the FileAdapter from the
Component Palette to the Exposed Service swim lane in the Composite
design screen.

8. The File Adapter Configuration Wizard is opened. Name it
“FilePoller” and choose the following options in the wizard:

Step 3: “Define from
operation and schema (specified later)” in the next step.

Step 4: Choose “Read
File” as the operation, since we are going to poll for files on the
file system.

Step 5: Directory =
 c:incoming  (or any other directory that exists)

Step 6: Enter “*.xml”
as the wildcard, so that we only pickup .xml files.  

Step 7: Keep the
Polling Frequency options on default.

Step 8: Check the box
for “Native format translation is not required”.

In this case, we’re not interested in
manipulating the contents, so we can check this box. Typically, you
would select a XML Schema that applies to the incoming files, so
the XML content can be validated or transformed later on. Another
option is to build a Native Format schema, which will translate
content in plain text to XML elements.

9. Create another FileAdapter, but this time drag it to the
“Exposed Services” swim lane. This FileAdapter will write the
files. Choose the following options in the Wizard:

Step 2: Service Name
= FileWriter

Step 3: Interface =
Define from Operation and schema (specified later)

Step 4: Choose Write
File

Step 5: Directory =
 c:outgoing  (or any
other directory than the incoming)

File Naming Convention:
 outbound_%SEQ%.xml

Step 6: Check the box
for “Native format translation is not required”.

Wiring the File adapters and the
Mediator  

In the Composite design screen, you’ll
now see three components: the incoming FileAdapter, the Mediator
and the outbound FileAdapter. In order for messages to flow from
left to right, we need to wire the components.  

10.
Drag the arrow from FilePoller to the left arrow of the Mediator
component.  

By
connecting the arrows, every file that is picked up by the
FilePoller will now be sent to the Mediator as a request. From the
Mediator we can then route the request to other components, for
example BPEL, or to external system through one of the Exposed
References.

11.
Drag the right arrow from the Mediator component to the arrow on
the FileWriter.

The flow of your integration service
is now completed. The FilePoller will poll the directory every
minute, once an .xml file is detected, it will send it to the
Mediator which will route it to the FileWriter. The file will be
deleted in the polling directory and written to the outgoing
directory.

Building the deployment artefact

In order to test the service, the
Composite needs to be deployed to a running SOA Suite environment.
You can either build a deployment artefact – a JAR file – or make
an Application Server Connection in JDeveloper and deploy through
that. We’ll build a SAR file, so you can deploy it through the
Fusion Middleware Control web interface onto a SOA Suite
environment.

12. Right-click the Project in the
Application Navigator. Select Deploy to open the Deployment
Wizard.

13. Choose Deploy to SAR file and
leave the options to their default selection in the next steps.

14. After the deployment wizard is
finished, JDeveloper will start building the deployable JAR file.
In the Deployment Log screen you will see this message:

 

[01:13:20 PM] Wrote Archive Module to C:JDevelopermyworkSOASuiteAppFileProcessordeploysca_FileProcessor_rev1.0.jar

 

Testing the application

By deploying the JAR file through the
Fusion Middleware Control web interface it will start polling
directly and moving files straight away.

15. Open the Fusion Middleware Control
web interface for your running SOA Suite environment. The default
URL is: http://<hostname>:7001/em

16. Navigate to the soa-infra screen,
where the dropdown menu “SOA Infrastructure” is located.

17. Choose “Deploy” and select the
created JAR file from the file selection dialog. Everything else
can be kept at the default options.

Once it is deployed, create a new .xml
file in the directory that you specified in the FilePoller. Once
the FilePoller has detected it, you will see a new Composite
instance in the FMW screen  and you can check the output
directory to see whether it worked. 

Tip: the directory locations and the
polling frequency can be changed by going to the Properties screen
of the FileAdapters in the Fusion Middleware Control screen.

Source Code

The full code for this tutorial can be
found at C2B2’s
GitHub

Next Steps

As a next step I would suggest trying
out manipulating XML messages by defining schemas and playing with
the validation and transformation features of the Mediator.

After that I would recommend looking
into the other components such as BPEL and Business Rules to
implement more complex integration services. Also check out the
various adapters in the Component Palette to connect to FTP
servers, Databases, Web Services, etc.

Author Bio
Shanny Anoep is a Senior Middleware Consultant at C2B2
Consulting. Shanny has extensive knowledge on Oracle Fusion
Middleware and Java/JEE technology, with experience as a technical
consultant and in-house developer for large organizations in the
financial, utilities, telecom and internet industry across the
Netherlands, the United Kingdom and Singapore.

Author
ShannyAnoep
Shanny Anoep is a Senior Middleware Consultant at C2B2 Consulting. Shanny has extensive knowledge on Oracle Fusion Middleware and Java/JEE technology, with experience as a technical consultant and in-house developer for large organizations in the financial, utilities, telecom and internet industry across the Netherlands, the United Kingdom and Singapore.
Comments
comments powered by Disqus