MuleSoft Manchester Meetup #4 slides 11th February 2021

11 February, 2021
Manchester MuleSoft Meetup #4 (online)
Bobby James
Solution Architect
The Co-operative Bank
Francis Edwards
Integration Analyst
Saint-Gobain Building
Distribution
Justin Saliba
Solution Architect
EPAM (Ricston)

11/02/2021 – Bobby James
Manchester MuleSoft Meetup Group
‘I Hate Layers’
- A Presentation of Apologies

3
●About the presenter:
○ Mulesoft Solution Architect at the Co-Operative Bank
■ MuleSoft Certified Integration Architect - Level 1 Certificate
○ Barclays, API Design
○ 25 Year in IT
■ ‘Developer in an SA Cloak’
○ http://uk.linkedIn.com/in/drbobbyjames
Introductions
A SHOW OF HANDS:
Who is new to this Meetup?

API
●Application Programming Interface
○ Layer of Abstraction
○ RESTful / Stateless services
● From a MuleSoft Development Fundamentals (Mule 3)…
4

Layer Application Follies
● Application Architecture
● Statements Made
○ Every Layer has to be used
○ Semantics of Names
○ Unknown User, known application
○ Create Customer / Stateless API’s
■ the oxymoron
7

Message Integration Patterns
9

10
● Think
○ Functionality
■ Channel API (Consumer / Provider)
○ Layer of Abstraction
○ Security
○ Re-Use
○ Micro-Services-ish
● Define the API and then the Layer (and name) becomes self descriptive
“Imagine…..There’s no Layers It’s easy if you can”

All contents © MuleSoft, LLC
Evolving an App using API Led Design
Francis Edwards, Integration Analyst / Developer

Introduction
1. I’m an Integration Analyst / Developer, I create MuleSoft APIs and applications, deploying and
supporting them in on premise and cloud environment
2. I work for Saint-Gobain Building Distribution, the building materials, retail & wholesale arm of Saint-
Gobain in the UK
3. I enjoy playing rugby and swimming and perfecting my MuleSoft usage!
12
Francis Edwards, MuleSoft Ambassador

Agenda
● Show a simple workflow that is not API Led
● Demonstrate how this can be decomposed into the three layers of the API-Led Structure
● Make these APIs not just decomposed, but more RESTful & Reusable
● Outline the coding considerations required for each of the system, process & experience layers
● Highlight the benefits of designing APIs in this manner
● Take questions and share code to those interested in futher investigation
13

What makes them brittle
Point to Point Integrations
Many simple application flows mix and match mule scopes and functionality. This can cause performance
problems as well as permenantly using more resources than required
• Batch scopes are useful for processing a lot of data, but take time to load into memory and disk and require
that same memory and disk even when not being used, ie for once a day etl processes
• Filtering of streams may involve reading into memory all the input data & require a large vCore
• Unit testing or functional testing are usually the same thing, measuring end to end functionality
• Processing is usually one-way with little scope for checking output, post processing
• Iterations to functionality usually involve added complexity using choice routers and involve complete re-
testing of integration
• The application usually contains a number of referenced libraries, so is a large deployable archive
14
Process Integration
CRM
Customer
Object
Integration

API Led Applications
Separating and Describing the APIs
I’ve remodelled an example application, using multiple flows, into separate applications that are optimised
for the purpose of each flow
• Applications are decomposed using HTTP transports and Anypoint MQs
• Each is made independent using RAML to control the datatype of the ingress payload
• The process layer has a ‘loosened’ contract to enable future functionality
• Extra RESTful functionality is built to make sytem layers more functional
15
Process APIs
System APIs
Experience APIs
Customer
Object
Interface
CRM
v2
Replacement
CRM
Interface
New
CRM
v1.1
CRM
v1

What the Extra Work Has Achieved
Benefits
The benefits are of decomposing and making the worflow API-Led are;
• Smaller experience and process layers (microservices) that are quicker to deploy
• Smaller experience and process layers that are also easier to adapt and iterate forward with additional
functionality
• A more RESTful system layer that can be re-used and offer more functionality
• Contracts for the process and system layers that better define functioanlity and aid unit testing
• Taking advantage of default and fast exception handling provided by the APIkit Router
• Controlling payloads and responding quickly to bad data inputs
• Better use of resources such as limited time windows for resource hungry dataloads, but small efficient
orchestration
• The ability to apply relevent policies, to each layer, specific to the API needs
16

Using Studio Components in a RESTful way
Key Considerations
In summary, to be API led, each API needs to be managed independently. The
• Use HTTP Listeners to receive payloads, to ensure RESTful interaction and provide http.status and reason
responses
• Describe the API in RAML, to enable the validation of payloads and loosely define query parameters to enable
future functionality
• Use the APIKit Router to direct messages into the functional flows and provide default error handling
• Use Anypoint MQs to handle messages in a performant manner and separate the handling, orchestration and
processing of the input payload
• Use query parameters as JSON objects to not tie the process layer to any particular system layer
• Make system layers as RESTful as possible, transforming responses and resources where required and creating
new methods where possible
• Use an auto-discovery global configuration element to enable the application of policies, via API Manager, such
as the managed client-id and client-secret enforcement policy
17

