MuleSoft Certified Platform Architect Exam (MCPA) notes

 

1. RAML must be updated when the API implementation changes the structure of the request or response messages.
2. When you deploy your application in particular region in MuleSoft Cloudhub, Workers are randomly distributed across available AZs within that region
3. What is most likely NOT a characteristic of an integration test for a REST API implementation? The test prepares a known request payload and validates the response payload
4. When could the API data model of a System API reasonably mimic the data model exposed by the corresponding backend system, with minimal improvements over the backend system's data model - When there is an existing Enterprise Data Model widely used across the organization.

Anypoint Platform

1. Anypoint Platform control plane
1. MuleSoft hosted: US East (N.VA) or  EU (Frankfurt)
2. Customer hosted: Private Cloud Edition
2. Anypoint Platform runtime plane
1. CloudHub ( US East, US West, Canada, Asia Pacific, EU (Frankfurt, Ireland, London, …), South America); EU (Frankfurt and Ireland)
2. Customer-hosted: 
1. Manually provisioned - bare metal, VMs, on-premises, in a public or private cloud
2. iPaaS-provisioned - 
1. Mulesoft provided s/w appliance - Anypoint Runtime Fabric, 
2. customer- managed - Anypoint Platform for Pivotal Cloud Foundry

1. Anypoint Runtime Fabric is a software appliance that provides customer-hosted iPaaS functionality comparable to CloudHub. It leverages a Kubernetes cluster to do so, and executes Mule applications on Mule runtimes within Docker containers
2. Connection to control plane is via AMQP/TLS initiated by Anypoint Runtime Fabric
3. By default, Anypoint Platform does not act as an Identity Provider for OAuth 2.0 Client Management; Anypoint Platform supports the configuration of multiple Identity Providers for Client Management

Publishing APIs

1. Anypoint Platform provides two main features for making the documentation for an API engaging: API Notebooks and API  Consoles
2. Every change to the content of that API specification triggers an asset version increase in the corresponding Anypoint Exchange entry. This behavior is consistent with the fact that Anypoint Exchange is also a Maven-compatible artifact repository - storing, in this case, a RAML definition
3. The API Notebook for an API makes use of the API specification for that API and provides an interactive JavaScript-based coding environment that can be used to document interactions with the API from the point of view of an API client
4. Anypoint API Community Manager allows an organization to build and operate API consumer communities around their APIs, addressing both internal and external developers (partners). Anypoint API Community Manager provides customization, branding, marketing, and engagement capabilities

API Management - Policies

1. An API policy consists of a template (code) and definition (data) and its enforcement requires a Mule runtime, which provides this function. Enforcement can either be performed embedded in an API implementation itself (if it is a Mule application), or via a separate API proxy (a dedicated Mule application), or through Anypoint Service Mesh (via a dedicated Mule application deployed to the same Kubernetes cluster as the API implementations).
2. API policies are downloaded at runtime from Anypoint API Manager into the Mule application that enforces them
3. External API implementations deployed to a Kubernetes cluster can use Anypoint Service Mesh as an add-on to the Kubernetes cluster
4. API clients continue sending API invocations to the Kubernetes service representing a given API implementation: Istio/Envoy transparently intercepts all API invocations to/from an API implementation and routes them to the Mule runtime/Mule application performing API policy enforcement
5. API proxies are well-suited for coarse-grained APIs, where the addition of a separate node - the API proxy - into the HTTP request-response path between API client and API implementation does not constitute significant overhead
6. An API instance is an entry in Anypoint API Manager that represents a concrete API endpoint for a specific major version of an API in a specific environment 
7. Automated policies - apply to all API instances in a given environment
8. API Groups - that bundle API instances and streamline some API management tasks common to the group; Administrators can apply SLA tiers to the entire group of API instances;  API policies cannot be applied to API Group instances
9. API Group instances bundle several API instances for the main benefit of enabling API consumers to request access for a particular API client to the group and thereby gain access to each API instance in that group
10. The API policy caches entire HTTP responses, incl. the HTTP response status code, HTTP response headers and the HTTP response body. There is a size limit for cached HTTP responses (1MB)
11. Spike Control API policy must protect the backend system from temporary API invocation bursts by evening them out and enforces the published overall throughput guarantee - X-RateLimit- HTTP response headers should not be exposed to API clients from this API policy but from the SLA-based API policy
12. In the case of security-related API policies, RAML has specific support through securitySchemes, e.g. of type OAuth 2.0 or Basic Authentication. In other cases, RAML traits are a perfect mechanism for expressing the changes to the API  specification introduced by the application of an API policy
13. Edge policies supported by Anypoint Security 
1. Content Attack Prevention (CAP) 
2. Allowlisting of API client IP addresses 
3. Web Application Firewall (WAF) 
4. DoS attack prevention 
14. Tokenization replaces sensitive information (credit card number, SSN, account number, any regex, …) with a reversible token

Enterprise, Bounded Context Data Models

