Cert++
  1. Home
  3. MuleSoft Integration Foundations

MuleSoft Integration Foundations

Checklist progressProgress

0/188Learned

MuleSoft Integration Foundations 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/188Learned

  • Common reasons IT integration projects fail
  • Point-to-point sprawl and data silos as integration failure causes
  • Defining the IT delivery gap
  • MuleSoft's approach to closing the IT delivery gap
  • MuleSoft Catalyst three pillars
  • Central IT versus line-of-business IT in the production-and-consumption model
  • Center for Enablement role in a production-and-consumption model
  • Center for Enablement versus traditional Center of Excellence
  • Waterfall versus Agile delivery methodologies
  • Core practices of agile project delivery
  • Scrum, Lean and Kanban as common Agile frameworks
  • MuleSoft Catalyst as an integration delivery methodology
  • DevOps principles and lifecycle phases for integration teams
  • Continuous integration practice and its benefits for Mule projects
  • Apache Maven, source control and reproducible builds for Mule apps
  • MUnit for automated testing of Mule applications
  • Automated deployment of Mule applications across environments
  • Continuous delivery versus continuous deployment
  • Product-centric versus project-centric API delivery
  • Stages of the product-centric API lifecycle and their sequence
  • Designing and simulating an API before implementation
  • Publishing a specification to Exchange for early consumer feedback
  • Implement stage activities from scaffolding to deployment
  • Manage stage activities after an API is deployed
  • API product owner and business stakeholder responsibilities
  • Integration architect role in solution design decisions
  • API designer versus integration developer responsibilities
  • Citizen integrator role and MuleSoft Composer
  • Center for Enablement staffing, setup and core team responsibilities

Distinguish between Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service

0/3

  • IaaS, PaaS and SaaS definitions and example offerings
  • Provider versus customer responsibilities across cloud service models
  • Choosing a cloud service model for a business need

Identify the types of virtualization, computing, and storage infrastructure required by enterprise systems and describe the principles of system scalability

0/5

  • Virtual machines, hypervisors and containers
  • Serverless computing as a compute model
  • Block, file and object storage types
  • Vertical versus horizontal scaling
  • Scalability versus elasticity in cloud infrastructure

Classify and describe common networking protocols used in system communication

0/3

  • Classifying common networking protocols by layer and purpose
  • HTTP versus HTTPS and the role of TLS
  • Matching a networking protocol to a communication requirement

Recognize the differences between common data formats (for example, XML, YAML, and JSON) used in transformations and configuration files

0/6

  • JSON structure and data types
  • XML elements, attributes and namespaces
  • YAML mappings, sequences and indentation
  • Choosing among JSON, XML and YAML for an integration use case
  • Data formats in Mule application configuration files
  • Format-to-format conversion in DataWeave transformations

Define and describe the core concepts of API and enterprise system security

0/8

  • Confidentiality, integrity and availability security goals
  • Authentication versus authorization in API security
  • Multi-factor authentication for user access
  • Common API credential mechanisms compared
  • OAuth 2.0 token-based delegated authorization
  • Encryption of data in transit versus at rest
  • Digital certificates, PKI and mutual TLS
  • Network perimeter controls for enterprise systems

Identify and describe the HTTP components that enable RESTful web services

0/6

  • Web services versus APIs
  • Anatomy of HTTP request and response messages
  • HTTP methods and the resource operations they perform
  • Resource URIs, URI parameters and query parameters
  • Content-Type versus Accept and other common HTTP headers
  • HTTP response status code classes and common codes

Define and correctly use the terms API implementation, API proxy, API interface, API client/consumer, and API invocation

0/6

API interface definition and its role in API terminology

Learn this concept
Unseen

API implementation and its relationship to the API specification

Learn this concept
Unseen

API client or consumer role in an API interaction

Learn this concept
Unseen

API invocation and the request-response exchange

Learn this concept
Unseen

API proxy as an intermediary between API clients and the backend

Learn this concept
Unseen

When to front an existing API with an API proxy

Learn this concept
Unseen

Identify and classify RESTful, SOAP, AsyncAPI, and GraphQL APIs

