You open to “Invoke-UDAsyncScriptblock” (name is WIP)
Which does all this magic for you?
Yeah. I think we could just call it: Invoke-UDEndpoint (be consistent with naming?). It could then create a temporary Endpoint and run it through the same execution service as all other endpoints.
Invoke-UDEndpoint -ScriptBlock {
$Cache:SomeStuff = Get-SomeLongRunningStuff
}
Awesome!
Invoke-UDEndpoint does however sound like it’s intended to invoke existing endpoints, which Invoke-UDEvent already does.
Reinvent Invoke-UDEvent and include the funcitonality in Invoke-UDEndpoint or maybe call it Invoke-UDTempEndpoint ?
Probably should have an argumentlist aswell, and should be good?
I kind of like the idea of folding Invoke-UDEvent into Invoke-UDEndpoint since that’s what it’s actually doing and then make a new overload that accepts ScriptBlock and ArgumentList.
We could alias Invoke-UDEndpoint as Invoke-UDEvent as well to maintain backwards compat.
Another possibility is to have Invoke-UDEndpoint just accept an Endpoint object.
You could then use New-UDEndpoint to create the new Endpoint and execute it with Invoke-UDEndpoint.
1 Like
As it is an async function i would prefer something like New-UDAsyncEndpoint or New-UDBackgroundEndpoint
New as you create an object … Not doing anything with an existing object.
Fits to the powershell naming convention
Invoke-UDEvent has the “click simulation” functionality already, which would need to be redone in that case.
Rebrand Invoke-UDEvent to be purely javascriptily, and have Invoke-UDEndpoint be ondemand endpoint exection, sync or async?
Like this one the most … But should be clear that it is async
We could also use something like Start-UDEndpoint rather than invoke. That’s what jobs do and it would infer that it’s in the background. Invoke on the other hand would be synchronous.
Fair point,
Keep Invoke-UDEvent as is, and implement Start-UDEndpoint, which executes either endpoints or scriptblocks async?
Yeah. I like that.
Is there any need for an async switch on the cmdlet start-udelement?
I don’t think so. Just as with Start-Job, it would be assumed to be async. We could have a Wait-UDEndpoint but I don’t that’s necessary at this point.
Is everything invocation of an endpoint async?
HTTP requests aren’t async. They wait for the endpoint to finish before returning. Start-UDEndpoint would create a new runspace and then run the endpoint in the background without waiting for it to return.
1 Like
Just do sum it up … It is the same as Invoke-UDEvent but only async?
Yeah it’s similar. Invoke-UDEvent only invokes JavaScript events or scheduled endpoints.
Start-UDEndpoint would allow you to run any endpoint async but no JavaScript.
Part of me wants to also introduce Invoke-UDEndpoint that would run sync but not JavaScript.
So then:
Invoke-UDEvent - Runs only JavaScript events
Invoke-UDEndpoint - Runs any endpoint (Scheduled\New-UDEndpoint) sync
Start-UDEndpoint - Runs any endpoint (Scheduled\New-UDEndpoint) async
Also thought so … For this reason I would do an Invoke-UDEndpoint including a -Async parameter in order to have cmdlet consistency 
…
But this is only my humble opinion …
So if we want to call invoke-UDEndpoint/Start-UDenpoint with a specific endpoint, how can retrieve the endpoint from within a “standard” enpoint" ??
$longrunning = new-udendpoint -endpoint {something running for quite a while...}
new-udendpoint -url "test" -endpoint { param(whatever) invoke-UDEndpoint / start-UDendpoint -endpoint $longrunning }
should we cache the $longrunning endpoint ? $cache:endpoints = $longrunning ???
1 Like
When you call New-UDEndpoint it registers the endpoint with UD so we could implement Get-UDEndpoint as well to make getting a hold of it easier.
3 Likes