managing-stacks

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Managing Stacks

管理栈

A stack is a pointer to your own compute environment where Celigo runs extension code -- the script hooks and connector wrappers that would otherwise run on Celigo's hosted JavaScript runtime. A stack holds the address and credentials of that environment, not the logic. At runtime, when a hook or wrapper is configured to use a stack, Celigo dispatches that function's execution to the stack instead of running it on its own managed runtime.

Concerns when managing stacks:

Necessity -- most accounts never need a stack; the hosted runtime handles the vast majority of extension logic. A stack is for a real trigger (see the decision matrix).
Type and config --
```
server
```
(a self-hosted HTTP endpoint) or
```
lambda
```
(an AWS Lambda function), each with its own config block.
Credentials -- a server carries an auto-generated
```
systemToken
```
; a lambda carries AWS keys. Both are masked in responses and demand credential discipline.
References -- a stack does nothing on its own. It matters only once a hook (via
```
_stackId
```
on an export/import) or a wrapper connection (via
```
_stackId
```
) points at it.

Stacks are a resource type in their own right. They are referenced by script hooks and by wrapper connections.

栈是指向您自有计算环境的指针，Celigo会在此环境中运行扩展代码——原本会在Celigo托管JavaScript运行时中运行的脚本钩子和连接器包装器。栈存储该环境的地址和凭据，而非逻辑代码。在运行时，当钩子或包装器被配置为使用某个栈时，Celigo会将该函数的执行调度到该栈，而非在自身托管的运行时中运行。

管理栈时需要关注的要点：

必要性——大多数账户永远不需要栈；托管运行时可处理绝大多数扩展逻辑。仅在符合特定触发条件时才需要栈（参见决策矩阵）。
类型与配置——分为
```
server
```
（自托管HTTP端点）或
```
lambda
```
（AWS Lambda函数），每种类型都有各自的配置块。
凭据——server类型会携带自动生成的
```
systemToken
```
；lambda类型会携带AWS密钥。两者在响应中都会被掩码处理，且需要严格的凭据管理规范。
引用关系——栈本身不会主动执行任何操作。只有当钩子（通过导出/导入配置中的
```
_stackId
```
）或包装器连接（通过
```
_stackId
```
）指向它时，它才会发挥作用。

栈本身是一种资源类型，会被脚本钩子和包装器连接引用。

The Stack Is the Runtime, Not the Code

栈是运行时，而非代码

The distinction the whole domain hangs on:

The code is the logic: a hook (a JavaScript function on an export/import --
```
preMap
```
,
```
postSubmit
```
, etc.) or a connector wrapper (the server-side JavaScript that implements a custom adaptor). Hook logic is a script resource; wrapper logic belongs to the wrapper connection.
The stack is where that code runs. A hook or wrapper points at a stack via
```
_stackId
```
. When set, Celigo dispatches that function's execution to the stack instead of its managed runtime.

So "edit what the hook does" is script work; "change where the hook runs" (managed runtime <-> a stack, or one stack <-> another) is what touches

_stackId

. A stack is bring-your-own-compute: it supplies the environment, not the behavior.

这是整个领域的核心区别：

代码是逻辑内容：钩子（导出/导入中的JavaScript函数——
```
preMap
```
、
```
postSubmit
```
等）或连接器包装器（实现自定义适配器的服务器端JavaScript）。钩子逻辑属于脚本资源；包装器逻辑属于包装器连接。
栈是代码运行的位置。钩子或包装器通过
```
_stackId
```
指向栈。设置后，Celigo会将该函数的执行调度到该栈，而非自身托管的运行时。

因此，“修改钩子的功能”属于脚本开发工作；“更改钩子的运行位置”（托管运行时↔栈，或不同栈之间切换）则涉及修改

_stackId

。栈属于自带计算资源（bring-your-own-compute）：它提供运行环境，而非业务行为。

Stack vs On-Premise Agent

栈与On-premise Agent的区别

Both put "your own infrastructure" in the loop, but for opposite reasons -- keep the boundary straight:

