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

Hi Cristiano,

I took your idea and (simplified) added a property and setting 'CheckServerIdentity' which is set to 1 by default to the custom business operation, to make this setting available over settings menu. Works like a charm!

Thanks a lot for your help!

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

So, you mean replacing

write tResponse.%ToJSON()

with

do tResponse.%ToJSON()

will do the job, even for big responses? That would be great.

Thank you,

Martin 

Hello Marc,

thank's a lot! I had hoped and suspected that it must be a small thing.

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

Finally, Arun's suggestion to write the data objects to the database on the many side using %Save() at the time of creation worked. Regarding performance, this did not result in any significant losses.Thanks to all for the helpful comments and remarks.

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