Thanks for the hint. In the past it was the port of the packaged webserver, that is true. Meanwhile we're using the Apache server that comes with the distribution's package manager in combination with the Intersystems webgateway. We're just using the same port configuration. I hope this at least alleviates the problem described, but unfortunately does not change the problem that all web apps, including the management portal, are addressed via the same port.

Thank you for your explanations. The procedure you described sounds somewhat complex, but (as ultimately proven by your report) feasible. Together we are 5 colleagues who deal with the development and administration of interfaces in addition to other topics. We would need external help from our systems department to set up a certificate-based access procedure. I can see the day coming when the certificate has expired or something else has happened and we have locked ourselves out with no way of quickly re-establishing this access on our own. But thanks again for the suggestion, I will definitely look into whether this could be an option for us.

Thank you very much for your feedback. After some back and forth and failed attempts, I have now decided on a different approach. The reasons for this are on the one hand that an export of all 133500 records would take something like 12h and in case of an error all preliminary work is gone.
Furthermore, even with 1000 records the transfer to a FHIR bundle again ran into a STORE error. All in all it is more reasonable to split the export into smaller packages. I got a handle on the problem by now initiating export at 500 objects and persistently storing the IDs of the handled records so they can be ignored on the next run.
The process is called on a timed basis every 5 minutes and works in chunks until all resources are exported. This runs since 1h now, and looks good so far.

Regards, Martin

Yes, it took a while to find the solution as writing files did not cause problems. It came out, that the port for the lockd process is dynamically negotiated. We configured nfs to use a static port and opend the port in the firewall at the host system and the problems were gone. So you were right with the suggestion to search on OS-level.

Thanks for your help.

This is how I translated and simplified your example:

Method OnRequest(pRequest As Ens.Request, Output pResponse As Ens.Response) As %Status
{
	#dim tSc = $$$OK
	#dim tConvertedStream as Ens.StreamContainer
	#dim tStream as %Library.GlobalBinaryStream
	if ( pRequest.%IsA("EnsLib.HTTP.GenericMessage") ){
		set tConvertedStream = ##class(Ens.StreamContainer).%New()
		set tConvertedStream.Stream = ##class(%GlobalCharacterStream).%New()
		set tSc = tConvertedStream.Stream.CopyFrom(pRequest.Stream)
		set tConvertedStream.OriginalFilename = $Piece(pRequest.HTTPHeaders.GetAt("RawParams"),"=",2)
		
		set tStream = ##class(%Library.GlobalBinaryStream).%New()
		set tSc = tStream.Write("<html><head><title>Server Response</title></head><body><h1>This is your response</h1></body></html>")
		set tSc = tStream.%Save()
		
		set pResponse = ##class(EnsLib.HTTP.GenericMessage).%New(tStream,,pRequest.HTTPHeaders)
		do pResponse.HTTPHeaders.SetAt("HTTP/1.1 200 OK","StatusLine")
		do pResponse.%Save()
	}
	
	return tSc
}

It works like expected:

that is exactly what I needed to continue.

Thank you very much for your help,

regards,

Martin

Hi Oliver,

thanks a lot for your help. Your assumption is right, but at the moment I'm following the approach to write some COS Code to solve the task.

Class UKEr.BP.FHIR.HttpContsentRequestProcess Extends Ens.BusinessProcess
{

Method OnRequest(pRequest As Ens.Request, Output pResponse As Ens.Response) As %Status
{
	#dim tSc = $$$OK
	#dim tResponse as %Net.HttpResponse = ##class(%Net.HttpResponse).%New()
	set tResponse.StatusCode = 200
	// Do something to create a valdid response and assing it to pResponse
	Return tSc
}

/// Handle a 'Response'
Method OnResponse(request As %Library.Persistent, ByRef response As %Library.Persistent, callrequest As %Library.Persistent, callresponse As %Library.Persistent, pCompletionKey As %String) As %Status
{
	return $$$OK
}

}

