1. Introducing application networks and API-led connectivity
Companies today need to rapidly adopt and develop new tecnologies in order to stay relevant to customers & keep competitive
IT needs to be able to repidly integrate resources and make them available for consumption
An API-led connectivity approach can help achieve this
To drive API-led connectivity, create a C4E (Center for Enablement)
A cross-functional team to ensure assets across the organization are productized, published, and widely consumed
An application network is a network of applications, data, and devices connected with APIs to make them pluggable and to create reusable services
A web service is a method of communication that allows two software systems to exchange data over the internet
An API is an application programming interface that provides into for how to communicate with a software component
The term API is ofter used to refer to any part of a RESTful web service
The web service API(definition or specification file)
The web service interface implementing the API
The web service implementation itself
A proxy for the web service to control access to it
RESTful web services use standard HTTP protocal and are easy to use
The HTTP request method indicates which operation should be performed on the object identified by the URL
2. Introducing Anypoint Platform
Anypoint Platform is a unified, hybrid integration platform that creates a seamless application network of apps, data, and devices with API-led connectivity
Use Anypoint Exchange as a central repository for assets so they can be discovered and reused
Populate it with everything you need to build your integration projects
Use Flow Designer to build integration applications
These are Mule 4 applications that are deployed to a Mule runtime
Mule runtimes can be MuleSoft-hosted in the cloud(CloudHub) or customer-hosted in the cloud or on-prem
DataWeave 2.0 is the expression language for Mule to access, query, and transform Mule 4 event data
3. Designing APIs
RAML is a non-proprietary, standards-based API description language spec that is simple, succinct, and intuitive to use
Data structure hierarchy is specified by indentation, not markup characters
Use API Designer to write API specifications with RAML
Documentation is auto-generated from a RAML file and displayed in an API console
A mocking service can be used in API console to test an API and return the example data specified in RAML
Make an API discoveralbe by adding it to your private Exchange
API portals are automatically created for the APIs with
Auto-generated API documentation
An API console that provides a way to consume and test an API
An automatically generated API endpoint that uses a mocking service to allow the API to be tested without having to implement it
API portals can be shared with both internal and external users
Selectively share APIs in your org’s private Exchange with other internal developers
Share APIs with external developers by creating and customizing a public portal from Exchange and specifying what APIs you would like to include in it
4. Building APIs
Anypoint Studio can be used to build Mule applications for integrations and API implementations
Two-way editing between graphical and XML views
An embedded Mule runtime for testing applications
Mule applications accept and process events through a series of event processors plygged together in a flow
Use the HTTP Listener as an inbound endpoint to trigger a flow with an HTTP reques
Use the Set Payload transformer to set the payload
Use the Database connector to connect to JDBC databases
Use DataWeave and the Transform Message component to transform message from one data type and structure to another
Create RESTful interfaces for applications
Manually by creating flows with listeners for each resource/method pairing
Automatically using Anypoint Studio and APIkit
Connect web service interfaces to implementations using the Flow Reference component to pass messages to other flows
Synchronize changes to API specifications between Anypoint Studio and Anypoint Platform using API Sync
5. Deploying and managing APIs
Deploy appliations to MuleSoft-hosted or customer-hosted Mule runtimes
CloudHub is the platform as a Service(Pass) component of Anypoint Platform
Hosted Mule runtimes(workers) on AWS
An API proxy is an application that controls access to a web service, restricting access and usage through the use of an API gateway
The API Gateway runtime controls access to APIs by enforcing policies
Is part of the Mule runtime but requires a separate license
Use API Manage to
Create and deploy API proxies
Define SLA tiers and apply runtime policies Anypoint Platform has out-of-the box policies for rate-limiting, throttling, security enforcement, and more SLA tiers defines # of requests that can be made per time to an API
Approve, reject, or revoke access to APIs by clients
Promote managed APIs between environments
Review API analytics
6. Accessing and modifing Mule events
The best way to view event data is to add breakpoints to a flow and use the Mule Debugger
Use the Logger component to display data in the console
Use the Set Payload transformer to set the payload
Use the properties view to set response data for an HTTP Listener and request data for an HTTP Request operation
Use the DataWeave language to write inline expressions in #[ ]
Use the Set Variable transformer to create variables
7. Stucturing Mule applications
Separate functionality into multiple applications to allow managing and monitoring of them as separate entities
Mule applications are Maven projects
A projects’s POM is used by Maven to build, report upon, and document a project
Maven builds an artifact(a Mule deployable archive JAR) from multiple dependencies(module JARs)
Separate application functionality into multiple configuration files for easier development and maintenance
Encapsulate golbal elements into their own separate configuration file
Share resources between applications by creating a shared domain
Define application properties in a YAML file and reference them as ${prop}
Application metadata is stored in application-types.xml
Create applications composed of multiple flows and subflows for better readability, maintenance, and reusability
Use a Flow Reference to call flows synchronously
Use the VM connector to pass event between flows using asynchronous queues
8. Consuming web services
To consume a web service, first look to see if it has a connecor in Anypoint Exchange
Easiest way to consume a web service
Connectors for APIs specifications added to Exchange are generated automatically by REST Connect
Use the HTTP Request operation to consume any REST web service
With or without URI parameters and query parameters
With or without a RAML definition
Use the Web Service Consumer connector to consume any SOAP web service
Use the Transform message component to pass arguments to SOAP web service
9. Controlling event flow
Use different routers and validators to control event flow
Use the Choice router to send an event to one route based on conditional logic
Use the Scatter-Gather router to send an event concurrently to multiple routes
A collection of all results is returned
Use DataWeave to flatten the collection
Use the Validation module to specify whether an event can proessed in a flow
10. Handling errors
An application can have system or messageing errors
System errors are thrown at the system level and involve no event
Occur during application start-up or when a connection to an external system fails
Non-configurable, but logs the error and for connections, executes any reconnection strategy
Messaging errors are thrown when a proble occurs within a flow
Normal flow execution stops and the event is passed to an error handler(if one is defined)
By default, unhandled errors are logged and propagated
HTTP Listeners return success or error responses depending upon how the error is handled
Subflows cannot have their own error handlers
Messaging errors can be handled ata various levels
For an application, by defining an error handler outside any flow and the configuring the application to use it as the default error handler
For a flow, by adding error scopes to the error handling section
For one or more processors, by encapsulating them in a Try scope that has its own error handling section
Each error handler can have one or more error scopes
Each specifies for what error type or condition for which it should be executed
An error is handled by the first error scope with a matching condtion
On Error Propagate rethrows the error up the execution chain
On Error Continue handles the error and then continues execution of the parent flow
11. Writing DataWeave transformations
DataWeave code can be inline, in a DWL file, or in a module of functions
The data model for a transformation can consist of three different types of data：objects， arrays，and simple literals
Many formates can be used as input and output including JSON, Java, XML, CSV, Excel, Flat File, Cobol Copybook, Fixed Width, and more
The DataWeave application/dw fomat can be used to test expression to ensure there are no scripting errors
Use the map function to apply a transformation function(a lambda) to each item in an array
A lambda is an anonymous function not bound to an identifier
When mapping array elements(JSON or JAVA) to XML, wrap the map function in {(…)}
DataWeave is a functional programming language where variables behave just like functions
Define global variables in the header with var
Assign them a constant or a lambda expression
Use fun directive to access lambdas assigned to variables as traditional functions
Define local variables in the body with do{}
The scope of the do statement defines the boundaries of local variables
Functions are packaged in modules
Functions in the Core module are imported automatically into DataWeave scripts
Use the import header directive to import functions in all other modules
Functions with 2 parameters can be called with 2 different syntas
Use the metadata format schema property to format #'s and dates
Use the type header directive to specify custom data types
Transform objects to POJOs using: as Object {class: “com.myPOJO”}
Use lookup() to get data by calling other flows
12. Triggering flows
Use watermarks to synchronize data across data stores
Use either manual or the automatic watermarking available for som connectors
Use the family of File, FTP, FTPS, and SFTP connectors to work with files and floders
Use the On Neew or Updated File listener to trigger flows when files are added, created, or updated
Use the connector’s automatic watermarking to determine if a file is new based on a creation or modification timestamp
Use the On Table Row listener when new records are added to a database table
Use the connector’s automatic watermarking to determine if the record is new
Use the Scheduler component to schedule flows to run at a certain time or frequency
Use a watermark to keep a persistent variable between scheduling events
Use the Object Store connector to persist and share a watermark(or other data) across flow executions
Use the JMS connector to publish and consume messages
Connect to any JMS messaging service that implements the JMS spec
13. Processing records
Use the For Each scope to process individual collection elements sequentially and return the original payload
Use the Batch Job scope(EE only) for complex batch jobs
Created especially for processing data sets
Splits messages into individual records and performs actions upon each record
Can have multiple batch steps and these can have filters
Record-level data is persisted across steps using variables
Can handle record level failures so the job is not aborted
The batch job returns an object with thw results of the job for insight into which records were processed or failed
