Portal Applications

Definition

A driver is a software piece which manages the access to specific data or to a specific application. The Portal provides you with an api which enables you to write a driver in order to insert your own data and applications with Portal.

This API is divided into two pieces:

• The first one is the Data Driver part. It enables you to build a Driver for your Data Sources, for instance, to connect your PDM repository in the Driver. Hence your data will be viewed through the 3D Com WebTree, the 3D com Query Tool. You will be able to communicate for free with the 3D Com viewers, with the Enovia DMU Navigator and with other applications. All these services are available to your data. Your driver manages the access to your data which requires your specific knowledge.
• The second one is the Application Driver part. It enables you to add Actions on types of objects. These types of objects may be your specific data managed by your own data driver or any other types managed by others drivers. For example you can connect your CAD Application to the data managed by the Portal. Let's take a precise example. Suppose that you have an application that reads tiff files and you want to supply a "launch in this application" on each tiff document. You will defined an action representing your application and you associate it with the file type. Each time a user will select a tiff document from a PDM system, the Portal will display the associated action to the user. When the user selects the action, your driver will be called. It will retrieve the document and give it to your application. The Application Driver side enables you to build applications in the Portal that take advantage of the Portal without knowing anything specific about a driver: This is how we have built 3D com WebTree, 3D com Query Tool, the communication with DMU… We are eating our own dog food.

In V5R6 Release of Enovia Portal, only the Data Driver will be covered and opened.

[Top]

Advantages of a Driver

Reuse of previous investments

The Goal of the Portal is to leverage to a maximum your previous investments and to provide easy and seamless migration. For example, imagine you want to move from a PDM A to a PDM B. But the transition will not be done in one day, but perhaps in one year. Your users will need access to the data in the two repositories during this period. So you can build a driver to A and another to B. The users will access the both data sources. When all data will be migrated, you will remove the Driver to A, but the user interface will remain the same, the investments in the education of your users are protected. Hence you will have a smooth 12-month transition from the user point of view.

[Top]

Easy Programming

Last but not least, using the Driver API does not involve complex technologies nor a high learning curve. You needn't prerequisite any complex middleware technologies. You code your driver in the Java Language. You use the tools you want to make the connection to your PDM or Data System. The Core Driver API contains about 10 call methods.

The Driver API is built in order to give you transparency between applications and data sources, to help you to work on the services and the tools that are your strategic value.

Without knowing anything about your product Data repositories, Dassault Systèmes enables you to integrate your legacy data.

As a customer of Dassault Systèmes ENOVIA Portal Solutions, you do not want to re-implement a query tool user interface, a bookmark service, the connection with your DMU Tool, a product structure navigator. Just remember: "The Line of code that costs the least is the line you don't write " (Steve P. Jobs). It is not your added-value. Driver API provides a formalism on which the Portal's tools are built.

Of course, as you have some legacy data sources, you have some legacy applications, for example your CAD System. Using Portal Solutions does not imply that you change it, you have only to code an application driver in order to integrate it into the Portal.

• Driver API enables you to code the access to your Data in a very simple way
• Dassault Systèmes builds for you tools and services on this Driver API formalism
• It enables you to integrate your existing applications

[Top]

The concepts managing by each type of drivers

Before using the Portal, when you installed a new repository, you had to code the access to this repository for all applications that would use it. Now you have only to code the driver accessing your data and every application using or having an adapter to the Driver API Formalism will inherit the access.

• Developing applications and Developing Repositories are two different jobs. The Driver API formalism enables that there be no coupling between them.

Implementing a driver consists in implementing some tasks that are specifics to your applications or data. These tasks depend on the driver type because each driver type manages differents concepts presenting in the form of interfaces to implement.

[Top]

Data Driver

The Data Driver manages the access to your data, and especially requires the implementation of interfaces corresponding to the following concepts:

• Security: It's up to you to check the user's authorization on your data.
• Metadata: You have to describe your data and their attributes
• Data: By implementing this interface, you enable the query and the navigation in your data.

The three above interfaces are the core of the data driver.
As extended Services, you can add functionalities like:

• Bookmarking: This implies that you are able to query an object by its uuid
• Extract Data: If your data are stored in a secured vault, you need to give the driver the ability to extract them if you want to read them.

Afterwards, all the following portal services:

• Query tool
• Product structure Navigator
• Bookmarking Services
• Data Up-Downloader
• Reporting tool

are provided on your data thanks to your driver. See [1] for further's information.

[Top]

Application driver

The Application driver enables you to register actions on an object. These actions can be displayed through a popup menu in the WebTree or displayed as an icon in an html page. The definitions of these actions are independent from the user interface.

Hence, you can add an analysis tool on a selection of objects.

On an object, you can register actions due to 3 reasons:

• The possible document tied to the object: If a CATIA model document is attached to the object, CATIA is launch able.
• The type of an object: For example, a part can be promoted.
• The location of the object in the tree: a node can be expanded unlike a leaf

[Top]

Two Ways of Considering the Drivers

• As a Driver Supplier:

  You will code an access to your System or to a generic System, a data Driver. Then you will inherit all the functionalities like Query, Navigation, Book marking.

• As a Portal Application Supplier:

  You want to add the communication with your application. You will code an application driver that will enable to feed your application with data obtained by the Portal.

[Top]

In Short

Application and Data Driver are a way for you to extend the Portal.

[Top]

References

History

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