A stack is about compute -- running your extension code (hooks/wrappers) on your server or Lambda.
An on-premise agent is about connectivity -- a tunnel that lets Celigo reach private apps or networks behind your firewall (a database or app with no public endpoint).

"Run our code" -> stack. "Reach our private system" -> on-premise agent. A single flow can use both: an agent to reach a private database, and a stack to run a custom hook.

两者都会将“您自有基础设施”纳入流程，但目的完全相反——请明确区分边界：

栈关乎计算——在您的服务器或Lambda上运行您的扩展代码（钩子/包装器）。
On-premise Agent关乎连接性——建立隧道，让Celigo能够访问防火墙后的私有应用或网络（无公共端点的数据库或应用）。

“运行我们的代码”→使用栈。“访问我们的私有系统”→使用On-premise Agent。单个流程可以同时使用两者：用Agent访问私有数据库，用栈运行自定义钩子。

Quick Reference

快速参考

Do You Need a Stack?

是否需要栈？

Default: no. Celigo's hosted JavaScript runtime runs hooks out of the box. Reach for a stack only on a real trigger:

Situation	Need a stack?
A hook to transform, filter, or enrich records	No -- the hosted runtime handles it
Code that needs libraries, native dependencies, more memory, or longer execution than the sandbox allows	Yes
Compliance/security requirement that extension code and the data it touches never leave your environment	Yes
A custom connector implemented as a wrapper connection	Yes -- a wrapper runs on a stack you operate
Reaching a private database or app behind a firewall	No -- that's an on-premise agent, not a stack

默认：不需要。Celigo的托管JavaScript运行时可直接运行钩子。仅在符合以下真实触发条件时才考虑使用栈：

场景	是否需要栈？
用于转换、过滤或丰富记录的钩子	不需要——托管运行时可处理
需要使用库、原生依赖、更多内存，或执行时长超过沙箱限制的代码	需要
合规/安全要求扩展代码及其处理的数据永远不能离开您的环境	需要
以包装器连接形式实现的自定义连接器	需要——包装器在您运营的栈上运行
访问防火墙后的私有数据库或应用	不需要——这是On-premise Agent的用途，而非栈

server vs lambda

Neither is "better" -- it's a fit question based on where the team already runs infrastructure.

	`server`	`lambda`
What it is	A self-hosted, always-on HTTP endpoint you run and patch	A serverless AWS Lambda function Celigo invokes
Scaling / uptime	You own it	AWS manages it
Access control	Optional `ipRanges` allow-list	AWS IAM
Trade-offs	Full control, no cloud-provider coupling	Pay-per-invocation, but AWS coupling and cold starts
Leans toward	Teams with an existing managed server or non-AWS environment	Teams already deep in AWS

两者没有优劣之分——需根据团队现有基础设施的运行环境来选择适配类型。

	`server`	`lambda`
定义	您运行和维护的自托管、持续在线的HTTP端点	Celigo调用的无服务器AWS Lambda函数
扩容/可用性	由您负责管理	由AWS管理
访问控制	可选 `ipRanges` 白名单	AWS IAM
权衡点	完全控制，无云厂商耦合	按调用次数付费，但存在AWS耦合和冷启动问题
适用场景	已有托管服务器或非AWS环境的团队	深度使用AWS的团队

Minimum Required Fields

必填字段

Every stack needs

name

and

type

framework

twoDotZero

(the only supported version). The rest depends on

type

Type	Config block	Required fields
`server`	`server`	`hostURI` (the reachable HTTP(S) endpoint Celigo calls). Optional `ipRanges` allow-list. `systemToken` is auto-generated -- you do not set it.
`lambda`	`lambda`	`accessKeyId` , `secretAccessKey` , `awsRegion` , `functionName` . Optional `language` ( `Node.js` default, or `C#` / `Java` / `Other` ).

awsRegion

is an enum (e.g.

us-east-1

us-west-2

eu-west-1

eu-central-1

ap-southeast-1

, ...).

```
functionName
```
accepts a Lambda function name or full ARN.
Both secrets (
```
systemToken
```
,
```
secretAccessKey
```
) are masked as
```
******
```
in responses.

每个栈都需要

name

和

type

。

framework

