Correlation in foreach

[V. Seprak]

Hello,

I'm trying to create foreach counstruct in my BPEL process. When i have only 'invoke' activity inside foreach, everything works fine. But when i add 'receive' activity (with or without correlation), my process crushes even before invoke activity is executed. I have ODE v 1.3.2 connected to postgres DB through hibernate. The stack trace i get is following:

2009-10-24 16:25:54,750 DEBUG - GeronimoLog.debug(66) | prepareStmt: insert into BPEL_SELECTORS (PIID, SELGRPID, IDX, CORRELATION_KEY, PROC_TYPE, CORRELATOR, INSERT_TIME, MLOCK, ID) values (?, ?, ?, ?, ?, ?, ?, ?, ?)
2009-10-24 16:25:54,750 DEBUG - GeronimoLog.debug(66) | executeBatch, bound (1,8730) (2,116) (3,0) (4,240~) (5,{http://eclipse.org/bpel/sample}P0002) (6,8726) (7,2009-10-24 16:25:54.531) (8,0) (9,9173)
2009-10-24 16:25:55,578 DEBUG - GeronimoLog.debug(66) | close()
2009-10-24 16:25:55,609 DEBUG - GeronimoLog.debug(66) | close()
2009-10-24 16:25:55,687 ERROR - GeronimoLog.error(108) | Commit failed.
javax.transaction.RollbackException: [com.arjuna.ats.internal.jta.transaction.arjunacore.commitwhenaborted] [com.arjuna.ats.internal.jta.transaction.arjunacore.commitwhenaborted] Can't commit because the transaction is in aborted state
        at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1401)
        at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:135)
        at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:87)
        at org.apache.ode.bpel.engine.Contexts.execTransaction(Contexts.java:114)
        at org.apache.ode.bpel.engine.Contexts.execTransaction(Contexts.java:83)
        at org.apache.ode.bpel.engine.BpelServerImpl$TransactedRunnable.run(BpelServerImpl.java:981)
        at org.apache.ode.bpel.engine.BpelInstanceWorker$2.call(BpelInstanceWorker.java:143)
        at org.apache.ode.bpel.engine.BpelInstanceWorker$2.call(BpelInstanceWorker.java:142)
        at org.apache.ode.bpel.engine.BpelInstanceWorker.doInstanceWork(BpelInstanceWorker.java:174)
        at org.apache.ode.bpel.engine.BpelInstanceWorker.run(BpelInstanceWorker.java:141)
        at org.apache.ode.bpel.engine.ODEProcess$ProcessRunnable.run(ODEProcess.java:1189)
        at org.apache.ode.bpel.engine.BpelServerImpl$ServerRunnable.run(BpelServerImpl.java:923)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
        at java.util.concurrent.FutureTask.run(FutureTask.java:138)
        at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
        at java.lang.Thread.run(Thread.java:619)
Caused by: org.hibernate.exception.ConstraintViolationException: Could not execute JDBC batch update
        at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:71)
        at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
        at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:253)
        at org.hibernate.jdbc.AbstractBatcher.prepareStatement(AbstractBatcher.java:92)
        at org.hibernate.jdbc.AbstractBatcher.prepareStatement(AbstractBatcher.java:87)
        at org.hibernate.jdbc.AbstractBatcher.prepareBatchStatement(AbstractBatcher.java:222)
        at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2224)
        at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2660)
        at org.hibernate.action.EntityInsertAction.execute(EntityInsertAction.java:56)
        at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:250)
        at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:234)
        at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:141)
        at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:298)
        at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27)
        at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000)
        at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:338)
        at org.hibernate.transaction.CacheSynchronization.beforeCompletion(CacheSynchronization.java:59)
        at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:114)
        at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:247)
        at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:86)
        at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:177)
        at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1389)
        ... 17 more
Caused by: java.sql.BatchUpdateException: Batch entry 0 insert into BPEL_SELECTORS (PIID, SELGRPID, IDX, CORRELATION_KEY, PROC_TYPE, CORRELATOR, INSERT_TIME, MLOCK, ID) values ('8730', '116', '0', '240~', '{http://eclipse.org/bpel/sample}P0002', '8726', '2009-10-24 16:25:54.531000 +02:00:00', '0', '9173') was aborted.  Call getNextException to see the cause.
        at org.postgresql.jdbc2.AbstractJdbc2Statement$BatchResultHandler.handleError(AbstractJdbc2Statement.java:2569)
        at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1796)
        at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:407)
        at org.postgresql.jdbc2.AbstractJdbc2Statement.executeBatch(AbstractJdbc2Statement.java:2708)
        at org.jboss.resource.adapter.jdbc.WrappedStatement.executeBatch(WrappedStatement.java:774)
        at sun.reflect.GeneratedMethodAccessor856.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.apache.ode.utils.LoggingInterceptor.invoke(LoggingInterceptor.java:70)
        at $Proxy333.executeBatch(Unknown Source)
        at org.hibernate.jdbc.BatchingBatcher.doExecuteBatch(BatchingBatcher.java:48)
        at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:246)
        ... 36 more
