FLows in Mule:How the mule message from one flow to another through flow reference

1. Flows in Mule
PRESENTED BY
KARTHIK

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

3. 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.

4. 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.

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

6. 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.

7. 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.

9. Mule Debugger View :

10. 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

11. 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

12. 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.

13.  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

14. 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.

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

16. 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:

17.  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

18. 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.

19. 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.

20. 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

21. 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

22. 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

23. 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

24. 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

25. 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.

26. 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

27. 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

28. 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

29. 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

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

31. 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.

32. 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

33. 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.

34. 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.

35. 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:

36.  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.

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

38. unit tests in the Mule TCK:
Testing Component :
 AbstractConnectorTestCase
Description :
 Used to test the common
behavior of a connector.
This tests dispatching and
sending events using mock
objects.

39. unit tests in the Mule TCK:
Testing Component :
 AbstractMuleMessageFact
oryTestCase
Description :
 Provides tests for all the
standard methods defined
in
theMuleMessageFactory in
terface. Add specific tests
for converting your
transport message to a
MuleMessage in your
subclass.

40. unit tests in the Mule TCK:
Testing Component :
 AbstractMessageReceiverT
estCase
Description :
 Used to test the common
behavior of
aMessageReceiver. This
tests receiving messages
using mock objects.

41. unit tests in the Mule TCK:
Testing Component :
 AbstractComponentTestCa
se
Description :
 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.

42. unit tests in the Mule TCK:
Testing Component :
 AbstractTransformerTestCa
se
Description :
 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
asStringByteArrayTransforme
rsTestCase.

43. unit tests in the Mule TCK:
Testing Component :
 DefaultMuleContextTestCa
se
Description :
 Tests the creation and
disposal of the Mule
context.

44. 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.

45. 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.

46. 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

47. 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

48. 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

49. 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

50. 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.

51. 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

52.  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

53.  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

54. 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

55. 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

56. 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.

57. 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

58. 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.

59. 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

60. ThankYou!!!!!!