search

scandihealth / lpr3-docs

https://scandihealth.github.io/lpr3-docs/
MIT License
11 stars 7 forks source link

Conflict between XML Schemas (XSD) #240

Closed RasmusThernoe closed 5 years ago

RasmusThernoe commented 5 years ago

There is a conflict between national services.

The content of the XML schema (XSD) for DGWS used in the LPR3 service differs from XSD used in running services on NSPOP, e.g. Stamdata Kopiregisterservice (SKRS).

This would normally not be a problem but because these different XSDs have the same namespace (http://www.medcom.dk/dgws/2006/04/dgws-1.0.xsd) they conflict when deployed. The XML schemas are not compatible, e.g. the FaultCode in the LPR3 service is an arbitrary string and the FaultCode in SKRS must be a restricted enumeration.

The XSD used in the LPR3 service is defined in the GitHub repository: https://github.com/scandihealth/lpr3-docs/tree/master/src/interface/wsdl/xsd

A suggestion to a possible "short term" solution is to change the namespace of the XSD used in the LPR3 servicen to something unique - without changing the content. This would solve the current conflict.

jkiddo commented 5 years ago

The schema used by LPR3 is the same as the schema hosted on https://svn.nspop.dk/public/components/seal/latest/code/modules/seal/src/main/resources/medcom.xsd (which should be the official DGWS schema).

If this is to be changed, please address this to the steering committee

RasmusThernoe commented 5 years ago

Issue already raised to SDS.

TueCN commented 5 years ago

I assume LPR3 is indeed using the correct version of the schema so I am adding the 'wontfix' label until the steering committee decides otherwise.

KirstenLHSDS commented 5 years ago

The issue has been discussed with the region, SDS (architect), DXC and @RasmusThernoe. As I understand from the SDS-architect, the conclusion is, that there will be no change to the LPR3-solution. The source of the autoritative skema is (still): http://svn.medcom.dk/svn/releases/Standarder/DGWS/Schemas/

RasmusThernoe commented 5 years ago

There was no conclusion at the meeting.

The situation was explained to SDS: There is a conflict between national services, e.g. Stamdata Kopiregisterservice (SKRS), Fælles Medicin Kort (FMK) and LPR3. The conflict is caused by the XML Schemas (XSD) used in these national services are non compatible content but they all have the same namespace.

To fix the conflict in the national services one of them have to be moved to a unique namespace by the right authorities.

TueCN commented 5 years ago

LPR will add 3 new endpoints that use the new active namepsace http://svn.medcom.dk/svn/releases/Standarder/DGWS/Schemas/medcom-1.0.1.xsd The schema file used will be the file referenced by the namespace (as it is at LPR build time)

See https://svn.medcom.dk/svn/releases/Standarder/DGWS/Dokumentation/Den%20Gode%20Webservice%201.0.1.pdf

The 3 new endpoints will have identical functionality as the existing 3 endpoints, but different URLs.

RasmusThernoe commented 5 years ago

Will you publish the new schema files on the interface description, e.g. https://scandihealth.github.io/lpr3-docs/links/index.html?

TueCN commented 5 years ago

The new endpoints will be specified by a new WSDL file (that uses the new schema). The new WSDL file will be uploaded to https://github.com/scandihealth/lpr3-docs/tree/master/src/interface/wsdl when finalized.

Development is done and we just need to test the new endpoints before we can guarantee that the the WSDL is final. Expect the WSDL to be published today and the new endpoints deployed tomorrow.

TueCN commented 5 years ago

Here's a sneak peek of the new WSDL:

<?xml version='1.0' encoding='UTF-8'?>

<definitions xmlns:xsd="http://www.w3.org/2001/XMLSchema"
             xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
             xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl"
             xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
             xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"
             xmlns:medcom="http://svn.medcom.dk/svn/releases/Standarder/DGWS/Schemas/medcom-1.0.1.xsd"
             xmlns:ihe="urn:ihe:iti:xds-b:2007"
             xmlns:hsuid="http://www.nsi.dk/hsuid/2016/08/hsuid-1.1.xsd"
             xmlns="http://schemas.xmlsoap.org/wsdl/"
             xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/"
             name="DocumentRepository"
             targetNamespace="urn:ihe:iti:xds-b:2007">

    <documentation>IHE XDR Service with national SSI additions (using medcom namespace "http://svn.medcom.dk/svn/releases/Standarder/DGWS/Schemas/medcom-1.0.1.xsd")</documentation>
    <types>

        <!-- Danish national extensions start -->

        <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
                    xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
                    xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
                    xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"
                    xmlns:medcom="http://svn.medcom.dk/svn/releases/Standarder/DGWS/Schemas/medcom-1.0.1.xsd"
                    xmlns:ihe="urn:ihe:iti:xds-b:2007" xmlns:hsuid="http://www.nsi.dk/hsuid/2016/08/hsuid-1.1.xsd"
                    xmlns="http://schemas.xmlsoap.org/wsdl/"
                    targetNamespace="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
            <xsd:include
                schemaLocation="xsd/dgws/wsse.xsd"/>

        </xsd:schema>
        <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
                    xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
                    xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
                    xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"
                    xmlns:medcom="http://svn.medcom.dk/svn/releases/Standarder/DGWS/Schemas/medcom-1.0.1.xsd"
                    xmlns:ihe="urn:ihe:iti:xds-b:2007" xmlns:hsuid="http://www.nsi.dk/hsuid/2016/08/hsuid-1.1.xsd"
                    xmlns="http://schemas.xmlsoap.org/wsdl/" targetNamespace="urn:oasis:names:tc:SAML:2.0:assertion">
            <xsd:include
                schemaLocation="xsd/dgws/saml.xsd"/>

        </xsd:schema>
        <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
                    xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
                    xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
                    xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"
                    xmlns:medcom="http://svn.medcom.dk/svn/releases/Standarder/DGWS/Schemas/medcom-1.0.1.xsd"
                    xmlns:ihe="urn:ihe:iti:xds-b:2007" xmlns:hsuid="http://www.nsi.dk/hsuid/2016/08/hsuid-1.1.xsd"
                    xmlns="http://schemas.xmlsoap.org/wsdl/" targetNamespace="http://svn.medcom.dk/svn/releases/Standarder/DGWS/Schemas/medcom-1.0.1.xsd">
            <xsd:include
                schemaLocation="http://svn.medcom.dk/svn/releases/Standarder/DGWS/Schemas/medcom-1.0.1.xsd"/>

        </xsd:schema>
        <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
                    xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
                    xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
                    xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"
                    xmlns:medcom="http://svn.medcom.dk/svn/releases/Standarder/DGWS/Schemas/medcom-1.0.1.xsd"
                    xmlns:ihe="urn:ihe:iti:xds-b:2007" xmlns:hsuid="http://www.nsi.dk/hsuid/2016/08/hsuid-1.1.xsd"
                    xmlns="http://schemas.xmlsoap.org/wsdl/" targetNamespace="http://www.nsi.dk/hsuid/2016/08/hsuid-1.1.xsd">
            <xsd:include
                schemaLocation="xsd/hsuid/hsuid-1_1.xsd"/>

            <!-- Danish national extensions stop -->

        </xsd:schema>
        <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
                    xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
                    xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
                    xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"
                    xmlns:medcom="http://svn.medcom.dk/svn/releases/Standarder/DGWS/Schemas/medcom-1.0.1.xsd"
                    xmlns:ihe="urn:ihe:iti:xds-b:2007" xmlns:hsuid="http://www.nsi.dk/hsuid/2016/08/hsuid-1.1.xsd"
                    xmlns="http://schemas.xmlsoap.org/wsdl/" elementFormDefault="qualified"
                    targetNamespace="urn:ihe:iti:xds-b:2007">
            <xsd:include
                schemaLocation="../schema/IHE/XDS.b_DocumentRepository.xsd"/>

        </xsd:schema>
        <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
                    xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
                    xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
                    xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"
                    xmlns:medcom="http://svn.medcom.dk/svn/releases/Standarder/DGWS/Schemas/medcom-1.0.1.xsd"
                    xmlns:ihe="urn:ihe:iti:xds-b:2007" xmlns:hsuid="http://www.nsi.dk/hsuid/2016/08/hsuid-1.1.xsd"
                    xmlns="http://schemas.xmlsoap.org/wsdl/" elementFormDefault="qualified"
                    targetNamespace="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0">
            <xsd:include
                schemaLocation="../schema/ebRS/rs.xsd"/>

        </xsd:schema>
        <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
                    xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
                    xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
                    xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"
                    xmlns:medcom="http://svn.medcom.dk/svn/releases/Standarder/DGWS/Schemas/medcom-1.0.1.xsd"
                    xmlns:ihe="urn:ihe:iti:xds-b:2007" xmlns:hsuid="http://www.nsi.dk/hsuid/2016/08/hsuid-1.1.xsd"
                    xmlns="http://schemas.xmlsoap.org/wsdl/" elementFormDefault="qualified"
                    targetNamespace="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0">
            <xsd:include
                schemaLocation="../schema/ebRS/query.xsd"/>

        </xsd:schema>
        <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
                    xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
                    xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
                    xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"
                    xmlns:medcom="http://svn.medcom.dk/svn/releases/Standarder/DGWS/Schemas/medcom-1.0.1.xsd"
                    xmlns:ihe="urn:ihe:iti:xds-b:2007"
                    xmlns:hsuid="http://www.nsi.dk/hsuid/2016/08/hsuid-1.1.xsd" xmlns="http://schemas.xmlsoap.org/wsdl/"
                    elementFormDefault="qualified" targetNamespace="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0">
            <xsd:include
                schemaLocation="../schema/ebRS/lcm.xsd"/>

        </xsd:schema>
        <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
                    xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
                    xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
                    xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"
                    xmlns:medcom="http://svn.medcom.dk/svn/releases/Standarder/DGWS/Schemas/medcom-1.0.1.xsd"
                    xmlns:ihe="urn:ihe:iti:xds-b:2007"
                    xmlns:hsuid="http://www.nsi.dk/hsuid/2016/08/hsuid-1.1.xsd" xmlns="http://schemas.xmlsoap.org/wsdl/"
                    elementFormDefault="qualified" targetNamespace="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0">
            <xsd:include
                schemaLocation="../schema/ebRS/rim.xsd"/>

        </xsd:schema>
    </types>
    <message name="SecurityHeader">
        <part element="wsse:Security" name="security_header">
        </part>
    </message>
    <message name="MedcomHeader">
        <part element="medcom:Header" name="medcom_header">
        </part>
    </message>
    <message name="ProvideAndRegisterDocumentSet-b_Message">
        <documentation>Provide and Register Document Set</documentation>
        <part element="ihe:ProvideAndRegisterDocumentSetRequest" name="body"></part>
    </message>
    <message name="ProvideAndRegisterDocumentSet-bResponse_Message">
        <documentation>Provide And Register Document Set Response
        </documentation>
        <part element="rs:RegistryResponse" name="body"></part>
    </message>
    <message name="HsuidHeader">
        <part element="hsuid:HsuidHeader" name="hsuid_header">
        </part>
    </message>
    <portType name="DocumentRepository_PortType">
        <operation name="DocumentRepository_ProvideAndRegisterDocumentSet-b">
            <input message="ihe:ProvideAndRegisterDocumentSet-b_Message"
                   wsaw:Action="urn:ihe:iti:2007:ProvideAndRegisterDocumentSet-b"></input>
            <output message="ihe:ProvideAndRegisterDocumentSet-bResponse_Message"
                    wsaw:Action="urn:ihe:iti:2007:ProvideAndRegisterDocumentSet-bResponse"></output>
        </operation>
    </portType>
    <binding name="DocumentRepository_Binding" type="ihe:DocumentRepository_PortType">
        <soap12:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
        <operation name="DocumentRepository_ProvideAndRegisterDocumentSet-b">
            <soap12:operation soapAction="urn:ihe:iti:2007:ProvideAndRegisterDocumentSet-b"></soap12:operation>
            <input>
                <soap12:header message="ihe:SecurityHeader" part="security_header"
                               use="literal"></soap12:header>
                <soap12:header message="ihe:MedcomHeader" part="medcom_header"
                               use="literal"></soap12:header>
                <soap12:header message="ihe:HsuidHeader" part="hsuid_header"
                               use="literal"></soap12:header>
                <soap12:body use="literal"></soap12:body>
            </input>
            <output>
                <soap12:header message="ihe:MedcomHeader" part="medcom_header"
                               use="literal"></soap12:header>
                <soap12:body use="literal"></soap12:body>
            </output>
        </operation>
    </binding>
    <service name="dgws-1.0.1/DocumentRepository_Service">
        <port name="DocumentRepository_Port_Soap12" binding="ihe:DocumentRepository_Binding">
            <soap:address location="https://lprws.sds.dsdn.dk/cda-ws/medcom-1.0.1/DocumentRepository_Service/PatientHealthcareReportingService"/>
        </port>
    </service>
</definitions>
JacobBangSSE commented 5 years ago

I expect you are also going to add the new medcom-1.0.1.xsd file to you repository?

TueCN commented 5 years ago

Hmm we were not planning to add the xsd file as the new namespace is "active" (the namespace is also a link to the schema).

You can expect that LPR uses the schema precisely as it is defined on http://svn.medcom.dk/svn/releases/Standarder/DGWS/Schemas/medcom-1.0.1.xsd

JacobBangSSE commented 5 years ago

No problem with that. We just take a snapshot for the XSD file into our own repository. I expect that if SDS wants to introduce any changes in the future to the XSD file, they are going to update the version number.

TueCN commented 5 years ago

Yes, we expect that as well.

TueCN commented 5 years ago

Hmm.. as far as I can tell, whoever maintains Seal.java has not updated it to use the new medcom schema. Our test client depend on Seal.java so I cannot test the endpoints without hacking Seal.java and implementing the use of the new namespace myself..

@JacobBangSSE are you using Seal.java and if so, what are you going to do? :S

JacobBangSSE commented 5 years ago

Thanks for pointing that out. I need some time to look into that before I can give any answer. (and yes, we use Seal.java)

TueCN commented 5 years ago

I will raise the issue with SDS. If we are lucky, they can release a new version of Seal.java that supports the new namespace fairly quickly.

JacobBangSSE commented 5 years ago

I don't think we have a problem. The handling of getting STS ID Card are isolated in its own Java process on our integration platform and therefore uses its own schema files. The output of this are then XML but here we only use the "urn:oasis:names:tc:SAML:2.0:assertion" namespace which does not depend on DGWS.

So I think we are going to be OK without an update of Seal.java. I don't even know how Seal.java are going to be updated without updating the endpoint whish Seal.java are using to return the correct namespace. It can of course be done but the change are not trivial.

TueCN commented 5 years ago

Ok. I will have to try and test the new endpoints sporadically in SoapUI instead of running our full regression test suite.

TueCN commented 5 years ago

RESOLUTION 3 new endpoints have been added. See https://github.com/scandihealth/lpr3-docs/pull/293. Updated WSDLs available here

New URLs (available after next deployment):

JacobBangSSE commented 5 years ago

I am trying to implement the new wsdl into out integration platform and I got an error:

Caused by: Invalid value for datatype xs:NCName: "xdt:untypedAtomic('medcom-1.0.1/DocumentRepository_Service')".

It took some time to understand the issue but basically the name field for services is defined to have the type NCName which do have some restrictions: https://stackoverflow.com/a/6159003

In this case the character '/' are not allowed in the name "medcom-1.0.1/DocumentRepository_Service".

TueCN commented 5 years ago

I was not aware there was restrictions on service name, my tool stack didn't bother to tell me :( I will look into providing a valid WSDL but it will probably not be today.

Can you work around the invalid WSDL by temporarily modifying it locally and still direct the integration platform to the provided endpoint URLs?

JacobBangSSE commented 5 years ago

Yes, I am trying with custom name of the service which seems to work.

JacobBangSSE commented 5 years ago

After some more testing I can see our integration platform does not support URL's in schemaLocation and we therefore prefer that all schema dependencies can we found locale. I have therefore made the following change in our end in "ihe-xdr-medcom-1.0.1.wsdl" and downloaded "medcom-1.0.1.xsd":

From:

schemaLocation="http://svn.medcom.dk/svn/releases/Standarder/DGWS/Schemas/medcom-1.0.1.xsd"/>

To:

schemaLocation="xsd/dgws/medcom-1.0.1.xsd"/>

This also have the advantage that we don't depend on the svn.medcom.dk server in operation.

TueCN commented 5 years ago

Ok, we can do that if that helps you. I see no harm in bundling the schema file with the deployment.

JacobBangSSE commented 5 years ago

Well, it would be nice if we can use the same files from you in our deployments without any modifications. :)