需设置为

twoDotZero

（唯一支持的版本）。其余字段取决于

type

：

类型	配置块	必填字段
`server`	`server`	`hostURI` （Celigo可调用的可访问HTTP(S)端点）。可选 `ipRanges` 白名单。 `systemToken` 为自动生成——无需手动设置。
`lambda`	`lambda`	`accessKeyId` 、 `secretAccessKey` 、 `awsRegion` 、 `functionName` 。可选 `language` （默认 `Node.js` ，或 `C#` / `Java` / `Other` ）。

awsRegion

为枚举值（例如

us-east-1

、

us-west-2

、

eu-west-1

、

eu-central-1

、

ap-southeast-1

等）。

```
functionName
```
接受Lambda函数名称或完整ARN。
两个密钥（
```
systemToken
```
、
```
secretAccessKey
```
）在响应中都会被掩码为
```
******
```
。

Referencing a Stack (

_stackId

)

引用栈（

_stackId

）

A stack is inert until something points at it:

Hooks -- an export/import hook definition carries an optional
```
_stackId
```
alongside its
```
_scriptId
```
and
```
function
```
. Set it to dispatch that hook to the stack.
Wrapper connections -- a
```
wrapper
```
-type connection sets
```
_stackId
```
to the stack whose server-side JavaScript implements the connection. Required by the connection form for standalone wrappers.

To confirm what actually runs on a stack, list its dependents (

GET /v1/stacks/{id}/dependencies

) -- the hooks and wrapper connections pointing at it.

栈在被引用前处于惰性状态：

钩子——导出/导入的钩子定义中，会在
```
_scriptId
```
和
```
function
```
之外携带可选的
```
_stackId
```
。设置该值即可将钩子调度到栈上运行。
包装器连接——
```
wrapper
```
类型的连接会将
```
_stackId
```
设置为实现该连接的服务器端JavaScript所在的栈。独立包装器的连接表单要求必须设置该值。

要确认哪些内容实际在栈上运行，可列出其依赖项（

GET /v1/stacks/{id}/dependencies

）——即指向该栈的钩子和包装器连接。

Related Skills

How to Manage a Stack

如何管理栈

1. Confirm you actually need one

1. 确认确实需要栈

Use the Do You Need a Stack? matrix. When a user asks "should I set up a stack for this hook," the honest first answer is usually "probably not -- the managed runtime handles it," then escalate only if heavier/specialized code, a compliance requirement, or a custom connector wrapper is genuinely in play. If the real need is reaching a private system, that's an on-premise agent, not a stack.

参考是否需要栈？矩阵。当用户询问“我应该为这个钩子设置栈吗”时，最诚实的初始回答通常是“可能不需要——托管运行时可以处理”，仅当确实需要更复杂/专业的代码、合规要求或自定义连接器包装器时才考虑使用栈。如果实际需求是访问私有系统，那应该使用On-premise Agent，而非栈。

2. Choose the type

2. 选择类型

Use the server vs lambda matrix. Pick by where the team already runs infrastructure and how they want to operate it.

参考server vs lambda矩阵。根据团队现有基础设施的运行环境和运维偏好进行选择。

3. Check for existing stacks

3. 检查现有栈

Before creating a new one, look for a stack you can reuse:

bash

celigo stacks list
celigo account search "stack"
celigo account search "<keyword related to the extension>"

创建新栈前，先查看是否有可复用的现有栈：

bash

celigo stacks list
celigo account search "stack"
celigo account search "<与扩展相关的关键词>"

4. Create the stack

4. 创建栈

Data blocks differ by

type

. Create the metadata; the runtime code is deployed and owned separately.

bash

undefined

不同

type

对应的数据块不同。创建元数据即可；运行时代码需单独部署和维护。

bash

undefined

server stack -- systemToken is auto-generated, do not include it

server栈——systemToken自动生成，请勿包含在请求中

echo '{"name":"Order Enrichment Server","type":"server","framework":"twoDotZero","server":{"hostURI":"https://ext.example.com"}}' | celigo stacks create

server stack with an IP allow-list

带IP白名单的server栈

