Annotated Retrieve Document Set Transaction

From IHE Wiki
Revision as of 16:55, 25 November 2009 by BillM (talk | contribs) (→‎Response)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Retrieve Document Set Transaction

What follows is the metadata for the Retrieve Document Set transaction as generated by a Document Consumer. This example was generated with the testing tool xdstest using testkit test 12029.

The Retrieve Document Set transaction is always carried in a SOAP over HTTP package formatted with MTOM/XOP rules. This applies to both the request and the response. An example showing the SOAP and HTTP is found here.

The outer element is RetrieveDocumentSetRequest. Within that is one or more DocumentRequest elements. If more than one DocumentRequest elements then one of these two conditions must exist:

  1. None of the DocumentRequest elements contains a HomeCommunityId element.
  2. All of the DocumentRequest elements contain a HomeCommunityId element.

When none of the requests has a HomeCommunityId this corresponds to a Retrieve Document Set within the Affinity Domain and the rules of XDS.b apply. The transaction is sent directly to the Web Services Endpoint configured in the Document Consumer for the RepositoryUniqueId. All values of RepositoryUniqueId must be the same.

When all of the requests have a HomeCommunityId this corresponds to a Retrieve Document Set in the context of XCA and different rules apply. The request is sent to a local Initiating Gateway. DocumentRequests labeled with the local HomeCommunityId (this community) are routed to the correct Document Repository actor within the Affinity Domain (the local community). DocumentRequests labeled with other values of HomeCommunityId are routed to the proper community's Responding Gateway for processing. The only limitation on values for RepositoryUniqueId is that that Repository must exist within the indicated community.

An example XDS-style Retrieve Document Set looks like:

<RetrieveDocumentSetRequest xmlns="urn:ihe:iti:xds-b:2007"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <DocumentRequest>
        <RepositoryUniqueId>1.19.6.24.109.42.1.5</RepositoryUniqueId>
        <DocumentUniqueId>1.2009.0827.08.33.5105</DocumentUniqueId>
    </DocumentRequest>
</RetrieveDocumentSetRequest>

An example XCA-style Retrieve Document Set looks like:

<RetrieveDocumentSetRequest xmlns="urn:ihe:iti:xds-b:2007"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <DocumentRequest>
        <HomeCommunityId>1.19.6.24.109.42.1.5</HomeCommunityId >
        <RepositoryUniqueId>1.19.6.24.109.42.1.5</RepositoryUniqueId>
        <DocumentUniqueId>1.2009.0827.08.33.5105</DocumentUniqueId>
    </DocumentRequest>
</RetrieveDocumentSetRequest>

Note the ordering of the elements inside DocumentRequest. This structure is governed by schema which will return an error if this ordering is not preserved.

Response

For the response it is impossible to understand without the HTTP and SOAP wrappers. The Content-Length/Chunked type of headers and annotation have been removed for readability.

The RetrieveDocumentSetResponse XML message is in the first/start part. Inside this is the Document element which nominally contains the document contents. Actually this element uses

<xop:Include href="cid:1.urn:uuid:C2CD255C5B1A1D72A41259184933880@apache.org"
                        xmlns:xop="http://www.w3.org/2004/08/xop/include"/>

to point to the Multipart Part that actually contains the document contents.

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: multipart/related; boundary=MIMEBoundaryurn_uuid_C2CD255C5B1A1D72A41259184933878; type="application/xop+xml"; start="0.urn:uuid:C2CD255C5B1A1D72A41259184933879@apache.org"; start-info="application/soap+xml"; action="urn:ihe:iti:2007:RetrieveDocumentSetResponse"
Date: Wed, 25 Nov 2009 21:35:30 GMT

--MIMEBoundaryurn_uuid_C2CD255C5B1A1D72A41259184933878
Content-Type: application/xop+xml; charset=UTF-8; type="application/soap+xml"
Content-Transfer-Encoding: binary
Content-ID: <0.urn:uuid:C2CD255C5B1A1D72A41259184933879@apache.org>

<?xml version='1.0' encoding='UTF-8'?>
<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"
    xmlns:wsa="http://www.w3.org/2005/08/addressing">
    <soapenv:Header>
        <wsa:Action>urn:ihe:iti:2007:RetrieveDocumentSetResponse</wsa:Action>
        <wsa:RelatesTo>urn:uuid:0E98B3D24FE023F45C1259185261435</wsa:RelatesTo>
    </soapenv:Header>
    <soapenv:Body>
        <xdsb:RetrieveDocumentSetResponse xmlns:xdsb="urn:ihe:iti:xds-b:2007">
            <rs:RegistryResponse xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"
                status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success"/>
            <xdsb:DocumentResponse>
                <xdsb:RepositoryUniqueId>1.19.6.24.109.42.1.5</xdsb:RepositoryUniqueId>
                <xdsb:DocumentUniqueId>1.2009.0827.08.33.5124</xdsb:DocumentUniqueId>
                <xdsb:mimeType>application/pdf</xdsb:mimeType>
                <xdsb:Document>
                    <xop:Include href="cid:1.urn:uuid:C2CD255C5B1A1D72A41259184933880@apache.org"
                        xmlns:xop="http://www.w3.org/2004/08/xop/include"/>
                </xdsb:Document>
            </xdsb:DocumentResponse>
        </xdsb:RetrieveDocumentSetResponse>
    </soapenv:Body>
</soapenv:Envelope>

--MIMEBoundaryurn_uuid_C2CD255C5B1A1D72A41259184933878
Content-Type: application/octet-stream
Content-Transfer-Encoding: binary
Content-ID: <1.urn:uuid:C2CD255C5B1A1D72A41259184933880@apache.org>

Actual content removed because it was huge

--MIMEBoundaryurn_uuid_C2CD255C5B1A1D72A41259184933878--