JacobBangSSE commented 5 years ago

I am testing the new endpoint right now with the new medcom-1.0.1.xsd schema but got the following error from our integration platform:

caused by: org.xml.sax.SAXException: validation error: data "xs:string('FLOW_FINALIZED_SUCCESFULLY')" does not match enumeration facet "xs:string('flow_running'), xs:string('flow_finalized_succesfully')" for type "null"   ({com.tibco.xml.validation}SIMPLE_E_ENUMERATION_FACET_MISMATCH) at /outputMessage[1]/headers[1]/Header.medcom_header[1]/ns10:Header[1]/ns10:FlowStatus[1]

It seems the endpoint are returning the value "FLOW_FINALIZED_SUCCESFULLY" as FlowStatus but in the XML Schema the field are defined as:

  <xs:element name="FlowStatus">
    <xs:simpleType>
      <xs:restriction base="xs:string">
        <xs:enumeration value="flow_running"/>
        <xs:enumeration value="flow_finalized_succesfully"/>
      </xs:restriction>
    </xs:simpleType>
  </xs:element>

So it seems you endpoint are not behaving to spec since you are sending the value as uppercase. I need to test with SoapUI to see the full message from you.

JacobBangSSE commented 5 years ago

Here is the full returned answer from the endpoint: https://lprws-test.sds.dsdn.dk/cda-ws/medcom-1.0.1/DocumentRepository_Service/PatientHealthcareSaveIfNoErrorsReportingService

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
   <soap:Header>
      <ns10:Header xmlns="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0" xmlns:ns10="http://svn.medcom.dk/svn/releases/Standarder/DGWS/Schemas/medcom-1.0.1.xsd" xmlns:ns11="http://www.nsi.dk/hsuid/2016/08/hsuid-1.1.xsd" xmlns:ns2="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0" xmlns:ns3="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0" xmlns:ns4="urn:ihe:iti:xds-b:2007" xmlns:ns5="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0" xmlns:ns6="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:ns7="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ns8="http://www.w3.org/2000/09/xmldsig#" xmlns:ns9="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
         <ns10:SecurityLevel>3</ns10:SecurityLevel>
         <ns10:Linking>
            <ns10:MessageID>d2322c6dac12323600f090e7ba242785</ns10:MessageID>
         </ns10:Linking>
         <ns10:FlowStatus>FLOW_FINALIZED_SUCCESFULLY</ns10:FlowStatus>
      </ns10:Header>
   </soap:Header>
   <soap:Body>
      <ns2:RegistryResponse status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Failure" xmlns="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0" xmlns:ns10="http://svn.medcom.dk/svn/releases/Standarder/DGWS/Schemas/medcom-1.0.1.xsd" xmlns:ns11="http://www.nsi.dk/hsuid/2016/08/hsuid-1.1.xsd" xmlns:ns2="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0" xmlns:ns3="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0" xmlns:ns4="urn:ihe:iti:xds-b:2007" xmlns:ns5="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0" xmlns:ns6="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:ns7="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ns8="http://www.w3.org/2000/09/xmldsig#" xmlns:ns9="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
         <ns2:RegistryErrorList highestSeverity="urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error">
            <ns2:RegistryError codeContext="XSD|||cvc-complex-type.2.3: Element 'section' cannot have character [children], because the type's content type is element-only." errorCode="InvalidDocumentContent" location="F4E4518A-68B4-4E09-A22A-59511A8DF5ED^557b0ab7-2ca5-4465-b778-6a7502287f13|||1:6109" severity="urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error"/>
         </ns2:RegistryErrorList>
      </ns2:RegistryResponse>
   </soap:Body>
