Hi
Is it possible to return a http status before the end of an endpoint ? could this be possible ? i suppose not, but i could really use this feat … !
this is related to my long running endpoint question … so i have this endpoint that do some bulk stuff … and before entering a foreach loop, that could last for some time, i would like to return a http status 200 …
Anyone ? 
Hello, i guess you are referring to the REST API.
I never had that need but thought about something related with the same possible solution.
Maybe you can try to use Powershell jobs … Dont know if its working in UD but is worth to try it.
yes i’m referring to REST API.
i’m looking into $response variable but … no result so far
I am talking about starting a background job and do the long running task in the background.
After that end the REST method and this will automatically return 200 OK. This is something like a async api call …
oh sorry i forgot the background job in my response xD well i think the main problem will be passing cached variables in the job … or / and updating cached variables from the background job …
I we could create some kind of schedule job … where we could pass some parameters and launch it at will
from a REST Endpoint… that would be awsome !
working with jobs does not work … maybe a runspace ? but i dont think it will work … REST endpoints are runspaces no ? so everything is killed when the endpoint is done … i think
@adam any thoughts ?
I think this is totally related to my GitHub issue - https://github.com/ironmansoftware/universal-dashboard/issues/1393
Am I right?
Yes 
and adding the possibility to call this schedule endpoint from within another endpoint …
Something like this: https://github.com/ironmansoftware/universal-dashboard/issues/1394
Do not hesitate to add your needs and ideas.
1 Like
What kind of project are you working on? Where these features are required?
i have lots of REST endpoint to manage distribution groups / rooms / roomlists / ressources in general in exchange online … and for example creating a room, then for using a set-calendarprocessing is a pain … you have to wait for a least 30 seconds after you created a room to change the calendarprocessing … or else you might get an error saying your mailbox can not be opened … anyway !
i dont use the front part of UD (there is a python front, but to manage exo, the python calls UD Endpoints ! )
I had to tell them to not wait for a 200 reponse … but rather check a special endpoint (i call it notifications) where i store the different steps of this particular process… so they can know at wich step the creation process is exactly ( i n my process i update a cache variable … )
SO if i hade this kind of endpoints … it would be a walk in the park !
Totally clear use cases … Hope @adam can give us some news about the plan to have one time endpoints.
1 Like
I did some tests and the main problem is that in a Job the UD context is missing (e.g. $Cache: …).
@{message=Cannot find drive. A drive with the name ‘Cache’ does not exist.; location=; type=error; id=; refreshInterval=0; autoRefresh=False; hasCallback=False}
@adam is it possible to add this to a Job … I am thinking about something like Start-UDJob/…
Here is my test code:
$Endpoints = @()
#create a job
$Endpoints += (New-UDEndpoint -Url "/job" -Method "POST" -Endpoint {
param()
Start-Job -scriptblock {
$Cache:Test = @()
for ($i = 0; $i -lt 10; $i++) {
$Cache:Test.Add("$(Get-Date) - process")
"$(Get-Date) - process"
start-sleep -seconds 1
}
} | ConvertTo-Json
})
#get all jobs
$Endpoints += (New-UDEndpoint -Url "/job" -Method "GET" -Endpoint {
param($Id)
Get-Job | ConvertTo-Json
})
#get job by ID
$Endpoints += (New-UDEndpoint -Url "/job/:id" -Method "GET" -Endpoint {
param([int]$Id)
Get-Job -Id $Id | ConvertTo-Json
})
#get job data by ID
$Endpoints += (New-UDEndpoint -Url "/job/:id/data" -Method "GET" -Endpoint {
param([int]$Id)
Receive-Job -Job (Get-Job -Id $Id) | ConvertTo-Json
})
$Endpoints += (New-UDEndpoint -Url "/variable/get" -Method "GET" -Endpoint {
$Cache:Test | ConvertTo-Json
})
$Endpoints += (New-UDEndpoint -Url "/variable/set" -Method "POST" -Endpoint {
$Cache:Test = @("test", "test1")
})
Get-UDRestApi | Stop-UDRestApi
Start-UDRestApi -Endpoint $Endpoints -Port 10005
#testing
Invoke-RestMethod -Uri "http://localhost:10005/api/job"
$Job = Invoke-RestMethod -Uri "http://localhost:10005/api/job" -Method POST
Invoke-RestMethod -Uri "http://localhost:10005/api/job/$($Job.Id)"
Invoke-RestMethod -Uri "http://localhost:10005/api/job/$($Job.Id)/data"
Invoke-RestMethod -Uri "http://localhost:10005/api/variable/get"
Invoke-RestMethod -Uri "http://localhost:10005/api/variable/set" -Method POST
I dont know how the UD context (Cache and Session variable) is initialized but maybe its possible using the Start-Job -InitializationScript {…}
InitializationScript
Specifies commands that run before the job starts. To create a script block, enclose the commands in curly braces (
{}).Use this parameter to prepare the session in which the job runs. For example, you can use it to add functions, snap-ins, and modules to the session.
########################
after importing the module, the Cache PSDrive is there but its a different one than the one not using in the Job …
Start-Job -scriptblock {
Import-Module UniversalDashboard
for ($i = 0; $i -lt 10; $i++) {
$Cache:Test = "$(Get-Date) - process"
"$(Get-Date) - process"
start-sleep -seconds 1
}
} | ConvertTo-Json
you need to use -arguments on start-job to passe your data, then inside your scriptblock you reference your argument like this : $args[0] 0 being your first argument etc …
but it’s not going to work ! as soon as your job starts, the endpoint ends, and everything is destroyed (it’s a runspace) …
Thats not my goal for this discussion, I would like to integrate the Cache PSDrive into the Job in order to have a solution for your need to do async executions and other things like background jobs.
And the best way would be to have a global space to execute data like in my example (change a $Cache variable in the job and get it in another API call)
Start-Job starts an entirely separate process so you won’t have the same Cache values in the background job. You could use the ThreadJob module and it would work in this case because it creates background runspaces in the same process.