Set-UDElement with Session Info

Product: PowerShell Universal
Version: 5.3.2

I am aware of the Broadcast switch param, but I’m wondering if there is a way to pass a target $ConnectionId (or more specifically the SessionId) into the SendWebSocketMessage call to manipulate elements that exist within a particular session? I’ll make a feature request for this if it doesn’t exist natively. Ideally it would spread to the Add-/Get-/Remove- cmdlets as well.

For more context this call is being executed from within a Scheduled Endpoint.

@adam, does this reflect the example that you were outlining in the Implementation Assistance thread?

I think I’ve gotten somewhere by holding some things in $Cache. I’m using something similar to the following at this point:

# ./app.ps1
$sch = New-UDEndpointSchedule -Every 3 -Minutes
New-UDEndpoint -Id "tcpListenerEndpoint" -Schedule $sch -Endpoint {
  if ($Cache:tcpListener) { return }
  # tcp listener definition
  # processing the received data
  # $e represents target element to update
  $sessions = $Cache:relevantSessions.GetEnumerator().Where({$_.Value = $e})
  foreach ($ss in $sessions.Name) {
    $SessionId = $ss
    Set-UDElement -Id $e -Content { <# content to set within #> }
  }
}
New-UDApp -Content { ... }
# ./app.psm1
#... relevant module code
$tGuid = [GUID]::NewGuid()
# this is simplified; theres confirmation logic
$Cache:relevantSessions.$SessionId = $tGuid
New-UDElement -Tag "div" -Id $tGuid -Content { "Update me!" }
New-UDButton -Text "Update" -OnClick {
  #create tcpClient instance and write data to update
}

This method allows updating all sessions where that target ID exists based on the element’s existence necessarily adding itself to the cache variable that holds it all together. If you have multiple pages I could see holding the $PageId as being required as well based on the internal API calls including it.

Get-UDElement may also allow this to be the case, but it becomes messy when refactoring the relevant code within the foreach loop and then repeating it outside the loop for other elements that need to be broadcasted; if this is the way it’s supposed to work I’ll definitely put in a feature request to add session and page info as optional params for the relevant cmdlets.

Session management is tricky in general so I’m just glad I’ve been able to make this part work. It appears to save the listener definition across sessions but the lift is a bit insane to get this thing off the ground. I know this is not a common need by any means but hopefully this helps anyone else looking for similar functionality in the future.

Context for future recreators

This is just one piece of a massive project that allows our app to receive live updates based on event listeners running off endpoint agents, that sends the event listener data to an API. We have an API configured as the TcpClient that sends the data from the request over to the TcpListener running within the app and updates an element for every session where that element is shown to reflect the new data as soon as possible. We have an additional SQLite database running underneath that it pulls the initial data from, which is also updated when the API call to ensure newly opened sessions get the newest possible data. Making all the individual pieces was very fun, so I’ll let you handle that on your own, but this design is not only possible but very powerful!!