Hi everyone,
When do we use a trigger of time “change after response” over “change”?
Below is a link to the documentation containing the trigger time element. For trigger of time “change after response”, the docs states that “The trigger will go off when the value of the specified parameter has changed and the incoming response has been fully received.”.
Is there a use case where we want to receive the entire response before checking if the parameter has changed?
Hi Khoo Chee Yang,
When having a basic serial response (no header, trailer, checksum, etc), DataMiner will fill in the response parameters one by one. This means that if the beginning of the defined response matches but not the end, your first parameters will be updated and if you trigger on “change” on those first parameters, the trigger will go off even if eventually the full response does not match which maybe be desired or not depending on the use-case. If not desired, this is when the “change after response” one becomes useful because that one will only go off when the response fully matches.
Example:
Response defined in connector as followed:
- param 101: read param with fixed length 1.
- param 102: fixed param with value _ZZZ.
If the data source sends back: A_ZZZ, this fully matches, both trigger on ‘change’ and trigger on ‘change after response’ would go off.
If the data source sends back: A_XYZ, this does not fully matches. However, DataMiner will first fill in A into param 101 because so far, things match and then only notice ‘_XYZ’ doesn’t match with param 102. In this case,
- trigger on ‘change’ on param 101 will still go off because param 101 did match. It will actually even potentially go off multiple times depending on your retry settings. Indeed, the full response does not match so retries will kick in.
- trigger on ‘change after response’ will not go off because the full response did not fully match.