Introduction
Top  |
|
CMT Remote Server (Master Repository) |
|
|
Introduction |
|
|
This document assumes you are familiar with CMT functionality. If not, please see CMT Overview for more information.
When Change Control is deferred to a Master Repository, the Check Out and Check In operations manage SDIs on both the local server and the Master Repository. This lets you Check Out SDIs from the Master Repository to the local server, make changes locally, then check the SDI back into the Master Repository. While checked out to the local server, the SDI is protected on the Master Repository.
Any new SDIs created on the local server can be exported directly to the Master Repository using the Check In operation.
CMT Remote server functionality promotes global development in the following ways:
| • | Allows multiple developers to work on the same configuration simultaneously (regardless of time zone), then package those changes into a single build. |
| • | Easily move changes between systems. |
| • | Update the local system to synchronize with the Master Repository. |
| • | All changes are tracked by CMT. |
| • | View comparison SDI Snapshots between the local system and the remote server as well as view the history of changes made on the Master Repository. |
Following is a high level overview of global development using a remote server:
Configuring the Remote (Master Repository) Server |
|
|
Webservice access is required to perform Check Out, Check In, and transfer actions on the Master Repository.
In the Master Repository, set the CMT Policy property Global Enable Change Control to "Yes". Change Control is enabled on the Master Repository.
To establish a User's access to the Master Repository, each local server must have a corresponding User on the Master Repository. This is the External User authorized to access the Master Repository. To provide this User access, you must create an Authorization Token that identifies and authenticates this User.
Navigate to System Admin → Security → Auth Tokens. The Authorization Tokens list page displays, click "Add" to add a new Authorization Token.
|
This section describes options specific to establishing an Authorization Token for CMT remote server processing. See Token Authentication for External Applications for more details about creating an Authorization Token.
When establishing an Authorization Token for remote CMT, define the following:
| Field | Description | |||||||||||||
| External App | Specify CMT as the registered external application. | |||||||||||||
| Token Value | This authorization Token Value is distributed and configured in the CMT Policy of the local server (along with Master server URL to allow connection). See Configuring the local server below. | |||||||||||||
| Allow Process As? | Rather than always using the "External User" User to generate a connectionid, the incoming request can nominate another LIMS User to execute the operation as if that user had made the request.
|
|||||||||||||
| Process As:
Specific User User In Department User With Role |
Depending on the value chosen in the "Allow Process As" field, different options are shown. Specify a specific User, Department or Role.
The connectionid (and hence security settings) will reflect the LIMS User, Department or Role instead of the External User. When "Process As" is set to a Specific User the Authorization token can share a common External App User. |
Configuring the Local Server |
|
|
In the local server, set the CMT Policy property Global Enable Change Control to "Deferred to Master Repository". This disables Change Control on the local server and requires the Master Repository to control changes to SDIs.
Configure the Master Repository using the Global Master Repository properties in the CMT Policy Sapphire Custom Node (Advanced Properties):
|
| Field | Description |
| Master Repository Server URL | The URL used to connect to the Master Repository. |
| Master Repository Server Authentication Token | The Authorization Token for the External User defined for remote connection from this local server. |
When Enable Change Control is set to "Defer to Master Repository" in the local server, the following occurs:
| • | All change controlled SDC List pages will show the Repository Operations menu (in place of the Change Control menu). See Using Change Control When Deferred to Master Repository for more information. |
| • | The local Server will behave as if it is not under change control (aside from the differences noted above). |
Using Change Control with a Remote (Master Repository) Server |
|
|
When Change Control is deferred to the Master Repository, the Repository Options menu displays on controlled SDI list pages.
|
The following sections describe the available operations.
Update |
Updates the selected SDI from the Master Repository.
|
With the SDIs you want to update selected, click "Update". This opens the Master Repository Operation dialog.
|
The Master Repository is identified, and the SDI(s) to be updated are listed. Clicking "OK" updates the SDI(s) with information stored on the Master Repository.
Search for SDIs on the Remote Server |
If you need to update an SDI that exists only on the remote server do not select an SDI in the list page and click "Update". This provides a Search option in the Master Repository Operation dialog.
|
You must know the identifier of the SDI you wish to retrieve. As you begin typing, any matching SDIs are listed. To search for and include multiple SDIs continue to search, as each found SDI is selected they are added to the list of SDIs to Update.
Remote Check Out |
When Checking Out an SDI from the Master Repository, a simple Check Out operation is performed. This initiates a transfer between the remote Master Repository and the local server.
With the SDI you want to Check Out selected, click Check Out from the Repository Operations menu.
The Master Repository Operation dialog displays.
|
Check Out is associated with the defined External User as configured in the Repository server Authorization Token. Check Out to a Department is not supported.
| Field | Description | |
| Remote Connection Status | Details of the remote connection to the Master Repository are listed. | |
| Master Change Request | The Change Request with which to associate these changes. Begin typing to display a list of Change Requests from the Master Repository. When deferring Change Control to a Master Repository, Change Requests are always created and maintained on the Master Repository. Whether or not Change Requests are Mandatory is determined by the Master CMT Policy option (Global Change Request, Mandatory For Check out).
|
|
| Change Request Id | The automatically generated identifier of the Change Request. | |
| Check Out SDIs | The SDI to be checked out. | |
| Override Local Changes | When an SDI is checked out from the Master Repository its data is transferred to the local server. This option lets you determine whether or not any changes made locally (without first performing a Remote Check Out) should be overridden.
By default (according to the CMT Policy → Check Out Override Local Changes option), this option is checked. |
Upon clicking "OK" the following occurs:
| 1. | The local server makes a call to the Master Repository (CMTRemoteHandler) to Check Out the SDI. This generates a Change Log (with a status of "Checked Out") on the Master Repository. |
| 2. | The Check Out (pre image) SDI Snapshot is downloaded to the local server. |
| 3. | The local server imports the Check Out SDI Snapshot and Checks Out the SDI locally. The SDI can now be modified on the local server and cannot be checked out on the Master Repository. |
|
Undo Remote Check Out |
Undo Remote Check Out is a two step process. If you wish to undo a Remote Check Out you will first need to perform the Undo Check Out on the Master Repository, then "Undo Local Check Out" (Change Log List page) on the local server.
Remote Check In |
When Checking In an SDI from the Master Repository, a simple Check In operation is performed. This initiates a transfer between the local server and the remote Master Repository.
When checking in an SDI to the Master Repository the following should be considered:
| • | If the SDI already exists on the Master Repository and has been checked out, a simple remote Check In is performed. � |
| • | If the SDI is newly created on the local server, the SDI can be modified as if it is not under Change Control (while on the local server). When the SDI is ready to be checked into the Master Repository it can be remotely checked in without being checked out. On Check In, the SDI is exported to the Master Repository. The Check In dialog will include a Change Request field (as shown for remote Check Out above). |
Simple Remote Check In |
With the SDI you want to Check In selected, click Check In from the Repository Operations menu. The Check In SDI to Repository dialog displays.
|
Upon clicking "OK", the checked in Change Log is generated and exported to the Master Repository. The SDI is imported to the Master Repository and checked In.
Checking In a Newly Added SDI |
The Check In SDI to Repository dialog performs a dual function. It can both Check In checked out SDIs, or directly Export new SDIs to the Master Repository. However, it cannot do both at the same time. When selecting multiple SDIs for Check In, if you choose both, previously checked out SDIs as well newly added SDIs, only those that had been checked out will be checked in.
|
If all the selected SDIs are newly added, the Check In dialog will directly Export the selected SDIs to the Master Repository. In this case, there will be no local history of the Check In activity. Only the current status of the selected SDI will be transferred to the Master Repository.
|
| NOTE: | It is possible that two local systems might attempt to create the same new SDI at the same time. In this case, the first attempt successfully checks in the SDI. The second attempt will fail. |
Remote Check In to delete an SDI is not supported. Delete SDI should be done directly on the Master Repository.
Compare Between Local Server and Master Repository |
The Compare button (shown on the SDI list pages, within the Repository Operations menu) opens an SDI Snapshot Comparison View highlighting the differences between the local server and the Master Repository.
An SDI Snapshot is taken of the current configuration on the Master Repository and downloaded to the local server. This SDI Snapshot is compared to the local SDI Snapshot.
|
View History |
The View Change History button (shown on the SDI list pages, within the Repository Operations menu) shows Master Repository Check Out, Check In history. See Visualizing SDI Snapshots → View Change History for more information.
