Update: For a code-less solution, look at our Autonomous REST Connector, which is designed to connect to any REST API easily. You can get started by following this tutorial.
Do you have a custom API that you use in your company internally and would like to connect to your favorite analytics tool or integrate with any other tool using standards based connectivity like ODBC?
Do you have a data source which has a REST API and doesn’t have a ODBC driver, but you would like to have one for your analytics or integration purposes?
The OpenAccess SDK allows you to take full advantage of the data processing capabilities and it does that by allowing you to work in two modes of operation
In the Row-based mode, the OpenAccess SDK SQL engine performs all the parsing, planning, joins, union, nested query, and other SQL operations. The IP is responsible for handling row-based operations — read rows for a specific table or update rows into a specific table. Row-based mode is preferred when your REST API has some sort of basic operations of filtering or if it doesn’t have any at all. OpenAccess SDK SQL engine will take care of some or all JOINS by supporting join pushdown and taking care of grouping.
In SQL pass-through mode, the OpenAccess SDK SQL engine handles the parsing and validation of the SQL statement against the exposed schema, and makes the SQL statement available to the IP through the OpenAccess SDK SQL engine API. The IP must perform the operation that is requested by the SQL query using the mechanism that is supported by the data source. SQL pass-through mode is preferred when the backend already supports SQL or SQL-like language that can handle joins, unions, nested queries, and other SQL operations.
In this tutorial, we will be using the OpenAccess Native IP to build the driver that operates in SQL Pass Thru and would be implementing most of the Code for the IP instead of relying on a template generator. This opens customizing the IP code to your need so that you can implement custom Authentication schemes with your API, handle dynamic schema’s, push down filters from your driver to REST API (if your API supports filters) etc.,
I will be demonstrating on how you can build a driver for NYC Parking Violations SODA API. To be more precise, the API endpoint URL I will be using in this tutorial is:
Please note that this API supports SQL query like constructs and I will be using that to push down most of the SQL query and will not be relying on using OpenAccess post processing of data.
a. If you use eclipse, replace the 2nd line in the path with \path\to\Project\bin
b. Note that I am using JSON In Java library for parsing the JSON responses, so I added the path library which is in my Project Lib folder to the service classpath. You must add all your external libraries that you intend to use to this path.
If your API or data source needs Username and password based authentication, you need to change the DataSourceLogonMethod to DBMSLogon(UID, PWD)
dam_describeTable(long hstmt, StringBuffer pCatalog, StringBuffer pSchema, StringBuffer pTableName, StringBuffer pTablePath, StringBuffer pUserData).
You pass empty StringBuffer objects as input arguments and you should have the table name and schema name once the function gets executed.
SELECT VEHICLE_YEAR , COUNT(VEHICLE_YEAR) FROM NYCOPENDATA GROUP BY VEHICLE_YEAR
The IP code should translate this query to NYC Open Data API as
long dam_allocRow(long hstmt)
which returns a handle that you need to use it in the next steps.
int dam_addRowToTable(long stmt_handle, long row_handle)
where row_handle is the handle that you got when you created memory for the row.
-Xrunjdwp:transport=dt_socket,address=9015,server=y,suspend=n -Xdebug -Xrs
SELECT * FROM NYCOPENDATA
SELECT * FROM NYCOPENDATE WHERE VEHICLE_YEAR=2014
SELECT * FROM NYCOPENDATE WHERE VEHICLE_YEAR>2014
We hope this tutorial helped you to build your own custom ODBC driver using Progress DataDirect OpenAccess SDK. If you have any questions/issues, feel free to reach out to us, we will be happy to help you during your evaluation.