I'm trying to up- and downloading documents using crm-script in Customer Portal. The files are big. 50-150 MB. I'm using "printBinary" when I'm downloading. And
All Replies (1)
I can't comment on the exact workflow using the streaming-classes, but...
I don't think it's possible to change the memory of a specific tenant. The memory limit of the script engine is a system wide setting for Online, as I understand it.
Though, correctly implemented, the streaming classes exists to not be limited by the memory of the script engine (which is 8 MB).
The experience noted below is mainly related to the creation of documents via CRMScript, not downloading. But some parts may apply to both directions.
But, the usage of the streaming classes from within crmscript is a topic that I have discussed in detail with both Tony from SO RnD Dev Team as well as I-Centrum, that have built some document upload customisations using crmscript. Based on tests it seems hard to get a reliable functionality over 45-50 MB. If I understood Tony correctly, these classes weren't really intended to be used from within crmscript and should instead be used via the REST-API to be more reliable and offer the same limits as the default document features in the SO GUI.
It can also be good to know that SO Online doesn't support documents larger than around 94.4 MB. See the below article:
https://community.superoffice.com/en/support-faqs/faq/what-is-the-maximum-size-of-an-attachment-which-can-be-uploadedin-superoffice-crm/
What normally happens for larger documents doesn't seem to be a memory outage but rather a script timeout. The limit for running a script is around 60 seconds, which leads the script to just silently timeout if the time limit is reached. The result is often that the meta data of the document gets created, while the actual document is not. If a document data verification isn't added, you may end up with a bunch of documents that looks like they have been uploaded, but they really just contains the document meta data and not the actual document.
Therefore, these kind of solutions should preferably be triggered via some kind of webpanel hosted HTML-page that can own both the upload-process as well as the document-verification process. That way it can ensure that failed uploads also deletes the created document meta-data and returns an error.
How to verify the existance of the physical document
Class: NSDocumentAgent
Method: Void VerifyGetDocumentStream(Integer)
https://docs.superoffice.com/en/automation/crmscript/reference/CRMScript.NetServer.NSDocumentAgent.html#CRMScript_NetServer_NSDocumentAgent_VerifyGetDocumentStream_Integer_
Note:
This method will return its status by throwing a SoException Error with a message if the physical document is missing, so it needs to be wrapped in a try-catch-clause.
https://community.superoffice.com/en/technical/forums/api-forums/online-web-services/how-to-use-verifygetdocumentstream/
This is at least the findings we ended up with when we investigated this around in May 2024. I don't know if there has been any changes to this since then or if anybody else have some other relevant input or experience in relation to this to share. But I hope this input can be of value at least.
Best Regards
Marcus