How many times have you developed a new composite, or migrated an older composite, that simply turned into an overly complex process? Modifying and debugging the new process can become more difficult and take longer to implement.
A good java implementation breaks the problem into manageable classes that can be easily understood and managed over the life of the implementation. Since this works well with java, why not apply the basic principle to a composite. In comes SOA 12C and the implementation of subprocesses, which can be utilized for breaking down a composite into manageable components.
Breaking down a complex composite provides several benefits:
- Easy modification – smaller processes that focus on particular functionality are much easier to visualize and understand
- Reducing duplication – smaller processes provide the ability to be re-used within the composite
- Localized error handling – smaller processes allow specific error handling requirements to be handled and thrown to calling process
Now I will show a simplistic example of a composite that performs database syncing. The composite will attempt to sync table 1 and if any number of records are sync’d, then we want to sync table 2. I will not go into the details of how to create a subprocess since there are many tutorials already available.
My general approach is to simplify the main process so the flow is easier to follow. This concept can be extended to the subprocess layer in a similar fashion as the BPEL layer, if the subprocess layer becomes too complex.
The re-usable subprocess (spSyncTable) is used to sync both tables and the table name will be passed in as a parameter to the subprocess. The data records to sync are passed in as an additional parameter and the number of records processed will be passed back to the bpel process.
When implementing the logic within the subprocess, I have found that it is helpful to immediately create an additional scope level within the main scope. The reason for this is to only place variables in the main global scope for those variables that will be exposed as the interface to the subprocess (a method signature in Java). All other variables should be created at the inner scope level to make sure they aren’t inadvertently exposed on the interface.
There are two types of subprocesses, inline and standalone, that can be utilized. I use the standalone subprocess as it is available for re-use at the composite level, inline subprocesses are only re-usable at the BPEL level.
One other important note when using subprocesses: make sure that you install the appropriate patch for either 12.1.3 or 12.2.1 that will fix a memory leak issue. See Doc ID 2172292.1 and Patch 22696243.