Flows in mule

P R E S E N T E D B Y
S I N D H U V L
Flows in Mule

1. Debugging
 This section describes how to debug your Mule
application using:
Studio Visual Debugger
TroubleShooting

Studio Visual Debugger :
 Studio’s Visual Debugger allows you to run your
application in Debug mode, stopping execution to check
the contents of a message at previously-specified
building blocks.
 To do this, you set a breakpoint at any building block in
your flow that you wish to check or test (see image
below). When you run your application in Debug mode,
the application stops immediately after executing the
building block with the breakpoint. Using the Mule
Debugger View, you can browse through the contents
of the message as it exists at that point in the flow, and
evaluate Mule Expressions against the message.

Using the Visual Debugger :
 Complete the following macro-steps to use the Visual
Debugger in Studio.
1. Setting Breakpoints breakpoints on building blocks in your
application. Regf
2. Running in Debug Mode the application in Debug mode.
3. Viewing Message Data at a Breakpoint and/or Evaluating
Mule Expressions the data in the first building block with a
breakpoint.
4. Resume application execution.
5. Repeat step 3 with the next building block with a
breakpoint, if any.

Setting Breakpoints :
 Right-click a building block, then select Toggle
breakpoint.

Running in Debug Mode :
 In the Package Explorer pane, right-click your
application, then select Debug As> Mule
Application. Studio begins running the application
in Debug mode, and displays the Confirm
Perspective Switch window.

Viewing Message Data at a Breakpoint :
 When you begin running your application in Debug
mode, Mule opens the Mule Debugperspective.
Until a message arrives at the first breakpoint, the
Mule Debugger View in the console displays a
message that reads, "Connected with mule ESB.
Waiting for a mule message to arrive!"
 The image below illustrates the Mule Debug
perspective.

Troubleshooting :
 This section introduces a number of techniques
useful in troubleshooting Mule problems and in
gathering information for technical support.
Configuring Mule Stacktraces
Debugging Outside Studio
Logging

Configuring Mule Stacktraces :
 By default Mule will filter out some internal class
references from stacktraces to produce a more
readable output. This behavior can be controlled one
of three ways:
Command-line arguments
Setting properties in Mule Studio
Using JMX

Debugging Outside Studio :
 In Anypoint Studio, you can use the Studio Visual
Debugger to help you troubleshoot your app. If
you’re creating your Mule app oustide Studio, you
can resort to the following options:
 When Running From Eclipse : Select the "Debug As
> Mule Server" start-up mode from your
configuration file. Any breakpoint you will have set
in your custom code or Mule’s source code will
suspend the execution and will take you to Eclipse’s
Debug perspective.

 When Running Mule Standalone :You need to start
Mule with the -debug to activate remote debugging,
which gives (on Linux):
$MULE_HOME/bin/mule -debug
 With this option, Mule will start normally with the
only difference being the following message logged in
the console:
Listening for transport dt_socket at
address: 5005

Logging :
 he less high-tech and most popular of all debugging
techniques is the usage of log statements in order to
follow the evolution of an application’s state. In
Mule, the state you’re interested in resides in the
messages that are flowing through your
configuration and, possibly, custom code.
 If you’re running your Mule configuration from
Eclipse, the log outputs are visible right in Eclipse
console window. If you’re running Mule from the
command line, the logs then are visible in your OS
console.

2. Securing :
 Anypoint Enterprise Security
 Configuring Security
 FIPS 140-2 Compliance Support

1. Anypoint Enterprise Security :
 Anypoint Enterprise Security is a collection of
security features that enforce secure access to
information in Mule applications.
 This suite of security features provides various
methods for applying security to Mule Service-
Oriented Architecture (SOA) implementations and
Web services. The following security features bridge
gaps between trust boundaries in applications:

 Mule Secure Token Service (STS) OAuth 2.0a
Provider
 Mule Credentials Vault
 Mule Message Encryption Processor
 Mule Digital Signature Processor
 Mule Filter Processor
 Mule CRC32 Processor

Why Do Applications Need Security?
 Businesses must ensure that the valuable information
they store and make available through software
applications and Web services is secure. Locked away
and protected from unauthorized users and malicious
attackers, protected resources — such as credit card
information or Social Security numbers — must still be
accessible to authorized legitimate users and systems in
order to conduct business transactions.
 To provide secure access to information, applications and
services can apply a variety of security measures. The
suite of security features in Anypoint Enterprise Security
enables developers to protect applications according to
security requirements, prevent security breaches and
facilitate authorized access to data.

Advantages of Anypoint Enterprise Security :
 Anypoint Enterprise Security adds new features on top of of
