Object Type Exposure in LCANavigator/3dcom

LCANavigator	Customization	Object Type Exposure in LCANavigator/3dcom Describing how to create and modify object types.
Technical Article

Note

In this document words in italic represent specific values or names which must be supplied for the customization process. (Except in comments from Properties files)

LCA Web Type and LCA Type Customization
Miscellaneous Customization
Command Definition and Implementation

Thin Client User Interface

The LCA Navigator/3dcom environment is made up of two servers:

The web server (WebSphere) which generates and delivers the html user interface to the user’s browser on the user’s machine.
The ENOVIA V5 (LCA) server which is accessed by the web server to process and send back data based on the user’s request.

The LCA server provides a rich data model to the LCA server applications. This data model can be extended by using the RADE Data Model Customizer tools. Detailed instructions on how to do this can be found in the CAA RADE documentation. The LCA Navigator/3dcom web application provides a filtered view of the data model provided by the LCA server. If a new data type is defined on the LCA server using the RADE tooling, then additional work must be performed to expose this new data in the LCA Navigator/3dcom user interface. The LCA Navigator/3dcom web application uses “web types”, which are merely nicknames or synonyms for data types on the LCA server. So for each data type on the LCA server which needs to be exposed on the web server, the following tasks need to be performed:

Define a unique web type that maps to the LCA server type.
Define the characteristics of the web type (inheritance, relationships)
Add this web type to the appropriate search groups for exposure on the PPR Access search panel and Quick Search banner.

Defining a web type to map to a LCA server type
Defining the web type characteristics
Exposing the web type for search and quick search

Defining a web type to map to a LCA server type

This section describes how to define a LCA Navigator/3dcom web type that maps to a LCA server data type.

Runtime view subdirectories: ./resources/pprregistry/types/ENOVIA

Files: ENOVWebBO*.properties

Customization strategy:

New files
No files copied from the product installation directories.

The web types are defined in ENOVWebBO*.properties files. A web type is a unique nickname or synonym for a LCA server type. For clarity, the web type should be the same as the server type. If the server type name is not unique, then a unique web type name must be created. The format of the entries in the properties file is very simple.

WebType=Modeler.ServerType

where WebType is the unique web type string you are defining, the Modeler is the server domain in which the server type is defined, and ServerType is the name of the server type within the domain. The WebType and ServerType can often be the same value. There is one special case. When customizing a business object (which is comprised of two or more modeler data types), the custom business object must redefine within the same customer modeler each of the data types comprising that business object. When defining a web type for this custom business object, the server type should be the original business object type, not the customized server type. Example: The base Document web type maps to the DOCDIR.VPMDocFile business object. If a customized document business object CUSTOMDoc is defined in the CUSTOM modeler as the CUSTOM.CUSTOMDoc, then the custom document web type CUSTOMDoc needs to be defined as CUSTOMDoc =CUSTOM.VPMDocFile using the original business object type VPMDocFile rather than the custom server data type CUSTOMDoc.

ENOVWebBOCUSTOMDoc.properties file:

#------------------------------------------------------------------------
# Define the mappings from the web type to the server modeler names and
# server type names.
#    Syntax:
#      <web type name/>=<modeler name/>.<server type name/>
#------------------------------------------------------------------------

# NOTE: For the special case of business object customization,
#       the server type must be the original business object type.
CUSTOMDoc=CUSTOM.VPMDocFile

One (or more) new properties file should be created to hold the custom web type definitions. There is no need to override any of the shipped properties files by copying them to the customization directories. The naming convention for these properties files is ENOVWebBOXxxxx.properties, where Xxxxx makes this file uniquely named. The Xxxxx could refer to the custom modeler on the server, or any other naming convention that is desired. The only requirement is that it is unique from any of the other custom properties files or base shipped properties files.

Defining the web type characteristics

This section describes how to define the characteristics (inheritance, relationships, etc) for a LCA Navigator/3dcom web type.

Runtime view subdirectories: ./resources/pprregistry/types/ENOVIA

Files: ENOVWebObjectWebType.properties ENOVWebLabelsWebType_en.properties

Customization strategy:

New files
No files copied from the product installation directories.

