In Multi user apps script logger I introduced how you could integrate logging from apps script with another technology. In this case a Polymer app. Further down the page, a live demo will have been kicked off as you are reading this..
The inspector has a demo mode, where it remotely sets off a demo apps script app, which logs some imaginary data. See Dogger settings for how to control its behavior.
You can see the results arriving in real(ish) time via the inspector. The demo app is shown below, and references my version of a library called yourDoggerServer where I have set up my preferred connection parameters.
In this example I'm creating multiple threads of logging - I can use that to filter later on.
This sets up my logger handle. . The actual database it will use is irrelevant to the Logging operation. It's centrally controlled in your version of yourDoggerServer - we'll deal with that later. I always use DriverScratch for this, since the log files will fade away by themselves if not accessed, and I don't have to bother maintaining them.
Now every where I would use Logger.log() , I can use Dogger.log(). You could even assign this to replace the Logger if you want (Logger = Dogger) and continue using Logger.log().
You get a bit more information than you do with the normal Logger.
Most of it is obvious, but here's a quick summary
For more about identifying where things are called from and what they are see How to determine what kind of object something is in Apps Script and Reporting file, function and line number in Apps Script
Sometimes its useful to categorize messages into groups. This is especially true if more than one process is contributing to the same log file. A thread is some text value you choose to assign to a message. The inspector provides a way to filter on specific threads, and you could do the same with other database or spreadsheet tools if you choose to use them.
In the example, you can see that I opened two Logger threads, one with no thread, and another where the second argument was the thread to use.
From then on I can use Dogger.log(message) to create a message with no thread, and Verbose.log(message) to assign a thread name to the message. You can see in the image below that the messages that have a thread value were written with Verbose.log() in the example given earlier.
This kind of logging is going to introduce overhead, since it now has to go and write things to a database. In addition, since it is multiuser by design, there is a lot of complication around locking (see Using named locks with Google Apps Scripts) to ensure that the integrity of the log is maintained when there are multiple simultaneous contributions. You can turn off locking if you are sure it's sole use when you open the database (see Working with transactions) but in the end, this is a tradeoff between visibility with Dogger and efficiency with Logger.
Let's dive a little deeper into how to set this up. I recommend that you take a look at Database abstraction with google apps script if you are not already familiar with how this works.
Note that in this demo, the database may be used simultaneously by others trying the demo, so you may get mixed results.
What is happening is ...
For help and more information join our community, follow the blog or follow me on twitter . For more on this topic see Multi user apps script logger
Services > Desktop Liberation - the definitive resource for Google Apps Script and Microsoft Office automation > Polymer > Multi user apps script logger >