Skip to main content
udhayak0001
December 2, 2021
Question

Expression rule

  • December 2, 2021
  • 11 replies
  • 0 views

Hi All,

I just need to know which one is the best practice

1)creating an expression rule to fetch the data and creating another rule to manipulate the retrieved data

2) using same expression rule for both things

    11 replies

    csteward
    December 2, 2021

    I've used both methods - I prefer to separate but sometimes is not necessary.  If the rule to fetch raw data might be used in another location, separate it out from the manipulation rule.  If the rule is very specific to get/manipulate data, will unlikely be used in another location, might be fine to combine.

    I will typically separate them out regardless however for ease of maintenance, etc.  Just can't say I've always separated them :)

    Compartmentalizing your code functions is typically best practice.

    udhayak0001
    December 2, 2021

    Thank you chris

    stewart.burchell
    December 3, 2021

    The answer lies in whether you think the fetch of the data needs to be re-used in other contexts or you will always use the manipulated version of the fetched data.

    udhayak0001
    December 3, 2021

    Does creating more objects impact the application performance .i can create one expression rule and make use of it wherever i want (expression rule will be complex )  or i can create multiple expression rules to make the code more easily understandable. which way i should follow as best practice

    stewart.burchell
    December 3, 2021

    The performance overhead (which essentially can be attributed to passing pointers to the data you're processing) will be minimal. The benefit from "creating more objects" will only be reaped if those objects are well encapsulated and have high "cohesion" and low "coupling".

    December 7, 2021

    First of all appian should not be used to manipulate or play with data as this is not the best practice . it would be great if it is done from DB side and then fetch the manipulated data.