连接任何东西

HTTP 进，HTTP 出，麻烦的部分已处理

每个自动化工具都宣传自己的集成数量。这个数字总是很大，而且总是问错了问题，因为你真正需要的系统往往是 2014 年某个已经离职的人内部开发的。真正重要的是工具对底层协议的掌握程度。

现成的连接

大多数企业赖以运转的应用都有准备好的步骤：商店和市场、会计和开票、电子表格和数据库、日历和邮件、存储和消息、CRM 和客服工单、支付服务商和物流承运商。你只需授权一次账户，字段就会以应用本身的语言命名，而不是它的 JSON 语言。

当某个应用带有波兰市场的特殊性——比如开票系统必须兼容 KSeF，或某承运商的面单是国家标准——准备好的步骤也知道这一点，因为家族就在那个市场销售，不得不学会。

其余一切都是 HTTP 步骤，而这里的 HTTP 步骤不是安慰奖。它与现成连接构建在同样的机制之上，对那些自己写起来很繁琐的部分有同样的处理。

繁琐的部分

API 密钥、bearer 令牌、基本认证、带刷新的 OAuth 2、HMAC 请求签名、双向 TLS。凭据只存储一次，按名称引用，永远不会打印到日志或运行记录中。

游标、页码、偏移量、Link 头，以及通过返回空数组来表示结束的 API。只需说明是哪种形式，步骤就会遍历整个集合。

每个连接一个上限，在所有使用它的工作流中都会被遵守。当服务商返回 429 并附带 Retry-After 时，该步骤会等待相应时长，而不是反复冲击。

瞬时故障会以递增的间隔重试，并设有上限。步骤是其输入的纯函数，因此重试只重新运行该步骤，而不是重新运行整个运行。

JSON、表单编码、XML、纯文本、multipart 上传。响应会被解析成可以按名称引用的字段，包括嵌套四层之下的那些。

每个步骤都有时限，这样某个缓慢的依赖就不会占住一个工作节点，让排在后面的所有任务干等。达到时限后怎么处理由你决定，逐个步骤设置。

每个工作流都可以有一个触发它的 URL。该 URL 会验证签名——支持常见服务商使用的各种 HMAC 形式，在发送方只能做到共享密钥的地方也接受共享密钥。对要求签名的工作流发出的未签名请求会被拒绝并记录在案，而不是悄悄处理。

去重基于载荷自身的标识符，所以发送方因为没及时看到你的 200 而重试时，只会得到一次运行而不是三次。格式错误的载荷会被保留，并附上被拒绝的原因，因为自动化中出现神秘缺口的常见原因，就是发送方改了主意、换掉了一个字段。

它们确实存在。凌晨四点，一个文件出现在 SFTP 服务器上，或者作为附件到达，或者被放进共享文件夹。工作流可以监视它、读取它，并把每一行当作一条记录——包括那个带字节顺序标记、用分号分隔、表头是波兰语的文件，因为导出的东西实际长这样。

反方向也行得通：工作流可以组装一个文件，放到对方系统期望找到它的位置——对于 2006 年的软件来说，这往往就是它唯一的接口。

每夜供应商数据源SFTP → HTTP

调用过模型的步骤：0本次运行的成本：零

加密存储、按名称引用、限定在所属工作空间内，并且绝不会渲染进运行日志、错误消息或支持对话中。运行记录会显示某步骤以 supplier-sftp 身份完成了认证；但不会显示 supplier-sftp 是什么。

一家为三十个客户运行同一工作流的代理公司，可以为每个客户配置各自的凭据集，工作流引用的是凭据集而不是密钥本身。轮换密钥只需在一处修改——这正是代理公司选择这里的主要原因。

值得了解的限制：一个完全没有接口的系统——没有 API、没有 webhook、没有文件投放，只有一个人在浏览器里点击——无法被本平台或任何诚实的工具自动化。这里没有假装成用户的无头浏览器，因为对方一挪动按钮它就会坏掉，而且是悄悄地坏掉。