Skip to main content
W
weiliml1795
May 9, 2024
Question

Best practice for common rule override

  • May 9, 2024
  • 8 replies
  • 1 view

hi,

My team wanted to build a common library/application i.e. Global_CaseManagement where the application will be exported to 2 instances for 2 regions to share (similar to a common library), i.e. UK_Bank  and US_Bank.
Let's name the rule as rule!Global_GetNextCase which used within a node by a common global process model namely ACTION - Get Next Case

Given the rule Global_GetNextCase will have different logic for UK and US, what would be the recommended way to do the common rule override?

The dependency graph as below :
1. Global (application) -> ACTION - Get Next Case -> rule!Global_GetNextCase -> rule!Global_GetNextCase_UK
2. Global (application) -> ACTION - Get Next Case -> rule!Global_GetNextCase -> rule!Global_GetNextCase_US

This way will create a problem where both UK and US rules will be imported into the instances respectively causing unwanted dependency issue, cause UK only needs Global_GetNextCase_UK while US only needs Global_GetNextCase_US


Another method by using local!result: getrulereferencebyname("rule!Global_GetNextCase_" & cons!region) where this way will resolve the unwanted dependency issue, but it will be dynamically calling the expression rule, we are thinking this might not be the best practice since the dependency cannot be traced.

Any suggestion on the best practice?

8 replies

mikes0011
mikes0011
Brainy
May 9, 2024

Possibly the best solution I've seen where you want to avoid porting cross-application dependencies around to relatively-unrelated instances is to set up API calls for each specific environment.  So basically instead of calling a rule by name (not really a good practice even at the best of times, and super vulnerable to things like renaming and version issues), you'd refernce an API endpoint (stored as text in a constant or something) and call the relevant Web API which then passes back the info you want.

W
weiliml1795Author
May 9, 2024

hi mike, thanks for helping. Web API could be an alternative, what if we have hundreds of environmental overrule required for the expression rules or interfaces in the Global application for 2 countries, is having hundreds of Web API a doable plan as suggested? 

Allow me to let me rephrase my question, both UK/US instances will be using the same Global application, just that within the node (expression rule) of the shared Global process model/parent expression rule, each country might have different logic in the implementation, hence overrule is required. The goal is to share the common utility/expression rule/interface as much as possible while allowing overrule for some of the precedence/child expression rules.

stefanhelzle0001
stefanhelzle0001
May 10, 2024

Appian supports passing references to expressions. So when calling such an expression, you could implement generic stuff directly in that expression. For local stuff, you could call an expression that returns a rule reference based on some conditions. Then evaluate that reference passing data based on a fixed interface contract.

I describe this in my blog post: https://appian.rocks/2022/09/19/building-customisable-components/

For expressions, this should work, for processes, you would need a comparable concept. The "Start Process" node can start any process based on the model id. A decision table can be used to implement a dispatching logic.

richardm900458
richardm900458
May 12, 2024

Hello weiliml,
Is there any deeper logic in Global_GetNextCase that you need as it sounds that specific UK and US rule is verwriting the global rule totally?
or are there any specific parts?

i feels like, you create here a scientific approach you dont need. it feels way over complicated

Whats about the good old "if" ? If(ri!region = US,....,....) if(ri!region=UK,...,...)
ri region comes from a decision table used in a script node if the respective process modell. So you can even track in the vairblae monitoring of a process instance if the right region was selected.  

Terms & ConditionsAccessibility statement