Why Low-Code Integrations and Workflow Orchestration is the Future of How Businesses Use Software
It’s probably no surprise that the vast majority of businesses are managing a continuously growing number of software tools. These continuously evolving ecosystems are creating risk and making it difficult to find or access the information needed for critical decisions. That means that in order to remain competitive, organizations experiencing this issue must establish new ways to securely make data accessible when and where it is needed in order to unlock the insights that will guide them into the future. There have been many ideas on how to stop this proliferation of tools, but we believe that modern businesses will continue to need a wide variety of software in order to accommodate the growing number of business processes that make them unique. Instead of trying to block people from using the tools they need, we think that orchestrating workflow across different systems is an even better way to streamline the way that work gets done. We’re not the only ones who are seeing an increase in the demand for process innovation and automation either. Industry experts are beginning to talk more about how the need for automation across multiple systems is far outpacing the methods and resources available to support it, putting businesses at risk of falling behind expectations and competition. “By 2022, 80% of organizations that pursue a cloud-first strategy will forgo the use of RPA (robotic process automation) in favor of low-code integration platforms.” -Gartner (2019)* As we get ready to introduce new capabilities in early 2020 for Quickbase that will make it both fast and easy for businesses to automate processes and integrate workflow, here are a few ways that you can tell whether your business might benefit: Legacy systems no longer support the unique workflow and integration needs of your business There are not enough developers to support the pace of innovation required to stay ahead The cost, complexity, and risk of your application and integration ecosystem is burdening IT groups and slowing business down If any of these scenarios sound familiar, then here are 3 reasons why we believe that our new Pipelines technology will offer you an intuitive way to use the Quickbase platform, finally making it possible for the tools in your business to work together the way you need them to. Pipelines executes workflow in real-time, meaning that data is up to date where you need it, when you need it. Pipelines has a library of pre-built integration channels that make it easy to stretch processes and workflow across all the systems that people use The intuitive drag and drop interface makes it easy for Quickbase app builders of all different backgrounds to define exactly what needs to happen and when If you’re interested in learning more, we recommend signing up for updates below. *Gartner, "Automate Business Operations to Scale Your Digital Business," Rob Dunie, Saikat Ray, 26 November 2019
IOL Technique Officially Approved By QuickBase
I missed this the other day when I posted about the form used by QuickBase on thier Quick Base Customer Awards nominations. In my post I mentioned that QuickBase had created a custom Save button that saved and redirected to a unique page and I also presented the code they used. What I forgot to mention (I missed seeing it) is that QuickBase itself is using a version of the IOL technique to hide the native Save button so as to make the custom Save button the only functioning button. The Forum post has been removed: https://community.quickbase.com/quickbase/topics/quick-base-customer-awards-nominations-are-open But the new record pages are still accessible: The Quick Base Hero Award ~ Add New Record https://team.quickbase.com/db/bneu8emfj?a=nwr If you watch very carefully upon page reload you can see the Save button momentarily appear and is then rapidly hidden. The HTML code QuickBase is using to achieve this is as follows: <table id="sect_s8" class="formSection LabelsAbove"> <tr class="formRow "> <td id="tdl_23" class="label lc RichTextField" colspan=100> <label class="fieldLabel " for='_fid_21'><b >Hide Green Buttons</b></label> <div id="tdf_23" class="cell dc RichTextField" > <img src='/i/clear2x2.gif' onload="javascript:$(document).ready(function(){$('.IconOnly').hide();$('#saveButton').hide();})"> </span> </div> </td> </tr> </table> Here is a screenshot of the relevant HTML in the inspector (which helpfully points out an unbalanced </span> element) The code above basically uses the image onload technique I created almost a decade ago but simply does not use a code page because the script in question was so short. So we have to conclude that QuickBase sees the value in script as a handy workaround and will be working hard to provide a supported way to introduce script into the product. For reference here is the accompanying post that described how QuickBase formed their custom Save button: This is !important https://community.quickbase.com/quickbase/topics/this-is-important Pastie Database https://haversineconsulting.quickbase.com/db/bgcwm2m4g?a=dr&rid=633Announcing QuickBase Service Worker Council and QuickBase Crank
The newly formed QuickBase Service Worker Council met this morning for breakfast at the annual QuickBase Empower conference in Boston to welcome new members, clarify it's charter and review new applications that incorporate Service Worker technology into QuickBase. I am happy to announce the the Service Worker Council has unanimously voted to implement and release the QuickBase Crank proposal which will allow QuickBase users to significantly speedup their QuickBase applications. QuickBase Crank allows a user to configure a custom Service Worker which can modify the caching policy of critical assets such as JavaScript and CSS files, substitute a minimized and faster loading version of an asset or even block the loading of subordinate assets that are not critical to the performance of a QuickBase application. Initial testing of QuickBase Crank have demonstrated a twofold increase in page loading times as well as the potential for offline usage of a QuickBase application with later synchronization when network connectivity is regained. In addition to its technical capabilites - which are quite impressive - QuickBase Crank requires no external services or subscription fees and is widely supported in modern evergreen browsers. The QuickBase Service Worker Council is also announcing a call for new members and new features to implement with Service Worker technology. If you would like to participate in the Service Worker Council meetings and deliberations or have a suggestion for using Service Worker technology with QuickBase feel free to reply to this message or contact me off-line using the information in my profile.How to install BOL (Branding On Load)?
We previously posted the BOL (Branding On Load) instruction as a file attachment but in the conversion to the new forum attachments were dropped. Here is an updated method of installing BOL: Step 1 Create a code page named moduleBOL.js and place some simple content in it such as this one line of code: console.log("moduleBOL.js loaded"); Step 2 Visit your Branding Page https://<YOUR SUBDOMAIN>.quickbase.com/db/<YOUR APP DBID>?a=AppPropertiesBrandGuide Step 3 To turn BOL ON, press F12 and paste this code into the console tab: //turn on BOL (function(){ var page = "moduleBOL.js"; var formData = new FormData(); formData.append("PageToken", $("input[name=PageToken]").val()); formData.append("customHeader", "on"); formData.append("uiCustomHeaderOptions", "iBasic"); formData.append("uiCustomTextColor", 'white !important\n}</style><img src='' style='display:none' onerror=$.getScript(gReqAppDBID+'?a=dbpage&pagename=${page}');><style>foo {\nbar: baz'); fetch("?a=SaveAppSettingsBrandGuide", { method: "POST", body: formData, credentials: "include" }); })(); Step 4 To turn BOL OFF, return to the branding page, press F12 and paste this code into the console tab: //turn off BOL: (function(){ var formData = new FormData(); formData.append("PageToken", $("input[name=PageToken]").val()); formData.append("uiCustomHeaderOptions", "iDefault"); formData.append("uiCustomTextColor", "white"); fetch("?a=SaveAppSettingsBrandGuide", { method: "POST", body: formData, credentials: "include" }); })(); Notes: 1) This code uses the Fetch API, the FormData API and ES6 backticks. You can google these terms or ask a question here if you need a better understanding. 2) Some people have inquired about the credentials: include property and value used in the code. This is not your QuickBase login/password credentials and is perfectly safe to use. By default the Fetch API does not send cookies so including credentials: include merely sends your cookies to QuickBase which includes your ticket. Sending your cookies to QuickBase is the normal operation. 3) Setting up BOL will include moduleBOL.js on every page in your application including administrative pages. In contrast the IOL technique injected code only into {new, view, edit, report, grid edit} pages. Also, moduleBOL.js will load relatively early in the process of loading your page. You will have to supply your own decoding logic to determine what page you are on and what actions you want to take. 4) Part of the reason we are introducing this version of BOL is to acquaint you with the Fetch API, the FormData API and ES6 features (not just backtick). These are powerful features to use with QuickBase in their own right as you can do some amazing things in a short amount of code. 5) But the real reason is to slowly introduce you to Service Workers which will blow away all these other methods of introducing JavaScript into your QuickBase pages and provide amazing new features you never though possible in a browser (like offline QuickBase - nope I am not joking). In the next few days (maybe tomorrow - it depends on if I get my grass cut today) we will launch the Service Worker Travel Log which will feature a new aspect of using Service Workers with QuickBase. So clear you head, pack your bags and bring lots of cash as we embark on a 30 day adventure of using Service Workers with QuickBase.Service Worker Travel Log - Day 8
Day 8 - Warning! Warning! Alien spacecraft approaching! I first learned about Service Workers a little over year ago during a casual hallway conversation with another developer at a technical conference. At the time there was not a lot of information available and Google and Mozilla were taking their first steps releasing Service Workers in their Chrome and FireFox browsers. While it is still early days for Service Workers, today there is a growing amount of documentation, tutorials, blog posts, utilities and developer tooling available. However, it can still take a considerable amount of time to wrap your head around Service Workers because they are unlike other features traditionally found in browsers. Here is a blog post that is both helpful and humorous and uses a novel metaphor to explain that a Service Worker is just "an alien you can invite to live on user's browser": Service Worker, what are you ? https://kosamari.com/notes/Service-Worker-what-are-you Calling out warnings and summoning aliens may paint a picture that Service Workers are difficult or even dangerous. That is not the case. Some of the brightest minds in the industry have contributed to the technology and major companies are implementing Service Worker technology for a variety of reasons. In fact, Service Workers are a core technology in the larger trend named Progressive Web Apps (PWA). Here is an overview presentation from a recent Google I/O event that explains PWA in greater detail: I have a prediction that by Empower 2018 you will see both the core QuickBase product and independent developers offer many new features, products and services that move whole QuickBase ecosystem in this PWA direction. Next Up: Day 9 - I Forgot To Mention ThisService Worker Travel Log - 30 Days In The Hole
Day 1 - You Got Em Perhaps you heard about Service Workers or have even see a demo of their usage with QuickBase. Well in this first post about using Service Workers with QuickBase I want to simply convince you they are safe, used by the largest internet based companies and in fact you already have them installed on your computer and don't even know it. Just load up your Chrome browser and visit this special URL: Service Worker Internals chrome://serviceworker-internals/ On the computer I am currently using I have Service Workers installed from Google.com, Youtube.com, Weather.com, Dropbox.com and Twitter.com just from my casual browsing (this is a non-development computer). On my development computers I have hundreds of Service Workers that I have personally installed and a couple of dozen from my own casual browsing history. What Service Workers did you find on your computer? Next Up: Day 2 - How Do You Get Rid of Them?Service Worker Travel Log - Day 12
Day 12 - Give Us JSON Response! You don't know how many times I have heard users and developers ask that the QuickBase API return JSON instead of XML. Apparently this request has just never floated to the top of the QuickBase's feature list. Perhaps we should start a concerted campaign to flood the QuickBase User Voice channel with votes for this feature, stir up a complaint storm in the Community Forum and personally lobby our individual Customer Success Managers. Well that sounds like a lot of work that could take a long time with an uncertain outcome. How about we just implement the feature our self in a few minutes using our new best friend the Service Worker. Yeah let's do that instead. As a starting point you might remember that this problem was solved using jQuery: How To Get JSON From API_DoQuery? https://haversineconsulting.quickbase.com/db/bgcwm2m4g?a=dr&rid=395 But the problem with this approach is that you have to include a helper function XMLFlatToObj ahead of every place you might want to return JSON from API_DoQuery. It would be a lot more convenient if we could simply specify a parameter &fmt=json to API_DoQuery and return JSON instead of XML but not otherwise alter the native behavior of API_DoQuery if called without this special parameter. Can a Service Worker to that? Yes it can dear reader and it can do a whole lot more. To see our solution in action visit our application dashboard to register a new Service Worker sw8.js with scope bmtpmup9q (Table #8) Service Worker Travel Log Dashboard https://haversineconsulting.quickbase.com/db/bmtpmup9q Now jump over to Table #8 and press F12 to expose the developer tools console and paste in the following script which makes a call to API_DoQuery using our new parameter value &fmt=json: var dbid = "bmtpmup9q"; var dbidTable8 = "bmt87ephd"; var apptoken = "bpn2piidu367nrbfezws9dmz6qc6"; $.ajaxSetup({data: {apptoken: apptoken}}); $.get(dbidTable8, { act: "API_DoQuery", qid: "1", options: "num-3", fmt: "json" }).then(function(json) { console.log(JSON.stringify(json, null, " ")); }); Your console session should look like this: For comparison, if you omit the &fmt=json parameter you will get the normal XML response from API_DoQuery: Here is a link to our new Service Worker sw8.js and a listing: Code Page sw8.js https://haversineconsulting.quickbase.com/db/bmtpmup9q?a=dbpage&pagename=sw8.js importScripts("https://haversineconsulting.quickbase.com/db/bmss68i2j?a=dbpage&pagename=cheerio.js"); self.addEventListener("install", event => { event.waitUntil(self.skipWaiting()); }); self.addEventListener("activate", event => { event.waitUntil(self.clients.claim()); }); self.addEventListener("fetch", event => { var params = new URLSearchParams(event.request.url); if (params.get("act") == "API_DoQuery" && params.get("fmt") == "json") { event.respondWith( fetch(event.request).then(response => { return response.text().then(body => { $ = cheerio.load(body); var data = []; var record = {}; $("record").each(function() { record = {}; $(this).children().each(function () { record[$(this).prop("tagName")] = $(this).text(); }); data.push(record); }) var newBody = JSON.stringify({records: data}, null, " "); return new Response(newBody, {headers: {'Content-Type': 'application/json', 'Cache-Control': 'max-age=0'}}); }); }) ); } }); You can probably sort out what this new Service Worker is doing but there are a few new things introduced in this code that due to the length of this post we will have to pick up on Day 13 (whenever that occurs). Next Up: Day 13 - Hip Hip Cheerio!Service Worker Travel Log - Day 5
Day 5 - She's so Fetching In our previous post we used the Fetch API in a Service Worker to log the URLs of all navigational requests to a log table. If you are unfamiliar with the Fetch API it is the replacement used in modern browsers for the XMLHttpRequest API to make network requests. XMLHttpRequest is also the underlying mechanism that older libraries like jQuery use to form their AJAX requests. However, XMLHttpRequest will slowly fade out of usage in browsers and cannot be used in Service Workers. Within Service Workers network requests are exclusively made through the Fetch API and for good reason. Along with the Fetch API come objects that represent Requests, Responses, Headers, Bodys and Caches which gives developers complete control over how network requests are detected, managed and responded to. With Service Workers it is possible to (1) detect any network request and allow it to respond normally or to (2) substitute or (3) modify the response. It is even possible to respond with a previously cached copy of a response thus allowing an application to operate offline. It will take time for these concepts to be fully appreciated as browsers have never had these capabilities before and they are extremely powerful. This humorous video highlights the fact that Service Workers along with the Fetch API give you complete control over the network and is worth watching to drive these points home: Service Worker Game Changer (skip to 1 minute 15 secondes) https://www.youtube.com/watch?v=wl3kKBw-MGk&feature=youtu.be&t=1m15s We also need to mention that Service Workers are asynchronous in nature and make extensive usage of Promises. What this means in practical terms is that Service Workers listen and respond to Domain Events. In between Domain Events, Service Workers do not consume resources and merely sit around waiting to spring into action when a Domain Event occurs. A nice way to visualize the situation is that a Service Worker once installed sits between your visual browser display and the Server you are accessing You can think of Service Workers as a Network Proxy implemented in JavaScript that use the Fetch API to to manage network requests to the Server and have complete control over the requests and responses. Next Up: Day 6 - Can You Sub For Me Tomorrow?Service Worker Travel Log - Day 10
Day 10 - Show Me More! Okay let's show some more uses of Service Workers with QuickBase. We have a cornucopia of use cases in our arsenal that will amaze and delight you all of which most QuickBase users would think are impossible. In fact, what you already know about Service Workers already empowers you to accomplish the impossible and we haven't even got to the good stuff yet. What will 20 more days of the Service Workers Travel Log yield? Sometimes it is the littlest things that cause the most annoyance. For example when I create a new report I would prefer that the Report Builder preset some options by default such as selecting the Filter records option and selecting the <Some field> criteria as indicated here: Instead QuickBase opens the Report Builder in the following state and I have to manually make the above changes: So to fix this little annoyance let's use essentially the same Service Worker used on Day 7 to load a code page named bmt8x7tm6.js on every page within Table #7. We will further arrange for bmt8x7tm6.js to contain the following small piece of script that manipulates the form to our liking if we happen to be on the Report Builder page for Table #7: (function(){ var querystring=document.location.search; if (/a=ViewBuild/i.test(querystring)) { $("#Radio2")[0].click(); $("#critFID_0").val("0").trigger("change"); } })(); I will note in passing that these particular statements emulate user input and emulating user input is generally the safest way to customize a QuickBase page with script. We have again modified the Service Worker registration page (reg.html) to now register sw7.js with scope of bmtpmup9q (Table #7). Now just pass through the application dashboard to register our newest Service Worker sw7.js: Service Worker Travel Log Dashboard https://haversineconsulting.quickbase.com/db/bmtpmup9q Next bring up the Report Builder for Table #7 and observe our desired changes have been applied automatically: Modified Report Builder for Table #7 https://haversineconsulting.quickbase.com/db/bmt8x7tm6?a=ViewBuild With a little imagination you can see that there are almost unlimited uses for this particular pattern. Now you may be wondering why we didn't make our modifications to the Report Builder page in the Service Worker itself. Well one reason is that the Service Worker does not have access to the DOM (Document Object Model) so we could not use the two concise jQuery statements in the code page bmt8x7tm6.js to accomplish this goal. But a second reason is more important. What if we just used a single generic Service Worker to inject a <script> tag on every page in the application referencing a code page named after the dbid with the extension ".js" through the src attribute? Well it turns out that this and similar conventions of using Service Workers with QuickBase work out extremely well. Next Up: Day 11 - Will it Blend?