2009-10-24 16:25:55,703 ERROR - GeronimoLog.error(108) | Work for instance {http://eclipse.org/bpel/sample}P0002-19#8730 in thread Thread[ODEServerImpl-27,5,jboss] resulted in an exception.


With willowing JDBC exception:

ERROR: duplicate key value violates unique constraint "bpel_selectors_correlation_key_key"


Relevant part (on id_num correlation is performed) :

        <complexType name="DocPartX">
                <sequence>
                        <element name="ElemX" type="boolean" nillable="true" />
                        <element name="ElemY" type="P0002:ElemY" />
                </sequence>
        </complexType>
        <complexType name="ElemY">
                <sequence>
                        <element name="value" type="P0002:ElemYContent" maxOccurs="unbounded"/>
                </sequence>
        </complexType>
        <complexType name="ElemYContent">
                <sequence>
                        <element name="id_num" type="string"/>
                        <element name="name" type="string"/>
                        <element name="result_from_external_service" type="string"/>
                </sequence>
        </complexType>

In foreach sequence I first prepare document with SINGLE ElemY. Then I invoke external service with this document and then receive document with filled result_from_external_service element.

Any hint on cause of this problem is appreciated. Thanx.

[V. Seprak]

I have correlation property defined as following:

   <vprop:property xmlns="http://www.w3.org/2001/XMLSchema" name="subtask-id" type="string"/>
    <vprop:propertyAlias messageType='tns:acceptTaskDataRequest' part='parameters' propertyName='tns:subtask-id' >
        <vprop:query>xsd:DocPartX/xsd:ElemY/xsd:value[1]/xsd:id_num</vprop:query>
    </vprop:propertyAlias>

Note that inside acceptTaskDataRequest I have only one 'value' element (removing other 'value' elements is performed in assign operation - which is also the first activity in my foreach construct). If i remove [1] qualifier, i get error that multiple values for correlation are returned, which is realy strange because i have only one 'value' element.
 

shepy wrote:

Relevant part (on id_num correlation is performed) :

        <complexType name="DocPartX">
                <sequence>
                        <element name="ElemX" type="boolean" nillable="true" />
                        <element name="ElemY" type="P0002:ElemY" />
                </sequence>
        </complexType>
        <complexType name="ElemY">
                <sequence>
                        <element name="value" type="P0002:ElemYContent" maxOccurs="unbounded"/>
                </sequence>
        </complexType>
        <complexType name="ElemYContent">
                <sequence>
                        <element name="id_num" type="string"/>
                        <element name="name" type="string"/>
                        <element name="result_from_external_service" type="string"/>
                </sequence>
        </complexType>

In foreach sequence I first prepare document with SINGLE ElemY. Then I invoke external service with this document and then receive document with filled result_from_external_service element.

Any hint on cause of this problem is appreciated. Thanx.

[V. Seprak]

It looks like correlation inside parallel foreach is not supported by ODE. Can anybody confirm this?

[Karthick Sankarachary-3]

Using correlations inside of a parallel <forEach> activity might result in a
bpws:conflictingReceive, which the spec defines as follows:

"If during the execution of a business process instance, two or more receive
activities for the same partner link, portType, operation and correlation
set(s) are in fact simultaneously enabled, then the standard fault
bpws:conflictingReceive MUST be thrown by a compliant implementation."

Off the top of my head, one way to work around this issue could be to extend
the message variable that you're correlating on (via a <invoke> or <receive>
activity, for instance), by adding a numeric property, say
"iterationNumber", which is set to the value of the <forEach> counterName
variable. That property basically acts as a discriminant between the
messages corresponding to different iterations. AFAIK, there is no
constraint in the spec per se that would allow us to implement this feature
in the BPEL server.
Best Regards,
Karthick Sankarachary


On Fri, Oct 30, 2009 at 6:07 AM, shepy <vladoseprak@...> wrote:

>
> It looks like correlation inside parallel foreach is not supported by ODE.
> Can anybody confirm this?
> --
> View this message in context:
> http://old.nabble.com/Correlation-in-foreach-tp26050377p26129778.html
> Sent from the Apache Ode User mailing list archive at Nabble.com.
>
>

[Alex Boisvert-3]

Simply put, the way to resolve of this is to use a correlation set (nested)
inside your <bpel:forEach> scope such that the correlation is unique to each
instance of the <bpel:receive> activity.

alex


On Fri, Oct 30, 2009 at 12:40 PM, Karthick Sankarachary <
sankarachary@...> wrote:

> Using correlations inside of a parallel <forEach> activity might result in
> a
> bpws:conflictingReceive, which the spec defines as follows:
>
> "If during the execution of a business process instance, two or more
> receive
> activities for the same partner link, portType, operation and correlation
> set(s) are in fact simultaneously enabled, then the standard fault
> bpws:conflictingReceive MUST be thrown by a compliant implementation."
>
> Off the top of my head, one way to work around this issue could be to
> extend
> the message variable that you're correlating on (via a <invoke> or
> <receive>
> activity, for instance), by adding a numeric property, say
> "iterationNumber", which is set to the value of the <forEach> counterName
> variable. That property basically acts as a discriminant between the
> messages corresponding to different iterations. AFAIK, there is no
> constraint in the spec per se that would allow us to implement this feature
> in the BPEL server.
> Best Regards,
> Karthick Sankarachary
>
>
> On Fri, Oct 30, 2009 at 6:07 AM, shepy <vladoseprak@...> wrote:
>
> >
> > It looks like correlation inside parallel foreach is not supported by
> ODE.
> > Can anybody confirm this?
> > --
> > View this message in context:
> > http://old.nabble.com/Correlation-in-foreach-tp26050377p26129778.html
> > Sent from the Apache Ode User mailing list archive at Nabble.com.
> >
> >
>

[V. Seprak]

And this is exactly what I did. I have added a property to my message which,
in first assign activity, I set to $Counter value. Then i correlate on this
property. This didn't help. When i start with clean ODE database then it
works, but only the first time process is executed. Every subsequent
invocation results with "duplicate key value violates unique constraint
bpel_selectors_correlation_key_key". I have noticed that ODE tries to insert
empty value as CORRELATION_KEY (BPEL_SELECTORS table). Something like "240~"
where it should insert "240~myCorrelationId".  


Alex Boisvert-3 wrote:

