Hello Suraj,
On your project case, your suggest is a good way to solve quickly your
constraint, but you also create a second service that call the first
that negate the result.
* isSalesOrder
* isNotSalesOrder
After I'm more in favor to refactoring all conditions on seca and eeca
to follow the same pattern present on screen condition that would be
manage your case and some other currently not possible, and by the way
realign how define a condition.
Nicolas
On 04/02/2021 10:47, Suraj Khurana wrote:
> Hello folks,
>
> Hope you are doing good.
>
> Recently we encountered a client's requirement which led us to have two
> separate condition-services with exact same code but opposite output. In
> one case true and false for another.
>
> We can enhance existing behaviour by having one more attribute in the
> seca/eeca rule.
> As currently by default, the result expected from condition-service is
> always true. We can provide its control to the developer.
> For eg.
> <condition-service service-name="isSalesOrder" *boolean-field="true */*
> false"*/>
>
> This boolean-field will illustrate the expected boolean result from the
> available conditionReply result field in the defined condition-service. In
> this manner we give more control to developers and reduce duplicacy of code.
>
> Please share your thoughts on this.
>
> --
> Best Regards,
> Suraj Khurana
> Senior Technical Consultant
>
Locked
