Hello everyone

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.

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

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

Thank you Vic, Nigel and Eduard !

It seems that adding "Ens_Util.Log", as suggested, was useful.

Best regards,

Mathieu