![]()
CHAPTER 1
MuleSoft Fundamentals
In this chapter we will discuss the following topics:
- What is MuleSoft?
- History of MuleSoft
- MuleSoft as open-source ESB
- MuleSoft as API Led Connectivity
- Explore MuleSoft Website and Materials
Objectives
After studying this unit, you should be able to:
- Have a clear vision about MuleSoft ecosystem
- Access various MuleSoft materials
- Interact with MuleSoft community
About target audience
The target audience of the book series may be ranging from fresher, non-IT members, the business community, technology aspirants, and C-Suite members. This book will talk about MuleSoft technology in-depth, how to design and implement larger enterprise integration where the enterprise will have 1000 plus branches across global and the enterprise may not have modern architecture like API Led Connectivity and connectivity to niche applications like Salesforce, FinancialForce, Workday, Coupa, etc.
About the book design
This book is designed to address the upcoming common Information Technology audience who wish to become an integral part of a niche technology that will be playing a predominant position in the coming 20 years of Information technology history.
We planned to release 10 + volumes of books which will cover most of the MuleSoft technology features from basics to advanced concepts. The first 8 volumes will cover topics as given below:
- volume 1: Mastering MuleSoft – RAML, API Design
- volume 2: Mastering MuleSoft - Anypoint Studio - Components and Flows
- volume 3: Mastering MuleSoft – Core Connectors like DB, FILE, JMS, ObjectStore, etc.
- volume 4: Mastering MuleSoft – SaaS Connectors like Box, Slack, Stripe, etc
- volume 5: Mastering MuleSoft – Data Weave Language and Transformations
- volume 6: Mastering MuleSoft – DevOps for MuleSoft (Maven, Jenkins, Docker, Kubernetes, etc)
- volume 7: Mastering MuleSoft – WorkDay Integrations
- volume 8: Mastering MuleSoft – Internet of Things
We are not sure about the forthcoming volumes other than the titles listed above but may cover topics like Integrating with SAP, Collibra, Concur, Salesforce, ServiceNow, Coupa, FinancialForce, RPA, etc. in future.
Before starting
It is nice to know a few aspects of software evolution in the past 20 years; this is a must to know facts especially for the fresher and non-IT audience. Java started as a strongly typed internet programming language before 2000 and so many programming paradigms got added like Applets, JDBC, JSP, Beans, RMI, Corba, EJB, Struts, Spring, Web Services, SOA, ESB, etc. in the next 20 years.
It is strongly recommended for you to explore concepts like System Integration, Cloud Computing, DevOps, BigData, Docker, Kubernetes, SaaS, IaaS, PaaS, Puppet, Robotics, Internet of Things, etc. Also, try to understand the scenarios for Enterprise Service Bus space; anyways we will be explaining these concepts throughout this series.
Another important nice to have knowledge is about corporate companies, which means, you must explore case studies about larger enterprises like McDonalds, Mckesson who will have a global presence and they will be using advanced software suites like SAP and Salesforce for different business domains. This is important for you to understand how data will be exchanged between different systems in different formats and protocols.
Even if you are coming under, functional, non-IT, or non-development team, you will be able to design and manage multiple Application Programming Interfaces (API) without bothering much about how the APIs will be developed and implemented.
MuleSoft-background
As we mentioned earlier when concepts like SOA and System Integrations evolved, we got another interesting area called Enterprise Service Bus (ESB). ESB is architecture to integrate different systems using a centralized messaging system, meaning; different systems can post and receive data through a central message bus. The data may come in a different format, maybe a text file, CSV, Email, XML, or the data may be in a corporate format like SWIFT, IATA, HIPPA, etc. Also, the protocols may vary like SMTP, FTP, SFTP, etc.
The ESB developers will be receiving these data from the source systems messaging queue and they will do transformations and will give it back to the destination systems. MuleSoft started as an open-source ESB server and later enhanced its capabilities to address the API Led connectivity architecture. Let us start exploring the latest MuleSoft technology, API Led model, API Management, API design, and other concepts throughout this book.
ESB (Enterprise Service Bus)
For an enterprise, the enterprise service bus act as a central spine where different systems in different departments can exchange data. Those systems may be developed by different software companies across the globe using different technologies like Java, .NET, or PHP. These systems will be having different databases like Oracle, MySQL, etc. Now, if a sales team wants to send the opportunities or the deals won by the sales team to a finance team where billing and invoicing will be handled by them. These two systems that are customer relationship application and billing and invoicing application may have different databases application and different ways of sharing data for example customer relationship application may share the data in CSV file as CSV file, billing, and invoicing application may share the data as an XML file. Different ways of sharing data, for example, customer relationships. These two systems may share the data through different protocols, that means the sales application will share the CSV file through e-mail protocol, whereas the finance application may prefer to use secured file transfer protocol, meaning the finance application wants to store the XML files in a secured file folder so that the authorized other departments’ applications can access that. If an enterprise having multiple departments then has multiple applications and those applications need to exchange data for various workflows then those enterprises should implement an ESB platform and that enterprise service bus platform is the MuleSoft ESB platform.
MuleSoft ESB platform has been developed as an open-source project by Mike Ross on say December 2006. MuleSoft ESB developers can developer MuleSoft flow components for various data transactions between applications of different departments that means the MuleSoft flow will be having the access privileges to get the files from a secured file system or an email or through some web services like RESTful and SOAP, or by accessing particular Message queues. Now we can understand MuleSoft has been designed to access various protocols like email, SFTP, database, etc. The ESB developers are responsible for data transformation also data transmission means read the sales information from sales application via email as CSV format and convert those data into XML format and save these XML files inside the secured file system of the finance publications. Also, data transformation will be used for extracting the information need by the finance system, meaning the sales application may expose 50 fields to the MuleSoft flow component but the finance application requires only 35 fields. So MuleSoft developers have to understand the finance application and they have to develop XML file content based on the CSV file contents.
The next complex scenario will be the ESB developers will be interacting with multiple source systems they may have to merge all system data and they may have to distribute the merged file to multiple destination systems. As I already mentioned please explore different industry-standard data formats like data, swift, hippa, peci, picof which are used for various business domains.
In a nutshell, the enterprise service bus MuleSoft flow will be responsible for accessing multiple protocols, getting data I different formats, transforming the data like merging, filtering then routing the data to a destination system so this data transaction can happen when we are adding a record in the database or when a messaging queue receives a new message or when an email inbox receives a new message or a scheduled job can invoke the mule flow on a particular time everyday or a scheduled batch update can happen between a source and a destination system.
API LED connectivity
There is a phenomenal transformation for MuleSoft in recent days which are called API LED connectivity. In the last paragraph, you would have understood that the enterprise service bus will be talking to various applications based on their preferred protocol data format.
After the introduction of service-oriented architecture, all these applications started exposing their data through web services that are restful and soap so that every application can maintain a web service catalog, meaning a finance application can expose their finance data by creating a restful web service so that the MuleSoft developer no need to directly accessing the source systems file folder, database, etc. Instead, they can talk to the API’s if the source systems and destination systems. It doesn’t mean the developers shouldn’t access the endpoints of the source and destination systems like database, secured folders, etc. so the current scenario of API led connectivity will be a combinatio...
