flows in mule

PRESENTED BYSINDHU VL

Flows in Mule

1. Debugging

This section describes how to debug your Mule application using:

Studio Visual DebuggerTroubleShooting

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.

Mule Debugger View :

Troubleshooting :

This section introduces a number of techniques useful in troubleshooting Mule problems and in gathering information for technical support.

Configuring Mule StacktracesDebugging Outside StudioLogging

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 argumentsSetting properties in Mule StudioUsing 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 -debugWith 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 SecurityConfiguring SecurityFIPS 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 VaultMule Message Encryption ProcessorMule Digital Signature ProcessorMule Filter ProcessorMule 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 payloadDecrypt 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 MuleSign part of a message payloadVerify 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 ManagerComponent Authorization Using Spring SecuritySetting 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 MuleUnit TestingFunctional TestingTesting StrategiesMUnit

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 setupFunctional and unit testing of your custom modules and

transportsIntegration testing of multiple modules, transports, and

transformers, etc.System testing of transports that connect to embedded

or external servicesStress 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:


AbstractConnectorTestCase

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



AbstractMuleMessageFactoryTestCase

Provides tests for all the standard methods defined in theMuleMessageFactory interface. Add specific tests for converting your transport message to a MuleMessage in your subclass.



AbstractMessageReceiverTestCase

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



AbstractComponentTestCase

This is the base class for unit tests that test custom component implementations. Concrete subclasses of this base class includeDefaultJavaComponentTestCase,PooledJavaComponentTestCase, andSimpleCallableJavaComponentTestCase, each of which contains methods for testing that component type. For example, theDefaultJavaComponentTestCaseincludes methods for testing the creation, lifecycle, and disposal of a basic Java component.



AbstractTransformerTestCase

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



DefaultMuleContextTestCase

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 communicationReturning mock data to the callerCommon 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 processorswrite tests in XML or Javacreate tests in the Anypoint Studio drag-and-drop interface insert spy functionality to track what happens before and

after a message processor is calledview coverage reports in Studiorun tests with your pluginsaccess 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 codeCreate your Mule test by writing Java codeDisable flow inbound endpointsDisable endpoint connectorsMock outbound endpointsMock 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 codeAssert flow exceptionsSpy any message processorVerify message processor calls

Enable or disable particular testsSee assertion/error reports with Mule stack

traceExtend the MUnit framework with pluginsCheck visual coverage in StudioDebug 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.x1.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.x3.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 testsRun your testsView test results and coverageDebug 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:

ImportsBean DefinitionsBefore/After SuitesBefore/After TestsMUnit Tests

ThankYou!!!!!!

flows in mule

Design