Difference between revisions of "GVSocialAdapter-Configuration"
(Created page with "The Social adapter is an adapter which gives {{GVESB}} the ability to interact with social platforms. The configuration is specified into the GVSocialAdapter-Configuration.xml, a...") |
|||
(12 intermediate revisions 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 | + | 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 GVAdapter.xml, and the file has the following structure: | ||
+ | |||
+ | <syntaxhighlight lang="xml"> | ||
<GVSocialAdapterManager name="GV_SOCIAL" type="module"> | <GVSocialAdapterManager name="GV_SOCIAL" type="module"> | ||
<SocialAdapters> | <SocialAdapters> | ||
Line 6: | Line 11: | ||
social="twitter" type="social-adapter"> | social="twitter" type="social-adapter"> | ||
<Accounts> | <Accounts> | ||
− | <Account name=" | + | <Account name="ACCOUNT_NAME" consumer_key="..." consumer_secret="..." twitteruserid="..."/> |
... | ... | ||
</Accounts> | </Accounts> | ||
Line 14: | Line 19: | ||
</SocialAdapters> | </SocialAdapters> | ||
</GVSocialAdapterManager> | </GVSocialAdapterManager> | ||
+ | </syntaxhighlight> | ||
+ | The XML above shows the configuration for [http://twitter.com Twitter] platform. | ||
The following table explains the configuration: | The following table explains the configuration: | ||
{|class="gvtable" | {|class="gvtable" | ||
Line 36: | Line 43: | ||
|- | |- | ||
| Account consumer_secret || OAuth parameter | | Account consumer_secret || OAuth parameter | ||
− | |||
− | |||
− | |||
− | |||
|- | |- | ||
| Account twitteruserid || user id on the social platform | | Account twitteruserid || user id on the social platform | ||
Line 54: | Line 57: | ||
|- | |- | ||
|} | |} | ||
+ | |||
+ | 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: | ||
+ | <syntaxhighlight lang="xml"> | ||
+ | <SocialService> | ||
+ | <updateStatus account="ACCOUNT_NAME"> | ||
+ | <attribute type="java.lang.String">Message to publish</attribute> | ||
+ | </updateStatus> | ||
+ | </SocialService> | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | 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: | ||
+ | |||
+ | <syntaxhighlight lang="xml"> | ||
+ | <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> | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | |||
+ | *Response: | ||
+ | <syntaxhighlight lang="xml"> | ||
+ | <SocialServiceResponse> | ||
+ | <updateStatus account="ACCOUNT_NAME"> | ||
+ | <result type="java.lang.String">OK</attribute> | ||
+ | <error></error> | ||
+ | </updateStatus> | ||
+ | <flagGlobalErrors/> | ||
+ | </SocialServiceResponse> | ||
+ | </syntaxhighlight> | ||
+ | |||
+ | 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. |
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.