Create a DB connection for SOA Suite with Fusion Middleware Control 12c

For using a database from a SOA composite, a database connection is required. The configuration has remained the same through the 11g lifetime, but the configuration tools have changed with Fusion Middleware Control 12c in SOA Suite 12.2. This tutorial guides through the creation of a database connection in 12.2.

This is, for example, how your Database Adapter configuration might look like. In the top half is the connection information for the JDeveloper IDE. But after deployment, the Composite will not connect directly via the JDBC connect string, but via the database connection identified by the JNDI name below (here: eis/DB/soadb). That connection needs to be created on the server, or the composite will not deploy.

To create it, we need a JDBC Data Source first. To create it, in FMW Control browse to JDBC Data Sources

Choose Create|Generic Data Source

On the first page of the Wizard, click Select... and chose the Thin XA driver for Service connections.

Give it a name (SOAe2e Data Source) and a JNDI Name (jdbc/soae2eds), then click Next.

Click on 'Generate URL and Properties' and enter your database connection information

Click Test Database Connection. If that fails, check your parameters

In the list of JDBC Data Sources, click on the newly created DS.

On the targets tab, check your SOA server and save.

Now that we have a JDBC connection, we need a DB connection. Click on WebLogic Domain|Deployments

Check Show All and click on the DbAdapter.

In Modules and Components, click on DbAdapter.rar.

Here you will learn, that the DB-Adapter configuration hasn't been ported to FMW Control yet. So click on the link to get directed to good old WLS Console.

Navigate to Deployments|Configuration|Outbound Connection Pools and click on New.

Choose java.resource.cci.ConnectionFactory and click Next.

 Accept the Deployment Plan and click OK.

Give it a name. This must exactly be the same as in JDeveloper, or it will not be found at deployment time.

Back in the list, click on the new Connection Pool to configure it.

For the XADataSourceName enter the JNDI name of the JDBC connection created above. Press RETURN before clicking on Save.

 You should get the confirmation shown above.

Back in FMW Control, the new DB adapter should be visible in the JNDI Browser. If it is not, try restarting the DB Adapter or the domain.

Having the DB connection set up properly, the deployment should work.

Oracle Managed File Transfer (MFT) Handson - Part 4: Integration with SOA Suite

[Part 1] [Part 2] [Part 3] [Part 4] 

For users of both, MFT and SOA-Suite, both can be integrated. The SOA Suite can push data to MFT, which takes care of distributing those in the file system. And vice versa, the SOA Suite can be a target for a MFT transaction.
For this example, both MFT and SOA Suite should be installed. Basic knowledge of both products is required.

Starting with the Design tab of the MFT Console. A new source of type SOA is created here. Important: don't chose the name soa as depicted above, as this will lead to problems later. So chose a different name like service-source.

Next, a Transfer needs to be created, using the newly created service-source as Source. Create any File Target as target for this transformation, eg. the file-target from chapter 3.
Then click Save and Deploy, so both artifacts are deployed.

Next, open JDeveloper and create a new SOA-Project.

In the composite, drop a MFT adapter to the right side.

Accept the defaults

Also keep the defaults here

In this step, an existing application server connection can be chosen or a new one be created. The MFT server in that domain will be found automatically, click on Test MFT to check the connection.

The serivce-source will be found automaticall, end this wizard with Finish.

To have something to communicate with the MFT adapter, drop a BPEL process into the composite. In the dialog shown above, switch it to Synchronous BPEL Process and leave the rest.

Connect the MFT adapter with the BPEL process, then open the process with a double click.

Place an Invoke activity in the middle and connect it with the MFT partner link.

Create an input- and output-variable by clicking on each green plus sign (+). Then close the dialog with OK.

An assign activity is needed, place it before the Invoke1 and open it via double click.

Right click on ns1:InlinePayload to assign an expression.

Create a greeting, eg. one matching the region you live in. In my case:
concat("Moin, Moin ", $inputVariable.payload/client:input)

Do the same for ns1:TargetFilename. As this is the name for the target file, better avoid special characters which could cause troubles on some file systems. Eg.:
concat("Hello-",$inputVariable.payload/client:input)

The composite is ready now and need to be deployed (right click on [project name]|Deploy).
Next, open the Enterprise Manager and navigate to that project. Go to the Test Web Service page, enter a test string and start the test.

If everything was OK, the Flow Trace can be launched.

The flow trace will contain a MFT step, click on it.

This will lead to the MFT Console where the Transfer will be displayed.

In the file system, the resulting will be created. Open it and check the contents.

