#Codetober 2023 ~ 31 MuleSoft-related videos under 10min each!
Every year since 2021, I’ve been doing these 31 videos called #codetober!
See here the full list of videos for 2021–2023.
This year, the videos have been edited for your better digestion and are (almost all) less than 10 minutes each.
Please comment on our videos to suggest future content or ask any questions about a specific topic.
Happy codetober!!
💡 Find this year’s GitHub repository here: ProstDev/codetober23
Videos
Day 1: How to scaffold Mule flows from a published API spec in Anypoint Studio
Once you have your API specification and you have published it to Anypoint Exchange, you can now import this directly from Anypoint Studio to automatically scaffold the necessary Mule flows and error handling in a new Mule project.
Day 2: How to scaffold Mule flows from a published API spec in Anypoint Code Builder
Once you have your API specification and you have published it to Anypoint Exchange, you can now import this directly from Anypoint Code Builder (currently in BETA version) to automatically scaffold the necessary Mule flows and error handling in a new Mule project.
Day 3: How to RE-scaffold Mule flows from an Exchange API spec in Anypoint Studio
After doing some changes to the API Specification from Design Center, the API spec is published to Exchange with a new version. After that happens, you can download the new version to your Anypoint Studio and re-scaffold the Mule flows to have an up-to-date API implementation.
Day 4: Use MuleSoft’s visual API Designer to create a To-Do API specification
Did you know MuleSoft provides this neat Graphical User Interface (GUI) where you can configure your own API specification with just clicks? That’s right, you don’t have to learn RAML or OAS anymore. You can just follow this visual tool to create them and it gives you the code you need in whichever format you need it!
Day 5: DataWeave 2.5 module features: toString, concatWith, version
There was a new DataWeave version released this past October 3 (2023). Let’s check out what’s new with these three functions: toString, concatWith, and version.
Day 6: Exploring the Thunder Client Extension for Visual Studio Code
I was using the Postman extension for VS Code but I kinda liked this one better 👻 it’s more lightweight even though it doesn’t offer all the great options Postman does. But it’s great for quick testing!
Day 7: How to create custom user snippets in Anypoint Code Builder (VS Code)
User Snippets are important to keep handy your most used components in ACB!
Day 8: Exploring the GitHub Actions Extension for Visual Studio Code
This is a good add-on for VS Code if you’re using a lot of GitHub Actions for your projects!
Day 9: How to deploy to CloudHub 2.0 with the Mule Maven Plugin & Connected App
It took me a while to get this going!
Day 10: How to use DataWeave 2.5 with the BETA extension in Visual Studio Code
DATAWEAVE 2.5 HAS BEEN RELEASED FOR VSCODE AAAAAHHH 🤩
Day 11: 8 examples to import modules/functions in DataWeave & how to use aliases
Using the `import` keyword, you can just import a module and then call the function like `Module::function()`, or you can use the `from` keyword to specify the functions to import.
For example, `import * from Module` or `import function from Module`.
Then, we have other interesting approaches like using `as` to create aliases for the modules or the functions.
Like, `import Module as Mod` or `import function as f1 from Module`
Day 12: Help us get DataWeave into Exercism for programming challenges/exercises
Exercism provides coding exercises for you to learn a variety of programming languages. DataWeave is currently NOT one of them though. However, not all heroes wear caps! Join our community member Clayton Flesher in this quest to get DW on this platform!
Day 13: How to run several Mule applications in Anypoint Studio at the same time
To run more than 1 Mule app at the same time in Studio, first, you have to make sure your HTTP listeners are running in different ports. Otherwise, the applications won’t run at the same time because the port is already in use in your local.
After you change the ports, you can use the Run Configurations option and create a new Configuration to run all the apps at the same time. Make sure you use different ports locally but you still use the dedicated ports when you deploy to CloudHub (i.e., leave ports 8081 for CH but change them for local).
Day 14: Best practices in Mule apps: global elements & properties files per env
After creating our three Mule apps (from the previous video), we now have to set up the best practices so we can set up the different configurations for the dev and local environments to make our lives easier in the future.
1️⃣ We start by setting up the global.xml Mule Configuration File to save all the Global Element Configurations so we don’t have to be looking for them in other XML files. It may not seem like a big deal for a small project like this, but once you have more files and flows, it can become a nightmare.
2️⃣ After that, we set up different properties files per environment — one for dev (what we’ll deploy in CloudHub) and one for local. Don’t forget to set up the ${env}.properties or ${env}.yaml configuration for the properties files and the `env` global property set to `local`. And ta-da! We are ready to get started on the next step: calling each layer separately.
Day 15: Setting up HTTP Requests for Experience, Process, & System layers in Mule 4
In the previous two videos, we set up three very basic Mule projects to represent the 3 API-Led Connectivity layers: Experience, Process, and System.
If you’re not familiar with this approach, it means that the client application is gonna call the Experience-layer API, which is then gonna call the Process-layer API, which is finally gonna call the System-layer API.
Client ➡️ Experience API ➡️ Process API ➡️ System API ➡️ Server
It has its reasons why, but we’re not focusing on that now. We just want to set up the HTTP requests from E (or X) to P and from P to S. Along with that, we are making sure our local and dev properties are up to date.
The dev properties are always running in port 8081 while the local properties have to be split in ports 8081, 8082, and 8083 (can be other ports, these are just used as an example).
Day 16: How to debug several Mule applications in Anypoint Studio at the same time
In case you haven’t debugged Mule apps before, or in case you haven’t debugged more than one Mule app at the same time before, this video is perfect for you!
In previous videos, we had set up the Run Configurations to be able to run the three Mule apps that we’ve been using in these examples (Experience, Process, and System API layers from the API-Led Connectivity approach).
This time you can reutilize the same configuration but to DEBUG instead of just RUN. Apart from that, we encountered an error pretty quickly telling us that the HTTP response had resulted in a TIMEOUT because we halted the apps while debugging.
We learned how to set up some properties to increase the HTTP response timeout locally so that it lets us debug in peace 😌
Day 17: Deploy Experience, Process, & System API layers to CloudHub 2.0 from Studio
After setting up our three Mule apps for the Experience, Process, and System APIs (from API-Led connectivity), we are finally ready to deploy them to CloudHub 2.0 (in Runtime Manager) and finish setting up the properties for the dev environment ✨
We learned that the port for HTTP in CloudHub 2.0 has to be 80 and the port for HTTPS has to be 443! This works differently from CloudHub 1.0, where you can use port 8081. Interesting fact that I did not know about until now 🥹
Day 18: Designing the American Flights API Spec in Anypoint Code Builder (ACB)
After Anypoint Code Builder (ACB) has been GA’d, let’s go ahead and try out the different tutorials the team has created for us to get familiar with the tool.
In this video, we’ll use ACB to create an API specification widely used in the MuleSoft training called the American Flights API. We’ll learn how to reuse API fragments from Anypoint Exchange locally, how to use the data types from Exchange, and how to see it all reflected in the API console from ACB.
Day 19: Testing, syncing, and publishing an API in Anypoint Code Builder (ACB)
In the previous video, we designed an API Specification for the American Flights API.
In this video, let’s first test that our API is working as we would expect using the mocking service.
Then, we’ll sync the specification to Design Center so that we can access this same information from Anypoint Platform.
Finally, let’s publish this API to Anypoint Exchange so other people can consume it. All from Anypoint Code Builder!
Day 20: Integrating American Flights Processes in Anypoint Code Builder (ACB)
Let’s learn how to develop an integration in Anypoint Code Builder (ACB) by following the previous examples of the American Flights API.
In this video, we’ll create a simple Mule application with an HTTP Listener that will output a string payload. We will learn how to run this application locally to make sure it works properly.
Day 21: Connecting to a Database from the Mule app in Anypoint Code Builder (ACB)
We want to connect to the American Flights database so we can pull the details of the flights for our American Flights API.
In this video, we’ll learn how to set up the database configuration in the pom.xml and set it up in the Mule Configuration file. After that, we’ll test it to see if it works as-is or if we need some sort of transformation 👀
Day 22: Transforming Flight Data with DataWeave in Anypoint Code Builder (ACB)
We were able to connect to the Database in the previous video, but we weren’t able to get a successful response just by doing this.
In this video, we explore the Transform Message component in Anypoint Code Builder so we can correctly transform the data we receive from the database into the JSON structure we had defined in our API Specification.
Day 23: Implementing the American Flights API Spec in Anypoint Code Builder (ACB)
In this series of videos, we started by designing the American Flights API and then we developed some code to get the data from the database.
In this video, we are putting it all together. We can scaffold the flows from the API specification that was published to Exchange and then call the MySQL flow with a Flow Reference.
Day 24: Debugging the American Flights App in Anypoint Code Builder (ACB)
It’s very important to learn how to debug your code in Anypoint Code Builder (ACB) because it will give you more insights into what is happening in the flow of your application.
In this video, we’ll learn how to start a debugging session to test the app, how to add a watch expression to take a look at the payload’s media type, how to add, disable, or enable breakpoints, and how to stop debugging.
Day 25: Implement & test a GraphQL API in Anypoint Code Builder (ACB)
Even if you’re not familiar with GraphQL, you can generate/scaffold a whole Mule project based on a GraphQL schema that we publish in Exchange. After publishing the schema in Exchange, we can implement the API locally using Anypoint Code Builder in minutes!
Day 26: Using the Transform Message component (DataWeave) in Anypoint Code Builder
We know how to define metadata in Anypoint Studio to see a preview of our DataWeave code to transform the data using the Transform Message component. But how to do this in Anypoint Code Builder (ACB)?
In this video, we’ll use a Transform Message component in a Mule project to transform an input into an expected output according to our “business requirements.” Then, we learn how to create the payload.json input and how to run the script according to this JSON file. You can also use the Enable Autopreview button to get the same functionality from the DataWeave Playground!
Day 27: Using branches in Design Center & Anypoint Code Builder for API specs
Have you ever had to work on a single API specification but divide the work between more than 2 people? Isn’t it messy? You can use the branching system (or version control system) that Design Center provides for this type of scenario.
Whenever you work on a change to the API spec, you can create a new branch, make the changes, and then review the changes to merge to the master/main branch. You can do this same thing from Anypoint Code Builder (ACB) using the Source Control plugin from Visual Studio Code (VS Code). Here I’ll tell you how!
Day 28: Testing Mule flows with the MUnit recorder in Anypoint Studio
In MuleSoft, we use MUnit tests to make sure we create unit tests for our Mule flows and Mule projects. There is this tool called the MUnit recorder that runs your Mule application locally and records how you interact with it in order to create some tests.
In this video, we create a simple MUnit test to assert the expected output from what we send into the app. The app uses a Choice router and Set Payloads to see the different routes.
Day 29: Enable Multi-Factor Authentication in MuleSoft with the Salesforce App
When you sign in to Anypoint Platform, you can select to enable Multi-Factor Authentication (MFA) for your account to protect it from any dangers on the web 👀
In this video, we’ll learn how to enable MFA for Anypoint Platform using the Salesforce Authenticator app (available for iOS and Android devices).
Day 30: Differences between the DataWeave extension & Anypoint Code Builder
One thing is the DataWeave extension for Visual Studio Code which was mostly created for you to create new DataWeave libraries but can also be used instead of the online DataWeave Playground.
Another thing is Anypoint Code Builder (ACB), where you create Mule projects and can use DataWeave inside one of these projects.
You can use both of these tools independently or together. But what’s the difference then? In summary, you will have more DataWeave functionality if you install the DW extension and use it with ACB. You can also use ACB without having the DW extension, but there will be less functionality available for you. That’s why I’d recommend you to use both.
Day 31: Export a Mule project as a deployable JAR file in Anypoint Code Builder
A lot of times it’s just easier to export a deployable JAR file from your Mule project to upload it directly in Runtime Manager instead of using the IDE (whether it’s Studio or ACB) to deploy it from there.
Whichever it’s your preferred use case and method of deploying a Mule app into CloudHub or any other runtime plane, here is how you can export the Mule application into a .jar file from Anypoint Code Builder.
You can subscribe to my YouTube channel to get notifications as soon as I publish new videos!
