Programmatically triggering re-rendering of RMarkdown document hosted on RStudioConnect

Posit Professional & Hosted Products Posit Connect
, ,
1

Hello! I am wondering if it's possible to programmatically trigger a refresh of an RMarkdown document that is hosted on RStudioConnect? My use case would be something like this:

  1. Extract and process data using RMarkdown document, deployed to RStudioConnect. This document is scheduled daily.
  2. The processed data is pinned to the RStudioConnect board via pins and is used by other applications.
  3. Within those applications, users may want the ability to trigger a data refresh -> accomplished via re-rendering of the RMarkdown document in step 1.

How can I set up a trigger from the application, as described in step 3?

Thank you!

1 Like
2

That's a really interesting setup, thanks for sharing that @dwhdai! Apologies for the delay in responding. I will definitely pass this along to the product team.

Unfortunately, there is not a publicly documented way to accomplish this today. Further, there may be some nuances around permissions and how the application has access to refresh the R Markdown report.

However, there is an experimental R package (connectapi) that recently added an exploration of this type of functionality. In particular, a workflow like the following might get you started:

library(connectapi)

client <- connect(host = "myhost", api_key = "my-api-key")

rmd_content <- content_item(client, "my-content-guid")

rmd_content_variant <- get_variant_default(rmd_content)

my_rendering <- variant_render(rmd_content_variant)

poll_task(my_rendering)

get_variant_renderings(rmd_content_variant)

I hope that's helpful! We would definitely love to receive any feedback you have about this process and whether there are additional things we can do to simplify the workflow. At a minimum, we definitely plan to have this type of API request more publicly documented in the future.

3

This looks useful - we'll try it.

We're also considering if there is any way to completely disable (and preferably hide) the schedule panel

image

We already have a number of report schedulers which are wired up to lots of monitoring, to distribution mechanisms (email, Teams, sFTP, etc) and to audit - so we'd rather use our existing schedulers to request reports from Connect rather than to have to extend Connect in lots of ways.

I've tried switching off concurrency:

[Applications]
ScheduleConcurrency = 0

but that didn't hide or disable the UI.

Is there any way to disable and hide the built-in scheduler options?

4

That's a very interesting use case, and a great point! There is unfortunately no way to disable the schedule UI today, but setting ScheduleConcurrency = 0 will definitely disable the execution of schedules. This could potentially confuse users who schedule reports but they never execute.

Something else worth keeping in mind is that adhoc renderings do not go through the "email" engine on RStudio Connect. So if you want to use the RStudio Connect "custom email" behavior with subscriptions, unsubscriptions, etc., the canonical way to do this is through a schedule.

We will definitely share this feedback with the team, though! A flexible way to integrate into another scheduler for execution and email delivery would be very helpful for this case.

5

Thanks

I'm happy for adhoc's not to go through emails. In our case we'll want to use an existing scheduler, existing monitoring/error reporting, and existing distribution methods :slight_smile:

1 Like
6

Good to hear! :smiley: For background, I want be sure you are aware of the ability to customize emails and such on Connect. You can do much of the same functionality yourself through other channels, of course, but this functionality is often helpful to publishers :smile:

https://docs.rstudio.com/connect/user/rmarkdown/#r-markdown-email-customization

And the R package that powers much of the customization, previewing, etc. through R Markdown:

7

Hi all,

Thanks a lot for this question and the answers that have been provided already. We've had the exact same use case as @dwhdai , and the solution provided worked a charm - absolutely brilliant!

Given this post was last active over a year ago, I just thought I'd check - the connectapi package and the functions used in this example still appear to be experimental and come with warnings when used. Before I build in too much reliance on this method... Does anyone know if there is a more "conventional" method out there now, or is this pretty much still the go-to?

Many thanks! :smiley:

8

Howdy @tzwagerman ! Welcome to Community! Great question! And glad to hear that this solution has worked for you!

This is still the "conventional" method out there. However, we have added a bunch of other API endpoints formally, so there has been progress towards the goal of formalizing this approach! What we have done in those casees, and what we expect to do here, is to release publicly documented API endpoints (i.e. no longer "experimental") and then pivot the connectapi functions to use those APIs instead.

As a result, your entrypoint to this functionality should hopefully be sound for the future! If we fail at that objective and end up needing to create new functions / change arguments / etc., we will add such breaking changes to the NEWS in connectapi, so always good to pay attention there when upgrading the package or to the release notes when upgrading RStudio Connect.

I hope that helps! We are excited to move these functions to non-experimental status for sure - it just takes time to get there :smile: In the meantime, we are very glad to hear that the existing solution is useful to folks like you!

9

Hi @cole ,

Thank you for your very helpful response - the move towards publicly documented API endpoints sounds like a great step and I look forward to working with the non-experimental version in the future!

1 Like