Using Json string instead of CDT in process model (long running)

Currently in our workflow, the processes are very long lived (approximately 300,000 active at a time). So, any change we make in the CDT won't get affected on the older processes. 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.

Now we are on our way of redesigning our original process model that handles the workflow. Although we are leaning towards short lived processes, there are chances that few processes stays in the memory for a longer period of time.

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. And we can always deJsonify that and get a dictionary using a!fromJson function in the interface/expression. 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.

Is above a good practice? Or using CDT is the preferred way to go. Sorry if there is already a discussion on it, in that case please point me to that thread.

Thanks!

  Discussion posts and replies are publicly visible

Parents
  • Certified Lead Developer
    Agreed, it's not a best practice to choose json string instead of CDT.

    There are several reasons why you should opt for CDT approach 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.

    Also, CDT organises your data in proper structure(list of attributes into one object).

    If process fails, it's easy to debug that while working with CDT while Compared to json string.

    While using CDT, you can even have character restrictions for each attribute of the CDT (if required) whereas json string can't.


    If you are only concerned about multiple and long living process instances, then json string won't help you, instead you need to build your process light weight by following below mention steps:

    Avoid defining multiple process variables instead define less variabls, for example: applicationId , processInitiator and perform most of the db operation on-demand via interface. I know, it will be a bit difficult to debug if something goes wrong, but still this will be the better approach while compared to json string. And also this will avoid any performance issues on server, because every single instances will only have 2 - 3 process variables of type (non-cdt and non-array). Hence your each individual process will hardly contain few nodes.


    Hope this helps.
Reply
  • Certified Lead Developer
    Agreed, it's not a best practice to choose json string instead of CDT.

    There are several reasons why you should opt for CDT approach 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.

    Also, CDT organises your data in proper structure(list of attributes into one object).

    If process fails, it's easy to debug that while working with CDT while Compared to json string.

    While using CDT, you can even have character restrictions for each attribute of the CDT (if required) whereas json string can't.


    If you are only concerned about multiple and long living process instances, then json string won't help you, instead you need to build your process light weight by following below mention steps:

    Avoid defining multiple process variables instead define less variabls, for example: applicationId , processInitiator and perform most of the db operation on-demand via interface. I know, it will be a bit difficult to debug if something goes wrong, but still this will be the better approach while compared to json string. And also this will avoid any performance issues on server, because every single instances will only have 2 - 3 process variables of type (non-cdt and non-array). Hence your each individual process will hardly contain few nodes.


    Hope this helps.
Children
No Data