A Production Implementation of Intralink

1
A Production Implementation of Intralink
2
All Systems Implementations are initiated by the
customers need to solve problems.

• Typical problems inherent to manufacturing
  facilities and Pro-Engineer use are the need for
• Configuration Management
• Secure Master File Storage
• Release Management
• Revision History Tracking
• Attribute Tracking and Querying

3
Some key elements to a successful implementation
are

• Properly configured dataserver hardware.
• Early determination of custom Object Attributes
  and necessary release levels.
• Weighing storage and retrieval speed against
  devised folder structure.
• Intuitive folder structure, release levels, and
  attributes.
• A simple, but secure authorization scheme.

4
other key elements to a successful
implementation are...

• Detailed Testing of User Role authorizations.
• Customer Training and Functional Approval.
• I recommend custom training exercises that
  simulate all production scenarios.
• NOTE Users should functionally approve the
  methods used in the production exercises.

5
How did Stryker Instruments meet these key
elements?

• Planning and Testing.
• Assessment of test results.
• Training and Functional Approval by users.

6
Looking at the Details on the Key Elements...

• For the Dataserver Hardware
• Dell PowerEdge6300 with dual 400MHz Zeon
  processors, RAID5, and 512MB RAM.
• The more processors the better. Oracle is
  multi-threaded.
• Hot-swappable disks at RAID5 highly recommended.

7
Custom Object Attribute Recommendations

• Ask customers for the attributes they want and
  need.
• Make a list of the custom attributes and
  determine population method and type.
• NOTE There are tradeoffs in the choices for
  attribute types.

8
The Object Attribute Definition Choices are

• Versioned, non-filebased, not lifecycle
• can differ from version to version, not coming
  from Pro-E file, only set in WS, therefore
  requiring another version of the file be checked
  in to CS.
• Versioned, non-filebased, lifecycle
• can differ from version to version, not coming
  from the Pro-E file. Can be changed in the CS for
  a particular version without checking in another
  version from the WS.
• Versioned, filebased, not lifecycle
• can differ from version to version, attribute
  comes from Pro-E file, and requires check in to
  CS.
• Non-Versioned, non-filebased, not lifecycle
• set it and it changes for all versions of object,
  only set in CS not WS.

9

• Versioned, non-filebased, not lifecycle
• Versioned, non-filebased, lifecycle
• Versioned, filebased, not lifecycle
• Non-Versioned, non-filebased, not lifecycle
• For Stryker Instruments, I went with versioned,
  non-filebased, lifecycle attributes, because
• Our Pro-E models did not have the needed
  attributes.
• I did not want to have to generate a new file
  version in order to change a parameter.
• Lifecycle allows for typing errors to be fixed
  from the CS while the file is still a work in
  progress.

10

• Object Attribute recommendation
• Use pull-down lists to avoid non-consistent
  terminology.
• Enhancement needed
• The ability to set an object attribute as not
  NULL.
• Without this ability you cannot ensure that all
  the necessary fields are being filled with data.
  The system will not stop the user without a not
  NULL flag in the database.
• Out of the box, Intralink currently uses not
  NULL for the folder field and prevents check in
  if a folder has not been set. PTC CAN DO THIS!

11
Release Levels identify object status and allow
for authorization based on the status.

• As an example, I use the following release levels
  at Stryker Instruments
• In Progress
• In Approval
• Released
• Obsolete.

12
In Progress Role
13
In Approval, Released, and Obsolete Roles
14
My Authorization Scheme Goals were

• To create a secure, but easily administered
  authorization scheme.
• To eliminate the users ability to inadvertently
  mess up configurations by
• disallowing delete, override RTP, forced
  check-ins, creating branches, or editing folders.
• Also employing a Release Procedure to prevent
  demoting in the CS (security hole plugged).
• If demoting was allowed in the CS, users could
  take an object that was previously Released
  back to In Progress without generating another
  version (the security hole).

15
Sample utilization of Release Levels and Roles
as authorizations for folders.
16
Sample use of Release Procedure to prevent
demoting in the CS (only admin votes, set a top
level of folder structure).
17
Optimizing Storage and Retrieval

• Fileserver recommendations continued...
• Create a storage cluster for every major
  directory of your folder structure to distribute
  the quantity of files that can be contained in
  any one directory (I.e. any one filevault).

18
(No Transcript)
19
If filevault directory starts to exceed a
reasonable size

• Make an new filevault using the DSMU and attach
  it to the folders cluster.
• Make the existing filevault for the folder
  read-only so that it will not continue to grow in
  size.
• The system will default to start writing to the
  new filevault directory.

20
Remember, Intralink meets the needs of the
Pro-Engineering workgroup by providing

• Secure vaulting
• Configuration management
• Release management
• Revision history
• Attribute storage

How you implement and configure the software, as
well as, the training of your user base are keys
to how the system will perform and how easy the
system is to use for both the administrator and
the users.
21
Important Usage Enhancements are still needed!

• Cannot go backward in revision sequence to fix a
  mistake, you must remove object version from
  database which messes up baselines. (enhancement
  s 10683,10283,7946,10976)
• Object attributes are semi-worthless if you
  cannot set them to be not NULL (4411,10975).

22
Important Usage Enhancements Continued

• Lack of customizable, administrative reporting
  tools for watchdog type AT jobs (enhancement
  10681,10973).
• Out of the box system attributes should include
  last modified by and last modified on, which
  would reflect only attribute changes to the
  object, but not check-ins of object versions as
  tracked by checked-in by and checked-in
  on.(7787,10974)
• If you agree with me on these needed
  enhancements, email me at the address on the
  enhancements handout and Ill send you an
  electronic copy of the enhancement that you can
  cut and paste into a Web Enhancement form.

23
Questions?