About Objects/Options You Can Configure

The ENOVIA products use emxLogin.jsp and properties files to control the login process.

When a user logs in, the system goes to a general JSP for all applications, emxNavigator.jsp. The application submenus and commands are represented by administrative objects in the database.

The StringResource.properties files are different from the properties files discussed in this section. The StringResource.properties files define all text used in an application for internationalization. For more details, see Internationalizing Business Process Services Products.

Users enter a username and password using emxLogin.jsp. If the username and password is valid, the page forwards to emxNavigator.jsp. Users may also need to select a security context, if more than one has been assigned to them.

If your system uses Single Signon (SSO) for authenticating users, then users will use the SSO tool's login page and so the system bypasses emxLogin.jsp.

An ENOVIA administrator can require a user to change his/her password by setting Password Change Required for the person's administrative object. When the person attempts to log in, a message appears that says the person must change the password. When the user clicks OK, the Login page displays fields for changing the password.

The change password fields also appear on the Login page when the administrator sets system-wide password expirations for every x days. In Business Modeler, system-wide password settings are in the Settings > Password menu. Every x number of days, all users who have a password will be prompted to change their password. They must change their password before they can log in.

You can define the kinds of passwords that can be created for users using the system-wide password settings in Business Modeler. For example, you can set minimum and maximum character limits, require that passwords contain alphabetic and numeric characters, and restrict passwords from being the same as the username. For instructions, see the Business Modeler Guide.

This section describes requirements for logging into ENOVIA.

To log into a dynamic user interface application, a person must enter the username and password for a person who has:

• a valid person administrative object defined with that username and password
• a matching Person business object that is in the Active state and connected to an Active Company business object with the Employee relationship

If the first condition is met but at least one of the conditions in the second bullet are not met, the system presents an error message that asks the person to contact their administrator.

Logging in gains the person access to emxNavigator.jsp. To access menu items and other application components, the person must belong to roles that have access to those components, as described in Access Checks for Individual Components.

To log in as a different user, you must log out as the current user first. If you try to access the login page without first logging out, the system displays your default home page within emxNavigator.jsp.

If the Login Type attribute for the user's Person business object is set to Secure ID and the emxLogin.UseSecureId property is set to true, the login page requires the user to fill in the Secure ID field. If the user's Login Type is set to Standard, the login page ignores any entry in the field.

The diagram below shows how the system authenticates a user whose Login Type is set to Secure ID and when the UseSecureID property is set to show the Secure ID field on the login page. To implement this kind of authentication, you need tokenAuthen.jar and supporting native libraries, which are all supplied by IBM/Tivoli, on your Web server.

When running in an SSO environment that has been set up to bypass the emxLogin.jsp and emxLogout.jsp pages, the system performs the steps described in this section.

The ENOVIA system:

• Forwards to emxNavigator.jsp after a user logs in through the SSO login page. If a user accesses the emxLogin.jsp directly (by entering the URL in the browser or by clicking a shortcut to the URL), the system goes to the SSO login page instead.
• Forwards to the page set up on the SSO server for bypassing emxLogout.jsp, such as a web portal page, when a person clicks the Logout button on emxNavigator.jsp. The person is not logged out until the browser is closed and cannot log in as a new user until a new browser window is opened.

If the SSO server is not configured to bypass emxLogout.jsp, the system returns to emxNavigator.jsp when a user attempts to log out.

ENOVIA Business Process Services installs with a command object called AEFLogoutToolbar, which creates the Logout tool on the global toolbar. The Logout tool calls emxLogout.jsp. For more information on the Logout tool and command object, see Logout Command.

To launch a viewer from within an application, the viewer must be registered and the formats that the viewer can open must be assigned to the viewer. This section describes the connections and objects that must exists in the database to register a viewer and assign formats.

To register a viewer and associate formats with viewers, Business Process Services creates the objects and connections for you. For information, see Registering Viewers.

The following graphic shows the database objects and connections needed to register a Brava viewer and a Spicer viewer and assign four formats to each.

The program object emxViewerRegistration is a placeholder for registering viewers. To register a viewer, there must be program object with the same name as the servlet used to invoke the viewer and this program must be connected to emxViewerRegistration with the installedViewer property. Formats that are compatible with the viewer must be defined as format objects and connected to the viewer program object with the supportedViewer property. The program objects that represent the viewers also have a property called viewerTip that stores the text for a ToolTip for the viewer.

If changes are made to an application or to the underlying ENOVIA Business Process Services, ENOVIA cannot ensure the accuracy of the documentation.