That's the end of the MFT tutorial

[Part 1] [Part 2] [Part 3] [Teil 4]

SOA-Suite 12c: configure inbound REST adapter

Since release 12c, the Oracle SOA Suite comes with an adapter for REST-Services. This tutorial shows how to configure an inbound REST Adapter for XML and JSON Payload.

Start with a new SOA Application, choose 'Empty Composite'.

Create a new REST adapter on the left side of the composite at the Exposed Services.

A Resource Path could be defined, this simple example work without one. At least one HTTP operation needs to be bound by clicking the green plus sign (+) under 'Operation Bindings'. The last two entries are presets for easier setup, but leaving out some options. So we start with 'Add operations binding'

Check JSON and XML as payload and POST for the HTTP Verb. For defining the XML-Schema, click the cog reading 'Define Schema for Native Format'.

Click through the Native Format Builder with 'Next' ...

... and 'Next' ... 

... und 'Next' ... 

... until the page, where a sample JSON file could  be uploaded via the 'Browse' button. If no file is available, just enter the desired JSON Data in the Sample text field, for example 

{

"Event" : "asdf",

"Payload" : "dfgh"

}

and click next.

The JDeveloper comes back with a ready-to-use Schema, which will be used later. Click through the wizard with 'Next' and 'Finish'

For the Response tab, also choose XML and JSON for Payload. This isn't necessary for a POST operation, but useful for testing. Select the newly created XML Schema by clicking on the magnifier icon next to 'Schema URL'. Close both dialogs with 'OK'.

The REST service is now completed. Next a BPEL process is needed, e.g. by right mouse button and choosing Insert|BPEL Process.

Change the template to 'Synchronous BPEL Process' and uncheck 'Expose as a SOAP service'. Leave the rest and finish with 'OK'.

The interface of the BPEL process does not fit to our REST service and needs to be removed. Click the symbol of the inbound interface so that the surrounding circles is represented by a dotted line. Press the 'DELETE' key on your keyboard and answer both questions with 'YES'.

Now the RestService can be wired to the BPEL process. Click 'OK' when asked for a transaction. 

Open the BPEL Process. The input and output variables for the old interface are still there. They need to be removed by clicking on the variables button (x), mark both and click on delete.

Switch to source view. The old WSDL is still imported, so the line reading <import ui:processWSDL... needs to be deleted.

The old interface is deleted, so the receiveInput can now be wired to the RestService.

Change the Port Type to the new RestService_ptt.

A new input variable is needed. Click on 'Auto-Create Variable and in the 'Create Variable' dialog just click 'OK'. 

Wire the replyOutput also to the RestService and repeat the steps above.

To let the process do at least anything, create a file adapter to write down the messages.

Click through the wizard. Choose 'Write File' for Operation Type. Check 'Add Output Header' for more verbose output.

Choose an output directory, then a filename template and append a sequence (%SEQ%).

Select the Root-Element of the above created Schema.

Click through the wizard to the end.

Now put an Invoke activity right behind receiveInput and wire it to fileOutput.

Create a new input and output variable via the green plus (+) and close the dialog.

Put an assign activity in front of the Invoke1 activity.

Open the assign activity and map the Root-Element of receiveInput...InputVariable to Invoke1_Write_InputVariable.

For the return, place another assign activity between Invoke1 and ReplyOutput and create the mapping accordingly for Invoke1_Write_OutputVariable.

That's it, die example is ready to run. Deploy it to a SOA Suite instance of your choice and open

FMW Control.

In FMW Control, select the project, click the test button and choose the RestService.

Change both Media Types to application/json. Switch to Raw View, enter your request and test the service.

If nothing went wrong, the event should be logged to the file and the response gives back the folder and the filename.

At the deployment, the SOA Suite automatically creates an according WADL. This could be copied from the service test page for testing the service in JDeveloper.

Open the HTTP Analyzer via Tools|HTTP Analyzer and click on the 'Open URL...' icon.

Paste the copied WADL-URL and hit RETURN.

When JDeveloper parsed the WADL, the test client can be called via the 'Test' button.

The test form seems to have still some problems with JSON. So switch the Content-Type to application/xml and test it via 'Send Request'. Becase the returning data is now 'fileName' and 'directory', instead of expected 'Event' and 'Payload', the JDev cannot parse the returning data. But for a clean solution, this example would have become even longer.

Instead, simply switch to Raw Message view to see that the expected data is returned.

As this simple example shows, the REST/JSON-support in JDeveloper and SOA Suite is definitively ready to use.