Hi Duncan,

The standard lookup tables are the closest thing to what you're looking for but as you noted, they don't support reverse lookups.  I think you will need something custom for this.  The easiest solution is probably to implement a reverse lookup for existing lookup tables.  If you implement a new classmethod to do this in a class that extends Ens.Rule.FunctionSet, then that classmethod will be available to DTLs.


Hi Nupur,

I think solving this problem will take some investigation.  I recommend opening a WRC problem.


Hi Raghu,

Stream objects have an Attributes collection which holds the incoming HTTP headers.  I believe you should be able to check the incoming Content Type with pInput.GetAttribute("Content-Type") but I haven't confirmed this.


The testing form isn't smart enough to handle array or list properties.  The easiest way I've found to test these is to create a  file business service and add code to populate the array with some hard-coded values.  Then add that service to your production, set the file path, and copy any random file into the file path directory to trigger the service.  Here's an example file service to do this:

Class Community.TestArray Extends Ens.BusinessService

  Parameter ADAPTER = "EnsLib.File.InboundAdapter";

  Method OnProcessInput(pInput As %Stream.Object, Output pOutput As %RegisteredObject) As %Status
    set tTestMsg = ##class(MyApp.MyRequest).%New()
    do tTestMsg.idToTokenArray.Insert("One")
    do tTestMsg.idToTokenArray.Insert("Two")
    do tTestMsg.idToTokenArray.Insert("Three")
    quit ..SendRequestAsync("OperationToTest",tTestMsg)


Make sure the 'Enable Standard Requests' setting on the REST business service is checked, Port is blank, and Pool Size is set to 0.  This will ensure the business service only listens for requests through the CSP Gateway and not through its own port.  Be sure to construct the URL for accessing the REST service as described in the documentation here, under "Defining the URL Using UrlMap and EnsServicePrefix":



This is what the Ensemble message viewer does when the search criteria includes a date/time range.

I see $$$TRACE statements in your code, which leads me to believe you are using Ensemble.

What you're trying to do is much easier with EnsLib.EDI.XML.Document, and there are adapters supporting the use of this message class.

Here's an example:

ENSEMBLE>set msg = ##class(EnsLib.EDI.XML.Document).ImportFromString(tData)

ENSEMBLE>w msg.GetValueAt("/")








These are called DOM-style paths as opposed to VDoc paths.  Here's the documentation:


Basic Class Queries are similar to stored procedures.  You can hard-code some query parameters while allowing others to be passed as arguments.  The query is pre-compiled in the code.  With a dynamic query, when you call the .Prepare method, this causes code to be generated at runtime to run the query.

Embedded SQL is also pre-compiled into the code.  One benefit basic class queries have over embedded SQL is that basic class queries can be exposed to SQL, allowing them to be called like stored procedures.

If you use Managed Alerts, there is a custom FunctionSet function IsRecentManagedAlert() which you can use to suppress repeated alerts.  Here's an excerpt from the documentation:

The rule can check whether the alert is a repeat occurrence of a previous alert that is represented by a currently open managed alert. To do this, the rule uses the Ens.Alerting.Rule.FunctionSet.IsRecentManagedAlert() function. The IsRecentManagedAlert() function tests if there is a recent open managed alert that is from the same component and has the same text as the specified alert. You can optionally specify that the function adds a reoccurs action to the existing managed alert.