Logging Interface Access

RE: Logging Interface Access

Mike Schmitt — Tue, 21 Oct 2025 15:43:21 GMT

Ok good, glad to hear you got the error resolved.

RE: Logging Interface Access

Keizo Watsuji — Mon, 20 Oct 2025 07:06:23 GMT

I was able to resolve the issue on my own.

The error was related to the setting in the onError of a!startProcess.
In other words, the Process Model failed to start.

Although I had configured the Web API authentication to use a security account,
the security settings for the Process Model and Data Store Entity were missing, which caused the problem.

I've already fixed it and the original goal of saving logs on the screen display has been about 80% completed.

As for the remaining 20%, I will create a separate thread to ask questions.

RE: Logging Interface Access

Keizo Watsuji — Sun, 19 Oct 2025 11:22:57 GMT

Thanks Mike,

I've tried implementing accoding to your advice and I'm stacking on the connection between integration and Web API.

My Web API runs correctly when I click TEST button on it.
But when I click TEST button on my integration, it fails as below:

-------------------------------------------------------

Value
Dictionary
success: false
result: HttpResponse
statusLine: "HTTP/1.1 500 "
statusCode: 500
headers: Dictionary
Date: "Sun, 19 Oct 2025 11:04:35 GMT"
Content-Type: "text/plain;charset=ISO-8859-1"
Transfer-Encoding: "chunked"
Connection: "keep-alive"
X-Trace-Id: "522127991e953a7fe2716155fe5ecddc"
Strict-Transport-Security: "max-age=31536000; includeSubDomains; preload"
Referrer-Policy: "strict-origin-when-cross-origin"
X-Frame-Options: "SAMEORIGIN"
Content-Security-Policy-Report-Only: "style-src 'unsafe-inline' 'self' web-assets.appian-cdn.com 'strict-dynamic' 'nonce-YTlkMTBmNzUtZDRiMi00ZGEzLWFhMGYtYmM2NGExMWM5MWE1'; child-src 'none'; script-src 'self' 'unsafe-inline' 'unsafe-eval' web-assets.appian-cdn.com 'strict-dynamic' 'nonce-NGVjYmY4NjMtZDUzZS00Y2VmLTk5MWEtMmI5Y2NlNjJkYTcy'; object-src https:; frame-src https:; img-src https:; default-src 'self'; font-src 'self' https: data:; report-uri /suite/rest/a/logging/latest/csp/report; report-to report;" Content-Security-Policy: "report-uri /suite/rest/a/logging/latest/csp/report; report-to report;"
Reporting-Endpoints: "report="/suite/rest/a/logging/latest/csp/report""

X-XSS-Protection: "1; mode=block"
Requested-While-Authenticated: "false"
contentType: "text/plain;charset=ISO-8859-1"
body: "500 - Internal Server Error"
error: IntegrationError title: "The external system encountered an error"
message: "Failed to connect to https://{my appian url}/suite/webapi/{my end point}"
detail: "HTTP/1.1 500 "
connectedSystem: null (Connected System)
binaryDoc75MbLimitExceeded: false

-------------------------------------------------------

I can see connected system setting on my integration but it says
"connectedSystem: null (Connected System)"

RE: Logging Interface Access

Keizo Watsuji — Sun, 19 Oct 2025 11:10:44 GMT

Thanks Lejanson.

>Create the Web API as a POST but make sure that you check the Queries Data and not Modifies data.
It's very useful for me.

RE: Logging Interface Access

Jesse Knight — Wed, 15 Oct 2025 13:50:08 GMT

With the POST, be sure to select 'queries data', and this should work ok. If you select 'modifies data', you get an error related to the fact that the integration call is not in a saveInto.

A possible quirk about retrieving images via API: We don't know if there are performance issues at scale when retrieving images directly via API versus using a!documentImage().So to avoid any potential issues when using an image in this way, it may be best for the API to return a document id for use with a!documentImage(). That keeps the API layer small / concise, and keeps the performance of the UI expression in line with what's generally expected when many users load the image.

