complexType "etl:EtlType"

Namespace:	http://labkey.org/etl/xml
Content:	complex, 6 attributes, 8 elements
Defined:	globally in etl.xsd, see XML source
Includes:	definitions of 6 attributes and 8 elements
Used:	at 1 location

XML Representation Summary

<...

allowMultipleQueuing

boolean : "false"

loadReferencedFiles

boolean : "false"

siteScope

boolean : "false"

standalone

boolean : "true"

transactDestinationSchema

string

transactSourceSchema

string

Content:

etl:name × etl:description? × etl:transforms × etl:schedule? × etl:incrementalFilter? × etl:parameters? × etl:pipelineParameters? × etl:constants?

</...>

Content Model Elements (8):

etl:constants (type etl:ConstantsType),

etl:description (type string),

etl:incrementalFilter (in etl:etl),

etl:name (in etl:etl),

etl:parameters (in etl:etl),

etl:pipelineParameters (in etl:etl),

etl:schedule (in etl:etl),

etl:transforms (in etl:etl)

All Direct / Indirect Based Elements (1):

etl:etl

Known Usage Locations

As direct type of elements (1):
etl:etl

XML Source (see within schema source)

<all>

</all>

ETL can be run on its own, rather than a subcomponent that can only be queued from another ETL.

</documentation>

</annotation>

</attribute>

ETL can run at a site level scope, not just in a container.

</documentation>

</annotation>

</attribute>

By default, if a job for the etl is already pending (waiting), we block adding another instance of the etl to the job queue. Set this flag to override and allow multiple instances in the queue.

</documentation>

</annotation>

</attribute>

Optional. Experimental, Postgres datasources only. Causes a multi-step ETL to wrap an entire run of the ETL in a single transaction
on the source datasource containing the schema specified. This transaction will be isolation level REPEATABLE READ, guaranteeing consistent
state of source data throughout the transaction. This prevents phantom reads of source data which has been inserted/updated since
the ETL started. Only meaningful if the source schemas for every step in the ETL are all from the same datasource. Individual steps
will not have their own transaction boundaries.
The intended use case is for a source datasource external to LabKey Server.
This setting is independent of the optional transactDestinationSchema setting. If both are specified, and the two schemas are from
the same datasource, the ETL will be wrapped in a single REPEATABLE READ transaction. This scenario is only supported if
tha single datasource is Postgres, and is not recommended.

</documentation>

</annotation>

</attribute>

Optional. Very experimental, use with caution. Causes a multi-step ETL to wrap an entire run of the ETL in a single transaction
on the destination datasource containing the schema specified. This transaction will only be committed upon successful completion
of the ETL run; any error will cause a full rollback of every step up to that point. Only meaningful if the destination schemas for every
step in the ETL are all from the same datasource. Individual steps will not have their own transaction boundaries, nor will setting
a batchSize have any effect. Using this setting will very likely cause lock contention problems on the destination queries,
especially on SQL Server.
This setting is independent of the optional transactSourceSchema setting. If both are specified, and the two schemas are from
the same datasource, the ETL run will be wrapped in a single REPEATABLE READ transaction. This scenario is only supported if
tha single datasource is Postgres, and is not recommended.

</documentation>

</annotation>

</attribute>

</complexType>

Attribute Detail

allowMultipleQueuing

Type:	boolean, predefined
Use:	optional
Default:	"false"
Defined:	locally, within (this) etl:EtlType complexType

By default, if a job for the etl is already pending (waiting), we block adding another instance of the etl to the job queue. Set this flag to override and allow multiple instances in the queue.

XML Source (see within schema source)

By default, if a job for the etl is already pending (waiting), we block adding another instance of the etl to the job queue. Set this flag to override and allow multiple instances in the queue.

</documentation>

</annotation>

</attribute>

loadReferencedFiles

Type:	boolean, predefined
Use:	optional
Default:	"false"
Defined:	locally, within (this) etl:EtlType complexType

XML Source (see within schema source)

siteScope

Type:	boolean, predefined
Use:	optional
Default:	"false"
Defined:	locally, within (this) etl:EtlType complexType

ETL can run at a site level scope, not just in a container.

XML Source (see within schema source)

ETL can run at a site level scope, not just in a container.

</documentation>

</annotation>

</attribute>

standalone

Type:	boolean, predefined
Use:	optional
Default:	"true"
Defined:	locally, within (this) etl:EtlType complexType

ETL can be run on its own, rather than a subcomponent that can only be queued from another ETL.

XML Source (see within schema source)

ETL can be run on its own, rather than a subcomponent that can only be queued from another ETL.

</documentation>

</annotation>

</attribute>

transactDestinationSchema

Type:	string, predefined
Use:	optional
Defined:	locally, within (this) etl:EtlType complexType

