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
  • 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
  • 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
  • Classifying common networking protocols by layer and purpose
  • HTTP versus HTTPS and the role of TLS
  • Matching a networking protocol to a communication requirement
  • 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
  • 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
  • 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
  • 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
  • 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

Classify and describe the characteristics of common enterprise systems

0/4

  • 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

Classify and describe the tradeoffs of legacy and modern integration approaches

0/4

Legacy versus modern integration approaches

Learn this concept
Unseen

Point-to-point integration tradeoffs

Learn this concept
Unseen

Centralized ESB and SOA integration tradeoffs

Learn this concept
Unseen

Modernizing legacy systems without rip-and-replace

Learn this concept
Unseen

Given a complex business problem, identify the fundamental integration use cases that can deliver an end-to-end business solution

0/7

  • 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

Describe the purpose and function of the different classes of integration technologies

0/4

  • 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

Identify the types of integration technologies that are most suitable to realize different integration use cases and business scenarios

0/4

  • 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

Deconstruct an integration solution into its integration system constituents

0/3

  • 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. 670 members and growing.

Go to Discord
  1. MuleSoft Integration Foundations Checklist
  3. Recognize common integration problems, use cases, and technical solutions

Modernizing legacy systems without rip-and-replace

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 conceptData silos and manual re-entry as integration business problems

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. 670 members and growing.

Go to Discord
Close
  1. MuleSoft Integration Foundations Checklist
  3. Recognize common integration problems, use cases, and technical solutions
Modernizing legacy systems without rip-and-replace

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 conceptData silos and manual re-entry as integration business problems

Explainer

Legacy systems are older systems that were never designed to work together, so their data stays stuck in silos. Replacing them all at once can cause significant disruption. The modern approach is to keep them and connect them: wrap each one with APIs and connectors so the rest of the business can reuse its data, and replace it later when a better option becomes feasible.
Core information
  • Many organizations run IT architectures built over years, sometimes decades, that are full of silos. These systems were not designed to work together, so sharing data is hard, and keeping up with new technologies or business demands is slow.
More details and nuances
  • Quick fixes on top of legacy systems tend to deepen the problem. For example, utilities that added CRM systems, custom dashboards and 'super screens' (custom UIs that pull data from several legacy systems into one screen) ended up with more fragmentation, slow service, and teams stuck stitching data together.

Explainer

Legacy systems are older systems that were never designed to work together, so their data stays stuck in silos. Replacing them all at once can cause significant disruption. The modern approach is to keep them and connect them: wrap each one with APIs and connectors so the rest of the business can reuse its data, and replace it later when a better option becomes feasible.
Core information
  • Many organizations run IT architectures built over years, sometimes decades, that are full of silos. These systems were not designed to work together, so sharing data is hard, and keeping up with new technologies or business demands is slow.
More details and nuances
  • Quick fixes on top of legacy systems tend to deepen the problem. For example, utilities that added CRM systems, custom dashboards and 'super screens' (custom UIs that pull data from several legacy systems into one screen) ended up with more fragmentation, slow service, and teams stuck stitching data together.