>
> Simply put, the way to resolve of this is to use a correlation set
> (nested)
> inside your <bpel:forEach> scope such that the correlation is unique to
> each
> instance of the <bpel:receive> activity.
>
> alex
>
>
> On Fri, Oct 30, 2009 at 12:40 PM, Karthick Sankarachary <
> sankarachary@...> wrote:
>
>> Using correlations inside of a parallel <forEach> activity might result
>> in
>> a
>> bpws:conflictingReceive, which the spec defines as follows:
>>
>> "If during the execution of a business process instance, two or more
>> receive
>> activities for the same partner link, portType, operation and correlation
>> set(s) are in fact simultaneously enabled, then the standard fault
>> bpws:conflictingReceive MUST be thrown by a compliant implementation."
>>
>> Off the top of my head, one way to work around this issue could be to
>> extend
>> the message variable that you're correlating on (via a <invoke> or
>> <receive>
>> activity, for instance), by adding a numeric property, say
>> "iterationNumber", which is set to the value of the <forEach> counterName
>> variable. That property basically acts as a discriminant between the
>> messages corresponding to different iterations. AFAIK, there is no
>> constraint in the spec per se that would allow us to implement this
>> feature
>> in the BPEL server.
>> Best Regards,
>> Karthick Sankarachary
>>
>>
>> On Fri, Oct 30, 2009 at 6:07 AM, shepy <vladoseprak@...> wrote:
>>
>> >
>> > It looks like correlation inside parallel foreach is not supported by
>> ODE.
>> > Can anybody confirm this?
>> > --
>> > View this message in context:
>> > http://old.nabble.com/Correlation-in-foreach-tp26050377p26129778.html
>> > Sent from the Apache Ode User mailing list archive at Nabble.com.
>> >
>> >
>>
>
>

--
View this message in context: http://old.nabble.com/Correlation-in-foreach-tp26050377p26156622.html
Sent from the Apache Ode User mailing list archive at Nabble.com.

[V. Seprak]

And this is exactly what I did. I have added a property to my message which,
in first assign activity, I set to $Counter value. Then i correlate on this
property. This didn't help. When i start with clean ODE database then it
works, but only the first time process is executed. Every subsequent
invocation results with "duplicate key value violates unique constraint
bpel_selectors_correlation_key_key". I have noticed that ODE tries to insert
empty value as CORRELATION_KEY (BPEL_SELECTORS table). Something like "240~"
where it should insert "240~myCorrelationId".  


Alex Boisvert-3 wrote:

>
> Simply put, the way to resolve of this is to use a correlation set
> (nested)
> inside your <bpel:forEach> scope such that the correlation is unique to
> each
> instance of the <bpel:receive> activity.
>
> alex
>
>
> On Fri, Oct 30, 2009 at 12:40 PM, Karthick Sankarachary <
> sankarachary@...> wrote:
>
>> Using correlations inside of a parallel <forEach> activity might result
>> in
>> a
>> bpws:conflictingReceive, which the spec defines as follows:
>>
>> "If during the execution of a business process instance, two or more
>> receive
>> activities for the same partner link, portType, operation and correlation
>> set(s) are in fact simultaneously enabled, then the standard fault
>> bpws:conflictingReceive MUST be thrown by a compliant implementation."
>>
>> Off the top of my head, one way to work around this issue could be to
>> extend
>> the message variable that you're correlating on (via a <invoke> or
>> <receive>
>> activity, for instance), by adding a numeric property, say
>> "iterationNumber", which is set to the value of the <forEach> counterName
>> variable. That property basically acts as a discriminant between the
>> messages corresponding to different iterations. AFAIK, there is no
>> constraint in the spec per se that would allow us to implement this
>> feature
>> in the BPEL server.
>> Best Regards,
>> Karthick Sankarachary
>>
>>
>> On Fri, Oct 30, 2009 at 6:07 AM, shepy <vladoseprak@...> wrote:
>>
>> >
>> > It looks like correlation inside parallel foreach is not supported by
>> ODE.
>> > Can anybody confirm this?
>> > --
>> > View this message in context:
>> > http://old.nabble.com/Correlation-in-foreach-tp26050377p26129778.html
>> > Sent from the Apache Ode User mailing list archive at Nabble.com.
>> >
>> >
>>
>
>

--
View this message in context: http://old.nabble.com/Correlation-in-foreach-tp26050377p26156622.html
Sent from the Apache Ode User mailing list archive at Nabble.com.

[V. Seprak]

And this is exactly what I did. I have added a property to my message which,
in first assign activity, I set to $Counter value. Then i correlate on this
property. This didn't help. When i start with clean ODE database then it
works, but only the first time process is executed. Every subsequent
invocation results with "duplicate key value violates unique constraint
bpel_selectors_correlation_key_key". I have noticed that ODE tries to insert
empty value as CORRELATION_KEY (BPEL_SELECTORS table). Something like "240~"
where it should insert "240~myCorrelationId".  


Alex Boisvert-3 wrote:

>
> Simply put, the way to resolve of this is to use a correlation set
> (nested)
> inside your <bpel:forEach> scope such that the correlation is unique to
> each
> instance of the <bpel:receive> activity.
>
> alex
>
>
> On Fri, Oct 30, 2009 at 12:40 PM, Karthick Sankarachary <
> sankarachary@...> wrote:
>
>> Using correlations inside of a parallel <forEach> activity might result
>> in
>> a
>> bpws:conflictingReceive, which the spec defines as follows:
>>
>> "If during the execution of a business process instance, two or more
>> receive
>> activities for the same partner link, portType, operation and correlation
>> set(s) are in fact simultaneously enabled, then the standard fault
>> bpws:conflictingReceive MUST be thrown by a compliant implementation."
>>
>> Off the top of my head, one way to work around this issue could be to
>> extend
>> the message variable that you're correlating on (via a <invoke> or
>> <receive>
>> activity, for instance), by adding a numeric property, say
>> "iterationNumber", which is set to the value of the <forEach> counterName
>> variable. That property basically acts as a discriminant between the
>> messages corresponding to different iterations. AFAIK, there is no
>> constraint in the spec per se that would allow us to implement this
>> feature
>> in the BPEL server.
>> Best Regards,
>> Karthick Sankarachary
>>
>>
>> On Fri, Oct 30, 2009 at 6:07 AM, shepy <vladoseprak@...> wrote:
>>
>> >
>> > It looks like correlation inside parallel foreach is not supported by
>> ODE.
>> > Can anybody confirm this?
>> > --
>> > View this message in context:
>> > http://old.nabble.com/Correlation-in-foreach-tp26050377p26129778.html
>> > Sent from the Apache Ode User mailing list archive at Nabble.com.
>> >
>> >
>>
>
>

