Logging Interface Access

Question

I hope this message finds you well. 
 I would like to log the event of an interface being opened. However, my understanding is that on the interface itself, unless an action such as clicking a button occurs, 
 it is not possible to write a record or start a process model. 
 When consulting ChatGPT, I received the following idea: 
 
 Create a Web API on Appian that returns an image as the response and simultaneously saves a log. 
 Place an image on the target interface and set the endpoint of the Web API created in (1) as the image source. 
 As a result, when the interface is opened, the Web API in (1) is called, and the log is recorded. 
 
 However, it seems that the function a!writeToDataStoreEntity does not get triggered inside the Web API. 
 I have two questions and would appreciate your advice: 
 
 What should I review to implement the above ChatGPT idea successfully? 
 Are there alternative methods to log when an interface is opened? 
 
 Thank you in advance for your kind advice.

Mike Schmitt · Answer

If you absolutely must have this, it's pretty easy to create an Appian Web API that accepts key info (i.e. the username of the current user, and the name or some sort of identifier for the interface in question), which you can then call from the interface at load time in a local variable declaraion calling an Integration. The API would simply launch a process model that quickly makes an entry for that username and that identifier in a DB table you have previously created, as well as a "loaded at" timestamp. 
 I've implemented something like this for myself and decided to limit the DB table to 1 row per user per day per interface, so when it launches for a particular user, if there's already a row for that date/user/interface, it updates the existing row (incrementing an "updated" timestamp, as well as a "counter" that starts at 1 and increments for every unique load by that user). This is slightly extra work of course but has been pretty useful to me and our management team in tracking overall site usage.

Harsha Sharma · Answer

You web API structure as per this sample code doesnt seem right! the smart servcies should not be related to a local variable. 
 Please check the documentation for steps/considerations. In you use case you can create a web API that has a!startProcess() in it. Whatever you are trying to accomplish in a!writeRecord() and a!writeToDataStoreEntity() should be moved inside the process. 
 The https Response configuration would also come within the onSuccess or onError of a!startProcess() configuration.

tamaraw · Answer

Keizo, 
 Create the Web API as a POST but make sure that you check the Queries Data and not Modifies data. 
 - The webAPI must create an entry onto the database table where you are logging the event. 
 Create an integration to call that webAPI 
 In your interface, call the integration 
 
 a!localVariables( 
 local!eventLog: rule!MY_Integration(), 
 a!sectionLayout( 
 label: "My Label", 
 contents: {} 
 ) 
 ) 
 
 This should work. Let me know if you got any questions 
 Lejanson

Mike Schmitt · Answer

This isn't really how to structure what I was suggesting. My setup has 5 main layers - it could potentially be condensed some, but the layer structure defined here gives you levels of abstraction that will increase potential reusability and reduce rework efforts should you decide to change the way something works in the future. 
 
 On your interface , call an expression rule in a Local Variable definition, passing in the person's username, and relevant details about where they're viewing from. 
 In the expression rule , call an Integration you set up, and map the results. It doesn't need to do anything as complex as returning an "image file", it could simply return a timestamp or boolean value. My suggestion would be simply having it return a "last updated" timestamp (to be stored in the aforementioned Local Variable). 
 In the integration , call the Web API you set up, passing in the details sent in from the Expression Rule. Tie it to a Connected System pointing at your own environment and with a Service Account that has permissions to launch the process model used in the Web API. 
 in the Web API , configure as a POST method and call the designated Process Model using a!startProcess() , passing in the same relevant details having been passed down. 
 In the process model , you can do your DB write / update, passing back values to the caller indicating that it ran successfully (such as a "last updated" timestamp value). If you decide to look up an existing row for the user in question (such as grouping rows by day, so as not to clutter the table with a row for every single refresh), it will be trivially easy, for instance, to pre-query any relevant row for the user per location/day, and if one exists, update that row, and otherwise, create a new one. Or just write a new row every time, that part is up to you.