0/5

  • REST architectural style characteristics
  • SOAP web services and how they differ from REST
  • GraphQL query model and benefits over REST
  • AsyncAPI and event-driven API classification
  • Choosing an API style for an integration requirement
  • Enterprise application classes by business function
  • Systems of record, engagement and insight
  • SaaS applications versus on-premises enterprise systems
  • Characteristics of legacy and mainframe enterprise systems
  • Legacy versus modern integration approaches
  • Point-to-point integration tradeoffs
  • Centralized ESB and SOA integration tradeoffs
  • Modernizing legacy systems without rip-and-replace
  • Data silos and manual re-entry as integration business problems
  • One-way versus bidirectional data synchronization use cases
  • Data aggregation integration use case
  • Workflow and process automation integration use case
  • Orchestration and data processing integration use case
  • User interface integration use case
  • Decomposing a complex business problem into foundational integration use cases
  • ETL and ELT tools as an integration technology class
  • Enterprise service bus as an integration technology class
  • Integration platform as a service (iPaaS)
  • iPaaS versus full lifecycle API management
  • Purpose and families of integration design patterns
  • Criteria for matching integration technology to a use case
  • Messaging and event streaming for publish-subscribe use cases
  • Citizen integration and when to use MuleSoft Composer
  • Integration system primitives that make up an integration solution
  • Deconstructing an end-to-end business solution into its integration constituents
  • Deconstructing a solution into API-led layers and connectors
  • Request-reply interaction pattern
  • One-way (fire-and-forget) interaction pattern
  • Multicast interaction pattern
  • Batch interaction pattern
  • Stream interaction pattern
  • Synchronous versus asynchronous interaction tradeoffs
  • Choosing an interaction pattern for an integration requirement
  • Aggregation composition pattern
  • Orchestration composition pattern
  • Choreography composition pattern
  • Choosing a composition pattern for a business situation
  • Purpose of an API specification as an API contract
  • API specification languages and the API styles they describe
  • Design-first versus code-first API development
  • Benefits of a design-first, specification-driven approach
  • Mocking an API specification for early consumer validation
  • Reuse and implementation scaffolding from an API specification
  • Observability versus monitoring for integration solutions
  • Logs as an observability signal
  • Metrics as an observability signal
  • Distributed tracing as an observability signal
  • Anypoint Monitoring capabilities for integration observability
  • Choosing logs, metrics or traces for an integration troubleshooting need
  • Core components versus connectors as Mule app building blocks
  • Scheduler versus event-driven sources for starting a flow
  • Cloud, hybrid, and on-premises deployment models compared
  • Tradeoffs between cloud and on-premises deployment
  • Anypoint Platform deployment options mapped to cloud, hybrid, and on-premises
  • Monolithic application architecture characteristics
  • Microservices application architecture characteristics
  • Benefits of microservices compared with a monolith
  • Operational complexity and tradeoffs of microservices
  • Choosing monolithic versus microservices architecture
  • Anypoint Platform purpose and the application network
  • Integration benefits of a unified Anypoint Platform
  • Matching Anypoint components to design, build, deploy and manage needs
  • Anypoint Monitoring versus Anypoint Visualizer
  • Anypoint MQ versus Anypoint Object Store v2
  • Anypoint Connector purpose and benefits in Mule applications
  • Connectors for software applications versus databases versus protocols
  • Connector sources versus operations in a Mule flow
  • HTTP Listener versus HTTP Request in the HTTP Connector
  • Database Connector capabilities for relational databases
  • Salesforce Connector characteristics in Mule integrations
  • Anypoint Connector support categories and licensing
  • Control plane versus runtime plane in Anypoint Platform
  • Mule runtime engine and runtime services in the runtime plane
  • Benefits of separating the control plane from the runtime plane
  • CloudHub as a MuleSoft-hosted runtime option
  • CloudHub versus CloudHub 2.0
  • Anypoint Runtime Fabric as a customer-hosted runtime option
  • Hybrid standalone versus disconnected on-premises Mule runtimes
  • Runtime Manager as the console across deployment targets
  • Anypoint Platform Private Cloud Edition and when to use it
  • Control plane and runtime plane hosting combinations
  • Choosing MuleSoft-hosted versus customer-hosted deployment
  • RAML and OAS as API specification languages in Anypoint Platform
  • API Designer in Anypoint Design Center
  • Anypoint Studio uses and benefits for Mule application development
  • Anypoint Code Builder uses and benefits for integration developers
  • APIkit role in implementing APIs from specifications
  • DataWeave transformation language purpose and benefits
  • Maven-based CI/CD for building, testing and deploying Mule apps
  • Anypoint CLI and Anypoint Platform APIs for DevOps automation
  • Anypoint Exchange as a curated catalog of reusable assets
  • API specification asset types and their definition formats
  • API spec fragments versus API groups
  • Connectors as packaged connectivity assets in Exchange
  • Templates versus examples as integration starting points
  • Policy and ruleset assets for API governance
  • DataWeave libraries and custom assets in Exchange
  • API portals generated for API assets in Exchange
  • Sharing Exchange assets privately versus through a public portal
  • Anypoint Management Center role in monitoring and securing APIs
  • Anypoint API Manager purpose and benefits for API management
  • Role and benefits of an API proxy in API management
  • API policies applied through API Manager and their benefits
  • Anypoint Exchange for API discovery, sharing and reuse
  • API visibility with Anypoint Monitoring, API Functional Monitoring and Visualizer
  • Universal API Management goals and the API sprawl problem
  • Universal API Management lifecycle stages and their Anypoint products
  • Anypoint products across full lifecycle API development
  • Anypoint API Governance for API quality, security and conformance
  • API Experience Hub for engaging API consumers through portals
  • Anypoint Flex Gateway (Omni Gateway) versus Mule Gateway
  • API-led connectivity versus point-to-point integration
  • Purpose of System, Process and Experience API layers
  • Layer decoupling and change isolation in API-led architecture
  • Reuse of existing APIs to accelerate later projects
  • Application networks and composable API building blocks
  • Unified Anypoint Platform versus fragmented integration and API management tools

