-
is it possible to add/change search attributes on a workflow, after it has already started ?
-
We ( java-sdk ) need to add search attributes of the type AAA=xxx on our workflows.
I don’t see any examples. ( Im not able to understand what HelloSearchAttributes.java is doing )
We would like to get examples of both writing and searching -
Once we locate the workflow ( workflowId/runId ), how do we retrieve the value of AAA ?
-
Yes. Use Workflow.UpsertSearchAttributes API.
-
It starts a workflow passing a few custom search attribute values. Note that each attribute has to be registered with the service before SDK can use it.
-
They are available in the response to the DescribeWorkflowExecution API. But if you are doing this, I’m not sure why you are using search attributes instead of a workflow query. The idea for search attributes is that they can be used to list workflows by their values.
( Thank you very much Maxim )
Oh. So each search attribute tag ( AAA ) has to be added through tctl ?
So what can be passed to workflow programmatically ? ( value xxx for the tag AAA ? )
–sony
Oh. So each search attribute tag ( AAA ) has to be added through tctl ?
Yes, you are correct. Custom search attributes correspond to fields in the Elasticsearch schema. So when you register one through tctl the ES schema is updated.
So what can be passed to workflow programmatically ? ( value xxx for the tag AAA ? )
Yes, you pass key-value pair with “AAA” being the key.
We do not have an Elastic Search plugin ( Although we have plans to install that in the future )
Are you saying we cannot attach arbitrary TAG=VALUE s to workflows without installing elastic search ?
Are you saying we cannot attach arbitrary TAG=VALUE s to workflows without installing elastic search ?
What is your use case? I think you are trying to achieve something that custom search attributes were not designed for.
We have a workflow that processes requests on specific business objects.
Multiple workflows types make multiple changes .
Our design is to attach business object name to workflow as OUR_BUSINESS_OBJECT=objectname as a search attribute… we will also add another search attribute VERSION=versionnumber
( my questions were related to this part )Then from another part of our software, we should be able to query for specific business objects…Our current design is to Temporal search for the specific business object name …once we locate the workflow(workflowid/runid), we will get some data using our queryMethod() on the workflow
Have you considered using the “business name” as workflow ID to avoid that lookup step?
Are you saying we cannot attach arbitrary TAG=VALUE s to workflows without installing elastic search ?
Yes, custom search attributes require Elasticsearch integration.
Sorry. I got confused on this again:
Yes, custom search attributes require Elasticsearch integration.
I ran the default docker-compose.yml ( Cassandra with no ES ). Using this I was successfully able to run io.temporal.samples.hello.HelloSearchAttributes, which uses workflowoptions.setSearchAttributes() and searchAttributes.getIndexedFieldsOrThrow(“CustomStringField”)
So when exactly do you need ElasticSearch ?
So when exactly do you need ElasticSearch ?
To perform a search using the “CustomStringField”. You can add attributes to a workflow without ES running, but these attributes cannot be used to filter workflows while listing them.
Are you saying :
String query = …
ListWorkflowExecutionsRequest req = ListWorkflowExecutionsRequest.newbuilder().setQuery(query).build() ;
WorkflowService.listWorkflowExecutions(req)
…will fail if the Temporal instance is not backed by an Elastic Search ?
…although workflowoptions.setSearchAttributes() will succeed
?
We are a fairly large organization with a different team running the Temporal instances.
( Our team is not given access to tctl )
is there a way for us to check if our temporal instance is backed up by Elastic Search ? ( We have access to teh web ui )
I figured this out
GetSearchAttributesRequest gsa = GetSearchAttributesRequest.newBuilder().build();
GetSearchAttributesResponse gsares = service.blockingStub().getSearchAttributes(gsa);
// System.out.println( gsares.toString());
On the Web-ui side you could click on the “Advanced” button on the top-right side and try to run a query, for example: “ExecutionStatus=2” (to query completed workflows). If it returns results you should have ES capabilities turned on.
Ah. Thanks. very useful.
By teh way… what is the Visibility Archival under Settings
VISIBILITY ARCHIVAL
Disabled
believe the docs might be a little bit outdated as in visibility archival is available (still considered experimental) and works if history archival is enabled.
Is it possible to add custom search attributes to Temporal server via its YAML config file, or any other automated way when using Docker Compose?
The sample file I have (development-sql.yaml) has a few properties configured:
limit.maxIDLength:
- value: 255
constraints: {}
system.forceSearchAttributesCacheRefreshOnRead:
- value: false # Dev setup only. Please don't turn this on in production.
constraints: {}
Not via server config (yaml) but you can add them using tctl (with an entry point script for example, see how its done here)
@tihomir, thanks, I was trying to run the command from inside the Docker container running Temporal, and getting this error, the CLI tool is not connecting to the server:
bash-5.1$ tctl --auto_confirm admin cluster add-search-attributes --name Username --type Text
Error: Unable to get existing search attributes.
Error Details: rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing dial tcp 127.0.0.1:7233: connect: connection refused"
('export TEMPORAL_CLI_SHOW_STACKS=1' to see stack traces)
bash-5.1$
In that container can you check value of:
echo $TEMPORAL_CLI_ADDRESS
If its not set, set it to same value as what you have in your static config for publicClient->hotPort.
or set it directly in your tctl command:
tctl --address <publicClient->hostPort_value> ......
1 Like