User input task

RE: User input task

maximeg0001 — Fri, 29 Jan 2021 07:43:37 GMT

Hell,

I will see if the a!writeToDataStoreEntity() on each field can be implemented.

The "auto save" solution is to avoid the 1 hour timeout because some users need lot of time to fill the form and when they refresh the application they lost everything.

Very thank you all for your answers.

Best regards

RE: User input task

Chris — Thu, 28 Jan 2021 20:58:41 GMT

Also agree there is nothing natively OOTB that will allow auto-saving of forms. However, as the a!writeToDataStoreEntity() function could be called from any field's saveInto parameter, if this were my requirement I would create a rule that takes the CDT input and writes to the DB using this function, as the others have suggested - plugged into each field's saveInto. Along these lines, if nothing has changed on the form, what is the use case requiring auto-saving of unchanged data?

Purely food for thought, we can call fn!executeStoredProcedure() within a refreshVariable. Note this function is not designed to call procedures which alter and data within the DB - however it does allow this in some situations. I cannot speak to if this will change in the future. However, I have 2 cases in production where data is inserted or updated using this, such as a proxy function which runs on task assignment and updates a logging table if a proxy assignment is made, and a round robin task assignment procedure that maintains the task assignment history and pulls the next assignee.

In the example below, we are not writing to the DB, but a procedure is called which adds 10 to the local!input value and returns the output. This procedure is fired on each local!input field change, OR after each 30 seconds (based on local!save being refreshed), without any changes to the field saveInto's. With some modifications it may be possible to load data into the DB with this method.

Some other use cases that may benefit from fn!executeStoredProcedure() within a local variable load could be for logging any interface views, etc.

=a!localVariables(
  local!input: 10,
  local!save: a!refreshVariable(
    value: now(),
    refreshInterval: 0.5
  ),
  local!output: a!refreshVariable(
    value: fn!executestoredprocedure(
      dataSourceName: "java:comp/env/jdbc/sql_lookup",
      proceedureName: "usp_testAdd10",
      inputs: {
        {name: "NUM", value: local!input}
      }
    ),
    refreshOnVarChange: local!save
  ),
  {
    a!textField(
      label: "Input",
      labelPosition: "ADJACENT",
      value: local!input,
      saveInto:  local!input,
    ),
    a!textField(
      label: "Output",
      labelPosition: "ADJACENT",
      value: local!output.parameters.RESULT,
      readOnly: true
    ),
    a!textField(
      label: "Last Save",
      labelPosition: "ADJACENT",
      value: local!save,
      readOnly: true
    )
  }
)

Procedure:

SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO


CREATE PROCEDURE [dbo].[usp_testAdd10] 
	@NUM varchar(15),
	@RESULT varchar(16) OUTPUT
AS
BEGIN
	SET @RESULT = cast((cast(@NUM as int) + 10) as varchar(16))

	RETURN
END


GO

RE: User input task

Mike Schmitt — Thu, 28 Jan 2021 18:53:44 GMT

Agreed, if the requirement is strong enough and a high level of effort is acceptable, you could perhaps set up a custom table just to hold temporary on-form values pertaining to a specific user (indexed to their Appian username for example), wherein you store a JSON-ized text string representing a CDT containing all data editable on that form (or if it's a massive amount, maybe individual fields instead). Then any time the user changes anything, the form could wrap that value back into the JSON string and instantly beam it back over to that table... and when a user loads the form in the first place, the table would be queried and checked to see if it already contains any value.

It should be underlined that this has nothing to do with the functionality found in the "save a draft" button provided by Appian - in fact I would suggest anyone going this route actually disable that button so as to not confuse matters more.

RE: User input task

Peter Lewis — Thu, 28 Jan 2021 18:49:38 GMT

Agree with Mike - I don't think this is possible. The only thing that might work (but would likely require a lot of effort) is if you wrote to a database table using a!writeToDataStoreEntity() on the task any time any field is updated. Then, whenever you load the form, you would pull the data from the database and the user would never have to save it.

I should clarify - I have never actually done this, so there might be some weird edge cases or it might just be too much effort to be feasible. Theoretically it should work though!

RE: User input task

Mike Schmitt — Wed, 27 Jan 2021 17:36:39 GMT

I don't know of any current way to do this.