Thowing errors and raising alerts
Hi InterSystems Community
We recently had an issue where we weren't able to parse a JSON HTTP request, but the issue went by unnoticed. We also did not have a trace of what the raw HTTP request was that we couldn't parse. I'm looking at improving our this by:
Tracing the raw request using $$$TRACE
Raising an alert which will hit our Ens.Alert router which will compose and send an email
I'm having an issue with consistently raising the alert (I've seen it raise an alert before, and then it wouldn't raise it again on a subsequent message), and also the error back does not really make sense. Here's our class that handles the raw request and passes it to our BusinessService Class (shortened for brevity):
Class Phu.EventBus.BusinessService.JsonHttp.RestAdapter Extends %CSP.REST
{
ClassMethod EventNotification() As %Status
{
Set tSC=$$$OK $$$ThrowOnError(##class(Ens.Director).CreateBusinessService("EventBus_JsonHttp",.tBusinessService)) $$$ThrowOnError(tBusinessService.ProcessInput(%request, .tBusinessServiceOutput)) Return tSC
}
}
And our Business Service Class:
Class Phu.EventBus.BusinessService.JsonHttp.ReceiveEvent Extends Ens.BusinessService
{
Method OnProcessInput(pInput As %Stream.GlobalCharacter, Output pOutput As %Stream.Object) As %Status
{
set rawRequest = pInput.Content.Read()
do pInput.Content.Rewind()
set tEventNotification = ##class(Phu.EventBus.Events.EventNotification).%New()
$$$ThrowOnError(tEventNotification.%JSONImport(pInput.Content))
$$$ThrowOnError(..SendRequestAsync("Router_EventBus",tEventNotification))
return $$$OK
}
}
Even with the production item setting "Alert on Error" set to true, this does not raise an error when I send in a badly formed request (typo in a property name). Also, the error back looks empty:
{
"errors": [
{
"code": "<Ens>ErrException",
"domain": "Ens",
"error": "ERROR <Ens>ErrException: -- logged as '-' number - @''",
"id": "EnsErrException",
"params": [
" -- ",
"-",
"- @''"
]
}
],
"summary": "ERROR <Ens>ErrException: -- logged as '-' number - @''"
}
Apologies for the really long post!
Comments
You can improve this in two separate ways:
- write diagnostic information to the Event Log / trace output, and
- generate alerts when you need active notification. [1]
For logging and tracing inside production-related code, the documented macros are $$$LOGINFO, $$$LOGERROR, $$$LOGWARNING, $$$LOGSTATUS, $$$ASSERT, and $$$LOGASSERT. These write Event Log entries of the corresponding types. The documentation also describes tracing as something you add in applicable parts of production code to help with debugging and diagnosis. [1]
Important: If you need to notify users actively about certain conditions or events, use alerts, which are discussed in Generating Alerts and in Defining Alert Processors. [1]
So for your raw request capture goal, the supported guidance in the returned material is to add logging/trace statements in the relevant business host code where you want runtime information recorded. For example, logging the raw request text before attempting the JSON import would fit that model. [1]
For your alert expectation, the returned documents do not include enough information to explain why "Alert on Error" is not firing consistently in your specific flow, nor do they document the behavior of %JSONImport for a typo in a property name, or the meaning of the ERROR <Ens>ErrException: -- logged as '-' number - @'' response in this context. The available material only states that alerts are the mechanism to use when active notification is required, but it does not provide the implementation details needed to diagnose your case. [1]
If you want clearer error details returned from your own code path, one relevant pattern shown in the returned material is to create a formatted %Status, for example with $$$ERROR(..., $$$FormatText(...)), and to convert thrown exceptions back to %Status with ex.AsStatus() in Catch blocks. That pattern is shown as a general ObjectScript tip, but the returned material does not specifically tie it to Ens.BusinessService alert generation behavior. [2]
Because of that, I can only safely suggest the following based on the returned documents:
- add Event Log entries around the parsing step using
$$$LOGINFO,$$$LOGERROR, or$$$LOGSTATUS[1] - add trace elements in the relevant production code paths to capture the incoming request content for debugging/diagnosis [1]
- use alerts when you need active notification to users/operators rather than relying only on log entries [1]
- if you want better error text, construct and return a more explicit
%Statusmessage rather than relying on the current generic exception text [2]
I cannot confirm from the returned documents why your malformed request is not producing repeat alerts, whether a misspelled JSON property should count as an error in %JSONImport, or exactly why that EnsErrException payload is so empty. [1][2]
Sources: