SOA Suite 12c in Docker containers. Only a couple of commands, no installers, no third party scripts

For developers, installing a full blown local SOA Suite environment has never been a favorite (except for a select few). It is time consuming and requires you to download and run various installers after each other. If you want to start clean and haven't done your installation inside a VM and created a snapshot, you can start all over again.

There is a new and easy way to get a SOA Suite environment up and running without downloading any installers in only a couple of commands without depending on scripts provided by any party other than Oracle. The resulting environment is an Oracle Enterprise Edition database, an Admin Server and a Managed Server. All of them running in separate Docker containers with ports exposed to the host. The 3 containers can run together within an 8Gb VM.

The documentation Oracle provides in its Container Registry for the SOA Suite images, should be used as base, but since you will encounter some errors if you follow it, you can use this blog post to help you solve them quickly.

Quick overview of SOA Suite 12.2.1 new features

Oracle has just released SOA Suite 12.2.1 which contains several exciting new features. The below entries have shamelessly copied from the developers guide in order to provide a quick overview of highlights for this release of the SOA Suite. Also at the end of the article some links for new features of WebLogic Server 12.2.1 which has also been released.

Patching running instances

See Patching Running Instances of a SOA Composite.

Oracle SOA Suite 12c (12.2.1) supports Composite Instance Patching, which enables you to patch running instances of a composite and recover faulted instances after patching the runtime. You can only include those fixes in the patch that are compatible with Composite Instance Patching. Use the SOA Patch Developer role in Oracle JDeveloper to make the fixes and create the patch.

Composite Instance Patching enables you to deliver urgent composite fixes that can be picked up by long running instances. You can make compatible/allowed changes without aborting in-flight instances. If a patched running instance comes across a business process that has been fixed by the patch, say a BPEL transformation, then it picks up the fixes applied to the business process.

When designing the patch, the SOA Patch Developer mode in JDeveloper automatically disables changes that cannot be made to the patch. Some of the compatible changes that you can make include:

Non-schema related XSLT changes, changes to fault policy, sensor data, and analytics data.
Compatible BPEL changes such as transformation activity, assign operations, etc.
JCA Adapter configuration properties.

In-Memory SOA

See Using In-Memory SOA to Improve System Performance.

You can leverage the Coherence cache associated with WebLogic Server to run your non-transactional business processes in memory. This improves performance and scalability for these business processes, as read and write operations are performed out of the cache. Database performance and management also improves, as the costs associated with continuous disk reads and writes are significantly reduced.

In-memory SOA enables short-running processes to live in memory. The process state gets written to the database only when faulted, or at regular, deferred intervals using a write-behind thread. The BPEL state information is dehydrated and rehydrated to/from the Coherence cache.

Support for debugging XSLT maps

See Debugging the XSLT Map.

Starting in 12.2.1, you can debug your XSLT maps using the SOA Debugger. You can add breakpoints at strategic locations in the XSLT map. When debugging, the debugger halts execution at the breakpoints, enabling you to verify the data and output.

XSLT maps can be complex, making them difficult to debug. For example, you may have a Java function, or other functionality, that is best tested in the application server. Also, you might find it easier to debug in the application environment, as the XSLT may be invoked from many different applications in the server. The SOA debugger provides remote debugging capability for XSLT maps that have been deployed in the application server.

You can also use the debugger with your Oracle Service Bus projects.

Support for End-to-End JSON and JavaScript

See Integrating REST Operations in SOA Composite Applications.

Starting in 12.2.1, your SOA composites can use end-to-end JSON. This means that the REST service can receive the REST request and route it to the BPEL engine without translating it to XML. The BPEL component can use the JavaScript action, and also use JavaScript in conditional and iterative constructs, to work on JSON objects directly. The REST reference can receive the REST message from the BPEL engine and route it to an external REST endpoint without translation.

The REST interfaces and BPEL component support end-to-end JSON. However, if you are using other service components, like the Mediator, you need to use the 12.1.3–style composite that internally maps REST resources and verbs to WSDL operations and XML schemas, and translates the incoming payload into XML.

Running on WebLogic Server 12.2.1

Of course SOA Suite 12.2.1 runs on WebLogic Server 12.2.1 which also has several Interesting new features. See here.

• Multi-tenancy support
• Java EE 7 Support
• JDK 8 Certification
• Docker Certification

Among several other interesting things. Interesting to read the WebLogic full client is being deprecated.

SOA Suite 12c: Best practices for project structure and deployment

Efficient usage of version control has specific requirements to allow identification of versions and synchronous development on different branches. Design time you will want to have your Service Bus projects in a single application in order to allow usage of shared objects. At deploy-time or when creating a release, you want to group SCA composites together with Service Bus projects. How do you combine these different requirements?

