Things to focus on- would be the

– dataweave syntax
– error handling (questions makes you doubt your answers)
– debugging and what to expect on the output
– data transformation
– accessing and modifying events.

01-API RAML
02-Dataweave
03-ErrorHandling
04-Message Property

Here are my notes for passing the exam.

 Creating Application Networks

o Current IT landscape problem

 IT cannot delivery fast enough

 IT can build fast while still early but as time moves the IT
project gets complex and harder to build on top of it
 Solution: A new IT operating model IT builds reusable assets
and data Business can self-serve on the assets
o Modern API approach

 discoverable and accessible through self service

 productized and designed for ease of consumption

 easily managed for security, scalability and performance

 API-Led Connectivity

 Experience API

 Process API

 System API

o What is C4E ?

 Center for Enablement

 A cross functional team

  developers
 lob it

 central it

 C4E make sure assets

 are productized

 consumable

 fully leveraged

 success is based on asset consumption

o Deconstructing API
 What is an API?

 Acronym for Application Programming Interface

 it provides information how to communicate with a

software component
 Operations – what to call

 Inputs – what inputs are expected Output – results

expected
 Underlying data types ?

 It defines functionalities independent of implementations

 change what is behind the scenes without people

changing how they call it
 API can be of the following

 API specification file

 defines what to call, send and get back

 web service

 actual API implementation you can make calls

 API proxy

 application that controls access to a web service,

restricting access and usage through an api proxy
 What are web services

 different software systems often need to exchange data

with each other
 bridges platform, protocols, programming
language and hardware architecture
  is a method of communication between systems over the
internet
 system interaction manner is prescribed by some defined
rules of communication
 Parts of a web service API
 The web service api

 describes how to interact with the api

 may or may not be defined in a file

 web service interface implementing an api

 code providing structure to the application/

combination
 web service implementation itself

 actual code and application

 Two main API types

 SOAP

 traditional, more complex

 communication rules are defined in an XML

 RESTful

 recent, simplier
 uses existing HTTP communication protocol

 Representational State Transfer

 architecture pattern where clients and

servers exchange representation of resources
using HTTP protocols
 http request methods

 POST

 creates new resource

 GET

 retrieves current state normally

in XML or JSON
 PUT

 updates or creates a new one

 PATCH
  partially updates
 DELETE

 deletes a resource

 data and resources are represented using

URIs
 resources are accessed or managed with a
fixed set of operation
 get /companies

 get /companies?country=France

 etc…

 Example RESTful web service response

 JSON (Javascript Object Notation)

 supports maps and collections

 lightweight data-interchange
format
 XML

 Making calls
 Unsecured API

 no authentication required
 Secure API

 requires credentials or token

 sometimes api proxies are used to

govern access to an api
 you can secure an api with different
protocols OAuth, SAML and JWT
 Http Status Codes

 provides feedback for the

outcome of the operation
 good api should return status
codes that align with the http
spec
 Designing APIs
o Modern API

 productized
  easily govern
 build for consumption – reusable

o Anypoint Design Center

 Design your api

 API Designer

 Uses RAML

o AnyPoint Exchange
 A repository

 library of assets

 private content only to available to people in your org

 when a rest api is added to exchange it creates an api portal

 Flow Designer lightweight version/ available on the web

 Anypoint Studio for development

 Anypoint Management Center

 version proxy

 rate limit

 throttling visibility and

 control scale your application

 Runtime Services

 deploy applications

 lightweight java-based ESB

 decouples point to point

 can be deployed anywhere

 enforces policies for api governance

 Anypoint Platform

 uniquely built

 deploy anywhere

 can build your own connector

 have tons of pre-built connectors

 implemented all the internal process eg. database

connection etc..
 Achieving Success
  business outcome
 org enabled technology

 delivery

 Paths

 Plan for success

 Establish the foundation

 Build to scale

 Measure impact

 API Notebook

 on exchange you can create documentation – plays your

script
 MUnit

 test your mule application

o Mule Applications
 can be created visually or through xml

 under the hood it is java using spring

 mule apps are deployed to mule runtime

o Mule Runtime Engine

 lightweight java ESB and integration platform
 decouples point to point

 can be deployed anywhere

 enforces policies for API governance

o Mule 4 Applications and flows

 Mule application receive events, process them and route them

 A listener listens for events

 an application can consist of single or multiple flows

 mule event source

 initiates the execution of flow

 mule event processors

 tranform, filter, enrich

o Workers
 dedicated instance of mule that runs the app
  each worker runs in separate containers from every other
application
 can have different compute power

 apps can be scaled vertically by change worker size

 apps can be scaled horizontally by adding more workers

 there are workers in different environments

 Accessing and Modifying Mule Events

o Mule event

 Mule message – data that passes to the flow

 attribute – metadata in the header payload – core info of the

message
 variables – metadata for the mule event – can be defined and
referenced
 Structuring Mule Applications
 Building API Implementation Interfaces
 Routing Events
 Handling Errors
 Writing DataWeave Transformations
 Using Connectors
 Processing Records
 Debugging and Troubleshooting Mule Applications
 Deploying and Managing APIs and Integrations
In this post I’m sharing my notes for spec driven development and cover the basics on
creating an API specification. Spec driven development is a development process
where your application is built in two distinct phases.

 creation of the specification (design)

 development of code to match the spec(development)

What are the phases for spec driven development in the Mulesoft world?

 Design
 Simulate
 Feedback
 Validate

So what is an API Specification and how to create one?

– API specification and definition are interchangeble. API Specification is much more
concerned with the overall behavior of the API, and how it links to other APIs.

– To create API Specification we use a language called RAML.

 RAML is a language for the definition of HTTP-based APIs that embody

most or all of the principles of Representational State Transfer (REST).
 It is a non-proprietary language to build API specifications
 Data structure is hierarchical and by indentation not markup

Source: https://github.com/raml-org/raml-spec

Where can you start creating RAML?

 Design Center on the Anypoint Platform

 You can use Anypoint Studio
 API Workbench – installed as an Atom package
– http://apiworkbench.com/
Some key design features of creating an API Spec on the Anypoint Platform

 Documentation is created from the RAML and shown in the API console
 A mocking service can be used in the API console to test the API
 Make an API discoverable by publishing it to the Private Exchange
 You can publish to the public(needs Mulesoft review)
 API portals are auto generated
 Automatically generated api endpoint is created that uses mocking service
 API portals can be shared to internal or external users
 Share the API to external developers by making portal public
 You can customize the public portal
o logo

o favicon

o welcome text

o fonts

o image

What is a mocking service?

 it is an auto generated api endpoint to use for testing