This year MWLUG comes from Atlanta, GA, promising over forty sessions and workshops on collaboration.
LDC Via will be there! Visit our stand and find out about our latest release, our new offering LDC Via Lens, and our forthcoming developer community, #DevHub.
Dev Hub is a new developer zone coming to LDC Via. This features integrated search with our technical documentation, highlighted blog posts and other information aimed at developers. As a developer you can also sign up for a free LDC Via account using just your email address, and play with the LDC Via API.
So if you’re attending MWLUG, come along to the stand, and we can tell you more!
“Search?” I hear you mutter, “full text search? Really?”
Well yes indeed! We’ve always offered a field-based search facility in LDC Via, but of course, chances are your users will want to search for a phrase across an entire document or collection of documents. Enter LDC Via’s full text search functionality.
Searching like this is often a must-have in an application, but it’s not straightforward to implement when dealing with a platform like LDC Via that offers document-level security. We took some time and did it right, implementing full-text search for those using paid tiers in LDC Via. So if you’re signed up to one of our paid plans, you have a single box to tick and you’re good to go:
Full search functionality will now be available in both the standard templates we offer and the LDC Via API.
You can also combine full text search with standard field-based search in a single query. For example, you could issue a single query to get all contracts with an issue date between 01-Jan-15 and 31-Mar-15 within the category “New client”, and mentioning “banana” anywhere in their text.
As you may know, we already offer free application templates for Discussions, Document Libraries, Teamrooms and mail files. But what do you do when you’ve migrated a custom database to LDC Via and you want to provide your users with a simple view of the data, no bells or whistles?
Enter LDC Via Lens.
Lens is an application template that is driven by configuration, meaning that you can define how a screen of data is laid-out and presented. Using Lens, you can quickly create an interface onto your data that will make sense to your users and allow them to interrogate and explore the data effectively and easily.
In the Database Viewer admin page, you can elect to “Modify Collection Schema” which shows all of the settings for a collection in your database. What this means is that you can see all of the fields for documents stored in the collection, change their data type, their position on-screen, and whether a particular field is an “LDC Via Lens” field (i.e. available to end users), with an associated field label. (We’ve added this distinction between “key” and “non-key” fields: all fields are important, but some are not ones that you need or want to expose to end users. By flagging a field as “key”, this means that when you use our Export to PDF API, or Lens, we will just show the key fields.) In the screenshot shown below, we have defined four key fields. Subject is positioned first, then Categories, From and Body. “From” we want to display with a label of “Created By” and the Body field is rich text, so we’ll just take the automatically parsed HTML version of that field.
Once these settings are saved, select the “Open as Application” link on the Database Viewer page and your work is done:
We don’t stop there! If the key field functionality is a nod to half of the old way of doing things in IBM (Lotus) Notes—i.e. forms—then what about the other half, views? Well, in the Database Settings screen, you can also create view filters. This means that any time a user accesses the database with Lens they can use the “views” that you’ve created to find useful data more easily. Naturally you can manage your views with our API, so if you’re building your own application, any views you create are still available.
Of course, all of this honours our document-level security model. You are free to distribute application URLs with LDC Via Lens functionality to all your users without any concerns about them seeing data they shouldn’t.
LDC Via Lens allows you to create a read-only user experience for your migrated Notes / Domino data in next to no time, and provides your people with an experience they can easily understand and work with. Let’s go through all this in a video, and you can see exactly how polished an interface LDC Via Lens can give you!:
If you want to go further (i.e. editing content as well as just reading it), we provide a beautifully-crafted set of REST APIs, as well as plenty of code samples to get you started. You can create applications against your precious data (or—of course—brand new applications) rapidly.
We’ve created a full featured API for development of custom applications with LDC Via, however, we’re aware that there is not always the time or budget to do large development projects, so we have also given you a jumpstart.
We’ve worked closely with the team behind the XComponents project. This is an open source framework based on AngularJS and Bootstrap that allows you to quickly create applications that will work on desktop and mobile devices equally well.
All of our standard templates (Discussion, Document Library, Teamroom and Mail) are developed using XComponents, and, even better than that, they’re all open source. You can easily take the source code for them and modify it to fit the needs of your applications.
At the simplest end of the spectrum, you’ll be able to take one of our templates and simply modify the data model to match the forms that you want to display. Of course if you want to get more complicated, then you can extend the templates to do anything that you fancy using the best of breed frameworks like AngularJS and Bootstrap.
If you have in-house developers, then the best starting point would be our Github page or we can help you with your application development needs as well.
There’s no point having an all-singing all-dancing database application, if the data is locked up and can’t easily be extracted, reported on, analysed, and easily re-purposed for use elsewhere. Everybody’s favourite tool for working with business data in these ways is Microsoft Excel. So, naturally, it’s important that LDC Via has great (excel-lent, in fact) support for Excel. And it does, using Microsoft’s ‘Power Query’ feature.
When we were talking to people at the Engage conference in Ghent, this question came up, so we felt it warranted a fairly detailed ‘how-to’ blog post. In fact, the process is pretty simple, and to make it even simpler we’ve not only written it down step-by-step, but also provided a downloadable Excel file to get you up and running.
Using Power Query, which is a free add on to Excel, we can create a parameter-driven spreadsheet that pulls in data from any internet source, including LDC Via.
As ever, the internet is a wonderful source for getting started with these things, so thanks to the likes of Ken Puls and Matt Masson this is what we built in a few hours: LDC Via - Excel Power Query Sample. There are two sheets in the workbook: ‘LDC Via Data’ displays a table of data that has been pulled from LDC Via; and ‘Settings’ contains the configuration settings that define where to get the data from, what API key to use, and which fields to display in the output results.
To create all this we need two Power Query functions and a main “routine” to actually get the data.
The first function is called fnGetParameter and simply reads the settings from the Settings worksheet: We have four configuration settings: endpoint defines the LDC Via API endpoint from which data will be extracted. The simplest one will use our collections API that gets lists of documents from a collection count defines how many documents at a time will be extracted from the API apikey is your API Key that authenticates you to LDC Via fields is a comma separated list of field names from the LDC Via collection that will be displayed in the results
Next we need to actually go and get each page of data from LDC Via, and the fnGetCollectionData function performs this task: The relevant page number is passed in as a parameter called “start”, and then we use the Web.Contents and Json.Document functions to retrieve the data and parse it into an object that we can work with.
The documentation for Power Query, is, shall we say, opaque at best, but there is a list of functions that are available to you on the Microsoft site—the Power Query editor itself feels very much like going back to the Notes @formula editor, but once you get your head around it, you can perform some pretty powerful operations on the data.
In our case we’re loading the JSON document from LDC Via, extracting an array of document objects stored in the “data” property, converting that to a table, and returning all this to the calling function.
Now we need to pull these two functions together and actually run the query to load the data: Power Query doesn’t really have the concept of a For style loop, so we have to spoof that by creating our own range of page numbers. In this case we’ll loop from 1 to 100, and with 1,000 documents per request that will allow us to get up to 100,000 documents from LDC Via. For each page we call the fnGetCollectionData function, extract the fields that are specified in the settings worksheet, and finally insert them into the main worksheet.
Clearly the speed of all this depends on the number of documents in the database in the first place, but even the example above, with 40,000 documents, takes less than a minute to load and parse all of the data.
To go and get data from a different collection in LDC Via, simply modify the settings worksheet as appropriate, right-click on the GetTableData function, and choose the “Refresh” option: the data will be automatically downloaded and parsed.
Of course, once all your data is loaded you can do all of the things that you’re used to with Excel: pivot tables, filtering, sorting, charts and so on. The world is your mollusc.