Exposing Cassandra as a Data Service

This tutorial will guide you on how to expose data stored in Cassandra as a data service.

Install and start Cassandra

A Cassandra server of version 1.2.x, 2.0 or 3.0 should be already running in the default port. Cassandra version 3.0 is recommended from DSS 3.5.1 onwards.

Adding a Cassandra datasource

Now, let's start creating the data service from scratch:

1. Log in to the management console using the following URL on your browser:  "https://localhost:9443/carbon/".

2. Click Create under the Data Service menu to open the Create Data Service wizard.

3. In the Create Data Service screen, enter Cassandra as the data service name.

4. Click Next to go to the Add New Data Source screen. 

5. Select Cassandra as the data source type. The Cassandra-specific options will be available for editing. 
   

   See the following links for setting up Cassandra as a data store:

   • Get familiar with the basics of Cassandra, including the prerequisites for using Cassandra, by going through the following: https://wiki.apache.org/cassandra/GettingStarted.
   • Get familiar with using the Cassandra CLI, by going through the following: http://wiki.apache.org/cassandra/CassandraCli.
   • Functionalityoftheunderlyingconnector used for the Cassandra datasource: https://www.datastax.com/documentation/developer/java-driver/2.0/index.html.
   • Also, note that Cassandra requires the most stable version of Java 7 or 8 you can deploy; preferably the Oracle/Sun JVM. 
    Properties for a Cassandra datasource

   The following describes the properties supported by the Cassandra datasource. 

   Data Source Property	Description
   Cassandra Servers*	Host names of Cassandra servers in a comma-separated list.
   Keyspace	The default key space used by the Cassandra session.
   Port	The port of Cassandra servers.
   Cluster Name	The Cassandra cluster name.
   Compression	Compression used in communication.
   User Name	The authenticating user's username.
   Password	The authenticating user's password.
   Load Balancing Policy	The client load balancing policy on how calls should be made to the provided servers.
   Enable JMX Reporting	Enable JMX statistics for the connector.
   Enable Metrics	Enable metrics for the connector.
   Local Core Connections Per Host	Connection pooling: Local core connections per server host.
   Remote Core Connections Per Host	Connection pooling: Remote core connections per server host.
   Local Max.Connections Per Host	Connection pooling: Maximum local connections per server host.
   Remote Max.Connections Per Host	Connection pooling: Remote max connections per server host.
   Local New Connection Threshold	This property determines the threshold, which will trigger the creation of a new connection when the connection pool has not reached maximum capacity for local hosts. It is not necessary to change the default value for this parameter.
   Remote New Connection Threshold	This property determines the threshold, which will trigger the creation of a new connection when the connection pool has not reached maximum capacity for remote hosts. It is not necessary to change the default value for this parameter.
   Local Max Requests Per Connection	This property allows you to throttle the number of concurrent requests per connection for local hosts.
   Remote Max Requests Per Connection	This property allows you to throttle the number of concurrent requests per connection for remote hosts.
   Protocol Version	The native protocol version to use. By default, it auto connects. "2" for Cassandra versions 2.0 and upwards, and "1" for Cassandra version 1.2.x.
   Consistency Level	The consistency level used for queries.
   Fetch Size	Fetch size used by queries.
   Serial Consistency Level	The serial consistency level used for queries.
   Reconnection Policy	The reconnection policy used for the cluster.
   Constant Reconnection Policy Delay	If "ConstantReconnectionPolicy" is used for Reconnection Policy, this represents the constant wait time between reconnection attempts in milliseconds.
   Exponential Reconnection Policy Base Delay	If "ExponentialReconnectionPolicy" is used for Reconnection Policy, this represents the base delay in milliseconds.
   Exponential Reconnection Policy Max. Delay	If "ExponentialReconnectionPolicy" is used for Reconnection Policy, this represents the maximum delay in milliseconds.
   Retry Policy	Configured the retry policy in this cluster.
   Connection Timeout	The socket connection timeout in milliseconds.
   Keep Alive	Set if socket keeps alive.
   Read Timeout	Set per host socket read timeout in milliseconds.
   Receive Buffer Size	The socket receive buffer size.
   Send Buffer Size	Thesocketsendbuffersize.
   Reuse Address	The socket re-use address.
   So Linger	The socket linger on value.
   TCP no Delay	Set socket TCP to no delay.
   Enable SSL	Enable SSL.
   Enable OData	From DSS 3.5 onwards, OData protocol version 4 (OASIS standards) is supported, which mainly provides support for CRUD operations. You can easily expose databases as an odata service by selecting this check box. Currently, Odata service feature support is available for RDBMS datasources and Cassandra datasources. If you have enabled Odata for your data service, you can complete the data service creation process. That is, you are not required to define queries or operations for the service. This Odata service will now be accessible from the following endpoints: For super tenant: http://localhost:9763/odata/{dataserviceName}/{datasourceId}/ For normal tenants: http://localhost:9763/odata/t/{tenantId}/{dataserviceName}/{datasourceId}/
   Disable Native Batch Requests	Disables native Cassandrabatchrequests,and reverts to emulated batch requests.

   * Mandatory fields.

Define a query for the datasource

Now let's start writing a query for getting data from the datasource. The query will specify the data that should be fetched by this query, and the format that should be used to display data when the query is invoked.

1. Click Add New Query to open the Add New Query screen.
2. Enter the following values:
   
• Query ID: Enter an ID for the query.
• Datasource: Select the datasource for which you are going to write a query. Select the Cassandra datasource that you created previously.
  

• SQL: In this field, enter the SQL statement describing the data that should be retrieved from the RDBMS datasource.

3. Add input mappings: Input mappings allow you to add parameters to a query so that you can set the parameter value when executing the query. 
   

   Find out more about defining Input Mappings in WSO2 DSS.

4. Add output mappings: Out mapping is used to specify how the data that is fetched from your query will be shown in the response.
   

   Find out more about defining Output Mappings in WSO2 DSS.

5. Click Next to open the Operations screen.

Define operation to invoke the query

Follow the steps given below.

1. Click Add New Operation to open Add New Operation screen.
2. Add a name for your operation in the Operation Name field.
3. In the Query ID field, select the query that you defined previously.
4. Save the operation.