<< Click to Display Table of Contents >> Navigation:  Advanced Features > Briefcase > Briefcase in details

Briefcase: an example in detail

Strategy

Prerequisites

Remote Access Mode: mandatory

Key fields involved in the briefcases exchange process:
CHECK_OUT_BY
COMPANY_ID
OWNER_COMPANY_ID

Main goal

A company wishes to use external designers as an extra resource for producing machines

Scenario

Naming conventions:
Designer: a designer internal to the company
External Designer: a designer external to the company

For the sake of brevity and clarity we consider an internal designer and an external designer to describe the process.

INTERNAL DESIGNER SIDE

The designer wants to select some documents in order to have them been inserted in the briefcase and sent to the external designer for editing.
This action is called ‘Put into the briefcase’.

To achieve this goal:

•the designer must know the COMPANY_ID of the external designer, and must specify this information when creating the briefcase

•documents must be reserved by the designer (check-out) in order to avoid any internal modification on them before the modified documents come back from the external designer

•if the state of any selected document is still not checked-out, MechworksPDM will check them out before creating the briefcase

•Options are available for sending or not sending standard parts, related drawings, generic documents, not managed documents

•Documents not checked-out and not selected will be sent as reference documents

After the Briefcase creation:

•In the briefcase .mdb database, records checked-out by the designer that currently is creating the briefcase zip file have the field OWNER_COMPANY_ID filled with the pair <COMPANY_ID>\<CHECK_OUT_BY>, in order to store the information needed to get the briefcase back from the external designer

•in the main MechworksPDM internal database, the same records has the field OWNER_COMPANY_ID filled with the value of the destination external designer COMPANY_ID

EXTERNAL DESIGNER SIDE

The external designer receives with any media transfer protocol the .zip file of the briefcase.

He invokes the ‘Get from briefcase’ functionality, that implements the following strategy:

•all documents not in checked-out state are loaded without any change in the COMPANY_ID field, so becoming foreign documents for the MechworksPDM database of the external designer; those documents cannot be modified, but can be used as references

•for the reference documents, the file and record local copies are always overwritten in the external designer installation, to make sure that every information is up to date.

•the documents marked by the sender as modifiable are already assigned to the destination COMPANY_ID (the external designer one); the CHECK_OUT_BY field are changed with the user currently loading the briefcase: this user is allowed to modify the files

•every record received by the main company for modifications still has the OWNER_COMPANY_ID containing the pair <MAIN COMPANY ID>\<ORIGINAL CHECK_OUT_BY USER>

When the assigned job is finished, the External Designer creates another briefcase to be sent back to the main company designer.

This briefcase contains only the modified files; after creating the briefcase, the records of the modified documents have the COMPANY_ID changed back to the original COMPANY_ID, so becoming again foreign documents for the External Designer MechworksPDM installation.

The returned briefcase does not contain records with a not null OWNER_COMPANY_ID, making sure that the database is fully loadable by the internal designer with a ‘Get from briefcase’ command.

Example:

PUT

Put the above document in the briefcase, destination company id = MechWorks:

GET

The company MechWorks receives the briefcase; the external designed Ciro is assigned to the modifications; he loads the briefcase:

After finishing the job he creates a new briefcase to send back the work already done:

Supported Document States

Documents sent back from the External Designer can be in CHECKED_OUT or CHECKED_IN state.