Is there any way to compare two record values of same record type to find the difference?

Certified Senior Developer

I have the requirement to find the difference between two record values of a record type like we do in case of cdts using cdtdifference(). I have the previous value of record type and then new value, I need to populate Audit table using these difference values.

Any function like cdtdifference() or any workaround to do this?

  Discussion posts and replies are publicly visible

Parents
  • Hi - yes, CDT Diff Utilities is a plug-in I wrote a long time ago. But here it looks like the question being asked is how to find the difference between two run-time instances of a Record type.

  • 0
    Certified Senior Developer
    in reply to Stewart Burchell

    Yes, exactly. I am seeing no other way except manual compare or casting into cdt and then compare using function.

  •   Hi Stewart, someone just asked me this exact question in terms of how they will migrate from comparison of cdts to records in the future? have you had any more thoughts on this. The use case is a very granular audit trail of field level changes, by who, when etc.

    This works fine in CDT comparison, its the longer term thinking around this the client is concerned with.

    Would be interesting to hear of any other suggestions from anyone ... apart from database triggers ;)

    Dai

  •  

    Field level audits contains a challenge bigger than just "compare these two data structures". The missing part of the puzzle for me was always how to ensure any "difference" between version A and version B of the same data structure is communicated to an end-user in a business meaningful way. So whilst, yes, you can use CDT diff from CDTs (and you could cast from Records to CDTs - ugly though that is) what would still be missing would be "The field named 'dob' in the client database is "Date of Birth" in the User Interface. In short: there's a gap in the "mapping" between the technical and business representations.

    But, putting that to one side for the moment...it has occurred to me that perhaps to cater for any current implementation and to future-proof we should probably use a platform independent representation of the data and have a method of perform a diff on that. I would suggest JSON as a good candidate here as it's lightweight, there are functions in Appian (and in most - if not all - modern databases) that allow you to cast to JSON. And JSON has JSON Schema so not only could you conduct a diff you could also conduct validations of JSON instances against a JSON Schema (or even versions of Schemas) that might provide insights as to the validity of the data as well as what changed between instances.

    On a disappointing note - there is no JSON Diff (that I am aware of) in Appian. But I'll raise this as an internal opportunity as it seems a good way to go.

  • 0
    Certified Lead Developer
    in reply to Stewart Burchell

    In my projects I have been using a bit different approach.

    • I am finding keys of dictionary/record/cdt first using the a!keys.
    • Then I will check if any field needs to remove from audit, e.g. CREATED_BY, IS_ACTIVE etc. If yes, then remove those keys from first step. These metadata fields can be maintained in a generic rule.
    • Then run a loop with the remaining keys and using old and new cdt compare the values 
      a!forEach(
        items: local!keys,
        expression: if(
          index(ri!oldCDT, fv!item, null) = index(ri!newCDT, fv!item, null),
          null,
          fv!item
        )
      )
    • Using these changed keys, creates a map structure from old and new cdt.
    • Also, creates a generic rule to change keys to more user friendly names.

    Hope this helps to reduce dependency on any plugins.

  • Funny you should say that  pretty much exactly what we do now. We have a lookup between field name and field description to be able to then hold a more verbose term for the field when we create our json string that then goes to a NoSQL database. When displaying the data we then return it via API in a nice grid structure formatted as required. 

Reply Children
No Data