Cert++
  1. Home
  3. MuleSoft Platform Integration Architect

MuleSoft Platform Integration Architect

Checklist progressProgress

0/307Learned

MuleSoft Platform Integration Architect Study Checklist
  • Platform Administrator
  • Platform App Builder
  • Platform Foundations
  • Platform Developer
  • Platform Administrator II
  • Agentforce Sales Consultant
  • Agentforce Service Consultant
  • Platform Data Architect
  • Platform Development Lifecycle and Deployment Architect
  • Platform Identity and Access Management Architect
  • Platform Integration Architect
  • Platform Sharing and Visibility Architect
  • Heroku Architect
  • B2C Solution Architect
  • Experience Cloud Consultant
  • Agentforce Field Service and Operations Consultant
  • Agentforce Nonprofit Consultant
  • Data 360 Consultant
  • Omnistudio Consultant
  • CRM Analytics and Einstein Discovery Consultant
  • Platform User Experience Designer
  • Platform Strategy Designer
  • B2C Commerce Developer
  • JavaScript Developer
  • Omnistudio Developer
  • Platform Developer II
  • Marketing Cloud Engagement Administrator
  • Marketing Cloud Engagement Specialist
  • Marketing Cloud Engagement Consultant
  • Marketing Cloud Account Engagement Specialist
  • Marketing Cloud Next Consultant
  • Agentforce Sales Foundations
  • Business Analyst
  • Marketing Cloud Engagement Developer
  • Marketing Cloud Engagement Foundations
  • Agentforce Specialist
  • Agentforce Life Sciences Consultant
  • B2B Commerce Administrator AP
  • B2B Commerce Developer AP
  • Agentforce Communications AP
  • Agentforce Consumer Goods AP
  • Agentforce Financial Services AP
  • Agentforce Health AP
  • Agentforce Manufacturing AP
  • Public Sector Solutions AP
  • Revenue Cloud Consultant
  • MuleSoft Integration Foundations
  • MuleSoft Developer
  • MuleSoft Developer II
  • MuleSoft Platform Integration Architect
  • MuleSoft Platform Architect
  • Tableau Desktop Foundations
  • Tableau Data Analyst
  • Tableau Consultant
  • Tableau Server Administrator
  • Tableau Next Consultant
  • Tableau Architect
  • Slack Administrator
  • Slack Consultant
  • Slack Developer

Checklist progressProgress

0/307Learned

  • Classifying integration requirements as functional or non-functional
  • Non-functional requirements as drivers of architecture decisions
  • Anypoint Platform components across the API lifecycle
  • Design-first API specification workflow
  • Reusable API fragments and shared data types across specifications
  • Anypoint Exchange, API portals and cataloging for discovery and reuse
  • Managing API access and traffic with API Manager policies
  • API Autodiscovery versus API proxy for managing an API
  • Mule Gateway versus Omni Gateway for API management
  • API analytics and functional monitoring for managed APIs
  • API versioning across Exchange assets and API Manager instances
  • API Governance rulesets and conformance checks
  • Platform features for designing and managing event-driven APIs
  • Control plane versus runtime plane responsibilities
  • Choosing a control plane hosting option for data residency and compliance
  • MuleSoft Government Cloud deployment models
  • Anypoint Platform Private Cloud Edition for a fully customer-hosted platform
  • Choosing a runtime plane option by management model and built-in capabilities
  • CloudHub versus CloudHub 2.0 as the MuleSoft-managed runtime
  • Runtime Fabric versus Hybrid Standalone on customer infrastructure
  • Runtime Fabric shared responsibility model
  • Hybrid Standalone versus unregistered on-premises Mule runtimes
  • Hosting combinations of control plane and runtime plane
  • Control plane and runtime plane compatibility
  • Runtime region versus control plane data residency
  • Runtime behaviour when the control plane is unreachable
  • Distributed shared memory grid in a Mule runtime cluster
  • Active-active node processing, failover and load balancing in customer-hosted clusters
  • Mule runtime cluster prerequisites and node operations
  • Inbound source coordination in clustered versus unclustered scaled instances
  • Idempotency and redelivery state in clustered versus unclustered instances
  • Clusters versus server groups as Runtime Manager deployment targets
  • Performance and scalability trade-offs of clustering Mule runtimes
  • High availability and clustering across runtime plane deployment options
  • CloudHub 2.0 runtime cluster mode versus replica scale-out without clustering
  • Shared and durable state on CloudHub without a runtime cluster
  • Mule runtime cluster versus JMS queue, load balancer and shared-database HA designs
  • CloudHub deployment region, application domain and regional load balancer
  • Shared load balancer versus dedicated load balancer on CloudHub
  • Edge TLS, client certificates and allowlisting at the CloudHub ingress
  • Static IP addresses for allowlisting CloudHub applications
  • CloudHub 2.0 shared space versus private space networking
  • Anypoint VPC and private space firewall rules
  • Choosing VPN, VPC peering, Direct Connect or Transit Gateway
  • Keeping internal APIs off the public internet on CloudHub
  • Mule domain shared resources, sharing limits and benefits
  • Sharing one HTTP listener port across co-located Mule applications
  • When a Mule domain is justified versus per-application configuration
  • Domain class loading, inherited modules and resource export
  • Purpose and benefits of Mule 4 class-loading isolation
  • Making application dependencies visible to connectors through shared libraries
  • Shared libraries versus additional plugin dependencies
  • Exporting packages and resources from Mule artifacts
  • Reactive nonblocking execution and its effect on thread use
  • Event processor processing types and thread scheduling
  • UBER shared thread pool and runtime self-tuning
  • Thread pool tuning options across deployment targets
  • Mule event immutability in concurrent processing
  • Transactions and thread switching in the reactive engine

