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
  • API implementation and its relationship to the API specification
  • API client or consumer role in an API interaction
  • API invocation and the request-response exchange
  • API proxy as an intermediary between API clients and the backend
  • When to front an existing API with an API proxy

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

0/5

REST architectural style characteristics

Learn this concept
Unseen

SOAP web services and how they differ from REST

Learn this concept
Unseen

GraphQL query model and benefits over REST

Learn this concept
Unseen

AsyncAPI and event-driven API classification

Learn this concept
Unseen

Choosing an API style for an integration requirement

Learn this concept
Unseen
  • 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

Choosing an API style for an integration requirement

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 conceptEnterprise application classes by business function

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
Choosing an API style for an integration requirement

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 conceptEnterprise application classes by business function

Explainer

An API style, or architectural style, is the pattern an API follows to let systems exchange data. Picking the right style means matching it to what the integration needs to do, so the choice is driven by the use case, the systems involved, and the functions required. The common styles are REST, RPC (which includes SOAP, GraphQL, and gRPC), and event-driven or streaming APIs.
Core information
  • Choosing an API involves several decisions: its intended use case, who will use and access it, and which systems and datasets it connects. When the API needs certain functional capabilities, pick the architectural style that best supports its intended use. More technical teams usually make this design decision.
More details and nuances
  • RPC is protocol-agnostic, so it can run on many protocols, but it loses native protocol features such as caching. Procedure names are non-standard and differ from one RPC API to the next, which ties consumers and providers more tightly together and adds work for developers. REST, by contrast, separates consumer concerns from provider concerns.

Explainer

An API style, or architectural style, is the pattern an API follows to let systems exchange data. Picking the right style means matching it to what the integration needs to do, so the choice is driven by the use case, the systems involved, and the functions required. The common styles are REST, RPC (which includes SOAP, GraphQL, and gRPC), and event-driven or streaming APIs.
Core information
  • Choosing an API involves several decisions: its intended use case, who will use and access it, and which systems and datasets it connects. When the API needs certain functional capabilities, pick the architectural style that best supports its intended use. More technical teams usually make this design decision.
More details and nuances
  • RPC is protocol-agnostic, so it can run on many protocols, but it loses native protocol features such as caching. Procedure names are non-standard and differ from one RPC API to the next, which ties consumers and providers more tightly together and adds work for developers. REST, by contrast, separates consumer concerns from provider concerns.