Mulesoft Support | Job Assistance at Lower Price

Mulesoft ESB Training and support/ Job Assistances provided . mail to: sravanyadav2013@gmail.com to know more

Tuesday, 6 March 2018

Mule - Scopes

 

Mulesoft - SCOPES

Scopes are nothing but the processing blocks. Scopes like poll,Message enricher, until successful require to embed only one message processor within processing block.

 

Composite Source:

The processor inside Composite source are actually message sources, known as inbound connectors which listens parallel on different channels for incoming messages.

 

Synchronous means: Processing in main flow stops and all Message processors in child flow execute before parent flow resumes.

Asynchronous means: Parent flow doesn’t wait for child flow to complete.

 

Async Scope:

In Async Scope , when parent flow receives a message, it sends a copy of message onto the next message processor in parent flow , while simultaneously processing another copy of messagethrough its own.

 

Sub-flow Scope:

It is a synchronous flow. After receiving message from aren’t flow through flow-ref, the child flow go through message processors contain in it and then further parent flow continues.

 

Cache Scope:

It caches data produced by part of that particular flow. Wrap Cache scope around message processors in your flow, so it caches the response events produced within flow.

ForEach :

Splits any type of message collection and then aggregates them again at the end of scope.

·       You cannot drag inbound-connector inside for loop .

·       If you drag a two-way connector into foreach loop , mule automatically converts it into outbound-only connector

 

Message Enricher:

Appends information to a message , often expression is used to tell what part of payload to evaluate , so to return appropriate value to append to payload.

e.g.: The expression can evaluate pincode and then append associated state and city to payload

 

Poll:

Polling is used to trigger the connector, placed in it at regular intervals or the time set using cron expression.

 

Transactional:

Series of steps in flow must succeed or fail as one unit. Place something inside Transactional component and the output will always be either success or failure.

Until Successful:

Attempts at a specified interval, to route a message to an embedded message processor until one of the following occurs:

·       Message processor succeeds.

·       Maximum number of retries reached .

·       An exception is thrown.

Request-Reply Scope:

Request-reply scope enables us to embedded a part of async processing within Muleflow. Simply, request-reply converts part of synchronous process into asynchronous one.

Request : Outbound connector that submits an async request to another flow or external resource.

Reply: Inbound connector that receives an async response from another flow or external source

 

Batch-Processing :

A block of code is splitted (messages) into individual records , performs action on each record and report the result and pushes the processed output to other systems or queues .

Useful for streaming input jobs.

**Needs enterprise edition.

 

Batch-Commit :

Batch commit scope is used inside batch-scope .

Eg: To upsert contact numbers to google contacts.

If we are inserting each individual contact, we can configure batch commit to accumulate , say 100 contacts per commit as one chunk.

 

Batch- Scope:

Use as many as you can, inside processing section of main batch scope.

 

Processor-chain:

It is a linear chain of message processors which process in order.

 

Monday, 5 March 2018

Mule 3.xx - Mailing Strategies

Hello Everyone,

This post will give you description on Mailing Strategies provided my Mule.

 

SMTP:

This connector is used to send messages as mail over SMTP using Javax.mail API.

·       SMTPS enable SMTP over SSL.

·       TLS/SSL are also available.

Namespace: xmlns: smtp = http://www.mulesoft.org/schema/mule/smtp

Xmlns: smtps= http://www.mulesoft.org/schema/mule/smtps

(Above namespaces are automatically configured once the connector is placed in flow)

Simple to configure email access on outbound endpoint. TLS configuration is easy.

 

 

POP3:

Pop3 connector is configurable only as inbound endpoint . i.e., message source with one-way exchange pattern. It retrieve emails from POP3 email server.

·       Cannot send mail. Only retrieves mail

 

 

IMAP :

It is same as POP3 connector , configurable only as inbound endpoint with one-way exchange pattern.

 

·       IMAP supports both online and offline modes

·       Cannot send mail. Only retrieves mail

E.g.: IMAP user can leave emails on IMAP server until they are explicitly deleted.

 

SMTP

POP3

IMAP

Send mails

Receive mails

Receive mails

Online

Online

Online & Offline

TSL-Yes

TSL-Yes

TSL-Yes

Outbound

Inbound

Inbound

 

 

 

Friday, 2 March 2018

Mule - Processing Strategies

