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?
Discussion posts and replies are publicly visible
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.
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.
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.
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.
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.
Following on from this...having (and enforcing) naming standards for your objects would help a lot...having a pattern such as:
<APP_PREFIX><OBJECT_SUB_TYPE><OBJECT_NAME>
e.g. for a top-level Interface object for an Application that has a Prefix of ABC and is the Summary view on the Customner record:
ABC_IF_summaryViewCustomer
...so having a scheme that works left-to-right from the broadest to the most specific context will go a long way to helping you find the thing you're looking for...
Chris said:What I'd like to have rather than organization by folders would be the ability to tag
This makes sense too. However, tagging should be properly organized and reviewed. As we have seen overtime, developers would either create their own tags (tag hell) or ignore tagging altogether.
An advantage with folders would be they would have to place the rule in "some" folder that is appropriate and can be easily reviewed. And I guess a properly reviewed rule would be rarely moved out of a folder if ever.
My affinity towards folders was based on inference from how things are organized in other technologies.. like package(folder) based structure in java, component wise folder based structure in frontend MVC frameworks such as Angular, React etc. Key aspect for me would be to have an organizing structure/foundation that do not get ignored or become too complicated over time.
Stewart Burchell said:Following on from this...having (and enforcing) naming standards for your objects would help a lot
Agree.
Taking this a bit further, "rule!" can be further divided into "decision!", "interface!", "integration!" etc. That way, we know what we are calling and smart prompt can be a bit more relevant in what it shows.
Also, object search (I do not know if this is supported yet) can include rule type in the search as well.
E.g. "Interface car" can show all the interface rules that has the keyword car in it.