I have this loop inside of a resource job that is iterating over users, I then using tenancy (I use the CPF template) to get the devices that user has access too. I then loop over those devices to send reports for each device as separate emails. I also use the API node to send dashboard reports to emails per device per user as well. Now I know this is a lot of API request and that is probably why I am getting the error saying a request for that dashboard is already queued. I just wonder if there is a different implementation I could do that would be lighter on the API calls. I’m not sure if you can put multiple devices into a single dashboard report, and even if you could im not sure that would solve my throttling issue. I was wondering if there was some way to get the link for the download of the PDF as a return from the node upon completion so i could just generate one report per device then send the same link in all the emails. Though Im pretty sure the API node is async and cant return anything like that. Any ideas for a solution or different implementation are appreicated
Now I know this is a lot of API request and that is probably why I am getting the error saying a request for that dashboard is already queued.
Yes, the Dashboard: Send Report API call is limited to one concurrent call per dashboard. So if you request another report while the previously requested report is still generating, you will hit that error.
I’m not sure if you can put multiple devices into a single dashboard report, and even if you could im not sure that would solve my throttling issue.
Well, if you build your dashboard to support multiple devices per report you could - but it would have to be a fixed number of devices, with a device context variable for each, and probably a lot of duplication of blocks.
I was wondering if there was some way to get the link for the download of the PDF as a return from the node upon completion so i could just generate one report per device then send the same link in all the emails. Though Im pretty sure the API node is async and cant return anything like that. Any ideas for a solution or different implementation are appreicated
Exactly; it’s an asynchronous job so you won’t have the PDF link in the response to the API request. The way around this is to use the API call’s callbackUrl
parameter, pass it a webhook URL, and kick off another workflow in response to that webhook request.
We have a couple templates that demonstrate this technique, though not within a resource job:
In your case, you would want to pass the resource job iteration ID as a query parameter to the callback so you could then acknowledge the iteration and kick off the next report. You’d also have to abandon the loop within the workflow and keep track of which device is next to generate in the callback.
You say you are iterating over users and then looping over devices … would it instead be possible to iterate over your devices and look up the user(s) who should receive a report? You can send a report to up to 10 email addresses. That may simplify this flow.
Exactly; it’s an asynchronous job so you won’t have the PDF link in the response to the API
request. The way around this is to use the API call’s callbackUrl parameter, pass it a webhook URL, and kick off another workflow in response to that webhook request.
does the call back contain the link for the download?
Yes, the callback request will be a POST request and the link to the PDF will be in the body of the request, along with some other information. On your payload that should be at the path of data.body.downloadUrl
.
I strongly recommend importing that Request Experience Dashboard Report template, even if just into a blank application, so you can see the process. That template also adds in some additional security settings like generating a JWT and verifying it to protect against potential abuse.
Is there an easy way to fetch users based on their access to a device, maybe through what group they are in? maybe by using the cpf site/customer tags. I dont see any easy way to search users by what group theyre in