Uploaded byppts123456
PPTX, PDF342 views

Flowsinmule 160517130818

The document discusses various topics related to testing Mule applications including: 1. It describes different types of testing for Mule like unit testing, functional testing, integration testing, and performance testing. 2. It provides details on the unit testing framework in Mule, including base test classes for different components. 3. It discusses how to perform functional testing in Mule using the FunctionalTestCase and supporting classes like FunctionalTestComponent.

Download to read offline
Flows in Mule PRESENTED BY KARTHIK
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.
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 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.
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.
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.
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.
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.
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.
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.
unit tests in the Mule TCK: Testing Component :  DefaultMuleContextTestCa se Description :  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
ThankYou!!!!!!

More Related Content

PPT
MULE-JAAS
byD.Rajesh Kumar
 
PPTX
Flows in mule
bySindhu VL
 
PPTX
Mule ESB - Intra application communication
bykrishananth
 
PPTX
Mule integration with Servicenow
byRamakrishna Narkedamilli
 
PPTX
Integration with Salesforce using Mule ESB
bySanjeet Pandey
 
PPTX
Anypoint b2 b
byAchyuta Lakshmi
 
PPT
Mule security - jaas
byD.Rajesh Kumar
 
PPTX
Mulesoft Salesforce Connector - OAuth 2.0 JWT Bearer
byVince Soliza
 
MULE-JAAS
byD.Rajesh Kumar
 
Flows in mule
bySindhu VL
 
Mule ESB - Intra application communication
bykrishananth
 
Mule integration with Servicenow
byRamakrishna Narkedamilli
 
Integration with Salesforce using Mule ESB
bySanjeet Pandey
 
Anypoint b2 b
byAchyuta Lakshmi
 
Mule security - jaas
byD.Rajesh Kumar
 
Mulesoft Salesforce Connector - OAuth 2.0 JWT Bearer
byVince Soliza
 

What's hot

PPTX
Integration with Sercice-Now using Mule ESB
bySanjeet Pandey
 
PPT
Mule security - jaas
bycharan teja R
 
PPT
Anypoint platform highlights
byhimajareddys
 
PPTX
Mulesoft Calling Flow of Other Applications
bykumar gaurav
 
PPT
Mule security
byD.Rajesh Kumar
 
PPTX
Mule Microsoft Share Point 2010 Connector
byAnkush Sharma
 
PPTX
Integrate facebook using mule esb
bySanjeet Pandey
 
PPTX
Query in share point by mule
bySon Nguyen
 
PPTX
Get Data from Microsoft CRM using Mule ESB
bySanjeet Pandey
 
PPTX
Mule management console
bysrinivasvaddanam
 
PPT
Mule security-jaas
byPraneethchampion
 
PPTX
Mule Salesforce Connector
byAnkush Sharma
 
PPTX
Connecting to salesforce and using database in mule
byRaviShankar Mishra
 
PPTX
Mule esb stripe
byD.Rajesh Kumar
 
PPT
Mule anypoint b2 b
byD.Rajesh Kumar
 
Integration with Sercice-Now using Mule ESB
bySanjeet Pandey
 
Mule security - jaas
bycharan teja R
 
Anypoint platform highlights
byhimajareddys
 
Mulesoft Calling Flow of Other Applications
bykumar gaurav
 
Mule security
byD.Rajesh Kumar
 
Mule Microsoft Share Point 2010 Connector
byAnkush Sharma
 
Integrate facebook using mule esb
bySanjeet Pandey
 
Query in share point by mule
bySon Nguyen
 
Get Data from Microsoft CRM using Mule ESB
bySanjeet Pandey
 
Mule management console
bysrinivasvaddanam
 
Mule security-jaas
byPraneethchampion
 
Mule Salesforce Connector
byAnkush Sharma
 
Connecting to salesforce and using database in mule
byRaviShankar Mishra
 
Mule esb stripe
byD.Rajesh Kumar
 
Mule anypoint b2 b
byD.Rajesh Kumar
 

Viewers also liked

PPTX
MuleSoft ESB Sending email using hmailserver
byakashdprajapati
 
PPTX
Mule scopes foreach_scope
bykunal vishe
 
PPTX
Introduction testingmule
bySrikrishna k
 
PPTX
Mule concepts filters scopes_routers
bykunal vishe
 
PPTX
Polyglot Mule Transformers
bySulthony Hartanto
 
PPTX
Mule concepts connectors
bykunal vishe
 
PPTX
Mule concepts components
bykunal vishe
 
PPTX
Mulehdfsconnector 160810122655
byppts123456
 
PPTX
Mule: Java Component
bySulthony Hartanto
 
PPTX
Mule message
bykunal vishe
 
PDF
Processing files sequentially in mule
byPriyobroto Ghosh (Mule ESB Certified)
 
PPTX
Mule: JSON to Object
bySulthony Hartanto
 
PPTX
Mule concepts exception strategies
bykunal vishe
 
PPTX
Mulesoft Soap Service
byUjjawal Kant
 
PPTX
Mule: Java Transformer
bySulthony Hartanto
 