Hello Everyone,
This post will have a glance on what is Processing Strategy ? How we Choose it or how Mule Application selects by default etc.
This concept will help us to develop applications in a reliable way .
Processing Strategy determines how Mule implements Message processing for a given flow(s).
It determines by:
Ø Should message be processed synchronously or asynchronously? (Explained earlier)
Ø Should message be Non-Blocking strategy?
Ø If asynchronously , what are properties of pool of threads used to process messages.
Ø If asynchronously , how messages wait for their turn to be processed in 2nd thread.
All Mule Flows have a Default or implicit Startegy which mule applies automatically.
Implicit Processing Strategy :
Even though we do not define Processing Strategy for flow created, it will be automatically applied by Mule. It can be :
a)    Synchronous flow Processing Strategy
b)    Queued Asynchronous flow Processing Strategy.
How does it selects???
It can be selected based on 2 criteria’s :
1)    Flow’s Exchange pattern :
There are two types of exchange patterns and based on it , the strategy is defined.
a) Request-response exchange pattern: It is used when sender, I.e, inbound endpoint expects response or some result to return to caller.
b) One-way Response exchange pattern: It is used when no-response is expected or when result is sent to some other flow.
If its request response processing strategy, then its Synchronous Processing Strategy.
2)    Whether or not flow is transactional :
If flow is transactional, then it is Synchronous Processing Strategy
Exchange Pattern
Transactional
Processing Strategy
Request-Response
Yes
Synchronous
Request-Response
No
Synchronous
One-way
Yes
Synchronous(because Transaction is Yes)
One-way
No
Queued Asynchronous
Note: Request-response ----- Blindly Synchronous
Transaction if Yes-----Blindly Synchronous
Some Options:
a)    Change to Synchronous : If mule selects Queued Asynchronous Processing Strategy , we can specify a Synchronous flow to achieve reliability.
b)    Fine Tune: We can accept Mule’s choice of Queued Asynchronous Processing Strategy , but fine-tune it . Remember, we cannot fine tune Synchronous Flow.
c)     Wrap a Flow: Inside async Scope, we can wrap one or more message processors to achieve Asynchronous Processing Strategy.
d)    Sub-flow: It’s a Synchronous Processing Strategy
e)    Non-Blocking Strategy: Available in 3.7+ version . To avoid having threads blocked while waiting for Http-responses, which also requires less tuning. (Note: Not all components are supported. Non supported components fall back to Synchronous Processing Strategy).
f)      Custom: We can create custom Processing Strategy by specifying in xml as :
<flow name=”xxx” processing strategy =” Processing Strategy name” >
Strategy
Description
Non-blocking
Applies using Http listener
Thread-per processor
Here every processor runs sequentially in different thread
Asynchronous
Not applicable in most cases
Queued -thread
Not applicable in most Cases

Thursday, 1 March 2018

Mulesoft -ERROR HANDLING 3.xx version

This post helps you to understand basic things in knowing about how Mulesoft handles Errors.

Mule's Default Exception Strategy is implicitly applied to all Mulesoft Applications (Exceptions thrown within Muleflows).If we want more sophisticated or customized forms of error management, we can implement one or more exception strategies.


  1. System Exceptions : Mule invokes System Exception Strategy  when an exception is thrown at System level(i.e, when no message is involved) . For eg., During Application start-up or connection to external systems like Database, cloud connectors, Salesforce etc. fails.
    When exception occurs, Mule sends a notification to registered listeners/logs exception.
    If it is a connection failure, Reconnection Strategy is executed.
    System Exceptions are not configurable in Mule.
  2. Messaging Exception: Mule invokes Messaging Exception Strategy when an exception is thrown within a flow.
    When exception is occurred within the flow , normal flow execution stops and process transfers to Message Processors within the exception Strategy.


Exception Strategy
Use
Transaction Error Handling
Default Exception Strategy
Defined and implicitly applied by default , to handle all messaging exceptions thrown in Mule Applications
When message throw an exception , the default Exception Strategy rolls back message and logs exception.
Catch Exception Strategy
Define a catch exception strategy to customize the way Mule handles any exception. It consumes inbound messages.
When message throws exception, catch Exception Strategy always commits the transaction and consumes message
Rollback Exception Strategy
It is defined to ensure that message that throw an exception in a flow is rolled back for reprocessing (only if message source supports redelivery) . Do not consume inbound message
It makes one or more attempts to rollback message and redeliver for processing. If it exceeds attempts, then Rollback consumes inbound message.
Reference Exception Strategy
Define a reference to refer to error handling defined in global/catch or choice exception .
Reference itself never commits, never rollback nor consume activity.
Choice Exception Strategy
Customize the way mule handles exceptions based on message’s content.
Choice Exception strategy itself never rollback/commits nor consumes.