Hello @rsoika
Sorry for the late reply. Please accept our apologies for current situation. We are still working to improve WOPI on Document server.
As for forcesave scenario in general. There’s no desired mechanism for forcesave feature in WOPI at the moment. We are working on it.
There are only two ways to achieve desired scenario at the moment:
Switch WOPI to usage API.
Implement your own external Save button (not in the editor frame). This scenario should look like this: your server sends request to CommandService.ashx (ONLYOFFICE Api Documentation - Command service ) for checking file in Document server cache\build it\send to a storage.
Hi @Alexandre
thanks for your reply. No problem at all. If I know you are working on this it is fine. Can I track the issue on Github? Maybe I can also support your dev team with early testing.
For the moment I solved the problem somehow with the property settings for coauthoring:
But it is fine if you trigger me via this thread if a new version of the WOPI api is available. I prefer the WOPI API against the ONLYOFFICE API because an open standard protocol fits better in our own Open Source strategy.
Thank you for your testing offer, but I believe that our QA team deal with it. We have a lot of work to do to improve WOPI. I will notify you in this thread when we implement forcesave feature for WOPI.
As for autoAssembly parameter, as I mentioned before, this is not a right way in forcesave scenario (save button), but I understand why you looked at it in your scenario.
I will be in touch and provide you with any news about WOPI.
Hello @rsoika
Please clarify what you mean by ‘interface’.
As for WOPI in general, we are constantly improving WOPI and we publish new information when it’s ready.
Ah, I think I misunderstood your question since we discussed about WOPI features here (but not about ‘interface’, that confused me a little bit).
We are still working to improve WOPI (I remember about Forcesave feature for WOPI).
I will notify you when we have something to share.
Undrerstood, but please do not post the same question in the different communication channels. We are working to improve WOPI.
Described issue is related to lack of forcesave feature on the WOPI, we discussed it earlier and we are working to improve WOPI it and I mentioned workaround solution (usage API: ONLYOFFICE Api Documentation - Command service).
When we have any news about desired scenario (user can save a file during editing session), I will update this thread.
Hello @rsoika
Please accept our apologies for the length of situation. There’re a lot of tasks which we want to implement to increase user experience. One of them is mentioned in this thread (internal tracksystem number - 58764, Forcesave feature for WOPI) We are still working on it.
I will notify you when we have any news.
Hello
Command service uses a “key” as identifier of the file. But with WOPI there is only file_id. What key can we use with a command if the file was opened in OnlyOffice by WOPI?
And can we call Command service from WOPI Server?
Hello @Vladimir
There’s no possibility of sending requests to the Command Service through WOPI. You need to use Usage API to achieve it.
These are the different protocols with different logic of work, for example, WOPI doesn’t have ‘key’ parameter.
Hello, @Alexandre
What about a workaround solution with Command service which you mentioned earlier?
The commands work through the API, so in addition to the WOPI, we also have to implement a significant part of the API, namely a callback handler, etc?
Command service uses a “key” as identifier of the file. But with WOPI there is only file_id. What key can we use with a command if the file was opened in OnlyOffice by WOPI? document.key = file_id ?
Instead of a sequence of three requests between the WOPI server and the client (host-> office/command → host/callback → ofiice), is it possible to get by with one request that will immediately receive the contents of the file from the WOPI client (OnlyOffice)?
Hello @Vladimir
Sorry for the late reply.
As I mentioned before, there’s no way of sending requests to Command service in the WOPI.
The commands work through the API, so in addition to the WOPI, we also have to implement a significant part of the API, namely a callback handler, etc?
That’s right.
The main point is if you are going to use Command service, you have to implement the Document server integration to your storage through usage API. it includes document.key generation on your side which is used in most API requests: ONLYOFFICE Api Documentation - Config
Command service uses a “key” as identifier of the file. But with WOPI there is only file_id. What key can we use with a command if the file was opened in OnlyOffice by WOPI? document.key = file_id ?
No, there’s no way of using WOPI parameters in the usage API requests. document.key ≠file_id. There are the different protocols.
Instead of a sequence of three requests between the WOPI server and the client (host-> office/command → host/callback → ofiice), is it possible to get by with one request that will immediately receive the contents of the file from the WOPI client (OnlyOffice)?
I’m not sure that understand this scenario right. Could you please describe the usage scenario as detailed as possible?
Hello, @Alexandre
We tried a workaround solution for WOPI forcesave with Command service which you mentioned earlier.
We opened a file with WOPI by it’s file_id, edited it and then send a command forcesave with the document.key=file_id.
When processing the command request OnlyOffice Docs makes a WOPI PutFile request and the edited file is saved to the storage.
So, the workaround looks fine.
Maybe there are any unsolicited side effects from this method?
Hello @rsoika, I’m from @Vladimir team.
We use additional API command forceSave with WOPI:
WOPI API is partially implemented, namely the functions: CheckFileInfo, GetFile, PutFile and Lock
Open file in hostPage.
2.1. actionUrl has the structure:{suitable host from discovery}?wopisrc={host:port WOPI server}/wopi/files/{file_id}. Example: http://localhost/hosting/wopi/word/edit?wopisrc=http://testWOPI:4000/wopi/files/1.docx_457521443
2.2. token - in the test application we don’t perform validation, so a random URI-safe string
2.3 tokenTtl - current time in ms + 10 hours as ms
Implemented a REST POST request forceSave. Example on java
public String forceSave(final String fileId) {
try {
String content = createJsonSave(fileId); // generate request body
HttpRequest httpRequest = HttpRequest.newBuilder()
.uri(new URI(docserviceHost + "/coauthoring/CommandService.ashx")) // set URI command service, example: http://localhost/coauthoring/CommandService.ashx
.header("Content-Type", "application/json") // set Content-Type
.POST(HttpRequest.BodyPublishers.ofString(content)) // add request body
.build();
HttpResponse<String> response = HttpClient.newBuilder().version(HttpClient.Version.HTTP_1_1).build().send(httpRequest, HttpResponse.BodyHandlers.ofString()); // send request
return response.body(); // response forceSave
} catch (URISyntaxException | IOException | InterruptedException e) {
throw new RuntimeException(e);
}
}
/**
* Create request body
*/
private String createJsonSave(String fileId) {
Map<String, Object> jsonStringMap = new HashMap<>();
jsonStringMap.put("c", "forcesave"); // command name
jsonStringMap.put("key", fileId); // WOPI file_id, for the file opened in step 2
jsonStringMap.put("token", jwtManager.createToken(jsonStringMap)); // creating jwt as for API request
return JSONObject.toJSONString(jsonStringMap);
}
Change document opened in hostPage (step 2)
Call the forceSave method (step 3), passing the file_id WOPI of the document open in hostPage
DocumentServer call REST method PutFile on WOPI server
P.S. Sorry, I can’t attach links to documentation due to restrictions for new users, I highlighted documentation in italics