quickShipEntireOrder problems

[Hansen]

Hi,

I am using release4.0 and am having the following problems in
quickShipEntireOrder.

1. An order complete email is sent even if payment capture failed.

2. An order complete email is sent with status as "Approved" instead of
"Complete" even when the service succeeded.

The following is the related eca relating to the order complete email.

    <eca service="changeOrderStatus" event="commit" run-on-error="false">
        <condition field-name="statusId" operator="equals"
value="ORDER_COMPLETED"/>
        <condition-field field-name="statusId" operator="not-equals"
to-field-name="oldStatusId"/>
        <action service="resetGrandTotal" mode="sync"/>
        <action service="sendOrderCompleteNotification" mode="async"
persist="true"/>
    </eca>

Based on this eca, sendOrderCompleteNotification should not even be invoked
if changeOrderStatus failed because it is invoked before the commit of the
transaction and the transaction should be marked as rollback.

Problem #2 seems to do with database concurrent accessing. The problem is
that when the eca is invoked, it is comparing the status from the parameter.
However, sendOrderCompleteNotification is accessing the data (order status)
from the database. It is possible that sendOrderCompleteNotification is
commited before changeOrderStatus and in that case it will read the old
status (which is the behaviour of read committed).

So my questions are why #1 happened? Is #2 an expected hahaviour and how can
it be improved in a robust way?

Thanks,
Hansen

[Jacques Le Roux]

I did not check any details but

1) If payment capture fails is the changeOrderStatus rolled back ? If not it's a normal behaviour and you should try to add a
condition-field related to payment capture.
1') As I said I did not look into details but if the payment capture is part of a global transaction which includes both
changeOrderStatus and payment capture you could try "global-commit" instead of "commit"
2) Is this happening only when payment capture fails ?

Jacques

From: "Hansen Wang" <[hidden email]>

> Hi,
>
> I am using release4.0 and am having the following problems in
> quickShipEntireOrder.
>
> 1. An order complete email is sent even if payment capture failed.
>
> 2. An order complete email is sent with status as "Approved" instead of
> "Complete" even when the service succeeded.
>
> The following is the related eca relating to the order complete email.
>
>    <eca service="changeOrderStatus" event="commit" run-on-error="false">
>        <condition field-name="statusId" operator="equals"
> value="ORDER_COMPLETED"/>
>        <condition-field field-name="statusId" operator="not-equals"
> to-field-name="oldStatusId"/>
>        <action service="resetGrandTotal" mode="sync"/>
>        <action service="sendOrderCompleteNotification" mode="async"
> persist="true"/>
>    </eca>
>
> Based on this eca, sendOrderCompleteNotification should not even be invoked
> if changeOrderStatus failed because it is invoked before the commit of the
> transaction and the transaction should be marked as rollback.
>
> Problem #2 seems to do with database concurrent accessing. The problem is
> that when the eca is invoked, it is comparing the status from the parameter.
> However, sendOrderCompleteNotification is accessing the data (order status)
> from the database. It is possible that sendOrderCompleteNotification is
> commited before changeOrderStatus and in that case it will read the old
> status (which is the behaviour of read committed).
>
> So my questions are why #1 happened? Is #2 an expected hahaviour and how can
> it be improved in a robust way?
>
> Thanks,
> Hansen
>

[Hansen]

1. Yes. The transaction is rolled back.
1'. Yes. The global transaction include many services and one of them is
changeOrderStatus.
2. No. This can happen regardless whether the capture fails or not. This
happens for 1 out of 50 orders in my server. I have a work-around to include
code to check the order status in sendOrderCompleteNotice. If the order
status is not Completed, then it will log the information and do not send
the email.

The following will further explain what I am doing. I wrote a massShipOrders
services which process a batch input file with three columns (orderId,
trackingNumber, shippingMethod, shipGroupSeqId). This service iterate each
line of the input file and invoke gemmallQuickShipOrder which is a service
group. Please note that massShipOrders does not use transaction because the
failure of one record should not affect the rest.

I have further question regarding to your reply. Isn't that "global-commit"
and "commit" are the same, regardless the number of services invoked, if
there is only one transaction? Please clarify as I was not able to find out
related information from the docs.

These are the related services mentioned.

    <service name="gemmallQuickShipOrder" engine="group"
