Skip to main content
M
mattheww0004
May 16, 2021
Solved

Record Summary Views and Process Models

  • May 16, 2021
  • 4 replies
  • 0 views

I currently am writing a basic ticketing system which has an interface used as a record summary view, in the interface is a submit form where users will submit comments to be saved to the database. I am wondering what is the best practice for saving that data in the database? Is there a way to initiate a process model on a record view?

    Best answer by mikes0011

    You have a few options for this these days - which one you choose will depend on your own requirements and flexibility demands.  The most "officially" supported and old-school way to deal with it is to simply have a Related Action users can click which will take them into a process that handles comment entry.  This obviously isn't quite as seamless or click-minimized as what you seem to be asking for.  These we have both a!startProcess() and a!writeToDataStoreEntity(), which you could use one of in this case - either use the former to start a process when the user clicks something, which writes their entered comment; or use the latter to just write it straight to the DB.  Using StartProcess is the approach recommended by a lot of folks around here because it leaves behind a traceable process history when it comes time to troubleshoot/debug.  Speed-wise I'd guesstimate that both approaches are similar - unless you've done something explicitly inefficient, the user should experience a near-instant result in both cases.

    4 replies

    mikes0011
    mikes0011Answer
    Brainy
    May 16, 2021

    You have a few options for this these days - which one you choose will depend on your own requirements and flexibility demands.  The most "officially" supported and old-school way to deal with it is to simply have a Related Action users can click which will take them into a process that handles comment entry.  This obviously isn't quite as seamless or click-minimized as what you seem to be asking for.  These we have both a!startProcess() and a!writeToDataStoreEntity(), which you could use one of in this case - either use the former to start a process when the user clicks something, which writes their entered comment; or use the latter to just write it straight to the DB.  Using StartProcess is the approach recommended by a lot of folks around here because it leaves behind a traceable process history when it comes time to troubleshoot/debug.  Speed-wise I'd guesstimate that both approaches are similar - unless you've done something explicitly inefficient, the user should experience a near-instant result in both cases.

    The Expression Guru
      M
      mattheww0004Author
      May 16, 2021

      thank you for this! My current database schema is a ticket table, comment table, and then a pivot table containing the id's of both tickets and comments. I figured out how to use the process model data store entity to save the two values in the pivot table but I dont understand how to properly do so in the a!writeToDataStoreEntity function. What would be the proper way of doing that? Also if I went the process model route what would the first node of the process model be for it to initiate from an a!startProcess() call?

      mikes0011
      mikes0011
      Brainy
      May 16, 2021

      For your first question - if your intent is to write a row to one table, get its primary key id, then write that id as a member of a second table write, then it might not be easily possible in one click (using a!writeToDataStoreEntity() that is).  For whatever reason there's a restriction on the smart services you can call in one saveInto action on-form - and for some reason that limit is just 1.  I haven't tried this in a while so your mileage may vary.  But this would be trivially easy to handle in the process-backed approach.

      For your second question - you basically don't need to do anything special to launch a process model from a!startProcess() -- just remember that this function (unlike the sorta-similar a!startProcessLink()) strictly runs a process in the background after the user click event - the user won't leave the form they're on.  I believe this fits your use case, but just clarifying.  Then, the only configuration the process model really needs is to add whatever PVs you need to pass in (make sure they're set as parameters), and security settings with at least "viewer" access to any users who you expect to be performing such functionality.

      The Expression Guru
        Terms & ConditionsAccessibility statement