Native Table Copy Task Template

Specifies that the grantee can grant and revoke permissions to and from other users.

A user that creates an object automatically receives the ADMINISTRATION permission on that object.

Specifies that the grantee can delete objects of the selected types.

This permission controls access to diagnostic data of a task execution. The diagnostic data consists of the stages, their outputs and the batch reports.

Specifies that the grantee may execute the object, or schedule the object for later execution. This permission only applies to objects that are executable, i.e. tasks, task templates, workflows, workflow templates, and data shops.

Specifies that the grantee has read permission on the object. The grantee is able to see the object in lists and can see all of the object’s details, such as rules or access permissions.

In addition, the grantee can reference this object. For example, a user who has READ permission on a credential object can refer to this credential object when creating a new database connection.

Specifies that the grantee has the permission to change the settings and attributes of an object. This also includes modifying any rule lists that might be associated with the object (for example, the selection rules of a task template).

Boolean

true

This option specifies whether XDM checks uniqueness of modified unique key fields. When a modification method of modification type COLUMN modifies a column which is part of a unique key, XDM will check whether all output values of the modification are unique. This only checks the values processed by the task and does not involve other values that might exist in the target table.

Boolean

false

This flag controls whether the task process should abort if no tables are about to be copied.

Enum

N

Specifies the method that XDM uses to transport extracted data from the source database server to the target database server when copying full tables.

Boolean

false

This enables versioning with history tables to be deactivated before the target load starts. After the load is finished, versioning is reactivated. This option is can be used whenever the target system is Db2 LUW.

In order to apply this option the user must have ALTER TABLE authority for all tables with an associated history table (i.e. system period temporal tables).

Boolean

false

By enabling this property, identity values will not be checked and added for auto generated columns. This saves time, but can lead to incorrect identity values. Only check this option if you are sure that no inserted values will be in conflict with the current identity values of the target tables.

Boolean

false

Specifies if working files of a task execution should be deleted in case of a successful task execution. This reduces the required space for a task and should therefore prevent space problems on the server when many tasks exist.

String

n/a

An optional description for this object. The description can contain multiple lines to give more context on the configured object. The description is not used in a technical context.

String

n/a

Specifies the name of the object. The name is used to display and identify the object in lists. The name can contain any valid UTF-8 characters.

Enum

NOTHING

This option specifies how XDM handles the target tables of a task during structure comparison.

Boolean

false

Within Db2, with the attribute RestrictOnDrop cannot be dropped. This is a Db2 security option. When this property is set to true, RestrictOnDrop will be removed, and the table will be dropped.

String

default

This property defines whether and on which platform the Dataflow server is being built for a task or workflow execution. The property on the template is overwritten by the property on the task or workflow.

String

-1

Specifies how long executions are kept for the specific task or workflow. If an execution is older than the specified retention period, the XDM service will remove it. If the executions should not be deleted automatically, the retention period must be set to -1. Otherwise, the input must start with P for a date period or with PT with a time period.

A detailed description of the period syntax can be found here.

Boolean

false

This option prepares an additional temporary database, that allows previewing of the extracted data in the user interface. When enabled, the data can be investigated in the task execution detail view using the Schema Browser button.

If this option is enabled, additional space and time will be used during the execution of the task. Use this option during task development or debugging, but disable it for productive task usages.

For this option to work, the XDM core service needs access to the task directories. Please ensure, that the /xdm/tasks directories of your xdm-dataflow service, and your xdm-core service are mounted to the same storage.

Enum

DISABLE

There are three options which specify how to deal with foreign keys during the load process:

Boolean

true

If you copy a source table or sequence you can specify whether any aliases for these source objects should be generated in the DDL for the target as well. If the property is set to true, DDL for aliases will be generated and executed during task execution.

Boolean

true

If you copy a source table you can specify whether any comments for this source table should be generated in the DDL for the target as well. If the property is set to true, DDL for comments will be generated and executed during task execution.

Boolean

true

If you copy a source table you can specify whether the foreign keys for this table should be generated in the DDL for the target as well. If the property is set to true, DDL for foreign keys will be generated and executed during task execution.