Create high-level integration architectures using API-led Connectivity

0/5

API-led connectivity versus point-to-point integration

Learn this concept
Unseen

System, Process and Experience API layer responsibilities

Learn this concept
Unseen

Isolating backend system changes behind System APIs

Learn this concept
Unseen

Experience APIs for a new consumer channel versus reusing existing APIs

Learn this concept
Unseen

When to simplify or collapse API-led layers

Learn this concept
Unseen

Create high-level integration architectures using web APIs and HTTP

0/5

  • Choosing a web API style: REST, SOAP, GraphQL or gRPC
  • HTTP method semantics, safety and idempotency
  • Authentication, authorization and HTTPS for web APIs
  • Caching HTTP API responses at the client, gateway or Mule layer
  • Fault-tolerant invocation of unreliable downstream APIs

Create high-level integration architectures using event-driven APIs and message brokers

0/8

  • Event-driven architecture components and producer-consumer decoupling
  • When event-driven architecture fits versus synchronous request-reply
  • Point-to-point queues versus publish-subscribe fan-out
  • Broker-based buffering between producers and slow or unavailable consumers
  • Choosing VM queues, Anypoint MQ, a JMS broker or Kafka for messaging
  • Orchestration versus event-driven choreography for coordinating APIs
  • AsyncAPI contracts and APIkit for AsyncAPI implementations
  • Salesforce Platform Events and Change Data Capture in Mule event-driven designs

Design Mule applications and integration solutions using common messaging patterns and technologies

