MuleSoft for Salesforce Developers E-Book

Akshata Sawant

• Herausgeber: Packt Publishing
• Kategorie: Wissenschaft und neue Technologien
• Sprache: Englisch

Seitenzahl: 507

Veröffentlichungsjahr: 2025

Beschreibung

Salesforce developers often need help with complex integrations to manage multi-cloud environments, data mapping, data security, API scalability, and real-time integration issues. Written by industry veterans with 20+ years of experience, this revised edition will help you overcome these challenges and unlock data with MuleSoft.
In this second edition, you’ll learn about MuleSoft’s newest IDE (aka Anypoint Code Builder) and its tools and capabilities. The chapters will show you how to use AI-enabled APIs to maximize productivity, integration of Data Cloud with MuleSoft, Mule APIs with AI agents, and Mule AI Chain connectors. You’ll grasp the fundamentals of APIs and integration and confidently design your APIs, while also utilizing a no-code visual editor for API design to build your Mule applications using MuleSoft’s Anypoint Code Builder. The chapters will teach you about data transformation, API management, deployment models, and MuleSoft’s security features. Progressively, you’ll leverage MuleSoft connectors to integrate with Salesforce, Data Cloud, and other systems. You’ll explore AI-driven integrations and automation, and get practical tips to ace MuleSoft interviews and achieve MCD Level 1 certification.
By the end of this book, you’ll be able to implement the entire API lifecycle and manage complex integrations with MuleSoft like a pro.

Leseprobe

MuleSoft for Salesforce Developers

A complete guide for achieving Mulesoft certification readiness and building AI-driven API solutions

Akshata Sawant

Arul Christhuraj Alphonse

MuleSoft for Salesforce Developers

Copyright © 2025 Packt Publishing

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.

Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the authors, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.

Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.

Portfolio Director: Pavan Ramchandani

Relationship Lead: Alok Dhuri

Program Manager: Divij Kotian

Content Engineer: Nisha Cleetus

Technical Editor: Kavyashree K S

Copy Editor: Safis Editing

Proofreader: Nisha Cleetus

Indexer: Tejal Soni

Production Designer: Vijay Kamble

Growth Lead: Nivedita Singh & Priya Bhanushali

First published: September 2022

Second edition: February 2025

Production reference: 3111125

Published by Packt Publishing Ltd.

Grosvenor House

11 St Paul’s Square

Birmingham

B3 1RB, UK

ISBN 978-1-83588-232-0

www.packtpub.com

To my parents, Arun and Swati Sawant, for their endless efforts and sacrifices, and to my love, Dan, for being my unwavering support.

-- Akshata Sawant

To the memory of my father, Alphonse, and my mother, Esther RajaRathinam, for their sacrifices and love.

– Arul Christhuraj Alphonse

Contributors

About the authors

Akshata Sawant is a Senior Developer Advocate at Salesforce based in London. A distinguished technical speaker, she was named Rising Star of the Year (UK) 2024 by Digital Revolution Awards. Despite a short career span, she has spoken at top conferences, including Dreamforce, London’s Calling, Salesforce TDX, Devoxx Belgium, DevOpsDays Geneva, and APIDays. Beyond speaking, Akshata is a prolific writer, regularly publishing blogs and articles. She also conducts training sessions and workshops for the Salesforce community. Born in Mumbai, she now shares knowledge globally through talks, podcasts, blogs, and livestreams. Connect with her on LinkedIn to explore APIs, AI, and Integration.

I am deeply grateful to my parents for their love and sacrifices, and to my best friend and partner, Dnyaneshwar Mundhe, for being my constant source of motivation and pillar of support.

My heartfelt thanks to God and my spiritual guru, whose grace and blessings have made all of this possible.

A special thank you to my brother, Shubham, and my in-laws, family, and friends, mentors; my team at Salesforce; and the MuleSoft Community for their love and support. Ambadnya!

 

Arul Christhuraj Alphonse is a senior integration architect based in Singapore with over 20 years of experience in the integration and API domain. He has worked at Akmin Technologies, Quinnox, IBM, TCS, and Cognizant, designing over 1,000 integrations. Arul holds a Master of Computer Applications and an MBA, along with multiple certifications, including MuleSoft Mentor, MuleSoft Certified Integration Architect, and SoftwareAG webMethods Certified Professional. Passionate about sharing knowledge, he creates courses on Udemy and runs the Tech Lightning YouTube channel. Born in Thoothukudi, Tamil Nadu, India, he now lives in Singapore, contributing to the global tech community.

I thank God as none of this would have been possible without him. I would also like to thank my loving and understanding wife, Sahaya Divya, my son, Rithwin, my daughter, Riya, and my family for their unwavering support, patience, and encouragement throughout the long process of writing this book.

About the reviewers

Gaurav Kheterpal is a prominent figure in the Salesforce ecosystem. A Salesforce Hall of Fame inductee and MuleSoft Ambassador, he holds over 50 Salesforce certifications and 5 MuleSoft certifications. Ranked among the top three globally certified experts in the Salesforce and MuleSoft ecosystems, Gaurav has been recognized by Salesforce as a Developer Success Story and a Trailblazer. He has delivered sessions at major events, including Dreamforce, TrailheaDX, Salesforce World Tour, London’s Calling, and more. Passionate about evangelizing the Salesforce and MuleSoft platforms, Gaurav is dedicated to fostering growth and innovation within the broader community.

Anurag Sharma is a distinguished technologist renowned for designing secure and scalable systems across middleware and core technology solutions. With expertise in API design, cloud-native development, integration strategies, and automation frameworks, he has delivered impactful solutions in industries such as retail, healthcare, and financial services. Anurag holds certifications in MuleSoft and leading cloud platforms like AWS and Google Cloud. He specializes in CI/CD pipelines and API security and is recognized as a MuleSoft Ambassador. Anurag is a mentor, speaker at global industry events, and a contributor to technical literature, inspiring and guiding the next generation of tech experts worldwide.

D. Rajesh Kumar is an Enterprise Architect with over 18 years of IT experience, including more than a decade specializing in MuleSoft and integration technologies. He is an expert in platform setups, architecture design, and establishing Centers of Excellence (COE) and Centers for Enablement (C4E). His deep understanding of architectural and integration best practices has enabled him to lead and successfully deliver complex projects. A Certified MuleSoft Architect and MuleSoft Ambassador, Rajeshkumar is a thought leader who has authored technical blogs, presented at conferences, and hosted meetups on advanced MuleSoft topics, integration strategies, and architectural patterns. His previous professional experience includes roles at Infosys, HCL, and Jamcracker.

Table of Contents

