3.1.4.6 SubmitFile

  • Article

This method is called to submit a file and its associated properties to the repository.

The following is the WSDL port type specification of the SubmitFile WSDL operation.

 <wsdl:operation name="SubmitFile" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">
   <wsdl:input message="tns:SubmitFileSoapIn"/>
   <wsdl:output message="tns:SubmitFileSoapOut"/>
 </wsdl:operation>

The protocol client sends a SubmitFileSoapIn request WSDL message, and the protocol server MUST respond with a SubmitFileSoapOut response WSDL message, as follows:

  1. If the user is not in the list of users authorized to submit files to the repository, the protocol server MUST set the ResultCode element to "NotFound" and return.

  2. If required parameters were not specified, the protocol server MUST set the ResultCode to InvalidArgument and return.

  3. If the protocol server determines that the file cannot be submitted to the repository using an implementation-specific<14> algorithm, the protocol server MUST set the ResultCode element to FileRejected and return.

  4. If the protocol server determines that the repository is not configured for routing, the protocol server MUST set the ResultCode element to "InvalidRouterConfiguration" and return.

  5. The protocol server processes the rules in an implementation-specific manner based on the submission’s properties and recordRouting to determine the storage location for the submission.

  6. If no applicable rule is found:<15>

    1. The protocol server sets the ResultCode element to MoreInformation.

    2. The protocol server MUST set the ResultUrl element to an implementation-specific URL to enter more information about the submission.

    3. The protocol server uses the temporary storage location.

  7. If the protocol server determines that the storage location determined by the rules has required properties that are not present in the properties element:

    1. If the protocol server determines that the name of the user specified in the userName element is invalid using an implementation-specific validation algorithm, then the protocol server MUST set the ResultCode element to InvalidUser and return.

    2. Otherwise, the protocol server MUST set the ResultCode element to MoreInformation               and the ResultUrl element to an implementation-specific URL to enter more information about the submission. The protocol server uses the temporary storage location.

  8. The protocol server stores the file in the storage location.

  9. If implementation-specific errors occur while determining the storage location for the submission or while storing the file, the protocol server MUST set the ResultCode element to UnknownError and return.

  10. Otherwise, the protocol server MUST set the ResultCode element to Success and SHOULD<16> set the ResultUrl element to a non-empty HTML encoded URL to retrieve the stored file.

  11. If the file has been stored in the temporary storage location, the server returns.

  12. If the properties element contains all of the following properties, then the protocol server sets the implementation-specific metadata that indicates the file is placed on the legal hold. The protocol server SHOULD<17> set the CustomProcessingResult.HoldsProcessingResult element to Success.

    • _dlc_hold_url

    • _dlc_hold_comments

    • _dlc_hold_id

    • _dlc_hold_searchqquery

    • _dlc_hold_searchcontexturl

  13. If, however, at least one but not all of the properties mentioned previously are contained in the properties element, then the protocol server SHOULD NOT set the CustomProcessingResult.HoldsProcessingResult.

  14. If none of the properties mentioned previously are contained in the properties element then the protocol server MUST NOT set CustomProcessingResult.HoldsProcessingResult.