Difference between revisions of "GVSocialAdapter-Configuration"
(One intermediate revision by one other user not shown) | |||
Line 1: | Line 1: | ||
The Social adapter is an adapter which gives {{GVESB}} the ability to interact with social platforms. The platform integrated until now are: | The Social adapter is an adapter which gives {{GVESB}} the ability to interact with social platforms. The platform integrated until now are: | ||
− | * [[ | + | * [[TwitterSocialAdapter]] |
− | The configuration is specified into the | + | The configuration is specified into the GVAdapter.xml, and the file has the following structure: |
<syntaxhighlight lang="xml"> | <syntaxhighlight lang="xml"> |
Latest revision as of 08:12, 14 May 2014
The Social adapter is an adapter which gives GreenVulcano® ESB the ability to interact with social platforms. The platform integrated until now are:
The configuration is specified into the GVAdapter.xml, and the file has the following structure:
<GVSocialAdapterManager name="GV_SOCIAL" type="module">
<SocialAdapters>
<TwitterSocialAdapter class="it.greenvulcano.gvesb.....TwitterSocialAdapter"
social="twitter" type="social-adapter">
<Accounts>
<Account name="ACCOUNT_NAME" consumer_key="..." consumer_secret="..." twitteruserid="..."/>
...
</Accounts>
...
<Proxy proxyHost="" proxyPassword="" proxyPort="" proxyUser=""/>
</TwitterSocialAdapter>
</SocialAdapters>
</GVSocialAdapterManager>
The XML above shows the configuration for Twitter platform. The following table explains the configuration:
Parameter | Meaning and values |
---|---|
TwitterSocialAdapter | One of the implemented adapters |
TwitterSocialAdapter class | the adapter class |
TwitterSocialAdapter social | the social platform identifier |
TwitterSocialAdapter type | the adapter type |
Accounts | wrapper for all the account configured for a single social platform |
Account | single account configuration |
Account name | the name identifying the account |
Account consumer_key | OAuth parameter |
Account consumer_secret | OAuth parameter |
Account twitteruserid | user id on the social platform |
Proxy | proxy settings |
Proxy proxyHost | proxy host |
Proxy proxyPort | proxy port |
Proxy proxyUser | user for the proxy |
Proxy proxyPassword | password for the proxy |
Social platforms use the OAuth to achieve the following goals:
- a user can control which permissions he/she can grant to the installed application
- a user can revoke such permissions at any time
- the user's credentials are not spread, the application has its own tokens
All the consumer tokens are specified into the configuration file for each account; the access tokens are defined by the GV Console and are stored into a properties file.
Adapters Call
The messages exchanged with the adapter have the following format:
- Request:
<SocialService>
<updateStatus account="ACCOUNT_NAME">
<attribute type="java.lang.String">Message to publish</attribute>
</updateStatus>
</SocialService>
SocialService is the root tag. It contains all the operation requested in a single adapter call. If you have to write a custom implementation of the adapter for a new social platform, you can still use this format replacing updateStatus with new-platform-operation-name, and specify all the attributes required in the leaf tags. Thus a generic call will look like:
<SocialService>
<socialFunction account="ACCOUNT_NAME">
<attribute type="java.lang.String">Attribute required by the function</attribute>
<attribute type="java.lang.String">Attribute required by the function</attribute>
...
</socialFunction>
<socialFunction>
...
</socialFunction>
...
</SocialService>
- Response:
<SocialServiceResponse>
<updateStatus account="ACCOUNT_NAME">
<result type="java.lang.String">OK</attribute>
<error></error>
</updateStatus>
<flagGlobalErrors/>
</SocialServiceResponse>
The tag updateStatus in the XML above is referred to an operation available in Twitter, more exactly is the one called to send a tweet. Each operation available for a Social platform has its own XML tag and parameters, and it is presented in VulCon allowing to define data transformation. The response contains all the results of the operation specified in the request xml, each one containing an error tag with information about eventual errors on the single operation. the flagGlobalErrors tag is present only if there has been an error in any one of the calls.