--
View this message in context: http://old.nabble.com/Correlation-in-foreach-tp26050377p26156622.html
Sent from the Apache Ode User mailing list archive at Nabble.com.

[V. Seprak]

And this is exactly what I did. I have added a property to my message which,
in first assign activity, I set to $Counter value. Then i correlate on this
property. This didn't help. When i start with clean ODE database then it
works, but only the first time process is executed. Every subsequent
invocation results with "duplicate key value violates unique constraint
bpel_selectors_correlation_key_key". I have noticed that ODE tries to insert
empty value as CORRELATION_KEY (BPEL_SELECTORS table). Something like "240~"
where it should insert "240~myCorrelationId".  


Alex Boisvert-3 wrote:

>
> Simply put, the way to resolve of this is to use a correlation set
> (nested)
> inside your <bpel:forEach> scope such that the correlation is unique to
> each
> instance of the <bpel:receive> activity.
>
> alex
>
>
> On Fri, Oct 30, 2009 at 12:40 PM, Karthick Sankarachary <
> sankarachary@...> wrote:
>
>> Using correlations inside of a parallel <forEach> activity might result
>> in
>> a
>> bpws:conflictingReceive, which the spec defines as follows:
>>
>> "If during the execution of a business process instance, two or more
>> receive
>> activities for the same partner link, portType, operation and correlation
>> set(s) are in fact simultaneously enabled, then the standard fault
>> bpws:conflictingReceive MUST be thrown by a compliant implementation."
>>
>> Off the top of my head, one way to work around this issue could be to
>> extend
>> the message variable that you're correlating on (via a <invoke> or
>> <receive>
>> activity, for instance), by adding a numeric property, say
>> "iterationNumber", which is set to the value of the <forEach> counterName
>> variable. That property basically acts as a discriminant between the
>> messages corresponding to different iterations. AFAIK, there is no
>> constraint in the spec per se that would allow us to implement this
>> feature
>> in the BPEL server.
>> Best Regards,
>> Karthick Sankarachary
>>
>>
>> On Fri, Oct 30, 2009 at 6:07 AM, shepy <vladoseprak@...> wrote:
>>
>> >
>> > It looks like correlation inside parallel foreach is not supported by
>> ODE.
>> > Can anybody confirm this?
>> > --
>> > View this message in context:
>> > http://old.nabble.com/Correlation-in-foreach-tp26050377p26129778.html
>> > Sent from the Apache Ode User mailing list archive at Nabble.com.
>> >
>> >
>>
>
>

--
View this message in context: http://old.nabble.com/Correlation-in-foreach-tp26050377p26156622.html
Sent from the Apache Ode User mailing list archive at Nabble.com.

[V. Seprak]

And this is exactly what I did. I have added a property to my message which,
in first assign activity, I set to $Counter value. Then i correlate on this
property. This didn't help. When i start with clean ODE database then it
works, but only the first time process is executed. Every subsequent
invocation results with "duplicate key value violates unique constraint
bpel_selectors_correlation_key_key". I have noticed that ODE tries to insert
empty value as CORRELATION_KEY (BPEL_SELECTORS table). Something like "240~"
where it should insert "240~myCorrelationId".  


Alex Boisvert-3 wrote:

>
> Simply put, the way to resolve of this is to use a correlation set
> (nested)
> inside your <bpel:forEach> scope such that the correlation is unique to
> each
> instance of the <bpel:receive> activity.
>
> alex
>
>
> On Fri, Oct 30, 2009 at 12:40 PM, Karthick Sankarachary <
> sankarachary@...> wrote:
>
>> Using correlations inside of a parallel <forEach> activity might result
>> in
>> a
>> bpws:conflictingReceive, which the spec defines as follows:
>>
>> "If during the execution of a business process instance, two or more
>> receive
>> activities for the same partner link, portType, operation and correlation
>> set(s) are in fact simultaneously enabled, then the standard fault
>> bpws:conflictingReceive MUST be thrown by a compliant implementation."
>>
>> Off the top of my head, one way to work around this issue could be to
>> extend
>> the message variable that you're correlating on (via a <invoke> or
>> <receive>
>> activity, for instance), by adding a numeric property, say
>> "iterationNumber", which is set to the value of the <forEach> counterName
>> variable. That property basically acts as a discriminant between the
>> messages corresponding to different iterations. AFAIK, there is no
>> constraint in the spec per se that would allow us to implement this
>> feature
>> in the BPEL server.
>> Best Regards,
>> Karthick Sankarachary
>>
>>
>> On Fri, Oct 30, 2009 at 6:07 AM, shepy <vladoseprak@...> wrote:
>>
>> >
>> > It looks like correlation inside parallel foreach is not supported by
>> ODE.
>> > Can anybody confirm this?
>> > --
>> > View this message in context:
>> > http://old.nabble.com/Correlation-in-foreach-tp26050377p26129778.html
>> > Sent from the Apache Ode User mailing list archive at Nabble.com.
>> >
>> >
>>
>
>

--
View this message in context: http://old.nabble.com/Correlation-in-foreach-tp26050377p26156622.html
Sent from the Apache Ode User mailing list archive at Nabble.com.

[V. Seprak]

And this is exactly what I did. I have added a property to my message which,
in first assign activity, I set to $Counter value. Then i correlate on this
property. This didn't help. When i start with clean ODE database then it
works, but only the first time process is executed. Every subsequent
invocation results with "duplicate key value violates unique constraint
bpel_selectors_correlation_key_key". I have noticed that ODE tries to insert
empty value as CORRELATION_KEY (BPEL_SELECTORS table). Something like "240~"
where it should insert "240~myCorrelationId".  


Alex Boisvert-3 wrote:

>
> Simply put, the way to resolve of this is to use a correlation set
> (nested)
> inside your <bpel:forEach> scope such that the correlation is unique to
> each
> instance of the <bpel:receive> activity.
>
> alex
>
>
> On Fri, Oct 30, 2009 at 12:40 PM, Karthick Sankarachary <
> sankarachary@...> wrote:
>
>> Using correlations inside of a parallel <forEach> activity might result
>> in
>> a
>> bpws:conflictingReceive, which the spec defines as follows:
>>
>> "If during the execution of a business process instance, two or more
>> receive
>> activities for the same partner link, portType, operation and correlation
>> set(s) are in fact simultaneously enabled, then the standard fault
>> bpws:conflictingReceive MUST be thrown by a compliant implementation."
>>
>> Off the top of my head, one way to work around this issue could be to
>> extend
>> the message variable that you're correlating on (via a <invoke> or
>> <receive>
>> activity, for instance), by adding a numeric property, say
>> "iterationNumber", which is set to the value of the <forEach> counterName
>> variable. That property basically acts as a discriminant between the
>> messages corresponding to different iterations. AFAIK, there is no
>> constraint in the spec per se that would allow us to implement this
>> feature
>> in the BPEL server.
>> Best Regards,
>> Karthick Sankarachary
>>
>>
>> On Fri, Oct 30, 2009 at 6:07 AM, shepy <vladoseprak@...> wrote:
>>
>> >
>> > It looks like correlation inside parallel foreach is not supported by
>> ODE.
>> > Can anybody confirm this?
>> > --
>> > View this message in context:
>> > http://old.nabble.com/Correlation-in-foreach-tp26050377p26129778.html
>> > Sent from the Apache Ode User mailing list archive at Nabble.com.
>> >
>> >
>>
>
>

--
View this message in context: http://old.nabble.com/Correlation-in-foreach-tp26050377p26156622.html
Sent from the Apache Ode User mailing list archive at Nabble.com.

[V. Seprak]

And this is exactly what I did. I have added a property to my message which,
in first assign activity, I set to $Counter value. Then i correlate on this
property. This didn't help. When i start with clean ODE database then it
works, but only the first time process is executed. Every subsequent
invocation results with "duplicate key value violates unique constraint
bpel_selectors_correlation_key_key". I have noticed that ODE tries to insert
empty value as CORRELATION_KEY (BPEL_SELECTORS table). Something like "240~"
where it should insert "240~myCorrelationId".  


Alex Boisvert-3 wrote:

>
> Simply put, the way to resolve of this is to use a correlation set
> (nested)
> inside your <bpel:forEach> scope such that the correlation is unique to
> each
> instance of the <bpel:receive> activity.
>
> alex
>
>
> On Fri, Oct 30, 2009 at 12:40 PM, Karthick Sankarachary <
> sankarachary@...> wrote:
>
>> Using correlations inside of a parallel <forEach> activity might result
>> in
>> a
>> bpws:conflictingReceive, which the spec defines as follows:
>>
>> "If during the execution of a business process instance, two or more
>> receive
>> activities for the same partner link, portType, operation and correlation
>> set(s) are in fact simultaneously enabled, then the standard fault
>> bpws:conflictingReceive MUST be thrown by a compliant implementation."
>>
>> Off the top of my head, one way to work around this issue could be to
>> extend
>> the message variable that you're correlating on (via a <invoke> or
>> <receive>
>> activity, for instance), by adding a numeric property, say
>> "iterationNumber", which is set to the value of the <forEach> counterName
>> variable. That property basically acts as a discriminant between the
>> messages corresponding to different iterations. AFAIK, there is no
>> constraint in the spec per se that would allow us to implement this
>> feature
>> in the BPEL server.
>> Best Regards,
>> Karthick Sankarachary
>>
>>
>> On Fri, Oct 30, 2009 at 6:07 AM, shepy <vladoseprak@...> wrote:
>>
>> >
>> > It looks like correlation inside parallel foreach is not supported by
>> ODE.
>> > Can anybody confirm this?
>> > --
>> > View this message in context:
>> > http://old.nabble.com/Correlation-in-foreach-tp26050377p26129778.html
>> > Sent from the Apache Ode User mailing list archive at Nabble.com.
>> >
>> >
>>
>
>

--
View this message in context: http://old.nabble.com/Correlation-in-foreach-tp26050377p26156622.html
Sent from the Apache Ode User mailing list archive at Nabble.com.

[V. Seprak]

And this is exactly what I did. I have added a property to my message which,
in first assign activity, I set to $Counter value. Then i correlate on this
property. This didn't help. When i start with clean ODE database then it
works, but only the first time process is executed. Every subsequent
invocation results with "duplicate key value violates unique constraint
bpel_selectors_correlation_key_key". I have noticed that ODE tries to insert
empty value as CORRELATION_KEY (BPEL_SELECTORS table). Something like "240~"
where it should insert "240~myCorrelationId".  


Alex Boisvert-3 wrote:

>
> Simply put, the way to resolve of this is to use a correlation set
> (nested)
> inside your <bpel:forEach> scope such that the correlation is unique to
> each
> instance of the <bpel:receive> activity.
>
> alex
>
>
> On Fri, Oct 30, 2009 at 12:40 PM, Karthick Sankarachary <
> sankarachary@...> wrote:
>
>> Using correlations inside of a parallel <forEach> activity might result
>> in
>> a
>> bpws:conflictingReceive, which the spec defines as follows:
>>
>> "If during the execution of a business process instance, two or more
>> receive
>> activities for the same partner link, portType, operation and correlation
>> set(s) are in fact simultaneously enabled, then the standard fault
>> bpws:conflictingReceive MUST be thrown by a compliant implementation."
>>
>> Off the top of my head, one way to work around this issue could be to
>> extend
>> the message variable that you're correlating on (via a <invoke> or
>> <receive>
>> activity, for instance), by adding a numeric property, say
>> "iterationNumber", which is set to the value of the <forEach> counterName
>> variable. That property basically acts as a discriminant between the
>> messages corresponding to different iterations. AFAIK, there is no
>> constraint in the spec per se that would allow us to implement this
>> feature
>> in the BPEL server.
>> Best Regards,
>> Karthick Sankarachary
>>
>>
>> On Fri, Oct 30, 2009 at 6:07 AM, shepy <vladoseprak@...> wrote:
>>
>> >
>> > It looks like correlation inside parallel foreach is not supported by
>> ODE.
>> > Can anybody confirm this?
>> > --
>> > View this message in context:
>> > http://old.nabble.com/Correlation-in-foreach-tp26050377p26129778.html
>> > Sent from the Apache Ode User mailing list archive at Nabble.com.
>> >
>> >
>>
>
>