Nevertheless I'll import your example and have a look at the graphical BP as well. At the moment I'd prefer to create a response in code, but I'm quite confident also to be able to translate your example.

Thank you very much, I'll get back here with results (hopefully).

Regards,

Martin

Hello David,

thank you very much for your reply. How does this behave in case of using HS.FHIRServer.Interop.Request with HS.FHIRServer.InteropService? The creation of streams is done within the library classes, so it is not directly custom code. Since requests are derived from Ens.Request, they are cleaned up by the mentioned purge task. I can't find any hints in the code of the requests (something like a delete trigger does for persistent object hierarchies) that the quickstreams would be deleted as well. How is this handled in the Intersystems FHIR server?

Edit:

I discovered the globals in the namespace %SYS with "system items" checked in Cachetemp.HS.Stream. In the file system, unlike other stream types, quickstreams have no representation in the form of a file besides the database. As you described, the removal has to be done manually, because the quickstreams of the already purged requests are still present. Alternatively enough memory has to be provided and I wait until the next restart solves the problem by itself. If these assumptions aren't wrong this answers my questions from above.

Regards, Martin

Hello community,

I'm trying to break it down to the core problem: why does this function return the following output when trying to create a XML stream - is this a bug?

Class HOME.ms.MsFunctionSet Extends Ens.Rule.FunctionSet
{

ClassMethod FhirToXmlExample() As %Status
  {
    #dim tCapStat as HS.FHIR.DTL.vR4.Model.Resource.CapabilityStatement;
    set tCapStat = ##class(HS.FHIR.DTL.vR4.Model.Resource.CapabilityStatement).%New()
    w tCapStat.ToJSON()
    w tCapStat.ToXML()
  }
}

> do ##class(HOME.ms.MsFunctionSet).FhirToXmlExample()
> 426@%Stream.TmpCharacter
> do ##class(HOME.ms.MsFunctionSet).FhirToXmlExample() - Error <FUNCTION>

Regards,

Martin

It seems like the former enterprise client systems configuration had to be modified. 2018.2.1 worked well with the server name. In 2021.1 I had to provide the fqdn at the Web IP Address setting to make the production monitor showing up like expected. I don't know if this was the actual reason, but at least it works now.

Thanks and regards,

Martin

Hello Craig,

yes, it is. We're using configured credentials and method "Password" is checked. I also tried a different, newly crated user for testing purposes. Moreover, the access has worked before the upgrade to 2021.1 and we have not changed anything in the configuration. What I find confusing is that even when the "unauthenticated" method is checked at the webapp configuration, the login screen appears.

Regards,

Martin

Thanks for your reply,

a look into the table of the 'many' data objects confirms that the wrong order is already reflected in the ID of these objects. Since the ID is assigned in ascending order at the time of creation, I don't quite understand why it doesn't reflect the order of the result set.

Anyway, with the hints I can continue the search and make adjustments if necessary to resolve the dependency on implicitly assigning an ascending Object ID.

Regards,
Martin

Hello Vic,

yes, our admin users are provided with %ALL privileges, but it seems like I finally managed to get things working. I don't understand in detail why it works, but I noticed that the configuration of the databases on the other hosts is different. 

So I tried out adding the role %HS_DB_%DEFAULT to the user in question. With this additional role it seems to work. 

It would still be interesting to know if there is an unnecessarily large expansion of permissions associated with this role that poses an unintended risk.

Thank you for your help!

Regards, Martin

Hello Eduard,

thanks for your helpful reply. I assigned the role %DB_CACHESYS to the user, which grants R/W rights to some tables from the INFORMATION_SCHEMA schema. As the user still isn't allowed to login to neither management portal nor studio my basic demands are fullfilled, so I chose not to start an investigation which of the given tables causes the violation. This setting removes the unwanted entries from the auditlog, so the problem is solved from my point of view. Thanks again,

regards,

Martin Staudigel