All Things Integration

When it comes to moving large amounts of data from one place to another rapidly and scaleably, Apache Kafka is a excellent choice for enterprises. As a powerful messaging system, Apache Kafka is  tailored for high throughput use cases where vast amounts of data need to be moved in a  scalable, fault tolerant way. An ideal use case for Apache Kafka is managing data from different data sources such as log streams, records being sent to a database, key value pairs for No SQL databases like Redis all applications creating data at an incredible rate. The rate at which data moves can often  strain existing data stores and require more stores to take on the load.  Furthermore, a messaging environment is dependent on the ability for message consumers to actually consume at a reasonable rate . There is also the challenge of fault-tolerance. Another challenge in existing messaging systems is the fact that most of them are implemented on a single node or host, which generally relies on a limited

Applications which use a transactional transport such as JMS, VM or JDBC are guaranteed that messages will not be lost during the course of processing. Transactional support in these transports ensures that messages are delivered reliably from an inbound endpoint to an outbound endpoint or between processors in a flow. If however you have a web application accessing your flow via a non-transactional transport such as HTTP you can ensure reliable messaging in your flow by implementing a reliability pattern. Reliability patterns couple a reliable acquisition flow with an application logic flow. A reliable acquisition flow can be combined with a series of asynchronous flows to decompose applications into decoupled, reliable segments. Applications which access multiple remote systems as part of their processing which may take a variable amount of time to respond and maybe unreliable are good candidates for this architecture. This blog discusses this approach using a fictions exam

This is an issue I encountered recently whilst trying enable automated deployments to a local instance of Mulesoft EE Edition v3.8.3 and could not find any solution on the web. I am documenting it here in case anyone else faces the same issue and is looking for a solution. The mule-maven-plugin is unable to copy the application ZIP file to the apps directory. To resolve, follow the steps below. 1.  Use mule mule-app-maven-plugin to build the application - set the flag  copyToAppsDirectory  to false. <plugin>      <groupId>org.mule.tools.maven</groupId>      <artifactId>mule-app-maven-plugin</artifactId>      <version>${mule.tools.version}</version>      <extensions>true</extensions>      <configuration>          <copyToAppsDirectory>false</copyToAppsDirectory>       </configuration>   </plugin> 2. Add a plugin to copy the generated artifact to MULE_HOME/apps folder. This is done using the  mav

When building out green field migrations from existing legacy code to Mule soft, a bottom up approach is recommended for creating new integration applications. An ESB such as Mule ESB is an important enabler in this type of a migration facilitating the creation and orchestration of services without the need for an application server or other infrastructure components. Given that, migrations to this type of architecture is a two-step process – the first step involves creation of endpoints to expose business logic as services wrapped inside Mule flows. The next step is to create service compositions that represent the actual business processes. These steps lay the foundation for a ‘System API’ layer which connects to the various SOR’s hosting the most important asset of an organization – namely the data – enabling access from well-defined API’s. While building out these integrations, developers need to ensure some foundational design principles are followed. Separate implementatio

Mulesoft's Cloud Based message offering Anypoint MQ provides you APIs which enable REST based access to send and receive messages, administer queues and message exchanges, and analyze results. This blog goes over the usage of these API's when running POSTMAN on Windows. Details around usage with CURL are already available on the Mulesoft Website. With the Client ID and Client Secret handy, do a POST to the following endpoint - make sure you are passing the following parameters as x-www-form-urlencoded format to the endpoint https://mq-us-east-1.anypoint.mulesoft.com/api/v1/authorize client_id - this the client ID for your client app client_secret - this the client secret for your client app client_id - this the client ID for your destination grant_type - client_credentials Your Content-Type will be application/x-www-form-urlencoded ( surprise, surprise :) If everything above is correct, you will get back a JSON response similar to the following { "

Well, after three years of working almost exclusively on the Mulesoft Anypoint Platform, solving critical business problems for both on-premise as well as cloud based customers I’ve finally decided to start my own blog. As part of an ongoing client engagement, I got the opportunity to work with Mulesoft’s cloud based messaging solution, AnypointMQ – during the project we implemented point to point messaging for the most part but the publish-subscribe messaging is a powerful paradigm to connect distributed systems so I thought it would be a good idea to explore it as part of this blog. Anypoint MQ is a multi-tenant, cloud based messaging service which allows integrations deployed on Mulesoft’s Cloud Hub environment to talk to each other using either point to point or publish-subscribe messaging. Other alternatives for cloud based messaging include the Azure Service Bus and Amazon SQS messaging service both of which you can integrate seamlessly with your Mulesoft applications. Whil