Mulesoft

By : Kiran Raj P V

Agenda

Topics

Introduction to Enterprise Service Bus

Introduction to Mule Soft

Basics of Anypoint Studio

Deployment Environments

Questions ?

Enterprise Service Bus (ESB)

• ESB is a middleware which acts as an information highway aiding multiple applications to communicate

• Software architecture model used for connecting Mutually interacting software applications in a Service Oriented Architecture (SOA)

• All the applications communicate with the ESB and the ESB handles the routing of information and internal data format conversion

• Key focus is to decouple systems from each other, allowing them to communicate without dependency on or knowledge of other systems on the bus

ESB Integration principle

• Orchestration - Composing several existing fine-grained components into a single higher order composite service. This promotes reusability and maintainability. Example , bank loan processing application is a simple SOAP-based Web service and orchestrates three backend fine-grained services, namely: Credit Status Check REST - Web service , Retrieve Interest Rate JMS - Legacy service, Store Application to Data Warehouse JDBC - Database applications to create a new composite service.

• Transformation: Data transformation between canonical data formats and specific data formats required by each ESB connector. Canonical data formats can greatly minimize dependencies when integrating applications that use different data formats.

• Transportation: handles different protocols formats (such as HTTP, JMS, JDBC) . A proper ESB will handle multiple protocols in a transparent way and will be able to provide services that expose the desired functionality and hiding the technical details at the same time. This enables the developer that will consume the services to focus on the business processes implementation , instead of protocols.

• Mediation : Components should support multiple interface , like back ward compatibility or legacy format support, for example capability of routing based on the format / protocol etc.

Factors Considered Time Reduction Notes

Design (Architectural design) 75%Simplified designs through fewer components.

No need to introduce a fresh design , several integration patterns are built into component and those component are available to re-use (Mulesoft perspective)

Development 20%

Achieved through the use of new tools built for cloud integration and containing pre-built connectors to a large number of SaaS platforms.

Anypoint Studio Graphical UI to build integration applications toconnect to SaaS and on premise applications and data(Mulesoft perspective)

Release Management 50%

Achieved through reduced governance with fewer teams involved due to consolidation of ESB components.Example: iPaaS network integration done once and then reused for all subsequent integration

Since the sources are decoupled and mainly exposed as reusable REST services through Denodo , for continuous integration, overall review process is reduced (intel Perspective )

New Connectivity (Adaptor/ Connector) / Legacy Adaptors

10%

Achieved through use of prebuilt connectors, community of available connectors, and toolkit for quick connector creation.

(Mulesoft perspective)

Support 50%

Achieved through fewer components, more standardized patterns.Cost savings may be neutral: save on Hardware but pay license fee. Still require L2/L3 support teams.

(Mulesoft perspective)

• The Critical Success Indicators for ESB are based on reducing time to market and increasing agility for both SaaS and on premise integration.

• Project Lifecycle / Reduce the Total Time to Market, TTM, to 25% of the current baseline.

Mule as ESB

• Mule is a lightweight integration platform and service container that allows you to quickly and easily connect your applications together.

• Mule provides a robust, secure and scalable platform to build enterprise applications offering an array of transports such as JMS, HTTP, Email, FTP, JDBC and many more. It also offers a rich set of features for web services, message routing, mediation, transformation and transaction management.

• The ESB can be deployed anywhere, can integrate and orchestrate events in real time or in batch, and has universal connectivity.

To ESB or not ESB ?

• Are you integrating 3 or more applications/services?

• Will you need to plug in more applications in the future?

• Do you need to use more than one type of communication protocol?

• Do you need message routing capabilities such as aggregating message flows, or content-based routing?

• Do you need to publish services for consumption by other applications?

Mule Application / Flow

• Mule applications accept and process messages through a series of message processors plugged together in a flow

• A typical flow has

• A message source

- Accepts a message from an external source triggering the execution of the flow

• Message processors

- Transform, filter, enrich, and process the message

• An application can consist of

- A single flow

- Multiple flows connected together to create more complex applications

Connector It’s a Mule-specific connection to an externalresource of any kind e.g. HTTP , FTP Connector

Endpoint (Inbound or Outbound)

An endpoint is a flow-level element that is configured toreceive and/or send messages from and/or to externalresources e.g. File Connector can act as Inbound or Outbound

