images/download/attachments/164332959/611-version-1-modificationdate-1704703206925-api-v2.png

(1) See section Phase 4.

(2) See section Phase 4 - SQL Execution (GUI).

(3) See section Swapping.

(4) See section "Skip record in case of error" below.

(5) This checkbox applies to source structure fields. If the checkbox is not set, fields without a value will be filled with an empty string or the default value. If the checkbox is set, the Empty Flag will be set for fields without a value.

(6) This checkbox applies to target structure fields. If this checkbox is set, no internal data objects are generated for empty fields. This can save memory if empty fields in the target tree are not needed.

(7) Only those source fields that are mapped or which are referenced as function parameters are kept in the main memory if the checkbox is set. This saves memory when only a few fields are used for large input files. This option has no effect for the XML parser version 4. It cannot be used for document types EDIFACT in TradaComs format or BWA. If function copy field by name() is used in the profile, the checkbox may not be used. If set, it will be removed when saving the profile.

(8) Indicates whether numeric data types ("Integer", "Float", "Double", "BigInteger", "BigDecimal") should be filled from the left with zeros (0), even if this formatting is not explicitly set in the fields. This setting is only relevant for the output format "Fix record".

(9) If a node has several match codes and you want to know which one actually matched when the node was entered, you have to set this checkbox. Then, you can simply use function get matched value() to read out the value. Attention: Setting this checkbox considerably increases the memory requirements for the source tree.

(10) See section Execute "Execute Responses per record" below.

(11) If this option is set, fill settings of fields will be reapplied after the template has been applied. Only needed if you use content "Fix record" in a Response.

(12) Checks whether the input value is Base64-encoded and decodes it if it is. Note: This option only makes sense if the output format is not based on fixed lengths, since the length of the data is changed if decoded.

(13) The simple data mapper does not allow hierarchies below nodes. The normal data mapper allows complex hierarchies in the source and target structure. Note: See also section Phase 3: Mapping (performance).

(14) Concerns the source structure field attribute "New record if value changes". If this option is selected, the specified fields are ORed, otherwise ANDed (all field values must change).

Skip record in case of error

Usually, a profile is terminated if an error (like violations of the minimum/maximum constraints or missing mandatory fields) occurs during the mapping. But sometimes you do not want the whole profile to be terminated, for example, if a large number of orders are submitted in a single file. You would only want to skip the order that caused the error but still process all the other orders.

The checkbox "Skip record on error" can be used to limit errors during the mapping process to the current record. This allows for the subsequent (error-free) orders to be processed.

Error handling can only be activated at the level of a record. As a consequence, the logical unit of a mapping (e.g. an order) must be represented per record. If during the mapping an error occurs in a record, all subsequent phases behave as if the record would not exist.

Note: It is not a termination in the sense of terminating a transaction. Variables that were changed before the error in the record occurred retain the changed values!

If an error occurs, an entry is made in the log files. In addition, it is possible to use variables to collect information about the erroneous/skipped datasets.

The system variable VAR_SYS_HAS_INVALID_RECORD has the value true if an error has occurred during processing of at least one dataset.
You can use system variable VAR_SYS_MESSAGE to store relevant information about an erroneous/skipped dataset.
The contents of variable VAR_SYS_MESSAGE are accumulated in the system variable VAR_SYS_COLLECTED_MSGS.

The variables can, for example, be used in a Response to send an email containing information about the erroneous/skipped datasets.

Execute Responses per record

Normally, the Responses in phase 6 are executed once per job.

By setting checkbox Enter output channels for each record in the extended settings of phase 2, this behaviour can be changed. The Responses will then be executed once per record.

Attention: By default, Responses that have the content set to "Output of IU", only execute the Integration Unit once per job and not for each record. These Responses thus always receive the same data for each record. If you want the Integration Unit executed for each record, set checkbox "Incorporate IU".