PPTX
Creating a mule project with raml and api
byBhargav Ranjit
 
PPTX
Mule concepts elements in a mule flow
bykunal vishe
 
PPTX
Mule soft esb – data validation best practices
byalfa
 
PPT
Mule esb api layer
byAnand kalla
 
PPT
Mule webservices in detail
byShahid Shaik
 
MuleSoft ESB Sending email using hmailserver
byakashdprajapati
 
Mule scopes foreach_scope
bykunal vishe
 
Introduction testingmule
bySrikrishna k
 
Mule concepts filters scopes_routers
bykunal vishe
 
Polyglot Mule Transformers
bySulthony Hartanto
 
Mule concepts connectors
bykunal vishe
 
Mule concepts components
bykunal vishe
 
Mulehdfsconnector 160810122655
byppts123456
 
Mule: Java Component
bySulthony Hartanto
 
Mule message
bykunal vishe
 
Processing files sequentially in mule
byPriyobroto Ghosh (Mule ESB Certified)
 
Mule: JSON to Object
bySulthony Hartanto
 
Mule concepts exception strategies
bykunal vishe
 
Mulesoft Soap Service
byUjjawal Kant
 
Mule: Java Transformer
bySulthony Hartanto
 
Creating a mule project with raml and api
byBhargav Ranjit
 
Mule concepts elements in a mule flow
bykunal vishe
 
Mule soft esb – data validation best practices
byalfa
 
Mule esb api layer
byAnand kalla
 
Mule webservices in detail
byShahid Shaik
 

Similar to Flowsinmule 160517130818

PPTX
Flows in mule
bySon Nguyen
 
PPTX
Securing mule
bySindhu VL
 
PPTX
Mule securing
bySindhu VL
 
PPTX
Baltimore jan2019 mule4
byManjuKumara GH
 
PPTX
Mule Security
byShanky Gupta
 
DOCX
Mule esb beginner’s guide
byD.Rajesh Kumar
 
PPT
Mule anypoint enterprise security
byD.Rajesh Kumar
 
PPTX
Mule enterprise security
bykeshav Naidu
 
PPTX
Cmm vm 002
byLalit Panwar
 
PDF
Mule ESB
byYura Nosenko
 
PDF
Mule soft meetup_indonesia_june2020
byWendyTey4
 
PPTX
Anypoint enterprise security overview
bydanishsm84
 
PPTX
Mule soft Meetup #3
byGaurav Sethi
 
PPTX
Ashok mule esb
byaskumar037
 
PPTX
Mule
bysaikiran6423
 
PPTX
Mule slides
bynaveenkodumuri12
 
PPTX
Mule
bysaikiran6423
 
PPTX
Sai mule esb batch
bysaikiran6423
 
PPTX
Esb process
bysaikiran6423
 
PPTX
Mule esb kranthi
byEarnest Stephen
 
Flows in mule
bySon Nguyen
 
Securing mule
bySindhu VL
 
Mule securing
bySindhu VL
 
Baltimore jan2019 mule4
byManjuKumara GH
 
Mule Security
byShanky Gupta
 
Mule esb beginner’s guide
byD.Rajesh Kumar
 
Mule anypoint enterprise security
byD.Rajesh Kumar
 
Mule enterprise security
bykeshav Naidu
 
Cmm vm 002
byLalit Panwar
 
Mule ESB
byYura Nosenko
 
Mule soft meetup_indonesia_june2020
byWendyTey4
 
Anypoint enterprise security overview
bydanishsm84
 
Mule soft Meetup #3
byGaurav Sethi
 
Ashok mule esb
byaskumar037
 
Mule
bysaikiran6423
 
Mule slides
bynaveenkodumuri12
 
Mule
bysaikiran6423
 
Sai mule esb batch
bysaikiran6423
 
Esb process
bysaikiran6423
 
Mule esb kranthi
byEarnest Stephen
 

More from ppts123456

PPTX
Anypointconnectordevkit 160816041722
byppts123456
 
PPTX
Muleesbcomponents1 160625154208
byppts123456
 
PPTX
Mulefundamentals 160503050909
byppts123456
 
PPT
4 150915033746-lva1-app6892
byppts123456
 
PPT
Mulethenewtechnology 12549172699166-phpapp03-160421133841
byppts123456
 
PPTX
Deployingmuleapplications 160903085602
byppts123456
 
PPTX
Mulesoftanypointplatformintro
byppts123456
 
PPT
Mule overview
byppts123456
 
PPT
Wsdl
byppts123456
 
PPTX
2016 08-08 ecology and environment
byppts123456
 
PPTX
Algorithm analysis and efficiency
byppts123456
 
PPT
E procureppt
byppts123456
 
Anypointconnectordevkit 160816041722
byppts123456
 
Muleesbcomponents1 160625154208
byppts123456
 
Mulefundamentals 160503050909
byppts123456
 
4 150915033746-lva1-app6892
byppts123456
 
Mulethenewtechnology 12549172699166-phpapp03-160421133841
byppts123456
 
Deployingmuleapplications 160903085602
byppts123456
 