Transports Transports provide connectivity to a data source ormessage channel e.g. JMS, File Transport

Components Execute specific logic upon a message, includingcustom-logic in Java, JavaScript, Groovy, Python orRuby e.g. Expression , Script Component

Transformers Convert data types and formats so as to "translate"messages between applications or systems e.g. Data Weave , Json to Object Transformers

Mule Message

• The message header, which contains metadata about the message.

• The message payload, which contains your business-specific data.

• Mule message is, itself, embedded within a Mule message object. Some Mule message objects may contain variables, attachments, and exception payloads.

• Inbound properties are immutable, are automatically generated by the message source and cannot be set or manipulated by the user and it’s scope is within flow.

• Outbound properties are mutable; they are set during the course of a flow and can become inbound properties when the message passes from the outbound endpoint of one flow to the inbound endpoint of a different flow via a transport (not through flow ref)

• Variables are user-defined metadata about a message. Scope can be flow or session

Introduction to Anypoint Studio

Anypoint Studio is an Eclipse-based integration development environment , it includes Two-way editing between graphical and XML views

• Visual debugging (EE)

• Pre-built connectors , Message processors

• Visual data mapping

• One-click deployment of applications

Demo

Mule Connectors

• Each Flow operates on its on Thread Pool

• Message Sources are usually Anypoint Connector - which provides connectivity to external resources such as DB, protocols or API's like Salesforce , Twitter or MongoDB

• Anypoint Connectors (120 pre-build , 30 with Studio bundle )

• There are 2 main types of connectors

- Endpoint-based connectors - are either inbound or outbound endpoints in flow Inbound endpoints are message source Outbound endpoints sends information to external system - can occur mid-flow or at end of flow or at the beginning in a POLL (HTTP,JETTY,FILE,JMS)

- Operation - based connectors - requires specification for an operation for that connector to perform (salesforce , twitter, cmis , web Service Consumer , DB)

Components

• Components are message processors which execute business logic on messages. They enable you to perform specific actions without writing any Mule-specific code.

• Web Components facilitates exposing, consuming, and proxying Web services

• Use a Logger component to log activities in the flow as they occur.

• Use an Expression component to evaluate a particular expression upon a message in a flow.

• Use an Invoke component to invoke the method of an object specified with a Mule expression.

• Use an Echo component to return the payload of a message as a call response.

• Use a Flow Reference component to access another flow from within a flow.

• Use a Batch Execute component to kick off processing of a batch job.

Transformers

• A transformer prepares a message for further processing by enhancing or altering the contents of the message properties, variables, or payload. For example, to convert XML to JSON, use an XML-to-Object transformer followed by an Object-to-JSON transformer.

• Beyond transformation, there is one type of message processor in Mule that both converts and maps data: the Data Weave Transformer, labeled as Transform Message in the palette

Java Object This category contains the bulk of the Mule transformers. Each transformer in this group changes a Java object into another Java object, a Java object into a non-Java data type (such as an HTTP request), or vice versa.

•JSON to Object•XML to Object

Content This group of transformers modifies messages by adding to, deleting from, or converting a message payload.

•Append String•Expression•Parse Template•XSLT

SAP These transformers change SAP objects (JCofunctions or IDoc documents) into XML representations, or vice versa.

•SAP Object to XML•XML to SAP Function (BAPI)•XML to SAP IDoc

Properties, Variables, and Attachments

Rather than acting upon the message payload, these transformers add, remove, or copy properties, variables, and attachments on the message. This group of message processors doesn’t so much transform as manipulate or enrich the contents of the message header.

•Attachment•Property•Session Variable•Variable

Scope

AsyncCreates a block of message processors that execute asynchronously while the rest of the flow continues to execute in parallel

Composite Source

To accept incoming messages from multiple input channels, place two or more message sources (also known as receivers) into a Composite Source. A message entering the Composite Source on any supported channel triggers the processing flow.

For EachSplits any type of message collection apart into individual messages for processing, and then aggregate them again at the end of the scope.

Poll Periodically polls an embedded message receiver for new messages

Sub Flow A flow that is called by another flow. Sub flows inherit their properties from the flow reference and are always synchronous. Provides code reuse.

Until Successful Attempts, at a specified interval, to route a message to an embedded message processor until one of the following occurs:• The message processor succeeds• The maximum number of retries is reached• An exception is thrown