Optional. Very experimental, use with caution. Causes a multi-step ETL to wrap an entire run of the ETL in a single transaction on the destination datasource containing the schema specified. This transaction will only be committed upon successful completion of the ETL run; any error will cause a full rollback of every step up to that point. Only meaningful if the destination schemas for every step in the ETL are all from the same datasource. Individual steps will not have their own transaction boundaries, nor will setting a batchSize have any effect. Using this setting will very likely cause lock contention problems on the destination queries, especially on SQL Server. This setting is independent of the optional transactSourceSchema setting. If both are specified, and the two schemas are from the same datasource, the ETL run will be wrapped in a single REPEATABLE READ transaction. This scenario is only supported if tha single datasource is Postgres, and is not recommended.

XML Source (see within schema source)

</documentation>

</annotation>

</attribute>

transactSourceSchema

Type:	string, predefined
Use:	optional
Defined:	locally, within (this) etl:EtlType complexType

Optional. Experimental, Postgres datasources only. Causes a multi-step ETL to wrap an entire run of the ETL in a single transaction on the source datasource containing the schema specified. This transaction will be isolation level REPEATABLE READ, guaranteeing consistent state of source data throughout the transaction. This prevents phantom reads of source data which has been inserted/updated since the ETL started. Only meaningful if the source schemas for every step in the ETL are all from the same datasource. Individual steps will not have their own transaction boundaries. The intended use case is for a source datasource external to LabKey Server. This setting is independent of the optional transactDestinationSchema setting. If both are specified, and the two schemas are from the same datasource, the ETL will be wrapped in a single REPEATABLE READ transaction. This scenario is only supported if tha single datasource is Postgres, and is not recommended.

XML Source (see within schema source)

</documentation>

</annotation>

</attribute>

Content Element Detail

etl:constants

Type:	etl:ConstantsType, complex content
Defined:	locally, within (this) etl:EtlType complexType

XML Source (see within schema source)

etl:description

Type:	string, predefined, simple content
Defined:	locally, within (this) etl:EtlType complexType

XML Source (see within schema source)

etl:incrementalFilter

Type:	etl:FilterType, complex content
Defined:	locally, within (this) etl:EtlType complexType

XML Source (see within schema source)

etl:name

Type:	string, predefined, simple content
Defined:	locally, within (this) etl:EtlType complexType

XML Source (see within schema source)

etl:parameters

Type:	etl:ParametersType, complex content
Defined:	locally, within (this) etl:EtlType complexType

XML Source (see within schema source)

etl:pipelineParameters

Type:	etl:PipelineParametersType, complex content
Defined:	locally, within (this) etl:EtlType complexType

XML Source (see within schema source)

etl:schedule

Type:	etl:ScheduleType, complex content
Defined:	locally, within (this) etl:EtlType complexType

XML Source (see within schema source)

etl:transforms

Type:	etl:TransformsType, complex content
Defined:	locally, within (this) etl:EtlType complexType

XML Source (see within schema source)

This XML schema documentation has been generated with DocFlex/XML RE 1.7.2 using DocFlex/XML XSDDoc 2.1.0 template set.

DocFlex/XML RE is a reduced edition of DocFlex/XML, which is a tool for programming and running highly sophisticated documentation and reports generators by the data obtained from any kind of XML files. The actual doc-generators are implemented in the form of special templates that are designed visually using a high quality Template Designer GUI basing on the XML schema (or DTD) files describing the data source XML.

DocFlex/XML XSDDoc is a commercial template application of DocFlex/XML that implements a high-end XML Schema documentation generator with simultaneous support of framed multi-file HTML, single-file HTML and RTF output formats. (More formats are planned in the future).

A commercial license for "DocFlex/XML XSDDoc" will allow you:

To configure the generated documentation so much as you want. Thanks to our template technology, it was possible to support more than 300 template parameters (working the same as "options" of an ordinary doc-gen), which will give you an unprecedented control over the generated content!
To use certain features disabled in the free mode (such as the full documenting of substitution groups).
To enable/disable documenting of the initial, imported, included and redefined XML schemas selectively.
To document local element components both globally and locally (similar to attributes).
To enable/disable reproducing of namespace prefixes.
To format your annotations with XHTML tags and reproduce that formatting both in HTML and RTF output.
To insert images in your annotations using XHTML <img> tags (supported both in HTML and RTF output).
To use PlainDoc.tpl main template to generate all the XML schema documentation in the form of a single HTML file.
To use the same template to generate the incredible quality RTF documentation.
To document only selected XML schema components specified by name.
To remove this very advertisement text

Once having only such a license, you will be able to run the fully-featured XML schema documentation generator both with DocFlex/XML SDK and with DocFlex/XML RE, which is a reduced free edition containing only the template interpretor / output generator. No other licenses will be required!

But this is not all. In addition to it, a commercial license for DocFlex/XML SDK will allow you to modify the XSDDoc templates themselves as much as you want. You will be able to achieve whatever was impossible to do with the template parameters only. And, of course, you could develop any template applications by your own!

Please note: By purchasing a license for this software, you not only acquire a useful tool, you will also make an important investment in its future development, the result of which you could enjoy later by yourself. Every single your purchase matters and makes a difference for us!

To buy a license, please follow this link: http://www.filigris.com/shop/