Hi,I have a custom output node in a process model which is calling an expression rule which takes one rule input of type Map list. The expression rule generically updates some fields within the map. We are able to pass a list of any custom data types into this expression rule and Appian happily cast from CDT list to Map list. The output node target process variable is defined as a list type of CDT (same process variable value passed to the expression rule is being updated). Appian process model will not implicitly cast the expression rule return value back into list of CDT and in fact magically wipes out the process variable completely. If I add an explicit cast function call in the custom output expression it works fine. With the expression world is good and getting correct results. cast( 'type!{urn:com:florencehc:types:SC}SC_Request?list', rule!SC_setAuditFields(request: pv!request, actor: pv!actor))Without the explicit cast the process variable value list , pv!request, is being cleared out. I wanted to use a Map list rule input so I can apply it to any of our many CTDs which contain same set of common named audit fields.So the question of the day is should an explicit cast be required or have I hit a bug in Appian which I should report?
Thanks,Bob
Discussion posts and replies are publicly visible
My $.02 would be that not casting wouldn't be a bug really, and we shouldn't count on Appian casting automatically always (although it does so nicely in some situations, and is handy). There are still a number of functions out there such as wherecontains() which are extremely picking about data type casting and will error even between integer and decimal types both equal to "1".
To me, sounds more like a Feature Request to attempt casting automatically when saving a!map() into a CDT, which I would be on board with.
Hi Chris, king of agree about the casting however feel the process model runtime returning an empty set is if in this case Appian is not going to handle the explicit casting. The a!map documentation does say it can be casted to/from dictionary and CDT types so it is certainly sane to expect it should work everywhere. I will report a bug/enhancement request since the result of returning an empty set vs. throwing an exception if they are not supporting casting would be expected result.Thanks for the two cents :).