MuleSoft Surat Virtual Meetup#6 - MuleSoft API Led Connectivity, SEDA and MUnit Tools and Recorder

1. [19th
Dec 2020]
[Surat] MuleSoft Meetup Group
API Led Connectivity, SEDA and MUnit

2. 2
Organizers
A SHOW OF HANDS:
Who is new to this Meetup?
Jitendra Bafna
Enterprise Solution Architect
Capgemini
Nitish Jain
Consultant
IBM

3. 3
Speakers
Mary Joy Sabal
Integration Technical Lead
Datacom, NZ
Shivakant Sahu
Solution Architect
Apisero

4. Agenda
● Why application testing is important?
● MuleSoft testing framework - MUnit
● Implement Unit Testing Strategies using MUnit Tools
● MUnit Coverage
● Demo – MUnit Test Recorder
● API Led Connectivity and SEDA

5. MUnit Test Strategies and Recorder

6. Why application testing is important?
● We all make mistakes.
● Gives confidence to developers and customers to ensure good quality product is delivered.
● Untested code is broken code.
● Executable documentation of code’s behaviour.

7. Unit Testing
● White-box testing.
● Verifies the functionality of a specific unit.
● Do not require deployment into any special environment, such as a staging environment.

8. MUnit
● MUnit, is a dedicated unit testing tool specifically targeted to testing Mule applications inside a
Mule runtime.
● Design and create white-box test cases as Mule flows.
● Each test is itself a Mule flow, using components from the MUnit and MUnit Tools modules.

9. MUnit cont. . .
● Test Flow Structure ● Test Tags
● Test Coverage

10. Implement Unit Testing Strategies
using Munit Tools
● For read-only interactions to any
dependencies (such as other APIs): allowed
to invoke production endpoints ("sociable"
unit tests).
● For write interactions: developers must
implement mocks using MUnit.
● Assertions about the result are tested and
recorded.

11. MUnit Coverage
● Runs only for EE edition runtimes.
● Measurement of how much of a Mule application has been executed by a set of MUnit tests
by counting the amount of event processors executed.
● Enable MUnit Coverage
1. Maven
2. Studio
● MUnit Coverage Reports
1. Console
2. HTML
3. JSON
4. Sonar

12. MUnit Coverage Metrics
Flows Subflows Batch
jobs
XML
XML
XML
XML
XML
Application overall coverage
metrics
Resource coverage
metrics
Flow coverage metrics

13. MUnit Coverage Maven settings

14. Demo

15. API Led Connectivity

16. 16
Content
01 02
03
05
04
06
07
09
08
10
API-LED Connectivity Common Approach
Limitations with Common
Approach Power of API-LED Approach
SEDA Architecture Scenarios
Synchronous Asynchronous
QuestionsExamples

17. 17
• Order data in eCommerce system
• Inventory data in SAP
• Customer data in SAP, Salesforce
Project objective: Web app provides
real-time order status and order
history for sales team engaging with
customers
Aggregated customer
data
Order status Order history
Web app API
A common project-based Approach

18. 18
Web app API
Aggregated customer
data
Order status Order history
On time and within budget
Limited opportunity for reuse
Tight coupling = brittleness
Difficult to govern
Meets business requirements
?
A common project-based Approach

19. 19
Integration project
Aggregated customer
data
Order status Order history
mobile APIMobile API
Aggregated customer
data
Order historyOrder status
Web app APIWeb app API
6 months later…

20. 20
• Discoverable and accessible
through self-service
• Productized and designed for
ease of consumption
• Easily managed for security,
scalability, and performance
Modern
API
Modern API- The core enabler of new model

21. 21
System
APIs
Process
APIs
Experience
APIs
Customers
Web app API
Orders
Salesforce
customers
SAP
customers
Order
status
Order
history
The API-LED Connectivity Approach

22. 22
System
APIs
Process
APIs
Experience
APIs
Customers
Web app APIMobile API
Orders
Salesforce
customers
SAP
customers
Shipment
status
Toll
shipments
UPS
shipments
Order
status
Order
history
The API-LED Connectivity Approach

23. 23
System
APIs
Process
APIs
System
APIs
Process
APIs
Experience
APIs
Unlock assets and decentralize
access
Discover, reuse assets and compose
information
Discover, self-serve, reuse and
consumeDevelopers
LOB IT
Central IT
Enable and empower the entire organization

24. 24
System
APIs
Process
APIs
Experience
APIs
On time and within budget
Limited opportunity for reuse
Tight coupling = brittleness
Difficult to govern
Meets business requirements
?
Drive outcomes with API-LED Connectivity

25. SEDA – Staged Event Driven
Architecture

26. 26
SEDA Architecture
Staged, Event-Driven Architecture:
● The architecture upon which Mule was built
● Decouples receiving, processing, and dispatching phase Manage streams and
larger-than-memory payloads transparently
● Supports higher levels of parallelism in specific stages of processing
● Allows for more-specific tuning of areas within a flow's architecture

27. 27
SEDA Architecture
Inbound Endpoint
Message
Processor
REQ-RES
Outbound
Endpoint
Outbound
Endpoint
Message
Processor
FLOW
Receiver Thread
Pool Flow Thread Pool Dispatcher Thread
Pool
Synchronous Flow
Asynchronous Flow(SEDA Queue)
Connector (Common Transport Setting)

28. 28
SEDA Architecture
Staged, Event-Driven Architecture:
Scenario 1:
Inbound Connector is one way
Outbound Connector is one way
No transaction Flow
PROS CONS
Uses SEDA model with three fully decoupled
stages
Flow cannot return a response to the caller
Highly Performant Complicates integration with client that need
a response

29. 29
SEDA Architecture
Scenario 2: Synchronous - Asynchronous mode
Receiver thread is exchange pattern
Dispatcher thread is one-way
PROS CONS
Returns the component response to the
caller
Receiver thread pool can be still
overwhelmed by incoming requests
Dispatching decoupled from receiving and
servicing
Receiver
Synchronous
Flow Dispatcher
Asynchronous

30. 30
SEDA Architecture
Scenario 3: Synchronous mode
PROS CONS
Uses SEDA model with three fully decoupled
stages
All load handled by the connector’s receiver
threads
Simple to implement Don’t use SEDA queueing
Receiver
Synchronous
Flow Dispatcher
synchronous

31. 31
SEDA Architecture
Scenario 4: Asynchronous - Synchronous mode
PROS CONS
Allow synchronous routing in the dispatcher Flow cannot return a response to the caller
Receiving decoupled from dispatching and
receiving
Flow thread pool size constrains the
outbound dispatching load capacity
Receiver
Asynchronous
Flow Dispatcher
synchronous

32. Introduce yourself to your neighbor
Networking time