--
View this message in context: http://old.nabble.com/Correlation-in-foreach-tp26050377p26156622.html
Sent from the Apache Ode User mailing list archive at Nabble.com.

[V. Seprak]

And this is exactly what I did. I have added a property to my message which,
in first assign activity, I set to $Counter value. Then i correlate on this
property. This didn't help. When i start with clean ODE database then it
works, but only the first time process is executed. Every subsequent
invocation results with "duplicate key value violates unique constraint
bpel_selectors_correlation_key_key". I have noticed that ODE tries to insert
empty value as CORRELATION_KEY (BPEL_SELECTORS table). Something like "240~"
where it should insert "240~myCorrelationId".  


Alex Boisvert-3 wrote:

>
> Simply put, the way to resolve of this is to use a correlation set
> (nested)
> inside your <bpel:forEach> scope such that the correlation is unique to
> each
> instance of the <bpel:receive> activity.
>
> alex
>
>
> On Fri, Oct 30, 2009 at 12:40 PM, Karthick Sankarachary <
> sankarachary@...> wrote:
>
>> Using correlations inside of a parallel <forEach> activity might result
>> in
>> a
>> bpws:conflictingReceive, which the spec defines as follows:
>>
>> "If during the execution of a business process instance, two or more
>> receive
>> activities for the same partner link, portType, operation and correlation
>> set(s) are in fact simultaneously enabled, then the standard fault
>> bpws:conflictingReceive MUST be thrown by a compliant implementation."
>>
>> Off the top of my head, one way to work around this issue could be to
>> extend
>> the message variable that you're correlating on (via a <invoke> or
>> <receive>
>> activity, for instance), by adding a numeric property, say
>> "iterationNumber", which is set to the value of the <forEach> counterName
>> variable. That property basically acts as a discriminant between the
>> messages corresponding to different iterations. AFAIK, there is no
>> constraint in the spec per se that would allow us to implement this
>> feature
>> in the BPEL server.
>> Best Regards,
>> Karthick Sankarachary
>>
>>
>> On Fri, Oct 30, 2009 at 6:07 AM, shepy <vladoseprak@...> wrote:
>>
>> >
>> > It looks like correlation inside parallel foreach is not supported by
>> ODE.
>> > Can anybody confirm this?
>> > --
>> > View this message in context:
>> > http://old.nabble.com/Correlation-in-foreach-tp26050377p26129778.html
>> > Sent from the Apache Ode User mailing list archive at Nabble.com.
>> >
>> >
>>
>
>

--
View this message in context: http://old.nabble.com/Correlation-in-foreach-tp26050377p26156622.html
Sent from the Apache Ode User mailing list archive at Nabble.com.

[V. Seprak]

And this is exactly what I did. I have added a property to my message which,
in first assign activity, I set to $Counter value. Then i correlate on this
property. This didn't help. When i start with clean ODE database then it
works, but only the first time process is executed. Every subsequent
invocation results with "duplicate key value violates unique constraint
bpel_selectors_correlation_key_key". I have noticed that ODE tries to insert
empty value as CORRELATION_KEY (BPEL_SELECTORS table). Something like "240~"
where it should insert "240~myCorrelationId".  


Alex Boisvert-3 wrote:

>
> Simply put, the way to resolve of this is to use a correlation set
> (nested)
> inside your <bpel:forEach> scope such that the correlation is unique to
> each
> instance of the <bpel:receive> activity.
>
> alex
>
>
> On Fri, Oct 30, 2009 at 12:40 PM, Karthick Sankarachary <
> sankarachary@...> wrote:
>
>> Using correlations inside of a parallel <forEach> activity might result
>> in
>> a
>> bpws:conflictingReceive, which the spec defines as follows:
>>
>> "If during the execution of a business process instance, two or more
>> receive
>> activities for the same partner link, portType, operation and correlation
>> set(s) are in fact simultaneously enabled, then the standard fault
>> bpws:conflictingReceive MUST be thrown by a compliant implementation."
>>
>> Off the top of my head, one way to work around this issue could be to
>> extend
>> the message variable that you're correlating on (via a <invoke> or
>> <receive>
>> activity, for instance), by adding a numeric property, say
>> "iterationNumber", which is set to the value of the <forEach> counterName
>> variable. That property basically acts as a discriminant between the
>> messages corresponding to different iterations. AFAIK, there is no
>> constraint in the spec per se that would allow us to implement this
>> feature
>> in the BPEL server.
>> Best Regards,
>> Karthick Sankarachary
>>
>>
>> On Fri, Oct 30, 2009 at 6:07 AM, shepy <vladoseprak@...> wrote:
>>
>> >
>> > It looks like correlation inside parallel foreach is not supported by
>> ODE.
>> > Can anybody confirm this?
>> > --
>> > View this message in context:
>> > http://old.nabble.com/Correlation-in-foreach-tp26050377p26129778.html
>> > Sent from the Apache Ode User mailing list archive at Nabble.com.
>> >
>> >
>>
>
>

--
View this message in context: http://old.nabble.com/Correlation-in-foreach-tp26050377p26156622.html
Sent from the Apache Ode User mailing list archive at Nabble.com.

[V. Seprak]

And this is exactly what I did. I have added a property to my message which,
in first assign activity, I set to $Counter value. Then i correlate on this
property. This didn't help. When i start with clean ODE database then it
works, but only the first time process is executed. Every subsequent
invocation results with "duplicate key value violates unique constraint
bpel_selectors_correlation_key_key". I have noticed that ODE tries to insert
empty value as CORRELATION_KEY (BPEL_SELECTORS table). Something like "240~"
where it should insert "240~myCorrelationId".  


