Integrating SAP and Salesforce.com? Join Intrigo Systems, a leading SAP and Salesforce.com partner, and MuleSoft, the most widely used integration platform, to learn how this can be done painlessly with easy developer tooling on Mule ESB that doesn’t sacrifice performance and power.

Topics include:

  • Overview of the SAP to Salesforce integration problem
  • Discussion of integration options and best practices
  • Use Case Demo #1: Customer Master
  • Use Case Demo #2: Entitlement & Return Process

Date: Tuesday, November 20, 2012

Time: 10 AM PST / 1 PM PST

Watch webinar now »

To fight XSS attacks, the web browser imposes the same origin policy for HTTP requests made by JavaScript code:

But there are a lot of use cases where this kind of cross domain HTTP request is desired, so developers came up with some workarounds:

  • Server side proxy: the idea is to avoid cross domain requests in the browser by doing them on the server:To do that in Mule you can use the HTTP proxy pattern as explained in this post.
reza.shafii on Tuesday, November 6, 2012

Introducing Mule Enterprise Security

3

Service-Oriented Architectures (SOA) present unique security challenges due to loose service/application coupling and operations  running across trust boundaries.  To help our customers address these challenges, we have extended the Mule ESB platform security in several key areas and are making these extensions available through our Mule Enterprise Security package. This blog post will introduce the key components of that soon to be released package.

Product Overview

The first thing to know about Mule Enterprise Security is that it builds on top of Mule ESB Enterprise’s existing security capabilities. Mule ESB Enterprise already provides a solid set of security features, including:

A frequent issue I come across writing integration applications with Mule is deciding how to communicate back and forth between my front end application, typically a web or mobile application, and a flow hosted on Mule.

I could use web services and do something like annotate a component with JAX-RS and expose this out over HTTP.  This is potentially overkill,  particularly if I only want to host a few methods, the methods are asynchronous or I don’t want to deal with the overhead of HTTP.  It also could be a lot of extra effort if the only consumers of the API, at least initially, are internal facing applications.

This Monday, we are very excited to be participating in Cloud Channel Summit, hosted by THINKstrategies. As more Enterprises are moving to the cloud, SaaS ISV’s have an opportunity to grow their customer base from the early SaaS adopters in small businesses through to the largest of Enterprises. At MuleSoft we understand Enterprise IT projects and what it takes to make systems and applications work together. We also understand the tremendous value channel partnerships can bring to SaaS companies as they look strategically across their portfolio, and make critical decisions across engineering, services and sales resources for 2013 to outpace their competition.

Today I would like to talk a little bit about releasing a new version of your Mule extensions.  As you may know Mule is a an extensible platform with well defined integration points for plugging in your own connectors transformations, components and even routers. Suppose you have used The Mule Devkit to create your very own extension or cloud connector, and your project is so cool that it was accepted on MuleForge.

What happens if you make changes to you project and it moves from version 1.0 to 1.1? We’ll take a very quick look at how to do that in this post.

First, modify your pom.xml to increase your version number. In this case, we’ll go from 1.0 to 1.1:

<groupId>org.mule.modules</groupId>
<artifactId>cool-connector</artifactId>
<version>1.1</version>
<packaging>mule-module</packaging>

    

Mark Zuckenberg once said: “How can you connect the world if you leave out China”. Well, I now hereby say: “How can you connect the cloud if you leave out Google”. I know I don’t have his net worth, but I have a point nevertheless. Reality is that Google has done a great job building a Gazillion of different and very cool APIs and you’d be right to feel that it’s hard to keep their pace. To help you with that is that we proudly present to you the first release of the Google Cloud Connectors Suite.

I’m very excited to announce that the October release of Dataloader.io is now available! It includes many  new features,  UI enhancements and bug fixes, which we hope it’ll make you love your data loader even more.

Mule’s extension capabilities multiply its power as an integration platform and range from simple expressions to custom cloud connectors: wherever a configuration value is expected, expressions can be applied in various languages, including our new Mule Expression Language, so that the same value is calculated at run-time; our Scripting processors allow you to execute custom logic in Groovy, Python, Ruby, JavaScript, PHP and indeed any language which implements the JSR-223 scripting spec for the JVM; and of course Java components can be invoked too. Our extensible platform goes even further with the addition of custom Cloud Connectors with already over a hundred to choose from. These greatly simplify any interaction with a public API whether it be exposed on the cloud or on-premise. They come with connection-pooling and automated reconnection strategies.

Picking up where Dirk Olmes left off in the post, Migrating a MuleForge project to Github, we now suggest a utility to facilitate the migration: svn2git.

svn2git is a tiny utility for migrating projects from Subversion to Git while keeping the trunk, branches and tags where they should be.

This involves three basic steps:

  1. Getting the svn repository
  2. Creating a Git repository
  3. Pushing the trunk, tags and branches (previously added)

Step 1 is where svn2git is very appropriate.  To use it, you just need to execute the command “svn2git” followed by the url of the svn repository and the utility does the rest. Great, isn’t it?