Prepare for the Exam

Play Today's Certle

Study Community

Ask questions and get the latest info from other MuleSoft Integration Foundations studiers.

Go to Discord
  1. MuleSoft Integration Foundations Checklist
  3. Recognize and interpret essential integration concepts and terminology

API invocation and the request-response exchange

Explainer

Learn More

Practice Question

Studying for this exam?

This is one of 188 concepts on the Salesforce MuleSoft Integration Foundations exam.

Looking for practice exams? Click below to try one!

Keep going

Next conceptAPI proxy as an intermediary between API clients and the backend

Checklist progress

0/188 (0%)

0 of 188 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 Integration Foundations studiers.

Go to Discord
Close
  1. MuleSoft Integration Foundations Checklist
  3. Recognize and interpret essential integration concepts and terminology
API invocation and the request-response exchange

Explainer

Learn More

Practice Question

Studying for this exam?

This is one of 188 concepts on the Salesforce MuleSoft Integration Foundations exam.

Looking for practice exams? Click below to try one!

Keep going

Next conceptAPI proxy as an intermediary between API clients and the backend

Explainer

An API lets one piece of software ask another for data or functionality, much like a user interface lets a person do the same. Every call is a two-part exchange: a client sends a request, and the other system sends back a response. Both sides must use a format they both understand.
Core information
  • An API works like a user interface built for software instead of humans. It gives other software an easy way to get data or functionality.
More details and nuances
  • A client does not always talk to the backend directly. With an API proxy in front of the API, the client application calls the proxy, and the proxy forwards the call to the backend API.

Explainer

An API lets one piece of software ask another for data or functionality, much like a user interface lets a person do the same. Every call is a two-part exchange: a client sends a request, and the other system sends back a response. Both sides must use a format they both understand.
Core information
  • An API works like a user interface built for software instead of humans. It gives other software an easy way to get data or functionality.
More details and nuances
  • A client does not always talk to the backend directly. With an API proxy in front of the API, the client application calls the proxy, and the proxy forwards the call to the backend API.