This task takes a set of TDXInput specifications of files to export using TDX services. It supports several parameters to control whether files should be imported in a single transaction or multiple, whether to use the the asynchronous protocol or not, etc. For example, this declaration would export sales and returns data in a single transaction using the corresponding services:

One important aspect to note is that the task infers the type of the files based on file extension.

Refer to the documentation below for details on what is controlled by each parameter.

@param input a set of TDXInput messages that represent files to export, together with the service to be called for the file. The file attribute must not contain patterns (as in lb.tdx.Import) and the other attributes are ignored. The type of the file is defined by the extension: .gz and .gzip are considered gzip files, otherwise they are considered plain CSV files. Files can be local file paths (e.g. data/returns.csv), file URIs (e.g. file:///data/returns.csv) and cloud store locations (e.g. s3://project/data/returns.csv). File paths are resolved locally and file URIs are resolved in the server.

@param txn_service the URI prefix of the transaction service to use (e.g.: "/txn"). If this is set, then all TDXInput entries in input will be processed in a single database transaction. Otherwise, each entry will be processed in its own transaction, and all will be executed in parallel. In this case, the task will only succeed if every part also succeeds.

@param transport the URI that describes the service location. Currently only TCP transport is supported, so the URI must be an HTTP service (e.g. the default is "http://localhost:8080").

@param async whether to use the asynchronous transaction protocol. This is only valid if there is a txn_service configured. It is highly recommended that you use the asynchronous protocol as it has much better performance characteristics for client and server; the synchronous protocol should only be used for legacy servers that do not support the asynchronous protocol.

@param poll_delay when using the asynchronous transaction protocol, the client will send all the specification of the files to export in a transaction and will then start polling until the transaction is over. This parameter determines the number of seconds to wait between polls. Note that the client polls immediately after the commit requests returns, so short transactions may never need to wait.

@param timeout the maximum number of seconds that the export should take. The meaning of this parameter differs slightly between asynchronous and synchronous transactions:

For asynchronous transactions, this means how long the client should keep polling for the transaction to terminate (see poll_delay), and the default is to continue indefinitely. Also note that the timeout is only checked once a polling request returned that the transaction is ongoing, which means that the precision of timeout is that of poll_delay (e.g. if poll_delay is 5 seconds, the client checks the timeout only every 5 seconds, so a 6 seconds timeout will only expire after 10 seconds).

For synchronous transactions and for individual parts (i.e. when no txn_service is set), this timeout is used as the timeout of the HTTP connection for all requests. This means that the connection is kept at most this number of seconds and will then be dropped, which will cause the transaction to potentially abort, and the task to fail.

@param key alias for the key in the server used to encrypt the files when they are exported.