Business Process Services Overview

This section lists the components ENOVIA Business Process Services provides to support the ENOVIA applications.

The ENOVIA Business Process Services contains these schema items as defined in the Schema Reference Guide (Overview):

• associations
• attributes
• business objects
• commands
• formats
• groups
• menus
• persons
• policies
• programs, including Java Program Objects (but not those specific to an application)
• relationships
• roles
• stores
• types
• vaults
• wizards (for administrative uses only, not for business processes)

Each ENOVIA product contains the items listed in this table.

Some applications, such as Materials Compliance Central, install other components that may be shared between applications. When this is the case there are 2 directories installed under ENOVIA_INSTALL\Apps, one which includes "base" in the name, such as MaterialsComplianceBase. These base directories are where the doc directories can be found.

For example: c:\enovia\studio\Apps\APP_NAME\VERSION\pdf.

The documentation that describes the common components installed with ENOVIA Business Process Services can be found in the ENOVIA_INSTALL\doc directory.

Whether building a new application from scratch or extending an existing application, the UI components significantly reduce coding effort and make your code easier to upgrade.

The application interface consists of the following:

• Application Login
• Navigator Page and Toolbars
• Global Toolbar
• Menus
• Global/Generic Search component
• Application-specific Search Pages
• View Table Pages
• Mass Editable Configurable Tables
• Structure Browser Tables
• Navigation Trees / Structure Navigator Pages-.
• Configurable Web Forms
• Configurable Type Chooser Forms
• Configurable Vault Chooser Forms
• Calendar Popup Forms
• PowerView Configurable Pages (Portal Pages)
• Internet Portals

ENOVIA Business Process Services uses several database objects to support applications.

ENOVIA Business Process Services uses these database objects:

• Pre-defined schema (administrative and business objects)
• Program (Tcl and JPO) objects
• User Interface objects

The schema files contain these items:

• JPOs contain business logic.
• XML files contain schema definition and rules.
• The XML definition file contains the actual schema definition for types, attributes, relationships, and so on.
• The XML manifest file lists what schema is required by an application or functional area.
• The mapping file drives the installation wizard and defines prerequisites.
• The conversion file describes what version a conversion should run at and specifies the prerequisite schema.

Each application installs its own jar file that contains Beans and utility classes and the ENOVIA Business Process Services installs multiple jar files. This installation scheme allows ENOVIA products to be updated without having to update everything.

You can look at the version field in the manifest files for each jar to figure out what versions you currently have installed. A pictorial representation of the multiple-tier jar hierarchy is shown below.

ENOVIA Business Process Services is responsible for these jar files: framework.jar and common.jar.

The framework jar file contains the base classes DomainObject and DomainRelationship, as well as several interfaces and classes needed to support these base classes. This jar file also contains a number of utility classes.

The framework jar file also contains custom tags that make up our custom tag library, and classes that wrap the dynamic UI components (often referred to as the UI Beans).

To promote reuse of business logic, a common jar file has been established independent of any application. The common jar file contains domain Beans that are shared by more than one application. The common jar file also contains utility classes shared by more than one application.

There are strict rules on the dependencies allowed among the framework, common, and application tiers (as shown in the figure). Framework JSPs, JPOs, and Beans can only reference the framework jar files. The common components JSPs, JPOs, and Beans can only reference the common components and framework jar files. Each ENOVIA product's JSPs, JPOs, and Beans can only reference their own jar file and the common components and framework jar files.

An ENOVIA product can never reference another ENOVIA product's jar file.

The ENOVIA products allow you to use your exact business terminology. Names are case-sensitive and spaces are allowed. You can use complete names up to a maximum of 128 characters. Leading and trailing spaces are ignored.

The naming conventions for the ENOVIA Business Process Services ensure that:

• Programs refer to each other correctly.
• Business process application programs can be distinguished from non-business process application programs.
• It is easy to identify the purpose of the file and the application it belongs to.

Some object names installed with the ENOVIA Business Process Services are prefixed with "eService" and the version number of the installation. The installation program adds this prefix to prevent name collisions between objects in the framework and objects in the existing database. For example, if you install version V6R2011x BPS onto a database that contains a Part type, the installation program renames the Part type within the framework to "eServiceV6R2011x~Part". Other administrative objects within the framework that refer to the type--such as attributes for the type, relationships that connect the type, and policies that govern the type--refer to the framework Part type, now named "eServiceV6R2011x~Part." The installation makes no change to the existing Part type.

To list the name collisions the system found during installation, open the file named installFrameworkVERSION.log, where VERSION is the software version number, located in ENOVIA_INSTALL\Apps\BusinessProcessServices\VERSION. The file also lists all the administrative objects installed or modified during installation. For instructions on configuring objects in the framework, using existing objects instead of the objects installed with the framework, and for information about the installation process, see Configuring Using Schema.