I vote for #1 (except need to  'grovel' and hope to work towards removing that sentiment)

Here are some proposed enslib fixes and an example of using a custom search table to index data from the generic message that can be used in the current message search. The following is not intended to detract from the need to amend enslib code to prevent a headache by allowing searching for data within GenericMessage objects out of the box.

For the hard coded EnsLib.HTTP.GenericMessage:

In EnsLib.HTTP.GenericService:

Adding:

Property MessageClass As %String [ InitialExpression = "EnsLib.HTTP.GenericMessage" ];

Expose via Settings by including in SETTINGS parameter

MessageClass:Basic:selector?multiSelect=0&context={Ens.ContextSearch/SubclassOf?class=EnsLib.HTTP.GenericMessage&include=1}

Amend hard coded line to:

Set tRequest=$classmethod(..MessageClass,"%New",pRequestBody,,pRequestBody)

The SETTINGS include=1 is another limitation correction arising from this as Ens.ContextSearch/SubclassOf does include the super class parameter

Ens.ContextSearch method SubclassOf add the super class as a valid choice

If tClass '= "" {
    If $G(pParms("include")) Set pResults($I(n))=tClass

We ought to also expose the SearchTable property since this would allow indexing data from the source without creating a custom service to merely set the SearchTable class.

Adding to SETTINGS parameter:

SearchTableClass:Basic:selector?multiSelect=0&context={Ens.ContextSearch/SubclassOf?class=Ens.CustomSearchTable}

Example of a CustomSearchTable class:

Class JGM.CustomSearchTable Extends Ens.CustomSearchTable
{
Parameter DOCCLASS = "EnsLib.HTTP.GenericMessage";
/// This is the case id from the REST payload
Property CaseId As %String(MAXLEN = "");
Index CaseIdIdx On CaseId;
/// Example to index a JSON path value from the Stream property
ClassMethod OnIndexDoc(pDocObj As %Persistent, pSearchTable As Ens.CustomSearchTable) As %Status
{
    Set sc = $$$OK
    Try {
        Set json = {}.%FromJSON(pDocObj.Stream)
        Set caseId = json.%Get("case")
    } Catch ex {
        /*  can decide if want to populate sc from ex 
            if do not want to suppress error
        */
        Set caseId = "UNKNOWN"
    }
    /* Can prevent saving a search table entry if appropriate */
    If (caseId = "UNKNOWN")||(caseId = "") {
        Set pSearchTable=""
    } Else {
        Set pSearchTable.CaseId = caseId
    }
    Return sc
}

One can use a Transformation to populate pSearchTable in OnIndexDoc but still need to create the search table class with properties and hard code the transformation in the search table class.

my mistake the current non persist code does require Sync due to a missing check for no  request header created in Ens.BusinessService::SendRequestAsync() [there is such a check in SendRequestSync()]. I'll correct that.

Apologies if too late but I tried the following based on the Non Persistence option used in the EnsLib.HTTP/REST/SOAP Generic classes (also see  Accelerate Ensemble)

1. Custom TCP Service Extends EnsLib.HL7.Service.TCPService:

Class Community.NonPersistService Extends EnsLib.HL7.Service.TCPService
{

Parameter SETTINGS = "PersistInProcData:Additional";

/// Persist data to operations with invocation InProc<br/>
/// The default is On. <br/>
/// This setting is only used if calling an operation with invocation InProc. <br/>
/// If this setting is off then no message headers will be created and message bodies will not be saved.<br/>
/// If this setting is off there will be no trace in the message viewer. <br/>
/// If this setting is off there will be no retry attempts by the operation - only one attempt will be made. <br/> 
Property PersistInProcData As %Boolean [ InitialExpression = 1 ];

Method OnInit() As %Status
{
    Set $$$EnsInProcPersist=..PersistInProcData
    Quit ##super()
}

}

2. Custom HL7 File Operation invoked InProc that is the target of the service

Class Community.InProcOperation Extends EnsLib.HL7.Operation.FileOperation
{

Parameter INVOCATION = "InProc";

}

Note the property description from EnsLib.HTTP.GenericService for PersistInProcData states for synchronous sends but this needs to be removed since not relevant for InProc. Sufficient that InProc target processed via OnMessage.

How about using Work Queue Manager framework in conjunction with a BS?

Pick up a message but do not delete before we start processing since we are not going to record anywhere permanently that we are working on it.
Check if message queued in current lifetime temp list.
If already queued skip.
If not already queued:
    mark as in progress for duration of this container lifetime
    queue up for Work Queue Manager to process.
    use callbacks to say finished and delete the message.perhaps also give back answer as well.
We then also have auto scaling using the WQM framework if I am not mistaken.

It is possible for a BS to have more than one job  - the issue becomes how to control the multi process access to the inbound feed in an orderly manner. Hence as you asked it is  important  to know how the BS is pulling data.

Eduard, Is the  rate at which one BS can process known or is it variable based on data unit to be processed? Similarly is the rate of arrival known or possible to detect? If possible to know these 2 rates they could be used to control BS count rather than CPU (a tight looping BS looking for work could skew CPU test comes to mind)

Is the design to have all the processing of a data unit in the BS rather than pass to a BP/BO?

James

NB: there is a variation on pool size meaning for a BS using TCP based listening adapter where there can only be one listener but when Job Per Connection is true pool size setting is used as the maximum allowed number of concurrent connections created by the listener.

Perhaps also you can limit calling the Shouldxxx()  based on update production timeout (for example) rather than checking every request in the collection.

James

Greetings, When using the EnsLib.SOAP.InboundAdapter to provide the SOAP service on a dedicated TCP port one is bypassing the Web Gateway and hence %session is not available. (SOAP InboundAdapter docs)

I am doing work with Caché LDAP support  and am benefiting from using the  Apache DS and Apache Directory  Studio plug-in (http://directory.apache.org/studio/update) with Atelier.

See class method EnsLib.Testing.Service::SendTestRequest() that allows one to issue the test from terminal without having to add another component.

classmethod SendTestRequest(pTarget As %String, pRequest As Ens.Request, ByRef pResponse As Ens.Response, Output pSessionId As %String, pGetReply As %Boolean = 0) as %Status

    Send a test request to the specified target host (BusinessProcess or BusinessOperation).