The detailed information about a web type is defined in the ENOVWebObjectWebType.properties file, where WebType is the unique web type name. This properties files has many specialized sections that controls various functions in the web application. These sections of the properties file will be detailed in the appropriate sections of this customization document. The important information to put into the ENOVWebObjectWebType.properties file is the Parent property. If the web type refers to a server type that has a supertype Yyyy, then the web type should have a Parent property that specifies the web type that maps to the server type Yyyy. The parent web type can be discovered by searching through the custom and shipped ENOVWebBO*.properties files. Example: The base A new custom Action type CUSTOM.CUSTOMAction has been added to the LCA server and has APLAFL.AFLBaseAction as its supertype. Searching through the shipped ENOVWebBO*.properties files, it is determined that the Action web type refers to the APLAFL.AFLBaseAction server type. The following steps should be performed to correctly expose the new CUSTOM.CUSTOMAction server type:

1. A new web type CUSTOMAction should be defined (in a custom ENOVWebBO*. properties file) that maps to the CUSTOM.CUSTOMAction server type
2. In the ENOVWebObjectCUSTOMAction.properties file, a Parent property should be added to set Parent=Action.

In addition to the base ENOVWebObjectWebType.properties file, there is also a need to have a ENOVWebLabelsWebType_en.properties file that defines the labels for the web type and its relationships. Although the subject of object relationships is not covered in this book, the file should still be defined. The contents are very simple.

#-----------------------------------------------------------------
# This file defines the labels for the CUSTOMAction web type
#-----------------------------------------------------------------
Name=Priority Action

#-----------------------------------------------------------------
# Define the labels for any object relationships
#   Syntax is Relationship.Name=Label
#-----------------------------------------------------------------

For languages other than US English, then properties files with the appropriate language extensions should be created. For example, the French properties file should be named ENOVWebObjectWebType_fr.properties.

Exposing the web type for search and quick search

This section will describe how to expose a new LCA Navigator Web Type on the user interface.

Runtime view subdirectories:

./resources/pprregistry/search

Files: GroupFileName.WebType.XMLSearchType GroupFileName.XMLSearchInfoGroup

./resources/msgcatalog

Files: Xxxxx.CATNls

Customization strategy:

New files
No files copied from the product installation directories.

The LCA Navigator user interfaces uses the search group definition xml files to define the Environment and Type listings that are displayed in the user interface. This allows web types that represent server types from separate modelers to be presented in a single Environment on the user interface (such as the Change Management or Content Management environments that combine types from different modelers). However, this layer also prevents newly defined web types from being visible on the user interface. There are two strategies for adding new webs to the user interface:

1. If the new web type should appear in an existing Environment group (for instance, adding a new Action subtype to the Change Management group), then a XMLSearchType file should be defined. This file appends a new type to an existing group.
2. If the new web type should appear in a new Environment group, then a new XMLSearchInfoGroup file should be defined. This file defines a new group and can contain a list of the types that belong to this group.

The contents of a XMLSearchType file are as follows:

<?xml version="1.0"?>
  <DataType Name="WebType" Adapter="ENOVIA" Group="GroupName"
   	MsgCatalog="Xxxxx"
	QuickSearch="true">
  <QuickSearch attr="AttrID"/>
</DataType>

The DataType xml element attribute definitions are:

Name the WebType value is the name of the web type being exposed on the search panel.
Adapter the value should always be ENOVIA, which is the internal name of the LCA adapter within the 3dcom infrastructure.
Group - the GroupName value is the internal group name of the group to which the type is being added. This must match the Name attribute of the SearchGroup element in the XMLSearchInfoGroup file defining the group.
MsgCatalog - the Xxxxx value is the name of a CATNls file that contains the translated label for this web type. Usually this is a new file created along with the search type file. Multiple XMLSearchType files can share the same CATNls file. The format of the entry in the CATNls file for this WebType is: // Provide translated labels for the search entities WebType = Label;
QuickSearch this Boolean flag indicates if this type should be included in the Quick Search banner list of types. Only the most frequently needed types should be included in the quick search list. If this value is true, then there must be at least one QuickSearch child elements under the DataType element. QuickSearch data element. The Quick Search banner provide the type selection and an input field to do the search, but provides no way to choose what attributes to do the search against. So the QuickSearch elements represent the attributes against which a Quick Search banner search will be performed. The result will be a union of the searches for the user specified value against each of the specified attributes.
```
attr
```
attribute: This value is the name of an attribute on the webtype that will be compared to the user input value in the QuickSearch banner.

