Data Models for Business Process Services | ||
| ||
Profile Management
This graphic shows the data model for profile management.
This graphic shows the organization type hierarchy associated with profile management.
This graphic shows the skill management data model associated with common profile management.
Uploading/Checking In Files
When a user uploads one or more files (for example, into a Book in the case of Library Central), the system creates a Document business object and uploads files into it (that is, a root or holder object for all the files being uploaded). For each file being uploaded, it creates a Document business object with the "Is Version Object" attribute set to true and the "Title" attribute set to the name of the file. These Document objects are connected to the root Document object with the Latest Version and Active Version relationships. These relations both have a 1:N cardinality. In this graphic example, the names of the Document types are auto-generated.
File Version
To create a version of a file, a user checks out the file from the Document object by locking it, makes changes and checks it back in. Since the root Document object is not locked, other users can work on the remaining files concurrently.
When the new version is checked in, the system revises (using the core revisioning mechanism) the corresponding Document (Version) object and updates meta data like "Description" and "Title." Files in the Master are moved to the earlier version of the Document (Version) and the latest file version is checked into the Master object since the Latest Version, Active Version relationships are floated on revision at the Document (Version) end. The core handles relationship connects and disconnects.
Revising With Files
When the user chooses this option, the system revises the root Document object, clones the connected Document (Version) objects (using Active Version relationship) and connects them to the revised Document.
Revising Without Files
When the user chooses this option, the system revises the root Document object and does not bring forward (clone and connect) the Version objects.
Deleting Files
Users with proper access can delete active file versions. In this case, the system deletes the file from the Document object and moves the latest version of the file into the Document object (from previous Version object). Also, it deletes the corresponding Version object and connects the previous Document (Version) object with Latest Version and Active Version relationships.
This process can be done using a JPO trigger.
Workflow
This graphic shows the data model for workflows.
The Deliverable Types can be any of these types:
- CAD Drawing
- CAD Model
- Document
- Drawing Print
- ECO
- ECR Engineering Change
- Issue
- Markup
- Part
- Part Family
- Part Specification
- Product Line
- Sketch
Teams
This graphic shows the main data model for teams (workspaces).
* These objects are owned by another application.
Objects highlighted in yellow and bold text have been renamed but their symbolic names continue to reflect the original name. For a list of the symbolic names, see Renamed Administrative Objects.
Role Type Inheritance
This chart illustrates the type inheritance for roles. The standard job-related roles that are not children of Customer or Supplier are children of Employee. To see all child roles of Employee, use Business Modeler to expand the Employee role in the indented browser. The roles not included in this type hierarchy are system administrative roles such as System Conversion Manager, System Transition Manager, and Access Grantor.
When a Semiconductor Accelerator is installed, the role hierarchy looks like this:
For a description of roles, see Roles.
Change Type Hierarchy
This graphic shows the type hierarchy for change objects. The PSBASE type is only available with the ENOVIA Semiconductor Accelerator for Team Collaboration.