Preface

Free Benefits with Your Book

Part 1: Getting Started with MuleSoft

1

Introduction to APIs and MuleSoft

Understanding the need for an integration tool

Introducing no-code and low-code technologies

Analyzing integrations

Understanding APIs

Reviewing the restaurant analogy

Exploring an API example

Analyzing API components

Listing the benefits of using APIs

Introducing MuleSoft

Listing MuleSoft’s products

Understanding why MuleSoft is useful

Analyzing how MuleSoft helps Salesforce developers

Exploring application networks and the API-led connectivity approach

Understanding what application networks are

Analyzing the API-led connectivity approach

Summary

Questions

Answers

2

Designing Your API

Understanding an API life cycle

Introducing REST and SOAP

REST

Introducing HTTP

SOAP

Getting started with OAS and RAML

OAS

RAML

Getting started with API design

URI parameter

Query parameter

API mocking

Alternative ways to design your API

Designing your API with a guided approach

Designing your API in Anypoint Code Builder

Best practices and tips

API design naming convention

Optimizing your API design

Summary

Practice

Questions

Answers

3

Exploring Anypoint Studio and Anypoint Code Builder (ACB)

Technical requirements

Downloading and installing Anypoint Studio

Downloading Anypoint Studio

Installing Anypoint Studio

Launching Anypoint Studio

Introducing Mule Palette

Exploring the Mule project structure

Introducing Mule views and perspectives

Views

Perspectives

Building, running, and testing a Mule application

Building the Mule application

Running the Mule application

Testing the Mule application

Exporting and importing Mule files

Exporting a Mule application as a JAR file

Exporting a Mule application as a filesystem

Importing a Mule application from a JAR file

Importing a Mule application from the filesystem

Updating the theme in Anypoint Studio

Installing software updates in Anypoint Studio

Exploring Anypoint Code Builder (ACB)

Installing Anypoint Code Builder on the desktop

Designing an API using Anypoint Code Builder (ACB)

Publishing an API from Anypoint Code Builder (ACB) to Exchange

Develop an Integration from Anypoint Code Builder (ACB)

Exploring Anypoint Code Builder in cloud IDE

Summary

Questions

Answers

4

Introduction to Core Components

Technical requirements

Getting familiar with a Mule flow

Exploring the types of Mule flow

Understanding the Mule event structure

Core components

Batch

Features of the Batch scope

The batch processing stages

A batch step

The batch aggregator

The batch job

Components

Custom Business Event

Dynamic Evaluate

Idempotent Message Validator

Invalidate Cache

Invalidate Key

Logger

Parse Template

Set Transaction Id

Transform Message

Endpoints

A Scheduler component

Error handling

On Error Continue

On Error Propagate

Raise Error

Error Handler

Flow control

Choice

First Successful

Round Robin

Scatter-Gather

Scopes

Async

Cache

Flow

For Each

Parallel For Each

Sub Flow

Try

Until Successful

Transformers

Set Variable

Remove Variable

Set Payload

Summary

Assignments

Questions

Answers

5

All About Anypoint Platform

Technical requirements

Introducing Anypoint Platform

Getting started with Design Center

API Designer

Introducing Exchange

The public portal

Exploring Runtime Manager

CloudHub 2.0

Deploying a Mule application to CloudHub

Managing a Mule application

Runtime Manager alerts

Anypoint VPC – virtual private cloud

Load balancers

Introducing API Manager

Exploring Anypoint Monitoring

Alerts

Log Management

Introducing Anypoint Visualizer

Exploring Access Management

Organization and business groups

Invite user

Roles

Environments

Audit logs

Subscription

Summary

Questions

Answers

Part 2: A Deep Dive into MuleSoft

6

Learning DataWeave

Technical requirements

Introducing DataWeave

Analyzing DataWeave

Diving into a script’s anatomy

Adding comments to your code

Understanding data types

Understanding data formats

Writing DataWeave scripts

Using operators

Creating and using variables

Defining and calling functions

Retrieving data with selectors

Understanding scopes and flow control

Summary

Questions

Answers

7

Transforming with DataWeave

Technical requirements

Understanding modules in DataWeave

Importing modules and functions

Analyzing the existing DataWeave modules

Using the DataWeave Core functions

Transforming multiple types

Transforming numbers

Transforming strings

Transforming objects

Transforming arrays

Using the Transform Message component in Anypoint Studio

Exploring the views

Defining metadata

Creating custom modules

Summary

Questions

Answers

8

Building Your Mule Application

Technical requirements

Exploring different types of configuration files

Mule configuration file

Properties file

POM

Introducing Scheduler

Creating a Mule application with the Scheduler component

Generating a flow using APIkit Router

Creating a Mule application using API Specification

Running and testing a Mule application

Exploring Object Store Connector

Different types of Object Store

Creating a Mule application with Object Store Connector

Summary

Questions

Answers

9

Deploying Your Application

Technical requirements

Getting started with deployment models

Types of deployment models

Choosing the right deployment model

Deploying your Mule application to CloudHub

Deploying your Mule application on an on-premises server

Building a CI/CD pipeline with MuleSoft

The Mule Maven plugin

Summary

Assignments

Questions

Answers

10

Securing Your API

Technical requirements

The need for API security

API security with MuleSoft

Introducing API Manager

Understanding the capabilities of API Manager

Understanding the API gateway

Policies in MuleSoft

Security

Compliance

Transformation

Quality of service

Troubleshooting

Custom policies

Implementing API security using policy

API Autodiscovery

Configuring a security policy

The security capabilities of MuleSoft

Anypoint Security

Anypoint Flex Gateway

Summary

Assignments

Questions

Answers

11

Testing Your Application

Technical requirements

Introduction to testing

Getting familiar with testing tools

Postman

SoapUI

JMeter

Introducing MUnit

Creating a test suite

Exploring the MUnit Test Recorder

Creating a test suite using the Test Recorder

Summary

Assignment

Questions

Answers

Part 3: Integration with Salesforce and Other connectors

12

MuleSoft Integration with Salesforce

Technical requirements

Exploring Salesforce connectors

Configuring a Salesforce connector

Adding a Salesforce connector

Discovering accelerators and templates for Salesforce

Getting started with accelerators

Exploring templates

Getting Started with External Services

Exploring the Prerequisites for Mule API

Exploring MuleSoft’s integration capabilities with Salesforce

The Bulk API

CDC events

Data analytics tools

Summary

Assignments

Questions

Answers

13

MuleSoft Connectors and Use Cases

Technical requirements

Introducing connectors

Exploring File Connector, FTP Connector, and SFTP Connector

File Connector

FTP Connector

