| Agile Product Lifecycle Management Administrator Guide Release 9.3.3 E39286-04 |
|
 Previous |
 Next |
| Agile Product Lifecycle Management Administrator Guide Release 9.3.3 E39286-04 |
|
Previous |
Next |
This chapter discusses how to configure Agile PLM to handle design objects.
As with other areas of Agile PLM administration, the most important step comes before setting properties in Administrator. This chapter assumes that you answered the first question in the previous chapter affirmatively.
Does your company produce CAD design and graphic files? If so, you will build from the Designs class.
The Designs class is a business class in the File Folders base class.
Objects created in the Designs class have many of the same properties and behaviors of File Folders. The Designs class is enhanced for use with the Engineering Collaboration (EC) solution; therefore, this chapter highlights those differences. Chapter 37, "Administering Attachments" contains foundation details about the File Folders base class.
Deployment of Design structures in Agile PLM requires an Agile EC integration. That is, full use of CAD design graphics files needs an integration application that can automatically check out and check in Designs objects, track and update parent-to-child versioning of design structures, and so forth. Contact your Oracle Consulting - Agile Practice representative for additional information about Agile EC.
The Designs class supports structures between Design objects with explicit versions—let's call these "design structures"—and it supports integration with CAD tools. The Design object is very similar to File Folders, but has a few "extras" and specific features to realize its intended purpose.
The Designs class overcomes limitations that have existed in PLM using Documents class and the "DocuBOM" data model, which were not expressly designed for CAD use-cases. Three primary issues are resolved with design structures:
Structure Resolution is easily captured
"Structure" information between designs can be captured, as required by CAD environments, while the "DocuBOM" structure does not directly support fixed structure resolution.
Data Navigation is greatly enhanced
Structures of Designs objects are evident and easy to navigate, while the combination of Part-and-Document BOMs are difficult to navigate in the Agile user interface.
Change Control Process carries much less "overhead"
The full change control process (in the Product Collaboration solution) has too much overhead for many CAD use cases.
Although the Designs class is enabled in new installations, it is disabled upon PLM upgrade: in upgrading installations, the Agile administrator must enable the Designs class.
Besides the benefits to CAD environments mentioned above, additional benefits are:
Easy recognition of CAD data in PLM; CAD data will "look" more like it does in CAD
Users can "double-use" part names since Designs and Parts are separate classes of objects
Searching for design objects will be easier for CAD engineers
Using a single object has several advantages:
Change history is on the Design object instead of on a separate Change object
Design files are not in a separate "file folder"
Version-specific Where Used
Version-specific Routing Slip
Designs class enables the next version of Agile Engineering Collaboration, which will capture and exploit the capabilities built into the PLM model structures.
The Design object can be opened from Java Client, but it opens Web Client and the user works with Designs exclusively in Web Client.
There is a Checkout button, and modifications to a design structure cannot be done by a user without checking out the design.
Since a "parent" version of a design explicitly points at a "child" version, a user has to check out a version, update the children, and check it back in for the parent to reflect the changes. In CAD there can be multiple models for 1 part—there could be, for example, 20 or 30 versions of a single object—but in Product Collaboration the part is assigned to a single structure; moreover, the system lets you check in a "design structure" without checking in all child parts.
Now, those engineers who have "child" parts checked out must check that part back in, that is, he cannot "Cancel Checkout" for the part to "rejoin" the BOM. Attempting to do so will throw the error message: "This version is in use and cannot be canceled."
A feature of the Version drop-down list is that the checked-out version is incremented and displayed in brackets, for example [4], so the user can always see what the new version number will be when the object is checked back in. This applies to both File Folders and Designs classes.
On the standard Actions menu, the most significant added Action is View All Versions. The View All Versions action is available in File Folder and Design objects.
The View All Versions utility is extremely useful as file-folder structures or design structures grow, as it tracks the versions of each design or file folder. Each version displays:
Approved (users who have approved file folder or design in workflow), including the Awaiting Approval icon (users who have not yet approved);
Checkin Date;
Checkin User (which captures the user who checked in the version, and also can read through to the design Structure tab and to Attachments tabs in designs or file folders);
Change Info and Label (as filled in by users); and,
Revision and Revision Date.
Many of these fields are pulled from the object's Title Block tab.
Using the View drop-down, you can have a quick View of a selected version of the design, or select two versions and Compare them visually.
The tabs on Designs objects are: Title Block, Files, Structure, Routing Slip, Relationships, Where Used, and History. Most of these are given a look in the sections below; Relationships and History tabs are documented in Getting Started with Agile PLM.
By default, the Design object Title Block tab contains the fields listed in the following table. The administrator determines which fields are enabled and visible on the Title Block tab.
In Web Client, the Title Block can contain two additional sections, called Page Two and Page Three by default. Agile administrators can add custom class fields to Page Two section and custom subclass fields to the Page Three section. The Agile administrator determines whether these sections are enabled, and what they are called.
Table 38-1 Title Block tab fields
| Field | Description |
|---|---|
|
Number |
The Design object's number, completed when the file object is created. |
|
Type |
The subclass of this Design object. Depending on Agile system settings, this field is automatically completed when the Design object is created. |
|
Lifecycle Phase |
Current lifecycle; selected from a list. |
|
Description |
Text describing the Design object |
|
Version |
The currently selected version of the Design object |
|
Last Modified Date |
Date the Design object was last modified |
|
Checkout Status |
Indicates whether the Design object is currently checked out or checked in. |
|
Checkout User |
When the Design object is checked out, displays the user who checked out the Design object |
|
Checkout Date |
When the Design object is checked out, displays the checkout date |
|
Checkout Location |
When the checkout user's File Productivity Preference is set to Advanced, the checkout location is automatically filled in |
|
Checkin Date |
When the Design object is checked in, displays the checkin date |
|
Create Date |
The date the Design object was created |
|
Label |
Version-specific text field that holds a specified label |
|
Component Type |
Displays the type of component represented by the Design |
|
Thumbnail |
Displays information about thumbnail graphics in Design objects; whether it is enabled or not is determined by the systemwide Preference Thumbnail Support and the User Preference settings. |
|
Revision |
Version-specific text field that holds the targeted revision of the Design version |
|
Revision Date |
Version-specific date field that holds the revision date associated with the Design version |
|
Checkin User |
Version-specific field indicating the user who checked in the currently selected version; completed automatically |
The actions available on Designs Files tab are generally the same as File Folders Files tab. Similarly, privileges around the Files tab of both kinds of objects will mostly be the same; however, for best control of user access, privileges should not be based on the File Folders base class, which will apply to the Files tab of both File Folders and Designs class objects.
In order for the end-user to execute Files tab actions for Design model objects, he must have the appropriate Modify privilege masks. Refer to "Attachment Privileges", especially "Modify Privilege and Attachments": see the section of the table for File Folder Attachment Actions.
|
Note: If you are using privilege masks based on the File Folders base class, assigned users will have the same Modify, Checkin, Checkout (and so forth) capabilities for both File Folders class objects and Designs class objects. If you need to give users separate types of access to these two classes, you must create and define privilege masks based on the File Folders class (or subclasses) or the Designs class (or subclasses). |
The Designs Structure tab supports "read-through" fields from Designs Title Block tab or Page Two.
Like the Files tab, the Structure tab can only be edited when the object is checked out.
In Structure, the parent explicitly specifies the version of the child.
The Multi-level drop-down enables you to Expand or Collapse the structure.
AutoVue for Agile supports Designs Structure tab and File Folder Attachments tab.
File Folders (objects from File Folder and Markup subclasses) do not have a Structure tab, and they cannot be in a model structure. On the other hand, where you can use an "attachment" (that is, a file folder object), you can use a Design.
Icons indicate whether a Design is:
Checked out
Attached
Latest Version
Has Attachments
The Routing Slip tab is functionally "version-specific". Signoff on the Design object only signs off that specific version of the object.
Adding and removing Approvers and Observers can be done only when Design objects are checked in. To add or remove approvers and perform signoff actions, the user needs the appropriate privilege masks for Design objects.
This section collects various Administrator settings for convenience. Refer to node-specific chapters for more information about the capabilities in Administrator.
The SmartRule Display Structure Tables offers the choice between No Display (appropriate for non-CAD business environments) and Display. See "Display Structure Tables."
The SmartRule Copy File to Rev - Designs offers three setting choices: Disallow, Reference, and Reference with Warning. See "Copy Files to Rev - Designs."
Design Engineer is a Role tailored to create, access, and manage Designs class objects.
Privileges and privilege masks around the Designs business object use the Agile PLM Discovery and Read model, including on the Structure tab.
To add or remove approvers and perform signoff actions, the user needs the appropriate privilege masks for Design objects.
When working in conjunction with a CAD-to-Agile PLM integration application, each CAD user must also be an Agile PLM user. Each CAD user must have appropriate PLM roles and privileges to allow him to perform Checkout, Modify, Checkin (and so forth) actions on Design model objects. Contact your Oracle Consulting - Agile Practice representative for additional information about CAD-to-Agile PLM integration applications.
|
Note: Remember that privilege masks written at the File Folder base class level will affect both the File Folders class (File Folder and Markup subclass) and the Designs class (Design subclass). Privilege masks tailored for CAD environments should be entered at Designs class level. |
