FORAN Lock Restrictions on Windchill Actions

When Interim Product parts are locked in FORAN, Windchill will display the locked icon

, indicating that the objects are also locked in Windchill. The lock is applied only for Interim Product parts, and not for Design Solution or Configuration Item parts. The following actions for Interim Product parts are not available to the Windchill user when these Parts are locked in FORAN:

• Check Out and Edit

The Windchill Multi-Repository Lock Mechanism ensures that an administrator can perform a Windchill Lock to a System, and provides for a method for a Windchill Administrator to release the shared Lock, when appropriate. The Multi-Repository Lock Mechanism manages the import of objects under a Lock, and carries the Lock onto the imported iteration.

To prevent changes on the same portions of the structure from Windchill as well as FORAN, no modification is allowed on such affected objects on Windchill side. This applies only for Interim Product parts, and not for Design Solution or Configuration Item parts.

All the structures considered for the Multi-Repository Lock Mechanism must be the latest information in Windchill and FORAN. Windchill itself does not have to request a Lock, since the structures reside in Windchill. The characteristics of the Multi-Repository Lock Mechanism operation are as follows.

• FORAN selects a specific node in the tree and requests that it be locked in Windchill. FORAN then sends all the child nodes, as well as the node selected, to be locked. The node(s) can now be considered to be “shared” with Windchill.

• Upon a successful shared checkout on the Windchill side, FORAN establishes the lock to allow that portion of the structure to be updated. Windchill approves the request for a lock, even if all the requested objects are not the latest versions. In this case, Windchill suggests that FORAN do a Synchronize operation.

• FORAN sends a new update for all or some of these locked objects.

• Windchill imports the update by creating new iterations and carrying forward the Shared Lock.

• Eventually FORAN terminates the lock, after which all the objects have the Shared Lock taken off.

• A lock on behalf of the repository notion for a collection of objects is integrated with a “Shared Actions” framework; namely, all or nothing gets locked out. A lock cannot be held for more than one repository simultaneously for the same object version. It is assumed that these objects would exist in Windchill – if they are nonexistent, then Windchill assumes that the incoming object is New.

• A query can be run to check for the existence of lock for a given objects, a repository, etc. The query generates a report for the administrator, containing information on all objects locked on behalf of a certain repository.

• An Info*Engine task based web service can be used that allows FORAN to create/release such a lock.

• If the object is being updated during publishing to Windchill, it must be locked by FORAN.

• The notion of a shared checkout for WTParts and its subtypes is shown in the Windchill UI by an appropriate status on the Details page. Actions that validate against the shared checkout status – such as WIP/PDM checkout, Add Representation, Edit BOM, Rename, Revise, Delete, etc.– are disabled if the object is checked out to a remote repository.

Beginning at Windchill 10 M010, if the user updates a Windchill 10 server (of Windchill 10 M010 or greater) to Windchill 10.1 (of Windchill 10.1 M010 or greater), the Multi-Repository Lock Mechanism will not be carried forward for IP parts, since the Federation Lock is implemented in Windchill 10.1, wherein the lock is specific to the repository.