use-transaction="true" auth="true">
        <group name="gemmallQuickShipOrder">
            <invoke name="updateOrderItemShipGroup" mode="sync"/>
            <invoke name="updateTrackingNumber" mode="sync"/>
            <invoke name="quickShipEntireOrder" mode="sync"/>
        </group>
    </service>

    <service name="massShipOrders" engine="java" use-transaction="false"
            location="org.ofbiz.order.order.OrderServices"
invoke="massShipOrders" auth="true">
    </service>

Thanks
Hansen

On Mon, Mar 9, 2009 at 11:20 AM, Jacques Le Roux <
[hidden email]> wrote:

> I did not check any details but
>
> 1) If payment capture fails is the changeOrderStatus rolled back ? If not
> it's a normal behaviour and you should try to add a condition-field related
> to payment capture.
> 1') As I said I did not look into details but if the payment capture is
> part of a global transaction which includes both changeOrderStatus and
> payment capture you could try "global-commit" instead of "commit"
> 2) Is this happening only when payment capture fails ?
>
> Jacques
>
> From: "Hansen Wang" <[hidden email]>
>
>  Hi,
>>
>> I am using release4.0 and am having the following problems in
>> quickShipEntireOrder.
>>
>> 1. An order complete email is sent even if payment capture failed.
>>
>> 2. An order complete email is sent with status as "Approved" instead of
>> "Complete" even when the service succeeded.
>>
>> The following is the related eca relating to the order complete email.
>>
>>   <eca service="changeOrderStatus" event="commit" run-on-error="false">
>>       <condition field-name="statusId" operator="equals"
>> value="ORDER_COMPLETED"/>
>>       <condition-field field-name="statusId" operator="not-equals"
>> to-field-name="oldStatusId"/>
>>       <action service="resetGrandTotal" mode="sync"/>
>>       <action service="sendOrderCompleteNotification" mode="async"
>> persist="true"/>
>>   </eca>
>>
>> Based on this eca, sendOrderCompleteNotification should not even be
>> invoked
>> if changeOrderStatus failed because it is invoked before the commit of the
>> transaction and the transaction should be marked as rollback.
>>
>> Problem #2 seems to do with database concurrent accessing. The problem is
>> that when the eca is invoked, it is comparing the status from the
>> parameter.
>> However, sendOrderCompleteNotification is accessing the data (order
>> status)
>> from the database. It is possible that sendOrderCompleteNotification is
>> commited before changeOrderStatus and in that case it will read the old
>> status (which is the behaviour of read committed).
>>
>> So my questions are why #1 happened? Is #2 an expected hahaviour and how
>> can
>> it be improved in a robust way?
>>
>> Thanks,
>> Hansen
>>
>>
>
>

[Jacques Le Roux]

From: "Hansen Wang" <[hidden email]>

> 1. Yes. The transaction is rolled back.
> 1'. Yes. The global transaction include many services and one of them is
> changeOrderStatus.
> 2. No. This can happen regardless whether the capture fails or not. This
> happens for 1 out of 50 orders in my server. I have a work-around to include
> code to check the order status in sendOrderCompleteNotice. If the order
> status is not Completed, then it will log the information and do not send
> the email.
>
> The following will further explain what I am doing. I wrote a massShipOrders
> services which process a batch input file with three columns (orderId,
> trackingNumber, shippingMethod, shipGroupSeqId). This service iterate each
> line of the input file and invoke gemmallQuickShipOrder which is a service
> group. Please note that massShipOrders does not use transaction because the
> failure of one record should not affect the rest.
>
> I have further question regarding to your reply. Isn't that "global-commit"
> and "commit" are the same, regardless the number of services invoked, if
> there is only one transaction? Please clarify as I was not able to find out
> related information from the docs.

that "global-commit" and "commit" are not the same.
If you build a process which includes services in a sole transactionn, the condition using global-commit event for a particular SECA
will only be satisfied iff the (global) transaction succed. This could be a way for you to wrap all your related services in one
transaction to be sure that only if all services succeed (which is approximatively the same than the transaction succeed) a
particular SECA would be activated.

Also about use-transaction="false", note that even if the service does not use its own transaction it can be embedded in (an)other
surrounding transaction(s). Though even if it's embeded it will not commit, but , and this is a bit surprising, it will anyway end,
and this will activate any corresponding condition in SECAs using commit as event.

