The Mumbai Mulesoft Meetup on November 21, 2020, focused on Mulesoft code review automation with SonarQube, RAML best practices, and DataWeave functions. Participants were encouraged to keep their video on for interactivity, and important announcements included the Mulesoft hackathon deadline. The event featured discussions on coding techniques, API design, and practical sessions for improving development practices.

1. 21st November 2020
Mumbai MuleSoft Meetup Group
Sonar-Qube , RAML Best Practices , Data weave
Functions

2. Guidelines for Mumbai MuleSoft Meetup #15
[Virtual]
● Welcome to Mumbai MuleSoft Meetup! We will start our introduction session at 5 pm IST.
● Once you join write down your registered name in chat section so that we can provide you
audio/video access in Bevy.
● Please keep yourself muted unless you have any question.
● We encourage keeping your video on for making our meetup interactive.
● You'll can also write down your questions in chat section.
● We appreciate your valuable feedback. Thanks.
2

3. 3
● Introductions
● Mulesoft Code Review Automation Using SonarQube
● RAML Best Practices
● Dataweave Functions – Mule 4.3
● Quiz
● Networking time
Agenda

4. 4
●About the organizer:
○ Sudeshna Mitra
○ Manish Yadav
○ Akshata Sawant
●About the sponsor:
○ MuleSoft
Introductions
A SHOW OF HANDS:
Who is new to this Meetup?

5. Important Announcements

6. Latest Releases/News
● Reminder: The MuleSoft Hackathon ends Nov. 29, 2020
There is still time to register and submit a project for the MuleSoft Hackathon 2020! If you are
interested in participating, the deadline to register and submit is Nov. 29, 2020 at 11:59pm PT.
Register -> http://mulesoft.com/hackathon2020
● Anypoint Studio 7.7 release
Blog - Streamlining the development experience with Studio 7.7
6

7. Speakers
7
Supriya Pawar
Technical
Delivery Team
Lead at
Accenture
Sumit Ahuja
Senior
Software
Developer at
Accenture

8. Mulesoft Code Review Automation
Using SonarQube

9. 9
● Consistent design and implementation
● Minimizing your mistakes and their impact
● Ensuring project quality and meeting requirements
● Improving code performance
● Sharing new techniques
Why is code review important ?

10. 10
Code Review using Sonar

11. Prerequisites
● Download and install SonarQube Community Edition
● Download and setup Java SDK 11
● Install and build Mule SonarQube Plugin
11

12. 12
Run command on plugin master - mvn clean package sonar-packaging:sonar-plugin -Dlanguage=mule
Config changes and jar creation

13. 13
Rules addition and Start the sonar

14. 14

15. 15
Run the command on code - mvn sonar:sonar -Dsonar.host.url=http://localhost:9000

16. 16
Sonar UI

17. 17
Code Review
Report

18. Conclusion
Automating the code review process reduces the delivery time and
human error and SonarQube is a good fit for the Mulesoft Automated
Code Review tool as it sets a collection of rules to analyze your
source code at compile time to identify potential vulnerabilities, bugs,
anti-patterns, refactoring, and poor coding practices.
18

19. RAML (API) Best Practices

20. 20
What is RAML ? Why we use it ?

21. Best Practices in RAML ?
● Use Spec Driven Development
● Think about the API
● Modularize and Reuse
● Mocking
● Resources and Naming
● HTTP Codes and Verbs
21

22. 22

23. Use Spec Driven Development
● Use Design Patterns/ Code Reuse.
● Mock and get User Feedback.
● Make Necessary Changes.
● Start Coding to the Spec and don't deviate.
23

24. Benefits of Spec Driven
● Parallelize the development process
● Improves understanding of the whole
● Guide Development
24

25. Think about the API
25

26. Think of a Long term
● Your API is a Contract
● Versioning is not a Solution
● You can pay a little now , or much more Later.
● You need to think things through
● Mindset is everything
26

27. Think Things Through
● Who is your API for ?
● What type of API are you building ?
● How are you going to maintain your API ?
● How are you going to document your API ?
● How are you going to lets users interact with your API ?
● How are you going to manage authentication, provisioning and developer security ?
● How are going to protect your servers against attacks etc ?
● How are you going to manage support ?
27

28. Who Will Be Using Your API?
28