0/8

  • Enterprise Integration Patterns and their Mule 4 counterparts
  • Matching data and process integration patterns to requirements
  • Splitter and aggregator patterns in Mule 4 flows
  • Request-reply messaging over queues with publish-consume
  • Guaranteed delivery and consumer acknowledgment modes
  • Dead letter queues for undeliverable and poison messages
  • Message ordering with FIFO queues and concurrent consumers
  • JMS topic subscriptions in clustered and scaled Mule deployments
  • Configuration properties files in a Mule 4 application
  • System properties and environment variables as runtime property sources
  • Environment-specific property file selection with a placeholder
  • Secure Configuration Properties module for encrypted values
  • Mule property resolution hierarchy across property sources
  • Runtime Manager application properties versus bundled property files
  • CloudHub reserved properties and HTTP listener port placeholders
  • Mule event structure and variable propagation
  • DataWeave expressions and Mule runtime functions in flows
  • Flows versus subflows and Flow Reference
  • Modularizing Mule configuration files
  • Target variables for content enrichment
  • For Each versus Parallel For Each scopes
  • When to use the Async scope
  • Mule 4 error types and operation error mappings
  • On Error Propagate versus On Error Continue
  • Try scope for localized error handling
  • Scheduler source behaviour across deployment targets
  • Choice router for content-based routing
  • Scatter-Gather fan-out and aggregated result handling
  • Round Robin router for distributing events across routes
  • First Successful router versus Until Successful scope for failover
  • Mapping enterprise integration routing patterns to Mule 4 components
  • Salesforce API coverage of the Salesforce Connector
  • Salesforce Connector authentication and connection types
  • Bulk API versus record operations for Salesforce data writes
  • Invoking custom Apex logic through Apex REST and Apex SOAP
  • Salesforce Connector streaming event sources
  • Replaying missed Salesforce events after subscriber downtime
  • Salesforce integration patterns with the Salesforce Connector
  • Connectors, modules and core components as versioned dependencies
  • Global connector configurations and connection providers
  • Connection pooling and connectivity testing in connector configurations
  • Connector sources versus connector operations in flow design
  • Polling connector sources with watermarking and scheduling strategies
  • File, FTP and SFTP new-file pickup and post-read handling
  • HTTP Request timeouts and response status validation
  • Database connector bulk operations and parameterized queries
  • JMS connector acknowledgment modes and topic subscriptions
  • Metadata sources available to the Transform Message component
  • Defining metadata for components that do not expose it
  • Reusable custom metadata types in a Mule project
  • Reader and writer configuration for Transform Message formats
  • Metadata needs of the graphical mapper versus script-only DataWeave
  • Canonical data model versus point-to-point data translation
  • Canonical data models across Experience, Process and System API layers
  • Publishing canonical data types as reusable Exchange assets
  • Mapping between system-specific and canonical formats with DataWeave
  • Enterprise-wide canonical model versus bounded-context data models
  • Validation Module validators and their failure behaviour
  • Validation Module All scope versus individual validators
  • JSON and XML schema validation of message payloads
  • Request validation against an API specification with APIkit
  • Filtering invalid messages: validators with error handling versus Choice routing
  • MUnit suite structure and Behavior, Execution and Validation scopes
  • Running, debugging and reading MUnit tests in Anypoint Studio
  • Isolating a flow under test with Mock When
  • Spy, Verify Call and assertion processors for validating behaviour
  • Before and After Suite versus Before and After Test scopes
  • Enabling flow sources for listener- and scheduler-triggered flows
  • Testing error-handling paths in MUnit
  • Parameterized MUnit test suites
  • MUnit database and FTP server utilities for portable tests
  • Controlling MUnit test runs with tags, ignore and timeouts
  • MUnit coverage in Studio versus Maven coverage enforcement
  • Test Recorder versus APIkit test-suite scaffolding
  • Designing Mule applications for testability
  • Unit versus integration versus functional tests for Mule applications
  • Integration test environments, data state and endpoint configuration
  • Choosing load, stress, spike, soak or scalability testing
  • Performance test prerequisites and success criteria for Mule applications
  • Performance test environment design on CloudHub versus customer-hosted Mule
  • Component isolation and representative workloads in performance tests
  • VM Connector operations and message sources
  • Transient versus persistent VM queue trade-offs
  • Serialization requirements for persistent VM queue payloads
  • Persistent VM queue storage on a single runtime versus a Mule runtime cluster
  • VM queues for work distribution across Mule runtime cluster nodes
  • Inter-application messaging with VM queues and Mule domains
  • CloudHub persistent queues for durability across workers and restarts
  • Delivery semantics and duplicate messages with CloudHub persistent queues
  • Durable queueing options on CloudHub 2.0 and Runtime Fabric
  • Transactions with VM Connector listeners and operations
  • Reliability pattern with persistent VM queues
  • Choosing VM queues versus flow references, Anypoint MQ, or JMS
  • Default, global and private object store scoping
  • Persistent versus transient object stores
  • Object Store Connector operations and key-handling options
  • Entry TTL, max entries and expiration interval settings
  • Object store options for standalone on-premises and hybrid runtimes
  • Object stores in an on-premises Mule runtime cluster
  • Key-level locking and concurrent object store access across nodes
  • Object Store v2 versus local-disk object stores on CloudHub
  • Enabling and configuring Object Store v2 for CloudHub deployments
  • Object Store v2 TTL modes, partitions and data retention
  • Persistent object stores on Runtime Fabric with Persistence Gateway
  • Cross-application data sharing with Object Store v2 versus Anypoint MQ
  • Object stores versus databases for transactional or high-contention state
  • Mule components that keep state in an object store
  • Idempotent Message Validator object store design for duplicate rejection
  • Cache scope versus cache-aside caching with object stores
  • Redelivery policy counter storage in object stores
  • Watermark state persistence for incremental synchronization
  • OAuth token persistence in object stores for connectors
  • Aggregators module for stateful message aggregation
  • Stateful component state in clusters and multi-worker deployments
  • When to choose an alternative to local or XA transactions
  • At-least-once delivery with acknowledgements and idempotent receivers
  • Reliability pattern for non-transactional event sources
  • Reliable acquisition for socket-based versus resource-based sources
  • Choosing the reliability-pattern queue by deployment target
  • Until Successful scope retry behavior and exhaustion handling
  • Until Successful variable and payload state across retry attempts
  • Reconnection strategy options and deployment-time connection testing
  • Scope of reconnection strategies across sources, operations and error types
  • Redelivery policy for poison messages on message sources
  • Until Successful versus reconnection strategy versus redelivery policy
  • High availability versus disaster recovery
  • RTO and RPO in disaster recovery planning
  • Cold, warm, hot standby and active-active topologies
  • Sizing active-active, fault-tolerant and zero-downtime models to an SLA
  • MuleSoft versus customer HA and DR responsibilities by deployment model
  • Stateless design and externalized state for HA and DR
  • HA through multiple workers or replicas on CloudHub and CloudHub 2.0
  • Cross-region DR for CloudHub applications with load balancing
  • CloudHub 2.0 multiregion DR configurations by application impact and state
  • Region outage impact on control plane access and persisted state
  • Runtime Fabric HA replicas versus cluster backup and restore for DR
  • Mule runtime clustering for HA on Hybrid Standalone and on-premises runtimes
  • Single Resource versus XA transaction type selection
  • Transactional connector support and XA connection configuration
  • Starting a transaction at the event source versus a Try scope
  • Transactional actions for listeners, operations and Try scopes
  • Error handler outcomes for commit versus rollback in transactions
  • Scope and router behavior inside a transaction
  • Transactional publish and consume semantics on messaging connectors
  • Nested XA transactions with Try scopes
  • Bitronix transaction manager for XA recovery
  • Mule 4 self-tuning and tuning scope by deployment target
  • Backend response time as a throughput and scalability bottleneck
  • Flow and transformation design practices that reduce event overhead
  • Recursive flow references and iteration antipatterns
  • HTTP, HTTPS and APIkit configuration choices for performance
  • Connector pooling profiles for concurrent requests
  • Cache scope versus HTTP Caching policy for repeated lookups
  • Scatter-Gather and Async scope for reducing response latency
  • Back-pressure and maxConcurrency for protecting downstream systems
  • Spike Control versus Rate Limiting policies for capacity protection
  • Horizontal versus vertical scaling across deployment targets
  • Performance test criteria and capacity sizing
  • Performance test environment and execution practices
  • Repeatable versus non-repeatable streaming for flow throughput
  • File-stored versus in-memory repeatable stream strategies and buffer sizing
  • Object streaming, auto-paging and pagination for large result sets
  • Enabling DataWeave streaming with reader and deferred writer properties
  • Choosing For Each, Parallel For Each or Batch Job for large data sets
  • Batch Aggregator for grouped bulk operations
  • Batch step failed-record handling and job failure thresholds
  • Batch block size and concurrency tuning against memory and disk I/O
  • Aggregators module for grouping a stream of independent events
  • Queue-based load leveling and consumer scaling for high message volumes
  • Least-privilege control plane access with business groups, environments and teams
  • Federated SSO to Anypoint Platform with external identity providers
  • Access Management security settings for platform sign-in
  • Connected apps versus user credentials for programmatic platform access
  • Secure connectivity between customer-hosted runtimes and the control plane
  • Client applications, API contracts and SLA tiers for API consumers
  • Choosing API Manager policies for access control and threat protection
  • Client providers for external OAuth 2.0 authorization servers
  • Choosing an API policy enforcement point for Mule and non-Mule services
  • Gatekeeper protection during API deployment and restart
  • Anypoint Security layered edge protection model
  • Anypoint Security availability across deployment options
  • Choosing Anypoint Security Edge policies for threat scenarios
  • Edge security policies versus API Manager policies
  • Secrets Manager for TLS contexts and keystores
  • Inbound TLS termination and last-mile encryption on Runtime Fabric
  • Tokenization versus encryption for sensitive data
  • One-way versus mutual TLS for Mule HTTP listeners and requesters
  • Message-level encryption and signing versus transport-level TLS
  • Preventing injection and other OWASP Top 10 flaws in Mule flows
  • Protecting property values and the decryption key at deployment by runtime target
  • Mule runtime installation hardening on premises versus Runtime Fabric
  • Platform audit logs versus Mule application and runtime logs
  • Audit log entry contents and audited platform actions
  • Audit log access permissions and business group scoping
  • Audit log retention configuration for compliance requirements
  • Exporting audit logs to external SIEM and observability tools
  • Stages of a CI/CD pipeline for Mule applications
  • Mule Maven plugin goals and POM setup
  • MUnit tests and coverage gates in the CI build
  • Authenticating automated deployments to Anypoint Platform
  • Publishing application artifacts and API assets to Exchange from a pipeline
  • Choosing the Mule Maven plugin deployment strategy for each runtime target
  • Per-environment deployment settings in the Mule Maven plugin configuration
  • Promoting a tested artifact across environments without rebuilding
  • Anypoint Platform APIs for programmatic platform operations
  • Anypoint CLI capabilities and operating characteristics
  • Connected app grant types, scopes and allowlisting
  • Choosing among Maven plugin, Anypoint CLI, Platform APIs and Terraform for automation
  • Log4j 2 configuration resolution for Mule 4 applications
  • Logger categories and log levels in log4j2.xml
  • Asynchronous versus synchronous loggers in Mule applications
  • Built-in log viewing and search in Runtime Manager
  • Package-level log level changes across deployment targets
  • Forwarding CloudHub and CloudHub 2.0 logs to an external logging system
  • Runtime Fabric log forwarding versus external Log4j appenders
  • Logging design for hybrid and on-premises Mule runtimes
  • Centralized log aggregation across mixed deployment targets
  • Correlation IDs and MDC enrichment with the Tracing module
  • Anypoint Monitoring purpose and core capabilities
  • Runtime Manager monitoring versus Anypoint Monitoring
  • Enabling Anypoint Monitoring for CloudHub and CloudHub 2.0 apps
  • Anypoint Monitoring agent for hybrid servers, server groups and clusters
  • Anypoint Monitoring on Runtime Fabric
  • Built-in dashboards versus custom dashboards and custom metrics
  • Alerting options in Anypoint Monitoring and Runtime Manager
  • Anypoint Monitoring log management capabilities
  • API Functional Monitoring for scheduled endpoint checks
  • Distributed tracing of Mule app transactions
  • Subscription tier effects on Anypoint Monitoring features
  • Exporting monitoring data to external observability tools

