tables

Author: v-kents

articles/data-factory/concepts-pipeline-execution-triggers.md

@@ -231,7 +231,7 @@ To have your schedule trigger kick off a pipeline run, include a pipeline refere
 The following table provides a high-level overview of the major schema elements that are related to recurrence and scheduling a trigger:
 
 | JSON property | Description |
-|---------------|-------------|
+| --- | --- |
 | **startTime** | A date-time value. For basic schedules, the value of the **startTime** property applies to the first occurrence. For complex schedules, the trigger starts no sooner than the specified **startTime** value. |
 | **endTime** | The end date and time for the trigger. The trigger doesn't execute after the specified end date and time. The value for the property can't be in the past. <!-- This property is optional. --> |
 | **timeZone** | The time zone. Currently, only the UTC time zone is supported. |
@@ -277,7 +277,7 @@ The following table provides a high-level overview of the major schema elements
 ### Schema defaults, limits, and examples
 
 | JSON property | Type | Required | Default value | Valid values | Example |
-|---------------|------|----------|---------------|--------------|---------|
+| --- | --- | --- | --- | --- | --- |
 | **startTime** | string | Yes | None | ISO 8601 date-times | `"startTime" : "2013-01-09T09:30:00-08:00"` |
 | **recurrence** | object | Yes | None | A recurrence object | `"recurrence" : { "frequency" : "monthly", "interval" : 1 }` |
 | **interval** | number | No | 1 | 1 to 1000 | `"interval":10` |
@@ -288,7 +288,7 @@ The following table provides a high-level overview of the major schema elements
 The following table shows you how the **startTime** property controls a trigger run:
 
 | startTime value | Recurrence without schedule | Recurrence with schedule |
-|---|---|---|
+| --- | --- | --- |
 | **Start time is in the past** | Calculates the first future execution time after the start time, and runs at that time.<br /><br />Runs subsequent executions calculated from the last execution time.<br /><br />See the example that follows this table. | The trigger starts _no sooner than_ the specified start time. The first occurrence is based on the schedule,  calculated from the start time.<br /><br />Runs subsequent executions based on the recurrence schedule. |
 | **Start time is in the future or the current time** | Runs once at the specified start time.<br /><br />Runs subsequent executions calculated from the last execution time. | The trigger starts _no sooner_ than the specified start time. The first occurrence is based on the schedule, calculated from the start time.<br /><br />Runs subsequent executions based on the recurrence schedule. |
 
@@ -310,7 +310,7 @@ If multiple **schedule** elements are specified, the order of evaluation is from
 The following table describes the **schedule** elements in detail:
 
 | JSON element | Description | Valid values |
-|--------------|-------------|--------------|
+| --- | --- | --- |
 | **minutes** | Minutes of the hour at which the trigger runs. |- Integer<br />- Array of integers|
 | **hours** | Hours of the day at which the trigger runs. |- Integer<br />- Array of integers|
 | **weekDays** | Days of the week the trigger runs. The value can be specified only with a weekly frequency.|<br />- Monday<br />- Tuesday<br />- Wednesday<br />- Thursday<br />- Friday<br />- Saturday<br />- Sunday<br />- Array of day values (maximum array size is 7)<br /><br />Day values aren't case-sensitive|
@@ -334,7 +334,7 @@ This section provides examples of recurrence schedules. It focuses on the **sche
 The examples assume that the **interval** value is 1 and that the **frequency** value is correct according to the schedule definition. For example, you can't have a **frequency** value of "day" and also have a **monthDays** modification in the **schedule** object. These kinds of restrictions are described in the table in the preceding section.
 
 | Example | Description |
-|---------|-------------|
+| --- | --- |
 | `{"hours":[5]}` | Run at 5:00 AM every day. |
 | `{"minutes":[15], "hours":[5]}` | Run at 5:15 AM every day. |
 | `{"minutes":[15], "hours":[5,17]}` | Run at 5:15 AM and 5:15 PM every day. |
@@ -371,7 +371,7 @@ The tumbling window trigger and the schedule trigger both operate on time heartb
 The following table provides a comparison of the tumbling window trigger and schedule trigger:
 
 |   | Tumbling window trigger | Schedule trigger |
-|---|-------------------------|------------------|
+| --- | --- | --- |
 | **Backfill scenarios** | Supported. Pipeline runs can be scheduled for windows in the past. | Not supported. Pipeline runs can be executed only on time periods from the current time and the future. |
 | **Reliability** | 100% reliability. Pipeline runs can be scheduled for all windows from a specified start date without gaps. | Less reliable. |
 | **Retry capability** | Supported. Failed pipeline runs have a default retry policy of 0, or a policy that's specified by the user in the trigger definition. Automatically retries when the pipeline runs fail due to concurrency/server/throttling limits (that is, status codes 400: User Error, 429: Too many requests, and 500: Internal Server error). | Not supported. |