IDocumentPlugin2 GetDocumentUrl help needed

Hi there,

I'm building a NetServer document plugin (interface: IDocumentPlugin2) for a client of us.
The client has SuperOffice 8.4 running with users using the Windows client of SuperOffice.

I've implemented most functions already successfully but we have a problem with the GetDocumentUrl function.

This function expects a path to the document but we don’t have a document file (path) but we have to open a Windows app (DMS aka Document Management System) on the client machine which handles all actions off the document. If I give back a null or an empty string I get an exception in SuperOffice.

Is there a work-around to skip this error?

Kind regards,
Gert Nierop
The Implementation Group

Hello Geet,RE: IDocumentPlugin2 GetDocumentUrl help needed

Hello Gert,

From a Win client p.o.v. I can say this:

When you doubleclick a document row in some activity archive, we will call GetDocumentUrl, via PhysicalDocument in Netserver that in turn calls the relevant docplugin.
We then pass the result through Uri::UnescapeDataString and expect this to be a full path to a real physical file that can be opened with ShellExecuteEx.

Example url: "file:///d:/so_arc/cw/2018.1/test1.doc"

I.o.w. returning an empty string in GetDocumentUrl does not make any sense.



Af: Conrad Weyns 9. nov 2018

RE: IDocumentPlugin2 GetDocumentUrl help needed

Hi Conrad,

We already had a com-based (SO 7.5) document plugin working for our client (with the IDocumentInterface) which has the "Open" void function (so needs no return to give). After the upgrade to SO 8.4 we are trying to implement the NetServer IDocumentPlugin2 but there is no void "Open" function available as far as we know.

Because the DMS has it own implementation of the documents we don't have a result to return in the function "GetDocumentUrl", we just don't have a document to give the path. I understand the working of the "file:" result but there is nothing to show. The document is in the DMS database saved, not a physical path available as far as we know.

In the current function I execute a call to the DMS function with the ID of the document (incomingInfo.DocumentId). When creating a document (function CreateDocument) the Document ID is saved in the DMS database, in other words there is a link between the record in the SO database and the DMS by using this ID.

So giving back an empty string is something which would help us because the real opening of the document is managed by the DMS, for know I've created a dummy text file which will say "Switch to the DMS", this works but is not a beautiful solution of course.

We are also questioning the DMS experts if there is an other way to solve this issue we now have.

Gert Nierop



Af: Gert Nierop 11. nov 2018

RE: IDocumentPlugin2 GetDocumentUrl help needed

I gathered we were seeing an impedance mismatch here..
To me this seems a breaking change between our old COM based docplugin and the new netserver based functionality.
I have added a tfs issue, 61587. I will notify those that did the port.

So, if I understand correctly, with the old system you got a Open call where you triggered your DMS system.
So now, I guess users cannot any longer Open a document from SoCrm?

Add some info here as to what exactly you found got broken, and I'll paste it into the tfs issue.

Af: Conrad Weyns 11. nov 2018

RE: IDocumentPlugin2 GetDocumentUrl help needed

Hi Conrad,

Thanks for your quick reply!

Environment: SuperOffice 8.4 Windows Client / DMS Windows Client (Interop DOCSObjects of edocs)

The issue is we used the COM (void) function "Open" which is triggered by the "double-click" and "open document" in SuperOffice.

When using the NetServer implementation, the "double-click" triggers the function "GetDocumentUrl" which expects a return string with a path to the document.