# sap-intercompany-api

Backend HTTP (NestJS) dueño de toda la configuración de
[`sap-intercompany-worker`](../sap-intercompany-worker) — bases de datos,
escenarios, destinos, mapeos de valor — y del log de replicación
(`webhook_events` + `replication_attempts`), sobre la misma Postgres.
Reemplaza a las rutas `/replication/*` que tenía `sap-webhook-api`.

`sap-intercompany-worker` no expone HTTP a propósito (sigue siendo un
script plano por cron); esta API es la única superficie HTTP para
administrar su configuración, pensada para ser consumida por
`sap-intercompany-viewer` (frontend, aún no implementado).

## Qué NO hace

- **No corre migraciones.** `prisma/schema.prisma` es una copia de la del
  worker (mismo `DATABASE_URL`); acá solo se corre `prisma generate` para
  tener un cliente tipado. El worker sigue siendo el dueño del schema.
- **No genera la lógica de `filter`/`transform` de un escenario.**
  `POST /scenarios` crea la fila en Postgres y, si no existe, escribe el
  scaffold de 3 secciones en
  `sap-intercompany-worker/src/scenarios/<slug>.ts` (mismo scaffold que
  genera `scenario:add` del CLI del worker) — el cuerpo real de `filter`/
  `transform` siempre se edita a mano, en el editor del usuario.

## Endpoints

- `GET/POST /databases`, `GET /databases/:code`, `PATCH /databases/:code`
  (incluye desactivar con `{"active": false}`). Las respuestas nunca
  incluyen `password`.
- `GET /scenarios`, `GET /scenarios/:code`, `POST /scenarios`,
  `PATCH /scenarios/:code`, `POST /scenarios/:code/rename`.
- `GET /scenarios/:code/source` — código fuente crudo del `.ts` (solo
  lectura; requiere `WORKER_ROOT_PATH`).
- `GET/POST /scenarios/:code/destinations`,
  `DELETE /scenarios/:code/destinations/:databaseCode`.
- `GET/POST /scenarios/:code/mappings` (`GET` acepta `?fieldName=`).
- `GET /events` (filtros `from`, `to`, `businessObject`, `scenarioCode`,
  `status`), `GET /events/:id` (incluye `replication_attempts`).
- `POST /events/:id/reprocess` — pone el evento en `status='pending'` de
  nuevo; el worker lo va a reprocesar contra **todos** los escenarios y
  destinos aplicables en su próximo ciclo, no solo el que falló.

`POST /databases` y `POST /scenarios` fallan con `409` si el `code` ya
existe (a diferencia del CLI del worker, que hace upsert) — para
actualizar un existente se usa `PATCH`.

## Quick start

```bash
npm install
cp .env.example .env   # completar DATABASE_URL (la misma del worker) y WORKER_ROOT_PATH
npx prisma generate    # cliente tipado propio; NUNCA correr `prisma migrate` acá
npm start               # http://localhost:3001
```

## Stack

- NestJS (mismo framework/estilo que `sap-webhook-api`), corrido con `tsx`
  en vez de `nest build` — mismo enfoque ESM + TypeScript nativo que ya usa
  `sap-intercompany-worker`, para poder importar directo el cliente Prisma
  generado (`prisma-client`, salida `.ts`) sin fricción de compilación.
- Prisma 7 + `@prisma/adapter-pg`, contra la Postgres compartida con el
  worker.

Nota de implementación: la inyección de dependencias de Nest usa
`@Inject(Token)` explícito en cada constructor (en vez de depender solo del
tipo declarado) porque bajo `tsx`/esbuild la emisión de
`design:paramtypes` (`emitDecoratorMetadata`) no es confiable — sin esto,
Nest instancia los controllers/servicios sin fallar pero con las
dependencias en `undefined`.