Lessons from Mule4 CloudHub runtime batch Architecture and build Project
MuleSoft is a integration platform used for Application programming interface and extarct ,trasform and load (ETL) . As the time to market is shortening by each passing year, Mule4 programming uses drag and drop approach, which is relatively easier compared to traditional programming languages.
I had the privilege of working for the Mule4 Batch Project and I wish i knew the below mule Batch programming caveats before starting the project
Here are some the Mule terminologies before we move on to the main topic.
- CloudHub: Mule cloud runtime environment
- vCore: Compute ,Memory and Storage combined into one logical unit of measure
- Worker: Virtual container with predefined vCore size
- Combine batch jobs to avoid the below pitfalls
- Do not design a task specific Batch job to run in a Single Mule4 CloudHub worker, instead group the business specific batch job tasks together and deploy in Mule4.
Mule4 batch job once deployed in Cloud hub will not release the compute resources , untill the worker is deleted.
You will exhaust vcores when you design task specific Batch jobs
- There is no easy way to maintain the DB credentials , Access_keys , secret_keys common across all the workers in Mule4 hosted in CloudHub runtime.
- Divide the task specific batch jobs in different Mule XML files
- Mule4 code will be saved as XMLs in backend and we can call any component in one XML into other XML without importing the dependent XML
- Complex code in one XML can be divided into multiple XMLs to keep our code simple,clean and easier to debug
