That is already true as seen in Vitaliy's comment above. Personally, I prefer to use {}.%New() and then use the %Set method because you can provide a third argument to explicitly say whether the value you are adding is a number, string, boolean, stream, etc. to eliminate any ambiguity. We have alphanumeric fields that should be considered strings, but if they happen to be all numbers, they are incorrectly inserted as numeric values in JSON if we don't specify.

If you have Auditing turned on, you can check your audit log for login failures in system management portal. That will tell you why the login failed, which might point you in the right direction.

It might be nice to make such tracking conditional. Like "Log all queries that take over 10 seconds to run" or whatever number is appropriate for your usage.

Page not found, or Invalid Action? If it's page not found, how is the web application configured?

@Enrico Parisi , with Global Masters, we get a few points for having an answer marked as correct on the community. People often only mark the first correct answer they see. So if the user who posted the question didn't see this thread before the AI bot's post appeared, it's somewhat likely that the bot's post will be marked as the correct answer even though a human user answered the question first. That's all. Seems just a little unfair to me.

@DC AI Bot 
When I checked on this post earlier today, Vitaliy's correct answer was here, but the AI Bot's was not. Now it's showing here as if the AI Bot's answer was first. That is troublesome, particularly if Vitaliy is a Global Masters user.

Maikel, if your variable is named var in your ObjectScript code, then you would use where xyz = :var in the embedded query. The colon marks that this is a host variable.  

I'm not totally clear on what you're trying to do, but I have a feeling you might want to replace "quit" with "return status". Inside a catch block, a quit command will quit just the catch block and code execution will continue after it. Replacing that with return status would make the code execution stop right there, returning the error.

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.

And in addition to all of that, one of the workarounds people seem to like using is to have things comma-separated and enclosed in " to make sure it's getting the right commas, but I'm working on ERP software for the millwork industry in America. We're still allergic to metric here, and we use " to mean inches and ' to mean feet, so we can't use those either!

I know it's odd, but I've had three separate companies ask me for data formatted this way in the past couple of years. I'm not sure why, other than that the pipe is less common to run into within the data than commas.

@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.

@Evgeny Shvarov it's like this:

try{
    //Do things here
}
catch ex{
    do ex.Log()
    return ex.AsStatus()
}

If you do this, then the error gets logged in the application error logs in the system management portal, and a JSON representation of the exception gets returned through the API.

@Theo Stolker I'm not sure what you mean by, "I never liked the different behavior of embedded sql, like when you have no result, you have no easy way to find that out." When you run an embedded query, it sets a variable called SQLCODE. If SQLCODE = 0, query completed with results. If SQLCODE = 100, query completed with no results. If SQLCODE < 0, there was an error with the query.