Post Closed
2020-09-15 13-07-23
Kilian Hekhuis
 
MVP
4237Views
24Comments
Setting Logging Level of a REST API
Discussion
REST
Audit & Monitoring
How-to

Since this topic comes up every once in a while, I decided to write a quick guide aimed at the beginner level on how to set the Logging Level of an Exposed or Consumed REST API to aid in debugging. This can be useful in case you need to see what's going on when e.g. the server reports an unhelpful "500 Internal Server Error", and you need to see what's going on.

1. Increase Logging Level

  1. Open Service Center of your server and log in.
  2. Chose "Factory" and "Modules" from the menu, and search for the right Module (the one consuming or exposing the REST API).
  3. Click the "Integrations" tab.
  4. Click on the name of the REST API below "Consumed REST APIs" or "Exposed REST APIs".
  5. Set "Logging Level" to "Full" (there's also "Troubleshoot", but I'm not sure about the differences with "Full").

2. Check the logging

  1. After you have consumed the REST API (either by running the application that consumes it, or running an application (or e.g. Postman) that consumes your REST API, again open Service Center (if it's not already open), and choose "Monitoring" and "Integrations" from the menu.
  2. Optionally filter for the Module that consumed or exposed the REST API.
  3. Click "Detail" (the very last column) after the entry you're interested in (note that "Detail" will not appear if you haven't increased the Logging Level).
  4. On the page that appears you can see what has been sent, and what has been replied. If there's more than about a page it's cut off, and you can press the "Download HTTP Trace" button to get a text file with the full trace. Note that in case of binary content, it will be encoded in Base64; to decode it google for "decode base64" and you'll find online tools to decode the data.

That's about it. In case of errors, look for signs that there's something wrong, e.g. missing data, missing authentication headers, malformatted data, etc. Note that by default, the Platform doesn't send data that has the default value, so be aware that depending on the values of the data you send, not everything may appear (which could also be the source of a problem if an external REST API expects this data anyway).

EDIT (2021-04-29): Recently OutSystems updated its documentation for the above. It can be found here, and the reference on the various levels can be found here.

25
0
21 Dec 2017
UserImage.jpg
Davidk

Very cool... thanks.

1
0
21 Dec 2017

It really helpful 

Thanks

1
0
22 Dec 2017

Kilian Hekhuis wrote:

Since this topic comes up every once in a while, I decided to write a quick guide aimed at the beginner level on how to set the Logging Level of an Exposed or Consumed REST API to aid in debugging. This can be useful in case you need to see what's going on when e.g. the server reports an unhelpful "500 Internal Server Error", and you need to see what's going on.

1. Increase Logging Level

  1. Open Service Center of your server and log in.
  2. Chose "Factory" and "eSpaces" from the menu, and search for the right eSpace (the one consuming or exposing the REST API).
  3. Click the "Integrations" tab.
  4. Click on the name of the REST API below "Consumed REST APIs" or "Exposed REST APIs".
  5. Set "Logging Level" to "Full" (there's also "Troubleshoot", but I'm not sure about the differences with "Full").

2. Check the logging

  1. After you have consumed the REST API (either by running the application that consumes it, or running an application (or e.g. Postman) that consumes your REST API, again open Service Center (if it's not already open), en chose "Monitoring" and "Integrations" from the menu.
  2. Optionally filter for the eSpace that consumed or exposed the REST API.
  3. Click "Detail" (the very last column) after the entry you're interested in (note that "Detail" will not appear if you haven't increased the Logging Level).
  4. On the page that appears you can see what has been sent, and what has been replied. If there's more than about a page it's cut off, and you can press the "Download HTTP Trace" button to get a text file with the full trace. Note that in case of binary content, it will be encoded in Base64; to decode it google for "decode base64" and you'll find online tools to decode the data.

That's about it. In case of errors, look for signs that there's something wrong, e.g. missing data, missing authentication headers, malformatted data, etc. Note that by default, the Platform doesn't send data that has the default value, so be aware that depending on the values of the data you send, not everything may appear (which could also be the source of a problem if an external REST API expects this data anyway).

It's really a valuable info..Thanks for sharing!!

Sachin


1
0
22 Dec 2017

Great stuff @kilian sir!!

1
0
02 Jan 2018

Nice contribution!! Good Work!

1
0
09 Jul 2018

Hi Kilian,

Thanks for this post!

May I know what performance issue will be caused by changing the Logging level to "Full"?


0
0
03 Oct 2018

None, really. It's not adviced in production if you have large volumes of REST calls, and/or very large payloads, but on development and test you're pretty safe.

0
0
03 Oct 2018

I cannot find eSpaces area now, 1/11/2019. It seems the interface design is changed

0
0
01 Nov 2019

Pham Chinh wrote:

I cannot find eSpaces area now, 1/11/2019. It seems the interface design is changed

Hi, 

For Personal Environments Espaces is renamed to Modules in Service Center Factory menu.

Regards,

Daniel


2
0
01 Nov 2019

Yes, it was renamed "Modules" in version 11, thanks Daniël for pointing it out. Unfortunately, I can't edit the original post.

0
0
01 Nov 2019

Thank you so much for sharing knowledge.

0
0
01 Nov 2019

Kilian Hekhuis wrote:


2. Check the logging


4. On the page that appears you can see what has been sent, and what has been replied. If there's more than about a page it's cut off, and you can press the "Download HTTP Trace" button to get a text file with the full trace. Note that in case of binary content, it will be encoded in Base64; to decode it google for "decode base64" and you'll find online tools to decode the data.

Thanks for the valuable info, Kilian! That part about downloading HTTP trace is also important as the inner exception is usually not visible in the truncated error message in Service Center.


0
0
25 Nov 2019

You're most welcome Ozan! Happy coding :)

0
0
26 Nov 2019

Stumbled upon this post while wondering the difference between "Troubleshoot" and "Full".

Here are the details from OutSystems documentation:

(https://success.outsystems.com/Documentation/11/Developing_an_Application/Troubleshooting_Applications/Troubleshoot_Service_Actions_Using_Logs#how-to-change-the-logging-detail-level-for-service-action)

The available logging levels for Service Action requests are the following:

Default
All requests are logged including some basic information (like the date and time of the request). No details regarding errors, request headers or payloads are logged.
Troubleshoot
On top of the information kept by the Default level, error details are also logged. Click on the "Error" link displayed on the right to get more details about the error.
Full
On top of the information kept by the Troubleshoot level, request headers and payloads are also logged. Click on the displayed "Error" link or, if there's no error, click on the "Details" link to obtain detailed logging information.

It seems to say "Troubleshoot" has "Full" logging for errors and "Default" for anything else.

1
0
30 Oct 2020

Thanks for the addition Mikko. Though you reference a document for Service Actions, it's the same for REST and SOAP. For SOAP, the documentation is here, for REST, the documentation should be here but it's lacking, unfortunately.

0
0
30 Oct 2020

Hello Guys,

I have an HTTP trace that is not fitting in the txt:

(Consumed REST APIs)


<Message truncated in logging because it exceeded the maximum size>


Logging Level = Full:


Plataform Version 10.0.708.0 


How can i solve? 

is there any configuration to be done on the server or configuration tool so that the entire error message is displayed in the txt trace?


Regards and Thank you.


0
0
15 Dec 2020

Hi Agno,

I haven't seen this before. It seems you are sending very large documents as base64 binary content, which might've triggered this. However, looking at the database table the data is stored, the Detail column has nvarchar(max), which shouldn't have a limit. I'll ask around to see if someone from OS has more information.


0
0
16 Dec 2020
0
0
16 Dec 2020

Its really helpful!!!

0
0
21 Jan 2021

Thank you, glad this old post is still useful :).

0
0
21 Jan 2021

Thanks for sharing, Kilian; very useful!

It's very rare that some Azure APIs work well in test mode. But they don't support some features once executed:

{"error":{"code":"400","message":"Billing Period is not supported in (2019-10-01) API Version for Subscription Scope With Web Direct Offer. Please provide the UsageStart and UsageEnd dates in the $filter key as parameters. (Request ID: fb348927-3232-4b10-8a80-xxxxxxx)"}}

0
0
27 Apr 2021

Well, that error message indicates to me that you didn't send everything as it would expect, so inspecting the full message would indeed be very helpful in troubleshooting. If you still have problems, I'd advise you to start a new topic on the forum, as it's not really related to the original topic of this post.

0
0
28 Apr 2021

Very Nice ... 

Thanks.

0
0
20 Nov 2021

Thank you for sharing!

0
0
20 Oct 2022
Post Closed