Prepare for the Exam

Play Today's Certle

Study Community

Ask questions and get the latest info from other MuleSoft Platform Integration Architect studiers. 670 members and growing.

Go to Discord
  1. MuleSoft Platform Integration Architect Checklist
  3. Designing architecture using integration paradigms

Isolating backend system changes behind System APIs

Explainer

Learn More

Practice Question

Studying for this exam?

This is one of 307 concepts on the Salesforce MuleSoft Platform Integration Architect exam.

Looking for practice exams? Click below to try one!

Keep going

Next conceptExperience APIs for a new consumer channel versus reusing existing APIs

Checklist progress

0/307 (0%)

0 of 307 concepts learned

Tip: You can filter concepts by status.

Prepare for the Exam

Play Today's Certle

Study Community

Ask questions and get the latest info from other MuleSoft Platform Integration Architect studiers. 670 members and growing.

Go to Discord
Close
  1. MuleSoft Platform Integration Architect Checklist
  3. Designing architecture using integration paradigms
Isolating backend system changes behind System APIs

Explainer

Learn More

Practice Question

Studying for this exam?

This is one of 307 concepts on the Salesforce MuleSoft Platform Integration Architect exam.

Looking for practice exams? Click below to try one!

Keep going

Next conceptExperience APIs for a new consumer channel versus reusing existing APIs

