Anypoint Platform Development:
Production-Ready
Development Practices
Introductions
● Name
● Company & role
● Experience with Anypoint Platform Development
● What do you want to get out of this class?
All contents © MuleSoft Inc.
2
Introductions
● Class is typically from 09:00 to 17:00
● 1 hour lunch break, typically from 12:00 to 13:00
● 2 breaks each morning and afternoon
○ Other breaks as desired - just ask!
● Please let us know if you have other business to attend to
All contents © MuleSoft Inc.
Module
Welcome
3
Introducing this course
At the end of this course, you should be able to
● Understand and execute the fundamental API-related workflows in
Anypoint Platform
● Expose APIs from Mule apps over HTTPS
● Configure Mule apps succinctly and securely for different deployment
environments
● Automate, configure, and secure Mule app deployments to CloudHub
● Manage complex Maven dependency relationships of Mule apps
● Improve operational logging and monitorability of Mule apps
● Implement simple reusable libraries of Mule app code
All contents © MuleSoft Inc.
6
At the end of this course, you should be able to
● Unit-test successful and erroneous execution of Mule flows with
MUnit
● Structure MUnit test code and data for reuse and maintainability
● Run MUnit tests in Studio and as part of Maven builds
● Create Mule runtime domains sharing libraries and HTTP Listener
configurations for HTTPS endpoints
● Build and configure Mule apps for Mule runtime domains
All contents © MuleSoft Inc.
7
Course prerequisites
● Prior to attending this course
○ Anypoint Platform Development: Fundamentals (Mule 4)
○ Solid understanding of essential Maven concepts, as taught, for example, in
■ Apache Maven Tutorial
■ Maven in 5 Minutes
■ Maven Getting Started Guide
All contents © MuleSoft Inc.
11
Course outlines
● Module 1: Interactively Provisioning API-Related Artifacts
● Module 2: Applying Basic Software Engineering Principles
● Module 3: Automating Unit-Testing With MUnit
● Module 4: Sharing Resources Within Domains
All contents © MuleSoft Inc.
12
How the course will work
● Based around the AnyAirlines case study
● Walkthroughs developing aspects of this case study
● The Student Manual has all the details
All contents © MuleSoft Inc.
13
Section
Preparing for working with the
course material
Course material
● Available on MuleSoft Learning Management System
○ http://training.mulesoft.com/login.html
● Student Manual (PDF)
● Course slides (ZIP of PDFs)
All contents © MuleSoft Inc.
15
Module
The AnyAirline case study
Section 1
Requirements
AnyAirline use case
● AnyAirline is a regional airline and an existing MuleSoft customer
● Current MuleSoft landscape
○ MuleSoft-hosted Anypoint Platform control plane, and
○ a mixture of CloudHub and
○ customer-hosted Mule runtimes
● Supports a Mobile app and a few other, ad-hoc integrations
● Case study focuses on three use cases
All contents © MuleSoft Inc.
18
Requirements
● Pre-existent systems with which some integration is required, but
out-of-scope for this phase of solution design and implementation:
○ Mobile app - Native mobile app, the main strategic driver for this project
○ PayPal - For customer/passenger payments
○ Flights Management system
■ Accessible via SOAP web services over mutually authenticated HTTPS
■ Deployed on-premises in the AnyAirline data center
○ Passenger Data system
■ In-house legacy PostgreSQL database to be accessed directly
■ Deployed on-premises in the AnyAirline data center
All contents © MuleSoft Inc.
19
Domain terminology
● PNR (Passenger Name Record):
○ Contains personal information about a passenger, as well as their itinerary
■
i.e., flights
○ Itineraries consist of only one flight
■
thus each PNR identifies exactly one passenger and their flight
○ We do not deal with the PNRs themselves, just with Record Locators identifying
those PNRs
○ The term PNR is used to always mean “Record Locator referring to a
Passenger Name Record”
All contents © MuleSoft Inc.
20
User stories
● There is one user story in this course
○ US1: Mobile check-in
All contents © MuleSoft Inc.
21
US1: Mobile check-in
● As a passenger, I want to be able to check-in to an AnyAirline
flight using the mobile app, by providing my PNR and last name,
and pay for any baggage using Paypal
● Preconditions:
○ Passenger holds an AnyAirline ticket and knows the PNR
○ Passenger has a PayPal account
○ Passenger has the mobile app installed
All contents © MuleSoft Inc.
22
Non-functional requirements
● Non-functional requirements
○ NFR 1: Application components interacting directly with on-premises systems
(Flights Management, Passenger Data) must be deployed on-premises in the
AnyAirline data center. This applies, for instance, to System APIs
○ NFR 2: All application components interacting only with cloud-hosted
systems (PayPal, Salesforce) or APIs must be deployed to CloudHub
○ NFR 3: All data must be encrypted in flight (e.g. using HTTPS)
○ NFR 4: API-led connectivity should be followed unless performance
considerations suggest otherwise
All contents © MuleSoft Inc.
23
Section 2
Solution architecture
AnyAirline target architecture
All contents © MuleSoft Inc.
25
AnyAirline target architecture
All contents © MuleSoft Inc.
26
Deployment to production environment
● Deployment of Mule apps is to a mix of CloudHub and
customer-hosted Mule runtimes
○ Refer back to the high-level architecture
● Customer-hosted Mule runtimes are clustered for HA and have
domain-deployed Mule applications and domain-shared resources:
○ HTTP Listener configurations for exposing API endpoints and
○ Database configurations (incl. JDBC connection pools) for accessing the
Passenger Data system
All contents © MuleSoft Inc.
27
Deployment to production environment
● All Mule applications deployed to customer-hosted Mule runtimes are
associated with the same Mule runtime domain
○ Packaged and deployed as a Docker container to AWS ECS
● CloudHub deployments are to the public worker cloud in us-e1 (N.
Virginia) or us-e2 (Ohio) under the control of the MuleSoft-hosted
Anypoint Platform control plane in the US
All contents © MuleSoft Inc.
28