Hello Jani,

as far as I understand does the importer resolve imported references. Normally there is no need to separately import the referenced schemas when importing a wsdl file. This worked with some other serviced quite good, it is just two of them, which do not work.

Anyways, I was using the schema reader provided by Luis and the result from importing the VSDService.xsd is a package structure that also contains the elements defined by the file ConnectorContext.xsd. What I still don't have is the soap operation class and the request and response message classes...

Kind regards, Martin

Hello Luis,

thanks for taking the time to analyze my problem. I'm not sure if I fully understood what the problem and the suggested solution is. In the end I would like to have a functional SOAP Operation, with request and response classes to use the service.

As I understand your answer, the problem lies in the inclusion of datatypes, which is not supported by the SOAP wizard, so the process has to be done programmatically and the problem lies here:

<types>
  <xs:schema>
    <xs:import schemaLocation="VSDService.xsd" namespace="http://ws.gematik.de/conn/vsds/VSDService/v5.2"/>
    <xs:import schemaLocation="../../tel/error/TelematikError.xsd" namespace="http://ws.gematik.de/tel/error/v2.0"/>
  </xs:schema>
</types>

I would have to Import the referenced schemas using your to create the contained datatypes. I do so by importing the referenced xsd file using the classmethod you provided. After that, I'd guess the original wsdl file has also to be modified in some way to set the referenced datatypes to the formerly imported. Are my assumptions right, and how could I do this?

What I meanwhile tried was to import the two schemas into the currently used namespace using the schema import feature of the management portal. Doing so leads to the creation of some new datatypes:

When I'm then removing the "types" section from the wsdl file, I'm getting another error, which indicates that some other parts are missing.

Could you explain how to enable the import and the class creation of the initial wsdl file after the xsd schema files are imported? I'm sorry, but it seems like there is a missing piece in my understanding.

Thanks and regards,

Martin

Thanks very much!

Hello Nick,

thanks for your help. User rights configuration in Iris Healthconnect is a confusing field, I think. Nevertheless, I have configured a role that contains the functionalities I need, partly by trial and error. From my point of view, the documentation could be a bit more detailed, especially when it comes to the resource level. These days, the topic is too serious and important to simply fall back on %ALL for convenience.

Regards, Martin

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.

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.

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

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

Thanks for your helpful reply.

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