Check in DesignSync Files

For DesignSync files and folders, FCS supports the two-part checkin. This includes getting a ticket from the MCS, then executing a checkinStart and then executing checkin and checkinEnd.

For information on two-part checkin, see "Two-Part Checkins" in the FCS Guide.

The following diagram illustrates two-part checkin of a DesignSync file:



When checking in files to a DesignSync store, check and action triggers are supported. Macros available to these triggers include VCINDEX, which contains the index number of the vcconnection (the connection associating the business object to the DesignSync file). The index number provides all other information about the connection including the format and filename. Therefore, the checkin event macros FORMAT and FILENAME are not available in this case.

The following information is required to check in a vcfile:

  • The VERSION of the file. Checking in a new file or a newer version of a file succeeds only if the version of the file is specified as: branch:Latest or by no qualifier, (which is interpreted to mean Latest) or a selector which resolves to a branch and the latest version on it.
    Note: Check in fails and returns an error if you checkin a new physical file to an existing file in the DesignSync server where the version specification does not resolve to branch:Latest.
  • An optional comment describing your check in. If provided, it gets associated in DesignSync with the version of the file you are checking in.

All vcfiles that get checked in get an auto-generated CHECK_IN tag. This tag is returned to the FCS and to the MCS via the receipt.

When you check out a vcfile, it is locked by the DesignSync server. If other users try to check out the file, they are displayed a warning. The business object connected to the file remains unlocked.

For information on how to write a client that performs two part checkin of a vcfile, see Write Two-Part Checkin of Vcfile and Vcfolder.