Configuration

Map the named field evfn in the first ExtraView server to the named field evfn2 in the second ExtraView server, and vice versa as this is a bi-derectional assignment.  This is a global mapping of the field.  Unlike other integration daemons, you must map all fields that you want to synchronize between databases.  This ensures that the processing involved is kept to a minimum.  You must always map the AREA and PROJECT fields, else an error occurs and no processing is performed.

Note: The CLI_EDIT_MULTI_VALUE_FIELDS behavior setting must be set to YES in order for multi-value fields to be visible and editable in ExtraView.

Examples

evfn.SHORT_DESCR = evfn2.SHORT_DESCR
evfn.DESCRIPTION = evfn2.DESCRIPTION
evfn.SHORT_DESCR = evfn2.FRED_TEXTAREA
evfn.AREA = evfn2.AREA
evfn.PROJECT = evfn2.PROJECT
evfn.OP_SYS = evfn2.OP_SYS

Map the field value evv in the first ExtraView server to the field value evv2 in the second ExtraView server, and vice versa.

Note: These value mappings must be defined for mapped fields with a enumerated display type,(list, popup, radio, checkbox), in order for the synchronization to work.  Note that the mappings occur by comparing the titles to the fields.  If the values do not match exactly between servers, then the field is omitted from the synchronization transaction with a warning in the log.

Note: spaces in field values must be escaped with the \ character.

Examples

evv.STATUS.In\ Progress = evv2.STATUS.Work\ In\ Progress
evv.AREA.Empty\ Area = evv2.AREA.Engineering\ Issues
evv.PROJECT.Empty\ Area\ -\ Project\ Data = evv2.PROJECT.Defects

Map the field value evv in the business area and project in the first ExtraView server to the field value evv2 in the business area and project in the second ExtraView server, and vice versa.

Maps the information for the <ExtraView user id> in the first ExtraView server to the user id in the second ExtraView server, and vice-versa.  Note that User IDs and all supporting information are automatically inserted into the target instance when they do not exist but are referenced within the issue data.

Identify the name of the field in the first ExtraView server containing the mapped item ID in the second ExtraView server.  The field used for this purpose should have the following data dictionary attributes:

​- Display type = Text
– Select for Reports = Yes
– Filter Criteria = Yes

The EVID_FIELD does not need to be on the screen layout.

Example

EVID_FIELD = EV_ID

Identify the name of the field in the second ExtraView server containing the mapped item ID in the first ExtraView server.  The field used for this purpose should have the following data dictionary attributes:

​- Display type = Text
– Select for Reports = Yes
– Filter Criteria = Yes

The EVID_FIELD does not need to be on the screen layout.

Example

EVID_FIELD2 = EV_ID
 

This mapping provides for the replication of relationship group entries between the instances.  Note that you may map between relationship groups with different names on each server.  Only those relationship group entries that have issues that are replicated by the integration task are replicated.  At this point only parent-child relationships are support for synchronization.

Example

rg.my_relationship_group = rg2.another_relationship_group

As described in the Administration Guide, there is one built-in repeating row type in ExtraView, named RELEASE.  If you are mapping this repeating row type from SERVER to SERVER2, there is no need to explicitly provide a mapping for the layout type.  However, you may often want to map repeating rows with different layout types.  In these cases, you use the following syntax to identify the repeating row types being mapped:

layout_type.xxxx = layout_type2.yyyy

where xxxx and yyyy are the layout type names for the repeating row layouts being mapped on SERVER and SERVER2 respectively.  You may have multiple entries of this kind to map fields for multiple repeating row layouts within the same issue.  The statements that map the fields themselves will not be ambiguous as fields on one repeating row layout are never configured on another repeating row layout.

Example

# EVID_FIELD = <ExtraView Field Name>
#
# Identify the name of the field in the first ExtraView server containing the mapped # item ID in the second ExtraView server.
#
EVID_FIELD = EV_ID
RR_EVID_FIELD = RR_EV_ITEM_ID

# EVID_FIELD2 = <ExtraView field name>
#
# Identify the name of the field in the second ExtraView server containing the
# mapped item ID in the first ExtraView server.
#
EVID_FIELD2 = EV_ID
RR_EVID_FIELD2 = RR_EV_ITEM_ID

deletes.client = NO
deletes.client2 = NO

or:

deletes.client = YES
deletes.client2 = YES

If you set these to a value of NO, then if issues are deleted on one server, they will not be deleted on the other server.  It is useful for performance to set this value to NO if you are using the integration to migrate a significant number of records from one server to another as part of an initial data migration.  Once the initial migration of records is complete, you can set this back to YES and the deletes will happen over time.

This property is used to provide a value to be used to set a field in all issue INSERT operations in the first ExtraView SERVER.  This is not used for updates, only inserts and its primary purpose is to ensure that you provide field values for required fields on the target instance.

This property is used to provide a value to be used to set a field in all issue INSERT operations in SERVER2.  This is not used for updates, only inserts

Identify the field to be inspected for the MI_REGEX evaluation to determine if an item in the first ExtraView server maps to an item in the second ExtraView server.

The expression that is used with the MI_FIELD value to determine if an item in the first ExtraView server maps to an item in the second ExtraView server.  If MI_FIELD is set, then this entry is required.

Identify the field to be inspected for the MI_REGEX evaluation to determine if an item in the second ExtraView server maps to an item in the first ExtraView server.

The expression that is used with the MI_FIELD2 value to determine if an item in the second ExtraView server maps to an item in the first ExtraView server.  If MI_FIELD is set, then this entry is required.

Examples

MI_POLL_TRIGGER = <Boolean expression with replaceable variables>
MI_POLL_TRIGGER = "__area__" eq "Empty Area"
 

Examples

MJ_POLL_TRIGGER = <Boolean expression with replaceable variables>
MJ_POLL_TRIGGER = "__area__" eq "Empty Area"