MuleSoft Meetup Charlotte 2019 - Dec 10

All contents © MuleSoft Inc.
Welcome To MuleSoftMeetup
1

Welcome To MuleSoftMeetup
2
Charlotte MuleSoft Meetup 4
10th Dec 2019

Agenda
3
5:30 PM Introductions & Welcome
5:45 PM Networking + Dinner
6:00 PM API Autodiscovery - API Promotion & by Avinash Vaddi
6:30 PM Munit in Mule 4 by Diane Kesler.
7:00 PM Microservices and its Discoverability, Governance with a Service Mesh by Aravind Ramadugu.
7:30 PM Social Hour
8:00 PM Close

API Autodiscovery - API Promotion

About Autodiscovery
• Autodiscovery is a mechanism used to pair an API in API Manager to
its deployed Mule application.
• Setting up autodiscovery allows API Manager to manage the API.
When set up correctly, it shows the API status, represented as a
green dot if the API is being tracked, or a gray dot if untracked.

About Autodiscovery(Cont..)
• By configuring autodiscovery you can use policy management, and
API Analytics, accessed from within API Manager.
• When autodiscovery is correctly configured in your Mule application
you can say that your application’s API is tracked by or paired to API
Manager.
• An API in a Mule runtime can only be associated with one
autodiscovery instance.
• No two Autodiscoveries can be associated to the same API in a Mule
Runtime.

Prerequisites
• API must exist in API Manager, configured with either a basic
endpoint, or a proxy endpoint.
• Mule must be configured to use Anypoint Platform credentials.
• The autodiscovery element must be configured in your Mule
application. This XML element must point to the specific API in API
manager which you want to pair to.

Manage the API in API manager
• Once the RAML is published in Exchange, it needs to be managed in the
API manager.
• In the API MANAGER tab in Anypoint Platform, click on Manage API and
select Manage API from Exchange.
• Enter the API name. Select Managing type as Basic Endpoint. Check the
box for the Mule version as we are managing it in Mule4.
• Once you save the configuration, the API will visible in the API manager
but the status of the API will be "UNREGISTERED".
• It means that until now, it has not yet been associated with an actual
implementation.
• The most important thing to notice in the API is the API Autodicovery tag.
• This will help us to pair the API in the API Manger to its deployed Mule
Application.

Proxy vs Autodiscovery
• Proxy: When we are creating a Proxy in API Manager we are adding
governance (applying policies, managing traffic, adding
authentication methods, etc.) to an API which already exists and it is
going to consume 0.1 vCore by default.
• There are two main use cases for creating a proxy:
• When the company has in a SOA implementation and has already
created quite a lot of services for which there is no control or
governance.
• When you want to expose data externally and deploy the proxy in a
DMZ following the Gateway pattern.

Proxy vs Autodiscovery(Cont..)
• Auto-Discovery: API auto-discovery is the mechanism to manage
an API from API Manager by pairing the deployed application to an
API created on the platform, regardless of how it was deployed.
Auto-discovery will not consume extra cores since you manage the
Mule API directly.

MUnit is…
• Integrated with Anypoint Studio, allowing you to create, design and run MUnit
tests just like you would Mule applications.
• It provides a full suite of integration and unit test capabilities.
• Integrated with Maven and Surefire for integration with your continuous
deployment environment
What is Munit?

Overview of MUnit
16
With MUnit you can:
• Create your test by writing Mule code
• Minimize manual testing
• Mock processors
• Spy any processor
• Verify processor calls
• Enable or ignore particular tests
• Check visual coverage in Studio
• Generate coverage reports

MUnit Suite Sub Modules
17
• MUnit
MUnit is divided in two main sub modules:
• MUnit Tools

MUnit Operations
MUnit Module
18
• Before Suite - runs BEFORE executing MUnit Test Suite
• Before Test - runs BEFORE executing MUnit Test
• After Test - runs AFTER executing MUnit Test
• After Suite - runs AFTER executing MUnit Test Suite
• Test – adds a new test
• Set Event – sets a mule event
• Set null payload – defines a null payload for testing

MUnit Tools Operations
MUnit Tools Module
19
• Assert - validate the state of a Mule event’s content
– Equals
– Expression
– That
• Mock when - mock an event processor when it matches the
defined name and attributes
• Spy - what happens before/after an event processor is called
• Verify call - verify if a processor was called
• Fail - allows you to fail your test on purpose
• Run custom - custom assertion

Create an MUnit Suite
20
Various ways to create MUnit Tests
Method 1: File>New>MUnit Test Method 2 – Pallet Test Operation

Adding Tests Creates XML
21
Various ways to add MUnit Test RESULTS: XML Creation
Method 3- From Flow

• Behavior Scope
– Meant to set all the preconditions before executing the test logic
– Mocks and spies go in this section
• Execution Scope
– Meant to have the testing logic which will wait for all processes
to finish before executing the next scope
– Run flows in this section
• Validation Scope
– Meant to have all the validations regarding the result of the
execution scope
– Assertions and verifications go here
MUnit Test Scopes
22

