This is second in series of how to DevOps articles, and is a follow-up to the MUnit blog – HowTo(DevOps) – Leveraging MUnit For Test Automation.
A core component of the continuous integration process, that includes the previously discussed test automation framework, is the build process. As soon as the developer commits the code to version control repository, the build tool compiles the source code runs unit and integration tests and generates feedback for the developers.
Traditional integration platforms could get away with providing some command line tools to automate the build and deployment of applications built on their platform. But in the modern world, integration platforms need to encompass the critical API management & cloud components as well, so the scope of continuous integration and continuous delivery tools are no longer just limited to integration applications only.
As organizations embrace APIs for exchanging information with internal or external customers and partners, it’s critical not to sacrifice visibility or governance. That’s where API management comes in. API management policies can be layered on top of the implementation of the APIs to provide the governance, security and visibility required.
Out-of-the-box the Anypoint platform provides a full number of policies. Policies are grouped into categories of:
Welcome to this series of “HowTos” covering exceptions in MuleSoft Anypoint Platform. We will be covering many topics specifically with exceptions and exception/error handling in Mule integration flows.
The exception handling is demonstrated using a simple use-case. The example Mule project is available in exchange here.
Integration projects are complex, and exceptions are bound to happen. It is important that we have the ability to catch, categorize and handle exceptions so that we do not leave the system/application/data in an inconsistent state.
We recently introduced our HowTo blog series, which is designed to present simple use-case tutorials to help you as you evaluate Mulesoft’s Anypoint Platform. This blog post is a follow up to our last blog “How to ETL” using Mule. In that post, we demonstrated how Anypoint Platform could be leveraged to read a large number of messages, transform/enrich these messages, and then load them into a target system/application.
We recently introduced our HowTo blog series, which is designed to present simple use-case tutorials to help you as you evaluate Anypoint Platform. The goal of this blog post is to give you a short introduction on how to implement a simple ETL (Extract, Transform, and Load) scenario using Mulesoft’s batch processing module.
MuleSoft Anypoint Runtime Manager (ARM) provides connectivity to Mule Runtime engines deployed across your organization to provide centralized management, monitoring and analytics reporting. However, most enterprise customers find it necessary for these on-premises runtimes to integrate with their existing monitoring systems such as Splunk and ELK to support a single pane of glass view across the infrastructure.
With the advent of next generation, easy to use integration toolsets, the following is becoming a very familiar scenario.
The business has a use case to move customer records from a database (DB) to Salesforce (SFDC). A system analyst in the line of business quickly creates an integration with a connector and deploys it.
A few weeks later, the customer support team comes up with another use case to display customer data on the support web portal. So, the analyst creates another integration into the DB and SFDC.
There is hardly any argument on the fact that APIs are increasingly becoming an important part of how companies do business. API has become the de facto standard to unlock one of their most valuable resources, data.
We defined the API
specification using RAML
, implemented the API
by importing the RAML
into Anypoint Studio
and deployed the implementation to mule runtime in cloud or on-premise.
We are now ready to share the API
with the developer community. Before sharing, we need to make sure that the API
is governed. Governing an API
means applying policies like rate limiting, SLA based tiering and securing API
access with industry standard protocols.
One popular way to secure APIs
(Open Authorization). OAuth
2.0 focuses on client developer simplicity while providing specific authorization flows for Web applications, desktop applications, mobile apps and Internet of Things. Here’s more
about how OAuth
Mulesoft’s Anypoint Platform
provides a policy template to implement OAuth
out of the box. In this post, we will go through the step-by-step process of configuring the OAuth
policy to enforce OAuth
on an API