The client wants us to log information about everything that goes in and out of the app through APIs and integrations. Appian logs a lot of stuff by default. So far I've found:
api_key.csv - saves information about any api keys used for our APIs, including identifying information for the key itself, what endpoint it was used to access, and the ip address of the client that accessed itoauth_callback.csv - saves all oauth calls that made to other systems. includes the user that made the request, the connected system it was made too and whether it was successful or notoauth_client_credentials_grant_for_web_apis.csv - saves oauth requests made to our APIs. Includes the service account that was accessed, the endpoint that was accessed, and client ip addresses
Integration_summary.csv - I am not quite sure what this is. It seems to be a summary log taken every 5 minutes of the amount of time spent on all integrations in that 5 minutes. (is there some way to reduce the frequency? Every 5 minutes seems way too often)
integration_details.csv - basically the same info as the integration summary log, but itemized
web_api_summary.csv - same as integration_summary.csv but for APIs (again that 5 minute summary seems unreasonably short)
web_api_details.csv - same as integration_details.csv but for APIs
integration_req_resp_activity.log - contains the responses from integrations with HTTP Request/Response Logging enabled, though the body of those responses is obscured.
Finally there's also integration_trace.csv and web_api_trace.csv, but both of those logs appear empty. I've enabled tracing as per the documentation, and the file size is not 0, suggesting something should be in those logs, but when I download them I just get a blank file.
So here are my main questions.
1) Are there any other log files (related to API/integrations) that I am missing?
2) If I wanted to save the responses for these integrations/APIs (including the body that is normally obscured in the logs), how would I best go about doing that?
Discussion posts and replies are publicly visible
Hi Marco,
Related to your second question:
My personal approach - create a "API log" cdt with some meta data and a field "body". Every time the API is triggered you create a DB entry for each single call.
That is more or less what I'd planned on doing, but the only problem with that is "get" method API's don't allow smart services (like starting a process model or writing to the database), so I'm not sure how to trigger the write for that.
Have you enabled the logging option for your integrations? If so appian logs the request and response body as well. For more info please check this URL docs.appian.com/.../Integration_Object.html
Yes, but the actual data in the body is scrambled, making it useless. Also logs aren't exactly friendly to look through and sort. We want to have something a bit easier to filter through and organize. Something that we can actually use in Appian as opposed to a file we have to manually download and sift through.
Before you hit the API you must be having the request body and once it return the result , you will have your response , So if you hit your API using the expression rule or PM , you will have all the things to call a subprocess which will dump the data in DB. I am not sure why it cannot be achieved . We also have a similar shared subprocess which do it for all API calls.
Depends on the API's method. POST methods allow for smart services to be called (like process models), so there is no problem tossing in something to write the data from that. But GET methods don't allow for smart services. No smart services means we can't write to DB
which is absolutely correct.Appian is following HTTP standards here.Please follow them as well.Every method has its sense.GET is used to request data from a specified resource.POST is used to send data to a server to create/update a resource.If you want to create data (aka storing in DB) POST is your method of choice.https://www.w3schools.com/tags/ref_httpmethods.asp-> to solve this issue for tracking the APi usage, you should perhaps check, if its possible to just offer "POST" Apis.
I understand the difference between get and post. We just want a record of what is gotten through those gets that the current log system doesn't account for.
i think this should be a corner case here which cannot be served properly....