n8n-nodes-orbital-actions 2.2.2 → 3.0.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +287 -0
- package/dist/nodes/Orbital/OrbitalActions.node.d.ts +20 -1
- package/dist/nodes/Orbital/OrbitalActions.node.js +985 -63
- package/dist/nodes/Orbital/OrbitalActions.node.js.map +1 -1
- package/dist/nodes/Orbital/pipeline-templates.d.ts +51 -0
- package/dist/nodes/Orbital/pipeline-templates.js +407 -0
- package/dist/nodes/Orbital/pipeline-templates.js.map +1 -0
- package/package.json +3 -3
package/README.md
ADDED
|
@@ -0,0 +1,287 @@
|
|
|
1
|
+
# n8n-nodes-orbital-actions
|
|
2
|
+
|
|
3
|
+
Nodo de n8n para reportar progreso, steps y callbacks a Orbital desde workflows ejecutados como **Actions**.
|
|
4
|
+
|
|
5
|
+
> **v3.0.0** — Modelo plano (Pipeline + Fases + Steps) con plantillas de industria. Breaking change respecto a v2.x — ver sección [Migración](#migración).
|
|
6
|
+
|
|
7
|
+
## Instalación
|
|
8
|
+
|
|
9
|
+
```bash
|
|
10
|
+
npm install n8n-nodes-orbital-actions
|
|
11
|
+
```
|
|
12
|
+
|
|
13
|
+
O desde la UI de n8n: **Settings → Community Nodes → Install** → `n8n-nodes-orbital-actions`.
|
|
14
|
+
|
|
15
|
+
## Concepto
|
|
16
|
+
|
|
17
|
+
Cuando Orbital lanza un flujo n8n como **Action**, envía un payload con JWT del job (trae `jobId`, `userId`, `projectId`, `agentId` embebidos). Este nodo se usa **dentro del flujo** para reportar:
|
|
18
|
+
|
|
19
|
+
- **Pipeline** de fases al inicio (esqueleto del job)
|
|
20
|
+
- **Progreso** y **steps** durante la ejecución (hidratación)
|
|
21
|
+
- **Callback** de éxito/error al final
|
|
22
|
+
- **Documentos**, **notificaciones**, **aprobaciones HITL** según convenga
|
|
23
|
+
|
|
24
|
+
El dashboard de Orbital muestra todo en tiempo real (polling cada 8s).
|
|
25
|
+
|
|
26
|
+
## Modelo de datos
|
|
27
|
+
|
|
28
|
+
```
|
|
29
|
+
Job ← workflow_jobs (1 por ejecución)
|
|
30
|
+
└── Fase ← pipelineUi (declarada al inicio)
|
|
31
|
+
└── Step (flat, sin jerarquía) ← job_steps filtrado por phase_ref
|
|
32
|
+
└── ai.tools[] (inline) ← metadata del step AI, no substeps
|
|
33
|
+
```
|
|
34
|
+
|
|
35
|
+
**3 niveles fijos, no árbol recursivo**. Alineado con NIST, GitHub Actions, Airflow, Temporal.
|
|
36
|
+
|
|
37
|
+
## Uso típico
|
|
38
|
+
|
|
39
|
+
### 1. Declarar Pipeline (PRIMER nodo del flujo)
|
|
40
|
+
|
|
41
|
+
```
|
|
42
|
+
[Webhook Trigger]
|
|
43
|
+
↓
|
|
44
|
+
[Orbital Actions]
|
|
45
|
+
Operación: Declarar Pipeline
|
|
46
|
+
Plantilla: [CyberSOC NIST ▾]
|
|
47
|
+
→ Envía POST /public/wh/pipeline
|
|
48
|
+
→ Dashboard muestra 5 fases vacías:
|
|
49
|
+
- Identificación/Protección
|
|
50
|
+
- Detección
|
|
51
|
+
- Correlación
|
|
52
|
+
- Respuesta
|
|
53
|
+
- Análisis
|
|
54
|
+
```
|
|
55
|
+
|
|
56
|
+
### 2. Reportar progreso y steps
|
|
57
|
+
|
|
58
|
+
```
|
|
59
|
+
[Orbital Actions]
|
|
60
|
+
Operación: Reportar Progreso
|
|
61
|
+
Fase: detection ← marca como activa
|
|
62
|
+
Progreso: 20
|
|
63
|
+
|
|
64
|
+
[HTTP Request: recolectar logs]
|
|
65
|
+
|
|
66
|
+
[Orbital Actions]
|
|
67
|
+
Operación: Reportar Step
|
|
68
|
+
Fase: detection ← dropdown autocompletado tras 1ª ejecución
|
|
69
|
+
Título: "Logs firewall recolectados"
|
|
70
|
+
Tipo: io
|
|
71
|
+
Estado: success
|
|
72
|
+
```
|
|
73
|
+
|
|
74
|
+
### 3. Saltar fase (opcional, early-exit)
|
|
75
|
+
|
|
76
|
+
```
|
|
77
|
+
[IF es falso positivo?]
|
|
78
|
+
-> SI: [Orbital Actions] Saltar Fase: correlation, Motivo: "Falso positivo L1"
|
|
79
|
+
-> SI: [Orbital Actions] Saltar Fase: response, Motivo: "No aplica"
|
|
80
|
+
-> SI: [Orbital Actions] Saltar Fase: analysis, Motivo: "Cadena cerrada"
|
|
81
|
+
```
|
|
82
|
+
|
|
83
|
+
### 4. Finalizar
|
|
84
|
+
|
|
85
|
+
```
|
|
86
|
+
[Orbital Actions]
|
|
87
|
+
Operación: Finalizar - Éxito
|
|
88
|
+
Título del Resultado: "Informe generado"
|
|
89
|
+
Contenido: markdown del informe
|
|
90
|
+
```
|
|
91
|
+
|
|
92
|
+
## Operaciones disponibles
|
|
93
|
+
|
|
94
|
+
### Pipeline
|
|
95
|
+
|
|
96
|
+
| Operación | Uso |
|
|
97
|
+
|---|---|
|
|
98
|
+
| **Declarar Pipeline** | PRIMER nodo. Envía fases al backend desde una plantilla de industria o custom. |
|
|
99
|
+
| **Saltar Fase** | Marca una fase como saltada con motivo (early-exit, fases ya hechas, N/A). |
|
|
100
|
+
|
|
101
|
+
### Progreso y Steps
|
|
102
|
+
|
|
103
|
+
| Operación | Uso |
|
|
104
|
+
|---|---|
|
|
105
|
+
| **Reportar Progreso** | Actualiza `status`/`progress`/`phase` del job. |
|
|
106
|
+
| **Reportar Step** | Crea un step en la fase actual — 90% de casos. |
|
|
107
|
+
| **Construir Step (sin enviar)** | Devuelve JSON del step para manipular con Code/Merge. |
|
|
108
|
+
| **Batch > Añadir Step al Buffer** | Acumula step localmente (sin HTTP). |
|
|
109
|
+
| **Batch > Enviar Buffer** | Envía todos los steps acumulados en un POST atómico. |
|
|
110
|
+
| **Actualizar Step Abierto (async)** | **Solo** para async/loops largos — cierra un step con `status=started`. |
|
|
111
|
+
|
|
112
|
+
### Callbacks
|
|
113
|
+
|
|
114
|
+
| Operación | Uso |
|
|
115
|
+
|---|---|
|
|
116
|
+
| **Finalizar - Éxito** | Marca job como `complete`. Puede crear documento. |
|
|
117
|
+
| **Finalizar - Error** | Marca job como `errored` con categoría. |
|
|
118
|
+
| **Crear Documento** | Añade un documento al centro de documentos del usuario. |
|
|
119
|
+
| **Notificar Usuario** | Envía notificación visible al usuario. |
|
|
120
|
+
| **Solicitar Aprobación (HITL)** | Pausa el job esperando acción del usuario. |
|
|
121
|
+
|
|
122
|
+
## Plantillas built-in (22)
|
|
123
|
+
|
|
124
|
+
### Cybersecurity / SOC (5)
|
|
125
|
+
- **CyberSOC NIST** (Operativo L1/L2/L3) — Identificación/Protección -> Detección -> Correlación -> Respuesta -> Análisis (default)
|
|
126
|
+
- **NIST CSF 2.0** (Estratégico) — Govern -> Identify -> Protect -> Detect -> Respond -> Recover
|
|
127
|
+
- **SOC Incident Response** — Triage -> Investigate -> Contain -> Eradicate -> Recover -> Post-mortem
|
|
128
|
+
- **ISO 27001 Audit** — Scope -> Evidence -> Gap -> Remediation -> Verification
|
|
129
|
+
- **MITRE ATT&CK Response** — Detection -> Analysis -> Containment -> Eradication -> Recovery -> Lessons Learned
|
|
130
|
+
|
|
131
|
+
### Offensive Security (2)
|
|
132
|
+
- **Penetration Test** — Recon -> Scanning -> Enum -> Exploitation -> Post-Exploit -> Reporting
|
|
133
|
+
- **Red Team Operation** — Planning -> Recon -> Initial Access -> Lateral Movement -> Objectives -> Exfil -> Cleanup
|
|
134
|
+
|
|
135
|
+
### Research / Análisis (4)
|
|
136
|
+
- **Deep Research** — Scope -> Gather -> Analyze -> Synthesize -> Validate -> Report
|
|
137
|
+
- **Threat Intelligence** — Collect -> Process -> Analyze -> Disseminate -> Feedback
|
|
138
|
+
- **Market Research** — Define -> Design -> Collect -> Analyze -> Report -> Recommend
|
|
139
|
+
- **User Research (UX)** — Discover -> Define -> Design -> Test -> Iterate
|
|
140
|
+
|
|
141
|
+
### IT Service Management (2)
|
|
142
|
+
- **ITIL Change Management** — Request -> Assess -> Approve -> Plan -> Implement -> Review -> Close
|
|
143
|
+
- **ITIL Incident Management** — Detect -> Log -> Categorize -> Prioritize -> Diagnose -> Resolve -> Close
|
|
144
|
+
|
|
145
|
+
### DevOps (2)
|
|
146
|
+
- **CI/CD Deploy** — Build -> Test -> Stage -> Deploy -> Validate -> Monitor
|
|
147
|
+
- **Bug Triage & Fix** — Report -> Reproduce -> Diagnose -> Fix -> Verify -> Release
|
|
148
|
+
|
|
149
|
+
### Data (2)
|
|
150
|
+
- **ETL Pipeline** — Extract -> Transform -> Validate -> Load -> Verify
|
|
151
|
+
- **ML Model Lifecycle** — Prepare -> Train -> Validate -> Deploy -> Monitor -> Retrain
|
|
152
|
+
|
|
153
|
+
### Business (2)
|
|
154
|
+
- **Customer Onboarding** — Welcome -> Setup -> Training -> Verification -> Go-Live -> Follow-up
|
|
155
|
+
- **Sales Pipeline** — Lead -> Qualify -> Demo -> Propose -> Negotiate -> Close -> Handoff
|
|
156
|
+
|
|
157
|
+
### Compliance (2)
|
|
158
|
+
- **GDPR DPIA** — Identify -> Assess -> Mitigate -> Document -> Review
|
|
159
|
+
- **Contract Review** — Draft -> Review -> Negotiate -> Approve -> Sign -> Archive
|
|
160
|
+
|
|
161
|
+
### Content (1)
|
|
162
|
+
- **Content Production** — Brief -> Research -> Draft -> Review -> Publish -> Promote
|
|
163
|
+
|
|
164
|
+
### Custom
|
|
165
|
+
- **Custom** — Define tus propias fases manualmente.
|
|
166
|
+
|
|
167
|
+
## Dropdown dinámico de fases (loadOptions)
|
|
168
|
+
|
|
169
|
+
Tras ejecutar `Declarar Pipeline` al menos una vez, los siguientes nodos con campo **Fase** (Reportar Step, Saltar Fase, etc.) muestran un **dropdown** con las fases declaradas.
|
|
170
|
+
|
|
171
|
+
**Limitación n8n**: `loadOptions` solo lee de `workflowStaticData` (persistido de ejecuciones anteriores), no del output del mismo run. En la 1ª ejecución, escribe el `ref` directamente (ej: `detection`) o déjalo vacío — el backend auto-asigna a la fase activa (`currentPhaseRef`).
|
|
172
|
+
|
|
173
|
+
## Auto-asignación de fase
|
|
174
|
+
|
|
175
|
+
Si un step no trae `phaseRef`, el backend lo auto-asigna a `currentPhaseRef` (última fase marcada con `reportProgress`). Por tanto:
|
|
176
|
+
|
|
177
|
+
```
|
|
178
|
+
[Reportar Progreso] fase=detection
|
|
179
|
+
[Reportar Step] (sin phaseRef) -> auto-asigna a "detection"
|
|
180
|
+
[Reportar Step] (sin phaseRef) -> auto-asigna a "detection"
|
|
181
|
+
[Reportar Progreso] fase=response
|
|
182
|
+
[Reportar Step] (sin phaseRef) -> auto-asigna a "response"
|
|
183
|
+
```
|
|
184
|
+
|
|
185
|
+
## Combinación con OrbitalProcess
|
|
186
|
+
|
|
187
|
+
Si el flujo invoca agentes IA via `n8n-nodes-orbital` (OrbitalProcess), activar **Emitir Step** en ese nodo genera automáticamente un step `kind=ai` con `ai.tools[]` inline en la fase actual:
|
|
188
|
+
|
|
189
|
+
```
|
|
190
|
+
[Orbital Actions: Reportar Progreso] fase=detection
|
|
191
|
+
↓
|
|
192
|
+
[Orbital Process: Ejecutar Agente "clasificador"]
|
|
193
|
+
[X] Emitir Step
|
|
194
|
+
Fase: detection
|
|
195
|
+
-> Emite 1 step AI con tools inline (modelo plano, sin substeps)
|
|
196
|
+
```
|
|
197
|
+
|
|
198
|
+
Dashboard:
|
|
199
|
+
```
|
|
200
|
+
Detection (2 steps, 3.1s)
|
|
201
|
+
[ok] Logs recolectados io, 1.2s
|
|
202
|
+
[ok] Clasificador IA ai, 1.9s
|
|
203
|
+
gpt-4o, 1250 tokens, 3 tools
|
|
204
|
+
(expandir: get_logs, classify, score con input/output)
|
|
205
|
+
```
|
|
206
|
+
|
|
207
|
+
## Auth
|
|
208
|
+
|
|
209
|
+
Header `Authorization: Bearer eyJ...` — JWT del job, extraído del payload del Webhook:
|
|
210
|
+
|
|
211
|
+
```
|
|
212
|
+
Token JWT: {{ $("Webhook").item.json.body.auth.token }}
|
|
213
|
+
```
|
|
214
|
+
|
|
215
|
+
El JWT trae embebidos: `jobId`, `userId`, `projectId`, `agentId`, `conversationId`. El backend no necesita nada más.
|
|
216
|
+
|
|
217
|
+
## Endpoints internos
|
|
218
|
+
|
|
219
|
+
El nodo llama a:
|
|
220
|
+
|
|
221
|
+
- `POST /public/wh/pipeline` — declarePipeline (endpoint dedicado REST)
|
|
222
|
+
- `POST /public/wh/events` — reportProgress / reportStep / batchFlush / updateStep / skipPhase / requestApproval
|
|
223
|
+
- `POST /public/wh/callback` — Finalizar Éxito / Error
|
|
224
|
+
- `POST /public/wh/documents` — Crear Documento
|
|
225
|
+
- `POST /public/wh/notify` — Notificar
|
|
226
|
+
|
|
227
|
+
El middleware `apiKeyValidation` detecta automáticamente el token como JWT (empieza por `eyJ`) o API Key (`oapi_`).
|
|
228
|
+
|
|
229
|
+
## Output
|
|
230
|
+
|
|
231
|
+
Cada operación devuelve en `json`:
|
|
232
|
+
|
|
233
|
+
```json
|
|
234
|
+
{
|
|
235
|
+
"operation": "reportStep",
|
|
236
|
+
"url": "https://api.orbital.../public/wh/events",
|
|
237
|
+
"stepId": "step_abc123",
|
|
238
|
+
"step": { "id": "...", "kind": "...", "status": "...", "title": "...", "phaseRef": "..." },
|
|
239
|
+
"success": true
|
|
240
|
+
}
|
|
241
|
+
```
|
|
242
|
+
|
|
243
|
+
El `stepId` se puede usar en operaciones posteriores:
|
|
244
|
+
```
|
|
245
|
+
={{ $("Reportar Step").item.json.stepId }}
|
|
246
|
+
```
|
|
247
|
+
|
|
248
|
+
## Migración desde v2.x
|
|
249
|
+
|
|
250
|
+
**Breaking changes en v3.0.0**:
|
|
251
|
+
|
|
252
|
+
| Cambio | v2.x | v3.0.0 |
|
|
253
|
+
|---|---|---|
|
|
254
|
+
| Modelo | Árbol recursivo con `parentStepId` | **Plano por fase** (sin parent) |
|
|
255
|
+
| Tools del agente (emitStep) | N+1 steps (1 AI + N tools) | **1 step con `ai.tools[]` inline** |
|
|
256
|
+
| Campo "Es Substep De" | Sí | **Eliminado** |
|
|
257
|
+
| Stack automático `status=started` | Sí | **Eliminado** — usar explícitamente `updateStep` solo para async |
|
|
258
|
+
| Declaración de pipeline | No | **Nueva operación `declarePipeline`** con 22 plantillas |
|
|
259
|
+
| Skip de fase | No | **Nueva operación `skipPhase`** con motivo |
|
|
260
|
+
| Campo `phaseRef` en steps | String libre | **Dropdown dinámico** (loadOptions) con autocomplete |
|
|
261
|
+
|
|
262
|
+
**Cómo adaptar flujos v2.x**:
|
|
263
|
+
|
|
264
|
+
1. Añadir un nodo `Declarar Pipeline` al inicio del flujo.
|
|
265
|
+
2. Rellenar el campo **Fase** en cada step (o dejarlo vacío — se auto-asigna a la fase activa).
|
|
266
|
+
3. Eliminar el campo `parentStepId` de los steps (ya no existe).
|
|
267
|
+
4. Si usabas steps con `status=started` + substeps automáticos, ahora crea steps planos individuales en la misma fase.
|
|
268
|
+
|
|
269
|
+
## Build local
|
|
270
|
+
|
|
271
|
+
```bash
|
|
272
|
+
pnpm install
|
|
273
|
+
pnpm run build
|
|
274
|
+
```
|
|
275
|
+
|
|
276
|
+
El output queda en `dist/`. Para testing local:
|
|
277
|
+
|
|
278
|
+
```bash
|
|
279
|
+
npm link # en este paquete
|
|
280
|
+
cd ~/.n8n/custom # o donde tengas custom nodes
|
|
281
|
+
npm link n8n-nodes-orbital-actions
|
|
282
|
+
# reiniciar n8n
|
|
283
|
+
```
|
|
284
|
+
|
|
285
|
+
## Licencia
|
|
286
|
+
|
|
287
|
+
MIT
|
|
@@ -1,4 +1,4 @@
|
|
|
1
|
-
import type { IExecuteFunctions, INodeExecutionData, INodeType, INodeTypeDescription } from 'n8n-workflow';
|
|
1
|
+
import type { IExecuteFunctions, ILoadOptionsFunctions, INodeExecutionData, INodePropertyOptions, INodeType, INodeTypeDescription } from 'n8n-workflow';
|
|
2
2
|
/**
|
|
3
3
|
* ORBITAL ACTIONS — Nodo para integración webhook/actions con Orbital.
|
|
4
4
|
*
|
|
@@ -9,5 +9,24 @@ import type { IExecuteFunctions, INodeExecutionData, INodeType, INodeTypeDescrip
|
|
|
9
9
|
*/
|
|
10
10
|
export declare class OrbitalActions implements INodeType {
|
|
11
11
|
description: INodeTypeDescription;
|
|
12
|
+
/**
|
|
13
|
+
* loadOptions — populan dropdowns dinámicos en design-time.
|
|
14
|
+
*
|
|
15
|
+
* LIMITACIÓN n8n: loadOptions solo puede leer de workflowStaticData (persistido
|
|
16
|
+
* de ejecuciones anteriores) o hacer HTTP. NO puede resolver expresiones n8n
|
|
17
|
+
* como {{ $("X").json... }} porque corre ANTES de runtime.
|
|
18
|
+
*
|
|
19
|
+
* Flujo:
|
|
20
|
+
* 1. Usuario ejecuta el workflow al menos 1 vez con declarePipeline
|
|
21
|
+
* 2. Tras la ejecución, orbitalPipelinePhases queda guardado en staticData
|
|
22
|
+
* 3. En la siguiente vez que abre el nodo, el dropdown se llena con esas fases
|
|
23
|
+
* 4. En la 1ª ejecución, el dropdown está vacío — el usuario escribe el ref
|
|
24
|
+
* manualmente (ej: "detection") o deja vacío para auto-asignar a currentPhaseRef
|
|
25
|
+
*/
|
|
26
|
+
methods: {
|
|
27
|
+
loadOptions: {
|
|
28
|
+
getPipelinePhases(this: ILoadOptionsFunctions): Promise<INodePropertyOptions[]>;
|
|
29
|
+
};
|
|
30
|
+
};
|
|
12
31
|
execute(this: IExecuteFunctions): Promise<INodeExecutionData[][]>;
|
|
13
32
|
}
|