Suraj/Nicolas, IMO, There is no need to extend/override an ECA rule. ECA like we want to trigger something conditionally and it happens once we establish the rule. We can change the rule, and we are doing that frequently as per our custom requirement and we have calls to disable sometimes when required.
+1 for having condition-service tag, it should be useful for adding more proper conditions for running EECAs. Thanks! Rishi Solanki Sr Manager, Enterprise Software Development HotWax Systems Pvt. Ltd. Direct: +91-9893287847 http://www.hotwaxsystems.com www.hotwax.co On Sat, Feb 10, 2018 at 6:12 PM, Suraj Khurana < suraj.khur...@hotwaxsystems.com> wrote: > Hi Nicolas, > > I think there is a confusion here. > I am trying to find the reason why condition-service have not been > implemented for ecas? > I there is no such reason, I propose we should have a similar concept for > ecas as well. > So that we can write something like: > > <eca entity="OrderHeader" operation="create-store" event="return"> > <condition field-name="statusId" operator="equals" > value="ORDER_COMPLETED"/> > <condition field-name="needsInventoryIssuance" operator="equals" > value="Y"/> > <condition-service service-name="checkForSomeCondition"/> > <action service="issueImmediatelyFulfilledOrder" mode="sync"/> > </eca> > > Here, checkForSomeCondition service must return true to proceed for > issueImmediatelyFulfilledOrder. > HTH. > > -- > Thanks and Regards, > *Suraj Khurana* | Sr. Enterprise Software Engineer > *HotWax Commerce* by *HotWax Systems* > Plot no. 80, Scheme no. 78, Vijay Nagar, Indore, M.P. India 452010 > > On Sat, Feb 10, 2018 at 1:35 PM, Nicolas Malin <nicolas.ma...@nereide.fr> > wrote: > > > Hello Suraj, > > > > Currently I see no possibility to override an eca because definitions are > > all loaded and we can have exactly two identical definition with > different > > action. In this case difficult to spot the eca to disable/improve. > > > > So before try to override an eca I suggest to implement an identification > > like : > > > > <eca entity="FinAccountTrans" operation="create-store" event="return" > > package="org.apache.ofbiz.accounting" > id="FinAccountTransBalanceUpda > > te"> > > <condition field-name="statusId" operator="equals" > > value="FINACT_TRNS_APPROVED"/> > > <action service="updateFinAccountBalancesFromTrans" > mode="sync"/> > > </eca> > > > > and after we would implement a new element as flying idea : > > <extend-eca package="org.apache.ofbiz.accounting" > > id="FinAccountTransBalanceUpdate"> > > <add> > > <condition field-name="finAccountTrans" operator="contians" > > value="LOVE"/> > > </add> > > </extend-eca> > > or > > <extend-eca package="org.apache.ofbiz.accounting" > > id="FinAccountTransBalanceUpdate"><disable/></extend-eca> > > or > > <extend-eca package="org.apache.ofbiz.accounting" > > id="FinAccountTransBalanceUpdate"> > > <replace> > > <condition field-name="finAccountTrans" operator="contians" > > value="LOVE"/> > > <action service="updateFinAccountLove" mode="sync"/> > > <replace/> > > </extend-eca> > > > > Nicolas > > > > > > > > On 09/02/2018 14:01, Suraj Khurana wrote: > > > >> Hello, > >> > >> What is the best way to override entity eca definition? > >> Suppose you need to add a condition-service as well in eca, as far as I > >> can > >> check, currently, there is no way to handle condition service in eca > rule. > >> > >> IMO, this could be interesting to have this thing, is it intentional > that > >> we do this only for seca rules and not for eca's? > >> > >> Please share your thoughts on this. > >> -- > >> Thanks and Regards, > >> *Suraj Khurana* | Omnichannel OMS Technical Expert > >> *HotWax Commerce* by *HotWax Systems* > >> Plot no. 80, Scheme no. 78, Vijay Nagar, Indore, M.P. India 452010 > >> > >> > > >
