Hello Vic, sorry for the delay. We checked and tested many things and nothing seemed compliant for understanding what was going on.

However, the entire flow has been accepted since about 1 week ago, including previously blocked messages, although no one told me to have changed/restarted anything in configurations or network parameters. So it is very strange, but we could stop thinking about this problem for now (and begin working on other ones). The joys of computing...

Thank you again for your support !

Well, here is an update. Following Vic's answer, we were able to make the warnings disappear ("Discarding received non-HL7 data...") although we were already working with MLLP on both sides (sender <--> receiver).

The flow still blocks sometimes though. It occurs with particular messages because abandoning them allows the flow to become running anew (and this flow blocks again when those messages are put back in it). I think that it does not mean that there is no problem in the network anymore, because the receiver is able to process those blocking messages manually. But we could at least put them apart and so not to let the entire flow be blocked.

Maybe could I reply here once more if we find other clues (or even the solution). But at this time we will probably act as I have just described, processing blocking messages manually, and maybe that putting them apart will allow us to find similarities giving us advices for the real solution.

BR smiley

Hello Vic and thank you for your answer ! I transferred it to the receiver of the messages and he could made a change on the settings concerning the ACK messages that are sent back. Although I have no details about the change itself, the flow was up and running after that. It is not yet for a long time ago, so I will continue checking this flow during the next days, but at first sight it seems that the problem is solved.

Best regards :-)

Thanks again to you all,

We have actually built the stream ourselves, helped with some tricks got from the internet, and it seems to work within our test environment. Here is the pseudo-code for memo:

Method OnRequest(request As %Library.Persistent, Output response As %Library.Persistent) As %Status
{
              set httpRequest = ##class(%Net.HttpRequest).%New()
              set httpRequest.Server = "(...)"
              set httpRequest.Port = (...)
              Set filename="(...)"
              Set file=##class(%File).%New(filename)
              Do file.Open("RU")

              Set sc=fileStream.CopyFrom(file)
              Do file.Close()

              do fileStream.Rewind()

              set myStream = ##class(%Stream.TmpCharacter).%New()           
              set startJsString = "{""document"":{""id"":""@GUID@"",""language"":""fr"",""patient_id"":""@NDOS@"",""doc_type"":""@DOCUMENTTYPE@"","    //...and so on
              set startJsStringData = $REPLACE(startJsString, "@GUID@",  request.id,     1, -1, 1)
              set startJsStringData = $REPLACE(startJsStringData, "@NDOS@", request.patNdos ,     1, -1, 1)
              //...and so on          

            do myStream.Write(startJsStringData)

            s startJsContentString = """sections"":[{""section_id"":""main"",""content"":"""
            s endJsString = """}]}}"

            do myStream.Write(startJsContentString)
            set sc = ..Base64Encode(fileStream, myStream,,1)
            do myStream.Write(endJsString)
            do myStream.Rewind()        

            set len = 32000
            While (len > -1) {
                set sRead = myStream.Read(.len)
                do httpRequest.EntityBody.Write(sRead)
            }

            set sc=httpRequest.Post("/index/push", 0)

}

ClassMethod Base64Encode(tIn As %Stream.FileCharacter, tOut As %Stream.TmpCharacter, chunk As %Integer = 32000, Flags As %Integer = 1) As %Status
{
   set sc = $$$OK
   if $g(tIn)="" quit $$$ERROR(5001, "Input stream required")
   if '$IsObject(tIn) quit $$$ERROR(5001,"Input is not a stream object")
   if 'tIn.%IsA("%Stream.Object") quit $$$ERROR(5001,"Input object is not a stream")
   if 'tOut.%IsA("%Stream.Object") quit $$$ERROR(5001,"Output object is not a stream")
   set chunk=chunk-(chunk#3)
   do tIn.Rewind()
   While 'tIn.AtEnd {
    set sc= tOut.Write($SYSTEM.Encryption.Base64Encode(tIn.Read(chunk),Flags))
    if 'sc Quit
   }
   Quit sc
}

Best regards

Hello Katherine, thank you for your answer.

First just FYI, SuperServer SSL/TLS was already enabled and I have changed (back) the enabled protocols to match the default ones.

Then I have done the suggested tests; here is what I found in cconsole.log:

tpopen for host  device number 1972 port 1972  mode 0x208 tcpmode 0x0 terminators  ibfsz 1024 obfsz 1024 queuesize 5 timeout 2 tcpsbuf=0 tcprbuf=0, XY=on, BINDTO=
NETSEC_AcceptServerContext
netsecAcqSrvCred
netsecAcqSrvCred --> returns 1
netsecAcceptServerContext(ddbp=0xbbe1d4f0)
AcceptServerContext: peek saw no preamble
SSL/TLS configuration: %SuperServer
Cipher list: ALL:!aNULL:!eNULL:!EXP:!SSLv2
Certificate file: C:\chr11614pem\chr11614.pem
Setting private key file encryption password
Private key file: C:\chr11614pem\chr11614.key
Trusted certificate file: C:\chr11614pem\DigiCertCA.pem

Peer verification option = 1, certificate depth = 9
SSL/TLS server requested.
Verify error with X.509 certificate at depth 0
Subject: /C=BE/L=Liege/O=CHR de la Citadelle/OU=IT/CN=*.chrliege.be
Issuer: /C=NL/ST=Noord-Holland/L=Amsterdam/O=TERENA/CN=TERENA SSL CA 3
Error: 20, unable to get local issuer certificate
SSL/TLS error return from SSL_accept().
SSL_ERROR_SSL: protocol error
error:14089086:SSL routines:ssl3_get_client_certificate:certificate verify failed

...So we can see some explanations, although I don't know yet how to fix this. What seems weird to me is the "empty" host name in the first line (in other connection attempts I can see for example "tpopen for host CHR11832 device number 2120 port 2120" etc.).

Don't hesitate to tell me if you know what could help me smiley

Best regards

Hello everyone smiley

Well it seems that being able to reach the webapp via HTTPS does not secure the TCP messages between the remote CSP Gateway and the main Ensemble server (port 1972).

Until now in the gateway I did not use the "SSL" connection security level in the server configuration page, so I guess I have to do it now.

So I have filled in the related fields, in the way described in the 1st picture from the 1st post of this topic. And following the link and advices from Katherine and Eduard that were previously given in the answers here, I have also created the %SuperServer configuration in the main server, as described in the picture below:

But then I get an error 500 ("Server is currently unavailable").

Do you know where it could come from ?

Best regards.

Hello Katherine, thank you for your answer.

I have configured Apache in my server S2, and it seems to work as expected now, after having added those lines to httpd.conf :

LoadModule ssl_module modules/mod_ssl.so
Listen 443
<VirtualHost *:443>
    ServerName myhost.mydomain.be
    SSLEngine on
    SSLCertificateFile "D:/pathToMy/certificate.cer"
    SSLCertificateKeyFile "D:/pathToMy/certificate.key"
    SSLVerifyClient optional
    SSLVerifyDepth 1
    SSLCACertificateFile "D:/pathToMy/certificateCA.crt"
</VirtualHost>

Best regards :-)

Thank you for your quick answer. By the way, we actually managed to process the display of the app' in the new server from the other one without configuring IIS on the new server but only configuring its CSP Gateway (describing the other server and so on).

Now we are wondering how to allow the "https" feature to this application offered in the new server within http for now, but I guess it could be a subject for another topic...

BR