These changes include but are not limited to:

• Changing onscreen text
• Adding or removing fields on a page
• Changing administrative objects in the schema
• Adding new JSPs or changing existing JSPs
• Changing trigger programs
• Changing the installation or login process
• Changing the values in any properties file

See Customizing User Documentation for instructions on making changes.

Each ENOVIA product has two forms of user documentation as described in this section.

Documentation comes in these formats:

• A user guide in Acrobat PDF format

  The PDF user guide is created from FrameMaker source files by saving the entire book as pdf from within the FrameMaker book file. FrameMaker uses Adobe Acrobat to perform the pdf conversion. Users must have Acrobat Reader or Adobe Acrobat to view the file.

• An html-based online help system

  The online help is context-sensitive so when a user clicks help from a page (visual page, not JSP), the help system displays information about that page. The help system uses the same FrameMaker source files as the PDF user guide. These source files are converted to a JavaScript-based help system using WebWorks Publisher Professional Edition.

In addition, all ENOVIA products include two other context-sensitive html-based online help systems: AEF Help and Common Components Help (both part of ENOVIA Business Process Services). These are also created in FrameMaker as separate user guides.

AEF Help and Common Components Help contain information about ENOVIA Business Process Services, a prerequisite for all ENOVIA products. The needed help system is called when the user clicks the Help button on a page, such as pages called from toolbar tools (Change Password, Preferences, Discussions, Collections, and so on.)

Help called from within an application, such as the common routes page in Engineering Central, opens the appropriate help system (Common Components help, in this case).

The applications also have documentation for ENOVIA business and system administrators, such as an administrator guide. Although these documents are also created in FrameMaker and are produced in a similar way, this section applies only to documentation aimed at standard end users.

When on-staff or partner writers update application documentation for a new release, they use the FrameMaker source files. This is the approach that should be used if the applications are heavily customized, rendering the out-of-the-box help obsolete.

Contact your Professional Services Representative to obtain a copy of the source files.

As an alternative to changing the existing help, you can add a Tip Page tool to a specific page and specify a URL to be called when the tool is clicked. Though this page would not be part of the help system as a whole, it is a method to provide additional information to end users about specific pages. For details, see the Tip Page entry in Settings for Tree Menu Objects.

You can make minor content changes--such as changing a term, adding a step to a procedure, or replacing an image--to the output files for both types of documentation. For example, suppose you customize the application by changing a term (replace the word "originator" with "creator"), changing the labels on buttons or links, changing the title of a page, or adding an additional field on a page. You can edit the online help and/or the user guide to reflect these kinds of changes in an application but keep these things in mind:

• You must make the changes to both the pdf and help.
• Maintaining the documentation may be more difficult when you receive a new version of the software with its documentation from ENOVIA because you will have to make all the changes again to the new output files. If you do not track the changes you make, this could be very difficult.
• The new or changed information will not be included in the search and index features. For example, if you add a new term to the help system, the index and search features will not recognize the term so users will not be able to find the information you added except by browsing through the help system.

The best way to determine which strategy is best for you is to consider how extensive your changes are. If you can make a short list (maybe 6 or 7 items) of exactly what changes need to be made to each set of output files, then changing the output might be acceptable. You can keep this list and when you receive a new set of documentation files, implement these few changes again. Also remember to evaluate how serious it is not to have new or changed terms in the index or search.

Many of the applications regularly send notifications to users to inform them of important assignments and changes to objects that they own.

Users receive these notifications in their IconMail inbox and, if email is configured for the user, at the email address specified for the user's profile. Your system must be set up to use SMTP for email transmissions if you want notifications to be emailed to users.

The content for these notifications is stored in the emxFrameworkStringResource.properties file (and the equivalent file for each language). Each message has a "tag" for its subject and text, followed by the content to use when constructing the message. For example, the tags for the "new owner" messages in English are:

emxFramework.Beans.DomainObject.NewOwnerSubject=New owner of '<type>' 
'<name>'.

emxFramework.Beans.DomainObject.NewOwnerMessage=You are the new owner 
of '<type>' '<name>'

If your company needs custom messages, you can edit these messages. Each standard mail message tag can have additional tags created that append the company name, with no whitespace. For example, a "new owner" message subject tag for Acme Company would be named:

emxFramework.Beans.DomainObject.NewOwnerSubject.AcmeCompany

When sending the notifications, the system always looks for company-specific messages defined for the current user's company. (The system uses the company connected to the person's business object.) If the system does not find company-specific tags for the messages, it uses the standard message.

See Configuring Notifications and Messages for instructions.