Mulesoftanypointplatformintro
byppts123456
 
Mule overview
byppts123456
 
Wsdl
byppts123456
 
2016 08-08 ecology and environment
byppts123456
 
Algorithm analysis and efficiency
byppts123456
 
E procureppt
byppts123456
 

Recently uploaded

PPTX
Advanced Risk Assessment Module for Enhanced Workplace Safety
byEHA Soft Solutions
 
PDF
Comprehensive Guide to Cascading Style Sheets (CSS)
byJaydeep Kale
 
PDF
Evolution and Examples of Java Features, from Java 1.7 to Java 25
byYann-Gaël Guéhéneuc
 
PDF
How App Developers in London UK Empower Digital Businesses – US APP Developer...
byIndia App Developer
 
PPTX
Building smarter with AI - From Idea to Market at Warp Speed
byLuca Grulla
 
PDF
Agentic AI meets Serverless on AWS - AWS User Group Cologne 2025
byVadym Kazulkin
 
PDF
Comprehensive Logging with mORMot 2 on Delphi and FPC
byArnaud Bouchez
 
PDF
Working with Machine Learning in Production
byFrederick Apina
 
PDF
git - from commit to merge - semcomp beta 2018 workshop
byJoao Marins
 
PDF
Workshop about mORMot 2 during EKON: write a clean-architecture TDD sample
byArnaud Bouchez
 
PDF
VADY AI-Powered Business Intelligence — Turning Raw Data into Strategic Growth
byNewFangledVision
 
PPTX
B2B Marketing Attribution Solutions - VALiNTRY360
byVALiNTRY360
 
PDF
The Ultimate Guide to Software POC Development and Validation
byShiv Technolabs Pvt. Ltd.
 
PDF
Guidewire Connections 2025 PT 6 Unleash the Power of Agentic AI with Guidewire
byBrian Petrini
 
PPTX
power point presentation of Soft computing
byyashhjain24
 
PDF
How Code and Pixels Expertise Can Deliver Superior E-Learning Content .pdf
byelearningdevelopment
 
PPTX
Lifecycle of Automated Testing: A Step-by-Step Journey from Planning to Repor...
bySophie Lane
 
PDF
Comprehensive Guide to Performance Testing Tools and Services
byKanika Vatsyayan
 
PDF
Why an Airbnb Clone is the Perfect Start for Your Rental Marketplace.
byTechBuilder
 
PDF
Automated Compliance Through DevSecOps as a Service
byVish techno
 
Advanced Risk Assessment Module for Enhanced Workplace Safety
byEHA Soft Solutions
 
Comprehensive Guide to Cascading Style Sheets (CSS)
byJaydeep Kale
 
Evolution and Examples of Java Features, from Java 1.7 to Java 25
byYann-Gaël Guéhéneuc
 
How App Developers in London UK Empower Digital Businesses – US APP Developer...
byIndia App Developer
 
Building smarter with AI - From Idea to Market at Warp Speed
byLuca Grulla
 
Agentic AI meets Serverless on AWS - AWS User Group Cologne 2025
byVadym Kazulkin
 
Comprehensive Logging with mORMot 2 on Delphi and FPC
byArnaud Bouchez
 
Working with Machine Learning in Production
byFrederick Apina
 
git - from commit to merge - semcomp beta 2018 workshop
byJoao Marins
 
Workshop about mORMot 2 during EKON: write a clean-architecture TDD sample
byArnaud Bouchez
 
VADY AI-Powered Business Intelligence — Turning Raw Data into Strategic Growth
byNewFangledVision
 
B2B Marketing Attribution Solutions - VALiNTRY360
byVALiNTRY360
 
The Ultimate Guide to Software POC Development and Validation
byShiv Technolabs Pvt. Ltd.
 
Guidewire Connections 2025 PT 6 Unleash the Power of Agentic AI with Guidewire
byBrian Petrini
 
power point presentation of Soft computing
byyashhjain24
 
How Code and Pixels Expertise Can Deliver Superior E-Learning Content .pdf
byelearningdevelopment
 
Lifecycle of Automated Testing: A Step-by-Step Journey from Planning to Repor...
bySophie Lane
 
Comprehensive Guide to Performance Testing Tools and Services
byKanika Vatsyayan
 
Why an Airbnb Clone is the Perfect Start for Your Rental Marketplace.
byTechBuilder
 
Automated Compliance Through DevSecOps as a Service
byVish techno
 

Flowsinmule 160517130818

  • 1.
  • 2.
    1. Debugging  Thissection 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 VisualDebugger :  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 DebugMode :  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 Dataat 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.
  • 10.
    Troubleshooting :  Thissection 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 RunningMule 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 :  heless 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 SecureToken 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 ApplicationsNeed 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 EnterpriseSecurity :  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-2Compliance 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 toTesting 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 ContinuousIntegration 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 testedwith 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 inthe 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 inthe 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 inthe 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 inthe 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 inthe 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 inthe 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 inthe 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 :  Theprevious 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 notonly 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 ordisable 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 AnypointStudio :  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 inAnypoint 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 anMUnit 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.