The Parking Lot Pattern has been leveraged in many Oracle SOA Suite deployments to handle complex batching, message correlation, and complex processing flows. One scenario that is a frequent topic of discussion is throttling SOA Suite so as not to overwhelm slower downstream systems. Most often this is accomplished via the tuning knobs within SOA Suite and WebLogic Server. However, there are times when the built-in tuning cannot be tweaked enough to stop flooding slower systems. SOA design patterns can be leveraged when product features do not address these edge use cases. This blog will focus on using The Parking Lot Pattern as one implementation for throttling. Also note a working example is provided.
Throttling Parking Lot
The key piece to this pattern is the database table that will be used for the parking lot. The table is very simple and comprised of 3 columns:
|
Column
|
Description
|
|
ID (NUMBER)
|
This is the unique ID/key for the row in the table.
|
|
STATE (VARCHAR)
|
|
This will be used for state management and logical delete with the database adapter. There are three values this column will hold:
|
|
1.
|
N – New (Not Processed)
|
|
2.
|
P – Processing (In-flight interaction with slower system)
|
|
3.
|
C – Complete (Slower system responded to interaction)
|
|
The database adapter will poll for ‘N’ew rows and will mark the row as ‘P’rocessing when it hands it over to a BPEL process.
|
|
|
PAYLOAD (CLOB)
|
The message that would normally be associated with a component is stored here as an XML clob.
|
The Use Case Flow
Without the parking lot, the normal flow for this use case would be:
|
1.
|
Some client applications call SOA Suite via Web Service, JMS, etc.
|
|
2.
|
An asynchronous BPEL instance is created and invokes the slower system for every client request within the tuning parameters of the SOA engine
|
|
3.
|
The slower system cannot handle the volume and gets flooded
|
How the flow is changed with the parking lot:
|
1.
|
Some client applications call SOA Suite via Web Service, JMS, etc.
|
|
2.
|
Each client request is inserted into the parking lot table as an XML clob with STATE = ‘N’.
|
|
3.
|
A composite containing a polling database adapter will select 1 row with STATE = ‘N’ and the count of rows with STATE = ‘P’ are less than a throttle value (e.g., 5).
|
|
4.
|
If the in-flight interactions with the slower system are less than the throttle value, the database adapter gets the next available row and marks it as being processed (STATE = ‘P’).
|
|
5.
|
This row is handed off to an asynchronous BPEL process that will invoke a different BPEL process responsible for interacting with the slower system.
|
|
6.
|
When the slower system responds and this response propagates back to the initiating BPEL process, the row is marked as complete (STATE = ‘C’).
|
|
7.
|
Go to step 3 until all records have been processed.
|
The throttle control value represents the maximum number of in-flight BPEL processes that are interacting with the slower system. We will see later how this value can be changed at runtime through the SOA Suite Enterprise Manager console.
Read the complete article here.
SOA & BPM Partner Community
For regular information on Oracle SOA Suite become a member in the SOA & BPM Partner Community for registration please visit www.oracle.com/goto/emea/soa (OPN account required) If you need support with your account please contact the Oracle Partner Business Center.
Blog 
Twitter 
LinkedIn ![image[7][2][2][2]](https://soacommunity.files.wordpress.com/2013/04/image7222.png?w=20&h=20 "image[7][2][2][2]")
Facebook ![clip_image002[8][4][2][2][2]](https://soacommunity.files.wordpress.com/2013/04/clip_image00284222.jpg?w=26&h=23 "clip_image002[8][4][2][2][2]")
Wiki
PaaS Community Blog 