Set Event
Set Event Processor
23
– Allows you to define a Mule Event.
– Normally used at the beginning of an
MUnit test, to define the first message
to send to the flow being tested.
– You can define as many properties per
each scope as you need for your test.

Assert that
Assert That Event Processor
24
– Allows you to run assertions to validate the state
of an event’s content
– Can validate the event after the production code
runs
– Uses DataWeave functions called MUnit matchers
to define the assertion conditions for any value
in an expression
– Include the prefix MunitTool:: in the expression
• notNullValue() checks that the expression is not null.
As shown: #[MunitTools::notNullValue()]

Matchers
Assert That MUnit Matchers
25
• Core Matchers - evaluate core values in
the expression
• String Matchers - perform assertions on
String expressions
• Comparable Matchers - compare the
expression against a specified value
• Iterable and Map Matchers - when your
expression is an array or a map of data
• withMediaType(String)
#[MunitTools::withMediaType('text/xml’)]
• containsString(String)
#[MunitTools::containsString('example’)]
• greaterThanOrEqualTo(Comparable)
#[MunitTools::greaterThanOrEqualTo(20)]
• isEmpty()
#[MunitTools::isEmpty()]
Examples

Mock when
Mock When Event Processor
26
• Allows you to mock an event processor when it matches
the defined name and attributes
1) Pick processor
2) Select target processor
3) Select attributes
4) Click OK

Configure “Then return” section
Mock When - Then Return
27
• Configure Then Return to define the type of response
the mocked processor should return
• It could be a payload, a variable, attributes, or even
an error
1) Choose type of response
2) Click Add icon
3) Enter values
4) Click OK

Spy
Spy Event Processor
28
– Allows you to spy what happens before and
after an event processor is called
– Tells MUnit to run a set of instructions before
and/or after the spied event
1) Pick processor
2) Select target processor
3) Select attributes
4) Click OK

Verify Call
Verify Call Event Processor
29
– Allows you to verify if a processor was called
– you can validate if a specific processor has
been called:
• with a particular set of attributes
• a specific number of times

Run MUnit Suite Select src/test/munit>Run As>Munit
Run MUnit Suite
30
• Right click Canvas
• Select Run MUnit suite

Run MUnit Test
31
Run MUnit Test
• Right click In Test
• Select Run MUnit test

DEMO on MUnit

View test results and coverage
MUnit Coverage Report
33
1) All the tests for all test
suites
Green means successful
2) Errors: shows the
reason for test failure
3) Coverage: % of the
flow that were covered
4) Detailed coverage
report.

Failures
Munit Failures
34
Munit Test Suite
FAIL
SUCCESS

TESTING ERRORS
35
For the MUnit test we can configure ‘Expected Error Type’ or ‘Expected Exception’ or both
Validation:Null

DEMO on MUnit RAML APIKit

Anypoint Service Mesh

Increasing demands drive the need for microservices
38
Customer
expectations
Hyper-specialized products
More agile business models
Disruptive
competitors
Microservices
architectures
91% of organizations are using or
planning to use microservices*

Choosing microservices is the easy part...
39
Isolated
expertise
Siloed management and
governance
Custom coded network configs
99%
of organizations adopting
microservices report
challenges*
SAP
Inconsistent
security across
services

Anypoint Service Mesh - Introduction
• Anypoint Service Mesh enables accelerated adoption of microservices by
providing the following features to non-MuleSoft microservices
• Discoverability
• Management
• Security
• Non MuleSoft microservices can be written using different languages and
platforms and gets deployed in various different environments.
• Provides resilient service-to-service communication using zero-trust policies to
handle traffic control, fault tolerance and load balancing
• Extends MuleSoft API Management capabilities to any non-Mule service, with policies,
security and analytics all applied directly from Anypoint Platform
• Amplifies reuse of services with discovery of non-Mule services within Exchange,
available for use in future projects

Anypoint Platform October 2019 Launch

Discoverability and governance with a service mesh

Anypoint Service Mesh - Architecture

Anypoint Service Mesh – Request Flow
1. The client, which might be another microservice or any Kubernetes Ingress component, sends a request to the
service.
2. Envoy captures the request and redirects it to the Istio-mixer.
3. The Mixer adapter then calls the Anypoint Service Mesh adapter to perform policy checks and verifications.
4. The Anypoint Service Mesh adapter performs policy checks and responds back to the Mixer.
5. The Mixer communicates the outcome of the policy checks to the Envoy proxy.
6. When no policy violations are encountered, the request is routed to the microservice. The microservice runs the
service logic and sends the response back to the client.

