Package wt.vc.wip

See:
          Description

Interface Summary
WIPChangeDelegate Interface to check whether checked out copy has been Changed.
Workable Provides an abstraction of a plug-and-play component.
WorkInProgressService Provides server-side functionality as a service that's remotely available for use by a client.
WorkInProgressServiceSvr

Supported API: false

Extendable: false
 

Class Summary
CheckoutInfo Holds WIP state as a cookie for client-side operations.
CheckoutLink Provides the link between an original checked out object and its working copy.
CheckoutLinkCleanupMigrator Delete orphaned CheckoutLinks.
StandardWorkInProgressService Provides the standard implementation of server-side functionality as defined by the WorkInProgressService interface.
WIPChangeDefaultDelegate Specific delegate for checking whether passed WTObject has been changed.
WIPChangeFactory This will return delegate corresponding to the requestor object as given the typedServices.properties

Supported API: false

Extendable: false
WorkInProgressConflictType

Supported API: true

Extendable: false
WorkInProgressHelper Provides the Work In Progress (WIP) service's Application Programming Interface (API).
WorkInProgressResolutionType

Supported API: true

Extendable: false
WorkInProgressServerHelper

Supported API: false

Extendable: false
WorkInProgressServiceEvent Provides a service specific event extended from KeyedEvent used in conjunction with the standard implementation of the server-side functionality as defined by the WorkInProgressService interface.
WorkInProgressServiceFwd Provides server-side functionality as a service that's remotely available for use by a client.
WorkInProgressState The valid set of work-in-progress states that a workable object can exist within.
 

Exception Summary
NonLatestCheckoutException

Supported API: true

Extendable: false
ObjectsAlreadyCheckedOutException

Supported API: false

Extendable: false
WorkInProgressException Provides an abstraction of an abnormal occurrence or error in the usage or processing of the WIP service.
 

Package wt.vc.wip Description

vc package - Work in Progress Service

The work in progress service (wt.vc.wip package) provides functionality to perform Work In Progress (WIP) on workable objects, generally known as checkout and checkin, or undoing of a checkout.

Design Overview

Work in Progress Model

The WIP service is designed to be a plug-and-play component in the Windchill system, which is by default enabled to execute.

The WIP service is intended to be used for both client and server development. Business objects asserted as being Workable (Iterated, Lockable, and Ownable) in the object model can be checked out and then either checked in or undone from being checked out. When an object is checked in, it exists in a vault. When it is checked out, it is outside the vault. The protection from modification that is offered information is somewhat different when it is inside the vault versus when it is outside the vault.

When a checkout occurs, the original object is locked, and a working copy is made from the original and linked to it via the CheckoutLink If the Workable is instance of Foldered then the working copy is placed in the user's Checked Out folder (in the default implementation). By being placed in the user's Checked Out folder, the user becomes the owner of the working copy with the access rights that have been established for it. If the Workable is not foldered, the working copy is moved to the USER domain and the user owns it. The working copy is considered an exact duplicate of the original (that is, it has the same attributes and associations). For example, if iteration 5 of version B is checked out, the working copy is iteration 5 of version B.

Upon a checkin, the original object's latest iteration is superseded with the working copy and its identifier is incremented to the next adjacent value in the series. Given the checkout example above, the checked in object would now be at iteration 6 of version B. Mechanically, a checkin can be done from either the original object or its working copy. The system will understand what is meant and perform the checkin. When the checkin completes, the lock on the original object is released and the working copy is removed from the checked out folder.

Upon an undo of a checkout, the working copy is deleted along with the link to the original object. Additionally, whenever the checked-out original object or working copy is deleted, the checkout is undone automatically.

External Interface

The Workable interface provides an abstraction of a plug and play component. The intent is that, in an object model, a business object would assert that it is Workable by inheriting (that is, to implement) the Workable interface. With this assertion, the business object can then be checked out and checked in.

The WorkInProgressHelper provides an abstraction as the API to the WIP service. The API's methods can be categorized as either local or remote invocations. The local methods are getters of information, typically from cookies that are held in the business object. The remote methods serve as wrappers to a service that promotes server-side functionality.

The WorkInProgressService provides an abstraction that specifies and promotes server-side functionality as a service that is remotely available for use by a client. The intent is that this interface defines all the necessary server-side functionality for WIP. The WorkInProgressServiceEvent provides an abstraction of a specialized keyed event used by the WIP service to signal other services that a WIP activity is about to begin or has occurred. This gives other services the opportunity in a plug and play architecture to act accordingly on these events. Validation, vetoing, and post processing are typical reactions to events.

The WorkInProgressException provides an abstraction of an abnormal occurrence or error in the usage or processing of the WIP service. This exception can be localized through a given resource bundle and other exceptions can be nested within it. The most common occurrences of this exception is when an attempt is made to check in/out a business object but it already is checked in/out, and when used incorrectly during a database modification, deletion, and navigation.

The WorkInProgressState provides an abstraction of the valid set of work-in-progress states that a Workable object can exist within. The three supported states are checked out, checked in, and working.

Business Rules

As defined by the standard WIP service's access control rules, since a Workable object is asserted as being Lockable, the service relies on the locking service for applicable access control. Additionally, when an object is checked out, neither the original checked out nor working copies can be checked out again.

Event Processing

Event-based processing is performed on business objects asserted as being workable during database storing, [preparation for] modifications, deletions, and folder changes.

When a business object is being stored in the database, the WIP service listens to a dispatched event indicating that the store is about to begin and initializes the state of the object to being checked in if and only if its checkout info cookie is null. Since a workable may also be a Foldered, the WIP service listens to a dispatched event indicating that a store on a cabinet has successfully completed and checks if the cabinet exists in the user domain (that is, a personal cabinet) and, if so, stores a checkout folder in that cabinet.

When a business object is [prepared for] being modified in the database, the WIP service listens to a dispatched event indicating that the modify is about to begin and vetoes it if either of the following conditions are true:

Otherwise, the WIP service allows the modification to take place.

When a business object is being deleted in the database, the WIP service listens to a dispatched event indicating that a deletion is about to begin and undoes a checkout if the object is checked out or a working copy of a checked out object.