Explainer

System APIs are the bottom layer of API-led connectivity. They connect directly to core systems of record, such as ERPs, CRMs and databases, and give every other API a stable, reusable way to reach that data. Consumers call the System API instead of the backend, so they are insulated from the backend's complexity and from changes to it.
Core information
  • API-led connectivity sorts APIs into three layers: System APIs, Process APIs and Experience APIs. Each layer is decoupled from the others, and each layer hides the complexity of the layer below it.
More details and nuances
  • Isolation makes it possible to replace a backend system. For example, a bank built a 'Get Accounts and Transactions' Process API on top of four System APIs (Core Bank Accounts, Loans, Credit Card and Auto Lease), one for each line of business. That design let the bank switch its core banking provider without significant upstream or downstream impact, a true plug-and-play architecture. It also let multiple providers co-exist during the transition without disrupting the business.

Explainer

System APIs are the bottom layer of API-led connectivity. They connect directly to core systems of record, such as ERPs, CRMs and databases, and give every other API a stable, reusable way to reach that data. Consumers call the System API instead of the backend, so they are insulated from the backend's complexity and from changes to it.
Core information
  • API-led connectivity sorts APIs into three layers: System APIs, Process APIs and Experience APIs. Each layer is decoupled from the others, and each layer hides the complexity of the layer below it.
More details and nuances
  • Isolation makes it possible to replace a backend system. For example, a bank built a 'Get Accounts and Transactions' Process API on top of four System APIs (Core Bank Accounts, Loans, Credit Card and Auto Lease), one for each line of business. That design let the bank switch its core banking provider without significant upstream or downstream impact, a true plug-and-play architecture. It also let multiple providers co-exist during the transition without disrupting the business.