Question on expected behavior when mapping rule parameters while calling sub-interface

Sidhant Behura over 8 years ago

#UserInterface
Hi All, I was designing a form where I came across this new or different behavior which I suspect to be a bug. This is related to the mapping of the rule parameters while calling a sub-interface.

I have 2 interfaces, one parent interface(TEST_Interface1) and one sub-interface(TEST_Interface2).
TEST_Interface1 contains two rule inputs : varA (Text) and varB (Text).
TEST_Interface2 contains two rule inputs : varA (Text) and varB (Text).

TEST_Interface2 contains 2 text fields using which I initialize the rule inputs varA and varB.
In TEST_Interface1, I am calling TEST_Interface2 and below goes the code snippet:
rule!TEST_Interface2(
varA: ri!varB,           /* Mapping varA in TEST_Interface2 to varB TEST_Interface1 */
varB: ri!varA                    /* Mapping varB in TEST_Interface2 to varA TEST_Interface1 */
),
          a!textField(          /* Displaying the changed variable value */
label: "Variable A",
labelPosition: "ADJ...

Additional Info.zip

Discussion posts and replies are publicly visible

0 Sidhant Behura over 8 years ago

...ACENT",
value: ri!varA,
readOnly: true
),
a!textField( /* Displaying the changed variable value */
label: "Variable B",
labelPosition: "ADJACENT",
value: ri!varB,
readOnly: true
)
---------------------------------
In TEST_Interface2:
a!textField(
label: "Enter Value for Variable A",
value: ri!varA,
saveInto: {
a!save(ri!varA,save!value)
}
),
a!textField(
label: "Enter Value for Variable B",
value: ri!varB,
saveInto: {
a!save(ri!varB,save!value)
}
)
While mapping the parameters, I am mapping varB to varA and vice versa.
In this case, it doesn't consider the parameter mapping which I have specified(i.e varA(TEST_Interface1) --> varB(TEST_Interface2) and varB(TEST_Interface1) --> varA(TEST_Interface2)).

Instead it is mapping varA(TEST_Interface1) to varA (TEST_Interface2) and varB(TEST_Interface1) to varB(TEST_Interface2).

But if I change the variable names i.e 4 distinct variable name...
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 Sidhant Behura over 8 years ago

...s then it works fine.

It might be a little bit confusing, so attaching code snippets and screenshots. Please refer them for more clarity.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 Sidhant Behura over 8 years ago

As per my knowledge, this is an unexpected behavior. Please correct me if I am wrong.
SAIL is being used, and this behavior is found on Appian 16.1.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 PhilB
Certified Lead Developer
over 8 years ago

I think you've answered your own question - the behaviour you're seeing is because the rule inputs of the main rule and sub-rule overlap.

The documentation here - forum.appian.com/.../Interfaces.html - says "Input names are case insensitive and must be unique within a given interface." which is a strong argument for it being unexpected as there's no mention of rule inputs across interfaces.

I'd suggest you raise a support case.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 Stefan Helzle
A Score Level 3
over 8 years ago

I did some small tests and agree that this is not what I expect. It looks like there is only one global variable scope for the whole execution of the expressions. I thought that local variables defined as ri or in with()/load() are truly local.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 Mike Schmitt
Certified Lead Developer
over 8 years ago

Neither of your screenshots seem to show the incorrect behavior you're describing, and I'm having a hard time figuring it out based on just what you've written - can you post some additional description of 1) what exactly you're doing, 2) what you'd expect to see, and 3) what you're actually seeing?
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 Mike Schmitt
Certified Lead Developer
over 8 years ago

@stefan: AFAIK local and RI variables will be inherited down through sub-interfaces, but I agree that I'd expect explicitly defined RIs in sub-interfaces to override any ones passed in from the parent... but maybe this isn't guaranteed?
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 Sidhant Behura over 8 years ago

@stefanh791 and @mschmitt :
Here are some additional information:
If you observe there are 2 interfaces main and sub interface.
The rule input names in the parent and child interfaces are same i.e varA and varB.
So when i call the sub-interface(contains text fields to initialize the variables) and map the rule inputs there is an anomaly.
My mapping is:
varA(Main Interface) --> varB(Sub Interface),
varB(Main Interface) --> varA(Sub Interface)

In this case whatever changes you might perform on the variables, those wont persist.
Reason being appian is not considering my mapping instead it is mapping
varA(Main Interface) --> varA(Sub Interface),
varB(Main Interface) --> varB(Sub Interface)

If the above explaination is not clear then I will create a small application with the same interfaces and attach it so that it can be imported and checked.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 PhilB
Certified Lead Developer
over 8 years ago

@mschmitt you're better off creating the rules as attached above - it's a little confusing initially but I've been able to see the unexpected behaviour exactly as described.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 Stefan Helzle
A Score Level 3
over 8 years ago

I used the submitted code to do my tests. The issue is clear I think. But Appian is not mixing up your variable assignment, but overwriting the values in the sub expression because of the equal naming. And this is not OK.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel