New post
AllAccepted answers
Sean Connelly · Jun 8, 2022

I think you might have missed my point about the adapter being non standard.

E.g. what if the adapter has code like this...

Method OnTask() As %Status
{
    //Set tSC = ..BusinessHost.ProcessInput($$$NULLOREF)
    Set tSC = ..BusinessHost.General($$$NULLOREF)
    Set ..BusinessHost.%WaitForNextCallInterval=1
    Quit tSC
}

The normal sequence of

OnTask() → ProcessInput() → OnProcessInput()

becomes

OnTask() → General()

Of course this then raises the question, how does the interval then work as it would most likely only run once.

Main point is to check if the adapter has hard wired it in directly. It's the only logical explanation outside of this being an observer error.

Sean Connelly · Jun 8, 2022

Sounds very odd. The adapters OnTask would call the bussiness hosts ProcessInput and this would call OnProcessInput(). If the service is standard then how General() gets called is an oddity.

My only thought (other than observer error) is that the service has a non standard adapter implementation.

If you look at the adapter, does its OnTask call ProcessInput(), or is it hard wired to call General() ?

Sean Connelly · Apr 23, 2022

Hi Scott,

My understanding is that search table classes are maintained in Ens.DocClassMap. When you do a purge the Ens.MessageHeader appears to have the responsibility for calling RemoveSearchTableEntries() on the Ens.SearchTableBase which uses indirection to call RemoveIndex() on the class name maintained in the DocClassMap.

The docs briefly mention DocClassMap...

The Ensemble classes use this class to remove search table entries when message bodies are deleted.

https://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=EEDI_search_tables#EEDI_search_tables_mgmt

Short answer, purges will automatically include new search tables even if you scheduled the purge before creating the search table.

Sean Connelly · Apr 20, 2022

Hi Thomas,

This really depends on how the downsteam SOAP service has been implemented.

On the surface it sounds as if you are using an out-of-date URL.

If you are getting a 301 then you should look at the response headers to see if there is a "Location" value in the headers, if this is present then try using that URL.

A 301 could also be implemented outside of the HTTP standard, so as an example, a third party developer might use it as a way to indicate a resource has moved, so the ID in your XML could be wrong (please take this just as an example).

My feeling is probably check the URL first to see if you are using the correct up-to-date location value. If its not that then contact the third party API developer for a more detailed reason.

Some additional tips if you need them...

1. Use the SOAP log to check the response headers, documentation here...

https://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=GSOAP_debug#GSOAP_debug_info_soap_log

2. Not related to the 301, but noticed you are escaping XML by hand, there is a function to do that...

https://docs.intersystems.com/ens201815/csp/docbook/Doc.View.cls?KEY=RCOS_fzconvert

Cheers,
Sean.

Sean Connelly · Sep 24, 2021

If you are not re-generating the operation code then I wouldn't be worried to change it if required.

The implementation class will be on the adapter..

Property %Client As %SOAP.WebClient;


So if for instance you change the SOAP version (should that make a difference) then it could be done with

set ..Adapter.%Client.SoapVersion="1.2"


First though, I would enable the SOAP log and compare the headers to your working SOAP UI headers.

Sean Connelly · Sep 24, 2021

Hi Kurro,

Some random suggestions without being able to see the implementation details...

1. Enable the SOAP log and compare the request and response headers to SOAP UI to see what is different

https://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=GSOAP_debug#GSOAP_debug_info_soap_log

2. Does changing the SOAP version make any difference

https://docs.intersystems.com/latest/csp/documatic/%25CSP.Documatic.cls?LIBRARY=%25SYS&CLASSNAME=%25SOAP.WebClient#PROPERTY_SoapVersion

3. The error is probably raised in this block of code, might be worth working backwards from there, its at the end of DoSOAPRequest in %SOAP.WebClient

    Set responseContentType=$zcvt($piece(response.ContentType,";",1),"L")
    If ..SoapBinary {
        If (responseContentType'="application/octet-stream") Quit $$$ERROR($$$SOAPUnexpectedType,response.ContentType)
    } Else {
        If (responseContentType'="text/xml") && 
           (responseContentType'="application/soap+xml") &&
           (responseContentType'="multipart/related") {
            Quit $$$ERROR($$$SOAPUnexpectedType,response.ContentType)
        }
    }

4. If your running out of ideas then maybe reinstall / restart the server code (is it .NET by any chance)?

Sean Connelly · Sep 17, 2021

It depends what you really need.

SYSTEM MODE

There are existing global flags that are available through various classes. For instance SystemMode() will provide system wide constants for Live, Test and Dev...

https://docs.intersystems.com/healthconnectlatest/csp/documatic/%25CSP.Documatic.cls?&LIBRARY=%25SYS&CLASSNAME=%25SYSTEM.Version

The SystemMode() is admin configured via the Memory and Startup screen on the management portal.

LOOKUP TABLES

For some global settings, particularly business related, it would be good practice to use lookup tables and not a global...

https://docs.intersystems.com/latest/csp/documatic/%25CSP.Documatic.cls?&LIBRARY=ENSLIB&PRIVATE=1&CLASSNAME=Ens.Util.LookupTable

UTIL FUNCTIONS

Also, if you are not aware of them yet, you should take a look at creating your own Ens util functions which are automatically inherited into routers and DTL's and provide a good place to stash various levels of global and business value / logic...

https://docs.intersystems.com/latest/csp/documatic/%25CSP.Documatic.cls?&LIBRARY=ENSLIB&PRIVATE=1&CLASSNAME=Ens.Util.FunctionSet

https://docs.intersystems.com/latest/csp/docbook/Doc.View.cls?KEY=EBUS_utility_functions