Thank you
Any Questions or Comments?

© Ricston Ltd. 2021
A normal day in Air Malta’s
IT operations team
Justin Saliba

Air Malta - challenges
● High competition - entry of low cost carriers and relatively small
‘homebase’ for Air Malta
● Economies of scale are practically non-existent
● Efficiencies and Sustainability - cost cutting and profitability
● Legacy dependent - both internal and external
● Vendor driven - driven by large players
● Monolithic - lacking of integration prospects

IT’s role within Air Malta
• Bringing services and information together
• Analyse and understand what a customer really wants
• Optimising without disruption
• New ways of applying technology
• Launch products to market quicker
• Increase distribution coverage
• Be one step ahead of what the business needs
Opening new
revenue streams
Innovate customer &
employee experience
Operate more
efficiently

Achieving the vision through
API-led economy
Data Governance -
Be in control of data
and information
Visibility and
reusability
Market options and
capability to shift
Explore new trends,
technologies and
frameworks
Robust, resilient and
adaptive
Maturity through
iteration
Provide means and
opportunities
Becoming core
Become as vendor
agnostic as possible

Point of origin

Forming a team
CHALLENGES
● No IT development capabilities
● Previous solutions delivered by external
partners - lost of key knowledge and agility
● Lack of development tools
● Lack of delivery experience
DECISIONS
● Introduce an Air Malta Platform architect
● Clear executive stakeholder ownership and
sponsorship (CIO)
● Form a new development team with Ricston
consultants
● Introduce all required tools for development.
Git, artifact repository, CI/CD, etc.
● Experience through iteration

Consistent delivery
● Reduce Human effort → Reduce human errors
● Deployment of Microservices in a Hybrid solution
○ Avoid issues due wrong configurations
○ Encrypt properties through an encrypted Vault
● Delivery/Maintenance of IT infrastructure
○ Depletion of human interaction
○ Setup connectivity/configuration for new VMs
○ Keep all tools healthy
● Tools introduced
○ Atlassian products (Jira, Confluence, Service
Desk…)
○ Source Control, Artifact Repository, Database
version control
○ CI/CD server, Ansible, Docker
○ Log Management/Analysis tool
○ Alerts

Surviving without QA team
● Lack of manual testers
● Tests became a critical part of our daily delivery
● No tasks are completed without Unit tests and Integration Tests:
○ Unit test: Munit
○ Integration Test: Wiremock, RestAssured, JsonAssert, Docker
● CI/CD closed the gaps
○ A pipeline to deliver artifacts: Build, Test, Package
○ A pipeline to deploy deliverable artifacts

Maintenance and support
● Log management and log analysis service
● Infrastructure monitoring tool
● Air Malta Logger connector
● Continuous feedback providing Continuous
improvement
● API Documentation and Versioning
● Usage of Log Alerts / Anypoint Alerts

A normal day of an
API developer in Air Malta
● Morning stand up
● Focus on developing solutions (when there are no
meetings…)
● Single team working in parallel deliveries across
several projects
● One click deployment. Automated processes are
ready for you
● Tests are a top priority. No Test = No Party
● Feature not completed until documentation is in
place

Architecture - simplified view

Use Case 1 - Unlocking the
Reservation System
Booking Workflow
Build a technical understanding
of how the reservation system works,
rather than relying on prebuilt solutions
Adapt booking workflow
depending on business needs
Adapt to new needs and
demands without involving
third parties.

Use case 2 - Brand Identification
Check-in
Changes in luggages policies
Retain control
Move to real-time
Increase Agility/Flexibility

Use Case 3 - Flight Crew
Management
Flight Operations Integration
Improved crew satisfaction
Additional observability
Reusability
Operational efficiency

Results
METRIC 1
Up to 5 times faster
time-to-market
API MVP available for Salesforce
integration partner within 2 weeks down
from 8 weeks
Flight Reservation API project completed in
8 weeks, instead of the estimated at 9
months
Flight Operations project complete in 6
months, instead of the estimated at 18
months
METRIC 3
95% code-reuse
METRIC 2
One-click deployments
METRIC 1
time-to-market

METRIC 3
95% code-reuse
METRIC 2
METRIC 1
time-to-market
Deployment range from two-nodes on
CloudHub to 8 hosts on premises and
load balancers
Codified deployments included are Mule
apps, reverse proxies, database schemas,
integration, load and end-to-end testing
Zero downtime deployments
Results

Heavy use of out-of-the box Mule connectors
and libraries
Custom logging connector re-used across
applications
Re-use of the APIs
Tried and tested, highly-available, low-latency,
99.99% up-time
METRIC 3
95% code-reuse
METRIC 2
METRIC 1
time-to-market
Results

Thank you!
Q&A

MuleSoft Manchester Meetup #4 slides 11th February 2021

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to MuleSoft Manchester Meetup #4 slides 11th February 2021

Similar to MuleSoft Manchester Meetup #4 slides 11th February 2021 (20)

More from Ieva Navickaite

More from Ieva Navickaite (6)

Recently uploaded

Recently uploaded (20)

MuleSoft Manchester Meetup #4 slides 11th February 2021