echo '{"name":"Order Enrichment Server","type":"server","framework":"twoDotZero","server":{"hostURI":"https://ext.example.com","ipRanges":["203.0.113.0/24"]}}' | celigo stacks create

lambda stack -- enter the AWS secret via a local, untracked file; never paste real secrets into chat

lambda栈——通过本地未跟踪文件输入AWS密钥；切勿在聊天中粘贴真实密钥

celigo stacks create < lambda-stack.json


Example `lambda-stack.json` (use a placeholder here and supply the real key only in a local file or the UI):

```json
{
  "name": "Order Enrichment Lambda",
  "type": "lambda",
  "framework": "twoDotZero",
  "lambda": {
    "accessKeyId": "<aws-access-key-id>",
    "secretAccessKey": "<aws-secret-access-key>",
    "awsRegion": "us-east-1",
    "functionName": "celigo-order-enrichment",
    "language": "Node.js"
  }
}

celigo stacks create < lambda-stack.json


`lambda-stack.json`示例（此处使用占位符，真实密钥仅在本地文件或UI中提供）：

```json
{
  "name": "Order Enrichment Lambda",
  "type": "lambda",
  "framework": "twoDotZero",
  "lambda": {
    "accessKeyId": "<aws-access-key-id>",
    "secretAccessKey": "<aws-secret-access-key>",
    "awsRegion": "us-east-1",
    "functionName": "celigo-order-enrichment",
    "language": "Node.js"
  }
}

5. Wire up authentication

5. 配置认证

