Designing a Process API means specifying its contract, deciding which System APIs it will orchestrate, and building the transformation and error logic that models the business process. Here is the shape of that work in Anypoint Platform.
- Define the business process and its contract
Pin down the single business process this Process API serves, such as order fulfillment or unified customer view. Write the API specification (typically in RAML or OpenAPI) describing the resources, request, and response the consumers will see, independent of any backend.
- Identify the System APIs to orchestrate
List the System APIs that hold the data you need and confirm each one exposes the operations required. The Process API will call these rather than any database directly, so missing a needed System API is a signal to build or extend one first.
- Build the orchestration and transformation flow
Implement the flow that calls the System APIs in the right order, then merge and transform their responses with DataWeave into the shape your contract promises. Add the conditional logic the process needs, such as splitting a shipment when stock is short.
- Add error handling, then publish and govern
Decide how partial failures behave (retry, compensate, or return a clear error), and implement it. Publish the API as a reusable asset in Anypoint Exchange, apply governance rulesets and policies, and version the contract so consumers can depend on it safely.
The one business process this API models; keep it focused rather than letting it sprawl across unrelated concerns.
The set of System APIs (and possibly other Process APIs) this layer calls; it should never reach a backend system directly.
The DataWeave mappings that merge and reshape System API responses into the contract's response format.
The agreed behavior when one orchestrated call fails midway, covering retries, compensation, and the error returned to consumers.
- If a Process API connects straight to a database or hard-codes system credentials, it has become a System API and loses its reuse value. Always go through a System API.
- Stuffing unrelated business logic into one Process API creates a monolith that is hard to reuse. Split distinct processes into separate Process APIs.
- Skipping a partial-failure plan is risky in multi-system orchestration, where payment may succeed after inventory was reserved but shipping failed.
- Changing the Process API contract without versioning can break every Experience API and agent that depends on it.