Innovator 16.1 Java API
Requirements
- Java Development Kit 21 or higher (available at http://www.oracle.com/)
- Innovator Java API binaries inojapi.jar
Overall Structure
Most parts of this API are generated according to model-driven architecture principals. This means that the structure of the interfaces primarily relies on the Innovator repository server's meta model. The API enables a Java application to work with Innovator components that can be reached via the TCP/IP network. This means that it supports, for example, a client interface to a running Innovator server or provides the ability to communicate to local Innovator client programs.
Some classes are coded by hand to ease the integration into the java runtime environment. Please refer to the package description to get information about using those classes. The API is designed for and implemented using Java 21, which provides the user with a lot of new features and advantages. Generics, in particular, enable type-safe calling of the interface methods and should reduce the need to use unsafe type casting.
The binaries of the API can be found under your Innovator installation path in the $INODIR/java/lib/ext directory. They are automatically added to your class path if you use the Innovator virtual machine launcher (inojava). Otherwise, you have to add this jar archive manually to your class path.
Interfaces and Implementer
There are several interfaces in the API structured in a package structure listed above. The structure and names of these interfaces represent an Innovator meta model entity. We have developed our model in such a way that it is easily understood by anyone familiar with UML. The Innovator meta model was designed similarly to the UML 2 specification using Innovator. An interface normally has an implementation that has to be chosen at creation time. The implementation classes are hidden to the user within the Innovator Java API because the real work is done by the server. That means every call to an interface method will result in a TCP/IP communication where the request is answered, for example, by the repository server; the result then automatically creates the implementer for the resulting interfaces. The implementers can be seen as proxy elements to the server side instances, that encapsulate the communication layer but do not contain any further useful information. This means that you should never need to program with implementation classes and, consequently, there is no description about those implementers in this documentation; in fact, they are not even mentioned, except in this paragraph.
The structure of interfaces and implementers, however, raises some problems and traps that you should be aware of:
-
The Java instanceof operator should be handled with care. For example,
if an API method returns a CLClassifier and you want to know which type of
classifier you have, calling the
result instanceof CLClasswill always return false, because CLClass is an interface and the implementer of CLClass that is instantiated by the method call does not extend CLClass but implements CLClass. Consequently, you should always use the Java reflection method isAssignableFrom to check if a CLClassifier implementer also implements CLClass. - An interface describes a list of instance methods, which means that any static method cannot be called using the interface. According to CORBA calls in Java, they can be called through helper classes. There are several helper classes in the Innovator Java API which contain all static methods to a corresponding interface. For example, the static methods to CLClass can be found in CLClassHelper.
- The creation of new instances cannot be performed by calling new but must be done with help of a static method named create, which also can be found in the corresponding helper class.
Quickstart
The easiest way to write a Java program that can be run from an Innovator client is to use the
following code template. The example uses the base class InnovatorApplicationDefault
for implementing the interface InnovatorApplication. In general, every Java
application (class with a 'main' static method) can be configured to be executed from the Innovator
clients. However, if you want to use a transparent way, either run a standalone application or you can extend
the default application inside the Innovator context, if you prefer. This enables your program
to react on standard global property values or use an existing Innovator environment to contact
a repository.
The 'run' method is your starting point to navigate through an Innovator model. It can be accessed using, for example, the protected default application member variable 'model'. If you did start your application within Innovator client context, the java program will use the same login and model which is currently open in your Innovator model browser.
import java.util.ArrayList;
import java.util.List;
import de.mid.innovator.client.InoClientContext;
import de.mid.innovator.srv2api.icw2elem.ELElement;
import de.mid.innovator.ui.InnovatorApplication;
import de.mid.innovator.ui.InnovatorApplicationDefault;
import de.mid.innovator.ui.PropertyCfg;
import de.mid.innovator.util.InoNlsException;
public class Main extends InnovatorApplicationDefault implements InnovatorApplication {
private static PropertyCfg[] argumentsCfg = new PropertyCfg[0];
public static void main(String[] args) throws Exception {
InnovatorApplicationDefault.create(Main.class, argumentsCfg, args);
}
public void run() throws InoNlsException {
List<ELElement> sel = new ArrayList<ELElement>();
if (InoClientContext.hasContext())
sel = InoClientContext.getInstance().getSelection();
// TODO: code your program here
// use instance variable 'model' or InoClientContext to start server queries
}
public String Usage() {
return "My own usage";
}
}
In addition it deals with the concepts of Online Analytical Processing (OLAP) to build a data warehouse for business intelligence (BI) matters.