This blog post explains how to use the Mule Facebook Connector version 2.3. A good tutorial on the Facebook Connector has already been posted but deals with a much earlier version. This post presents a demo using the current version.
Versions and Assumptions
To understand this tutorial, you need a good general knowledge of Mule. To install the Facebook Connector 2.3, you need to use MuleStudio 3.5.0 and then set CloudHub Mule Runtime (Dec 2013) as the runtime of your Mule project.
To apply the demo example of this post to your project, you will also need a Facebook account for testing. Additionally, the account needs to have a developer app so that the Facebook Connector can communicate with it.
Before Mule can access or make use of your Facebook account, some authentication procedures need to be followed; Facebook makes use of OAuth2 authentication, and in this case your Mule application needs to request an access token from Facebook to authorize the application and hence gain access to your account.
To obtain this token, your application needs to be configured with the credential information provided by the Facebook app, namely the App ID and the App Secret. The OAuth Redirect URI is also required as a callback endpoint; during authorization, your application is redirected to the service provider to be authenticated and the latter redirects you back to the callback endpoint. The OAuth Redirect URI can be found in the app settings.
The Mule Application
First you need to configure the Facebook Connector with the App ID and the App Secret, as well as the OAuth URL to perform the callback and receive the access token. Such details are typically saved in a separate properties file and accessed through placeholders as shown below:
The defaultAccessTokenId attribute is optional and allows you to give the token ID a custom name. If it is not set, the Connector will by default assign the token ID with the config’s name, in this case “FacebookConfig”.
The scope attribute can also be optionally added to the config, which asks the user permission to access something in particular on the Facebook account. The service provider asks for this permission by displaying a request page and waits for the user’s response before continuing. Different Facebook processors require different scopes, although some processors can function even without providing the scope in the config.
Below is the flow structure which our example uses to post a message on Facebook.
The next step is the authorization process. A simple HTTP inbound is used to trigger the flow and the Facebook authorize message processor is called. The authorize processor redirects the application to the service provider and back to the callback URL when authentication is done. If the user is not already logged in to the account, the service provider displays the Facebook sign-in page before proceeding with authentication. The Connector by default, creates an object store to save the access token.
The next bit of code shows two of the Connector’s processors, the first to get all the user details and the second to post a status message on that user’s account. The publish-message processor (and several other Facebook processors) requires the profile_id attribute to be assigned, which corresponds to the user’s Username on Facebook. You can easily find the username and insert it in the flow, but it is usually preferable to make code as generic as possible. Hence, the logged-user-details processor can be used to fill the payload with all the user details and the publish-message processor can just extract the username from the payload.
While this example includes both the authorization step and Facebook processors within one flow, you can separate them into two different flows. This is sometimes preferable due to redirecting issues. Below is the same example from above but divided into two flows:
This variation still works with the 2.3 version, since the access token will still be saved in the object store. It may also be preferable for some projects, especially if the account has not been logged in before authorization.
There are a few significant changes between 2.3 and previous versions. The code below is meant to perform the same function as the example presented above but this time its configuration is based on versions 2.0 and 2.2:
In the config section, the defaultAccessTokenId attribute is not available and the appId and appSecret are used to store the credentials instead of consumerKey and consumerSecret.
Moreover, the Facebook processors are required to explicitly define the token ID. The latter can be found in a flow variable in the message that the authorize processor returns (this flow variable is also returned in version 2.3, but was not needed in the example shown in the previous section). In these versions, the token ID is assigned the username of the Facebook account by default. The logged-user-details processor could have been removed and the profile_id attribute immediately set with the value in the flow variable. On the other hand, using the logged-user-details processor is preferable if you can’t or don’t want to manually define the account username.
Version 2.3 has greatly simplified the use of the Facebook Connector in Mule. That being said, the choice of Connector version is still dependent on the developer and the application environment.
One thing to keep in mind is that Facebook does not allow spam. Therefore, if the Mule application posts the exact same message twice in a short period of time, an exception will be thrown.
In addition, although it is possible to install two different versions (libraries) of the Facebook Connector in MuleStudio, it is inadvisable since the two libraries may conflict with each other.
I hope you enjoyed this blog post! (First published; 8th April 2014 on blog.ricston.com)