3D PLM Enterprise Architecture

What You Will Learn With This Article

This article describes the basic classes and notions which will be used in the four use cases dealing with event model and  publish/subscribe notions. Some classes are used in more than one use case, and the article details them:

• CAAVpiSimpleSubscription
• CAAVpiPublishEvents
• CAAVpiAutomaticSubscription
• CAAVpiPackageSubscription

[Top]

Customization Requirements before running the Use Cases

The Use Cases presented in this education framework require that a data domain named "INDEX" exists in LCA. By default, no such domain exists. Hence, for the following Use Cases to run properly, your installation has to be customized to include this data domain in the runtime environment.

For this purpose, a metadata file named "CAA_INDEX.metadata" is delivered in the directory "InstallRootDirectory/CAADoc/CAAVPMInterfaces.edu/CNext/resources".

This file defines two entities "Part" and "Document" in the data domain "INDEX". These entities are created and manipulated by the following Use Cases located in the present education framework:

• CAAVpiPublishEvents
• CAAVpiAutomaticSubscription
• CAAVpiPackageSubscription

To customize your environment, you have first to create a new framework named "INDEX" under your workspace root directory along with the following file tree:

INDEX -> CNext -> code -> dictionary

INDEX -> CNext -> reffiles -> DBMS -> Generator

Copy the metadata file "CAA_INDEX.metadata" to the newly created directory "RootDirectory/INDEX/CNext/code/dictionary", and rename it "INDEX.metadata".

Copy the param file "CAA_INDEX.param" to the newly created directory "RootDirectory/INDEX/CNext/reffiles/DBMS/Generator", and rename it "INDEX.param".

Then you have to publish and deploy this customization in your runtime environment using the Data Model Customizer RADE Tool.

Refer to the technical article concerning DMC for ENOVIA LCA to learn how to do it. Finally, check that the file "INDEX.metadata" exists now in the directory "OS_a/code/dictionary" of your runtime environment.

Under directory "InstallRootDirectory/CAADoc/CAAVPMInterfaces.edu/CNext/resources", you will also find an event file named "CAA_INDEX.event" which declares the events related to the data domain "INDEX".

For the following Use Cases to run properly, you have to copy this event file to the directory "OS_a/reffiles" of your runtime environment, and rename it "INDEX.event".

Note that you could alternatively copy the file to the directory "RootDirectory/INDEX/CNext/reffiles" (to be created), rename it, and update the runtime view.

This is the final step of the Customization Requirements.

[Top]

The UML Diagram for Classes Involved in the Use Cases

This UML diagram represents all the classes involved in the four use cases delivered for illustrating the ENOVIA event model capabilities.

[Top]

Detailing the UML Diagram Classes

In the event use cases, there are four different kinds of classes to be precised.

The Standard Classes

In each use case, an ENOVIA Session must be created and opened, and to be able to work further, a login session must be opened too (attached to 1 user). To be able to subscribe to events, people must get the object which manages the event model: a query on the Session gives an ENOVIEventManager interface pointer, and using it, you will be able to perform subscriptions and get information on events. There usually is one Event Manager per ENOVIA session while there can be more than one Login Session per ENOVIA session.

The Publisher Class

The CAAVpiFileManager class is used in 3 of the 4 events use cases : it raises events that the CAAVpiFMEventsSubscriber and the CAAVpiFileManager classes can subscribe to , by implementing the associated CAAIVpiFMCallback interface.

To raise events, CAAVpiFileManager uses an EVENT_FIRE macro (see [2]) which implies an indirect and hidden link with the event manager class . In the different use cases the CAAVpiFileManager instances will have methods called, which raise events, so that potential subscribers receive messages .

The Subscriber Classes

The UML diagram shows three "simple" subscriber classes, each of them being used in one single use case.

• The CAAVpiSimpleSubscriber subscribes to events that a login session may raise . To do that , it implements an "explicit" callback interface : ENOVISessionEvent, and a "generic" callback interface : ENOVISubscriberEvent , to show 2 different ways of subscription. in both cases, one must get the event manager attached to the current session.
• The CAAVpiFMEventsSubscriber and CAAVpiFileManagerListener classes will subscribe to events that the CAAVpiFileManager instances may raise. To do that, they implement the CAAIFMEventsCallback interface, and get the event manager attached to the current session.
  

The Automatic Listener Classes

The CAAVpiAutomaticSubscription and CAAVpiPackageSubscription use cases show 2 different mechanisms of automatic subscription when the creation of a login session is involved.

• The first one implies a CAAVpiPlugin class, extending a late type T_Plugin for the implementation of ENOVIEventPlugin interface (see details in the use case documentation). The session is able to automatically instantiate an object and call the unique method of the ENOVIEventPlugin Interface : Init. In this method, a subscription to event CreateLoginSession step After is performed for a listener class that implements ENOVISessionEvent. In the callback method onAfterCreateLoginSession, a CAAVpiFileManager instance will be created and will subscribe to events on CAAVpiFileManager objects.
  
• The second one implies the CAAVpiSessionListener class, to use a generic mechanism of the session : each domain of ENOVIA (PRODUCT, ACTION, DOCDIR, INDEX, ...) is associated with a late type INFO_<<NameOfDomain>>; when a domain is loaded during the session initializations, the session asks if there is an extension of the late type which implements the ENOVISessionEvent interface (let's call it "listener"), and if yes, subscribes it to Session and LoginSession events . So when a loginsession is created, the "listener" is called back and can subscribe other objects to others events.

Here, the CAAVpiSessionListener extends a late Type INFO_INDEX, associated to the test ENOVIA Domain "INDEX" and implements ENOVISessionEvents interface.When it's called back at loginsession creation time, it instanciates the CAAVpiFileManagerListener and makes subscriptions to events raiseable by the CAAVpiFileManager objects.

[Top]

Classes and Use Cases

The following table shows the use of the different classes in the use cases.

[Top]

In Short

This article has introduced the common notions of the four use cases describing events model. To go further refer to the detailed four use cases.

[Top]

References

History

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