Mule ESB Enterprise’s existing security capabilities. Mule
ESB already provides the following security features:
 Mule Security Manager, client authentication and
authorization on inbound requests as well as credential
mapping for outbound calls
 LDAP and third party identity management system
integration
 Validation of inbound requests through the SAML 2.0
federated identity standard
 Secure FTP (SFTP) Transport that enables Mule flows to read
and write to remote directories over the SSH protocol.

Mule Credentials Vault :
 Mule can encrypt properties in a .properties file. The
.properties file in Mule stores data as key-value pairs.
Mule flows may access this data — usernames, first
and last names, credit card information — as the flow
processes messages. In the context of Anypoint
Enterprise Security, Mule refers to the .properties
file in which it safely stores encrypted properties as
the Mule Credentials Vault.
 Encrypt a properties file

Mule Message Encryption Processor :
 Mule can encrypt an entire payload or several fields
of data within a message. Where sensitive
information must move between users, yet remain
hidden from them, a developer can encrypt message
content to prevent unauthorized access. Typically,
you may need to encrypt data such as a password,
credit card number or social security number (SSN).
 Encrypt a message payload
Decrypt a message payload

Mule Digital Signature Processor :
 Mule uses digital signatures to ensure that messages
maintain integrity and authenticity. Mule can verify that
an incoming Web service request originates from a valid
source, and can sign an outgoing Web service response to
ensure its contents. Digital signatures ensure that a
sender is valid, that a message is not modified in transit
between Web services, and that no unauthorized user has
tampered with a message.
 Add a digital signature to a message in Mule
Sign part of a message payload
Verify a digital signature in Mule

Mule Filter Processor :
 Mule can filter messages it receives to avoid
processing invalid ones. With a filter processor in
place, Mule discards any message it receives that
does not match the filter’s parameters — a message
from outside a set range of IP addresses, for
example.
 Filter unsecure messages

Mule CRC32 Processor :
 Mule can apply a cyclic redundancy check (CRC) to
messages to ensure message integrity. CRC uses an
algorithm to apply a check value to a message when it
enters a system, and verifies the value when the message
leaves the system. If the entry and exit values do not
match, CRC marks the message as changed. Generally,
CRC32 (32 indicates the 33-bit polynomial length in the
algorithm) detects unintentional changes to messages,
such as the accumulation of “noise” between
transmission points, but it can also detect unauthorized
intentional changes – for instance, flagging a message
that has been tampered with during transmission to
change it into a Trojan horse.
 Apply a CRC to a message

2. Configuring Security :
 Mule ESB allows you to authenticate requests via
connectors using transport-specific or generic
authentication methods. It also allows you to control
method-level authorization on your components. The
Security Manager is responsible for authenticating
requests based on one or more security providers.
 For information on the elements you can configure for
the Security Manager, seeSecurity Manager
Configuration Reference. The following sections provide
links to information on configuring different types of
security managers.

Spring Security 3.0 :
 Spring Security is the next version of Acegi and
provides a number of authentication and
authorization providers such as JAAS, LDAP, CAS
(Yale Central Authentication service), and DAO. The
following topics will help you get started securing
your flows using Spring Security:
 Configuring the Spring Security Manager
 Component Authorization Using Spring Security
 Setting up LDAP Provider for Spring Security

WS-Security and SAML :
 WS-Security is a standard protocol for applying security to
Web services. It contains specifications on how integrity and
confidentiality in a SOAP message can be enforced via XML
signatures and binary security tokens such as X.509
certificates and Kerberos tickets as well as encryption headers.
It ensures end-to-end security by working in the application
layer as opposed to the transport layer. Mule provides the
following resources for WS-Security:
 Enabling WS-Security - Describes how to secure your
CXF connectors with WS-Security.
 SAML Module - Mule now supports the SAML standard for
exchange of security information between systems. This
module is available in the enterprise edition of Mule as of
version 2.2.3

Other Security Integration :
 Mule also supports the following security
technologies:
 Encryption Strategies - Secure your messages by
encrypting them.
 PGP Security - Secure your messages by encrypting
them with PGP.
 Jaas Security

3. FIPS 140-2 Compliance Support :
 As of Mule 3.5.0, Mule ESB can be configured to run
in a FIPS 140-2 certified environment. Note that
Mule does not run in FIPS security mode by default.
There are two requirements:
 Have a certified cryptography module installed in
your Java environment
 Adjust Mule ESB settings to run in FIPS security
mode

3. Testing :
 This section describes how to test your Mule
application.
 Introduction to Testing Mule
 Unit Testing
 Functional Testing
 Testing Strategies
 MUnit

