I'm looking for a simple, clean way of displaying a 'percentage complete

I'm looking for a simple, clean way of displaying a 'percentage complete' for a CDT using a progress bar. The CDT has X number of attributes that need to be populated with data to be considered 100% complete. I believe I just need to interrogate those attributes, determine if they contain data and then do the division manually in an expression rule. Are there any built in functions to accomplish this or has anyone had success with this scenario?...

OriginalPostID-41268

OriginalPostID-41268

  Discussion posts and replies are publicly visible

  • Pretty interesting use case. These are the two ideas that I can think of. The quick and dirty way is to convert the CDT into TEXT and then count the number of "=," which is there when a value of the CDT is null and use this as the total number of empty elements. Evaluate this against the total number of elements in the CDT and you should get the number. You can count the number of "=" to do this dynamically as well - just in case the CDT structure changes. Note: I am assuming all elements are required in your use case. The second (and probably a more reliable way) is to use TOXML() to convert the CDT into XML and use expression to find out number of empty nodes.
  • Thanks Sathya I appreciate your ideas. What do you think about setting it up in such a way where each CDT has an attribute for the number of fields required for 100% completion. At the time of saving the data I loop through each field mapped to the data store checking for a value and increment this attribute so that the number of fields with data are stored along with the CDT? Do you see any problems that this could cause?
  • You can do that as well. I think we are talking about the looping logic. If you want it dynamic, then you need to interrogate the CDT at any given time and get the values. If I were to design your logic, I would have a separate variable holding the % complete as I dont see CDT the right place to store % complete as it doesnt really form part of the data model which CDT's are suppose to be. And in the logic where you do the looping, you would update the process variable. The advantage here is that the lifecycle of the process variable is now controlled by the lifecycle of the process instance and this in turn lines up nicely with the lifecycle of the instance dashboard and secondly and most importantly, updating the value and storing it back into the DB means that you now have to do two writes and two reads to the database which again can add overhead.