OpenAccess SDK Use Cases

OpenAccess is for empowering end users, application integration, data integration, application modernization, legacy data access, securing enterprise data access, and much more.

Empowering End Users
Application Integration
Data Integration
Application Modernization
Securing Enterprise Data Access
Accessing Required Data from Logs or Archives

Empowering End Users to Use Best of the Breed Reporting and Analysis Tools

As an ISV delivering applications into an enterprise or an IT department deploying an in-house application there is pressure by users to use their favorite tools to access the data. For example, many organizations use Brio or Cognos for reporting and Excel for analysis. These users are quite sophisticated at using these tools to create the reports they need. But all this works only if these tools can easily consume the underlying data source. Today that means the need to support ODBC or JDBC interface with SQL capabilities.

OpenAccess SDK lets an ISV or enterprises quickly make the data in its purpose built application appear like a SQL database accessible through ODBC or JDBC such that the tools work with it as if they were working with a SQL Server, Oracle, or DB2. The standards compliance, cross platform support, scalability, and robustness of OpenAccess allows it to be embedded in enterprise quality solutions. Data can be accessed at the file level, through a C/C++ API, COM objects, Java Object, or .NET objects.

Application Integration

Integrate your existing applications into the real-time enterprise - delivering business-on-demand for your trading partners. OpenAccess allows your application to be made accessible using standards many integration platforms support - ODBC and JDBC. By making your data source appear like a relational data source you leverage the rich support for relational database access in today's integration platforms from leading vendors like IBM, Oracle, BEA, webMethods, Microsoft, and others.

Relational view of a data source allows the application integration to work with your data records as if they were from a SQL database. This means well-known data types and language for selecting the required data. The architecture of OpenAccess allows efficient access to the data source by allowing the adapter developed for the data source to tightly work with the OpenAccess SQL engine to efficiently execute the data requests.

Data Integration

Making business and engineering decisions requires access to data from multiple sources. Many tools exist to mine, analyze, and present data. These tools almost always support accessing relational data stores through ODBC/OLE DB or JDBC. One widely used tool is Microsoft Access. It allows access to data stored in the Access MDB files and to external data sources accessible through ODBC. It then allows the user to report and query data as if it all exists in the Microsoft Access data store. All without having to move the actual data into Access or some other common data store.

Other approaches used by enterprises are to present an integrated view of data through middleware or a RDBMS such as SQL Server, Oracle, or DB2. SQL Server offers a distributed query processing feature that allows external OLE DB compliant data sources to be included in queries. This allows for data in SQL Server to be joined with data residing in one or more external data sources. Oracle and DB2 offer similar functionality.

Middleware from companies like IBM, Metamatrix and XAware allows creating a virtual layer on top of existing data stores. These products contain application specific adapters to access data from popular ERP and CRM applications and ODBC/JDBC adapters to access data from relational data stores.

All of the above scenarios require data sources to offer ODBC/JDBC and SQL capability. OpenAccess SDK empowers both ISV and the enterprise to quickly make their data sources accessible using SQL through ODBC, OLE DB, JDBC, or ADO.NET.

Application Modernization

An existing screen or terminal based application can be modernized incrementally by adding a Web and/or Desktop GUI interface on top of existing platform. This allows the existing modules to continue working while allowing the use of the latest technologies and trends to offer a new look to certain classes of users. The most flexible way to achieve this is to make the data source look like a relational database accessible using ODBC or JDBC and SQL. This allows freedom in choosing development, reporting, and analysis tools.

OpenAccess SDK allows a data source to expose a SQL interface with ODBC/JDBC drivers. The architecture of OpenAccess provides efficient access to the data source by allowing the adapter developed for the data source to tightly work with the OpenAccess SQL engine to efficiently execute the data requests.

One state government agency has been using terminal based applications that access data on Concurrent Computers for many years. The agency wanted to allow the public to be able to submit certain requests over the Web but this required access to the data residing on the Concurrent system from the Web Server system. But because Concurrent System uses OpenAccess to allow the data on the Concurrent hardware to be accessed from Windows and Unix boxes using JDBC or ODBC, the customer was able to use IBM WebSphere and the JDBC connectivity provided by OpenAccess to implement a Web solution that works in conjunction with the existing native applications. The new Web based application was first developed on Windows using Java and then deployed on Solaris - both technologies that represent 20+ years of innovation over the existing legacy application platform and development environment.

Securing Access to the Enterprise Data

There is an overwhelming demand for access to all of enterprises information by the users in the organization but at the same time there are serious issues with security. Data access must be controlled so that only the authorized persons can access that data but at the same time not limit what tools the users can use to get to this information. This requires that you provide an open interface to the data source and implement logic to control access.

OpenAccess allows the implementation of a custom ODBC/JDBC on top of the business logic implemented in C/C++, Java, or .NET. It then exposes the data sources through the familiar ODBC/JDBC API to allow existing desktop tools and middleware to consume the data through the business logic layer. The ability to control security through a business layer has advantages over the use of underlying RDBMS. The common rules can be used over multiple data sources instead of having to configure each underlying database.

One CRM vendor used OpenAccess to allow OLE DB compliant access to the underlying data stored in a SQL Server while maintaining security configured within the CRM application. This allowed third-party modules and tools to interact with the CRM using an open API.

Another enterprise used OpenAccess to allow Business Objects to connect to the underlying HR data in an Oracle database through custom Java objects implemented to enforce access control. This allowed the end users to continue using the tools they are familiar with and allowed the IT to implement common access control logic for use with desktop applications and web Java applications.

Accessing Just the Required Data from Logs or Archives

In many applications there is lots of data that is collected and archived. In real-time controls domain this is the sampling of various sensor and actuator measurements that are collected over time and archived for reporting and analysis purposes. The data is typically stored in a compressed proprietary format to allow large amounts of data to be quickly captured and stored. In financial markets domains the performance of various instruments like stock prices and mutual fund prices are stored over time. This could also be data collected during flights that results in many Gigabytes worth of data for each test flight.

The commonality in all these industries is that lots of data is collected and stored in an efficient format and in many cases the users want to access only a sub-set of that data in an ad-hoc manner. One option is to extract and load this data into formats such as relational data store such that analysis tools like Excel or reporting tools like Crystal Reports can access it. But this is not very efficient or practical, as it requires manual transfer of selected data and massaging of that data to allow consumption by each user. A better approach is to provide real-time access to the sub-set of data requested through a custom ODBC/JDBC driver. In this architecture the data is left in its native format and exposed through ODBC or JDBC driver that implements SQL processing over the data store.

OpenAccess SDK allows the data to stay in its native form and be presented as relational tables accessible using SQL. Desktop tools and users then formulate a SQL query to request the sub-set of data they are interested in. This request is processed by OpenAccess using an adapter that is written to plug the data source into the OpenAccess SQL engine. The adapter (we refer to it as the Interface Provider) works closely with the SQL engine to efficiently access just the required data. Many SCADA vendors including ABB Automation, Honeywell, National Instruments, Emerson Process and QEI have used OpenAccess to allow the users of these systems to access archived and real-time data they manage as if it was stored in a SQL database like SQL Server or Oracle.


Copyright © 1993 - 2008. Progress Software Corporation. All rights reserved. | N. America: 800 876 3101 | World: +44 (0) 1753 218 930