Add CONTEXT keyword to the workflow definition

[ricardozanini]

Hey folks!

Similar to what we already have (CONSTANT and SECRETS), I'd like to propose the CONTEXT keyword to give the user access to the internal context information of the running workflow instance such as an ID, the workflow name, version, etc.

It should be pretty straightforward, something like:

{
  "id": "processSalesOrders",
  "name": "Process Sales Orders",
  "version": "1.0",
  "specVersion": "0.8",
  "start": "MyStartingState",
  "states":[
  {
     "name":"MyStartingState",
     "type":"operation",
     "actions": [{
       "functionRef": "myFunction"
       "args": {
          "order": "${ .orderId }",
          "callerId": "${ $CONTEXT.workflowInstanceId }"
       }
     }]
  }
  ]   
}

As an example use case, sometimes third-party requires specific caller identification for audit/traceability matters. Since each party could have a particular way to identify a caller, users could model how they pleased to fulfill a specific scenario.

We won't need to define anything in the schema, but a section highlighting that the CONTEXT keyword could be used within an expression field, as in the above example.

wdyt?

[tsurdilo]

$CONTEXT.workflowInstanceId

i get the need but this is very runtime specific to my liking.
we cannot specify all the different things that would fit in the CONTEXT for every runtime, and if we do it just will be
maintenance to keep adding stuff that runtimes need.

think its just better to let this type of info be part of the runtime that adopts the spec

from spec side, we cannot even assume that workflowInstanceId is a json string. it could be an image for some runtimes :)

[tsurdilo]

we could define a WORKFLOW bucket where users could get the top-level workflow definition properties like workflow id,
but i think what's asked here is runtime id
imo we cannot do as spec.

you could maybe just put that stuff in the default jq ARGS bucket?

[ricardozanini]

I agree that we should not add variables for the CONTEXT. This should be implementation specifics. But the spec should be aware of this reserved keyword within expressions.

I like the idea of the WORKFLOW bucked to give access to the meta info of the workflow, but implementations can extend to add their specifics and instruct the users on the way to do it so.

[tsurdilo]

ah ok so we just need to name a bucket into which runtimes can stick whatever they want into?
ok, in that case feel free to call it whatever you feel like it and we can add :)

[fjtirado]

yes thats the idea. The same we have metadata to freely specify implementor information at build time, It would be nice to have some reserved word (CONTEXT or WORKFLOW) to allow access specific implementor information at runtime. The information there will vary for each implementor, but some examples are: the id of the flow instance, the start date of the instance, the id of the flow. On summary, a generic container for random information a specific implementor might want to add available at runtime.

[ricardozanini]

ah ok so we just need to name a bucket into which runtimes can stick whatever they want into? ok, in that case, feel free to call it whatever you feel like it and we can add :)

exactly, I'm gonna open a PR. I think we can use WORKFLOW, I feel like it's more user-friendly.

[ricardozanini]

As settled, I will open a PR to add the reserved word WORKFLOW on expressions, so implementations can use it to give meta information of the currently running instance.

@cdavernas @mswiderski thoughts?

[mswiderski]

no special opinion on this so fine to go with WORKFLOW