Sun's JavaOne is rolling around again, and SAP is once again a co-sponsor (and not something that comes out of a tree). Howzzat? Mark Finnern blogged about SAP JavaOne: "What does Saaaap do?" at JavaOne last year. This year, with NetWeaver released and Java a big part of its message of openness, can SAP still expect to have to explain itself?
In case you are unsure of the right answer, in this post I'll tell you some examples of how to "tap into" the Java in SAP, told handily through the example of the BI Java SDK.
The Java in the BI Java SDK
The BI Java SDK - Business Intelligence Java Software Development Kit - is a key new component of SAP NetWeaver that is made possible on many different levels by Java, and serves in turn as a good example of Java at SAP. This SDK opens up both SAP and non-SAP data sources, and lets you build Java applications that render results of custom-designed queries on diverse, heterogeneous OLAP systems as well as relational databases. How has Java made this possible?
J2EE Connector Architecture
First and foremost, NetWeaver’s J2EE engine implements an industry-standard connection architecture based on the J2EE Connector Architecture (JCA). JCA tells us how to build and deploy standard connectors. This provides us with uniform environment for connection management and monitoring and a pluggable architecture in which we can connect to different, heterogeneous data sources. NetWeaver is widely adopting JCA across SAP's components, and JCA is the framework for the BI Java Connectors.
The BI Java Connectors are a group of four JCA-compliant resource adapters that essentially implement the APIs of the BI Java SDK and allow you to connect via the applications you build with the SDK to heterogeneous data sources. These connectors are deployed onto SAP NetWeaver's J2EE Web Application Server.
In the Business Intelligence component NetWeaver's Information Integration layer, this means that we can address business requirements for data connectivity in two directions:
- Inbound - feeding data from external, heterogeneous data sources into BW
We connect Java connectors to the back-end to feed external data into BW via UD Connect. (UD Connect is part of the BW 3.5 platform). - Outbound – feeding data from BW into other applications
By using the connector architecture to access BW, we enable the implementation of custom applications on top of BW (via the BI Java SDK).
JDBC
We dive deeper into the topic of connectivity in Java with JDBC. The Java platform gains significant momentum because of its ability to simplify and accelerate the development of business applications. It does so by providing services such as transaction and resource management, persistence, mobility, versioning, scalability, and security. The importance of this is that it facilitates the development of a wide variety of applications that require back-end connectivity — of which JDBC is just one example. If you take a look at the Sun Web site, and specifically at their section about JDBC drivers, you can access the whole list of current drivers and see that there are currently over 200 different JDBC drivers listed, representing major database systems such as InformX and SQL Server as well as many drivers for smaller vendors.
Keeping this in mind, one of the BI Java Connectors we provide is the BI JDBC Connector. Given the number of publicly available JDBC drivers, this gives you a lot of flexibility to integrate with many different types of flat, relational data sources – any data source that provides a JDBC driver. Since you'd be hard-pressed nowadays to find a database that doesn't have a JDBC driver, we could say that this covers virtually all types of relational data management systems. But this connector also provides access to more proprietary data formats, such as Excel and dBase files.
java.sql.ResultSet
Sun’s established java.sql.ResultSet interface is part of the JDBC API, and we heavily leverage this interface in the BI Java SDK.
Ultimately, the goal of the SDK is to be able to represent result sets for any of the diverse queries that can be defined using the SDK’s query APIs. These result sets can have any geometry (for example, crosstabs with nested dimensions) and can contain any data type in relational or OLAP result sets. It’s the job of the SDK’s ResultSet API to provide applications with a complete set of interfaces to access these result sets, delivering a relational result set from a relational data source, and an OLAP result set from an OLAP data source.
The SDK ResultSet API is based almost entirely on java.sql.ResultSet. Only a few lightweight interfaces have been added to facilitate a multidimensional representation.
Java Metadata Interface
Also made possible by Java and leveraged in the BI Java SDK is the Java Metadata Interface (JMI). JMI is an extensible metadata service for the Java platform, used for introspection, discovery, and dynamic access to metadata sources, thus creating a Java programming model for accessing metadata. It supports the design and use of generic tools for working with metadata -- for example, the interaction with a metadata repository such as SAP’s Metamodel Repository.
This specification enables among other things the platform-neutral creation and exchange of metadata, important of course when dealing with heterogeneous data sources. A large amount of the APIs provided by the BI Java SDK, including its metadata APIs, are generated by a template-based translation or rendering of Common Warehouse Metadata (CWM) models into Java interfaces. In order to generate Java interfaces out of these models, the SDK uses JMI mapping.
A JMI service is any system that provides a JMI-compliant API to access its public metadata. The BI Java Connectors expose metadata of the underlying EIS via JMI services. Any type of metadata, including objects that form the basis of OLAP and relational queries, can be represented via JMI-compliant interfaces and implementations that are generated by the JMI mapping service of the Metamodel Repository. JMI thus provides the benefits of interoperability and compliance with the industry standards, as well as allowing for future extensibility.
In a nutshell, through JMI, metadata models are translated into Java APIs (in a process that looks something like the diagram above) provided with the BI Java SDK to allow visualization components to access and navigate instances of the metamodels.
Portability
Lest we forget, the obvious advantage of sitting in a Java environment is the portability of Java-based components. We just write applications once – be they BI Java Connectors delivered by SAP, or applications created by customers using the BI Java SDK – deploy them onto NetWeaver's J2EE server, and they run on any platform, any client on which Java runs.
Javadocs
Lastly, where documentation is concerned, we've fully exploited the benefits of Java's built-in API documentation compiler, Javadoc. Not one, but two sets of Javadocs are included in the BI Java SDK distribution set - one for the SDK and one for the CWM models on which we rely – and no bells and whistles have been spared here. Our exposed interfaces are fully documented, as are all packages, including interconnected diagrams in many cases. These programmer's references are built with a rich user experience in mind, with hyperlinks within the diagrams helping you directly navigate into the Javadoc API reference, and cross-references between all the different components of the included documentation set. This set is delivered completely inside the BI Java SDK archive, which when you unzip the archive is accessed via the file index.html.
You can also check out the Javadocs online here on the SDN:
Still jonesing for pancakes?
Surely I've left out key foundations of Java that SAP leverages. Still, if all of this is just -- ugh -- maple syrup to you, plan to stop by and see us when you're at JavaOne in San Francisco this year, June 28-July 1.
