The Wellington Meetup #14 covered MuleSoft's Experience Hub and the new deployment release channels with Java 17, featuring presentations from Bhajan Mehta and Kunal Bante. Key topics included API management, deployment options (Edge vs LTS), and the migration timeline to Java 17, emphasizing the importance of adapting to new architectural needs. The meetup concluded with a quiz and opportunities for networking within the community.

1. Wellington Meetup #14:
Mule Experience Hub
and Release Channel
with Java 17
Bhajan Mehta, Solution Architect, Datacom
bhajan.mehta@datacom.com
He/Him

2. AGENDA
● Introductions
● Certification Vouchers
● MuleSoft Experiene Hub
● Deployment Release Channel
● Deployment With Java 17
● What is next?
● Quiz
● Networking time

3. Introductions
● MuleSoft Moderator
○ Bhajan Mehta
● Speakers:
○ Bhajan Mehta
○ Kunal Bante
● Sponsor By:

4. Introductions
Bhajan Mehta
● Bhajan Mehta:
○ 15+ Years of experience in IT
○ Solution Architect at Datacom
○ MuleSoft Meetup Leader – Wellington
Region
○ MuleSoft Mentor 2024

5. Introductions
Kunal Bante
● Kunal Bante
○ 12+ years of experience in IT
○ Technical Architect at Datacom
○ Speaker for Today’s Meet-up (Experience
Hub)

6. MuleSoft Anypoint
Experience Hub

7. Universal API Management on Anypoint Platform
Anypoint Platform
Build Discover Govern Manage Engage
Discover, Build and Catalog any API
Ensure consistent API quality and security
Control and secure access to any API
Engage and create API Ecosystems

8. Why do you need
Universal API Management
Accelerate
Application and
automation delivery
This enables
developers build
connected and
responsive experiences
Anypoint API Designer
Anypoint DataGraph
Anypoint API Catalog CLI
Anypoint Code Builder
Gain consistent
security and quality
For architects to
operate seamlessly in
any environment or
architecture
Anypoint API Governance
Anypoint API Manager
Implement modern
architectures
For API owners adopting
distributed architectures
and modern applications
Create vibrant API
ecosystems
To let API product
managers create new
revenue streams and
business models
Anypoint Flex Gateway
Anypoint API Manager
Anypoint API Experience
Hub

9. Maximizing API value needs a shift in mindset
Making APIs discoverable and consumable is imperative in digital ecosystems
Where do I maintain all APIs I want to
publish to consumers?
I want a single source of truth
Consolidated API view
Do we have expertise to build and maintain
portals?
I want to save time and resources
Publish APIs to consumers
Our users want support from product and
community.
I want build and engage ecosystems.
Customer support
API Product
Manager

10. Anypoint Exchange
Access and work with any API, built anywhere
Consolidate APIs built anywhere
Automatically discover APIs and relevant documentation
from any environment using CI/CD pipelines
Package your APIs into products
Describe your APIs with asset information, interactive
documentation and simulated behaviour
Streamline API consumer onboarding
Empower developers to discover, explore and get started
with your own APIs, asset and best practices
Jumpstart development and governance
Use hundreds of templates, APIs and governance rules
from the MuleSoft ecosystem

11. Anypoint API Experience Hub
Build API portals in minutes for better API engagement
 Fast and Easy guided UI to build API Portals
 Create branded API portals using built-in templates
powered by Salesforce Experience Builder
 Manage portal user and registration requests
 Self-service consumption experience: search APIs, check
API docs, test APIs, request access
 Built-in API marketplace to drive API adoption and value

12. Key API Portal use cases

13. Journey for API Experience Hub
 API Specialist (Employee) is
API provider responsible for creating
and managing the API Portal
 Software developer
(External) is consumer of API’s
which available on API Portal

14. Demo

15. Questions?

16. Deployment Release
Channels
EDGE vs LTS

17. Deployment Release Channel
● MuleSoft introduces two new release channels starting from Mule 4.5
○ Edge
○ LTS
● Monthly Patches
○ These patches will continue as it is, irrespective of the frequency for the release of EDGE or
LTS release channel.
● Includes new features, and improvements in each cycle,

18. Deployment Release Channel - Edge
● Release cadence – Three times a year:
○ February
○ June
○ October
● Recommended Option for CloudHub or Cloudhub 2.0
● Support Coverage:
Release
Date
End of Standard
Support
End of Extended
Support
4 Months 4 Months

