CRMScript unable to work with documents stored in SharePoint
Hi,
what's the story with CRMScript and documents when stored in SharePoint?
We have a customization which used to work, but lately it keeps failing with errors like "No document plugin found for plugin id 365", "Object not set to an instance of an object", and "Document info is blank" when working with DocumentEntities. I'm not sure if the customization broke because they've changed the templates from SO_ARC to SharePoint, or if CRMScript used to work against SharePoint.
Here is some example code - it works fine when the document is stored in SO_ARC, but when the template is set to use SharePoint it fails with various errors.
#setLanguageLevel 3;
Integer documentId = 4486; // Document stored in SharePoint
//Integer documentId = 4488; // Document stored in SO_ARC
NSDocumentAgent agent;
NSDocumentEntity documentEntity = agent.GetDocumentEntity(documentId);
NSStream stream = agent.GetDocumentStream(documentId); // Fails with "Document info is blank"
Byte[] bytes = stream.GetStream();
printLine(bytes.length().toString());
NSStream stream2 = agent.GetDocumentStreamFromEntity(documentEntity); // Fails with "Object not set to an instance of an object"
Byte[] bytes2 = stream2.GetStream();
printLine(bytes2.length().toString());
agent.DeleteDocumentEntity(documentId); // Fails with "No document plugin found for plugin id 365"Is there anything we can do about this?
All Replies (12)
What user are you running this script as? A system user or a 'normal user' that is mapped to the Office 365 tenant of the customer?
Hey Frode.
Based on the errors you've encountered, it seems the following is true:
- You are using the "legacy" Office 365 sharepoint-integration, not the new "Zero Footprint" version.
- And more importantly, your CRMScript for your online-tenant is routed through the Online API-cluster, and not interfacing with the CRM-tenant directly.
After taking a quick look, it seems like the API cluster lacks the DLLs required to work with any "non-standard" document-plugin. That is, the following document-plugins are affected:
- Sharepoint (legacy)
- Sharepoint (zero footprint)
- GSuite
Basically this could never have worked with API-cluster in the first place. Weird thing we haven't heard about any issues until now 😮
I've pushed some changes to make sure that these DLLs are now included, but I haven't been able to test if that alone is enough to solve the issue.
Could you test if this works for you in SOD? You will need either latest main-fileset or latest release-fileset.
Hi Jostein, thanks for the feedback.
It's been a while (maybe two years?) since we set up the SharePoint integration, so they are using the Legacy version.
Regarding the API-cluster, we have a document-signing solution in the Online appstore, which have never been able to handle writing documents back into SuperOffice (with Sharepoint) using the REST api and system user flow. I know Infobridge also has had issues with one of their apps working with documents stored in Sharepoint. In those cases I think our conclusion has been that it's been related to the SystemUser and the RefreshToken.
I found a SOD tenant now that I think has Sharepoint integration (Cust22068). It must have worked in the past, but now when I double click on a document template in Admin I get this:
If I try to create a document in CRM (which I want to use to test the CRMScript) I get this:
Writing documents using a system user should work using the new integration if this bug/wish report is to be believed:
https://community.superoffice.com/en/product-releases/bugs-wishes/product-issue/?bid=25865&azure=1
Hey Frode. Thanks for the detailed response.
> Regarding the API-cluster, we have a document-signing solution in the Online appstore, which have never been able to handle writing documents back into SuperOffice (with Sharepoint) using the REST api and system user flow. I know Infobridge also has had issues with one of their apps working with documents stored in Sharepoint. In those cases I think our conclusion has been that it's been related to the SystemUser and the RefreshToken.
This should be fixed in the new Sharepoint ("Zero footprint") document plugin. This has been tested and confirmed to work, at least for the test-cases we have attempted.
We are also in the process of releasing a document migration tool to help migrating documents to their preferred document-backend, like the new Zero Footprint plugin.
For now though, it will only be available to pilot customers, but if your customer contacts Frode Berntsen, they can be enlisted as a pilot customer and can migrate their documents to this new codebase which should hopefully work better for their needs.
> I found a SOD tenant now that I think has Sharepoint integration (Cust22068). It must have worked in the past, but now when I double click on a document template in Admin I get this
To me that looks like a configuration error. From the page in OC, there are no settings the "Cloud Office" pane:
This means that the relevant doc-plugins wont be enabled. This also means that if enabled, it might also required specific configuration to work with the old documents and libraries.
If you have another site to test with, that would be great. Otherwise, you can let us know if this works better in production, once the latest release is out there.
Hi, unfortunately Cust22068 is the only tenant in SOD where the SharePoint integration is in use, so I haven't got any other to test with. Doesn't anyone at SuperOffice R&D have access to a SOD base with SharePoint integration?
I've been unable to find any SOD sites with CS/CRMScript enabled to test the old O365-integration with.
That said, I have access to a similar site except with new Zero Footprint/Sharepoint Documents DocPlugin enabled. And for that site I could reproduce a very similar error in CRMScript (tracked in DevOps bug id 31792).
In the latest development builds I have now fixed that error (at least for Zero Footprint), and this fix has been merged to release too.
It will thus be included in the next release of the CRM Fileset. Let me know if you are still having issues once that version is released :)
Hey Frode!
To my knowledge Fileset version 10.1.5 is being rolled out in production these days, and chances are some of your test-sites may already be on that version.
If your O365 test-site is on that version, could you please re-test now and see if the issue is solved on your end?
Hi Jostein, the tenant in question is still on 10.1.4, so I'll check again in a few days.
Frode
Hi Frode,
Is it possible for you to retest this now? So we could close the issue on our side
Best,
Erik
Hi Erik, thanks for following up.
Yes, I tried the same script again now that they are on 10.1.6, and it seems to work now. Thanks again.
Frode