Harsha Sharma One possible reason to make this an image retrieval is so that there's a reusable UI component that's placeable in any UI, including collapsible sections / hidden parts of the UI that are conditionally shown. The reusable component would receive any metadata about the section context, automatically call the API on demand, and load a 1x1 pixel image with no padding / borders onto the UI. Without the UI component aspect, the logging isn't very reusable as an encapsulated rule.

RE: Logging Interface Access

Harsha Sharma — Wed, 15 Oct 2025 03:35:18 GMT

Web APIs using 'GET' method cannot call any smart services as per Appian Design. So for intended functionality use the 'POST' method in web API and setup an Integration that calls your web API from target interface. As soon as interface loads, the Integration (executed on load against a local variable) will call the API. API will execute the smart service and record log with a success response for integration. When setting up a!httpResponse for web API in response body you can send back the image as well.

a!httpResponse(
  statusCode: 200,
  headers: {
    a!httpHeader(name: "content-type", value: "application/json")
  },
  body: a!iconIndicator("STATUS_WARN")
)

However as earlier discussed in this thread that to log the interface load activity you don't necessarily need to follow what ChatGPT suggested.

The web API can write to db and respond back with a successful message. That web API can be called using an integration in the interface. So on load the integration->web API->write records will execute. On Error of API execution, response can be a user friendly message asking them to re-load the interface.

Is there any reason for image to be involved in the response and showing it on interface if you just want to log the interface load activity?

RE: Logging Interface Access

Keizo Watsuji — Tue, 14 Oct 2025 23:56:10 GMT

I'm sorry for causing confusion. The "Portal Site" I mentioned is not the Appian Portal, but a portal site in the usual sense, meaning the entry point for users.

RE: Logging Interface Access

Keizo Watsuji — Tue, 14 Oct 2025 23:48:54 GMT

Thanks Jesse.

I understood that. But the error "Smart Services cannot be executed in Web APIs that have a method of 'GET'." is still remaining...

RE: Logging Interface Access

Mike Schmitt — Tue, 14 Oct 2025 16:30:24 GMT

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.

RE: Logging Interface Access

tamaraw — Tue, 14 Oct 2025 14:45:26 GMT

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

RE: Logging Interface Access

Jesse Knight — Tue, 14 Oct 2025 13:03:12 GMT

Hi Keizo,

It is not a hard requirement to write records from a Process Model. For APIs that are intended to be called frequently, it is better in practice to call a!writeRecords() from the API object itself to remove the overhead and latency of starting a process.

Keep in mind that, if enabled in the record types, you can write multiple related records at once if they are sync'ed records and have a relationship defined. For me, this has worked for 99% of my use cases. For the other 1%, I did something like the following:

a!writeRecords(
    records: {Record A and its embedded related records}
    onSuccess: a!writeRecords(
        records: {Record not related to record A}
        onSuccess: a!httpResponse()
        onError: a!httpResponse()
    ),
    onError: a!httpResponse()
)

RE: Logging Interface Access

Jesse Knight — Tue, 14 Oct 2025 12:52:42 GMT

It is my understanding that portal users do not 'log in' to Appian, and therefore loggedInUser() will return the service account that is called from the portal rather than the person accessing the portal. You can probably add some metadata (headers, path, query param, etc) to your API call to get some sort of user info.

RE: Logging Interface Access

Keizo Watsuji — Tue, 14 Oct 2025 11:06:41 GMT

Dear Harsha,

Thank you for your advice.

I reviewed the documentation again, modified my code and confirmed that a!startProcess() and a!writeRecord can be executed.

However, as mentioned in my initial post,
(1) Create a Web API on Appian that returns an image as the response and simultaneously saves a log.
(2) Place an image on the target interface and set the endpoint of the Web API created in (1) as the image source.
(3) As a result, when the interface is opened, the Web API in (1) is called, and the log is recorded.

Since we intend to implement this behavior, the Web API must be implemented with the GET method.

As a result, we encountered the error:
"Smart Services cannot be executed in Web APIs that have a method of 'GET'."

and cannot proceed further.

Is there any way to work around this?

RE: Logging Interface Access

Keizo Watsuji — Tue, 14 Oct 2025 10:04:37 GMT

Dear Stephan,

I generally agree with your opinion.
However, we are building a portal site for users and are considering displaying various information for them on the top page.
Since there are quite a few users for whom simply viewing the portal site is sufficient, we would like to also track who has accessed the portal site.

