Throttling in SOA Suite via Parking Lot Pattern

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:

The Use Case Flow

Without the parking lot, the normal flow for this use case would be:

How the flow is changed with the parking lot:

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.

Configuring the Polling Database Adapter

The database adapter is the gate for flow control via the polling SQL statement. And “expert polling” configuration is required in order to setup the appropriate SQL statement. This configuration is a combination of getting artifacts created in JDeveloper using the DBAdapter Configuration Wizard and then manually tweaking the generated artifacts. The important steps in the wizard consist of:

When the wizard finishes and the artifacts are created, there will be a file with the following naming convention: [Service Name]-or-mappings.xml (please note that you may have to edit this file outside of JDeveloper with 12c). It is in this file we will make changes that are considered “expert polling” configuration steps. The steps are not complicated:

SELECT
    ID,
    "STATE",
    PAYLOAD
FROM
    THROTTLE_PARKINGLOT
WHERE
    (((SELECT COUNT("STATE") FROM THROTTLE_PARKINGLOT WHERE "STATE" = 'P') < #MaxRowsProcessing) AND
    ("STATE" = 'N'))
ORDER BY ID ASC FOR UPDATE SKIP LOCKED

<delete-query>
    <call xsi:type="sql-call">
      <sql>
      UPDATE THROTTLE_PARKINGLOT SET "STATE" = 'P' WHERE (ID = #ID)
      </sql>
    </call>
</delete-query>

Other Components

Now that the polling adapter is configured, we need an asynchronous BPEL process to handle the state management of the message. In the blog example, it is a very straightforward process:

The state update is done through another DBAdapter configuration where the Operation Type is Update Only and the column is the STATE column. The state management BPEL process simply updates the STATE to ‘C’ using the row ID it already has as the key.
The blog example has one more BPEL process called SlowSystemSimulatorBPELProcess. This is an asynchronous BPEL process that will randomly generate a wait time in seconds between 20 and 240. It then uses a Wait activity to simulate a very slow and sporadic downstream system.

The Example

I have provided two SOA Suite 12c projects for the example:

Each project contains the necessary SQL scripts to get things setup in the database. Once the user and the table are set up, you will have to configure your database adapter for accessing the THROTTLE_PARKINGLOT table via the ATeam_Example user. To make it easier on you, use eis/DB/ATeamExample as the JNDI Name for the DBAdapter. Otherwise this will need to be changed in the .jca files before deploying the projects to your SOA server.

Once the projects are deployed, you can run a stress test on the ThrottleParkingLotTableLoader / AddPayloadToParkingLotMediator_ep to fill the parking lot with records. Once the parking lot has records they should start being processed by the ThrottleParkingLotBlogExample composite. The initial setting for the MaxRowsProcessing property is 5, so the number in in-flight instances will be limited to 5:

Within the SOA Suite Enterprise Manager, we can change the value of MaxRowsProcessing:

Now we see that the number of in-flight instances has changed:

This will allow runtime tweaking of load on the downstream system. The value for MaxRowsProcessing can also be set to 0 (zero) to stop messages flowing to the downstream system. If you noticed, the polling sequence also leverages SKIP LOCKED which should allow this to work in a clustered environment. However, I have not tested this so feel free to try it out and provide feedback on your findings

I do hope you find this a valuable option for finer grained throttling within SOA Suite.