接 Google Maps：为 TMS 线路提供路线距离、时长与 ETA
在 Google Cloud Console 里建项目、启用 Routes API、新建 API 密钥，把唯一的 api_key 填进 Integration，用一次真实 Routes 调用测试，选路线规划模板再激活——TMS 就能拿到线路成本与 ETA 所需的距离、时长与线路。
Google Maps 连接器是 TMS 的路线数据源。它调用 Google Maps Routes API 一次算一条路线——距离、时长与线路本身——供 TMS 里的运单与招标单用作线路成本与 ETA 的依据。这就是它唯一的工作：不拉也不推订单，不同步客户或库存，也不追踪车辆。一个连接只放一个 Google Maps API 密钥。
前置条件#
- 能进 Google Cloud Console，并有在项目里建项目、启用 API、新建 API 密钥的权限。
- 会在该项目里启用 Routes API。没启用时，密钥再对也拿不到路线。
- 您清楚测试这个连接会产生用量：Routes API 没有免费探针端点，每次测试都是一次真实路线调用、消耗一次配额。不要无故反复点测试。
- 在本系统里有打开 Integration 并新建连接的权限。
拿凭证#
- 登录 Google Cloud Console，为这个连接新建一个项目。
- 在该项目里启用 Routes API。
- 在同一个项目里新建 API 密钥并复制完整密钥。本连接的密钥以 AIza… 开头——完整复制，两端都不要截断。
- 按控制台的建议给密钥加限制：限定到 Routes API 和您的 IP。把您放行的 API 与 IP 准确记下来，后续失败常常只是与这条限制对不上。
填进 Integration#
- 打开 Integration → 连接器市场 → Google Maps → 新建连接。
- api_key——必填，谷歌地图 API 密钥：粘贴在 Google Cloud Console 启用 Routes API 后新建的完整 API 密钥。这是密码类型字段，作为秘密保存。本连接没有第二个字段：这里不用填账号名、项目字段或用户名。
- 测试前先保存连接，让测试用的正是您刚填的密钥。
测试连接#
点测试连接。填了密钥时，测试会做一次真实的最小 Routes 调用：把 computeRoutes 请求发到 https://routes.googleapis.com/directions/v2:computeRoutes，密钥放在 X-Goog-Api-Key 请求头里，从起点 34.0633,-117.6509 到终点 34.0733,-117.6409、driving 模式。测通表示密钥有效、Routes API 可达，成功提示会用文字写明：API key 有效，Routes API 可达（探针消耗一次配额）。最后一句请按字面理解——这个探针是真实调用，每跑一次就消耗一次配额，所以只测一次；失败先修原因，修好再测。
配 Mapping / 选模板#
选路线规划模板——本连接只用这一个模板。没有订单或客户字段要配 Mapping。模板定的是 TMS 里请求的出行方式怎么发给 Google：driving 与 driving-traffic 发为 DRIVE，cycling 发为 BICYCLE，walking 发为 WALK。测试通过后，在 TMS 里算一条您熟悉的路线，把返回的距离与时长和您对该线路的预期对照，确认后再激活。若每条线路的数字都看着不对，先查方式——同两个点，开车、骑行、步行的结果差别很大。
激活#
激活后，TMS 的运单或招标单需要估算线路时就能向本连接要路线：连接返回距离、时长与线路，TMS 用它们作线路成本与 ETA 的依据。先在 运行监控 / 日志里盯头几次真实请求，拿几条您熟悉的线路对照返回的距离与时长，无误后再放手跑。
这个连接不做的事：它只提供路线规划。不拉订单进来，不把任何东西推回其他系统，不同步客户或库存，也不追踪移动中的车辆。激活后 TMS 界面没有新订单出现是正常的——订单来自您的订单渠道，本连接只在 TMS 提问时回答：多远、多久、走哪条线。
常见问题#
密钥刚建好测试就失败，提示 Routes API 不可达
最常见的原因是放密钥的那个项目里根本没启用 Routes API。密钥本身可以完全有效，但 Google 没有为该项目打开 Routes 服务，computeRoutes 调用无处可去。
打开 Google Cloud Console，选创建密钥的同一个项目，在那里启用 Routes API，等片刻让变更生效，然后再测一次连接。
密钥限定了 API 与 IP 之后测试失败
您给密钥设的限制与本系统调用 Google 的方式对不上。若放行的 API 列表不含 Routes API，或放行的 IP 不是本系统发起调用的地址，即使粘贴的密钥文字完全正确，Google 也会拒绝调用。
在 Google Cloud Console 里打开该密钥，检查限制的两个部分：放行 API 列表里必须有 Routes API，放行 IP 必须是本系统调用 Google 的地址。改好限制、保存，再测一次——不要为了绕开限制对不上而再建第二个密钥。
连接还没激活，用量却在涨
每次测试都是真实调用。Routes API 没有免费探针端点，测试只能靠真算一条路线来证明密钥可用——而该请求会消耗一次配额，正如成功提示所写：探针消耗一次配额。激活前反复测试就是真实用量。
只测一次。失败就读失败信息，在密钥、项目或限制里修那一个原因，修好后再测。测通后就进入模板与激活步骤，不要为了再确认一遍而重复测试。
密钥看着完整，Google 还是拒绝
粘贴进来的值不是 Google 为该项目签发的那个密钥：复制时丢了字符、多带了空格，或该密钥属于另一个项目——那里的 Routes API 与限制设置不同。字段什么文字都能填，只有测试里的真实调用能分辨。
回到 Google Cloud Console，打开启用了 Routes API 的项目里的那个密钥，一次性重新复制完整值，粘贴进 api_key、不要手敲任何一段，保存后测一次。
熟悉线路的距离与时长看着不对
这条路线是按与您预期不同的出行方式算的。模板把 driving 与 driving-traffic 发为 DRIVE、cycling 发为 BICYCLE、walking 发为 WALK；同两个点在每种方式下的距离、时长与线路差别很大——把步行结果当开车结果看就会觉得不对，尽管调用本身是成功的。
查 TMS 该线路请求用的方式，与您心里想的方式对照，用预期方式重算。只拿同方式的结果作判断——不要拿 BICYCLE 的时长和您的开车经验比。
已激活，但哪里都没有订单或追踪出现
什么都没坏。这个连接本来就不承载订单或追踪：它唯一的能力是路线规划，激活不会新增订单来源，也不会有车辆位置——它只是让 TMS 在运单或招标单需要估算线路时能问到距离、时长与线路。
订单请走您的订单渠道，追踪请用承运商工具。本连接只用在需要线路成本或 ETA 的地方，验它的工作请看 TMS 运单或招标单里的路线结果。