Example: The CUSTOMAction web type represents a new custom action object. This new action subtype will be added to the Change Management environment (defined in LCAJChgMgmt.XMLSearchInfoGroup, group name is “ChgMgmt”). The CUSTOMAction data type inherits a V_name field from the parent AFLBaseAction type. There is also a custom V_keyword field that the user may do a quick search on. The LCAJChgMgmt.CUSTOMAction.XMLSearchType file is defined as:

<?xml version="1.0"?>
  <DataType Name="CUSTOMAction" Adapter="ENOVIA" Group="ChgMgmt"
    MsgCatalog="CUSTOMLabels"
	QuickSearch="true">
  <QuickSearch attr="V_name"/>
  <QuickSearch attr="V_keyword"/>
</DataType>

The CUSTOMLabels.CATNls file provides translated labels for the search entities

CUSTOMAction = Priority Action;

When creating a new Environment group to contain the custom types, the steps are very similar. An outer SearchGroup xml element is used, with the same DataType xml elements to define the individual types.

<?xml version="1.0"?>
  <SearchGroup Name="GroupName" Adapter="ENOVIA" MsgCatalog="Xxxxx">
  <DataType Name="WebType1" QuickSearch="true">
  <QuickSearch />
  </DataType>
  <DataType Name="WebType2" QuickSearch="false"/>
  <DataType Name="WebType3" QuickSearch="false"/>
</SearchGroup>

The SearchGroup xml element attribute definitions are:

Name: The GroupName value is the internal name of this group. This name is the key value that will be looked up in the MsgCatalog to find the translated label for the Environment.
Adapter: The Adapter value should always be ENOVIA, which is the internal name of the LCA adapter within the 3dcom infrastructure.
MsgCatalog: The Xxxxx value is the name of a CATNls file that contains the translated label for this Environment group, as well as all of the data types declared in this group. Usually this is a new file created along with the search group file. The format of the entry in the CATNls file for this WebType is:
```
		// Provide a translated label for the Environment search group
		GroupName = Label;

		// Provide translated labels for the search entities
		WebType1 = Label;
		WebType2 = Label;
		WebType3 = Label;
		
```

The DataType xml element is the same element that is used in the XMLSearchType files. Several attributes are defaulted from the SearchGroup parent element, such as the Group name and the MsgCatalog. If there is already a CATNls file that contain a label for the data type, then the DataType element can have a MsgCatalog value to reference this CATNls file.

What is customization

This section contains several specific customizations that may be need to tailor the user interface to meet your customization requirements.

Adding a new subtype to the parent’s create panel
Hiding a relationship tab in the Properties page
RELNav Relationships

Adding a new subtype to the parent’s create panel

This section describes how to add a new subtype to the parent type’s list of creatable types.

Runtime view subdirectories: ./docs/javacommon

Files: ENOVWebObjectParent.properties

Customization strategy:

Copy properties file from the product installation directories.
Dual maintenance on this file is the responsibility of the customer.

The LCA Navigator user interface allows a create panel to list the various object subtypes that can be created. For instance, the Action create panel lists all of thee various Action subtypes and allows the user to select which one to create. When adding a new subtype to an object already exposed on the LCA Navigator user interface, this subtype can be added to the list on the parent type’s create. An alternative is to not add the new subtype to the parent create panel, but instead require the user to directly perform a create operation on the new subtype instead of the parent type. This avoids copying the parent type’s properties files from the original installation directories. Here are the steps to add a new subtype to the parent type’s create panel:

1. If not already done, define the new subtype as a web type, and create a properties file to define the new subtype inheritance to the parent web type.
2. Copy the ENOVWebObjectParent.properties, where Parent is the parent web type, from the product installation directories to the customization directory.

3. Within this properties file, there is a “CreateTypes” property that defines the list of subtypes that will be displayed on the create panel.

a. If this property does not exist in the file, then add it. The list should contain both the parent type and the new subtype. Whichever web type that appears first in the list will be the default type on the create panel.

				#----------------------------------------------------------------
				# Create types
				# Specify the subtypes that can be created
				#    Syntax:
				#      CreateTypes=Type;Type;Type
				#----------------------------------------------------------------
				CreateTypes=Document;CUSTOMDoc