SFTP Connector

Understanding Database Connector and watermarking

Watermarking

Configuring Web Service Consumer Connector

Publishing and subscribing using VM Connector

Operations

Publishing and listening to a message

Exploring JMS Connector

Operations

JMS Connector configuration

Introducing MuleSoft accelerators

Summary

Questions

Answers

14

MuleSoft Best Practices, Tips, and Tricks

MuleSoft best practices

General best practices

Mule projects best practices

Anypoint Platform best practices

Tips and tricks

Summary

Questions

Answers

15

Certification and Interview Tips

Choosing your career path

Getting MuleSoft certified

Expanding your knowledge with official training

Developer training

Architect training

Operations training

Contributing to the MuleSoft Community

Expanding your knowledge with MuleSoft meetups

Helping others as a MuleSoft Mentor

Becoming a MuleSoft Ambassador

Getting help with the MuleSoft forums

Passing your interview

Summary

Questions

Answers

16

AI and Automations with MuleSoft

Automations with MuleSoft Composer

Capabilities of MuleSoft Composer

Configuring MuleSoft Composer

Introduction to MuleSoft RPA

Automating your document processing with IDP

Getting started with IDP

Creating your first Document Actions

Testing the Document Action

Integrating Mule APIs with Agentforce

Introduction to Agentforce

Building intelligent integrations

Summary

Questions

Answers

17

Unlock Your Exclusive Benefits

Unlock this Book’s Free Benefits in 3 Easy Steps

Index

Other Books You May Enjoy

Preface

MuleSoft for Salesforce Developers will help you build cutting-edge enterprise solutions with flexible and scalable integration capabilities using MuleSoft’s Anypoint Platform and Anypoint Studio. If you’re a Salesforce developer looking to get started with this powerful tool, this book will get you up to speed quickly, enhancing your integration developer skills.

Complete with step-by-step explanations of key concepts, practical examples, and self-assessment questions, this guide begins by introducing the fundamentals of MuleSoft and API-led connectivity. It then walks you through the API lifecycle and the Anypoint Studio IDE, preparing you to create Mule applications. You’ll explore the core components of MuleSoft and the Anypoint Platform, gaining expertise in building, transforming, securing, testing, and deploying applications using a wide range of components. Finally, you’ll learn how to use connectors to integrate MuleSoft with Salesforce to address various use cases, as well as receive valuable tips for certification and interviews.

By the end of this book, you will feel confident building MuleSoft integrations at an enterprise scale. This book will also prepare you to pass the fundamental MuleSoft certification: MuleSoft Certified Developer (MCD) – Level 1.

Who this book is for

This book is designed for Salesforce developers who want to get started with MuleSoft. As demand grows for cross-cloud solutions that integrate MuleSoft with Salesforce or its cloud offerings (such as Service Cloud, Marketing Cloud, and Commerce Cloud), this book will serve as an essential resource. Salesforce architects will also find the concepts covered useful for designing Salesforce solutions.

Basic knowledge of a programming language and familiarity with integration concepts will be helpful. Some experience with Salesforce development and Salesforce APIs (SOAP API, REST API, Bulk API, or Streaming API) is expected.

What this book covers

Chapter 1, Introduction to APIs and MuleSoft, covers no-code and low-code technologies, APIs and integrations, MuleSoft products, application networks, and the API-led connectivity approach.

Chapter 2, Designing Your API, explores the API lifecycle and how to create API specifications using RAML, HTTP web services, and API fragments. This chapter also includes adding documentation to APIs and downloading API specifications from the Anypoint Platform.

Chapter 3, Exploring Anypoint Studio and Anypoint Code Builder (ACB), covers how to download and install Anypoint Studio and Anypoint Code Builder, develop a new Mule application, and run it in both tools.

Chapter 4, Introduction to Core Components, examines fundamental MuleSoft components, including flow controls (Choice Router, First Successful, Round Robin, and Scatter-Gather), scopes (Flow, Subflow, For Each, Parallel For Each, Async, Cache, Try, and Until Successful), and error handling scenarios.

Chapter 5, All About Anypoint Platform, delves into the components of Anypoint Platform, including Design Center (API Designer), Exchange, API Manager, Runtime Manager, and Anypoint Monitoring. By the end of this chapter, you’ll understand how to create an API using Design Center, publish the API in Exchange, create the API in API Manager to enforce policies, utilize Runtime Manager, and monitor applications on Anypoint Platform.

Chapter 6, Learning DataWeave, introduces DataWeave for beginners. It covers the basics, including what DataWeave is, how to create scripts, how to add comments, and details on data types, data formats, operators, variables, functions, selectors, scopes, and conditionals.

Chapter 7, Transforming with DataWeave, delves deeper into DataWeave modules and some of the most commonly used functions in real-world scenarios. It also covers how to use the Transform Message component to work with DataWeave in Anypoint Studio.

Chapter 8, Building Your Mule Application, teaches you how to build a Mule application using various configuration and properties files. It also discusses the Scheduler Endpoint, APIkit router, and Object Store.

Chapter 9, Deploying Your Application, covers the different deployment options available in MuleSoft. This chapter explains how to deploy an application to CloudHub, how to download and install a Mule on-premises server, and how to deploy the Mule application to the on-premises server.

Chapter 10, Securing Your API, focuses on creating and applying policies in Anypoint Platform, securing configurations, exposing Mule applications via HTTPS, and handling encryption and decryption.

Chapter 11, Testing Your Application, introduces MUnit and MUnitTools, along with different operations. It demonstrates how to create test suites and test cases using MUnit, and explores how MUnit can speed up the development process, including the use of the test recorder.

Chapter 12, MuleSoft Integration with Salesforce, explains how to integrate MuleSoft with Salesforce CRM using the Salesforce connector. It covers two integration approaches: API-based, where you access Salesforce objects via the API for real-time data, and event-based, where you listen to Salesforce topics and process the messages synchronously to the required backend system.

Chapter 13, MuleSoft Connectors and Use Cases, explores various MuleSoft modules (File, FTP, SFTP, Database, Slack, SOAP, VM, and JMS). In the File-based module (File, FTP, SFTP), you’ll learn to connect to systems and read files, as well as send files via different connectors. The Database module shows how to configure connectors to specific databases and read/insert records. This chapter also covers modules such as Slack, Web Service Consumer (SOAP), VM, and JMS connectors.

Chapter 14, MuleSoftBest Practices, Tips, and Tricks, provides guidelines on MuleSoft best practices, coding standards, and useful tips and tricks.