29. Versioning – A Necessary Evil
● Problems with versioning :
○ Backward Incompatibilities
○ Multiple services to maintain
○ Multiple systems to support
○ Creates Confusion among developers
29

30. Modularize and Reuse (RAML Inheritance)
● This can be Best achieved using the below two features :
○ Resource Types
■ ResourceType is basically a template that is used to define the descriptions, methods, and parameters that
can be used by multiple resources without writing the duplicate code or repeating code.
○ Traits
■ Traits is like function and is used to define common attributes for HTTP method (GET, PUT, POST,
PATCH, DELETE, etc) such as whether or not they are filterable, searchable, or pageable.
30

31. Defining Resource Types
31

32. Calling resource Types from RAML
32

33. Declaring Traits
33

34. Calling Traits from Resource Types and Resources
34

35. Mocking
● The API mocking service enables you simulate the behavior of an API specification. The
mocking service provides a test link to an API. The mocking service returns the responses
(both HTTP status codes and example payloads) that are defined in your API specification
and is valuable for testing or for simply exploring how your API behaves.
● Simulate a Call to an API using an Internal URL
● Simulate a Call to an API using a Public URL
35

36. Simulate a Call to an API using an Internal URL
36

37. Simulate a Call to an API using a Public URL
37

38. Resources and Naming
● Use of camelCase for placeholders in URL.
● Use nouns in lowercase to represent a resource, for resources with multiple words, use
lowercase for all the words or use '-' (dash) in between the words and make it readable.
● Use of Parameters:
○ URI Parameter
○ Query Parameter
38

39. Example
39

40. HTTP Codes
● 1xx : Informational
● 2xx : Success
● 3xx : Redirect
● 4xx : Client error
● 5xx : Server error
40

41. HTTP verbs
● GET
● PUT
● PATCH
● POST
● DELETE
41

42. Data weave Functions

43. Modules
● Core (dw::Core)
● Arrays (dw::core::Arrays)
● Crypto (dw::Crypto)
● Binaries (dw::core::Binaries)
● URL (dw::core::URL)
● Values (dw::util::Values)
43

44. Core (dw::Core)
● entriesOf
● keysOf
● namesOf
● valuesOf
44

45. entriesOf – Mule 4.3
45

46. keysOf – Mule 4.3
46

47. namesOf – Mule 4.3
47

48. valuesOf – Mule 4.3
48

49. Arrays (dw::core::Arrays)
● drop
● dropWhile
● every
● firstWith
● partition
● some
● splitAt
● splitWhere
● take
● takeWhile
49

50. drop
50

51. dropWhile
51

52. every
52

53. firstWith
53

54. partition
54

55. some
55

56. splitAt
56

57. splitWhere
57

58. take
58

59. takeWhile
59

60. Crypto (dw::Crypto)
60
● HMACBinary
● HMACWith
● MD5

61. HMACBinary
61

62. HMACWith
62

63. MD5
63

64. Binaries (dw::core::Binaries)
● fromBase64
● toBase64
● fromHex
● toHex
64

65. toBase64
65

66. fromBase64
66

67. toHex
67

68. fromHex
68

69. URL (dw::core::URL)
69
● encodeURI
● decodeURI

70. encodeURI
70

71. decodeURI
71

72. Values (dw::util::Values)
72
● mask
● update

73. mask
73

74. update
74

75. 75
Nominate yourself for the next meetup
speaker and suggest a topic as well.
Take a stand!

76. 76
● Share:
○ Tweet using the hashtag #MuleSoftMeetups
○ Invite your network to join: https://meetups.mulesoft.com/mumbai/
● Feedback:
○ Fill out the survey feedback and suggest topics for upcoming events
○ Contact MuleSoft at meetups@mulesoft.com for ways to improve the program
○ Contact your organizers Manish Yadav, Sudeshna Mitra and Akshata Sawant to
suggest topics
○ Tweet your organizers at @SudeshnaMitra14, @Manish_Kyadav,
@sawantakshata02
○ Follow us on Instagram (mumbai_mulesoftofficialpage)
○ Telegram: https://t.me/joinchat/Q6y-MgriEqyDicfZV9PIAg
What’s next?

77. Introduce yourself to your neighbor
Networking time

78. Thank you