Skip to main content
T
tarunb0231
January 12, 2023
Question

Organising rules in an application

  • January 12, 2023
  • 8 replies
  • 0 views

Hi all

I want to hear some of the ways you guys organise the rules in an application in general or as a best practice.

For example, an application involving a couple of hundred rules would be hard to manage and understand for someone new to it. I've thought of organising rules in their dedicated folders by their feature/record type. I want to know what other patterns the community follows for better organising their rules?

    8 replies

    csteward
    csteward
    January 12, 2023

    Since developers don't see rules in the application based on a folder hierarchy, I'm not sure this would provide much benefit.  We just push for standard, logical naming conventions with an application prefix, and generally I will create objects something like below.  One of the current applications I'm working on contains 525 objects with 190 of those being expression rules, with them named properly (with DESCRIPTIONS!) I don't have much issue finding what I need.  Typically as well, I'm working through an interface or process model which shows me which rule(s) it's calling in the areas I'm updating anyway, and I can drill into them from there, vs blindly searching rules to update in /design.  

    /* Interfaces */

    rule!APP_formSubmit()

    rule!APP_formApprove()

    rule!APP_reportAdmin()

    /* expression rules */

    rule!APP_isViewer()

    rule!APP_isAdmin()

    rule!APP_getDataByUser()

    rule!APP_getDataById()

    /* constants */

    cons!APP_DS_REQUEST_DATA

    cons!APP_DS_CONTRACT_LOOKUP

    cons!APP_RUN_DAILY_NOTICE

    cons!APP_LINK_TRAINING

    ..etc.

    T
    tarunb0231Author
    January 13, 2023

    Right.. I was drawing some parallels to java packages with folders. Actually using folder structure will only help with hierarchical view which I guess isn't that great in the product currently. Also the object search doesn't really tell us which folder the object is from.

    While updating existing rules is an easy one. Building new ones by referring existing ones in them require some work. I think expression editor could use some enhancement for suggestion UI show what kind of rules are being listed (Different kind of rules can have same name) - which can be overcome probably with the rules naming convention.. 

    It appears rule naming is the only way. 

    davel001150
    davel001150
    January 13, 2023

    You can also organize by functions.  Dashboards get their own folder, forms get their own folder, utility expressions get a folder, query entity expressions almost definitely get their own folder, reusable ui components could get their own folder.

    It's really a matter of personal preference.  Some get by with naming conventions and all lumped into the same few folders.

    In general, at a minimum, I like to do Constants, Expressions, Queries, and SAIL.  "Interface" has two meanings, so I like to be explicit.

    T
    tarunb0231Author
    January 13, 2023

    Yes.. I'm all for organising using folders. That would automatically be a better laid out project. If Appian could also include which folder a rule came from during object search and code prompts, I guess that would make a difference in developer experience.

    csteward
    csteward
    January 18, 2023

    What I'd like to have rather than organization by folders would be the ability to tag, or add metadata to objects.  Foldering is too restrictive, being that objects can only reside in one folder, and browsing folder by folder can be cumbersome.  If you've seen technology like SharePoint grow over the years, best practice there is to nix the old way of massive folder structures for documents and flatten things out, adding metadata to objects, making organization and searching much, much cleaner.

    Terms & ConditionsAccessibility statement