Chapter 15, Certification and Interview Tips, explores career paths within the MuleSoft ecosystem. It discusses MuleSoft certifications, tips for getting certified, available training options, how to contribute to the MuleSoft community, and interview tips for landing your first MuleSoft position.

Chapter 16, AI and Automations with MuleSoft, covers Automations with MuleSoft Composer, an introduction to MuleSoft RPA, automating document processing with IDP, and integrating Mule APIs with Agent Force.

To get the most out of this book

You will need Anypoint Studio 7.x installed on your computer – preferably the latest version. The examples in this book have been tested using Anypoint Studio 7.17 on macOS, but they should work with future minor versions as well.

You will also need a web browser to access Anypoint Platform and the DataWeave Playground. The examples have been tested using Google Chrome on macOS, but other browsers such as Safari or Firefox should work as well.

Finally, you’ll need a REST client application installed on your computer to make requests to APIs. The examples have been tested using Postman v9 on macOS and Windows, but other tools like Advanced REST Client or curl should also work.

Software/hardware covered in the book

Operating system requirements

Anypoint Studio 7.17

Windows or macOS

Anypoint Platform and MuleSoft Composer

Any browser

Postman or any similar API client tool

Postman v9 (Windows 64-bit), Mac (Intel chip/Apple chip), or Linux (x64)

Google Chrome

Windows or macOS

If you are using the digital version of this book, we advise you to type the code yourself or access the code from the book’s GitHub repository (a link is available in the next section). Doing so will help you avoid any potential errors related to the copying and pasting of code.

Download the example code files

You can download the example code files for this book from GitHub at https://github.com/PacktPublishing/MuleSoft-for-Salesforce-Developers-Second-Edition. If there’s an update to the code, it will be updated in the GitHub repository.

We also have other code bundles from our rich catalog of books and videos available at https://github.com/PacktPublishing/. Check them out!

Conventions used

There are a number of text conventions used throughout this book.

Code in text: Indicates code words in the text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles. Here is an example: "To configure it, you can set the initial state to started or stopped. "

A block of code is set as follows:

asyncapi: '2.0.0' info:   title: MusicAsyncAPI   version: '1.0.0' channels: {}

Bold: Indicates a new term, an important word, or words that you see onscreen. For instance, words in menus or dialog boxes appear in bold. Here is an example: "Provide the path where it needs to be extracted and click Extract."

Tips or Important Notes

Appear like this.

Get in touch

Feedback from our readers is always welcome.

General feedback: If you have questions about any aspect of this book, email us at [email protected] and mention the book title in the subject of your message.

Errata: Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you have found a mistake in this book, we would be grateful if you would report this to us. Please visit www.packtpub.com/support/errata and fill in the form.

Piracy: If you come across any illegal copies of our works in any form on the internet, we would be grateful if you would provide us with the location address or website name. Please contact us at [email protected] with a link to the material.

If you are interested in becoming an author: If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, please visit authors.packtpub.com.

Share Your Thoughts

Once you’ve read MuleSoft for Salesforce Developers, we’d love to hear your thoughts! Please click here to go straight to the Amazon review page for this book and share your feedback.

Your review is important to us and the tech community and will help us make sure we’re delivering excellent quality content.

Free Benefits with Your Book

This book comes with free benefits to support your learning. Activate them now for instant access (see the “How to Unlock” section for instructions).

Here’s a quick overview of what you can instantly unlock with your purchase:

PDF and ePub Copies

Next-Gen Web-Based Reader

Access a DRM-free PDF copy of this book to read anywhere, on any device.

Use a DRM-free ePub version with your favorite e-reader.

Multi-device progress sync: Pick up where you left off, on any device.

Highlighting and notetaking: Capture ideas and turn reading into lasting knowledge.

Bookmarking: Save and revisit key sections whenever you need them.

Dark mode: Reduce eye strain by switching to dark or sepia themes

How to Unlock

Scan the QR code (or go to packtpub.com/unlock). Search for this book by name, confirm the edition, and then follow the steps on the page.

Note: Keep your invoice handly. Purchase made directly from packt don't require one.

Part 1: Getting Started with MuleSoft

Part 1 introduces you to MuleSoft, the capabilities of Anypoint Platform, and the process of designing an API. It also covers the core components of Anypoint Studio and Anypoint Code Builder. We will explore various components of Anypoint Platform. At the end of this part, we will be familiar with the features and capabilities of Anypoint Platform, Anypoint Studio, and Anypoint Code Builder. We will also gain hands-on experience in designing an API.

The part includes the following chapters:

Chapter 1, Introduction to APIs and MuleSoftChapter 2, Designing Your APIChapter 3, Exploring Anypoint Studio and Anypoint Code Builder (ACB)Chapter 4, Introduction to Core ComponentsChapter 5, All About Anypoint Platform

1

Introduction to APIs and MuleSoft

The world is changing. Technologies keep emerging. There is a greater need for technology now than there used to be, and it’s not a coincidence. In the past, problems were simpler, and the solutions, while not perfect, were sufficient. Now, we’re overwhelmed with countless technologies offering different ways to achieve the same goals. We’re constantly introduced to new programming languages, frameworks, and methodologies. Today, AI-driven tools, such as ChatGPT, Copilot, and Google Gemini, are at the forefront, while what was popular yesterday quickly becomes obsolete. How can we keep up with this relentless pace?

Before, it was good enough to just have an engineering or computer science degree to be able to thrive in the Information Technology (IT) world. Now, you don’t necessarily need a degree, but you do need to understand the basic terminology or learn the appropriate logic required to create software. Many people believe that understanding programming algorithms and patterns is a skill you’re born with—you either have it or you’ll never succeed in IT. This is not true – especially nowadays, in the no-code/low-code era.

Today, we can find mobile applications that do our work for us. There are tools online to help us write, design, paint, sing, and build, even if that is not our strongest suit. Why would programming be any different? This is where technologies such as Salesforce, MuleSoft, SAP S/4HANA, Zoho, Oracle Cloud, Tableau, Power BI, and JIRA come into play. The simplicity they’re based on helps you to thrive in this environment even if you don’t come from an IT background.

In this chapter, we’re going to cover the following main topics:

No-code and low-code technologiesIntegrationsAPIsMuleSoft’s productsApplication networksAPI-led connectivity approach

Let’s start by understanding the need for an integration tool.

Understanding the need for an integration tool

In today’s complex digital landscape, businesses rely on multiple systems and applications to operate efficiently. However, these systems often operate in silos, leading to data inconsistencies and workflow disruptions. An integration tool such as MuleSoft bridges these gaps by seamlessly connecting different platforms, enabling smooth data flow, and enhancing overall productivity. Understanding the need for an integration tool is crucial for any organization aiming to streamline operations, improve data accuracy, and maintain a competitive edge. Before we dive into MuleSoft, let’s first understand why we need an integration tool and what low-code or no-code technologies are.

Introducing no-code and low-code technologies

Programming and software development have been evolving over the years. At first, programmers needed to manually translate the behavior they wanted into computer code. You needed to study a programming language, practice it, and really polish it to be able to create unimaginable programs. Eventually, this transformed into human-readable words that you could input into the machine and it would automatically know what you meant.

Fast-forward to the year 2024 and you don’t even have to input words for the computer to know what you want to do. Computers are now good enough to work with icons, buttons, or drag-and-drop components. You don’t need to memorize commands; you just need an introduction to the tool and some practice to be proficient in it. What a blessing!

Of course, there might still be some need to write code in order to have more customized behavior that fits into more complex needs for the tool; but code in general, or a programming language, is easier to understand every time.

Let’s now look into both no-code and low-code technologies in more detail.

No-code technologies

There are some applications that you can use that involve no coding whatsoever. A few examples that come to mind are Trello for project management, Canva for graphic design, and Zapier for integration/automation. You can use them without needing to know a programming language. It’s all done through clicks and configurations. For example, Salesforce’s no-code capabilities include Salesforce Flow for automating complex business processes through a visual interface, Lightning App Builder for customizing page layouts and creating apps with drag-and-drop functionality, and Process Builder for automating tasks and workflows based on predefined criteria. These tools enable users to tailor Salesforce without writing any code.

For example, Zapier and other tools, such as If This Then That (IFTTT), are very popular because you only need your browser to access them. There’s no need to install an application on your computer or perform updates to your software. You can simply type the site name into your browser, create an account, and start using it right away. Of course, there is a learning curve to understanding how to use them. But this can be overcome in a matter of hours or days, not years of a professional career. With these kinds of integration tools, there are predefined apps that you can connect to through their Graphical User Interfaces (GUIs), such as Google Calendar, GitHub, and Philips Hue. You can create specific triggers to automate your day-to-day work. An example that comes to mind is sending a Slack message as soon as a commit is pushed in GitHub. You can just click through the flow to sign in to your accounts from these different services and you don’t even need to understand how their code works. That is the beauty of no-code technologies.

Low-code technologies

In low-code tools, you can still take advantage of drag and drop, clicks, and configurations, but there might be some coding involved for more precise functionality. However, programming is not the majority of the work. The technology does not revolve around the programming language; rather, it is considered a feature of the overall product. This is the case for Salesforce with Apex and MuleSoft with DataWeave. You can use Salesforce and MuleSoft without the need to use their programming languages, but they are available for you in case you need custom functionality.

MuleSoft is considered a low-code technology because, while it provides a user-friendly, drag-and-drop interface for creating integrations, it still requires some coding for more complex tasks. For example, if you need to perform custom data transformations, advanced error handling, or connect to legacy systems, MuleSoft allows you to use DataWeave scripting or custom connectors. These scenarios go beyond simple configuration, requiring technical knowledge, which is why MuleSoft is categorized as low-code rather than no-code.

Analyzing integrations

Integration connects various systems or applications, allowing them to communicate and share data effectively. This process streamlines workflows and ensures that different technologies function together cohesively.

Let’s now look into a technical example to demonstrate what integration does. If you’re not familiar with JavaScript Object Notation (JSON), it’s a type of data that is widely used nowadays because of its simplicity and easiness of reading.

Let’s say that system A uses the following JSON object to describe a person. It contains the ID, FirstName, and LastName fields:

systemA-person.json

{ "ID": 1, "FirstName": "Alexandra", "LastName": "Martinez"}

However, system B uses a different JSON structure to describe a person. Instead of the ID field, it uses id, instead of FirstName, it uses firstName, and instead of LastName, it uses lastName:

systemB-person.json

{ "id": 1, "firstName": "Alexandra", "lastName": "Martinez" }

For a human, this might seem like a pretty straightforward transformation. The fields have the same names; they just have different uppercase and lowercase letters. However, for a computer program, these fields are completely different. You need an integration that will help system A and system B to effectively communicate with each other even though their fields are different.

Of course, this example is simple compared to real use cases. This is just to give you a better idea of why you would need integration to connect different systems. In the real world, this data can range from something as brief as what was just demonstrated to as extensive as 2,000 fields at a time. Sometimes, this data will also involve different data types.

Now, imagine that we not only have to connect different data structures from system A to system B but also need to connect systems C, D, and E. All of them have their own data structures. Some of them don’t even use JSON; they use other data types, such as CSV or XML (see Figure 1.1). It would be a lot of work to manually create code to be able to talk within all of these systems. Instead of creating a huge, tightly coupled, and hard-to-maintain application to connect them all, you can create small and easy-to-maintain Application Programming Interfaces (APIs) that will help you to integrate all of these systems and even leave space for any changes to the integrations that can be easily done.

Figure 1.1 – Integrating different systems

You’re not stuck with a ton of dependencies within the same project but have different microservices to manage your whole application network (see Figure 1.7), which brings us to our next topic.

Understanding APIs

The term integration is still an abstract concept without seeing some examples of technology that can implement it; but don’t worry, we’ll get there. Let’s now switch gears and dive into another popular term we hear a lot nowadays: API.

If you’re a visual person, we encourage you to watch this video, https://youtu.be/s7wmiS2mSXY, from MuleSoft to see an animation with a restaurant analogy that is widely used to explain APIs. This step is optional, but it might help you understand this concept better. We will walk through the restaurant analogy in the following section.

Reviewing the restaurant analogy

When you go to a restaurant, after you sit down and get yourself comfortable, a server will come to ask for your order. You order your dish, the server writes it down, and then they proceed to communicate the order to the kitchen. The kitchen staff works their magic to cook your meal, and then let the server know when the meal is ready. The server picks up the dish and takes it to your table for you to enjoy.

Now, let’s break this down into smaller pieces:

You order your food.The server writes down your order and sends it to the kitchen staff.The kitchen staff prepares the order and gives it to the server.The server picks up the order and brings it to you.You receive your food.

We can look at this process as if it were API calls:

You call the Server API, requestingsome food.The Server API forwards your order to the Kitchen API, requestingyour food.The Kitchen API processes this information and responds with your food.The Server API takes the food and responds to your order with the food.You receive the food and confirm it is correct.

Figure 1.2 – API calls in restaurant analogy

The important things to understand from this analogy are as follows:

You don’t know what the server wrote down in their notebook that was sent to the kitchenYou don’t know all the ingredients that were put into your food or the exact process that the kitchen staff followed to prepare the orderYou don’t know what the kitchen staff told the server to let them know your order was ready

All that you know is that you ordered what you wanted and you received what you had ordered. APIs are a lot like that.

Fun fact

In a restaurant, you are the client and the person who brings your food is the server. Guess what it is called in the API world? In API lingo, the application that calls an API is called the client application, and the application or API that responds is called the server application.

Let’s now look at a real-life API to understand it better.

Exploring an API example

There are thousands of APIs that you can use in the real world. An example that we can use to demonstrate is the Twitter/X API. X (formerly Twitter) is a social network that is popular because of the maximum number of characters allowed in a single tweet. As of the time of writing, you can only post 280 characters at a time, which makes it ideal for short thoughts or quick updates about different topics. Once you have a Twitter/X profile and start following other accounts, you will be able to see the tweets from those accounts on your home page, or timeline.

If you go to the Twitter/X API documentation (developer.twitter.com/docs/twitter-api), you will be able to find all the different requests and responses that you can use to communicate with the API (the menu from the restaurant analogy, if you want to look at it that way).

Figure 1.3 – Twitter/X API documentation site

You can use the Twitter/X API to retrieve your tweets, post new ones, or integrate Twitter/X with other apps. For instance, social media tools, such as Hootsuite or Later, use the API to schedule posts. APIs allow you to work with any language or technology, as long as you follow their data format requirements. You don’t need to know the API’s internal workings—just the data it accepts and returns.

Analyzing API components

Now that we have a better idea of what APIs are, let’s start looking into some components to define them. We won’t get into the technical details just yet, but it is good for you to start familiarizing yourself with this terminology.

Implementation

The implementation is the body of the API, that is, the code you choose to build the API with, the part that does the processing of the request and the response. We will use this term interchangeably with API throughout the book.

Request

Whatever is sent to the API is called a request. This includes different kinds of information that will tell the API what needs to be done with the data that is received. In the restaurant analogy, this can be, for example, a hamburger with no pickles, in a combo, with a large soda, and some fries on the side.

Response

Whatever is received back from the API is called a response. This includes information to describe what happened in the processing of the requestor, for example, whether the request was successful or not or whether there was a problem with the request. In the restaurant analogy, this can either be the food you ordered (a successful response), the server telling you that the dish is no longer available but you can still order something else (a failed response with a workaround), or the server telling you that they’re closed for the day (a failed response with no workaround).

Figure 1.4 – API implementation

API specification

This specification serves as a rule, standard, or contract – however you want to look at it – to tell the client application (the application that calls the API or sends a request to the API) what kind of information it needs to send to the API in order to be accepted and processed as needed. For example, if the API specification says the API only accepts JSON requests and the client application sends an XML request instead, then an error will be returned stating that this data type is not accepted by the API. This is also a contract in the sense that it lists what the API may or will return to the client application, for example, a JSON object containing the id, firstName, and lastName fields.

Listing the benefits of using APIs

We still haven’t talked about the technical aspect of an API, but we’ve seen some examples and an analogy to help us get a better idea of this concept. Let’s list some of the benefits of using APIs:

Loosely coupled: Integrating multiple systems through loosely coupled APIs within an application network offers flexibility and avoids dependency issues compared to tightly coupled systems (interacting components are interdependent and must be simultaneously present and operational).Governance: With the APIs approach, you have a better chance of being able to govern your network. You can create API gateways, policies, and any sort of security to ensure that no unwanted intruder can get to your APIs. This can be a challenge with legacy systems sometimes because you need to create personalized code or external solutions may not be available for your system.Discoverability: APIs are well documented for easy discovery and usage by developers, providing examples, use cases, and descriptions, unlike legacy systems, which lack such accessibility.Easier maintenance: APIs, with their specific functionality and smaller code base, are easier for developers to understand and maintain compared to complex legacy systems with millions of code lines and dependencies.Efficiency: From a project management perspective, we can also take this point into account. Because APIs have less code and their functionality is so specific, the time to deliver new features can be shortened compared to other architecture types or legacy systems.Reusability: APIs are designed with reusability in mind, allowing specific functionality to be easily reused across multiple services or systems without the need for custom code, thanks to their loosely coupled nature.

Figure 1.5 – Benefits of using API

Introducing MuleSoft

Everything comes together. After understanding all of the previous concepts – no-code/low-code technologies, integrations, and APIs – we can start talking about MuleSoft. In this section, we’ll describe what MuleSoft is, what some of its products are, how it’s useful, and how it is going to help you in your career as a Salesforce developer. First of all, MuleSoft is the name of the company that created the existing suite of products. When people talk about MuleSoft in a development context, they are referring to all of the products that this company has created. A clearer example of this can be seen now that Facebook has changed its name to Meta; we can more easily see the difference between the name of the company (Meta) and its corresponding products (Facebook, Instagram, and WhatsApp). The same is the case with MuleSoft. The name of the company is MuleSoft; it’s not the name of a product. But when we refer to MuleSoft, it encompasses all of MuleSoft’s products.

Listing MuleSoft’s products

Let’s take a look at some of the most popular products that MuleSoft has released so far (up to the time of writing this book). The suite of technologies can be broken down into three main products:

Anypoint PlatformAnypoint StudioComposer

Each of these products includes its own products and functionality as well. Let’s review them in detail.

Anypoint Platform

Anypoint Platform can be accessed through your browser. If you go to anypoint.mulesoft.com, you will see the login screen. You can create a free trial account that will last 30 days. Inside Anypoint Platform, you will find the following products:

Note

We will talk more about all these products in Chapter 5.

Anypoint Design Center: This is where you can manage your API specifications with API Designer and your Async API specificationswith AsyncAPI.Anypoint Exchange: You can look at this product as an app store of sorts where you can find a catalog of published assets that you can reuse in your own code.Anypoint DataGraph: If you’re familiar with DataGraph, MuleSoft created its own product to help you use this technology within its suite of products.Access Management: This is where mostly only the admins of the account will be able to change permissions or access for the users of the account.Anypoint API Manager: As its name says, you will be able to manage your APIs from here. You can manage alerts, contracts, policies, SLA tiers, and other settings.Anypoint Runtime Manager: The Mule applications are located in Runtime Manager. You can access logs, object stores, queues, schedules, and settings.CloudHub or CloudHub 2.0: If your Mule application is running within MuleSoft’s cloud provider service, that means you’re using CloudHub. Your Anypoint Platform free account will use CloudHub by default.Anypoint Visualizer: You can use this product to get a visual representation of your systems, such as autogenerated architectural diagrams or available policies, or perform some general troubleshooting of your applications.Anypoint Monitoring: Here, you can generate custom dashboards or use the built-in dashboards to get a better feel for how your apps are behaving.Secrets Manager: Here, you can store sensitive data such as passwords, tokens, certificates, or keys in secrets manager so they can be accessed and still be secured.Anypoint Runtime Fabric: This is not included in your free trial account, but this is where you would be able to deploy your Mule applications to different cloud providers, such as Microsoft Azure, Amazon Web Services, Alibaba, Redhat OpenShift, or Google Cloud Platform.Anypoint MQ: This is MuleSoft’s message queueing service. It is a built-in solution that includes its own connectors to use within your code with no extra drivers or settings needed.Anypoint Service Mesh: This is not included in your free trial account, but with this product, you can manage non-Mule applications within the same suite of products, regardless of the programming language they’re based in.Anypoint Flex Gateway: With this lightweight gateway, you can manage Mule and non-Mule applications. You can install Flex Gateway in Docker, Kubernetes, or Linux. This is included in your free trial account.Anypoint API Governance: Here, you can create standards for your API specifications, Mule or non-Mule applications, security policies, and more. This is included in your free trial account.Anypoint Code Builder (ACB): It’s a new IDE for designing and implementing APIs, available in desktop and cloud versions, currently in BETA release. Let’s now see the products inside Anypoint Studio.

Anypoint Studio

Anypoint Studio is MuleSoft’s IDE (based on Eclipse). You install this application on your computer and this is where you’re able to develop Mule applications. Studio has a nice GUI to find predefined connectors and use them to develop your Mule flows. Inside Anypoint Studio, you will find the following products:

MUnit: MuleSoft’s testing framework. MUnit is optimized to create tests visually. We can create tests using connectors, such as Mock, Assert, and Spy. We will talk more about MUnit in Chapter 11.APIkit: With this product, you can take your API specification and create a basic structure for your Mule application instead of doing it from scratch. We will talk more about APIkit in Chapter 8.DataWeave: MuleSoft’s functional programming language, optimized for transformations. We will do a deep dive into this language in Chapter 6, and Chapter 7.

Let’s now see an overview of Composer.

Composer

Composer, as opposed to the other MuleSoft products, is a no-code tool. There’s no need to create an API specification or implementation. Composer was specifically designed to have clicks not code, as its slogan says. If you’re familiar with some of the no-code tools we mentioned earlier in this chapter, such as Zapier and IFTTT, Composer follows a similar approach. We will talk more about Composer in Chapter 12.

Now that we understand the variety of products MuleSoft offers, let’s look into how all of these tools are useful.

Understanding why MuleSoft is useful

We just learned about the suite of products and functionality that MuleSoft offers. Besides being a low-code technology with a smaller learning curve than a regular programming language, MuleSoft can fulfill almost all the requirements you need to cover in the development life cycle. From designing to implementing and testing to deploying, securing, and monitoring your solutions, MuleSoft most likely has a product for your needs. The best part is that because you’re using all these products under the same sphere, they can be easily integrated or moved from one stage to the next.

Let’s review what a Mule application or an API life cycle would look like within MuleSoft’s products.

Design phase – API specification

We’re first going to review what MuleSoft products can be used in the design phase of your API. This will result in an API specification that you can use as the foundation for the next phase. This phase takes place in Anypoint Platform:

API specification design: Using Design Center, you can start designing your API specification with the visual API Designer without having to know RESTful API Modeling Language (RAML) or OpenAPI Specification (OAS).API specification testing: Using the mocking service, which can be found in API Designer, you can create a mock of your current API specification and make calls to it. This is with the purpose of getting a feel for how the developers will experience your API before even implementing it. The idea is that you go back and forth between the design and testing until you feel comfortable with the specifications you’ve created.API specification publishing and feedback: From API Designer, you can publish your finished specification to Exchange for others in your organization to discover. Exchange will automatically generate basic documentation based on your API specification. You can share this Exchange asset with others in order to gather feedback on your design. If you still need to adjust things, you can just go back to API Designer and modify what’s needed. After you do this, you can publish a new version of your API specification in Exchange.

We can iterate through these first three steps as long as needed until we feel comfortable that we have an API specification on which to base our implementation. Once we have the first draft, we can continue with the next phase.

Implementation phase – Mule application

Now that we have a first draft of the API specification, we can get started with the implementation. This phase takes place in Anypoint Studio:

Mule application implementation: This process is where you would be using the available connectors or DataWeave to start creating your Mule application’s implementation. After you’ve finished any number of iterations and feel comfortable with the API specification you generated in the previous phase, you are now ready to start creating your Mule application. From Anypoint Studio, you can connect to your Anypoint Platform account and download the API specification from Exchange. This will generate the basic flows and error handling so you don’t have to start creating everything from scratch. This process uses APIkit to route the different types of requests to their corresponding Mule flows. In addition, any request that is not recognized by the API specification will be routed to the corresponding error handling. For example, if we refer to our previous restaurant analogy, if you were to order food that was not available on the menu, the server would respond that what you requested does not exist.Mule application testing: Once you generate the main functionality, you are ready for the next step, which is where you would start creating your unit testing using MUnit. Nothing is better than a high-quality application. Here, you can create mocks and use asserts to make sure the different scenarios for your code are indeed working as expected. A best practice is to aim for 90% of MUnit coverage, if not 100%, but this varies depending on each project.

Same as earlier, we can iterate through these steps as many times as we need to achieve good-quality code and functionality of the application. Once we’re happy with the first draft of the functioning app, we can continue with the next phase.

Deployment and managing phase – API

Now that we have a functioning Mule application, we can start the deployment and managing phase. This phase takes place in Anypoint Platform:

API deployment: After testing your Mule application locally, deploy it seamlessly to the cloud from Anypoint Studio. Monitor the deployment progress via Runtime Manager. While various cloud providers are available, we’ll concentrate on MuleSoft’s CloudHub for now.API security: Now that your application is running in CloudHub, you are ready to create API policies, contracts, SLA tiers, and so on. All of this is managed by API Manager.API monitoring: Your API is secured and running. Now, it’s time to lay back and relax. You can monitor your API from Anypoint Monitoring or create alerts in case something goes wrong and you want to immediately get notified about it.

The API life cycle doesn’t stop here; it’s an ongoing process. Once the application is deployed, developers test it and give feedback on features or bugs. This initiates a new cycle, either at the design or implementation phase, depending on the case, and the cycle repeats.

Now, we have a better idea of what MuleSoft is and how it’s useful in the API life cycle. This book was written for Salesforce developers and architects, so let’s now see how MuleSoft is helpful for your professional career.

Analyzing how MuleSoft helps Salesforce developers

MuleSoft has long been helpful in integrating different technologies, including Salesforce. However, since Salesforce acquired MuleSoft, we can see more and more integrations between the technologies. Furthermore, the acquisitions of Slack, Tableau, and Servicetrace have also increased the use of MuleSoft throughout these platforms and vice versa. For example, there wasn’t an official Slack connector in MuleSoft before, but one was created after the official acquisition. There is also a new product in the works called MuleSoft Robotic Process Automation (RPA), and guess what Servicetrace is? Yes, it’s an RPA technology. We now also have Composer, which is a technology created by mixing both Salesforce and MuleSoft technologies.

Together, these acquisitions create a cohesive platform where integration, collaboration, and analytics work seamlessly, leading to improved operational efficiency and a more connected, insightful business environment.

While it might be true that you don’t necessarily need to know MuleSoft in order to be a Salesforce developer, the past and the present are the foundation of what we predict the future will be like. What history’s been telling us is that Salesforce will continue adding to its 360 products from other companies it acquires. We already have Composer in common with Salesforce and MuleSoft – who knows what else will be integrated in the future. But it all points to the fact that MuleSoft will be integrated more and more into the Salesforce suite.

From a professional career perspective, currently, there are not a lot of developers who are proficient in both MuleSoft and Salesforce – they are either Salesforce developers or MuleSoft developers, or they may know a little bit about the other but are not experienced developers in both. It wouldn’t be a surprise if in some years, job postings started requiring proficiency in both technologies.

The following summarizes what we have discussed in this section:

MuleSoft enhances Salesforce’s ecosystem to connect with other technologies, providing a more integrated and efficient solution for managing and utilizing data across various platformsThere is already a product created that combines both Salesforce and MuleSoft: ComposerCareer-wise, it would be smart of you to get ahead of the trend and become proficient in both technologies before it becomes a requirement

Exploring application networks and the API-led connectivity approach

This is where it all comes together. We understand that MuleSoft is a collection of low-code technologies that help us to create APIs or microservices based on Mule applications. Integrations are important because we can connect different services with different data types or structures to create an application network.

Understanding what application networks are

If computers are connected in a network, it’s called a computer network, such as in a computer lab and office network. Similarly, when applications are interconnected, it’s referred to as an application network.

Why do we create several APIs and connect them instead of creating one single system to do all of this? Remember the benefits of using APIs: loosely coupled, governance, discoverability, easier maintenance, efficiency, and reusability. We can’t achieve these with a regular system. All the code is tightly coupled, it’s hard to maintain, it can’t be reused, and so on. This is why we want to create an application network to connect all of these different building blocks.

Figure 1.6 – Application network representation

We can connect services or platforms such as Salesforce, Workday, Amazon Web Services, NetSuite, Dropbox, Google Drive, SAP, and Twitter/X – the options are endless. Even if these don’t have an API to connect to as easily, MuleSoft’s products offer so many options for customization that you can really integrate almost anything with MuleSoft. The main vision when MuleSoft was created was to be able to work together and make more APIs to discover and reuse. This would essentially reduce time to delivery and IT demands would be easier to meet over time. But how exactly do we plan on doing this network? This brings us to our next point.

Analyzing the API-led connectivity approach

MuleSoft believes in an architectural approach in which you have a standard to give your APIs a specific purpose in your application network. This can help you create more reusability around your APIs so you can easily add new functionality or APIs, modify or upgrade existing ones, or remove any API that’s no longer being used.

This API-led connectivity approach is based on three different layers in which we’ll categorize our APIs: Experience, Process, and System.

Figure 1.7 – The three layers of the API-led connectivity approach: Experience, Process, and System

Experience layer

This is the top layer. It is where we have the APIs that directly make contact with the client application, whether that’s a mobile application or a desktop/web application. This is where we put the APIs that have direct contact with the outside world, that is, the APIs that are public. The sole purpose of these Experience APIs is to connect to the client application and send the information to the next layer. The only logic we may add here is any kind of security or filter to make sure the information that is received is correct and can indeed proceed with the rest of our application network. If anything is missing or looks suspicious, then it’s the Experience API’s responsibility to not let this data proceed further and raise this as an error immediately.

Process layer

This is the middle layer. It is where, as its name suggests, the data we receive from the Experience layer is processed or transformed in order to be sent to the rest of the APIs. Just as we saw earlier on in this chapter when we talked about integrations, if we have system A, which processes certain information, and then we have system B with a different data structure, then it’d be the responsibility of the Process APIs to transform (or translate) these two data types in order to be understandable by their corresponding APIs.

Going back to our previous example, say now system A is the data that comes from the client application and system B is the data that we need to send to the server application; we end up with something like this:

client-application.json

{ "ID": 1, "FirstName": "Alexandra", "LastName": "Martinez" }

server-application.json

{ "id": 1, "firstName": "Alexandra", "lastName": "Martinez" }

It is the Process API’s responsibility to do these two transformations both upstream and downstream. The Process API would first receive client-application.json as its input, then it would have to transform it to the server-application.json structure and send it to the corresponding API. After the downstream API responds, the Process API needs to transform the data from whatever it received from the server application to whatever data type or structure the client application is expecting to receive. In this case, the client application would be the Experience API that’s calling the Process API, and the server application would be the System API.

System layer

This is the last layer. The Experience layer, the topmost layer, is the one that directly connects to the client application. Now that we’re at the bottom, this is where we directly connect to the server application, whether that is Salesforce, Facebook, SQL, or Azure, you name it. These APIs are where we store any tokens, passwords, credentials, or URLs that are needed to connect to the underlying systems.

Since most of the filtering, security, cleanup, and transformations are done in the previous layers, this layer can focus solely on connecting and sending the data to its target. If there is more data transformation needed from this response, the Process API is responsible for doing so, not the System API.

We have a better picture now of how the API-led connectivity approach is helpful for our application network – when we separate the APIs into these three layers, we have a better standard to follow in our architecture. Now, let’s summarize all we have learned in this chapter.

Summary

In this chapter, we learned how the learning curve for no-code or low-code technologies is smaller than learning a programming language. You mainly need to learn how to use the GUI, which may take some hours or days, and almost all the functionality is done through clicks instead of code.

When we have systems that need to exchange pieces of information, but they don’t necessarily use the same data type or data structure, we create integrations to help translate this data. Using APIs is better for the developers who create or maintain the code, the developers who want to use a public API, and the companies behind them. APIs, as opposed to other systems, are loosely coupled, easier to maintain, discoverable, and reusable.