Web Services Designer Source Control and Layering

The Personify WSD is designed to support the version control and layering out of the box.

The Personify WSD provides the following Source Control features:

· Ability to check-out, check-in, and rollback the Service elements

· Supports multiple users working on different set of elements simultaneously

· Tracks the check-in history and preserves the changes

· Ensures that only valid definitions are checked-in

· Ensures that a user's changes are not overwritten by another user

The Personify WSD provides the following layering features:

· Ability to define multiple services

· Ability to define multiple layers within a Service

· Ability to inherit layers within a Service

· Ability to extend the parent (inheriting layer) entities and consume parent entities

· Provides a seamless upgrade, without having to manually retrofit anything

· Provides the option to resolve the layer conflicts and automatically resolves them

The Architecture

The definitions of the service elements are stored in the Personify database in XML form. Service definitions are broken into individual service elements and are stored in the database in order to facilitate better multi-user layering and version control support.

Database Schema

PDS_SERVICE_DEFINITION, PDS_LAYER_DEFINITION and PDS_ELEMENT_DEFINITION are three core tables that hold the service definitions. When the service definitions are moved across the databases, you have to move only the data from these three tables.

The Personify WSD does not support multiple services and layers.

PDS_ELEMENT_SANDBOX, PDS_ELEMENT_HISTORY and PDS_CHANGESET are three auxiliary tables used for source control. Initially all of these three tables will be empty.

Layering

The Data Service installation package includes the SQL script to populate these tables with the elements developed by base. When the Personify WSD is opened for the first time against any database, it forces the user to create a “Customer” layer that inherits “Base”. At this time, this database has one service and two layers (Base and Customer) underneath. The Base layer should have all the element definitions in PDS_ELEMENT_DEFINITION, whereas the Customer layer should not have any element definitions.

The Personify WSD shows all the elements from the Base layer. The reason for this is, even though the customer layer does not contain any since it inherits Base layer, it brings the elements from its parent layer.

When you extend the parent entity by adding additional properties and publish, only the delta will be stored under the “Customer” layer. For example, Base delivered an entity called Customer with MasterCustomerId, SubCustomerId, and LastName. Then, the developer extends that to add another property called FirstName. Therefore, on check-in, only FirstName will be stored under Customer layer, as shown below.

The following XML content of the “Customer” entity is stored under “Base” layer:

The following XML content of the “Customer” entity is stored under “Customer” layer:

The Personify WSD merges the elements from all the inherited layers and renders as a single Entity (as shown below). On save, it parses the layers and saves appropriately, as discussed above.

Native Element

A Native Element is an element that originated from your own layer.

Inherited Element

An Inherited Element is an element that is inherited from its parent layer.

Source Control

The Source Control provides ability to check-out, check-in, and undo check-out.

Check-out

When an existing element is checked-out, PDS_ELEMENT_DEFINITION.ELEMENT_STATE will be set to “L” (=> Locked) and a new record is added in the PDS_ELEMENT_SANDBOX table.

When a new element is added in the designer, PDS_ELEMENT_DEFINITION.ELEMENT_STATE will be set to “N” (=> New) and a new record is added in the PDS_ELEMENT_SANDBOX table.

To check-out an element, right-click the element and select Check Out, as shown below. Please note that an element can be checked out to only one developer at a time.

Developers can checkout elements as needed, if nobody else checked-out that element. Additionally, when needed, the Personify WSD prompts you checkout files that are affected by your operation. For example, when the developer deletes an association, the Personify WSD prompts the developer to check out the related Entities.

Undoing Check-outs

When the check-outs are rolled back, PDS_ELEMENT_DEFINITION.ELEMENT_STATE will be set to “U” (=> Unchanged) and the corresponding record is deleted from the PDS_ELEMENT_SANDBOX table.

The Personify WSD does not allow partial undoing of check-outs in order to preserve the integrity. Therefore, undoing a checkout will undo ALL checkouts. This operation can be performed any time by selecting Source Control > Undo Check-out All from the toolbar menu.

The Personify WSD prompts the developer to refresh the element definitions if needed. Please see Refreshing the Service Definitions for more information.

Save

When the changes are saved, the changes are updated in PDS_ELEMENT_SANDBOX table.

Check-in

When the elements are checked-in, the following sequences of operations are performed:

· Any unsaved changes are automatically saved in the PDS _ELEMENT_SANDBOX table.

· Elements are validated. Please note that invalid definitions cannot be checked-in.

· A new change set number is created in PDS_CHANGESET table.

· A new record is created for each element being checked-in in PDS_ELEMENT_HISTORY tables and element definition taken from PDS_ELEMENT_DEFINITION is preserved.

· PDS_ELEMENT_DEFINITION.ELEMENT_STATE is set to “U” (=> Unchanged).

· The element definition in PDS_ELEMENT_DEFINITION is updated, by taking the latest from PDS_ELEMENT_SANDBOX table.

· The corresponding record is deleted from the PDS_ELEMENT_SANDBOX table.

The Personify WSD does not allow partial check-ins in order to preserve the integrity. When the service is published to the server, the Personify WSD automatically checks-in the element definitions, if validation is complete. Developers may check-in all the changes any time by selecting Source Control > Check-in All from the toolbar menu.

Viewing Pending Check-ins

The Personify WSD provides an ability to view the pending check-ins by all the developers. This dialog provides the ability to check-in your pending changes, undo only your pending changes, and undo all the changes. This operation can be performed at any time by selecting Source Control>View Pending Check-ins from the toolbar.

Configuring Source Control

In version 1.2.0 and earlier, the metadata of the service definitions were stored in Personify database. In version 1.3.0, the source control is no longer located in the Personify database. Instead, it is a central source control database that provides the user with better flexibility and control and is hosted by TMA Resources free of charge.

After installing or upgrading to WSD 1.30 (or higher), contact your TMA Resources representative for your URL and credential information. After receiving this information, enter it in “Configure and Verify Interfaces Screen” (APP014) in Personify Enterprise, as shown below.