New to SOA 12.2.1 is the concept of Resiliency.  Oracle has introduced functionality that shuts down adapters when their composite failure meets a certain threshold. In effect, an error circuit breaker!  This is extremely helpful to prevent filling up the error hospital with an abundance of errors.  When suspended, the failed composite will retry the composite at a defined interval in an attempt to un-suspend the service adapter.  The idea is to suspend any inbound adapters so that messages can be queued whenever an error is present and then processed later when the service is fixed. 

Currently, resiliency currently only works for a small subset of adapters.  These adapters include EDN, File, FTP, AQ, and JMS.  

My Example – File Adapter

I deployed a sample project that used a file adapter to read a file and insert those records into a database table.  Once the global resiliency policy was configured for the server, there is no special setup or additional configuration needed at the process/project level.  

I dropped a few files into the staging area that the file adapter read, and off they went.  All the records were inserted into the database as expected.  To cause a failure, I renamed the database table.  Now, my database adapter will no longer be able to find the table it needs to insert into.  I copied a few more files into the staging directory and, as expected, they disappeared and faulted instances showed up.  However, because I had configured the global resiliency to trigger with three errors in two minutes the file adapter now shows as suspended.

After the configured five minute retry interval, the files in the staging area were picked up by the file adapter in an attempt to re-enable the adapter.  Failed instances were created and sent to the error hospital as expected.  I fixed the table name and dropped a few more files into the staging area.  Again, after the specified retry interval, the files were picked up and processed successfully.  EM no longer shows the adapter as being suspended!  I manually recovered all of the failed instances and verified that they had completed successfully.

Important Note!  

This feature is very helpful to prevent an overload of the error hospital. However, this does not protect the order of messages.  After the first few failed instances were created, it attempted to instantiate new messages at the configured interval.  The new messages were processed out of order and then I manually had to recover the initial failed instances using the error hospital.  If event order matters in your process, do not enable this feature! 

Configuration

Configuring resiliency is done in EM. Expand out the Target Navigation, right click on soa-infra, and navigate down to SOA Administration -> Resiliency Configuration

Set a failure rate (3 errors in 2 minutes), a retry interval, and then click Apply.  Its that easy!  If desired, notifications can be enabled when adapters are suspended. The options include Email, SMS, and IM.