MGWC flashcards
MGWC · Build recall with a focused review session.
33 cards. Read the term and the definition here. The deck at the top of this page is optional.
- C4 model levels
- A hierarchical way to document architecture: Context (systems and users), Container (deployable apps and APIs), Component (flows and connectors), and Code. Choose the level matching the audience.
- Architecture decision record
- A short document recording context, decision, alternatives considered, and consequences. ADRs are immutable once accepted; a later ADR supersedes rather than edits the original.
- Exchange asset types
- Reusable Anypoint Exchange assets include REST and SOAP APIs, HTTP APIs, connectors, templates, examples, policies, and custom assets. Each is versioned independently and shared across the organization.
- Non-functional requirements per interface
- Document expected throughput, payload size, latency SLO, availability target, data retention, and RPO/RTO for each interface. These drive worker sizing, policy choice, and queue configuration.
- Control plane vs runtime plane
- The control plane hosts design and management (Design Center, API Manager, Exchange). The runtime plane executes Mule apps and gateways (CloudHub, Runtime Fabric, hybrid). They are deployed and scaled separately.
- Scatter-Gather behavior
- Runs branches in parallel and aggregates results into an array. By default a failing branch fails the whole route; set maxConcurrency and handle partial failures explicitly when branches are independent.
- Flow versus sub-flow
- A flow has its own source and error handler. A sub-flow has neither and inherits the caller's error handler, making it useful for reusable processing steps invoked from multiple flows.
- Object Store v2 limits
- Provides cross-worker persistent key-value state for idempotency keys and watermarks. Values are limited to 10 MB, TTL is configurable, and it is not a substitute for a database.
- Batch job semantics
- Processes records in blocks with per-record success and failure tracking. Supports max-failures and an on-complete phase, and reports failures for later reprocessing.
- API-led tiers
- System APIs expose systems of record, Process APIs orchestrate and apply business logic, Experience APIs shape data for a specific channel. Dependencies point downward only.
- System API responsibility
- Wraps exactly one system of record, hides its protocol and schema, and contains no business logic. It is coarse-grained and stable so multiple Process APIs can reuse it.
- Experience API granularity
- One Experience API per consumer channel or device, shaped to that consumer's task. It is narrow and changes more often than lower layers, so keep channel logic out of Process APIs.
- API versioning rule
- Put the major version in the base URI, for example /v1. Additive changes stay in the same major version; breaking changes require a new major version plus a deprecation window for existing consumers.
- API instance autodiscovery
- A Mule app links to an API instance in API Manager by declaring the api.id in its configuration. Policies then apply to that app without a separate proxy.
- Policy execution order
- Policies run in the order listed in API Manager. Authentication and rate limiting normally precede transformation and logging so unauthenticated or over-limit traffic is rejected early.
- SLA-based rate limiting
- API Manager defines tiers with request limits, and each client application is assigned a tier. Limits are enforced per client ID, preventing one consumer from exhausting shared capacity.
- Client ID enforcement
- A policy requiring callers to present a registered client ID and secret from an application in API Manager. It identifies the consumer and enables per-client SLA tiers and analytics.
- JWT validation policy
- Validates the token signature against the configured JWKS, plus issuer, audience, expiry, and scopes. Requests failing validation are rejected before reaching the Mule flow.
- Until Successful scope
- Retries a message processor a configured number of times with a delay between attempts. Use only for idempotent operations or when paired with an idempotency key to avoid duplicates.
- Circuit breaker pattern
- After N consecutive failures the breaker opens and fails fast for a cool-down period, then allows a probe. It prevents cascading failure when a backend is degraded.
- CloudHub worker sizing
- Capacity is workers multiplied by vCores, where one vCore equals 0.1 vCPU, 0.5 GB heap, and 500 MB disk. Scale horizontally with more workers before increasing worker size.
- Dead-letter queue
- A destination for messages that repeatedly fail processing. Configure redelivery attempts on the source queue and route poison messages to the DLQ for inspection rather than blocking the consumer.
- Streaming large payloads
- Process large payloads as streams instead of collecting them into memory. Use repeatable streams when the payload is read more than once, and paginate outbound API calls.
- OAuth client credentials flow
- Machine-to-machine grant where the client exchanges its ID and secret for an access token. Suitable for backend integrations; secrets must never be embedded in mobile or browser code.
- Secure properties placeholder
- Credentials stored as secure:: placeholders in property files are decrypted at runtime using a key supplied at deployment. The encrypted values can be committed safely to source control.
- mTLS for system calls
- Both parties present certificates during the TLS handshake. Configure keystore and truststore in the TLS context, and rotate certificates before expiry to avoid outage.
- PII redaction in logs
- Mask or omit sensitive fields before logging and before sending data to analytics. Use DataWeave to replace values, and keep production log levels conservative.
- DataWeave pluck function
- Converts an object into an array of key-value pairs, enabling map, filter, and sort over object entries. Commonly used to transform a keyed map into a list.
- Enrich processor
- Calls a resource and merges the result into the current message without replacing the original payload. It implements the content enricher pattern for adding reference data.
- on-error-continue vs propagate
- on-error-continue handles the error and returns a normal result to the caller. on-error-propagate rethrows, optionally after mapping to a custom error type, so the caller sees the failure.
- Custom error types
- Raise errors with an APP: namespace such as APP:VALIDATION using raise-error. Flow error handlers can then match specific types before falling back to a catch-all ANY handler.
- Environment promotion
- The same built artifact is promoted across Design, Sandbox, and Production; only configuration and secrets differ per environment. Production secrets are never reused in lower environments.
- MUnit testing
- A Mule testing framework that mocks connectors and processors and asserts on payload, attributes, and errors. Run it in the build pipeline and fail on coverage regression.