1. In an Enterprise Data Model - often called Canonical Data Model, but the discussion here uses the term Enterprise Data Model throughout - there is exactly one canonical definition of each data type, which is reused in all APIs that require that data type, within an organization
2. In a Bounded Context Data Model several Bounded Contexts are identified within an organization by their usage of common terminology and concepts. Each Bounded Context then has its own, distinct set of data type definitions - the Bounded Context Data Model. The Bounded Context Data Models of separate Bounded Contexts are formally unrelated, although they may share some names. All APIs in a Bounded Context reuse the Bounded Context Data Model of that Bounded Context
3. If there is no successful Enterprise Data Model, it is most pragmatic to use Bounded Context Data Models
4. If there is a successful Enterprise Data Model, then all Process APIs and System APIs should reuse that Enterprise Data Model as much as possible
5. The API data model of Experience APIs, on the other hand, is determined by the needs of the top-level API clients (such as user-visible apps) and thus is very unlikely to be served by an Enterprise Data Model
6. Start with the organizational structure, aiming for structural units where important business concepts are used in a coherent and homogenous way; If in doubt prefer smaller Bounded Contexts; If still in doubt put each API in its own Bounded Context
7. A Bounded Context Data Model should be published as RAML fragments (RAML types, possibly in a RAML Library) in Anypoint Design Center and Anypoint Exchange, so that it can be easily re-used in all APIs in a Bounded Context
8. The approach to mapping between Bounded Context Data Models is called anticorruption layer
9. Both the CloudHub Object Store  as well as an external database keep state outside the nodes (CloudHub workers) to which the API implementation is deployed and therefore do not make the API implementation stateful in the above sense
10. If, however, state is kept in local memory or on disk on a node, or in-memory replicated amongst nodes (these are also options with Object Stores, where the latter is not available in CloudHub) then the API implementation is stateful 
11. Safe HTTP methods are ones that do not alter the state of the underlying resource. 
1. GET
2. HEAD
3. OPTIONS
12. REST API headers used for caching: (Cacheable trait in RAML fragment)
1. Cache-Control
2. Last-Modified
3. ETag 
4. If-Match, If-None-Match, If-Modified-Since 
5. Age
13. HTTP-based optimistic concurrency control
1. ETag HTTP response header to send a resource version ID in the HTTP response from the API implementation to the API client
2. If-Match HTTP request header to send the resource version ID on which an update is based in an HTTP PUT/POST/PATCH request from API client to API implementation 
3. HTTP 412 Precondition Failed client error response code to inform the API client that the resource version ID it sent was stale and hence the requested change not performed 
4. HTTP 428 Precondition Required client error response code to inform the API client that the resource in question is  protected against concurrent modification and hence requires If-Match HTTP request headers, which were however missing from the HTTP request

API Implementation

1. API implementations developed as Mule applications and deployed to a Mule runtime (this includes API proxies) should always be configured to participate in auto-discovery
2. The API implementation by default refuses API invocations until all API policies have been applied. This is called the gatekeeper feature of the Mule runtime
3. Default configuration - Shared Cloudhub VPC
4. Firewall rules (AWS Security Groups, a form of stateful firewall) of the CloudHub Shared Worker Cloud are fixed:
1. TCP/IP traffic from anywhere to port 8081 (HTTP) and 8082 (HTTPS) on each CloudHub worker 
2. TCP/IP traffic from within the AWS VPC to port 8091 (HTTP) and 8092 (HTTPS) on each CloudHub worker
5. Custom Anypoint VPC
6. Every CloudHub worker receives a private IP address from the address range of its VPC - be it an Anypoint VPC or the CloudHub Shared Worker Cloud. A well-known DNS record resolves to those private IP addresses
7. Anypoint Platform Architecture Application Networks
8. Every CloudHub worker also receives a public IP address that is NOT under the control of the Anypoint VPC admin. Again, a well-known DNS record resolves to these public IP addresses
9. Anypoint VPCs and Anypoint Platform environments can be in a many-to-many relationship
10. Anypoint VPCs cannot be peered with each other
11. The CloudHub Shared Load Balancer terminates TLS connections and uses its own server-side certificate
12. The upstream protocol for the VPC-internal communication between CloudHub Dedicated Load Balancer and CloudHub workers can be configured to be HTTPS or HTTP, i.e., can be different from the protocol used by the API client (unlike with the CloudHub Shared Load Balancer)
13. The state of an Object Store is (only) available to all workers of its owning Mule application Can be circumvented using the Object Store REST API 
1. Max TTL of 30 days
14. CQRS - Commands are formulated in the domain language of the Bounded Context and trigger writes 
1. Commands are typically queued and executed asynchronously
15. Queries are optimized for the API clients' exact needs (joining and aggregating data as needed) and execute synchronously

Production Deployment

1. Anypoint Platform has no direct support for "canary deployments", i.e. the practice of initially only directing a small portion of production traffic to the newly deployed API implementation
2. Promoting all supported parts of the Anypoint API Manager entry for an API instance does not copy API clients
3. The client ID/secret a given API client uses for accessing an API is, however, independent of the environment. That is, if the same API client has been granted access to an API instance in the Sandbox and Production environments, it must make API invocations to both API endpoints with the same client ID/secret
4. So, create a new API client and request access so it gets a new set of clientId/secrets for production

Testing

1. Integration test - There should not be a single interaction in the API Notebook of an API that is not covered by a test scenario
2. A safe sub-set of integration tests can also be run in production as a "deployment verification test suite"
3. With MUnit Anypoint Platform provides a dedicated unit testing tool that
1. is specifically designed for unit testing Mule application
2. can stub-out external dependencies of a Mule application
3. has dedicated IDE-support in Anypoint Studio
4. can be invoked from Maven builds using the MUnit Maven plugin
4. Resilience testing is the practice of disrupting the web of application network and asserting that the resulting inevitable degradation of the quality of all relevant services offered by/on the application network is within acceptable limits

Scaling Application Network

Vertical scaling - Different sizes of cloudhub workers

Horizontal scaling - Multiple cloudhub workers (max 8) - can be configured as autoscaling