• It is used to encapsulate other message processor so that they function as single unit

Filters

• Filters determine whether a message can proceed through an application flow.

• We can create custom filter according to business requirement

• Global Filters could be defined which can be used in multiple flows

Flow Control / Routers

• Routers (Flow Controls in Anypoint Studio) route messages to various destinations in a Mule flow. Some routers incorporate logic to analyze and possibly transform messages before routing takes place. For example, various flow controls can:

• Split a message into several segments, then route each segment to a different building block.

• Combine several messages into a single message before sending it to the next building block in the flow.

• Reorder a list of messages before sending it to the next building block.

• Evaluate a message to determine which of several possible building blocks it should be routed to next.

• Broadcast the same message to multiple building blocks.

Routers

• The routing message processor Scatter-Gather sends a request message to multiple targets concurrently. It collects the responses from all routes, and aggregates them into a single message.

• By default, if any route fails, Scatter-Gather performs the following actions:

o Sets the exception payload accordingly for each route.

o Throws a CompositeRoutingException, which maps each exception to its corresponding route using a sequential route ID.

o Catching the CompositeRoutingException allows you to gather information on all failed routes

Routers • The Splitter Flow Control splits a message into separate fragments,

then sends these fragments one at a time to the next message processor in the flow

• MULE_CORRELATION_GROUP_SIZE: number of fragments into which the original message was split.

• MULE_CORRELATION_SEQUENCE: position of a fragment within the group.

• MULE_CORRELATION_ID: single ID for entire group (all output fragments of the same original message share the same value).

Custom correlation settings <expression-message-info-mapping messageIdExpression="#[java.util.UUID.randomUUID().toString()]" correlationIdExpression="#[xpath3('//order/@id')]"/>

• These properties helps when an aggregator receives a single fragment, it knows what group to put it into and how large this group should be. Once all of the fragments have arrived, it passes on the complete group as a single message

Error Handling

• Mule’s default exception strategy implicitly and globally handles all messaging exceptions that are thrown in Mule applications. You can override Mule’s default exception strategy by adding a catch, rollback, or choice exception strategy to a flow. Otherwise, when an exception is thrown in a flow, Mule automatically rolls back any pending transaction and logs the exception; if no transaction is involved, the default exception strategy simply logs the

• You can define a catch exception strategy to customize the way Mule handles messages with errors. A catch exception strategy catches all exceptions thrown within its parent flow and processes them, thereby overriding Mule’s implicit default exception strategy.

• Rollback exception strategy - Whenever a message throws an exception, Mule rolls back the transaction (JDBC,JMS ), mule sets a new payload on the message which contains both: Exception Payload as well as original payload message.

• Reference Exception strategy - Define a reference exception strategy to refer and adhere to the error handling parameters defined in a global catch, rollback or choice exception strategy.

REST API support

• RESTful API Modeling Language (RAML) makes it easy to manage the whole API lifecycle from design to sharing.

• Anypoint Studio have great support for Raml & by using APIkit it’s easy to develop API functionalities

• RAML basically have the design specification / usage description (just like wsdl for SOAP based service) of your API. Also, the content-typecan vary from different media resources (like stream ) or most common exchange pattern like json , xml or form based , even custom content-type could be specified and client should be able to process on such content – type

• The best practice for API design with APIkit is first to design the RAML or WSDL interface outside Studio. For RAML development, MuleSoftrecommends using API Designer

Deployment

• During development, applications are deployed on an embedded Mule ESB runtime in Anypoint Studio. For everything else (testing, Q&A, and production), applications can be deployed to

- On-premise Mule Server Runtime

• As a standalone application to a Mule ESB (typically)

• Simpler architecture and better performance

• As a WAR file with an embedded Mule instance to an application server

- CloudHub

• Hosted Mule Server Runtime on AWS

• Integration Platform as a Service (IPaaS)

Intel Server

Mule Run Time

ARM Anypoint Runtime Manager

Mule Runtime Agent

Splunk (External analytics tools)

Cloudhub (AWS)

ARM & Run Time

…On premise server’s in ARM & Agent plugins

Questions ?

References

• https://docs.mulesoft.com• http://raml.org/• Enterprise Integration Patterns - by Gregor Hohpe

• Open Source ESBs in Action: Example Implementations in Mule and ServiceMix - by Jos Dirksen