Add path templating support

[cdavernas]

What would you like to be added:

The ability to render path templates upon functions execution

Why is this needed:

So far we have no clean, out-of-box way to make calls to functions which's host name has been defined dynamically.

It is required in cases where you need to make a call to a specific instance of a service, which's url has been returned by a previous call.

Hypothetic example:

name: Load Balancer
functions:
- name: get-round-robin-url-for
  type: rest
  operation: https://roundrobin.routing.test.com/openapi.yaml#fastest-url-for
- name: send-email
  operation: https://{emailServiceIP}/openapi.json#send    #resolved dynamiccaly using expression evaluator upon invocation
states:
- name: load-balancer
  type: operation
  actions:
  - name: GetRoundRobinUrlFor
    functionRef:
     refName: get-round-robin-url-for
     arguments:
       serviceName: email
    actionDataFilter:
      toStateData: ${ .emailServiceIP }
  - name: SendEmail
    functionRef:
      refName: send-email
      arguments:
        to: ${ .email.to }
        subject: ${ .email.subject }
        body: ${ .email.body }
 ...

[ricardozanini]

So in runtime, you will invoke a service that you don't know where it's in design time? And this data will come from the execution of another state?

So the data schema to call the send-email service is a supposition from the user designing the workflow?

I can see a few use cases of this, but I'm on the fence. I'll try to think more about this proposal and how I would solve it from the infra perspective.

[fjtirado]

I think it will be better to introduce a URI reference construct in the spec and there, rather than using all type of expressions, be able to specify the values of URIS from a properties reserved word which are not mutable at runtime (similar to already existing $SECRET) For example "uris" : { "uriAlias1" : "http:://localhost/blabla", "uriAlias2": {"scheme": "https", host" : "$PROPS.<propName>", "path": "openapi.json" }} and

functions: [
  { "name" : "send-email",
    "operation" : "uriAlias2#sendMail"},
  { "name" : "send-file",
    "operation" : "uriAlias2#sendFile"}
]

[fjtirado]

you can argue, accepting the $PROPS reserved word to narrow down possible values to parsing time, that this should be supported

 { "name" : "send-email",
    "operation" : "https://{$PROPS.<propName>}/openapi.json#sendMail"}

Ths issue in my opinion is that the only part of the URI that should be actually properties are the host and the port, and I think it is more clear to specify that in a separate URI construct. The use case for host and port in the environment will make sense when the same spec is available in different servers but not all of them are accessible from everywhere and rather than changing the flow in the different locations where they are deployed, you prefer to change the env.

[fjtirado]

I would say (as @ricardozanini before) that a variable spec location case does not really fit in the workflow spec target use case set. I think it is a fair assumption that the spec details are known by the writer of the flow, therefore invoking an unknown spec does not really fit well In the email example, you are implicitly assuming than the spec to be returned by the dynamically returned host accepts to, subject and body parameters.

[antmendoza]

It makes more sense to me the @fjtirado 's approach. I think that having environment variables will make "the developer's life easier"

Could not be this also archived by storing the functions spec as a separate file?

"functions": [
  {
    "name": "sendOrderConfirmation",
    "operation": "file://confirmationapi.json#sendOrderConfirmation"
  }
]

So confirmationapi.json could be different in any environment.

Anyway, I suppose that we will have to support PROPS / ENVS as well, in the same way the spec does with SECRET

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.