As I’ve written about before, Microsoft’s PowerApps product is a fantastic addition that facilitates the extension of a company’s ERP or CRM software to mobile devices and custom processes. Often, we leverage both the connectors native to Microsoft Flow and PowerApps to do so, however, depending on whether there is an existing connector, and the depth of the Flow actions relating to that connector, we may need to leverage an ERP or CRM software’s API to satisfy the requirement laid out by our customer. In these scenarios, we use Flow’s HTTP Request action to query data from or post one of our customers’ software.
When it comes to the API’s we work with, most have relatively simple authentication protocols that we’ve been able to build into our Flow-generated HTTP requests, however, Netsuite presented an issue.
Netsuite uses Token-Based-Authentication meaning that any application that wants to communicate with it will need to generate a token to authenticate to it. In Netsuite’s case, their token requires several parameters generated in Netsuite’s UI (Token Key and Secret, and Consumer Key and Secret), a random string called a “Nonce”, a timestamp, the environment you’re trying to connect to, the OAuth version, a “Signature” and a signature method. The signature is the concatenation of the “Base String” which is all the aforementioned parameters and a second concatenation of the consumer and token secrets. After the signature string is generated, it will need to be hashed using HMAC-256 – which is where the issues begin in Flow. Up until this point, everything seems relatively easy, but it gets tricky when needing to hash the signature, as Flow does not have any connectors that can do the transformation.
This put us in a quagmire – without the ability to hash the signature, we couldn’t authenticate to Netsuite and thus couldn’t push any data back to Netsuite. One option would be to have one of our developers write a C# application that we could access through Flow in order to generate our header. The issue with this, however, would be the associated development costs and hosting costs that would make the Flow integration more expensive to implement and maintain.
While trying to find a different way, I found myself frustrated with the conundrum I was in – it seemed so close because I already had Javascript and C# code that could create a properly formatted authentication header, but I couldn’t access it on the Flow side of things. After a while of puzzling over this task, an unconventional idea popped into my head – since I was able to build a valid header in Javascript and thus deploy it from Netsuite’s end, what if I were to trigger my Flow using a scheduled script and pass the header along then?
I quickly began testing and voila! It worked, but with a few limitations. Firstly, the biggest limitation is the inability to push data from Flow to Netsuite in real-time, as the trigger for my flow must come from Netsuite. While I can run the “trigger script” every 15 minutes, it still cannot be pushed the moment new data is ready to be posted to Netsuite. Secondly, a Netsuite token is only valid for a little bit less than 5 minutes. Thus, the actions performed in my flow need to complete before the time is up to be able to write back to Netsuite. In the context of the project I was working on when we ran into this issue, neither of these limitations was a deal-breaker – I have the trigger set up to run every 15 minutes, and process small batches to make sure that I don’t hit the time limit on my token.
Overall, while certainly not the most elegant solution, this hack has allowed us to create a closed-loop with Netsuite – for several of our existing customers, we pull supporting data out of Netsuite and then periodically throughout the day bring various records back, whether that’s sales, inventory, or custom data that needs to be accessible through Netsuite itself.
