44 lines
2.1 KiB
Protocol Buffer
44 lines
2.1 KiB
Protocol Buffer
syntax = "proto3";
|
||
|
||
package test_pb;
|
||
|
||
option go_package = "Beacon/pkg/pb"; // 替换 your_module_path
|
||
|
||
message DynamicTestRunInput {
|
||
string run_id = 1;
|
||
string composite_case_id = 2; // 引用数据库中的复合案例ID
|
||
map<string, string> global_parameters = 3; // 运行时传入的全局参数，例如 environment_url
|
||
|
||
// 这里的 steps 会在 Go 服务端启动 Workflow 时，根据数据库查询结果动态构建
|
||
// 也可以不在 Proto 中定义，直接在 Workflow 中根据 DB 数据拉取并使用
|
||
// 但如果希望 Workflow 的输入本身包含整个流程定义，可以定义一个嵌套结构
|
||
repeated DynamicStep steps = 4; // 也可以通过 DB ID 在 Workflow 中获取
|
||
}
|
||
|
||
message DynamicStep {
|
||
string step_id = 1; // 对应数据库中的 step_id
|
||
string activity_name = 2; // 对应 Activity 函数名
|
||
map<string, string> parameters_json = 3; // 将 JSONB 转换为 string 或 bytes 传递
|
||
// 对于条件和跳转，Workflow 内部逻辑会根据这些信息进行判断
|
||
// 例如，可以传递一个表示整个流程图的 DAG 结构，或让 Workflow 每次都查询 DB
|
||
}
|
||
|
||
// 定义一个复合测试用例中的单个步骤
|
||
message CompositeCaseStepDefinition {
|
||
int64 step_id = 1; // 对应数据库中的 step_id
|
||
int32 step_order = 2; // 步骤执行顺序
|
||
string step_type = 3; // e.g., "API_TEST", "UI_TEST"
|
||
string activity_name = 4; // 对应的 Temporal Activity 函数名
|
||
|
||
// 将参数作为 JSON 字符串传递，在 Workflow 中反序列化
|
||
// 也可以根据 Activity 的具体类型定义一个 oneof 结构，但 JSON 字符串更灵活
|
||
string parameters_json = 5; // JSON 格式的 Activity 参数
|
||
|
||
// 条件跳转 (如果成功/失败，跳转到哪个 step_order)
|
||
optional int32 success_next_step_order = 6; // 可选，如果成功则跳转到此步骤的顺序号
|
||
optional int32 failure_next_step_order = 7; // 可选，如果失败则跳转到此步骤的顺序号
|
||
|
||
// 执行条件（例如：{"prev_step_id": "xyz", "status": "success"}）
|
||
// Workflow 内部需要解析和评估此 JSON
|
||
string run_condition_json = 8;
|
||
} |