Workflow integration

A second engine, n8n, gained the same first-party treatment the core had already given SAP Build Process Automation. Before it, triggering an n8n workflow from CAP meant the independent sleibach/cap-n8ncap-n8ncds-pluginMaps CAP onto n8n: a programmatic workflow API, @n8n.trigger annotations dispatched through the transactional outbox, and a typed cds import --from n8n.independent, cap plugin or a hand-wired HTTP call; after it, @n8n.process.start on an action or event, or the programmatic n8n service, triggers a workflow with credentials resolved through config, a Cloud Foundry binding or a BTP destination.

The core gained a first-party way to drive SAP Build Process Automation from a CAP service. Before it, starting or managing a process meant hand-rolling calls against the workflow API through a destination; after it, a built-in generic ProcessService covers start, suspend, resume and cancel without any import, and importing a specific process additionally generates a typed CDS service with ProcessInputs, ProcessOutputs and ProcessInstance types.