</soap:Envelope>
TueCN commented 5 years ago

Ah. Yes this is an oversight :( We will rectify this as quickly as possible and deploy to test as soon as the fix is ready.

I assume this is a high urgency problem? Do you need this fixed in prod before Sunday? (is that not the day you are scheduled to begin using production?)

JacobBangSSE commented 5 years ago

Yes this is urgent. We need a fix as quickly as possible since we are going into prod on sunday with LPR3 and we need to prepare a deployment plan for our customer and testing the new endpoint.

RasmusThernoe commented 5 years ago

Will this fix be ready and deployed today?

TueCN commented 5 years ago

I'm working on it now and will deploy it as soon as it is ready

RasmusThernoe commented 5 years ago

Good news :-)

TueCN commented 5 years ago

Fix for https://github.com/scandihealth/lpr3-docs/issues/240#issuecomment-458564828 + https://github.com/scandihealth/lpr3-docs/issues/240#issuecomment-458851601 + https://github.com/scandihealth/lpr3-docs/issues/240#issuecomment-458933521 is deployed.

Please try the new endpoints again now.

RasmusThernoe commented 5 years ago

Thank you for the fixes. We are currently testing the new endpoints.

JacobBangSSE commented 5 years ago

Looks good from my point of view. My basics tests are going through but I cannot validate that the messages are saved before #300 are fixed.

RasmusThernoe commented 5 years ago

Basic tests performed and it works.