Need guidance in designing a workbook and function app with api keys
My requirement is to have a workbook that calls our product’s apis and visualizes the data. The data to be visualized is divided into many widgets about 6-8 in total.
Hence, I am thinking of creating a http trigger function app when the workbook is loaded. This function app will be provided the context of our product’s url, api key, api secret, org_id as environment variables. These params will be provided by customer who deploys the solution.
Then, the function app uses the api key, api secret to make a GET call to the product URL. Note this is an outbound connection to a URL.
The api call is to fetch objects from an endpoint, il store this response in a _CL table. But I dont want this table to grow in size with each call to the custom endpoint defined by function app. Instead, I want the row to be updated with new response when workbook is loaded again. I don’t know if a custom table is ideal for this or maybe there is a different solution?
Do please let me know your opinion.
My requirement is to have a workbook that calls our product’s apis and visualizes the data. The data to be visualized is divided into many widgets about 6-8 in total.Hence, I am thinking of creating a http trigger function app when the workbook is loaded. This function app will be provided the context of our product’s url, api key, api secret, org_id as environment variables. These params will be provided by customer who deploys the solution. Then, the function app uses the api key, api secret to make a GET call to the product URL. Note this is an outbound connection to a URL.The api call is to fetch objects from an endpoint, il store this response in a _CL table. But I dont want this table to grow in size with each call to the custom endpoint defined by function app. Instead, I want the row to be updated with new response when workbook is loaded again. I don’t know if a custom table is ideal for this or maybe there is a different solution?Do please let me know your opinion. Read More