HTH

Jacques

> These are the related services mentioned.
>
>    <service name="gemmallQuickShipOrder" engine="group"
> use-transaction="true" auth="true">
>        <group name="gemmallQuickShipOrder">
>            <invoke name="updateOrderItemShipGroup" mode="sync"/>
>            <invoke name="updateTrackingNumber" mode="sync"/>
>            <invoke name="quickShipEntireOrder" mode="sync"/>
>        </group>
>    </service>
>
>    <service name="massShipOrders" engine="java" use-transaction="false"
>            location="org.ofbiz.order.order.OrderServices"
> invoke="massShipOrders" auth="true">
>    </service>
>
> Thanks
> Hansen
>
> On Mon, Mar 9, 2009 at 11:20 AM, Jacques Le Roux <
> [hidden email]> wrote:
>
>> I did not check any details but
>>
>> 1) If payment capture fails is the changeOrderStatus rolled back ? If not
>> it's a normal behaviour and you should try to add a condition-field related
>> to payment capture.
>> 1') As I said I did not look into details but if the payment capture is
>> part of a global transaction which includes both changeOrderStatus and
>> payment capture you could try "global-commit" instead of "commit"
>> 2) Is this happening only when payment capture fails ?
>>
>> Jacques
>>
>> From: "Hansen Wang" <[hidden email]>
>>
>>  Hi,
>>>
>>> I am using release4.0 and am having the following problems in
>>> quickShipEntireOrder.
>>>
>>> 1. An order complete email is sent even if payment capture failed.
>>>
>>> 2. An order complete email is sent with status as "Approved" instead of
>>> "Complete" even when the service succeeded.
>>>
>>> The following is the related eca relating to the order complete email.
>>>
>>>   <eca service="changeOrderStatus" event="commit" run-on-error="false">
>>>       <condition field-name="statusId" operator="equals"
>>> value="ORDER_COMPLETED"/>
>>>       <condition-field field-name="statusId" operator="not-equals"
>>> to-field-name="oldStatusId"/>
>>>       <action service="resetGrandTotal" mode="sync"/>
>>>       <action service="sendOrderCompleteNotification" mode="async"
>>> persist="true"/>
>>>   </eca>
>>>
>>> Based on this eca, sendOrderCompleteNotification should not even be
>>> invoked
>>> if changeOrderStatus failed because it is invoked before the commit of the
>>> transaction and the transaction should be marked as rollback.
>>>
>>> Problem #2 seems to do with database concurrent accessing. The problem is
>>> that when the eca is invoked, it is comparing the status from the
>>> parameter.
>>> However, sendOrderCompleteNotification is accessing the data (order
>>> status)
>>> from the database. It is possible that sendOrderCompleteNotification is
>>> commited before changeOrderStatus and in that case it will read the old
>>> status (which is the behaviour of read committed).
>>>
>>> So my questions are why #1 happened? Is #2 an expected hahaviour and how
>>> can
>>> it be improved in a robust way?
>>>
>>> Thanks,
>>> Hansen
>>>
>>>
>>
>>
>

[Hansen]

Thanks for the help. I will play around the code and check the difference. I
will reply with my findings to update this thread.

On Mon, Mar 9, 2009 at 3:10 PM, Jacques Le Roux <
[hidden email]> wrote:

