This site contains the documentation that is relevant to older WSO2 product versions and offerings.
For the latest WSO2 documentation, visit https://wso2.com/documentation/.

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

Datasource management capability is provided by the following feature in the WSO2 feature repository:

Name : WSO2 Carbon - Datasource Management Feature
Identifier : org.wso2.carbon.datasource.feature.group

If datasource management capability is not included in your product by default, you can add it by installing the above feature using the instructions in Feature Management. Follow the instructions below to add a new datasource to a running ESB instance.

1. In the ESB management console, click the Configure tab, and then click Data Sources.

2. Click Add Data Source.

3. Specify the required options in the "New Data Source" page. Depending on the datasource type, the required fields may vary. Discussed below are the two types available.

RDBMS

If you select the "Data Source Type" as RDBMS, the following screen will appear.

This is the default RDBMS datasource configuration provided by WSO2. Users can also write your own RDBMS configuration by selecting the Custom Data Source option. The following fields should be provided when defining the default RDBMS datasource.

  • Data Source Type : RDBMS
  • Name : Name of the datasource (This value should be unique.)
  • Data Source Provider : Discussed below.
  • Driver : The JDBC driver to be used.
  • URL : The connection URL to be passed to the JDBC driver to establish a connection.
  • User Name : The connection user name to be passed to the JDBC driver to establish a connection.
  • Password : The connection password to be passed to the JDBC driver to establish a connection.
  • Expose as a JNDI Data Source : Discussed below.
  • Data Source Configuration Parameters : Additional properties can be defined when creating an RDBMS datasource. For more information on these properties, see Datasource Parameters.

The meaning of many fields is similar to the DBCPconfiguration guide, to which you can refer to for more information: http://commons.apache.org/dbcp/configuration.html

4. After entering the values, click Save.

You can now edit and delete datasources as needed.

Datasource Provider

There are two types of datasource providers. You can use the default provider or link to an external provider. For the 'default' datasource provider, enter the connection properties Driver, URL, User Name, and Password as follows:

If you need to add a datasource supported by an external provider class such as "com.mysql.jdbc.jdbc2.optional.MysqlXADataSource", select the "external" option and enter the name and value of connection properties by clicking Add Property. Following is an example datasource for an external datasource provider.

JNDI Datasource

Java Naming and Directory Interface (JNDI) is a Java application programming interface (API) that provides naming and directory functionality for Java software clients to discover and look up data and objects via a name. It helps decouple object creation from the object look-up. When you have registered a datasource with JNDI, others can discover it through a JNDI look-up and use it.

To expose a datasource as a JNDI datasource, select "Expose as a JNDI Data Source".


Name : Name of the JNDI datasource that will be visible to others in object look-up.
Use Data Source Factory : If the datasource needs to be accessed from an external environment, Data Source Factory should be used. If this is selected, a Reference object will be created with the defined datasource properties. Then Data Source Factory will create the datasource instance based on the values of the Reference object when accessing the datasource from an external environment. In the configuration, this is set as useDataSourceFactory="true".
JNDI Properties : Properties related to the JNDI datasource (such as password). If Use Data Source Factory is selected, the following properties should be specified:
        java.naming.factory.initial -This property is used to select the registry service provider as the initial context.
        java.naming.provider.url - This property specifies the location of the registry when the registry is being used as the initial context. 

Custom Datasource 

If you select the "Data Source Type" as Custom, the following screen will appear.


  • Data Source Type : Custom 
  • Custom Data Source Type : Described below.
  • Name : Name of the datasource (This value should be unique)
  • Description : Description of the datasource
  • Configuration : XML configuration of the datasource
Custom Datasource Type 

The actual type of the custom datasource can be either "DS_CUSTOM_TABULAR" or "DS_CUSTOM_QUERY". There are two options cover most of the common business use cases.  

Custom Tabular Datasources   

Tabular datasources are used when there is a datasource that represents its data using tables, where a set of named tables contains data rows that can be queried later.  

To implement tabular datasources, the interface "org.wso2.carbon.dataservices.core.custom.datasource.TabularDataBasedDS" is used. A sample implementation of tabular custom datasource can be found at InMemoryDataSource. 

A tabular datasource is typically associated with a SQL data services query. This is done by internally using our own SQL parser to execute SQL against the custom datasource. A sample dataservice descriptor on how this is done can be found at InMemoryDSSample. Also, this is supported in Carbon datasources, with the datasource reader implementation "org.wso2.carbon.dataservices.core.custom.datasource.CustomTabularDataSourceReader". A sample Carbon datasource configuration file can be found at <CARBON_HOME>\repository\conf\datasources\custom-datasources.xml.

Custom Query Datasources   

Custom query-based datasources are created when there is a datasource that has some form of a query expression support.

To implement, the interface "org.wso2.carbon.dataservices.core.custom.datasource.CustomQueryBasedDS" is used. Any non-tabular datasource can be created using the query-based approach. Even if the target datasource does not have a query expression format, users can create their own. For example, any NoSQL type datasource can be supported using this type of a datasource.  

A sample implementation of a query-based custom datasource can be seen at EchoDataSource. A sample data service descriptor with custom query datasources can be found in action in InMemoryDSSample. This is supported in Carbon datasources, with the datasource reader implementation org.wso2.carbon.dataservices.core.custom.datasource.CustomQueryDataSourceReader. A sample of a Carbon datasource configuration file can be found at <CARBON_HOME>\repository\conf\datasources\custom-datasources.xml.  

In the "init" methods of all custom datasources, user-supplied properties will be parsed to initialize the datasource accordingly. Also, a property named "__DATASOURCE_ID__", which contains a UUID to uniquely identify the current datasource, will be passed. This can be used by custom datasource authors to identify the datasources accordingly. For example, scenarios like datasource instances communicating within a server cluster for data synchronization.

Shown below is an example configuration of a custom datasource of type 'DS_CUSTOM_TABULAR'.


4. After entering the values, click Save.

You can now edit and delete datasources as needed.


 

  • No labels