Boolean

true

If you copy a source table you can specify whether the grants for this table should be generated in the DDL for the target as well. If the property is set to true, DDL for grants will be generated and executed during task execution.

Enum

ABORT

Controls how XDM should react if data should be loaded into a Db2 for z/OS table when there are other tables in the same tablespace. This operation can be problematic, since the other tables would be overwritten by the usual LOAD REPLACE operation. Therefore, special consideration is required of the user.

This property has no effect if the target system is not Db2 for z/OS, nor if there are no other tables in the target tablespace (except for the ´APPEND´ option).

Enum

ABORT

Defines XDM behavior, when source and target table structures are deemed to be incompatible.

Boolean

false

Activate the performance supervision in the associated task template (all task types are supported). If this option is activated certain warnings in the task logs will be activated and profiling statistics for JDBC queries are logged. They are available through a task execution export in the task folder files/performanceSupervision.

Loglevel

INFO

Controls the granularity of the log messages for the XDM task issued directly by XDM. The number of log messages decreases in the following order: Trace → Info → Warning → Error

It is also possible to overwrite the log level in specific program parts. This can be done by adding the prefix logger.level. + package name via a task stage hook to the global property map. For example, to set a specific log level to all components of the package de.ubs.xdm.batch.subsetapply you have to set the property logger.level.de.ubs.xdm.batch.subsetapply with the wanted required log level. inside a task stage hook. Supported values are info, warning, error, verbose and debug. A example how to set a property in a task stage hook can be found here. Typically, the support team will instruct to set a package log level for detailed analysis if necessary.

Possible values are:

ModificationSet

n/a

The property contains a list of modification sets that can be used to modify data during the task execution. For every modification set it is also stored, if it is selected or not. Only selected modification sets are shown in the view mode of the object.

Boolean

false

By enabling this property, values affected by modification methods will be checked if they can be inserted in the target. The task will abort if this is not possible.

Boolean

true

If this is active, the internal load format will be used instead of the delimited load format. This may enhance the load performance and can be used to transport binary data, which would be truncated using the delimited format.

Boolean

false

If this is active, all lobs will be transported inline in spanned datasets, instead of using PDS format. This option increases transport and load performance when GENERIC processing is active for a table. This flag will only be evaluated if using MVS internal LOAD format.

Boolean

true

Specifies whether the target DBMS logs all changes that are made to the target tables when XDM populates them with data from the source tables. Writing log records ensures that the target environment is able to perform a recovery operation if required. However, it also means that a large number of log records will be created in the target environment, which may not be desirable. If you want to minimize the number of log records that are written in the target, consider setting this option to true and taking a fresh backup copy of the target environment after the copy process finishes.

If the property is set to true, no log records will be written for the target tables while they are populated. Otherwise, the target DBMS is instructed to write log records for all changes that XDM makes to the contents of the target tables.

If the LUW database is configured as high available database, this flag must be set to false and in the connection, the parameter Backup path for COPY YES option must contain a valid path for the LOAD statement to be successful. Otherwise an error message SQL2032N The "COPY FLAG" parameter is not valid occurs.

Boolean

true

The parallel modifications flag determines whether modifications to tables should be processed in parallel (simultaneously) or sequentially (one after the other). Setting the flag to true enables parallel processing, which is faster but only suitable if there are no dependencies between the modification rules. Setting it to false enforces sequential processing, ensuring that modifications are applied in the correct order when dependencies exist.

Dependencies Between Modification Rules:

Dependencies occur when one modification rule relies on the results of another. If such dependencies exist, sequential processing is necessary to ensure data integrity and correctness.

Examples of Dependencies:

Data Collection Dependency:

Data Obfuscation and Usage:

Summary: Use the parallel modifications flag to control the order of table modifications:

Connection

n/a

Specifies the connection that is used as source connection in the task. A source connection must be set in either the task template or the task. If it is set in both, the connection set in the task is used.

String

n/a

The mount point on the source database server for a shared drive. When copying data between two different database servers, using a shared drive is one of the available transport options to move the data from the source database server to the target database server. This property specifies the full path under which the shared drive is accessible from the source database server.