In this article I'll describe several practices and considerations which can help you structuring your version control and artifact repository. The main challenge is finding a workable balance between the amount/complexity your deployment scripts and developer productivity / focus on business value. A lot of scripts (large investment) can make it easy for developers on the short term, however those scripts can easily become a burden.

If you are just looking for some good practices to structure your version control and artifact repository, look at the list below. If however you want to know why I think certain things are good and bad practice, read on.

SOA Suite 12c: Collect & Deploy SCA composites & Service Bus artifacts using Maven

An artifact repository has many benefits for collaboration and governance of artifacts. In this blog post I will illustrate how you can fetch SCA composites and Service Bus artifacts from an artifact repository and deploy them. The purpose of this exercise is to show that you do not need loads of custom scripts to do these simple tasks. Why re-invent a wheel when Oracle already provides it?

This example has been created for SOA Suite 12.1.3. This will not work as-is for 11g and earlier since they lack Maven support for SOA Suite artifacts. In order to start using Maven to do command-line deployments, you need to have some Oracle artifacts in your repository. See http://biemond.blogspot.nl/2014/06/maven-support-for-1213-service-bus-soa.html on how to put them there. I have used two test projects which were already in the repository. A SCA composite called HelloWorld_1.0 and a Service Bus project also called HelloWorld_1.0. In my example, the SCA composite is in the GroupId nl.amis.smeetsm.composite and the Service Bus project is in the GroupId nl.amis.smeetsm.servicebus.

Searching Oracle Service Bus Pipeline Alert contents

There are several ways monitor messages passing through the Service Bus. Using pipeline alerts is one of them. Pipeline alerts can be searched in the Enterprise Manager based on several parameters such as summary or when they have occurred. Usually an important part of the message payload is saved in the content of the alert. This content can not be searched from the Enterprise Manager. In this post I will provide an example for logging Service Bus request and response messages using pipeline alerts and a means to search alert contents for a specific occurrence. The example provided has been created in SOA Suite 12.1.3 but the script also works in SOA Suite 11.1.1.6.

Deploying SOA Suite 12c artifacts from Nexus

SOA Suite 12c introduces Maven support to build and deploy artifacts. Oracle has provided extensive documentation on this. Also there already are plenty of blog posts describing how to do this. I will not repeat those posts (only shortly describe the steps). What I couldn't find quickly enough though was how to deploy artifacts from an artifact repository to an environment. This is a task often done by provisioning software such as Puppet or Jenkins. Sometimes though you want to do this from a command-line. In this post I'll briefly describe steps required to get your Continuous Delivery efforts going and how to deploy an artifact from the Nexus repository to a SOA Suite runtime environment.

Oracle SOA Suite 12c: SOA instance purging with the Java API in multiple threads

Let's tackle a single topic at a time in this blog post ;) SOA Suite 12c provides a Java API to perform operations on the SOA infrastructure and things running there such as composites and instances. There are several blog posts available on how to do this in SOA Suite 10g and 11g. However since 12c is relatively new, I decided to try if I could easily access the Java API in 12c and if the API was still similar to 11g or had undergone major changes. As a usecase I decided I wanted to purge instances. This is usually done by database scripts on the SOA infra database. If however you do not have direct access to the database, this can be used as an alternative. I could of course have done the same by using WLST. I found that purging instances by using the Java API was slow so I decided I would like to try this using multiple threads working in parallel. The resulting code is provided in this post.

Oracle SOA Suite 12c: The LDAPAdapter, a quick and easy tutorial

In enterprises, LDAP servers are often used to store user credentials and groups and share them among applications. Oracle SOA Suite 12c introduces a new technology adapter; the LDAPAdapter which allows easy integration with LDAP servers. In this blog post I will provide a quick and easy howto on installation of an LDAP server and browser (ApacheDS and Apache Directory Studio). I will also describe the configuration required to use the LDAPAdapter and provide an example BPEL process which allows creation of new users in the ApacheDS LDAP server by means of webservice calls.

SOA Suite 12c: Obtaining composite resources such as WSDLs, XSDs and WADLs

In SOA Suite 12c and 11g there are several options to obtain composite resources such as WSDL's and WADL's. In this blog post I will demonstrate some of them and provide some background information. First I'll describe how URL's can be used to access composite resources. Next I'll describe how and when the EM test console and the Webservice test client can be used to gain information about composite WSDL's and XSD's.

SOA Suite 12c: Introducing the REST Adapter

The REST Adapter is an important new feature of Oracle SOA Suite 12c. This new adapter allows easy calling/exposing of RESTful services (see http://javaoraclesoa.blogspot.nl/2014/05/what-is-rest.html for an introduction to REST) based on a WADL or configured manually. Not only does Oracle introduce the REST Adapter, but JSON support is also added in SOA Suite 12c. These features will greatly increase the integration options and flexibility of Oracle SOA Suite. In this blog I'll describe how a RESTful service can be called by using the REST adapter. Exposing a RESTful service will be described in a later blog.