Server Access Service

Serverless enables operations to be spent on demand and billed on a case-by-case basis, while the self-deployed, lightly quantified features of functions require many “glue codes” when actual operations get down.

Rill Flow supports common process control statements and can serve as "glue codes" for low coding Serverlessness.

Flow Control

Process control nodes that support conditions, loops, jumps, etc. in Rill Flows. Use process control nodes to implement basic business control album and expression and reference流程控制

Server Gateway

Rill Flow organizes cloud services, including cloud functions, in the form of workflow to support process control nodes of conditionality, loop and jumps.Tasks are forwarded via HTTP request to a Serverless Gateway, implementing Serverless Business Integration.For further information, reference may be made to the [HTTP dispatcher](../user-guide/03-defination/02-task-and-dispatcher.md#http-protocol dispatcher).

You can also implement the Serverless special dispatcher by developing custom plugin details for创建插件

Consider text-generated videos, where text acquisition, text split, text-color, text-pairing, text-matching, calibration and calibration services are a separate function. Rill Flow can organize functions into line with project needs and reduce developers to write unnecessary "glue codes".Product demand iterations can be quickly developed by modifying the DAG graphs based on different needs over time.

OpenFaas

OpenFaas gateway's namespace, service and port can be confirmed by deploying Yaml to OpenFaas. When defining a task, the task can be bound to a different Serverless function via the ResourceName field.

• The OpenFaas function synchronizes calls to ResourceName like：

  http://{service}.{namespace}.svc.cluster.local:{service-port}/function/{function-name}/{function-uri}

  

• The OpenFaas function asynchronously calls ResourceName like：

  http://{service}.{namespace}.svc.cluster.local:{service-port}/async-function/{function-name}/{function-uri}

  )

Business integration and asynchronous calls

Business Integration

For the integration of normal business, simply create tasks by using the business call interface as a resourceName of task. If the business is not called in the way of http:/fit, the corresponding resourceProtocolProtocol can be supported by creating a custom distributor plugin, reference to 开发插件

When the business function takes longer to execute it, you can set the task's pattern field to task_async to indicate that this is an asynchronous call. Rill Flow will return immediately after calling a function and will not wait for the function to be executed.

Asynchronous task callback address

For asynchronous calls, Rill Flow will add the X-Callback-Url field to the header that is the callback address after the current task's execution. The function needs to be executed by sending a request to that address to notify Rill Flow that the task's execution has been completed.Refer to 异步模式, specific callback address：

http://{rill-flow-server-host}/flow/trigger.json

This callback interface supports both GET and POST calls.

The url query request parameter for the interface follows：

	Required	Type	Description
execution_id	true	string	Execute id
task_name	true	string	Task name
Status	false	string	Task running, value：successes, failed, default to success
Context	false	string	JSON format task execution result

If called via POST, the JSON format task return parameter can be passed through body parameters, used to process the return parameter through outputMappings, such as in the context etc. Therefore, for POST calls, the Content-Type field in the header must be valued as application/json.

Rill Flow will merge both the query and the POST body arguments of the context if they are passed simultaneously, and the same key key will override body arguments in the same query argument.

Use callback as task parameter

To use the above callback interface and the parameter for a task as the incoming parameter for a task node, add the corresponding map： to the inputMappings of the corresponding task node

inputMappings:
    - target: $input.data.rigger_url
      source: $tasks.tasks.task1.trgger_url

In the execution of this workflow, Rill Flow will pass the callback address called task1 to the task as an input["data"]\["trigger_url"] when the task is configured.

The default value for this parameter is：

http://{rill-flow-server-host}/flow/trigger.json?execution_id={current-execution-id}&task_name=task1

如果你需要在该任务接收到的 trigger_url 中额外添加某些参数，可以通过在 trigger_url 后面添加 ? 来将参数以 key1=value1&key2=value2 的方式添加到 trigger_url 中：

inputMappings:
    - target: $.input.data.trigger_url
      source: $.tasks.task1.trigger_url?context=%7B%22key%22%3A%20%22value%22%7D

Then, the final generated trigger_url will become：

http://{rill-flow-server-host}/flow/trigger.json?execution_id={current-execution-id}&task_name=task1&context=%7B%22key%22%3A%20%22value%22%7D