Using Office Documents within Servoy

Hi there, and welcome to Servoy Tech Webinar. This will be number 46. Just a reminder that this webinar will be recorded and available shortly after. If you are attending this webinar live, you can, of course, ask questions directly. If you have happened to have missed one of our previous webinars and want to go back, we now have over 45 videos in our archives. These webinars are mixed up different topics ranging from Servoy basics to integrations of all sorts. Today’s topic is on document integration with Servoy and only office. Only office provides users with a way to create, edit, and collaborate on documents online. I want to point out that only office is not a Microsoft product. I’ll be at it, so there’s many of the same feature sets. We actually did a office 365 integration last year, so if you’re curious about that particular video, feel free to check out our archives. This edition of the webinar comes from Servoy Labs, where we are really excited to show all new things that we’ve been working on. These can be fully running proof of concepts for customers regarding different sorts of integrations. This particular solution has emerged as one of the potential options for document integrations, and we just wanted to share it with you all today. As per tradition in these webinars, we will start out with a few demos, then do a bit of code review and answer any questions you might have. So let’s get started with the demos first. The first thing here that we’re going to look at is the document editor. This editor is provided by only office via its document server, and it’s made available in Servoy Web Component. So what we’ll see shortly is that editor, I’m going to open up one of these documents that I’ve downloaded. The editor really has nearly all the features you might expect of other word office type document products, even their desktop components. You can make updates to texts such as different font types, styling. You can add images, tables, charts, etc. This is just a simple sample dot text that we’re seeing here. Let’s look at a more complex document. This one’s a little bit more complicated. It has some formatting already inside. This is a .x type, and you can see the available table views, and they even have some scripting inside this document, which is also supported by the editor. The editor also supports really large files. Let’s look at how quickly this one opens up and how it looks and performs. As you can see, it opens fairly quick. This document has over 175 pages, and it loads it within a couple of seconds here. That’s really nice. The editor also works with spreadsheets. In addition to viewing all the records here, you can also make edits and changes to them. You also have functionality such as some summing and other things you might expect from Excel type products. And of course, it also works with PowerPoint or presentation type slides as well. There’s a slide from one of our old Servoy world classes. These render fairly close to how the author intended it. It’s quite nice. With all of these documents that I’ve opened up, we also have the ability to convert them into a different type of document. I go back to the sample.txt file here. I have the ability to actually convert a document directly from the editor itself to a number of different formats. If I wanted to get it as a PDF, I can have it convert to PDF. I’ll open it up. Here it is. It’s PDF view. What’s nice is that formatting changes and things of that nature also pull over. So if I made a couple of changes here, I try that again. Let’s open it up. And those changes also come through on the PDF. So it’s a full conversion, including format types. Now in addition to converting it directly from the editor, you can also convert these things, you type the documents programmatically through their API. So we try converting it maybe to a different type like a .x. You can also do this programmatically. And now I get back a nice little document here. And I have opened this document on my desktop document editor. In this case, it’s the LibreOffice. Now the formatting comes through just as well. All right. So for this second demo, I’m going to show collaboration, real-time collaboration between users and a single document. Here I’ve loaded up two documents, a document in two different clients. I mean, new.x. And here’s also the same document. These are two separate browsers, two separate clients. And as you can see, once I start typing at the top here, the bottom also renders in real time what the change is made from the first user. Now with only Office, one of the cool features that has its ability to track changes and actually allow users to either choose to accept changes strictly or accept them in real time. So if I were to type now my new header, now you get to track the changes. And this other user has the ability to reject or accept certain changes. The author gets to see when they made the changes. So I chose, I could say, OK, I accept this change. That’s fine. So I’m going to do another change. And you know, we don’t like this change. We can also say we reject it and it’s rejected. So it also works with Excel type files too. We look at an Excel file. Make some changes here. Let’s update it. Everything is in real time. Maybe we want a little chart here. Let me get a little chart. All right. So that ends the demos. Let’s get back to the code and see how a lot of this is done. Where the steps you need to do to get this up and running for your own solution. We’ll start at the scope here. This is the example solution that we’ll be provided later on GitHub. So here we start with the endpoints for the document server. The document server comes with a few different endpoints. I’ve actually just used two. One is for the API.js. That contains all the API. It contains connections to the document editor. The other endpoint is for the conversion API. We also need a third endpoint within the Servoyitself that we expose. In order to communicate with the document server and when it talks back to servo, it’ll just manage the document and whether or not we want to save it to a database or to our own file system. This endpoint would be the starting point for that. I’m going to open up the demo form. This is the form that you guys saw. Here I just have a table component that allows me to show the files I’ve uploaded. Behind that is another tab panel for the editor itself, which I’ll make visible once we open up a file. If we look at just the table component, there is an event here that I’ve used called on cell click. Let’s go there. And if you remember in the browser, we had three different options. One was to open the file. One is to try to convert it. And the other was an X just to delete the file. So let’s look at the first event here, the open file. So in order to open one of these documents, we have to do a few things. The first is to convert it into an accessible URL that the document server can actually access. And so when I first uploaded the file, I uploaded it directly to a database. So what I’m doing here is I’m getting that record on click. And I’m going to convert it into an actual file on my file system temporarily. And then creating a remote URL to that file. This is done on the server side itself, so clients won’t really see this. But anyways, once you’ve done all of that, you get back every remote URL, which we’re going to then pass to the editor form via a load method. So this is the editor form. And just to show you, it really is a simple form with just the web component on here. Currently, the web component doesn’t have any type of callbacks or properties directly on the designer. Currently, it’s all done programmatically. So we do have one on load method that needs to be used and that’s to initialize the document editor. And we’re going to pass in this endpoint here that you get from the document server. So that’s what we’re doing on load, nothing else. The next step would be to then load the file. So those parameters are the file name, the URL, the document type. And most importantly, it’s this key, this document key. This is going to be used by the document server to identify the file. And when it sends back changes, it’s also going to use the same key. So keep that in mind, that’s an important concept here. So here’s where we’re actually grabbing the link to the callback URL. So this callback is for a web endpoint in the servoire REST endpoint. And that’s where we’re going to manage the file. So that’s where I grab it here. That’s also going to be passed along in this load method for the document. So first we destroy the current document, meaning we close the document if anything is open. Then we load the document. So here’s just a basic example of a JSON property that you might pass through to it. Obviously, I’ve customized it a little bit, but most of this will be the same for your integration. One key aspect of this is that the load function has a callback method. Within the callback, the first time that the document loads, it generates a new file key. And so what I’m doing here is I’m getting my current record in my database, and I’m updating the key so that we have a fresh unique key for our document. Once the file is actually loaded, what happens when you actually make changes to a document? So let me run the solution real quick. So here I’ve opened up a local client from my developer. So we’re going to look at what happens when you actually make some changes to a document. Now, when I’ve loaded this document up, I’ve actually set a property here called AutoSave to be true. So when does the save actually take place? Let’s take a look. Here I’ll make some changes, make some changes. You can see that AutoSave is happening, and it little disk shows up. So these changes are actually done on the document server. It has not come back to Sirboy or come back to your server-wood backend server yet. So when do those changes actually go back? Well, as soon as you close the editor, that’s what happens. So now we see a little message to get document changes and we’re writing back to the database. Where does that actually happen? As I said, I expose a REST endpoint here, and I’ll show you what that looks like. So here’s the endpoint that the document server will call back. So here it is. And it’s usually going to bring back a key and a URL that you have both of those. In my case, I just searched on the record base of the key they provided. And if your key is up to date, then you should get the same document. And once you have that record document, then all we’re doing is updating the data from the provided URL that they gave us. And that’s how you save your changes back to back to your backend. The other item that we looked at in the demo with the conversion process, how does that piece work? Let’s take a look. And that was back in the file manager. So let’s go back to the demo. And I’m so quick. That’s the second option here. So we do fairly the same things. We still need a remote URL. I add it to some extra plug-in here to show a little loading spinner. But aside from that, there’s not much difference. We still need a remote URL of the file. So we search for the file. We get it from a record, convert it to a remote URL. We pass it to this method called convert. So the convert method, what it does is it’s able to execute a post request on the conversion API, which we have here. And it’s going to be the same document server API IP address as the document server JS file. So it just goes to a different endpoint. And what we’re doing here is we’re setting up this JSON property, whether or not to do this conversion async, or a synchms. Or not, it’s actually. And then the file type, the key of the document, the output type that you want, and the URL of the document. Once you’ve done all of that, you call the post request, and you’ll get back a file URL. This file URL is a link to the actual converted document. And all we’re doing then is application.showurl, which downloads the application on your browser. So that’s really it for the items that we saw today. And the demo, let’s get back to the slides here. All right, well, we got a chance to look at the code, went through a few demos. Let’s get back to the slides a little bit here. And just take a look at some of the use cases with integration like this. Obviously, the main use cases would be editing a document in a web browser. Real-time collaboration between users and a document. Document conversion via the API. And of course, integration with the NG client and your Servoy solutions. Compatibility with Microsoft Office formats and open formats are also a nice plus. Remember that this architecture requires a few things. One of which is the document server, which is provided by only office. This can be installed via Windows Unix operating servers or Docker, if you’re familiar with that tool. It contains the text document spreadsheet and presentation editors that we saw today. And it exposes the document conversion API. To programmatically convert on the Servoy side, there’s two items. The editor component, which is going to be a wrapper really for the document servers. Yes, editor. And that’s going to be available via our GitHub site or the web package manager shortly. Then there’s the Servoy REST service endpoint that a document server and its editors can communicate with. And this will just manage the changes to an open or updated document on the server side. So is this something that’s going to be ready for production today? I think at the moment, probably not. There’s still a lot of work to be done. The current web component has yet to really be fully tested. Documentation on a lot of the features are there, but it’s still being worked on to get it from. to get it fully ready for end users. Not all features have been really integrated yet. The document server is available, but the current solution that we saw today doesn’t really utilize it fully. So there’s a lot more left that untapped. The command service API, which is another endpoint, is not used at all. And that allows us to actually programmatically modify and do some changes to the editor. And that was not in this demo. So that could be something that we work on in the future. If users need it or want it. The beta version, however, of this web component will be released. So you get a chance to try this on your solution if you’d like. And as always, we really welcome user feedback. And it’s important for us to get that feedback to move this into production level. For the future. So the demo will be available today on GitHub. All the stuff that we saw today. And I’m going to leave this link up so that you guys can grab it. And that really ends the webinar. Thank you for attending and watching the video.

Close