5 Minute, Duct Tape App Analytics Through Microsoft FlowIsaac JonesBlockedUnblockFollowFollowingMar 30Photo by Jonatan Lewczuk on UnsplashNow, let me preface this by telling you why this isn’t a good idea, because it’s not.
For my extremely specific use case, I wanted to track when my desktop (VB.
NET…shh I know, I’m learning C#) application was booted up on a client computer, and any errors that occur during use.
I did not need any significant analytics, and I did not have the ability to build a RESTful API endpoint to receive the analytics (corporate network, etc.
).
Also, not many people will be using the application.
Ideally, one would build an API that could handle these requests with Django, RoR, or any other web framework.
It really is the way to go, since it’s considerably more flexible, you can provision tons of resources, and really…this is a pretty duct tape-y, superglue-y solution.
I, on the other hand, needed a quick and dirty solution to test my proof of concept and didn’t have the resources to set up a web server.
So, without further ado, my solution!First off, create a new flow using the When a HTTP Request is received trigger.
First one on the list!You can specify whatever JSON schema you want for the flow.
Currently, I have the following schema:datetime — This one should be relatively self-explanatory.
type — Currently I have two types of analytics: boot — for analytics sent when the app boots, and error — for analytics sent when an error occurs.
error_message — Also pretty self-explanatory.
error_value — Stack trace for the error that occured.
application_version — Again, yep.
ip — Actually used for the OS version (I need to change it, I know)guid — Universal identifier generated by the application (Makes it easy to track how many users are sending analytics)My example payload, note my incredible laziness with not updating ip to a relevant name like version.
You can quickly throw together a sample JSON payload and feed it to the Flow trigger.
It’ll generate it’s own schema to handle it, how neat is that!What your flow should look like after dumping the sample JSON payload.
(Note: the HTTP POST URL will not be filled until you save the project)Now, all there is to do is throw the data into whatever storage medium you want to use!.Flow has connectors for Postgres, MySQL, SQL Server, a bunch of Azure stuff, and even more.
You can even connect a local SQL Server instance through to flow using the On-Premises Data Gateway!.( https://docs.
microsoft.
com/en-us/power-bi/service-gateway-onprem).
For the sake of this example, I created a SharePoint list to quickly store the data.
But in all seriousness, this data should be stored in some sort of proper database.
Sample schema for the SharePoint list.
Don’t use SharePoint though, it’s definitely not the right way to store this data!!!Connecting your flow to your data storage of choice is also incredibly easy.
Just select it from the list, and all of your JSON objects from the sample schema magically appear for you to add them in!Easy as Pie!I also made the flow return the HTTP status code 200 after successfully receiving the request.
It is on a parallel branch to the storage of the data.
You could have it return anything that you wanted, however I kept it simple since the app really doesn’t need to intake any data from the server.
Returns the HTTP status code 200 for….
Success!So, after you’re all done that, you should be ready to save the flow.
This will generate the URL you can use to POST to the flow.
If the submitted JSON schema does not match the provided sample payload, flow will even return a 4XX status code to let you know something is awry!.If you’ve followed along with this quick tutorial, your flow should look something like this (except without the SharePoint!):Hopefully your flow looks very similar to this!You can now spin up your favorite programming language, or Postman to test out the API endpoint! Postman is really handy for testing out whether your newfangled, duct tape-y idea works.
Just copy and paste the HTTP POST URL that was generated when you saved your flow, and then paste your sample schema into the body of the request, as I did below:POST request containing my sample payload.
The server responded with the HTTP status code 200! Success!If you look wherever you stored your data, you should see a new entry containing the data you sent to the server!Double success! It works!You can also test the flow in real time, and investigate any issues that pop up early.
Just press the test button at the top, right-hand corner, and then send a POST with Postman.
Huzzah!So there it is.
Duct tape analytics in under 5.
ish minutes! You can do so much more with Flow as well.
You could throw some if statements in there to separate your different types of analytics and store them in different tables, or have notifications sent to your email when a specific type of request comes in.
The sky is the limit!Be wary of the pitfalls of this approach, however.
It definitely is not designed for a huge deluge of data, and I’m unsure if that URL is 100% static.
Either way, as long as you are cognizant of the pitfalls, this can be an easy solution for some simple analytics.
Sample CodeBelow is some sample code in VB and Python to use in your projects!Happy coding :)VB.
NET Class for Tracking (Requires reference to System.
Web.
Extensions)Python Class for Tracking.