String

n/a

With this option it is possible to use a specific working directory on the source database server. If a file path has been specified here, this path will be independent of that which is defined on the database server under working directory / qualifier. If nothing else has been specified here, the default is to use of the working directory from the underlying storage location.

Enum

TABLESPACE

Specifies whether the source tables are stopped while the copy process is running.

Tag

n/a

Contains the tags that apply to this object. These tags can be used in the search to find objects quickly and effortlessly.

Connection

n/a

Specifies the connection that is used as the target in the task. A target connection must be set in either the task template or the task. If it is set in both, then the connection set in the task is used.

String

n/a

The mount point on the target database server for a shared drive. When copying data between two different database servers, using a shared drive is one of the available transport options to move the data from the source database server to the target database server. This option specifies the full path under which the shared drive is accessible from the target database server.

String

n/a

With this option it is possible to use a specific working directory on the target database server. If a file path has been specified here, this path will be independent of that which is defined on the database server under working directory / qualifier. If nothing else has been specified here, the default is to use of the working directory from the underlying storage location.

TaskExecutionReport

n/a

This list defines which reports are created at the end of an execution and are displayed in the task execution. The list includes all defined reports to which the current user has READ access. The selected reports are generated at the end of a task or workflow execution.

Enum

1

If a source table differs in structure from a destination table you have to specify how differences are treated while copying it from source to target. The values are still written to the target database as they are. It depends on the handling of the database if there is a truncation or an error message. It is necessary to use a modification rule on the respective column to implement a proper data truncation.

For more details, see toleration mode in Comparing and Generating Objects.

String

n/a

This property specifies a list with one or more values which should be traced during XDM task processing. If multiple values are specified, these should be separated by semicolons. The specified values are reported in a trace data report at the end of a task stage in which the value was detected. Reported are the rows of a table in which one of the specified values occurs in any of the row’s columns, whenever that row is part of an INSERT, UPDATE, DELETE, or SELECT action.

If a specified value is detected in a stage as part of one of the above named actions, then the row in which it occurs is reported in the trace data report at the end of that stage. In the event that a specified value is affected by a modification method, the row in which it occurs is reported in the trace data modification report.

Boolean

true

Specifies whether a double quote delimiter should be used in DDL and SQL statements to identify objects such as schemas, tables, etc.

Unquoted identifiers are case-insensitive. This means that they will recognize customer, Customer, and CUSTOMER as the same object. However, quoted identifiers are case-sensitive. This leads to treating "CUSTOMER" and "customer" as entirely different objects.

You should keep in mind that XDM uses double quote delimiters by default. Turning this feature off can lead to usability issues. If you decide not to use double quote delimiters, you should be aware of how the database you are dealing with handles identifiers. For example, Db2 converts unquoted identifiers to uppercase, whereas PostgreSQL converts them to lowercase. Therefore, if you want to select a table named customer in Db2, this property should be set to true. Otherwise, XDM will look for a table named CUSTOMER, which either would not exist or would be a different table than the one you are looking for.

You should avoid mixing tasks with and without double quote delimiters.

Boolean

false

This property enables a task to use an alias on a table as a replacement for this table. This is useful in the following scenario: You have defined a uniform application model that names tables in the rules. In a certain environment the tables are named differently and have an alias for the original name. Then XDM creates a virtual table object in the task process under the name of the alias, and the column list of the underlying table.

Boolean

false

Using viewed tables controls when views should be handled like tables. In the event that a view references another view or an alias, XDM will follow the chain of references to a depth of 5 steps by default. You can control the selection depth by setting a custom parameter objSel_viewSelectionDepth with your preferred value.

Views can be used as a source in most cases, even if they are based on multiple tables or using functions to modify column values. For target usage, only views can be used that are based on a single table and reflect the columns without modifying any value. Please refer to the definition on deletable views, insertable views and updatable views of the database system documentation. When inserting on a view, the view will receive the DELETE, UPDATE and INSERT statements and the database system evaluates if the operation is permitted.