I am retrieving a large JSON document from a web service and need to display this on a set of interfaces. The JSON has separate sections for different aspects of the data and my plan is to create separate interfaces for each section then add each of these interfaces to a single master interface. The end user will be directed to this master interface to view all the necessary information from the JSON document. This data is strictly read-only. We will have other JSON documents that may allow edits which are then passed to an integration to be saved in a database, and/or to notify other system components of the change.
Some of these components are made available to multiple Appian applications which are created by other developers (not involved in the creation of these common components).
The question I have is around passing data internally between Appian objects (process model to interface, interface to interface, interface to expression rule, etc). Should we map the JSON data into a CDT to pass it around or just leave it as a Dictionary (map, actually, since I cannot find a way to create a rule input as a dictionary type)?
It seems to me that by using CDTs we are using strongly typed data. The caller knows exactly what kind of data the target (interface, process variable, expression) expects and errors are caught early on (in the Designer). Using dictionary/map objects, these seem more loosely typed. There is no definitive list of expected properties and no formal data type for any of the properties. The caller cannot tell from the rule input data type what the target really needs (i.e. what properties with what data types)? If the wrong property name is given, dictionaries typically respond by returning null. This may allow bugs to go unnoticed at design-time.
As you can probably tell, I come from a strongly typed OOP background (C#), but do have some familiarity with more loose/dynamic typing systems (e.g. JavaScript).
It appears that Appian development prefers the more loose/dynamic typing model.
What suggestions do you have for when to use CDTs vs dictionaries (and by implication strong vs loose/dynamic typing)?
Thank you.
Discussion posts and replies are publicly visible
"Some of these components are made available to multiple Appian applications"
This is what makes my answer "CDT"!
I typically do not take the effort for pure read-only data. Rule inputs of type "ANY" happily accept dictionaries. To fetch data from these structures, make sure to use index()/property() to gracefully fail on non existing fields.
I prefer CDTs when they are viable. If the JSON from your web service is going to vary in format, then your only option may be a!map - but if you are confident that the JSON will always have the same fields, and the values in those fields are the same type, I would recommend using CDTs. Largely for the reasons you've already mentioned - the strong typing makes it more reliable, it's easier to maintain and troubleshoot when you see the expected CDT type as opposed to dictionary, and you are more likely to catch errors earlier on if you are improperly accessing fields.
So, without that cross-application requirement, would you lean more towards dictionaries?
Yes, our JSON is defined by our .Net Web Service so it is strongly typed at the service layer (and in the WSDL). When it changes, it is reasonable for us to make the corresponding change to our CDT.
Yes. I do not see much benefit from turning it into CDTs.
It appears from Stefan and Dan's responses that there may be a mix of practices. Is this more of a personal preference thing then?
There is no right or wrong answer, there are pros and cons to each that you will need to weigh. It does take more time to create CDTs than to use dictionaries/maps, so it depends on if you feel like that extra work is worth the benefits you get of using CDTs.
Ok. Thank you for your input.