Click on the Destination button to define extraction-specific settings of the extraction.

ext_spec_set_de_form_debug

Table Name

Specify the name of the destination table. You have the following options:

  • Same as name of SAP object
  • Same as name of extraction and
  • Custom to specify a custom name yourself.

Column Name Style

Defines the style of the column name. Following options are available:

Ex-Spec-Settings-Makt-ColumnName

Code: The SAP technical column name will be used as column name, e.g. MAKTX.
CodeAndText: The SAP technical column name and the SAP description separated by an underscore will be used as column name, e.g. MAKTX_Material Description (Short Text).
TextAndCode: The SAP description and the SAP technical column name description separated by an underscore will be used as column name, e.g. Material Description (Short Text)_MAKTX.

Preparation

Defines the action to be executed on the destination database, before the data are loaded to the destination table.

  • Drop & Create: Drop the table if existent and create a new one.
  • Truncate Or Create: Truncate the table if existent, else create a new table.
  • Create if Not Exists: Create table if not existent.
  • Prepare Merge: prepares the merging process and creates a temporary staging table. Please refer to the section about merging.
  • None: No action.
  • Custom SQL: Defines custom SQL statement. Refer to the section Custom SQL for more information.

If you want in the first step to just create a table, you have two options:

  1. Copy the SQL statement and run it directly on the destination database.
  2. Select the None option for Row Processing and Finalization and then run the extraction.

After the table is created, you can change the table definition, e.g. by creating key fields, indices or additional fields.

Row Processing

Defines how to load the data to the destination table.

  • Insert: Insert rows.
  • Fill merge staging table: Insert rows in the staging table. Please refer to the section about merging.
  • None: No action.
  • Custom SQL: Defines custom SQL statement. Refer to the section Custom SQL for more information.
  • Merge (deprecated):This option is deprecated. Please use the option Fill merge staging table and refer to the section about merging.

Finalization

Defines the action to be executed on the destination database, after the data has been to the destination table.

  • Finalize Merge: finalizes the merging process and drops the temporary staging table. Please refer to the section about merging.
  • None: No action.
  • Custom SQL: Defines custom SQL statement. Refer to the section Custom SQL for more information.

About merging

Before you merge data, it is required that you have a table, where new with existing data should be merged. The table could have been created in the first run using the correspondent Preparation-Option filled with data using the Row Processing-Option Insert .

In the following runs you would like to merge the new incoming rows. Therefore you should set the following options:

  • Preparation to Prepare Merge,
  • Row Processing to Fill merge staging table and
  • Finalization to Finalize Merge.

The merge operation uses a staging table and is performed in three steps. In the first step a temporary staging table is created into which the data is inserted in the second step. In the third step, the temporary table is merged into the target table and afterwards deleted.

Destination-Exa-Makt-Merge

The merge operation updates existing rows and inserts non existent ones. You can see in the SQL statement, which fields will be updated. The SQL statement can be changed, e.g. to exclude certain columns from being updated. Fields that do not appear in the SQL statement will not affected by changes.

It is important that an appropriate index exists to run the merge operation efficiently. Without an appropriate index a merge operation may take long time depending on the amount of data.

Debugging

Disable bulk operations:
This option disables the bulk operation for inserting data into the destination database and leads to slower performance but it enables more detailed error messages on row level.

Transaction style

One Transaction
Preparation Row Processing and Finalization are executed in a single transaction. +: allows for a clean rollback of all table changes.
-: might result in table or database locks during the whole extraction process.

Three Transactions
Preparation, Row Processing and Finalization are each executed in a single transaction.
+: allows for a clean rollback in each of the above sections. Shorter locking periods as compared to “One Transaction”.
-: No rollback of the previous section possible (e.g. errors in Row Processing will only rollback the statements performed as part of the Row Processing, however not those performed in the Preparation section)

RowProcessingOnly
Only the Row Processing section will be performed as a transaction. Preparation and Finalization are peformed without an explicit transaction (implicit commits).
+: DDL in Preparation and Finalization for DMBS which don’t support DDL with explicit transactions (e.g. AzureDWH) -: No rollback of errors that occur in the Preparation/Finalization sections

No Transaction
No explicit transactions.
+: No transaction management via DBMS necessary (Locking,transaction log , etc.) might lead to performance improvements.
-: No rollback in any section.