Alex Boisvert-3 wrote:

>
> Simply put, the way to resolve of this is to use a correlation set
> (nested)
> inside your <bpel:forEach> scope such that the correlation is unique to
> each
> instance of the <bpel:receive> activity.
>
> alex
>
>
> On Fri, Oct 30, 2009 at 12:40 PM, Karthick Sankarachary <
> sankarachary@...> wrote:
>
>> Using correlations inside of a parallel <forEach> activity might result
>> in
>> a
>> bpws:conflictingReceive, which the spec defines as follows:
>>
>> "If during the execution of a business process instance, two or more
>> receive
>> activities for the same partner link, portType, operation and correlation
>> set(s) are in fact simultaneously enabled, then the standard fault
>> bpws:conflictingReceive MUST be thrown by a compliant implementation."
>>
>> Off the top of my head, one way to work around this issue could be to
>> extend
>> the message variable that you're correlating on (via a <invoke> or
>> <receive>
>> activity, for instance), by adding a numeric property, say
>> "iterationNumber", which is set to the value of the <forEach> counterName
>> variable. That property basically acts as a discriminant between the
>> messages corresponding to different iterations. AFAIK, there is no
>> constraint in the spec per se that would allow us to implement this
>> feature
>> in the BPEL server.
>> Best Regards,
>> Karthick Sankarachary
>>
>>
>> On Fri, Oct 30, 2009 at 6:07 AM, shepy <vladoseprak@...> wrote:
>>
>> >
>> > It looks like correlation inside parallel foreach is not supported by
>> ODE.
>> > Can anybody confirm this?
>> > --
>> > View this message in context:
>> > http://old.nabble.com/Correlation-in-foreach-tp26050377p26129778.html
>> > Sent from the Apache Ode User mailing list archive at Nabble.com.
>> >
>> >
>>
>
>

--
View this message in context: http://old.nabble.com/Correlation-in-foreach-tp26050377p26156622.html
Sent from the Apache Ode User mailing list archive at Nabble.com.

[V. Seprak]

And this is exactly what I did. I have added a property to my message which,
in first assign activity, I set to $Counter value. Then i correlate on this
property. This didn't help. When i start with clean ODE database then it
works, but only the first time process is executed. Every subsequent
invocation results with "duplicate key value violates unique constraint
bpel_selectors_correlation_key_key". I have noticed that ODE tries to insert
empty value as CORRELATION_KEY (BPEL_SELECTORS table). Something like "240~"
where it should insert "240~myCorrelationId".  


Alex Boisvert-3 wrote:

>
> Simply put, the way to resolve of this is to use a correlation set
> (nested)
> inside your <bpel:forEach> scope such that the correlation is unique to
> each
> instance of the <bpel:receive> activity.
>
> alex
>
>
> On Fri, Oct 30, 2009 at 12:40 PM, Karthick Sankarachary <
> sankarachary@...> wrote:
>
>> Using correlations inside of a parallel <forEach> activity might result
>> in
>> a
>> bpws:conflictingReceive, which the spec defines as follows:
>>
>> "If during the execution of a business process instance, two or more
>> receive
>> activities for the same partner link, portType, operation and correlation
>> set(s) are in fact simultaneously enabled, then the standard fault
>> bpws:conflictingReceive MUST be thrown by a compliant implementation."
>>
>> Off the top of my head, one way to work around this issue could be to
>> extend
>> the message variable that you're correlating on (via a <invoke> or
>> <receive>
>> activity, for instance), by adding a numeric property, say
>> "iterationNumber", which is set to the value of the <forEach> counterName
>> variable. That property basically acts as a discriminant between the
>> messages corresponding to different iterations. AFAIK, there is no
>> constraint in the spec per se that would allow us to implement this
>> feature
>> in the BPEL server.
>> Best Regards,
>> Karthick Sankarachary
>>
>>
>> On Fri, Oct 30, 2009 at 6:07 AM, shepy <vladoseprak@...> wrote:
>>
>> >
>> > It looks like correlation inside parallel foreach is not supported by
>> ODE.
>> > Can anybody confirm this?
>> > --
>> > View this message in context:
>> > http://old.nabble.com/Correlation-in-foreach-tp26050377p26129778.html
>> > Sent from the Apache Ode User mailing list archive at Nabble.com.
>> >
>> >
>>
>
>

--
View this message in context: http://old.nabble.com/Correlation-in-foreach-tp26050377p26156622.html
Sent from the Apache Ode User mailing list archive at Nabble.com.

[V. Seprak]

And this is exactly what I did. I have added a property to my message which,
in first assign activity, I set to $Counter value. Then i correlate on this
property. This didn't help. When i start with clean ODE database then it
works, but only the first time process is executed. Every subsequent
invocation results with "duplicate key value violates unique constraint
bpel_selectors_correlation_key_key". I have noticed that ODE tries to insert
empty value as CORRELATION_KEY (BPEL_SELECTORS table). Something like "240~"
where it should insert "240~myCorrelationId".  


Alex Boisvert-3 wrote:

>
> Simply put, the way to resolve of this is to use a correlation set
> (nested)
> inside your <bpel:forEach> scope such that the correlation is unique to
> each
> instance of the <bpel:receive> activity.
>
> alex
>
>
> On Fri, Oct 30, 2009 at 12:40 PM, Karthick Sankarachary <
> sankarachary@...> wrote:
>
>> Using correlations inside of a parallel <forEach> activity might result
>> in
>> a
>> bpws:conflictingReceive, which the spec defines as follows:
>>
>> "If during the execution of a business process instance, two or more
>> receive
>> activities for the same partner link, portType, operation and correlation
>> set(s) are in fact simultaneously enabled, then the standard fault
>> bpws:conflictingReceive MUST be thrown by a compliant implementation."
>>
>> Off the top of my head, one way to work around this issue could be to
>> extend
>> the message variable that you're correlating on (via a <invoke> or
>> <receive>
>> activity, for instance), by adding a numeric property, say
>> "iterationNumber", which is set to the value of the <forEach> counterName
>> variable. That property basically acts as a discriminant between the
>> messages corresponding to different iterations. AFAIK, there is no
>> constraint in the spec per se that would allow us to implement this
>> feature
>> in the BPEL server.
>> Best Regards,
>> Karthick Sankarachary
>>
>>
>> On Fri, Oct 30, 2009 at 6:07 AM, shepy <vladoseprak@...> wrote:
>>
>> >
>> > It looks like correlation inside parallel foreach is not supported by
>> ODE.
>> > Can anybody confirm this?
>> > --
>> > View this message in context:
>> > http://old.nabble.com/Correlation-in-foreach-tp26050377p26129778.html
>> > Sent from the Apache Ode User mailing list archive at Nabble.com.
>> >
>> >
>>
>
>

