Forum Stats

  • 3,851,852 Users
  • 2,264,043 Discussions


DBAdapter polling for new or changed records not issuing callback?

1017794 Member Posts: 7
edited Jul 3, 2014 2:32PM in SOA Suite Discusssions


I have a requirement to poll a database table withing an asynchronous process. The reason I want to use a receive within an asynchronous BPEL is because the process needs to be notified many times thru polling. So might need many receive activities.

I have developed a process as described below :-

1. Created an asynchronous process.

2. Created a Database adapter for polling a table. Logical delete strategy is being used.

3. Have put a receive activity from the DB Adapter created.

4. Created a correlation set consisting of a single property(String)

5. Created a property alias to refer to

a. the input string of the asynchronous process. (unique for this process)

b. the input from the database adapter (unique for this process)

I initiate this process from the console. Then I inserted a record the table with proper inputs.

But the BPEL waits indefinitely at the receive activity.

When I try to poll the table from an empty BPEL process, it works perfectly fine.

Could someone please help me here.



  • I would suspect that the Correlation Set is not working as expected, since the DB adapter message flow works in the non correlated case. I would suggest that you enable TRACE level logging for the BPEL engine, via the EM console and look for some clue in the SOA diagnostic log.

  • 1017794
    1017794 Member Posts: 7

    Hi Bo_Stern,

    Thanx for your response.

    Actually this is what i am trying to achieve :-

    both the receives are matched with correlation IDs,upon testing the ssecond

    receive is showing receive is pending although logical delete is happenning.

    I am using a non XA Datasource for the same.

    please find my sample project as attachment (version



    On Wed, Jul 2, 2014 at 6:03 AM, community-admin <

  • Unfortunately the image did not make it in the posting above. The Logical Delete will happen since the adapter consumes and posts the message to BPEL. However, BPEL is not able to successfully correlate the message, and thus it appears as if the <receive> is hanging.

    I would suggest you provide your test case to support, if you would like additional help with analysis.

This discussion has been closed.