server -- the
```
systemToken
```
is generated on creation. Retrieve the unmasked value from the UI (the stack's "Show token" action) or via
```
GET /v1/stacks/{id}/systemToken
```
, then set it as the
```
INTEGRATOR_EXTENSION_SYSTEM_TOKEN
```
environment variable on every server that runs the extension code. To rotate it, use
```
DELETE /v1/stacks/{id}/systemToken
```
(the old token is invalidated immediately) and re-fetch the new one.
lambda -- the AWS IAM user behind
```
accessKeyId
```
/
```
secretAccessKey
```
must have the
```
lambda:InvokeFunction
```
permission for the target function, and
```
awsRegion
```
must match where the function is deployed.

server——
```
systemToken
```
在创建时生成。可从UI（栈的“显示令牌”操作）或通过
```
GET /v1/stacks/{id}/systemToken
```
获取未掩码的值，然后在所有运行扩展代码的服务器上设置为
```
INTEGRATOR_EXTENSION_SYSTEM_TOKEN
```
环境变量。如需轮换令牌，使用
```
DELETE /v1/stacks/{id}/systemToken
```
（旧令牌会立即失效），然后重新获取新令牌。
lambda——
```
accessKeyId
```
/
```
secretAccessKey
```
对应的AWS IAM用户必须拥有目标函数的
```
lambda:InvokeFunction
```
权限，且
```
awsRegion
```
必须与函数部署的区域匹配。

6. Point a hook or wrapper at the stack

6. 将钩子或包装器指向栈

The stack only runs code once referenced:

Hook -- add
```
_stackId
```
to the hook definition on the export/import (alongside
```
_scriptId
```
and
```
function
```
). See writing-scripts > How to Write a Script for hook wiring.
Wrapper connection -- set
```
_stackId
```
on the
```
wrapper
```
connection. See configuring-connections > Connection Types. A wrapper stack must expose a
```
ping
```
function so Celigo can health-check the connection.

栈仅在被引用后才会运行代码：

钩子——在导出/导入的钩子定义中添加
```
_stackId
```
（与
```
_scriptId
```
和
```
function
```
一起）。钩子配置可参考writing-scripts > How to Write a Script。
包装器连接——在
```
wrapper
```
连接上设置
```
_stackId
```
。可参考configuring-connections > Connection Types。包装器所在的栈必须暴露
```
ping
```
函数，以便Celigo进行连接健康检查。

7. Verify

7. 验证

Confirm the expected hooks and wrapper connections reference the stack before relying on it:

bash

celigo stacks get <id>
celigo account dependencies stack <id>

在依赖栈之前，确认预期的钩子和包装器连接已正确引用该栈：

bash

celigo stacks get <id>
celigo account dependencies stack <id>

CLI Commands

CLI命令

bash

undefined

bash

undefined

CRUD

CRUD操作

celigo stacks list celigo stacks get <id> celigo stacks create < stack.json celigo stacks update <id> < stack.json celigo stacks delete <id> [-y]

Discover existing stacks across the account

跨账户查找现有栈

celigo account search "<keyword>"


UI/API alternatives worth knowing (no dedicated CLI subcommand -- use the UI or the API directly):

- Retrieve the server system token: `GET /v1/stacks/{id}/systemToken` (or "Show token" in the UI).
- Rotate the server system token: `DELETE /v1/stacks/{id}/systemToken`.
- List dependents: `GET /v1/stacks/{id}/dependencies`.

<!-- TIER:3 -->

celigo account search "<关键词>"


值得了解的UI/API替代方案（无专用CLI子命令——直接使用UI或API）：

- 获取server系统令牌：`GET /v1/stacks/{id}/systemToken`（或UI中的“显示令牌”）。
- 轮换server系统令牌：`DELETE /v1/stacks/{id}/systemToken`。
- 列出依赖项：`GET /v1/stacks/{id}/dependencies`。

<!-- TIER:3 -->

Pre-Submit Checklist

提交前检查清单

Confirmed a stack is genuinely needed (heavier/specialized code, compliance, or a custom connector wrapper) -- not a routine hook the hosted runtime could handle.
Correct
```
type
```
chosen (
```
server
```
vs
```
lambda
```
) based on where the team operates infrastructure.
```
framework
```
set to
```
twoDotZero
```
.
```
server
```
:
```
hostURI
```
is reachable over HTTPS; if
```
ipRanges
```
is set, Celigo's egress IPs are included.
```
server
```
:
```
systemToken
```
retrieved (not set) and configured as
```
INTEGRATOR_EXTENSION_SYSTEM_TOKEN
```
on the runtime.

lambda

awsRegion

functionName

, and AWS keys supplied; IAM user has

lambda:InvokeFunction

No secret pasted into chat or a tracked file; AWS
```
secretAccessKey
```
entered via the UI or a local, untracked file only.
The consuming hook (
```
_stackId
```
on the export/import hook) or wrapper connection (
```
_stackId
```
) actually points at this stack.
Dependents verified so you know exactly what runs on the stack.

确认确实需要栈（复杂/专业代码、合规要求或自定义连接器包装器）——而非托管运行时可处理的常规钩子。
根据团队基础设施运行环境选择了正确的
```
type
```
（
```
server
```
vs
```
lambda
```
）。
```
framework
```
已设置为
```
twoDotZero
```
。
```
server
```
：
```
hostURI
```
可通过HTTPS访问；如果设置了
```
ipRanges
```
，已包含Celigo的出口IP。
```
server
```
：已获取
```
systemToken
```
（而非手动设置），并在运行时配置为
```
INTEGRATOR_EXTENSION_SYSTEM_TOKEN
```
环境变量。
```
lambda
```
：已提供
```
awsRegion
```
、
```
functionName
```
和AWS密钥；IAM用户拥有
```
lambda:InvokeFunction
```
权限。
未在聊天或跟踪文件中粘贴密钥；AWS
```
secretAccessKey
```
仅通过UI或本地未跟踪文件输入。
消费端钩子（导出/导入钩子中的
```
_stackId
```
）或包装器连接（
```
_stackId
```
）已正确指向该栈。
已验证依赖项，明确了解哪些内容在栈上运行。

Gotchas

常见陷阱

A stack is the runtime, not the code. It does nothing visible until a hook or wrapper references it via
```
_stackId
```
. Creating a stack alone changes no behavior.
Most accounts don't need one. Hooks run on Celigo's hosted JavaScript runtime by default. Only escalate to a stack on a real trigger.
The server
systemToken
is auto-generated -- you don't set it. Retrieve it via
```
GET /v1/stacks/{id}/systemToken
```
(or the UI), store it as
```
INTEGRATOR_EXTENSION_SYSTEM_TOKEN
```
on your server, and rotate with
```
DELETE /v1/stacks/{id}/systemToken
```
when needed.
Never paste secrets into chat. Both the
```
systemToken
```
and the AWS
```
secretAccessKey
```
are secrets returned masked as
```
******
```
. A secret pasted into a logged conversation is compromised -- rotate it (recycle the system token, or rotate the AWS key) and re-enter it via the UI.
Don't write the masked
******
back as a real credential.
```
secretAccessKey
```
is write-only; to change it, send the real value. To keep the existing value, supply the real value again or edit through the UI -- never persist the literal
```
******
```
.
PUT clears omitted optional fields. Updating a stack replaces it: for example, omitting
```
framework
```
on update clears a previously set value. GET the stack, modify, then PUT the full object.
twoDotZero
is the only supported framework version. There is no other valid value.
lambda
needs
lambda:InvokeFunction
. The IAM user must be allowed to invoke the function,
```
functionName
```
(name or ARN) must exist in the specified
```
awsRegion
```
, and
```
language
```
must match the deployed function.
Stack != on-premise agent. Don't create a stack to reach a private database -- that's connectivity, which is an on-premise agent's job. A stack is compute for your code.
Delete is a soft delete (30-day recycle bin), and dependents block it. A stack still referenced by hooks or wrapper connections cannot be deleted until those references are repointed or removed.

栈是运行时，而非代码。在钩子或包装器通过
```
_stackId
```
引用它之前，它不会产生任何可见行为。仅创建栈不会改变任何行为。
大多数账户不需要栈。钩子默认在Celigo的托管JavaScript运行时中运行。仅在符合真实触发条件时才考虑使用栈。
server的
systemToken
是自动生成的——无需手动设置。通过
```
GET /v1/stacks/{id}/systemToken
```
（或UI）获取它，在服务器上存储为
```
INTEGRATOR_EXTENSION_SYSTEM_TOKEN
```
，需要时通过
```
DELETE /v1/stacks/{id}/systemToken
```
进行轮换。
切勿在聊天中粘贴密钥。
```
systemToken
```
和AWS
```
secretAccessKey
```
都是密钥，在响应中会被掩码为
```
******
```
。粘贴到已记录对话中的密钥会泄露——请轮换它（重新生成系统令牌，或轮换AWS密钥）并通过UI重新输入。
不要将掩码后的
******
作为真实凭据写回。
```
secretAccessKey
```
是只写字段；如需修改，请发送真实值。如需保留现有值，请再次提供真实值或通过UI编辑——切勿保留字面意义上的
```
******
```
。
PUT请求会清除未指定的可选字段。更新栈会替换整个对象：例如，更新时省略
```
framework
```
会清除之前设置的值。请先获取栈信息，修改后再PUT完整对象。
twoDotZero
是唯一支持的框架版本。没有其他有效值。
lambda
需要
lambda:InvokeFunction
权限。IAM用户必须被允许调用该函数，
```
functionName
```
（名称或ARN）必须在指定的
```
awsRegion
```
中存在，且
```
language
```
必须与部署的函数匹配。
栈≠On-premise Agent。不要为了访问私有数据库而创建栈——这是连接性需求，属于On-premise Agent的职责。栈是用于运行您的代码的计算资源。
删除是软删除（30天回收站），且依赖项会阻止删除。仍被钩子或包装器连接引用的栈无法删除，除非这些引用被重新指向或移除。

Common Errors

常见错误

Error	Cause	Fix
`422` `missing_required_field` on create	`type: server` without `server.hostURI` , or `type: lambda` missing `accessKeyId` / `secretAccessKey` / `awsRegion` / `functionName`	Provide the full config block for the chosen `type` ; the error's `field` names the missing path
`422` dependency-conflict on delete	Hooks or wrapper connections still reference the stack via `_stackId`	Repoint or remove the dependents first; list them via `GET /v1/stacks/{id}/dependencies`
Hook or wrapper still runs on Celigo's runtime	`_stackId` not set on the hook definition or the wrapper connection	Set `_stackId` on the hook (export/import) or the `wrapper` connection
`404` "Stack of type server not found." on systemToken	Requested a system token for a `lambda` stack (or wrong ID)	System tokens exist only for `server` stacks; verify the `_id` and `type`
Server calls fail / `401` from your server	Your server isn't validating the current `systemToken` , or the token was rotated	Fetch the current token via `GET /v1/stacks/{id}/systemToken` and set `INTEGRATOR_EXTENSION_SYSTEM_TOKEN`
Lambda `AccessDenied` / not invoked	IAM user lacks `lambda:InvokeFunction` , wrong `awsRegion` , or bad keys	Grant `lambda:InvokeFunction` , confirm the region matches the function, re-enter the AWS keys
Wrapper connection shows offline	The stack's `ping` function is missing or unreachable	Implement the `ping` function in the extension; Celigo re-pings offline connections hourly with exponential backoff

错误	原因	修复方法
创建时返回 `422` `missing_required_field`	`type: server` 未提供 `server.hostURI` ，或 `type: lambda` 缺少 `accessKeyId` / `secretAccessKey` / `awsRegion` / `functionName`	为所选 `type` 提供完整的配置块；错误信息中的 `field` 会指明缺失的字段路径
删除时返回 `422` dependency-conflict	钩子或包装器连接仍通过 `_stackId` 引用该栈	先重新指向或移除依赖项；通过 `GET /v1/stacks/{id}/dependencies` 列出依赖项
钩子或包装器仍在Celigo的运行时中运行	钩子定义或包装器连接未设置 `_stackId`	在钩子（导出/导入）或 `wrapper` 连接上设置 `_stackId`
获取systemToken时返回 `404` "Stack of type server not found."	请求了 `lambda` 栈的系统令牌（或ID错误）	系统令牌仅适用于 `server` 栈；验证 `_id` 和 `type`
服务器调用失败/您的服务器返回 `401`	您的服务器未验证当前 `systemToken` ，或令牌已被轮换	通过 `GET /v1/stacks/{id}/systemToken` 获取当前令牌，并设置 `INTEGRATOR_EXTENSION_SYSTEM_TOKEN` 环境变量
Lambda返回 `AccessDenied` /未被调用	IAM用户缺少 `lambda:InvokeFunction` 权限、 `awsRegion` 错误或密钥无效	授予 `lambda:InvokeFunction` 权限，确认区域与函数匹配，重新输入AWS密钥
包装器连接显示离线	栈的 `ping` 函数缺失或无法访问	在扩展中实现 `ping` 函数；Celigo会以指数退避策略每小时重新检查离线连接

managing-stacks

Original

Translation

Managing Stacks

管理栈

The Stack Is the Runtime, Not the Code

栈是运行时，而非代码

Stack vs On-Premise Agent

栈与On-premise Agent的区别

Quick Reference

快速参考

Do You Need a Stack?

是否需要栈？

server vs lambda

server vs lambda

Minimum Required Fields

必填字段

Referencing a Stack (_stackId)

引用栈（_stackId）

Related Skills

相关技能

How to Manage a Stack

如何管理栈

1. Confirm you actually need one

1. 确认确实需要栈

2. Choose the type

2. 选择类型

3. Check for existing stacks

3. 检查现有栈

4. Create the stack

4. 创建栈

server stack -- systemToken is auto-generated, do not include it

server栈——systemToken自动生成，请勿包含在请求中

server stack with an IP allow-list

带IP白名单的server栈

lambda stack -- enter the AWS secret via a local, untracked file; never paste real secrets into chat

lambda栈——通过本地未跟踪文件输入AWS密钥；切勿在聊天中粘贴真实密钥

5. Wire up authentication

5. 配置认证

6. Point a hook or wrapper at the stack

6. 将钩子或包装器指向栈

7. Verify

7. 验证

CLI Commands

CLI命令

CRUD

CRUD操作

Discover existing stacks across the account

跨账户查找现有栈

Pre-Submit Checklist

提交前检查清单

Gotchas

常见陷阱

Common Errors

常见错误

Referencing a Stack (
`_stackId`
)

引用栈（
`_stackId`
）