--
View this message in context: http://old.nabble.com/Correlation-in-foreach-tp26050377p26156622.html
Sent from the Apache Ode User mailing list archive at Nabble.com.

[V. Seprak]

And this is exactly what I did. I have added a property to my message which,
in first assign activity, I set to $Counter value. Then i correlate on this
property. This didn't help. When i start with clean ODE database then it
works, but only the first time process is executed. Every subsequent
invocation results with "duplicate key value violates unique constraint
bpel_selectors_correlation_key_key". I have noticed that ODE tries to insert
empty value as CORRELATION_KEY (BPEL_SELECTORS table). Something like "240~"
where it should insert "240~myCorrelationId".  


Alex Boisvert-3 wrote:

>
> Simply put, the way to resolve of this is to use a correlation set
> (nested)
> inside your <bpel:forEach> scope such that the correlation is unique to
> each
> instance of the <bpel:receive> activity.
>
> alex
>
>
> On Fri, Oct 30, 2009 at 12:40 PM, Karthick Sankarachary <
> sankarachary@...> wrote:
>
>> Using correlations inside of a parallel <forEach> activity might result
>> in
>> a
>> bpws:conflictingReceive, which the spec defines as follows:
>>
>> "If during the execution of a business process instance, two or more
>> receive
>> activities for the same partner link, portType, operation and correlation
>> set(s) are in fact simultaneously enabled, then the standard fault
>> bpws:conflictingReceive MUST be thrown by a compliant implementation."
>>
>> Off the top of my head, one way to work around this issue could be to
>> extend
>> the message variable that you're correlating on (via a <invoke> or
>> <receive>
>> activity, for instance), by adding a numeric property, say
>> "iterationNumber", which is set to the value of the <forEach> counterName
>> variable. That property basically acts as a discriminant between the
>> messages corresponding to different iterations. AFAIK, there is no
>> constraint in the spec per se that would allow us to implement this
>> feature
>> in the BPEL server.
>> Best Regards,
>> Karthick Sankarachary
>>
>>
>> On Fri, Oct 30, 2009 at 6:07 AM, shepy <vladoseprak@...> wrote:
>>
>> >
>> > It looks like correlation inside parallel foreach is not supported by
>> ODE.
>> > Can anybody confirm this?
>> > --
>> > View this message in context:
>> > http://old.nabble.com/Correlation-in-foreach-tp26050377p26129778.html
>> > Sent from the Apache Ode User mailing list archive at Nabble.com.
>> >
>> >
>>
>
>

--
View this message in context: http://old.nabble.com/Correlation-in-foreach-tp26050377p26156622.html
Sent from the Apache Ode User mailing list archive at Nabble.com.

[V. Seprak]

And this is exactly what I did. I have added a property to my message which,
in first assign activity, I set to $Counter value. Then i correlate on this
property. This didn't help. When i start with clean ODE database then it
works, but only the first time process is executed. Every subsequent
invocation results with "duplicate key value violates unique constraint
bpel_selectors_correlation_key_key". I have noticed that ODE tries to insert
empty value as CORRELATION_KEY (BPEL_SELECTORS table). Something like "240~"
where it should insert "240~myCorrelationId".  


Alex Boisvert-3 wrote:

>
> Simply put, the way to resolve of this is to use a correlation set
> (nested)
> inside your <bpel:forEach> scope such that the correlation is unique to
> each
> instance of the <bpel:receive> activity.
>
> alex
>
>
> On Fri, Oct 30, 2009 at 12:40 PM, Karthick Sankarachary <
> sankarachary@...> wrote:
>
>> Using correlations inside of a parallel <forEach> activity might result
>> in
>> a
>> bpws:conflictingReceive, which the spec defines as follows:
>>
>> "If during the execution of a business process instance, two or more
>> receive
>> activities for the same partner link, portType, operation and correlation
>> set(s) are in fact simultaneously enabled, then the standard fault
>> bpws:conflictingReceive MUST be thrown by a compliant implementation."
>>
>> Off the top of my head, one way to work around this issue could be to
>> extend
>> the message variable that you're correlating on (via a <invoke> or
>> <receive>
>> activity, for instance), by adding a numeric property, say
>> "iterationNumber", which is set to the value of the <forEach> counterName
>> variable. That property basically acts as a discriminant between the
>> messages corresponding to different iterations. AFAIK, there is no
>> constraint in the spec per se that would allow us to implement this
>> feature
>> in the BPEL server.
>> Best Regards,
>> Karthick Sankarachary
>>
>>
>> On Fri, Oct 30, 2009 at 6:07 AM, shepy <vladoseprak@...> wrote:
>>
>> >
>> > It looks like correlation inside parallel foreach is not supported by
>> ODE.
>> > Can anybody confirm this?
>> > --
>> > View this message in context:
>> > http://old.nabble.com/Correlation-in-foreach-tp26050377p26129778.html
>> > Sent from the Apache Ode User mailing list archive at Nabble.com.
>> >
>> >
>>
>
>

--
View this message in context: http://old.nabble.com/Correlation-in-foreach-tp26050377p26156622.html
Sent from the Apache Ode User mailing list archive at Nabble.com.