Using OLE Controls to Interface the Data Model to Third-Party PC Products

Abstract

Abstract Object Linking and Embedding (OLE) controls are used to interface the Schlumberger data repository with commercial PC products, such as Excel and Visual Basic. OLE controls for logs, well deviation surveys and casing strings have been created. Using this approach, data integration with third-party products can be achieved while using industry-standard technology. Introduction As existing oilfield software applications expand to the PC platform, integration with existing PC applications becomes a necessity rather than a luxury. Applications such as Microsoft Excel allow users to create their own calculations, and many Field Engineers have their own suite of such calculations. Generally, users must enter the outputs of an engineering applications manually into their Excel workbooks. This manual data entry, however, imposes some practical limits on the degree of data integration. Ideally, all engineering applications should be able to share data seamlessly among themselves and with third-party products. The first goal - sharing data within a suite of engineering applications - can be achieved with reasonable cost. However, sharing data with third-party products is typically more difficult, because defining clean interfaces between products becomes more difficult. In Windows 95 and Windows NT, Object Linking and Embedding (OLE) technology allows applications to share interfaces without directly linking to each other's code. OLE began as a technology for supporting compound documents. However, the technology and its name have since evolved. As a result, the original name only applies to a subset of OLE's capabilities. To make matters more confusing, Microsoft has renamed OLE used in Internet applications as ActiveX. OLE allows applications to share data or self-contained fragments of functionality in a loosely coupled manner, even when these applications are written in different programming languages. Although integrating applications written in different languages is more complicated than integrating applications written in the same language, OLE addresses these issues rather nicely. Most Microsoft applications, such as Excel, allow customization through Visual Basic for Applications, whereas most Windows applications are written in C or C++. As a result, a language-neutral technology is required to provide integration among these various applications. The use of OLE controls, one aspect of OLE, facilitates a solution to this integration problem. Before a strategy for integrating applications can be implemented, some conventions on the data must be established. Applications must use a common data model and must diligently follow any usage rules or other conventions stipulated by the model. If third-party applications or legacy applications do not adhere to this common data model, integration becomes more difficult. By developing a standard set of business objects that provide access to the data that must be shared, applications can deal with subsets of this larger data model, thereby making the integration task less intimidating. These business objects can also encapsulate the data model navigation, usage rules and any other internal details specific to the data repository. As a result, clients of these business objects can deal with a simple interface that hides many of the underlying implementation details. This paper describes how OLE controls are being used within Schlumberger to integrate a Petrotechnical Open Software Consortium (POSC)-compliant data repository with Microsoft Excel and Visual Basic. The data repository is provided with implementations for either Microsoft Access or Oracle as the underlying database. Instead of providing a relational data model, the data repository implements an object-relational model and provides a C interface to access the data. The underlying relational table definitions are not public, and all clients must use the C interface to access data.