RE: Logging Interface Access

Stefan Helzle — Tue, 14 Oct 2025 08:02:00 GMT

"Usage Rate" ... isn't this about users actually doing something vs. just staring at a page? User activity in Appian is closely tied to starting processes. When writing records, you can also write record events which then should correlate with "user activity".

RE: Logging Interface Access

Harsha Sharma — Tue, 14 Oct 2025 06:41:44 GMT

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.

RE: Logging Interface Access

Keizo Watsuji — Tue, 14 Oct 2025 03:39:53 GMT

Thank you all for your advice.

Although I initially lacked some information, ultimately, I would like to calculate usage rates for each application from the log data. Therefore, I prefer to save the logs as records rather than text files. Additionally, since I need to calculate usage rates by organization, user information is also necessary.

Hence, I believe the approach Mike has already implemented is the closest to what I need.

I implemented the Web API as shown below. While it returns an image file as the response, it seems that neither a!startProcess, a!writeToDataStoreEntity, nor a!writeRecords functions are executing.

I implemented it using the GET method to return the image file. Is there anything else I should do?

a!localVariables(

local!codea: 200,
local!codeb: 200,
local!codec: 200,

local!a: a!writeToDataStoreEntity(
dataStoreEntity: cons!XLOG_EVENT,
valueToStore: 'type!{urn:com:appian:types:XLOG}XLOG_RT_EVENT'(
timestamp: now(),
appName: "Application Name",
functionName: "Function Name",
user: tostring(loggedInUser())
),
onSuccess: a!save(local!codea, 201),
onError: a!save(local!codea, 202)
),

local!b: a!writeRecords(
records: 'recordType!{}XLOG rtEvent'(
'recordType!{}XLOG rtEvent.fields.{}timestamp': now(),
'recordType!{}XLOG rtEvent.fields.{}appName': "Application Name RT",
'recordType!{}XLOG rtEvent.fields.{}functionName': "Function Name RT",
'recordType!{}XLOG rtEvent.fields.{}user': tostring(loggedInUser())
),
onSuccess: a!save(local!codeb, 201),
onError: a!save(local!codeb, 202)
),

local!c: a!startProcess(
processModel: cons!XLOG_pmTest,
onSuccess: a!save(local!codec, 201),
onError: a!save(local!codec, 202)
),

local!d: a!richTextDisplayField(
value: "code: " & local!codea & " " & local!codeb& " " & local!codec
),

a!httpResponse(
statusCode: local!codec,
headers: {
a!httpHeader(name: "Content-Type", value: "image/png"),
a!httpHeader(name: "Cache-Control", value: "no-store, no-cache, must-revalidate, max-age=0"),
a!httpHeader(name: "Pragma", value: "no-cache")
},
body: cons!XLOG_PNG
)
)

NOTE:In this sample code, these local variables are only for debbuging.

RE: Logging Interface Access

Mike Schmitt — Mon, 13 Oct 2025 18:44:39 GMT

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.

RE: Logging Interface Access

Jesse Knight — Mon, 13 Oct 2025 14:28:13 GMT

ChatGPT's approach isn't "wrong", it's just incomplete and can be misleading. Even 2025's latest LLMs are like the over-confident interns we're constantly correcting and rolling our eyes at. Yet in this case, its approach is possible.

For this to work

You need a what's colloquially known as a "loopback" API call, where an Appian API is called via an Appian integration that uses an API key from the admin console. In theory it's possible to have the logged in user authenticate to the Appian API as themselves, but in practice it's a little more nuanced than that. Depending on your environment's security requirements, loopback API's may not be a good idea to do in production.
API trace logging must be enabled in the admin console. Enabling this logging can cause a bit of overhead in production, and the logs will be overwritten every few days (or ~10MB) if there is a large volume of API calls.
View perflogs/web_api_trace.csv

According to your prompt, you don't need to know who loaded the page, just that the page was loaded. If you need to know who loaded the page, there's a bit more development / complexity there.

RE: Logging Interface Access

Stefan Helzle — Mon, 13 Oct 2025 11:56:33 GMT

ChatGPT has no clue how Appian works.

Did you check whether the records usage log meets your requirements?