Check this article on delegated authentication.

I am setting the software defined username in the Properties("Comment") array and wanting to reference it in the Rest Service Dispatch class.

Do you see delegated user getting created?

Properties("Comment") should be available as this user Comment property.

is there a way to return more specific messaging regarding the failure to the calling web application?

iirc both ZAUTHENTICATE main entry point and GetCredentials entry point return %Status so you can pass the error there.

You can use this SQL directly:

SELECT COUNT(1)
FROM Your.Table

Or if you want to pass class name as an argument, you can wrap it in SQL procedure:

Class Utils.Dictionary
{

/// Call from SQL: SELECT Utils.Dictionary_GetExtentSize('Utils.Persistent') As ExtentSize
/// write ##class(Utils.Dictionary).GetExtentSize("Utils.Persistent")
ClassMethod GetExtentSize(class) As %Integer [ SqlProc ]
{
  /// Convert class name to table name.
  /// You can skip this step if you have table name already
  #define ClassSQLTable(%c) ($$$comClassKeyGet(%c,$$$cCLASSsqlschemaname)_"."_$$$comClassKeyGet(%c,$$$cCLASSsqltablename))
  set table = $$$ClassSQLTable(class)

  /// Quoter2 is called to escape table name if required
  set table = ##class(%CSP.UI.Portal.SQL.Home).Quoter2(table)

  /// Execute dynamic SQL
  /// Really %sqlcq.<NAMESPACE>.cls<NUMBER>
  #dim rs As %SQL.ISelectResult
  set rs = ##class(%SQL.Statement).%ExecDirect(,"SELECT COUNT(1) AS extentSize FROM " _ table)

  /// Get first result
  do rs.%Next()
  set extentSize = rs.extentSize

  quit extentSize
}

}

And call like this:

SELECT Utils.Dictionary_GetExtentSize('Utils.Persistent') As ExtentSize

Can you elaborate on your data model? What are your two tables, and what information joining them  generates.

Consider the following database: it has clients and products -and each client and each product has a guid.

The join between clients and products would mean semantically - what client bought which products.

But it's probably be better to store this information in another table - orders and just add properties/fk/relationships to clients and products.

You want GUIDs - a mark of persistency,  but you want them in a transient query. I think it would be better to create another table and populate it with the relevant data and new  GUIDs and return that new GUIDs.

Another approach would be exposing hash function as an sql procedure and passing both GUIDs into it and returning a hash to a client.

This is not what the customer wants. He have a use case where he only needs to be able to create and decompress raw DEFLATE-compressed content.

What's the use case?

 

Also, why use node instead of just calling zlib directly:

zlib deflate string ?level?

I'm not talking about callout here (which could also be another valid approach) but just direct $zf(-1, "zlib ...") call

Can you please provide example of OnValidate?

Here's what I tried and it does not work:

Class Test.InboundAdapter Extends Ens.InboundAdapter
{

/// Stream class to store message body. Leave empty to use strings.
Property BodyClass As %Dictionary.CacheClassname;

Parameter SETTINGS = "BodyClass:Basic";

/// Does not get called.
Method OnValidate(args...)
{
    merge ^b = args
    quit $$$ERROR($$$GeneralError, "Some error")
}

/// Runtime only. And $username is always _Ensemble. ##super() is in Ens.Settings
Method AssignOneSetting(pProperty As %String, pValue As %String, pName As %String) As %Status
{
    set ^c($i(^c)) = $lb(pProperty, pValue, pName, $username)
    quit ##super(pProperty, pValue, pName)
}
}

You can give user %EnsRole_Operator role:
Role for operation staff managing the day-to-day status of a particular production. Users assigned to this role have the Read permission on the current configuration to determine what settings and code are in effect, but do not have permissions to modify the configuration. Operations staff may start and stop interfaces, and may start and stop the production. They do not have access to the contents of messages, but may resend messages which cause issues. Operators may view queue and job information, and may inspect the settings for purges, alerts, credentials, and lookup tables.

Other approach would be readonly access the tables of the Ens.Config package.