Anypoint Service Mesh – Prerequisites
• Your Anypoint Service Mesh installation requires the following applications and
Kubernetes environments:
• Kubernetes 1.12+ or a newer cluster, with RBAC (Role-Based Access Control)
enabled
• Helm 2.13.0 or later Tip: To verify installed version, use the helm version. For more
information about how to install Helm, see the Helm installation documentation. .
• Kubectl version 1.12 or later (compatible with the cluster) is installed on your local
machine Tip: To verify installed version, use the kubectl version.
• One of the following environments on which to run Kubernetes:
Google Kubernetes Engine (GKE)
Amazon EKS
Azure Kubernetes Service (AKS)
• Not installed Istio in the cluster

Anypoint Service Mesh – Installation
• To download the Service Mesh software use the
following command.
– curl -
Ls http://anypoint.mulesoft.com/servicemes
h/xapi/v1/install > service-mesh && chmod
+x service-mesh
• Installing Service Mesh:
– ./service-mesh install
– Installer installs Istio, Service Catalog,
Anypoint Service Mesh Broker, and ClusterIP
Service components are installed in your
Kubernetes cluster.
– Enter the Client-id, client-secret and License
file path.

Anypoint Service Mesh – Configuration
• Provision the Adapter
• Check the adapter status.
• ./service-mesh adapter list
• The status values include:
• Ready—The adapter is now ready to be used.
• Failed—The adapter was not created successfully. An
error occurred.
• Provisioning—The adapter is in the process of being
provisioned.

CLI Help for Adapter Commands
Help command for the service-mesh help.
./service-mesh adapter help

Provisioning Adapter
• Determine the adapter size based on the plan.
• From Anypoint Platform, obtain the the client ID and client secret for your
environment
• Command to provision Adapter:
./service-mesh adapter create
--name=<adapter name>
--namespace=<adapter namespace>
--size=<adapter plan size>
--clientId=<clientId of the environment or organization>
--clientSecret=<client secret of the environment or organization> --platformUri=<URL of Anypoint Platform>
• Checking Adapter Status:
• ./service-mesh adapter list

Provisioning Adapter – Contd.
• Review adapter logs to see detailed information about Kubernetes events
and adapter transactions:
• ./service-mesh adapter logs --name=<adapter_name>
--namespace=<namespace>
• To check whether the applications are redeployed, run the following
command:
• kubectl get pods -n <namespace>

Create an API
1. Go to Anypoint Platform > API Manager and select the Manage API drop-down
list.
2. Select Create new API.
3. The Creating an asset page is displayed.
4. Specify the Name, and Asset types details for the API.
5. Your Asset is now created in Exchange for reuse. After you create the Asset, you
are now ready to perform Endpoint configuration.
6. The Endpoint Configuration window is displayed.
7. In the Managing type field, select the Basic Endpoint radio button.
8. In the Application type field, select the Non-Mule application radio button.

Binding APIs with Services
1. Go to Anypoint Platform > API administration, and expand the API version name to
display the instances.
2. Click an instance name and copy the API ID that is displayed. Make sure to save this API ID
to a text editor.
3. To retrieve the service name from Kubernetes, with which you want to bind the API, run the
command:
kubectl get svc -n <namespace>
4. Verify that your microservice port is named following the requirements requested by Istio:
[https://istio.io/docs/setup/additional-setup/requirements/].
5. From the Anypoint Service Mesh installer download location in the Command window, type
the following command to bind the adapter with an application:

Managing APIs with Anypoint Service Mesh
53
• Navigate to API Manager and select the specific API instance.
• From the left navigation, select Policies > Apply New Policy.
• Select any of the following policies to secure your APIs:
– Client ID Enforcement
– JWT Validation
– Rate Limit
– Rate Limit SLA-Based

Managing APIs with Anypoint Service Mesh
54
• After the binding is done we will see the API being registered on the API manager.

DEMO on Service Mesh

Q & A
56
DEMO

Explore our new version
MuleSoft Documentation

Find the answers you need, fast.
58https://docs.mulesoft.com/

The best place to ask questions and help others.
MuleSoft Help Center

15,000+ members ready to help.
60
https://help.mulesoft.com/
• Check out the “MuleSoft
Training” category for all
training and certification-
related questions

Join Charlotte MuleSoft Discussion Group.
61
https://help.mulesoft.com/s/
group/0F92T0000004odaSAA
/charlotte-meetups
• Check out the “Charlotte
MuleSoft Discussion Group.”
category for all your
questions which you want
to discuss within the
Charlotte Group.

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

What’s next
63
• Feedback:
– Contact your organizer Subhash Patel, Aravind Ramadugu or Savannah
Williamson to suggest topics.
– Contact MuleSoft at meetup@mulesoft.com for ways to improve the program.

Please Tweet
64
• Nominate yourself for
the next meetup speaker
and suggest a topic as
well.
Tweet your pictures with the hashtag
#MuleSoftMeetup

MuleSoft Meetup Charlotte 2019 - Dec 10

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to MuleSoft Meetup Charlotte 2019 - Dec 10

Similar to MuleSoft Meetup Charlotte 2019 - Dec 10 (20)

Recently uploaded

Recently uploaded (20)

MuleSoft Meetup Charlotte 2019 - Dec 10