1. Introduction to Testing Mule :
 Typically, existing, bundled tests can fill many of
your testing requirements. Thesrc/test/ directory in
every Mule ESB Maven project incorporates both
unit and functional tests. The included
Maven tests project contains additional useful
functional and integration tests.

Types of Testing :
 You can leverage the following bundled tests when
configuring and customizing Mule:
 Unit testing of your simple extensions and
customizations
 Functional testing of your Mule configuration and setup
 Functional and unit testing of your custom modules and
transports
 Integration testing of multiple modules, transports, and
transformers, etc.
 System testing of transports that connect to embedded or
external services
 Stress and performance testing

Performance Tests :
 After you have ensured that your setup and
configuration are correct and that your
customizations work correctly, verify that your
system is performing as intended. RunJapex
benchmark tests to test individual packages.
Additionally, the Mule Profiler Packcan identify
memory leaks in your customizations.

Using MuleForge for Continuous Integration
Testing :
 If you host your Mule project on MuleForge, you can
take advantage of continuous integration testing.
MuleForge automatically builds hosted projects
using Bamboo, a Continuous Integration Build
Server from Atlassian. The build frequency for
source code is every 30 minutes, while the snapshot
build frequency is once per day. You can request
different frequencies for your individual project.
 For more information on hosting your project,
visit MuleForge.

2. Unit Testing :
 Mule ESB provides a Test Compatibility Kit (TCK) of
unit tests that you can use to test your simple
extensions as well as your custom modules and
transports. The unit tests are located in the -
tests.jar file, such as mule-core-3.0.0-tests.jar for
Mule version 3.0.0. All unit tests inherit
from org.mule.tck.AbstractMuleTestCase
 These unit tests are beneficial for the following
reasons:

 Components tested with a TCK test case ensure that the
common behavior of the component is compatible with the
Mule framework.
 Using a TCK test case allows the developer to concentrate on
writing tests for specific behavior of their component.
 Where testing of a method in the Component API cannot be
tested by the TCK test case, the test cases provides an abstract
method for the test, ensuring the developer tests all areas of
the component.
 The TCK provides a default test model that is a simple set of
test classes. The developer doesn’t need to worry about
writing new test classes for their test cases each time.
 The abstract test cases in the TCK use JUnit’s TestCase, so
they are compatible with other test cases.

Testing Component : Description :
 AbstractMuleTestCase  A helper test case
providing methods for
creating test and mock
object types. This is the
base class for all other
abstract TCK classes.
unit tests in the Mule TCK:

 AbstractConnectorTest
Case
 Used to test the
common behavior of a
connector. This tests
dispatching and
sending events using
mock objects.

 AbstractMuleMessageF
actoryTestCase
 Provides tests for all
the standard methods
defined in
theMuleMessageFactor
y interface. Add
specific tests for
converting your
transport message to a
MuleMessage in your
subclass.

 AbstractMessageReceiv
erTestCase
 Used to test the
common behavior of
aMessageReceiver.
This tests receiving
messages using mock
objects.

 AbstractComponentTes
tCase
 This is the base class for unit
tests that test custom component
implementations. Concrete
subclasses of this base class
includeDefaultJavaComponentTe
stCase,PooledJavaComponentTe
stCase,
andSimpleCallableJavaCompone
ntTestCase, each of which
contains methods for testing that
component type. For example,
theDefaultJavaComponentTestC
aseincludes methods for testing
the creation, lifecycle, and
disposal of a basic Java
component.

 AbstractTransformerTe
stCase
 Used to test transformers.
This class defines a number
of tests that ensures that
the transformer works in
single scenarios as well as
in round trip scenarios.
There are many concrete
sub-classes of this abstract
class that test specific types
of transformers, such
asStringByteArrayTransfor
mersTestCase.

 DefaultMuleContextTe
stCase
 Tests the creation and
disposal of the Mule
context.

3. Functional Testing :
 Because Mule ESB is light-weight and embeddable, it
is easy to run a Mule Server inside a test case. Mule
provides an abstract JUnit test case
calledorg.mule.tck.junit4.FunctionalTestCase that
runs Mule inside a test case and manages the
lifecycle of the server.
The org.mule.tck.functional package contains a
number of supporting classes for functionally testing
Mule code, includingFunctionalTestComponent.
These classes are described in more detail in the
following sections.

FunctionalTestComponent :
 The previous example of FunctionalTestCase covers
many common (synchronous) test scenarios, where
the flow responds directly to the
caller. FunctionalTestComponent can help support
richer tests, such as:
 Simulating asynchronous communication
 Returning mock data to the caller
 Common scenarios such as forced exceptions,
