Checkin/Checkout Concept

Table Of Content

Goal

The checkin/checkout concept allows to, automatically or manually, lock an RPMObject prior to updating its content. The web service API adds its own layer on top of the RPM checkin/checkout functionality.

RPM DB modifications

The WEBAPI_SESSION_MONITOR table has been altered to add the AUTOMATIC_CHECKOUT column. This column (boolean value) specifies if the related session is in automatic or manual checkin/checkout mode

The WEBAPI_SESSION_CHECKOUTS table has been created and added to the RPM DB to manage each checkouts for every WS-API sessions. This table has 5 columns:

  1. RPMOBJECT_CK_ID: represents a unique ID generated from the RPMObjec ID.
  2. SESSION_ID: represents the SESSION_ID owner of this checkout.
  3. RESOURCE_ID: represents the Resource ID who created the session.
  4. RPMOBJECT_CLASS: contains the string representation of the checked out RPMObject.
  5. TIMELESS_CHECKOUT: shows if the checkout is timeless.
The SessionCheckoutsDAO class is responsible for querying and updating this table.

Automatic and manual

Automatic checkin/checkout mode is the default mode and hides all the complexity of checking in and out all required RPMObject for any modifications. When the automatic mode is disabled the WS API session falls into manual checkin/checkout mode, where each required RPMObjects prior to any modifications must be checked out based on the checkout mode type from the Rational Portfolion Manager Web Services API Guide.

Timless checkout vs session timeout and logging out

When the automatic checkout mode is disabled, every checkout call requires a boolean isTimeless that indicates if the checkout will remain after the user logs out or if the RPM WS session times out. When a checkout has isTimeless to true, the rules are, the requesting resource ID must be the same and in:

Again in manual checkout mode type when the isTimeless flag is set to false, if the rpmObjec is not checked in, the checkout rpmObject will automatically be checked in once a user logs out (or if the session times out), this way we avoid leaving an object checked out for an undetermined period of time.

Checkout mode type

The CheckoutModeType is defined for every container in the metadata. There are three CheckoutModeType:
  1. None: No checkin/checkout required
  2. Parent: In order to modify this RPMObject, the parent CheckoutModeType must be looked at.
  3. Self: Prior to updating this RPMObject it must be checked out and then checked in.

The default CheckoutModeType is "None" and is defined in the RPMObject metadata info, and this property is inherited by all children. Every RPMObject can set this property to any of the value described previously

API related methods and prerequisistes

checkIn

prerequisistes

checkOut

prerequisistes

disableAutomaticCheckoutMode

Deactivate the automatic checkin/checkout mode.

prerequisistes

None

enableAutomaticCheckoutMode

Activate the automatic checkin/checkout mode.

prerequisistes

None

forceCheckinOnRPMObjectCheckOut

The RPMObject is checked in without validating if the RPMObject was checked out by this user. Eventually, this method should validate if a certain user has the rights to do so. For the moment only the owner of this RPMObject checkout is allowed to break it.

prerequisistes

forceCheckinOnSessionsCheckOut

All checked out RPMObjects belonging to this session will be checked in. Eventually, this method should validate if a certain user has the rights to do so. For the moment only the owner of this session is allowed to force the checkin.

prerequisistes

forceCheckinOnUsersCheckOut

All checked out RPMObjects belonging to this user will be checked in. Eventually, this method should validate if a certain user has the rights to do so. For the moment only the user itself is allowed to force the checkin.

prerequisistes

isCheckedOut

Indicates if the RPMObject is checked out, either from the RPM Client or through the WS API.

prerequisistes

Concurrency between RPM API and RPM Client

One major idiosyncrasy of RPM checkin/checkout model is the existence of two ways to handle checkouts. The first one it through the RPM client and the second one is through the RPM WS API. The WS API is aware of the checkouts made by the client and is able not to override them. As opposed to the RPM client which considers all checkouts as if they have been made by the RPM client. The consequences are, if a user checks out an RPMObject from the WS API, the same user can checkin the RPMObject from the RPM client. However the opposite is not true, meaning that if a user checks out an RPMObject from the RPM client, the same user will not be allowed to check in the RPMObject from the WS API.

Checkin/Checkout Validation

Validation is done through the ManualCheckinCheckout class. Most of the validation methods requires the isCheckedOutFromRPM and isCheckedOutFromSession parameters. The isCheckedOutFromRPM parameter indicates wether REC_STATUS is set to checkout in the corresponding table for the RPMObject (e.g. TMT_CRI for a ScopeElement). The isCheckedOutFromSession indicates if the RPMObject was checked out through the WS-API . As noted in the Concurrency between RPM API and RPM Client section there's a side effect in the validation depending on the context in which the checkout was made.

Modifications to the RPMObjectManager Structure

The new methods in the RPMObjectManager are: