Cert++
  1. Home
  3. MuleSoft Developer

MuleSoft Developer

Checklist progressProgress

0/232Learned

MuleSoft Developer 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/232Learned

Identify core architectural concepts of the Application Network and modern APIs

0/6

  • Application network definition and building blocks
  • Application network benefits and the IT challenges it addresses
  • API contracts, abstraction and benefits of using APIs
  • Characteristics of a modern API
  • RESTful versus SOAP web services as API styles
  • Anypoint Platform components for building an application network

Identify features of an API-led approach

0/4

Classifying APIs into System, Process and Experience layers

Learn this concept
Unseen

Key attributes of API-led connectivity

Learn this concept
Unseen

Change isolation and reuse across API-led layers

Learn this concept
Unseen

API-led connectivity versus point-to-point integration

Learn this concept
Unseen

Identify features of MuleSoft's recommended Operational Model

0/5

  • IT delivery gap and the production-consumption operating model
  • Center for Enablement role, staffing and expected benefits
  • Center for Enablement versus traditional Center of Excellence
  • C4E activities for publishing foundational assets and driving consumption
  • Metrics that measure C4E success and asset reuse

Apply correct processors / syntax and predict outcomes to consume RESTful web services (RAML-based) and predict outcomes

0/8

  • Testing REST calls with a REST client or the API Console
  • HTTP Request configuration versus Request operation settings
  • RAML URI parameters and query parameters in an HTTP Request
  • Dynamic HTTP Request paths built with DataWeave expressions
  • Custom request headers for consuming secured REST APIs
  • Mule event contents after an HTTP Request operation returns
  • HTTP Request error types for unsuccessful response status codes
  • Consuming a RAML-described API from Anypoint Exchange in Studio
  • HTTP method semantics for create, read, update and delete operations
  • Methods on collection resources versus individual item resources
  • RAML syntax for declaring resources, nested resources and methods
  • Required versus optional parameters in RAML 1.0
  • RAML request header declarations on a method
  • HTTP status codes for REST API responses
  • RAML response declarations keyed by HTTP status code
  • Data types and examples in RAML request and response bodies
  • Mocking service responses generated from declared examples
  • Choosing URI parameters versus query parameters in REST API design
  • RAML syntax for declaring URI parameters on a resource
  • RAML syntax for declaring query parameters on a method
  • Request URLs that satisfy a RAML resource and parameter definition
  • Reading URI and query parameters from Mule event attributes
  • Mule event and Mule message composition
  • Set Payload value syntax and inline DataWeave expressions
  • Transform component set-payload structure and external scripts
  • Single-value, multi-value and descendants selectors on payloads
  • Index, range and selector modifiers on payload data
  • Payload changes as the event passes through processors
  • Attributes versus payload in the Mule message
  • HTTP Listener request attribute selectors
  • Selector syntax for header and attribute names with special characters
  • Attribute state after an outbound HTTP Request or File operation
  • Setting attributes with the Transform component
  • Set Variable component configuration and value syntax
  • Reading Mule variables with the vars keyword in DataWeave
  • Setting variables in a Transform Message component
  • Preserving the original payload or attributes in a variable
  • Creating, updating and removing Mule variables
  • Variable visibility across Flow Reference calls
  • Connector operation targets and the message passed downstream
  • Target Value expressions for connector targets
  • Mule project folder structure and file purposes
  • Encapsulating global elements in a separate configuration file
  • Imported versus side-by-side loading of multiple configuration files
  • Configuration Properties global element and properties file formats
  • Property placeholder syntax for YAML and .properties keys
  • Reading configuration properties inside DataWeave expressions
  • Environment-specific properties files selected through an env property
  • Property value precedence across files, global, system and deployment properties
  • Flows, private flows and subflows compared
  • Payload and variable changes returned from a referenced flow or subflow
  • Flow Reference target and targetValue configuration
  • Error behaviour when a referenced flow or subflow fails
  • VM connector versus Flow Reference for passing events between flows
  • Variable and attribute persistence across connector boundaries
  • Hand-built HTTP Listener flows for spec resources and methods
  • Importing an API specification to scaffold a new Mule project
  • Hand-built REST interfaces versus APIkit-scaffolded interfaces
  • APIkit for REST versus APIkit for SOAP scaffolding
  • Components APIkit scaffolds from a RAML specification
  • APIkit module XML: apikit:config, router and flow mappings
  • Naming convention of APIkit-generated backend flows
  • Request URLs and parameter values reaching APIkit backend flows
  • Responses from scaffolded flows before implementation
  • APIkit Router request validation against the RAML contract
  • Requests that trigger each APIkit Router error type
  • Generating and regenerating APIkit flows from an updated RAML
  • Replacing scaffolded mock flows with implementation logic
  • Returning the status codes and headers a RAML response declares
  • Scaffolded APIkit error handlers and the error responses they build
  • Database Config connection types and JDBC driver setup
  • Parameterized Database queries with input parameters
  • Select operation result structure and downstream access
  • Insert, Update and Delete operation outputs
  • Database operation error types
  • File, FTP and SFTP connectors and their shared operation set
  • File and FTP connector global configuration and working directory
  • Read operation syntax: path, MIME type, encoding and lock
  • Read operation result: payload, file attributes and source file
  • Write operation modes and dynamic file path syntax
  • Mule event after a File or FTP Write operation
  • List operation output and iterating listed files
  • Copy, Move, Rename and Delete operation outcomes
  • On New or Updated File source polling and post-processing options
  • Connector operations versus event sources for mid-flow retrieval
  • Mule event state after a mid-flow connector operation
  • Combining stored lookup results with the current payload
  • SOAP web service calls mid-flow with Web Service Consumer
  • For Each collection expression and element splitting
  • Payload inside versus after a For Each scope
  • For Each counter and root message variables
  • Variable changes across For Each iterations and after the scope
  • For Each batch size and sub-collection payloads
  • Error handling when a For Each element fails
  • For Each versus Parallel For Each
  • Batch job instance phases and what happens in each
  • Batch job XML structure and component nesting
  • Valid batch job input and the implicit record split
  • Record payload, variables and attributes inside batch steps
  • Batch step filtering with acceptExpression and acceptPolicy
  • Batch aggregator fixed size versus streaming
  • Failed records and the maxFailedRecords threshold
  • On Complete report and what the flow sees after the batch job
  • Choosing batch processing versus For Each and Parallel For Each
  • On Table Row listener events and per-row payload
  • On Table Row listener configuration and watermark settings
  • Object Store versus flow variables for state across flow executions
  • Object Store connector store and retrieve operation syntax
  • Persistent versus transient object stores and Object Store v2
  • Cache scope behaviour for repeated requests
  • Script header, output directive and inline DataWeave expressions
  • Default output type when the output directive is omitted
  • DataWeave data types, literal syntax and typeOf
  • Type coercion with the as operator
  • Parsing and serializing strings with read and write
  • JSON-to-XML conversion and XML output structure
  • map lambda parameters and the `$` and `$$` shorthand
  • mapObject versus map for object inputs
  • pluck for turning an object into an array
  • Array reshaping with flatten, flatMap and distinctBy
  • Concatenation and removal with `++` and `--`
  • Core string functions for splitting, joining, casing and replacing
  • Core numeric and aggregate functions
  • groupBy result structure
  • reduce accumulator initialization and iteration
  • log function for debugging DataWeave expressions
  • Key, multi-value, descendants and XML attribute selectors
  • Index, range and filter selectors on arrays
  • Filtering arrays with the filter function
  • Filtering object key-value pairs with filterObject
  • Sorting arrays and objects with orderBy
  • Conditional fields and if/else expressions in output
  • Number formatting with format and locale properties
  • Parsing and reformatting date and time strings
  • Custom DataWeave types for reusable formatting
  • Implicit coercion in comparison and equality operators
  • Chaining filter, orderBy, and map in a single expression
  • lookup function syntax for invoking a flow from DataWeave
  • Payload passed to and returned from a flow called with lookup
  • lookup function versus Flow Reference for calling flows
  • Global header variables versus local do-scope variables in DataWeave
  • DataWeave script variables versus Mule event variables
  • Declaring and calling custom DataWeave functions with fun
  • Lambdas in variables and functions passed as arguments
  • Custom DataWeave module file contents and project location
  • Import directive forms and calling functions from imported modules
  • Reusing DataWeave mapping files through the main function
  • Choice router XML structure and route configuration
  • Choice router route selection order and the default route
  • DataWeave when conditions on payload, attributes, and variables
  • Routing conditions on missing keys and null values
  • Mule event state after the Choice router completes
  • Choice router for content-based routing versus other routers
  • Scatter-Gather parallel route execution and event handoff
  • Scatter-Gather aggregated result structure
  • DataWeave expressions for combining Scatter-Gather route payloads
  • Variable propagation across Scatter-Gather routes
  • Scatter-Gather behaviour when a route fails or times out
  • Accessing route results and failures in a Scatter-Gather error handler
  • Scatter-Gather versus Parallel For Each for parallel processing
  • Validation module operations, scopes and XML syntax
  • Flow outcome when a validator passes or fails
  • Validator error types, custom messages and on-error matching
  • Validation module versus Choice router for rejecting invalid events
  • Defining and referencing a global error handler
  • Application default error handler in the global configuration element
  • Reusing named global On-Error components
  • Error handler and On-Error component XML structure and attributes
  • On Error Continue versus On Error Propagate effect on the owning flow or scope
  • HTTP Listener response when a flow error is continued versus propagated
  • Default error handling when no error handler is configured
  • Error object expressions inside an On-Error handler
  • Error type lists, ANY and the type hierarchy in On-Error matching
  • On-Error when conditions for expression-based error matching
  • On-Error component evaluation order within one error handler
  • Errors that no On-Error component matches
  • Error propagation across Flow Reference calls to child flows and subflows
  • Try scope XML structure and its embedded error handler
  • Flow execution after On Error Continue handles an error in a Try scope
  • On Error Propagate inside a Try scope and the enclosing flow's handler
  • Payload and variable changes across a Try scope boundary
  • Try scope versus a separate flow or subflow for isolating errors
  • Custom error type namespaces and identifiers
  • Raise Error component for custom error types
  • Error mapping syntax on connector operations
  • Handler matching for operation errors mapped to custom types
  • System errors versus messaging errors
  • Running a Mule app in Anypoint Studio debug mode with breakpoints
  • Inspecting the Mule event at a breakpoint in the Mule Debugger view
  • Reading Mule error log entries to locate the failing processor
  • Logger component messages, expressions and log levels
  • Error object selectors for logging and diagnosis
  • Default error handling and the HTTP Listener response to a failed request
  • Tracing an error through On-Error matching to the flow result
  • Root causes of failing DataWeave expressions
  • Verbose connector logging and stack trace detail
  • Ways to deploy a Mule application to CloudHub
  • CloudHub application names and public domain URLs
  • HTTP Listener host and port configuration for CloudHub deployment
  • CloudHub worker size and worker count
  • Deploy-time application properties versus properties files
  • Redeploying and updating a running CloudHub application
  • CloudHub deployment prerequisites and failed deployments
  • API proxy versus API autodiscovery for managing an API
  • API autodiscovery global element configuration
  • Pairing a Mule application with an API Manager instance
  • Creating and deploying an API proxy from API Manager
  • Request path and policy enforcement through a deployed API proxy
  • API Manager metrics for usage, performance and policy violations
  • Purpose and enforcement point of API Manager policies
  • Prerequisites for applying policies to a Mule application
  • Applying and upgrading a policy in API Manager
  • Client ID enforcement policy and consumer credentials
  • Rate limiting versus spike control policy behaviour
  • SLA tiers with the SLA-based rate limiting policy
  • Choosing an API policy for an access or traffic requirement
  • API-wide versus resource-level policy application

Prepare for the Exam

Play Today's Certle

Study Community

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

Go to Discord
  1. MuleSoft Developer Checklist
  3. Creating Application Networks

Change isolation and reuse across API-led layers

Explainer

Learn More

Practice Question

Studying for this exam?

This is one of 232 concepts on the Salesforce MuleSoft Developer exam.

Looking for practice exams? Click below to try one!

Keep going

Next conceptAPI-led connectivity versus point-to-point integration

Checklist progress

0/232 (0%)

0 of 232 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 Developer studiers.

Go to Discord
Close
  1. MuleSoft Developer Checklist
  3. Creating Application Networks
Change isolation and reuse across API-led layers

Explainer

Learn More

Practice Question

Studying for this exam?

This is one of 232 concepts on the Salesforce MuleSoft Developer exam.

Looking for practice exams? Click below to try one!

Keep going

Next conceptAPI-led connectivity versus point-to-point integration

Explainer

API-led connectivity organizes APIs into three layers: System, Process, and Experience. Each layer has one job. Because the layers are decoupled, a change in one layer, such as replacing a backend system, does not ripple into the others. Each layer also produces reusable building blocks, so new apps can be built by reusing existing APIs instead of starting from scratch.
Core information
  • API-led connectivity spans three layers: System APIs, Process APIs, and Experience APIs. Each layer serves a specific purpose, and the layers are decoupled from one another. The style works like microservices: small, isolated services instead of one monolithic API, which reduces dependencies.
More details and nuances
  • Keeping business logic out of the system layer is what makes System APIs valuable. Because they only connect to systems, changes there stay contained and the same API stays reusable across applications. Business logic belongs in the process layer.

Explainer

API-led connectivity organizes APIs into three layers: System, Process, and Experience. Each layer has one job. Because the layers are decoupled, a change in one layer, such as replacing a backend system, does not ripple into the others. Each layer also produces reusable building blocks, so new apps can be built by reusing existing APIs instead of starting from scratch.
Core information
  • API-led connectivity spans three layers: System APIs, Process APIs, and Experience APIs. Each layer serves a specific purpose, and the layers are decoupled from one another. The style works like microservices: small, isolated services instead of one monolithic API, which reduces dependencies.
More details and nuances
  • Keeping business logic out of the system layer is what makes System APIs valuable. Because they only connect to systems, changes there stay contained and the same API stays reusable across applications. Business logic belongs in the process layer.