storing message history, appending text to
responses, and delayed responses.

4. Testing Strategies :
 Building a comprehensive suite of automated tests for your Mule
project is the primary factor that will ensure its longevity: you’ll gain
the security of a safety net catching any regression or incompatible
change in your applications before they even leave your
workstation.
 We’ll look at testing under three different aspects:
 *Unit testing: these tests are designed to be fast, with a very narrow
system under test. Mule is typically not run for unit tests.
*Functional testing: these tests usually involve running Mule,
though with a limited configuration, and should run fast enough to
be executed on each build.
*Integration testing: these tests exercise a full Mule application with
settings that are as close to production as possible. They are usually
slower to run and not part of the regular build

Unit Testing :
 In a Mule application, unit testing is limited to the code that
can be realistically exercised without the need to run it inside
Mule itself. As a rule of thumb, code that is Mule aware (for
example, code that relies on the registry), will better be
exercised with a functional test
 With this in mind, the following are good candidates for unit
testing:
 *Custom transformers
*Custom components
*Custom expression evaluators
*All the Spring beans that your Mule application will use.
Typically, these beans come as part of a dependency JAR and
are tested while being built, alleviating the need for re-
retesting them in your Mule application project

Functional Testing :
 Functional tests are those that most extensively
exercise your application configuration. In these
tests, you’ll have the freedom and tools for
simulating happy and unhappy paths.
 The "paths" that you will be interested to cover
include:
 *Message flows
*Rule-based routing, including validation handling
within these flows
*Error handling

5. Munit :
 Munit is Beta-version Mule testing framework that allows
you to:
 mock the output of your message processors
 write tests in XML or Java
 create tests in the Anypoint Studio drag-and-drop interface
 insert spy functionality to track what happens before and after
a message processor is called
 view coverage reports in Studio
 run tests with your plugins
 access detailed Mule stacktraces that pinpoint message
processor failures
 integrate with Maven and Surefire for continuous integration
support

What is Munit ?
 MUnit is a Mule application testing framework that
allows you to easily build automated tests for your
integrations and APIs. It provides a full suite of
integration and unit test capabilities, and is fully
integrated with Maven and Surefire for integration
with your continuous deployment environment.

Purpose of MUnit :
 Create your Mule test by writing Mule code
 Create your Mule test by writing Java code
 Disable flow inbound endpoints
 Disable endpoint connectors
 Mock outbound endpoints
 Mock message processors

 Create not only unit tests but also integration tests in
a local environment — MUnit allows you to start a
local FTP/SFTP, DB server or mail server
 Call the Mule client from Mule code
 Assert flow exceptions
 Spy any message processor
 Verify message processor calls

 Enable or disable particular tests
 See assertion/error reports with Mule stack trace
 Extend the MUnit framework with plugins
 Check visual coverage in Studio
 Debug your tests with Studio

MUnit Compatibility :
 MUnit is divided among several sub modules. From
a user’s point of view there are only two that are
really important. Both modules are compatible
amongst themselves.
 The important sub modules are:
MUnit Version Mule MUnit Support
Version
1.0.x 3.6.x, 3.7.x
1.1.x 3.6.x, 3.7.x

Mule MUnit Support :
 The Mule MUnit Support module is meant to follow
Mule ESB releases:
Mule MUnit Support
Version
Mule ESB Version
3.6.x 3.6.0 to 3.6.x
3.7.x 3.7.0 to 3.7.x

MUnit and Anypoint Studio :
 MUnit is fully integrated with Anypoint Studio,
allowing you to create, design and run MUnit tests
just like you would Mule applications. You can also
use Anypoint Studio’sStudio Visual Debugger to
debug your MUnit tests.

Using MUnit in Anypoint Studio :
 MUnit is fully integrated with Anypoint Studio. You
can use Studio’s graphical interface to:
 Create and design MUnit tests
 Run your tests
 View test results and coverage
 Debug your tests

MUnit Suite :
 The base of the MUnit Framework consists
of MUnit Test Suite files. These files are
the.xml files located under the src/test/munit folder
in your Mule application’s folder structure. Each
MUnit Test Suite file is a collection of MUnit tests. It
is meant to work on its own, and should be able to
run independently from any other MUnit test suite
files.

Components of an MUnit Test Suite :
 An MUnit test suite file should contain any
combination of the following components:
 Imports
 Bean Definitions
 Before/After Suites
 Before/After Tests
 MUnit Tests

Flows in mule

Recommended

More Related Content

What's hot (18)

Viewers also liked (20)

Similar to Flows in mule (20)

More from Sindhu VL (15)

Recently uploaded (20)

Flows in mule