The Flexibility of Remote and Local R Workspaces

by Sean Wells, Senior Software Engineer, Microsoft

The mrsdeploy R package facilitates Remote Execution and Web Service interactions from your local R IDE command line against a remote Microsoft R Server instance. Both core features can be used independently of one another or combined to support different convenient workflows. These different workflows composed together can produce some creative R development and operationalization solutions.

mrsdeploy comes bundled with installations of Microsoft R Client and Microsoft R Server.

Before using any mrsdeploy API you must first authenticate against the R Server and before we authenticate we should become familiar with the different authentication approaches and their supported arguments. Currently, there are two ways to authenticate:

• remoteLogin() using an on premises Active Directory server on your network:

remoteLogin(
   endpoint, 
   session = TRUE, 
   diff = TRUE,
   commandline = TRUE, 
   username = NULL,
   password = NULL
)

• remoteLoginAAD() using Azure Active Directory in the cloud:

remoteLoginAAD(
   endpoint,
   authuri = NULL,
   tenantid = NULL,
   clientid = NULL,
   resource = NULL,
   session = TRUE,
   diff = TRUE,
   commandline = TRUE
)

Both APIs are equivalent in that they provide the means to authenticate against a Microsoft R Server instance. Take special note of the arguments session and commandline:

Argument	Description
session	If TRUE, create a remote session.
commandline	If TRUE, creates a REMOTE command line in the R console. REMOTE command line is used to interact with the remote R session. Parameter is only valid if session parameter is TRUE.

These two parameters are subtle yet can produce bold context switches from your local R workspace. Depending on their values, you can end up in one of three post authentication command line states in the R console:

State 1 - Remote Command Line

Authenticate, create a remote R session, and transition to the remote REPL command line. The default prompt REMOTE> indicates you are now interacting with your remote R session and are no longer in your local R environment:

# Taking the default arguments (session = TRUE, commandline = TRUE)
> remoteLogin("http://localhost:12800")
REMOTE>

State 2 - Local Command Line

Authenticate, create a remote R session, and remain in your local R environment:

> remoteLogin("http://localhost:12800", session = TRUE, commandline = FALSE)
>

State 3 - Local Command Line No remote session

Authenticate, do not create a remote R session, and remain in your local R environment:

> remoteLogin("http://localhost:12800", session = FALSE)
>

Now that we understand the different authentication scenarios and their arguments we can begin to compose them together with other supported functions. The mrsdeploy package provides many convenience functions to aid workflow from the R IDE command line. Listed below are a few that deal with context switching between your local and remote sessions post authentication:

Argument	Description
pause	When executed from the remote R session, returns the user to the local > command prompt.
resume	When executed from the local R session, returns the user to the REMOTE> command prompt, and sets a remote execution context.
putLocalObject	Puts an object from the workspace of the local R session and loads it into the workspace of the remote R session.

See the documentation for a full list of supported functions.

Expanding on State 1 as shown above, here we define an interactive authentication workflow that spans both our local and remote environments.

The same outcome can be achieved with State 2’s authentication workflow as it differs only in the R environment order. Here we start out in the local R session then move to the remote R session.

Finally, State 3’s workflow demonstrates authentication without a remote R session being created session = FALSE. This is useful if the intention is to only work with the Web Service functionality of the mrsdeploy package. Here we authenticate and remain confined within our local R session in order to publish and consume a service.

Note Web Service management can only occur locally. Attempting to use the service APIs during remote interaction REMOTE> will result in a error.

Feedback

I am interested in seeing what people build. If you have any feedback on the above approach or the mrsdeploy package in general, please leave a comment below.

Happy New Year!

Comments

[Anish Sharma]

Hello Sean,

Thanks for the article describing the new mrsdeploy package. In our organization, we have developed an application using MRS 8.0 and we used deployR for our application integration.

One of the function that we used was interruptExecution() which we used to interrupt a running R process and rerun with different arguments. Is this functionality removed or does the pause or resume helps with this?

Currently I am trying with MRS 9.0 and swagger API and will comment with few more things I find.

Thanks,
Anish Sharma

[Sean]

Hello Anish,

Thanks for the query.

1. Is this functionality removed


No. MRS 9.0.x still has the ability to "interrupt" using the core-server APIS, please see cancelSession I believe it is comparable to MRS 8.x while you use it in conjunction with executeCode


One caveat is that the user defined web services, (e.g.) the APIs that are consumable via (POST /api/:name/:version) currently do not have an "interrupt" feature. So it you published a service in R with `mrsdeploy` as defined below, there is currently no way to interrupt:

```R

longRunning <- function() { ..... }

api <- publishService('forever', code = longRunning)

# no way to interrupt
api$longRunning()

```

I think this in fine because will shortly have batch execution and async-execution inside `mrsdeploy` come March of this year. These are more suitable for long running scripts. Currently they exist in the core-server APIS just not the R package.


2. Does the pause or resume helps with this


No. The `pause()` and `resume()` functions are only part of the `mrsdeploy` R package. Their intention is to do a "context swtich" from your remote command line interaction and your local R IDE command line.


For example:


`REMOTE>`


This prompt indicates I am currently interacting with a remote R session in
MRS 9.0.x. All objects defined via this `REMOTE>` prompt are part of the remote
R session and not part your local R workspace in your R IDE.


`REMOTE> pause()`


This function does a "context switch" from your remote R session command line,
still keeping it active and returns interaction control back to your local
command line.

`> resume()`


The `resume` function does the opposite. It performs a "context switch" from your
local command line and its workspace/R-session [back] to the remote R workspace/R-session.

A summarized workflow example:

```R
REMOTE> # I am remote
REMOTE> pause()
> # I am now local
> resume()
REMOTE> # I am not remote again
REMOTE> exit
> # I am now local again and logged out and the remote R-session in closed
```

Please reach out with more questions/comments/suggestions. We are currently
pushing out more end-to-end examples.