Defining Mappings
A mapping defines how data source connection properties and principal definitions are mapped to the target site when related bundles are migrated. Deployment Manager uses the data source connection properties and principal definitions on the source site by default. However, you can define the mapping properties from scratch or use the properties from any defined site as the starting point and then edit those properties.
For data source mappings, you can define these properties:
• Data source properties (host, IP addresses, etc.)
• Data source logins (encrypted)
• Data source schema and catalogs (for some data sources like Oracle)
For principal mappings, you define the mapped name to define how this mapping should be named on the target site.
Requirements
If you have a database that supports enabled database links, you must disable database links prior to defining mappings in Deployment Manager. See
Disabling Database Links for Mapping for more information.
Note: Accessing resources during mapping requires that the source and target TDV instances are online.
See these topics for how to define the mappings:
Editing the Resource Mappings for a Site
The resource mappings define the connection properties for a data sources on your target site. Defining or editing resource mappings is optional. By default, the data source resources are mapped to the same properties that they have on the source site. You only need to define or edit the resource mappings if the data sources have different connection properties on the target site.
Note: If you are using caches, see
Caching and Deployment Manager for information about mapping the cache data sources.
To edit the resource mappings for a site
1. Click SITES.
2. Select a site.
3. Click the Resource Mappings tab.
Deployment Manager finds all data sources on the source site that contain resources that might be migrated to the target server. In this example, the source site has three data sources:
You can optionally map the connection properties on the source site to something different on the target site. If you do not edit the mappings, the current settings on the source site are used.
4. Click Choose Target Site and select a target site for the mapping.
The target site is the site to which you plan to migrate the bundle. Choosing a target site now makes it easy for you to populate the Target Values column.
Note: When you create a plan, you can migrate the bundle to a different site but you might want to adjust the mappings prior to plan execution.
5. Click a data source to expand it and see the three property groups: Basic, Advanced, and for some data sources, Containers.
The fields displayed in the Basic Properties, Advanced Properties, and optional Container groups depend on the data source type (such as relational data sources or XML data sources) and vendor (such as PostgreSQL, Oracle, SQL Server, etc.). See the sections below for information about the displayed fields:
For complete documentation on all of the data source properties for each data source type and vendor supported by TDV, see the TDV User Guide.
Note: You can view the properties for a data source by opening it in TDV Studio. The location of the properties on the Basic and Advanced tabs and the property names displayed in Deployment Manager might be slightly different than in Studio. Also, some fields are editable in Deployment Manager but not in Studio. Where they differ, Studio is the best authority.
6. Click a group to review its properties as shown below for the Basic group.
7. Optionally, populate the Target Values from either the source site or target site:
— Click Populate from Source to fill in the properties from the source site which you can then edit. These are the default properties that are used if you do not edit the mappings.
— Click Populate from Target to populate the fields using values from another TDV site which you can then edit. Deployment Manager displays a dialog for you to choose a site defined in Deployment Manager, then choose the data source with the properties to populate the fields. You should choose a compatible data source. That is, if your target data source is a relational data source, you should choose a relational data source to populate the fields.
Note: The target site must be online to Populate from Target. You can define mappings for offline sites, but you need to enter them manually or Populate from Source and edit the values.
8. Edit a property:
a. Double-click the row.
b. Type text directly into the field or choose an option.
c. Click Save to save the new value.
9. Repeat editing the mapping information for each data source, as necessary.
Relational Data Sources
Relational data sources have three possible property groups: Basic, Advanced, and Container (for data sources that support catalog and schema definitions). The properties shown in Deployment Manager for an Oracle data source are listed below.
Basic Properties (Oracle Example)
Property | Value Type | Notes |
urlIP | text | |
urlPort | text | |
urlDatabaseName | text | |
login | text | |
password | text | Appears as asterisks. |
connProperties | name/value | You can specify property name-value pairs to pass to the JDBC data source. You can add whatever connection property/value pairs are appropriate for your data source. For example, the Oracle data source might have these connection properties: processEscapes: true
disableDefinecolumnType: true
SetBigStringTryClob: true
AccumulateBatchResult: true TDV does not validate property names. Some data source adapters ignore invalid property names or values; others return an error. |
connPoolMinSize | numeric text | |
connPoolMaxSize | numeric text | |
connPoolTimeout | numeric text | |
connStaleTimeout | numeric text | |
execTimeout | numeric text | |
maxSourceSideCardinalityForSJ | text | |
minTargetToSourceRatioForSJ | text | |
maxNumberForOrSyntax | numeric text | |
Advanced Properties (Oracle Example)
Property | Type | Notes |
persistPassword | true|false|none | |
isPassThrough | Enabled|Disabled | |
txnIsolationLevel | Read Committed|
Serializable | |
urlPatternStr | text | Use the format: jdbc:postgresql://<HOST>:<PORT>/<DATABASE_NAME> |
connValidateQuery | text | Example: SELECT 1 |
commitOnFetchDone | true|false|none | |
connCheckOutProcedure | text | |
supportsStarSchema | true|false|none | |
nativeDataLoadingEnabled | true|false|none | |
collationSensitive | true|false|none | |
enablePassThroughPreparedStatements | true|false|none | |
introspectUsingDBA_Views | true|false|none | |
introspectProceduresEnabled | true|false|none | |
authentication | BASIC|KERBEROS | |
ticketCache | text | |
includeInvalidObjects | true|false|none | |
useLoginCertEncryption | true|false|none | |
supportsDataship | true|false|none | |
supportsDatashipAsTarget | true|false|none | |
LowerBoundForDataShip | numeric text | |
UpperBoundForDataShip | numeric text | |
destinationSchema | text | |
dataShipTempTablePrefix | text | |
supportsDBLink | true|false|none | If set to true, you must meet the following requirements for running data source mapping across sites successfully: • Valid connection credentials for the target site. For example, you must be able to connect to the data source using the supplied port number from the mapping definition. • The DBLink information must be valid. • The Database Links defined including the Database Link Name and the Path of data source must exist in the target site before executing the mapping action. Otherwise, disable this option before mapping across sites. See Disabling Database Links for Mapping. |
DBLinkList | name/value | Add a row for each database link, then enter the database link name and the path of the data source. |
Container Properties (Oracle Example)
Containers are the names of catalogs and schema definitions. Some data sources do not have the Container group if they do not support catalogs and schema.
Catalog or Schema Name | Type | Notes |
RQAN1 | text | |
QAN | text | |
SYSTEM | text | |
DBSNMP | text | |
RQAN | text | |
XML Data Sources
Basic Properties (XML Example)
Property | Type | Notes |
root | text | |
url | text | Example format:
file:///C:/engineering/test.xml |
schemaLocation | text | Example format:
http://www.compositesw.com/services/webservices/system/admin/resource file:///C:test.xsd |
noNamespaceSchemaLocation | text | |
Advanced Properties (XML Example)
Property | Type | Notes |
local | true|false|none | |
charset | text drop-down | <auto-detect> - Default
Cp1250-Cp1257
iso-8859-1
us-ascii
utf-8, 16, 16be, 16le
windows-1250 to windows-1257 |
filters | text | File name filters to restrict the files included, such as *.xml to select only files of type XML. Separate multiple filters with commas. |
Caching and Deployment Manager
If you are using caching, keep these things in mind when defining mappings:
• By default, the source site caching definitions for target files or data sources are used when you migrate resources to a target site.
• If you are using single-file or multi-file caching and have specified file or data source caching information on the source site, these data sources can be mapped to a different location on the target site.
• If you are using file-based caching and want to map the cache to a different location on the target site, you must create the folder and cache files on the target source prior to executing the deployment plan.
When you initially create a file-based cache data source, you need to configure the caching status table (cache_status) and tracking table (cache_tracking). The cache_status and cache_tracking files are generated in the storage directory of the file cache data source.
You can map the file caching storage directory to a different location on the target server, but you need to copy all folders and files from the source directory to the target directory manually. Otherwise, the mapping will fail.
For example, if you have the following cache storage directories:
— Source cache storage directory: D:\dm\ds\filecacheds
— Target cache storage directory: D:\temp
You need to copy cache_status and cache_tracking files to D:\temp manually before doing the Deployment Manager mapping operation.
When you migrate resources in a deployment plan, you can specify how caches for new or existing objects should be handled. You can choose to create or re-create the cache tables or not. These options apply to data source caches only; they are not applicable to file-based caches. See
Defining the Resource Bundle to Migrate.
Changing the Mapping Target Values Site
Changing the resource mappings for a specific environment can be done quickly from the Resource Mapping tab.
To change the target value for your resource mapping
1. From the Resource Mapping tab, click on the site name next to the Target Value column label.
2. Select a different site from the list.
Disabling Database Links for Mapping
For data sources that support database links, you might need to disable database links support prior to mapping the data source in Deployment Manager. See the supportsDBLink Advanced Property in the
Relational Data Sources section for the requirements.
To disable database links
1. Open TDV Studio.
2. Open the data source.
3. Click the Advanced tab.
4. If necessary, clear the database link check box. The database link option is labeled differently for example:
Data Source Example | Database Link Option Example |
Oracle | Enable Oracle Database Link |
PostgreSQL | Enable PostgreSql dblink |
Vertica | Enable Export To Another Vertica Database |
Sybase IQ | Enable Sybase IQ SQL Location |
Editing the Principal Mappings for a Site
The principal mappings define the names you want to give the selected principals on the target site. Editing principal mappings is optional; by default, the principals are mapped to the same names as they have on the source site, so you only need to edit principal mappings if the principals have different names on the target site.
To edit the principal mappings for a site
1. Click SITES.
2. Select a site.
3. Click the Principal Mappings tab.
A list of the existing principals—groups and users—for the TDV site is displayed as shown in this example:
4. Click Choose Target Site and select a target site for the mapping, then click OK.
5. Double-click a row to enter a new target value.
Deployment Manager displays a text box.
6. Type the target name you want to give this principal on the target site.
The target name must include the domain and group or user as a prefix to the target name using this syntax:
<domain>/<group|user>/<target_name>
as in:
composite/group/developers
For example, if you want to migrate this principal—composite/group/developers—to a different domain on the target server and also give it a new name, you might specify:
my_domain/group/Product_Developers
7. Click Save.
In this example, the source site name for the group is “developers”, but the name for this principal group will be “Product_Developers” on the target site. Also, two of the users are each mapped to a different name. All are mapped to a different domain.
Removing Mapping Definitions
You can easily remove any individual resource or principal mapping definitions that you have made. For resource mappings, you can delete all mapping definitions for a data source.
To remove an individual mapping definition
1. Click SITES.
2. Select a site.
3. Select the Resource Mappings or Principal Mappings tab.
4. Double-click the row containing the target value you want to remove.
5. Click Delete.
To remove all resource mapping definitions for a data source
1. Click SITES.
2. Select a site.
3. Select the Resource Mappings tab.
4. Select the data source.
5. Click Delete Mapping (the “-” button to the far right of the data source name).
