Solution Service
The SolutionService exposes information about the solution that is currently running and the Intrinsic platform it is running on.
It is meant to be used by skills and services that need certain pieces of information about the platform and the running solution.
The SolutionService exposes functionality through its gRPC API.
The API is available inside the cluster through the Ingress at istio-ingressgateway.app-ingress.svc.cluster.local:80.
Platform and solution status
The solution service provides insights into the status of the running solution (if any) and the platform running on a cluster/IPC through the GetStatus RPC.
The returned Status proto message contains the following key pieces of information:
- state and informations about the state (see state below)
- unique name (ID) and human-readable name of the running solution (if any)
- whether the solution is running in simulation
- name of the cluster/IPC running the platform
- version of the platform
State
The platform is always in a so-called state. This concept of state provides high-level insight into whether the platform is fully deployed and whether it has a solution running on it.
Consider reading the documentation provided on the State proto message for details about every possible value.
Available functionality
Some functionalities of the platform and the running solution are only available in certain states. The reason for this is that some functionality requires certain platform services and/or solution assets to be fully deployed.
| Functionality | Available in states |
|---|---|
| Solution deployment | PLATFORM_READY |
| Editing | DEPLOYING, READY |
| Process execution | READY |
All other states imply that something about the platform/solution is not ready for interaction.
Processes should only be executed using the Executive when the solution is in the READY state.
Behavior trees
Processes saved with solutions are modeled as behavior trees that can be executed using the Executive.
Each behavior tree is a single process that performs some task in the solution.
These processes are created in Flowstate and saved with the solution.
The SolutionService allows querying processes saved for the running solution.
Processes queried this way can then be executed using the Executive.
Reading
The most direct way to retrieve a process if its name is known is the GetBehaviorTree RPC of the SolutionService.
It returns the full behavior tree as a proto message that can be sent to the Executive as is for execution.
The SolutionService also enables process discovery through the ListBehaviorTrees RPC.
As the name implies this will return multiple processes saved with the running solution as a list in ascending alphabetical order by name.
Results are paginated to provide good performance.
Listing defaults to a BASIC view that only contains the name of the process rather than the entire behavior tree.
This enables listing many processes without needing to transfer large amounts of data.
The entire behavior tree can be retrieved afterwards by requesting the desired process with GetBehaviorTree by name.
Alternatively, processes can also be listed with a FULL view that contains the entire behavior tree.
Listing many processes with the FULL view can cause large data transfers. Consider setting the page_size to a smaller value when using the FULL view.
Writing
Processes can also be written to or deleted from a running solution.
Any process written to a solution can be retrieved using GetBehaviorTree and ListBehaviorTree described above.
The CreateBehaviorTree RPC allows storing an arbitrary behavior tree on a solution with a name.
To do this, the CreateBehaviorTreeRequest accepts the behavior tree itself and a unique but readable ID/name.
The name field of the behavior tree will be ignored.
This name will be shown in Flowstate when loading the process from the Process menu at the top.
In contrast to CreateBehaviorTree, the similar UploadBehaviorTree RPC allows overwriting a process that already exists.
The UpdateBehaviorTreeRequest must contain a behavior tree with its name field set.
By default, the solution must already contain a process with the name provided in the updated behavior tree (i.e. it will not be created).
This behavior can be overridden by setting the allow_missing field to true in the update request.
When allow_missing is set to true, then UpdateBehaviorTree acts like create or update, sometimes called upsert.
When a process is no longer needed it can be deleted from the solution.
The DeleteBehaviorTree RPC receives the unique name of the process to delete.
Once deleted, the process will no longer be discoverage using the reading RPCs described above.