> From: "Hansen Wang" <[hidden email]>
>
>> 1. Yes. The transaction is rolled back.
>> 1'. Yes. The global transaction include many services and one of them is
>> changeOrderStatus.
>> 2. No. This can happen regardless whether the capture fails or not. This
>> happens for 1 out of 50 orders in my server. I have a work-around to
>> include
>> code to check the order status in sendOrderCompleteNotice. If the order
>> status is not Completed, then it will log the information and do not send
>> the email.
>>
>> The following will further explain what I am doing. I wrote a
>> massShipOrders
>> services which process a batch input file with three columns (orderId,
>> trackingNumber, shippingMethod, shipGroupSeqId). This service iterate each
>> line of the input file and invoke gemmallQuickShipOrder which is a service
>> group. Please note that massShipOrders does not use transaction because
>> the
>> failure of one record should not affect the rest.
>>
>> I have further question regarding to your reply. Isn't that
>> "global-commit"
>> and "commit" are the same, regardless the number of services invoked, if
>> there is only one transaction? Please clarify as I was not able to find
>> out
>> related information from the docs.
>>
>
> that "global-commit" and "commit" are not the same.
> If you build a process which includes services in a sole transactionn, the
> condition using global-commit event for a particular SECA will only be
> satisfied iff the (global) transaction succed. This could be a way for you
> to wrap all your related services in one transaction to be sure that only if
> all services succeed (which is approximatively the same than the transaction
> succeed) a particular SECA would be activated.
>
> Also about use-transaction="false", note that even if the service does not
> use its own transaction it can be embedded in (an)other surrounding
> transaction(s). Though even if it's embeded it will not commit, but , and
> this is a bit surprising, it will anyway end, and this will activate any
> corresponding condition in SECAs using commit as event.
>
> HTH
>
> Jacques
>
>
>  These are the related services mentioned.
>>
>>   <service name="gemmallQuickShipOrder" engine="group"
>> use-transaction="true" auth="true">
>>       <group name="gemmallQuickShipOrder">
>>           <invoke name="updateOrderItemShipGroup" mode="sync"/>
>>           <invoke name="updateTrackingNumber" mode="sync"/>
>>           <invoke name="quickShipEntireOrder" mode="sync"/>
>>       </group>
>>   </service>
>>
>>   <service name="massShipOrders" engine="java" use-transaction="false"
>>           location="org.ofbiz.order.order.OrderServices"
>> invoke="massShipOrders" auth="true">
>>   </service>
>>
>> Thanks
>> Hansen
>>
>> On Mon, Mar 9, 2009 at 11:20 AM, Jacques Le Roux <
>> [hidden email]> wrote:
>>
>>  I did not check any details but
>>>
>>> 1) If payment capture fails is the changeOrderStatus rolled back ? If not
>>> it's a normal behaviour and you should try to add a condition-field
>>> related
>>> to payment capture.
>>> 1') As I said I did not look into details but if the payment capture is
>>> part of a global transaction which includes both changeOrderStatus and
>>> payment capture you could try "global-commit" instead of "commit"
>>> 2) Is this happening only when payment capture fails ?
>>>
>>> Jacques
>>>
>>> From: "Hansen Wang" <[hidden email]>
>>>
>>>  Hi,
>>>
>>>>
>>>> I am using release4.0 and am having the following problems in
>>>> quickShipEntireOrder.
>>>>
>>>> 1. An order complete email is sent even if payment capture failed.
>>>>
>>>> 2. An order complete email is sent with status as "Approved" instead of
>>>> "Complete" even when the service succeeded.
>>>>
>>>> The following is the related eca relating to the order complete email.
>>>>
>>>>  <eca service="changeOrderStatus" event="commit" run-on-error="false">
>>>>      <condition field-name="statusId" operator="equals"
>>>> value="ORDER_COMPLETED"/>
>>>>      <condition-field field-name="statusId" operator="not-equals"
>>>> to-field-name="oldStatusId"/>
>>>>      <action service="resetGrandTotal" mode="sync"/>
>>>>      <action service="sendOrderCompleteNotification" mode="async"
>>>> persist="true"/>
>>>>  </eca>
>>>>
>>>> Based on this eca, sendOrderCompleteNotification should not even be
>>>> invoked
>>>> if changeOrderStatus failed because it is invoked before the commit of
>>>> the
>>>> transaction and the transaction should be marked as rollback.
>>>>
>>>> Problem #2 seems to do with database concurrent accessing. The problem
>>>> is
>>>> that when the eca is invoked, it is comparing the status from the
>>>> parameter.
>>>> However, sendOrderCompleteNotification is accessing the data (order
>>>> status)
>>>> from the database. It is possible that sendOrderCompleteNotification is
>>>> commited before changeOrderStatus and in that case it will read the old
>>>> status (which is the behaviour of read committed).
>>>>
>>>> So my questions are why #1 happened? Is #2 an expected hahaviour and how
>>>> can
>>>> it be improved in a robust way?
>>>>
>>>> Thanks,
>>>> Hansen
>>>>
>>>>
>>>>
>>>
>>>
>>
>
>