Hi Bill, I was facing a similar (but not identical) issue not too long ago where I was trying set %response.Status in my REST handler class, only to have a different status code reflected in the response to the client.

The issue ended up being that the request to the REST handler class that I was working on was being forwarded from another REST handler class that extends EnsLib.REST.Service rather than %CSP.REST.  The EnsLib REST handler works a little differently.  The user code is supposed to write the output to a response stream, with the response headers being set as attributes of the stream, rather than setting headers of %response directly.

So my question is, is your REST handler downstream from an EnsLib.REST.Service REST handler?  I also see that your REST handler extends Ens.BusinessService.  I wonder if something in that class is overriding your %response headers.  Is there any way you can test your class with that superclass removed?

I'm not sure in what version %JSON.Adaptor was introduced, but if it's in your version, you can have the class modeling your object extend %JSON.Adaptor, which will give you access to the %JSONImport() method, which can de-serialize a JSON payload into an object.

One caveat to this is that I believe any serial objects referenced by the top-level object will also need to extend %JSON.Adaptor for the import to work properly.

Assuming that tSC is a %Library.Status, I don't think this will work the way you intend it to.  The argument to a THROW has to be an oref to a class that extends %Exception.AbstractException:
If you have a %Status that you need to throw as an exception, you can use $$$ThrowOnError or $$$ThrowStatus, both defined in They both call ##class(%Exception.StatusException).ThrowIfInterrupt(), but $$$ThrowOnError only does so if the status is an error, so it's slightly more efficient if you haven't checked the status yet.

Jorge has not followed anybody yet.
Global Masters badges:
Jorge has no Global Masters badges yet.