连接任何东西

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、没有文件投放，只有一个人在浏览器里点击——无法被本产品或任何其他诚实的工具自动化。这里没有假装成用户的无头浏览器，因为对方一挪动按钮它就会失效，而且是悄无声息地失效。