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:
- 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).
- 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