|
|||||||||||
PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES |
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. |
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.
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.
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.
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-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.
|
|||||||||||
PREV PACKAGE NEXT PACKAGE | FRAMES NO FRAMES |