Discussion
· Oct 6

Debugging REST API in InterSystems IRIS

Hi developers!

How do you debug implementation code in .impl classes of REST.API in InterSystems IRIS?

Especially if you don't have access to globals, so no things like: 

Set ^AAA="here we are"

not possible in this case.

Suppose I have the following signature of the REST.API method called as POST and containing JSON. :

ClassMethod submitForm(formData As %Stream.Object) As %Stream.Object
{

return formData

}

Can I debug "line by line" or "command by command"?

Can I return anything to the browser's console? Or into any IRIS expected place, which is relatively easy to check?

What are my options? 

Please, share your experience?

Discussion (23)4
Log in or sign up to continue

3 variants come to my mind

  1. writing to ErrorLog  Do LOG^%ETN()
  2.  write to Systrem message.log
     set %evgeny=$io
     open 1 use 1 write !,"Was in my REST code",! close 1
     use %evgeny
  3. If you have a terminal session  LOCK  ^%EVGENY --- And into your code, add this simple loop 
  4.  for  LOCK +^%EVGENY QUIT:$TEST   HANG 0.5
    Now your method loops, and you can attach with any external debugger. Releasing the LOCK from Terminal does the "un-freeze"

Hi @Brett Saviano !

Tried it!

Here is the feedback:

1 - can we add the link to the VSCode extension to be installed? I spent some time before I understood that, besides InterSystems ObjectScript, I need to install a special ObjectScript Extension pack .

2 - to make a REST API call I need to fill all the fields manually. Even I have an Open API spec class. Is it possible to read from it and provide all the fields ready to for tests? Filed a task and an idea.

3. Wasn't able to start debugging: faced the following error:

Thank you, @Robert Cemper !

This works like a charm! 

So, in my case, I also wanted to see what's in a stream object that comes into the method (you may ask me how I don't know this, as it is method I coded? ) I don't, as it is a generated one via %^REST):

ClassMethod submitForm(formData As %Stream.Object) As %Stream.Object

{

set formDataObj= {}.%FromJSON(formData.Read())

k ^SPOOL s %io=$I O 2 u 2 do formDataObj.%ToJSON() c 2 u %io

return $$$OK

And then I do a REST API call and can see data in the terminal with zw ^SPOOL global:

USER>zw ^SPOOL
^SPOOL(1,1)="{""amount"":0,""name"":""John Doe"",""taxid"":""AB123456C"",""nationality"":""british"",""email"":""john.doe@example.com""}"
^SPOOL(1,2147483647)="{67504,40535{2{"

Simple and easy! Fantastic, @Robert Cemper !

Given that the routes in your enabled %CSP.REST class point to class methods you should be able to debug/step thru line by line by calling the class method.  In the case where you might have a POST/PUT for your route that calls the class method you can always define the formal specificaiton of the class method to accept parameters and then have the code in your class method look at either your parameter values or %request.Data to determine if the class method is being called by a Http call or your simple debugging.

@Stephen Canzano , when you are testing you can also manually define %request and give it a body and whatever else it needs before you call your class method. For instance:

set %request = ##class(%CSP.Request).%New()
set %request.ContentType = "application/json"
set %request.Method = "POST"
set %request.Content = ##class(%CSP.CharacterStream).%New()
set json = {}.%New()
set json.firstname = "David"
set json.lastname = "Hockenbroch"
do %request.Content.Write(json.%ToJSON())

Then you can call your class methods and the %request object you usually manipulate in those methods will be defined.

Calling the methods this way is effective for testing the methods, yes. You just want to get really familiar with the %CSP.Request class. This approach isn't a good way to troubleshoot issues with your routes, or with authentication, though, as it bypasses those steps. For that, you'd probably have to define %request appropriately, then call some of the methods your API inherits from %CSP.REST, but I'm not as familiar with those.