19. Deployment Release Channel - LTS
● Release cadence – Once a year:
○ February
● LTS release contains all the features of latest EDGE versions.
● Recommended Option for Self Managed platforms, like: On-Prem, Hybrid.
● Support Coverage:
Release
Date
End of Standard
Support
End of Extended
Support
12 Months 12 Months

20. Mule Runtime Release Calendar

21. Release
Date
Deployment Release Channel – Self Upgrade
A reason to choose CloudHub Platform
● Auto Upgrade timeframe
○ Edge: 2 Weeks
○ LTS: 2 Months
● Mule Applications will be automatically gets updated with their runtimes on Cloudhub platform.
● Manually can be upgraded prior to self upgrade time frame.
● Example: For LTS
End of Standard
Support
End of Extended
Support
12 Months 12 Months
Manual Upgrade
Window
2 Months

22. Mule apps do not reach End of
Life because they are always
auto-upgraded.
Only if older version is compatible with the latest
version requirement, like Java Version Support.

23. What happened after EOES?
EOES - End of Extended Support
● Latest information can be found here.
○ https://docs.mulesoft.com/release-notes/mule-runtime/lts-edge-release-cadence
● Mule Apps stops running for any version prior to Mule 4.7 for CloudHub and CloudHub 2.0
● Utilizing the information from MuleSoft, as its source of truth, and which may change later.

24. FAQ – Can we stop auto-upgrade?
● Yes, it is possible but, you need to confirm with your account manager.
● Depending on your license subscription, you might be able to allowed to add a set of APIs
under exception list, which will skip the auto-upgrade.

25. Deployment Release Channel – Rollback
● If there any functional issues encountered, then it is possible to do the rollback:
○ Redeployment using CI/CD Pipeline
○ Runtime Platform API
○ Using Platform GUI

26. Recommentations for adopting Release Channel
● Create a comprehensive automated regression test suite.
● Identify critical Mule Applications – If it is not possible to run regression test for all Mule APIs.
● Perform manual auto-upgrade for Mule for non-production environment.
● Run Regression testing for critical applications to make sure latest version of Mule Runtime is
not causing any issues.
● If any issues discovered, contacted MuleSoft Account Manager to stop auto-upgrade.

27. Deployment Release Channel – Self Migration
Release Timeline
● It is good time to start thinking about migrating mule applications to Java 17
● It will be a must do activity in June 2025 for Edge and Feb 2026 for LTS.
Mule 4.5(E)
Java 8, 11
Mule 4.6 (L,E)
Java 8, 11,17
Oct 2023 Feb 2024
Mule 4.7 (E)
Java 8, 11,17
Jun 2024
Mule 4.8 (E)
Java 8, 11,17
Oct 2024
Mule 4.9 (L,E)
Java 17
Feb 2025
Mule Apps will stop
running after End of
Extended Support
Mule Apps will
COUNITUE running after
End of Extended Support

28. Deployment Release Channel - Migration
Edge to LTS or LTS to Edge
● Moving from lower version of EDGE or LTS release channel to higher version of either EDGE
or LTS is supported.
● Moving from higher version to lower version MAY NOT be supported:
○ New features released in higher version wouldn’t be available in lower versions.
○ Support of Java version
■ Mule 4.5 Supports Java 8 and 11, if it migrated to Mule 4.6 Java 17 then going back would require to
change java version as well.

29. Java - 17

30. Java version Update

31. Other Changes?
● POM Update:
○ mule.maven.plugin.version  4.1.0 (3.x.x Not Supported)
○ Need to update connector versions
■ Extension 'HTTP' version 1.7.1 does not support Mule 4.6+ on Java 17. Supported Java versions are:
[11, 1.8].

32. CloudHub 2.0
● Bit of change in the deployment cycle
● Update
● Artefact needs to deployed to Exchange first
Deploy to
CloudHub
2.0
Publish to
Exchange
Build Mule
Application
(jar file)
mvn clean package mvn deploy mvn deploy -Ddeploy

33. POM Changes for CloudHub 2.0 Deployment
● Maven Plugin
Mule documentation is
showing username and
password, rather than
connected app, which
will cause MFA issue.

34. POM Change for Publishing artefact to Exchange

35. Other Possible Errors for using Java 17
● [ERROR] Failed to execute goal on project hellomule: Could not resolve dependencies for
project 6cfbe428-bbb2-44fa-8b26-4f886eec15c3:hellomule:mule-application:1.0.0: Faile
d to collect dependencies at org.mule.connectors:mule-http-connector:jar:mule-plugin:1.5.25
-> org.apache.commons:commons-text:jar:1.8: Failed to read artifact descriptor f
or org.apache.commons:commons-text:jar:1.8: The following artifacts could not be resolved:
org.apache.commons:commons-text:pom:1.8 (absent): Could not transfer artifact org
.apache.commons:commons-text:pom:1.8 from/to mulesoft-releases
(https://repository.mulesoft.org/releases/): PKIX path building failed:
sun.security.provider.certpath.SunCer
tPathBuilderException: unable to find valid certification path to requested target -> [Help 1]

36. Fix for this error
● Download the full chain of certificates for the repository, which is causing error.
○ https://repository.mulesoft.org/releases/
● Full chain is import;
○ It may work for your local and may not for CI/CD
○ Possibly due to some reverse-proxy
● Import Certificate to <JAVA_HOME>libsecuritycacerts file

37. Demo

38. Quiz

39. API Specification (Contract) Update – RAML
Question 1:
What do we need to do to use API Spec version 2.0.0 in API Manager Proxy?
A) Nothing to do. Latest version will be picked up automatically.
B) API Spec Version needs to updated manually in the existing API Proxy
C) Create a new API Proxy with latest version.
● API Specification (RAML) is updated as below:
○ Version 1.0.0
○ API Proxy is created using API Spec version 1.0.0
○ API Spec Updated with version 1.0.1
○ API Spec Published with version 2.0.0

40. Mule LTS Self Update
Question #2
Will our Mule Application get Auto-Migrated after the new LTS release?
a) Yes – It will be self migrated to Mule 4.9 in Feb 2025.
b) Yes – It will get self migrated to Mule 4.9 in Apr 2025.
c) No – It will not auto-migrate.
● We have a Mule Application built and deployed using LTS 4.6 (Java 8)
● Next LTS release is scheduled for LTS in Feb 2025 (Mule LTS 4.9).

41. Mule LTS End of Extended Support
Question #3
What will happen to the Mule Application?
a) It will get migrated to Mule LTS 4.9 two Months after its release.
b) It will keep using Mule LTS 4.6 – Means, No Outage
c) It will stop running, and it will cause an outage.
● We have a Mule Application built and deployed using LTS 4.6 (Java 8)
● End of Extended Support for Mule LTS 4.6 is Feb 2026

42. ● We have a Mule Application built and deployed using Mule 4.6 Edge (Java 11)
● Mule Edge version 4.7 (Java 11) is released.
● The Mule application is auto migrated to the next Mule Edge version (4.7) 2 weeks after the
release.
● You found an issue and decided to manually rollback to Mule 4.6 Edge (Java 11).
Mule Application Self Upgrade
Question #4
What will happen to the Mule Application 2 weeks after the manual rollback?
a) It will get migrated to Mule 4.7 Edge (Java 11) again.
b) It will keep running with Mule 4.6 Edge (Java 11)

43. MuleSoft Anypoint Exchange
Questions #5
An API has been updated in Anypoint exchange by its API producer from version
3.1.1 to 3.2.0 following accepted semantic versioning practices and the changes have
been communicated via the APIs public portal. The API endpoint does NOT change in
the new version. How should the developer of an API client respond to this change?
a) The API clients need to update the code on their side and need to do full
regression
b) The API producer should be contacted to understand the change to existing
functionality
c) The API client code only needs to be changed if it needs to take advantage of the
new features
d) The API producer should be requested to run the old version in parallel with the
new one

44. Questions?

45. What is next?

46. MuleSoft Meetup Community
● Will plan another Wellington meet-up very soon (probably Virtual), so be on the lookout for
the invite and invite others to grow this community.
○ Joining the next meetup will increase your chances to win.
● Feel free to suggest a topic for a future meetup
○ If you want to be the next Speaker, then please let me know.
● Be part of the Wellington whatsapp community group be connected and share knowledge
(QR Code can be found on the slide at the end of this presentation, also it is circulating
around on paper).

47. Thank You

48. Networking time