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:
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:
This is great and a huge improvement over Mule 3.4.x. However, imagine a really 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 a 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:
This is how it works:
- Each time an OAuth2 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! Here 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!