API Post Event#
The task API Post Event is a Task that posts an event into the Data Platform event ingestion.
Details#
| Fields | Details |
|---|---|
| Scope | Connect IoT Data Platform Enterprise Integration Factory Automation |
| Workflow | Data flow Control flow |
IsProtocol flag |
Inputs#
| Name | Data Type | Description |
|---|---|---|
| Application Name | String | The application name for the event posting |
| Event Time | DateTime | The time when the event was triggered |
| Raw Values | Any | The values to be sent to the Data Platform |
| Activate | Any | Activates the task execution |
Outputs#
| Name | Data Type | Description |
|---|---|---|
| Success | Boolean | Returns true if the event was posted successfully |
| Error | Error | Error that occurred during the processing of this task |
Settings#
On the General Tab, there are the following settings:
| Name | Data Type | Default | Description |
|---|---|---|---|
| Application Name | String | MES | The application name for the event posting |
| Event Time | DateTime | The time when the event was triggered | |
| Event | String | IoT Event Definition full name (for example \\IoTEventDefinitions\CDM\Material\MaterialOperations) to which post MES request should be performed |
And the following retries settings:
| Setting | Data Type | Default | Description |
|---|---|---|---|
| Number of Retries | integer | 30 | The maximum number of attempts the IoT process (client) makes to call the MES backend. Only the transient failures listed in Retry Mechanism are retried; any other failure is reported without a further attempt. |
| Sleep Time between retries (ms) | integer | 1000 | Number of milliseconds to wait after each attempt that ends in a transient failure, including the last attempt, before the task reports the error. |
| Number of System Retries | integer | 10 | The maximum number of attempts the MES backend makes to call the target service if the execution fails. |
Multiplicative Retry Effect
Retry limits are cumulative. In the event of a persistent target service failure, the total number of requests generated will be the product of the Client Retries (N) and the Backend Retries (M). For example, if both are set to 10, a single IoT request could result in up to 100 total attempts (N x M), which may lead to system congestion or high latency.
Behavior#
The task is used to generate information that will be received and saved by an IoT Consumer. It posts the IoT Event with the supplied raw values as well as the dynamic inputs inherited from the IoT Event Definition and sends all values as payload.
When a property is in Raw Values and a dynamic input of the same name has a value, the value of the dynamic input is sent.
A value received on the service Retries (numberOfRetries) input replaces Number of System Retries and is sent to MES as the number of system retries.
When the MES cannot process the posted event, the task returns the errors on the Error output and the MES publishes the event to the <systemname>_dp_iotevents_dlq Kafka dead-letter topic instead of the topic of the IoT Event Definition. This happens when the event does not have the required fields, when the current user has no write access to the Data Group of the IoT Event Definition, or when the event fails processing, for example, because the IoT Event Definition is not found or the raw values do not comply with its IoT Schema. The dead-letter message contains the errors together with the event data, and its headers include an ErrorContext header that identifies the failure, in addition to the IoT Event Definition headers when the definition is known.