WorldServer SOAP Client API: 1 MB limit for attachedFile in WSWorkflowManager createProjectGroup call

First, some background. We have an application that uses both the REST and SOAP APIs for WorldServer 11.3 to create project groups. We use the REST API call in most cases. The situation that requires us to use a SOAP call is when one or more of the project files is a zip file containing source files within sub folders. Using the REST API in this situation when folder structure is important becomes an issue because:

  1. If the zip file is uploaded to WorldServer using the POST /files endpoint, WorldServer does not extract the file contents. Because of this, when a subsequent call is made to the POST /projectGroup/create endpoint with the previously uploaded zip file referenced in the systemFiles array of the request body, a single WorldServer task is created with the zip file itself being the asset (which is non-translatable).
  2. When folder structure within the zip file is important, extracting it first on the client end and then uploading the extracted files one at a time to WorldServer is not an option because the folder structure is lost. We have a requirement to allow for duplicate filenames in the same project, provided that the files are in different folders.

For these reasons we are forced to use the createProjectGroup7 SOAP API operation to create project groups with assets where folder structure is important. The SOAP API, as well as WorldServer's UI, accepts zip files and extracts them in a way so that the folder structure is preserved.

Using the SOAP API call has worked relatively well for us. However, recently we discovered what we consider to be a major limitation: the SOAP createProjectGroup call seems to have a single attached file limit of roughly 1,000 KB (1 MB). The chart below shows the results from some of our testing creating project groups through the WorldServer SOAP API using different file sizes and types:

File Size (KB)

File Type

Result

266

Zip

Succeeded

553

Zip

Succeeded

661

Zip

Succeeded

947

Zip

Succeeded

981

Docx

Succeeded

993

Zip

Succeeded

1015

Docx

Succeeded

1041

Zip

Failed (11 more bytes expected)

1053

Docx

Failed (10 more bytes expected)

1165

Zip

Failed (12 more bytes expected)

1900

Zip

Failed (12 more bytes expected)

3929

Zip

Failed (35 more bytes expected)

8179

Zip

Failed (83 more bytes expected)

24146

pptx

Failed (274 more bytes expected)

In the test where project group creation failed a WSRuntimeException was thrown. Here is an example of one of those exceptions:

com.idiominc.ws.WSRuntimeException: End of physical stream detected when 11 more bytes expected. (covers java.io.IOException: End of physical stream detected when 11 more bytes expected.) at org.apache.axis.message.SOAPFaultBuilder.createFault(SOAPFaultBuilder.java:222) at org.apache.axis.message.SOAPFaultBuilder.endElement(SOAPFaultBuilder.java:129) at org.apache.axis.encoding.DeserializationContext.endElement(DeserializationContext.java:1087) at java.xml/com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(Unknown Source) at java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(Unknown Source) at java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(Unknown Source) at java.xml/com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(Unknown Source) at java.xml/com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(Unknown Source) at java.

Has anyone else encountered this limitation on file size? We need to be able to support zip files larger than 1,000 KB that contain sub folders. Any help or suggestions are appreciated.

Thanks,

Joseph Richards

Parents Reply Children
No Data