b. If the property already exists, then add the new subtype to the list. Whichever web type that appears first in the list will be the default type on the create panel.

				#----------------------------------------------------------------
				# Create types
				# Specify the subtypes that can be created
				#    Syntax:
				#      CreateTypes=Type;Type;Type
				#----------------------------------------------------------------
				CreateTypes=Action_Design;Action_Deliverable;Action_Manufacturing;Action_Maintenance;Action_Documentation;Action_SignOff;Action_PenetrationRequest;CUSTOMAction

Hiding a relationship tab in the Properties page

The Properties page for an object shows the object attributes as well as the related objects. Depending on the business process developed for use with LCA Navigator, there may be object relationship exposed on the Properties page that are never used by the end users. In this case, the relationship can be hidden so that it will no longer appear on the Properties page.

Runtime view subdirectories: ./docs/javacommon

Files: ENOVWebObjectXxxxx.properties

Customization strategy:

Update of custom web types in the customization directory.
Copy base web type properties file from the product installation directories.
Dual maintenance on base web type files is the responsibility of the customer.

The ENOVWebObject*.properties files define the object relationships for a web type. By default, the relationships are exposed on the Properties pages. However, an additional property can be added to the properties file in order to hide the relationship so that it does not appear. First, the web type for the displayed object must be determined. Then the internal relationship name must be determined that goes with the relationship tab that is to be hidden. The ENOVWebLabels*_en.properties file can be examined to see the relationship labels in order to find the internal relationship name. Once you know the web type and the internal relationship name, then perform the following steps:

1. Copy the ENOVWebObjectWebType.properties, where WebType is the web type that needs to be modified, from the product installation directories to the customization directory.

2. There may be a Relationship Flags section in the properties file. If not create one at the bottom of the file and add the following information, where ‘Relationship’ is the internal name of the relationship that is to be hidden.

		#----------------------------------------------------------------
		# Relationship Flags
		# These property values allow you to hide a local or
		# inherited relationship.
		#    Syntax:
		#      Rel.=Hide|Expose
		#----------------------------------------------------------------
		Rel.Relationship=Hide

ENOVWebBOEnvironmentName.properties File
Changing the order in which the Properties tabs are presented
Adding a web type to an object’s list of allowed attach types
Programming updates to allow multi-select on attach

ENOVWebBOEnvironmentName.properties File

Defines Web Type to Type mapping: Files are located in ./resources/pprregistry/types/ENOVIA directory Format is: WebTypeName=ModelerName.ServerTypeName For custom BO types, the MODELER must be the custom modeler, but theTYPE must be the original BO type definition, not the custom type defined in the custom modeler. Example: customDoc type would be: CustomDoc=CUSTOM.ENOVIA_VPMDocFile

Changing the order in which the Properties tabs are presented

Rel.display example: Rel.display=AffectedObjects,Attachments,AllLinks,AssociatedObjects,History (Names are internal names)

Adding a web type to an object’s list of allowed attach types

AttachTypes and AttachRelTypes example: Rel.n.AttachTypes= Part, DocRevision, Document, TOCFolder, Clash Rel.n.AttachRelTypes= InputAffectedObject, OutputAffectedObject (Names are internal names)

Programming updates to allow multi-select on attach

AttachCardinality example: Rel.0.AttachCadinality=[MULTI]

RELNav Relationships

If a new type is added to LCANav or if new relationships are created for a given type, RELNav customization files must be updated for the new types to be displayed properly.

RELNav uses domain files located in: ./resources/definitions/relgroups/

Adding a new type (or sub-type with different look) requires: First a new file: MyRelNavCustoNameDefaultRelGroup.xml defining the new customized types. In the file LCAMainRelGroup.xml add the corresponding entry:

			<RelGroup Defn="MyRelNavCustoNameDefaultRelGroup" />
			For each new type add in MyRelNavCustoNameDefaultRelGroup.xml the corresponding entry:

     		<!--  Relationship mapping for type TYPENAME  -->
			<EntityMap MapName="TYPENAME">
			<EntityType Defn="LCAEntity">
		  	<EntityName>TYPENAME</EntityName>
		  	</EntityType>
			<RelType Defn="LCARelationship" IsPrimary="true">
		  	<RelName>RelationName0</RelName>
		  	</RelType>
			<RelType Defn="LCACollectedRelationship">
		  	<RelName>RelationName1</RelName>
		  	</RelType>

		    ...1 to n
			<RelType Defn="LCACollectedRelationship">
		  	<RelName>RelationNameN</RelName>
			</RelType>

