Over a million developers have joined DZone.

Mule OAuth2 Support: Even Easier Still

Build APIs from SQL and NoSQL or Salesforce data sources in seconds. Read the Creating REST APIs white paper, brought to you in partnership with CA Technologies.

This post is brought to you by… you! Yes, a couple of weeks back I was writing about how dealing with OAuth2 secured APIs got way easier since Mule’s August 2013 Release. We got such a great feedback that we decided to incorporate some of it in our latest October 2013 release.

Token Management vs. Token Nightmare

So let’s do a quick recap. In the last post we said that now Mule is way smarter at automatically handling your tokens. So, in a single tenant scenario you could just do this:

<sfdc:authorize config-ref="mySalesForceConnector"/>
<sfdc:query="...." config-ref="mySalesForceConnector"/>

In this case, Mule will automatically handle your tokens by using the connector’s config name (in this case “mySalesForceConnector“) as the token id.

This is not enough for the multitenant case, since different tenants need to have different token ids (otherwise user1 could end up entering user2′s account and everything would be a big mess). So, we added the possibility to force a token id while doing authorization. The same example would look like this:

<sfdc:authorize accessTokenId="#[message.inboundProperties['tenantId']]" />
<sfdc:query="...." accessTokenId="#[message.inboundProperties['tenantId']]" />

This is great and a huge improvement over Mule 3.4.x. However, imagine a reeaallly large app in which you make extensive use of the Salesforce connector and your token id could always be obtained by the same expression (in our case #[message.inboundProperties['tenantId']]). In such an scenario, it would be quite annoying having to repeat the same expression in every single message processor. Not to mention that if for any reason that expression changes, you would have a lot of places to modify.

Repetition: Worst thing can happen to an artist

So yes, the problem here is repetition. Nothing like a good old default value to fix this. So basically, the big little change in BigHorn is this:

<sfdc:config name="mySalesforceConnector" consumerKey="${consumerKey}" consumerSecret="${consumerSecret}">
	<sfdc:oauth-callback-config domain="localhost"
		localPort="8081" path="callback" remotePort="8081"

<flow name="myFlow">
	<sfdc:authorize />
	<sfdc:query="...." />

This is how it works:

  • Each time an protected operation is found (and this includes the authorize) we check if the message processor has its own accessTokenId expression. If it does, we evaluate it and use it.
  • If the message processor didn’t provide its own token id, then we look for the default. If there is a default, then we evaluate the expression and use it.
  • If no defaultExpression was found either, then we just use the connector’s config name.

Neat isn’t it? But that’s too much XML. Can I do this in Studio? Sure! He’re is how:

So, nothing more to say than thank you! This is a feature straight from your feedback. If you have more, please bring it on!

The Integration Zone is brought to you in partnership with CA Technologies.  Use CA Live API Creator to quickly create complete application backends, with secure APIs and robust application logic, in an easy to use interface.


Published at DZone with permission of Mariano Gonzalez, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}