Database Reference
In-Depth Information
Essbase has featured an API since it was introduced in the early 1990s. In the begin-
ning, the API was available for both the C and the visual Basic programming languages.
These APIs, particularly the visual Basic API, were extremely popular and were used
by many companies to tailor how their users worked with Essbase. But, due to the ever-
changing nature of technology, another API was soon introduced that would eventually
become the lead API for Essbase development: the Essbase Java API.
The Java programming language was introduced in 1995 as a general purpose, mul-
tithreaded, object-oriented language. Java is well suited to the new generation of Web-
based applications that were gaining popularity at the time. The Essbase Java API was
introduced to a select set of Essbase partners in the summer of 1998 and was first delivered
as part of the Essbase Enterprise product in Essbase 6.5. It was designed as a server-based
API and ran inside a Java application server as its container. The initial version supported
a subset of Essbase functionality suited for writing custom user interfaces.
over the next several years, the Essbase Java API underwent very little change,
although the container name changed twice. In Essbase version 7x, the container for
the Java Essbase API was named Essbase Deployment Services (EDS). In Essbase 9.0
through 9.2, the container was named Essbase high Availability Services (AhAS).
Change finally came to the Essbase Java API in version 9.3 when the container name
changed once again to Analytic Provider Services (APS) to reflect the merging of the
Java API and the Smart view provider containers. Additionally, the necessity of a con-
tainer disappeared in version 9.3 with the introduction of
embedded mode
connections
that enable Java applications to connect directly to the Essbase database.
Shortly after the introduction of Essbase 9.3, oracle acquired hyperion Solutions,
which was a very important development for the future of the Essbase Java API. The
oracle Fusion strategy focuses on acquiring best-of-breed technologies and weaving
them together into a new set of integrated applications designed to work together and
written on a common Java platform. Essbase is one of the key technologies central to
oracle Fusion, and as Fusion depends on the Java platform, the Essbase Java API also
has become a key Fusion technology. In addition to embedded mode connections, the
functionality of the Java API has been expanded as well to include nearly all functional-
ity available in the original Essbase API for C. This trend appears to be accelerating as
oracle integrates Essbase deeper into its stack, and, at some point in the near future, it
may be the lead API where new Essbase innovations first appear.
In addition to writing custom applications, an API is useful for developers who want a
deeper understanding of how Essbase works. This is because applications are comprised
of low-level operations that must be executed to accomplish a task. The process of writ-
ing code at this level has the natural side effect of exposing the developer to the order,
or sequence, in which subtasks must be completed. many of the features exposed to
developers are completely hidden to the casual user, and, thus, developers gain insights
not available to normal users.
Java is an object-oriented language, so unlike the Essbase C and visual Basic APIs,
the Essbase Java API is object-oriented. In the next section, we will explore the object
model of the Essbase Java API and introduce the concept of task sequences.
8.2 essBase java api oBjeCt moDel
The most important part of writing code in any object-oriented language is to
understand the object model. An object model defines the components that can be
