02.05.2013 Views

MKS Implementer 2006 Administration Guide

MKS Implementer 2006 Administration Guide

MKS Implementer 2006 Administration Guide

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

Appendix C: Converting DesignTracker Data to <strong>MKS</strong> Integrity<br />

434<br />

Each DesignTracker DR and SR field is optionally mapped to an <strong>MKS</strong> Integrity field as<br />

defined by you. DR entities and corresponding fields automatically convert to <strong>Implementer</strong><br />

change packages in <strong>MKS</strong> Integrity. Fields can either be omitted, or they can have the name of<br />

an existing <strong>MKS</strong> Integrity field to populate with the data. The “Logged by User” and<br />

“Logged Date” always convert to internal fields.<br />

For each field you convert, if there is a master file in DesignTracker setup, the DesignTracker<br />

field value is assigned to the corresponding <strong>MKS</strong> Integrity field value as defined in the<br />

conversion properties file. This allows replacing the shorter abbreviated values common in<br />

DesignTracker, with the longer, more descriptive values common to <strong>MKS</strong> Integrity. For<br />

example, DesignTracker status values can be set to existing <strong>MKS</strong> Integrity state values.<br />

After the data conversion, the DRs and related lock history remain in DesignTracker,<br />

unchanged and available online to select DesignTracker users for historical and auditing<br />

purposes.<br />

TIP <strong>MKS</strong> recommends you assign the new <strong>MKS</strong> Integrity issue number to one of the<br />

user defined fields on DRs and SRs so it is visible when displaying a DR or SR. This<br />

also makes it available to include in reports and queries.However, this has no<br />

impact on the fact that once a DR or SR is converted, it will not convert again even if<br />

included in selection criteria.<br />

User Profile and Resource Fields<br />

<strong>Implementer</strong> attempts to convert all user profile and resource fields to the <strong>MKS</strong> Integrity user<br />

values defined for Project Leader and Developer Resource.<br />

<strong>Implementer</strong> retrieves the user ID that corresponds to the resource ID in the DesignTracker<br />

Resource master file. From the user ID, the OS/400 user profile is retrieved from the<br />

<strong>Implementer</strong> Work with Users function to verify if an <strong>MKS</strong> Integrity user ID is specified. If<br />

any of these values are invalid or not specified, the alternate value is used.<br />

In the event a name cannot convert, when defining the ICVTDT command parameters you<br />

must specify a valid default user to assign to the issue if there is no conversion for the user or<br />

available resource in DesignTracker.<br />

NOTE This rule applies when mapping to an <strong>MKS</strong> Integrity user field. If mapping to<br />

a text field, the original text maps to the new field.<br />

Entities Added as Change Package Entries<br />

When a converted DR is associated with a DesignTracker entity, an <strong>Implementer</strong> change<br />

package is created based on the standard <strong>MKS</strong> Integrity change package creation rules.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!