Connect with MuleSoft experts and other core Mule developers to share tips and tricks, ideas and how-tos for concepts that aren't even documented, and lessons learned. If you're comfortable in XML, this session is for you.

1. Tips and Tricks for Advanced
Developers

3. All contents © MuleSoft Inc.
Objectives
3
• Single project for all APIs
• Common code and resources
• Automated CI/CD pipeline

4. All contents © MuleSoft Inc.
Fine print
4
• This is one of many possible ways – many ways to skin a mule
• Many of these tools and techniques are not officially supported –
roll your own
• May become obsolete when new products are released

5. All contents © MuleSoft Inc.
Example use case
5
• ACME API
• Two systems, System ONE and System TWO
• Two types of resources – widget and gadget

6. All contents © MuleSoft Inc.
Multi-module Maven project
6
• Parent POM
• Domain project
• Shared resources project
• Separate project for each API

7. All contents © MuleSoft Inc.
Domain with conditional imports
7
• Connector has the same name but
different configs
• Embedded ActiveMQ local,
Websphere MQ on prod
• No need for TLS config on dev machine

8. All contents © MuleSoft Inc.
Domain with conditional imports
8
Domain XML config
common.local.xml
common.prod.xml

9. All contents © MuleSoft Inc.
Separate Resources Project
9
• Common custom Java classes, mappings, XML snippets,
RAML, schemas, examples
• Built as a JAR
• Listed as a dependency in all API implementation POMs
or in a domain (and loaded by a shared CL)
• Can be versioned independently

10. All contents © MuleSoft Inc.
Separate Resources Project - examples
10
• Custom Java classes – e.g. custom transformers
• Mappings – from and to canonical data model
• XML snippets – common and reusable exception strategies,
flows and sub-flows, object stores
• RAML, schemas, examples – system APIs may use canonical
data model

11. All contents © MuleSoft Inc.
Dynamic parse-template
11
• Custom Java transformer
• Can be used to load a file given the expression which
evaluates to a file name
• Just like built-in parse-template, can evaluate expressions inside the file

12. All contents © MuleSoft Inc.
Dynamic DataWeave mappings
12
• The flow is the same but request and response mappings are different
• Can I set mapping names in the APIKit request flow and invoke the
common code which calls the underlying system
• MEL function dw() evaluates a DataWeave script
• DataWeave script can be loaded using the dynamic
parse-template transformer

13. All contents © MuleSoft Inc.
Bonus: Coding Style and Naming Convention
13
https://github.com/javaduke/ACME_API/tree/master/docs

14. All contents © MuleSoft Inc.
Show me the goodies
14
https://github.com/javaduke/ACME_API/
Apache Maven: https://maven.apache.org
IntelliJ IDEA: https://www.jetbrains.com/idea/
Mule plugins for IntelliJ IDEA:
- https://plugins.jetbrains.com/idea/plugin/8212-mule-esb-plugin-for-intellij
- https://plugins.jetbrains.com/idea/plugin/8458-data-weave-intellij-plugin-
- https://plugins.jetbrains.com/idea/plugin/8459-raml-plugin-for-intellij

15. All contents © MuleSoft Inc.
Don’t forget the survey
15
• Why take the survey?
– Takes less than 2 minutes
– We value your feedback and apply it when deciding next year’s content and
speakers
– Surveys = Prizes!! Earn 55 points for a chance to win $250 in cash prizes
• See “Play To Win” in the Mobile App for details
• Where’s my survey?
– Log into the mobile app
– Click “Surveys” on the Tool Bar
– Find the relevant survey for this session slot

16. Thank you!

17. Mule Application
Enhancements

18. All contents © MuleSoft Inc.
Use case
• The integration layer have to sync records from Salesforce to Oracle
• The information is contained in three related Salesforce objects in a hierarchy and needs to be moved to
three different tables in Oracle
• If the records already exist in Oracle they will be updated, otherwise, inserted

19. All contents © MuleSoft Inc.
The first approach

20. All contents © MuleSoft Inc.
The first approach

21. All contents © MuleSoft Inc.
The first approach

22. All contents © MuleSoft Inc.
The issues
• Hard to debug and control since we had nested batch jobs that were triggered asynchronously
• Data inconsistencies arose since every Oracle operation was processed in a separate thread
• Batch module spawns multiple threads so when the job had to process a lot of records memory usage
increased and the runtime ran out of memory under certain scenarios
• When the poll processor triggered a new batch while there was a job running caused a job overlap

23. All contents © MuleSoft Inc.
The new approach (Part 1)
• Queue based to enable clustering and transactionality, batch is not cluster aware
• Single query from Salesforce
• Migrating from separate Insert/Update operations to Merge to prevent multiple calls
• Transactional scope to process records in Oracle

24. All contents © MuleSoft Inc.
The new approach (Part 2)

25. All contents © MuleSoft Inc.
Lessons learned
• Have small and reusable flows that are responsible of single tasks
• Enable logs with the right levels depending on the scope
• Avoid chatty flows
• Reduce the use of local variables and try to store only simple values, not large sets of records
• Load test should be done in earlier phases to assess design