If process fails, it's easy to debug that while working with CDT while Compared to json string. You might face some issues while working with json in Appian, when your CDT contains a date / datetime field value, while converting it to json, it's format gets change than the actual, due to which you won't be able to persist that dictionary into db(because the date format will be other than Appian date format), hence you need to do some manipulation to resolve that.Īlso, CDT organises your data in proper structure(list of attributes into one object). There are several reasons why you should opt for CDT approach while compared to json string.

Sorry if there is already a discussion on it, in that case please point me to that thread.Īgreed, it's not a best practice to choose json string instead of CDT. Is above a good practice? Or using CDT is the preferred way to go. And because the JSON is basically a text, if we change the structure (mostly adding/removing/updating an attribute), the process model won't require any changes. And we can always deJsonify that and get a dictionary using a!fromJson function in the interface/expression. So, mainly to avoid the CDT backward compatibility (that I mentioned above), we thought of using the JSON string wherever we were using the CDT in the process model. Although we are leaning towards short lived processes, there are chances that few processes stays in the memory for a longer period of time.

Now we are on our way of redesigning our original process model that handles the workflow. Which makes our job a little complex to write logic which is always backward compatible and sometimes we have to make compromise saying that the functionality will work for a new processes only. So, any change we make in the CDT won't get affected on the older processes. Currently in our workflow, the processes are very long lived (approximately 300,000 active at a time).

.json modeler