Portal Applications

Data Driver Overview

A Data Driver is the piece of code that helps the Portal and your legacy system to talk together. It has been designed to be very simple. In order to implement the basic functionalities of a data driver, you have to know about three interfaces and three objects. Then you will be able to query, navigate, access, view and report on your data.

[Top]

Low Implementation Cost

The cost of a driver implementation is low for two reasons:

1. It is based on simple technologies
2. The driver scalability: a first driver can be coded very quickly then extended according to the needs.

[Top]

Scalability

Some of our customers want to have basic functionalities on their data, but they want a quick development within one month on a lot of systems. Others accept to spend more time because they want advanced functionalities. In order to address the first, a driver is made of a core composed of 3 interfaces, which are about:

• Enabling the security
• Describing the data
• Querying and Navigating the data

Afterwards, you can implement other optional interfaces in order to add functionalities such as Bookmaking and Editing.

Hence you can quickly get the functionalities you need most. After considering the success of your implementation and your new needs, you can extend the basic features. You only have to invest for what you need, the "entry barrier" is not high.

[Top]

Technologies

Another factor that makes the learning curve high for an integration project is the technology, all the technologies that you have to learn.
For us, the only requirement is Java. This language is clearly simple compared to C++. It is portable and comes with a lot of built-in libraries. The best known for database access is JDBC.
For the middleware, you can choose what you want from among CORBA, HTTP, JDBC, etc.

We have built the Data Driver from a scalable perspective. If you want just a few things, your investment will be small. If you want more, you will invest more. And compared to other propositions, the cost is in every case low because

• we do not multiply hot technologies
• we let you implement the minimum necessary.

[Top]

Implementation of the Core of a Driver

Building a driver consists in implementing several mandatory interfaces which compose the core of the driver.

[Top]

Driver Interface

It is the main interface which must give access give access to the implementations of the other ones and manages the three following aspects.

[Top]

Life Cycle

A driver is instantiated through the traditional java forName.When it is launched, the driver is called on the start method with an argument: an InformationObject which provides all the information it needs during its life: the username, the cache where it can store files, etc.
At the end of the session, it is called on the stop method.

[Top]

Identity

Just after the start method, the driver is asked to give its User identity and then its System identity. The System identity will be used when some persistent information about a data must be stored. So be careful, don't change it after you have released the driver into production.

[Top]

Licensing

Then the Portal checks the licensing. It is up to you to tell us if the licensing for this driver is OK. The Portal does not own the licensing because, in fact, you can prerequisite another licensing system (for example, the PDM System when you run some of its libraries) and we will not be aware of this. For this, you are called on isLicensingOK.

[Top]

The SecurityIF Interface

After, we ask your driver for its SecurityIF interface. With this interface, we will understand if you have authorized the access of the user attempting to access the data.

There are three calls on this interface.

1. isUserChecked is called first. Here you have all the basic information through the informationObject. So it can be sufficient for you to determine the access right and you will be called on getDisplayableInformation
2. In the other case, we will call you on showDialog. This method returns nothing. In fact, you can implement whatever you want in this method. Remember you have a Frame Object, you can launch the panel. The only thing we ask you is that when you will return on this method, that you will tell us isUserChecked.
3. If it is true, we will continue. In the other case we will stop the processing of your driver. In the two cases, we will call you on getDisplayableInformation. You will return a String Object, that we will display. Just remember that each time you are called, we pass you a Contb

If you do not care about security because you rely on Enovia Portal security (if the user can access Portal, then he can access my data), then you can use a defaultSecurityIfImpl.

At this point, we have launched your driver, we have checked the licensing and the authentication. Now for the functionalities.

[Top]

The EnvironmentIF Interface

The environmentIF interface lets you organize your data.

With each data you are returning, you need to associate a Uuid.
A Uuid is a unique identifier. It is composed of an environment and an identifier. The environment acts like a container for your data: i.e. a container for manufacturing, one container for the design. And in each environment, a type of object can have different attributes.

If you do not need this feature, if your PDM system doesn't support it, you can use defaultEnvironmentIFImpl. Then your uuid will have to return the value "default".

In the other case, this interface has three calls:

1. getEnvironmentList is called first. You return all the environments available and that will be displayed for the query of an object. If you return a null array, you will be called on the following method
2. showDialog enables you to launch a panel and to let the user choose an environment
3. You will be called on getDisplayableInformation. You will return a String Object that we will display. Just remember that each time you are called, we pass you a Context object on which you can obtain a basicDriverServicesIF with a setText method. It is another way to proceed.

[Top]

The MetadataIF Interface

It contains one method getTypes, which returns all the types that the driver is able to access.

[Top]

The DataIF Interface

This interface has two purposes: one for querying data, one for navigating on basic parent-child relationship.

The first method enables the query of data. It is called QueryRoot.

It takes as Input the types requested, a query criteria and an environment.

At this time, two types of query criteria are defined:

• A java.lang.String which is passed with Search String queries
• An array of ElementOfQuery objects, an ElementOfQuery contains three Objects:
  • A PEAttribute, which is the attribute
  • A String, which is the Operator
  • A String, which is the Operand

The second method is aimed at Navigation.

It contains only one method openNode, which means return all the children of this object. It models the basic parent-child relation. As entry, openNode takes a PELeaf.

[Top]

Extended Services

PersistantDataIF

The goal of this interface is to enable the book marking of the object, i.e. to be able to store in a persistent way an identifier of an object, a uuid.Later, we are able to request this object by giving this uuid. The method that enables this is restoreFromUuid.

The other method isRestorableByUuid asks the driver if the portal can store the uuid. If false is returned, it means that we are not able to store persistently an identifier of the object. So the portal will not enable book marking on this object.

ExtractToPortalServerIF

[Top]

Deployment

In Short

The Data Driver enables you to access your data. In order to implement one, you have to implement 4 interfaces which manages the life cycle, the security, the metadata definition and the data access.

[Top]

References

History

Copyright © 2000, Dassault Systèmes. All rights reserved.