When working with dynamic service node trees, the assistant can have difficulty figuring how it can be structured as there is a dependency on previous services that may or may not affect the final result.
Example: Using a "for-each" loop makes it impossible to know the final result as it would be blank if the node path being looped on doesn't exist.
Solution 1: Create a static blank record so that 1 instance always exists. It can even be set up in an "if" statement so that the blank record only exists if the node path being looped on doesn't. As long as a blank record will not cause issues, then this could be a viable solution.
Solution 2: If it's desired to not have a blank record that can mess with later logic, then a second disconnected service can be an alternative approach. In this case, the static blank record exists outside of the execution flow and thus can be referenced without a blank record existing at runtime.
If the original service is exposing it's output, then exposing the disconnected service as well will allow anyone calling the method to also be able to take advantage of the assistant.
The one downside of this approach is that the original service is also still in the assistant. This means that the assistant may or may not show the node structure depending on which version of the service was selected in it.
Assistant Services and Dynamic Service Nodes
-
- Posts: 178
- Joined: August 31st, 2021, 11:37 am
- Contact:
-
- Posts: 571
- Joined: August 26th, 2021, 9:56 am
- Contact:
Re: Assistant Services and Dynamic Service Nodes
A projected response node has been added in a previous revision to achieve desired functionality.
word count: 15