Adding a new relationship requires a new entry like:

			<RelType Defn="LCACollectedRelationship">
		  	<RelName>RelationNameX</RelName>
  			</RelType>

Adding a new subtype with exact same look as the parent requires a new entry like:

  			<EntityName> TYPENAME </EntityName>
  			<EntityName>SubTypeName0</EntityName>
			...0 to N
  			<EntityName>SubTypeNameN</EntityName>

If necessary, assign the proper color to specific object status (See 3.1.1)

What is customization

overview text

Registering Command on Type
Command Implementation

Registering Command on Type

Registering new command commandName

Definition file located in: ./resources/pprregistry/command/definition This file named commandname.xml defines the following command basics: -Name: The directory name where the specific java code for the command execution is located. -Icon: The icon to be displayed in the toolbar or the contextual menu. -Msgcatalog: The CATNls file where title and tooltip for this command are defined. See example in 6.1
3.3.1.2. Assignment file (Command to Type mapping) Assigning command commandName to type typeName The command is assigned to a type through the assignment file (typename.xml). Mapping entries consist of the following attributes: -Name: Value is the above definition file name (commandname). -multiRowEnabled:True or False. Multi-row selection in list -enablement:True, False or Rule based. Command enablement for type -listEnablement:True, False or Rule based. Cmd enablement type in list -objEnablement:True, False or Rule based. Cmd enablement for type display (In case of listEnablement or objEnablement value, enablement value is ignored). -visibility: True, False or Rule Based Command visibility for type -listVisibility: True, False or Rule Based Cmd visibility for type in list -objVisibility: True, False or Rule Based Cmd visibility for type display (In case of listVisibility or objVisibility value, visibility value is ignored). The mapping follows the inheritance rule and a type derivedtypename , deriving from typename will be mapped the same way except if it redefines a different mapping (visibility,…) through an assignment file named derivedtypename.xml file and so on...
3.3.1.3. Rule file In the rule based command case, the enablement or visibility attribute is the name of a the rule xml file (RuleFileName.xml). This file is the rule file definition: xml rule files may either contain a predicate in the form of an attribute-value pair attributes, or specify a predicate java class or both (with AND operator). The attribute-value pair is used for simple rules like attr="isCompleted" value="false" The predicate java class may do more complex checking Predicate class definition The new rule’s package name is (For code clarity purpose): FwkName.ModuleName.custoruleName. Rule class name is RuleFileName.java (For clarity purpose) Example: actioncancelenable.xml
```
		<Rule name="cancelenable">
		<Predicate operator="AND">
  		<Predicate attr="isCompleted" value="false" />
  		<Predicate class="com.ds.FwkName.ModuleName.custoruleName.CancelRuleClassName" />
		</Predicate>
		</Rule>
		
```

3.3.1.4. Package file The rule class is defined in a new package prefix of a new Java class

		<Command Package>
		<PackagePrefix Adapter="ENOVIA" Name="com.ds.FwkName.ModuleName " />
		</CommandPackage>

Command Implementation

The command implementation consists of a new class in a new package. Package and class name must be: FwkName.ModuleName.command.commandname.ClassName commandname must be the xml file name (See above ) defining this command Either in: LCAJAppBase/cnext//resources/pprregistry/command/definition/commandname.xml. (Redefinition of an existing command for a subtype). Or in: FwrkName/cnext//resources/pprregistry/command/definition/commandname.xml, (New command for the new type). FwkName.ModuleName is defined in the package file There are two basic types of command: Commands which execute a server command. Commands which load a new screen(s) from which, a server command may be executed. For the first type the command definition suffices, but for the second one: -The command XMLDlg must be provided as well as the corresponding controller. -The corresponding CATNls file must also be created.

In Short

This article has explained how to modify, create and expose object types.

[Top]

History

Version: 1 [Jul 2005]	Document created
[Top]