ricardozanini commented on code in PR #531:
URL:
https://github.com/apache/incubator-kie-kogito-docs/pull/531#discussion_r1489724293
##########
serverlessworkflow/modules/ROOT/pages/core/understanding-jq-expressions.adoc:
##########
@@ -199,6 +199,45 @@ You can find an example of event data filtering in the
link:{kogito_sw_examples_
The previous example of the event filter copies the content of CloudEvent data
`result` field into the workflow model `move` field.
--
+== Workflow secrets, constants and context
+
+As per specification, you can use
link:{spec_doc_url}#workflow-constants[Workflow Constants] and
link:{spec_doc_url}#workflow-secrets[Workflow Secrets] whenever an expression
is accepted.
+In {product_name} you can use `$SECRET` to access any configuration property,
not just sensitive ones.
+So, assuming you have added to your `application.properties` a line with the
`myname=john` property, the following function will append the string `my name
is john` to the `message` variable
+----
+{
+ "name": "secretMessage",
+ "type": "expression",
+ "operation": ".message |= \"my name is \"+$SECRET.my_name"
+}
+----
+
+Besides constants and secrets, you might access contextual information of the
running workflow by using the $WORKFLOW reserved word.
+{product_name} supports the following contextual keys:
+ * `id`: The id of the running workflow definition
+ * `name`: The name of the running workflow definition
+ * `instanceId`: The id of the running workflow instance
+ * `headers`: Optional map containing the headers, if any, of the invocation
that started the running workflow instance
+ * `prevActionResult`: In a `foreach` state, give access the result of the
previous loop iteration output.
+ * `identity`: Quarkus security identity
+
+ Therefore, the following function, for a serverless workflow definition whose
id is `expressionTest`, will append the string `worklow id is expressionTest`
to the `message` variable
+
+----
+{
+ "name": "contextMessage",
+ "type": "expression",
+ "operation": ".message |= \"workflow id is \"+$WORKFLOW.id"
+}
+----
+
+=== Customizing workflow context
+
+In addition to the predefined keys mentioned previously, you can add your own
keys to workflow context using Java Service Loader mechanism, by providing an
implementation of class
link:{kogito_runtimes_url}/kogito-serverless-workflow/kogito-serverless-workflow-utils/src/main/java/org/kie/kogito/serverless/workflow/utils/KogitoProcessContextResolverExtension.java[KogitoProcessContextResolverExtension]
+
+This feature was used to add quarkus security identity support, you can check
source code as reference
link:{kogito_runtimes_url}/quarkus/extensions/kogito-quarkus-serverless-workflow-extension/kogito-quarkus-serverless-workflow/src/main/java/org/kie/kogito/serverless/workflow/QuarkusKogitoProcessContextResolver.java[here].
+
Review Comment:
I don't think we should mention Quarkus here. It's highly related to what we
are trying to do. These concepts sections must be solely to working with
workflows at the spec level and how our runtime handles it. We can move these
paragraphs to a new section under Quarkus. This is a rich material that we must
keep, it's just a matter of rearrangement. @domhanak wdyt?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
