MQTT - AWS IoT Core
CONNECT, 및 DISCONNECT RECONNECT게시SubscribeKeep-Alive영구 세션

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

MQTT

CONNECT, 및 DISCONNECT RECONNECT

“장치 전송 CONNECT 대상 AWS IoT Core (해피 케이스)”

테스트 중인 디바이스가 CONNECT 요청을 보내는지 확인합니다.

API 테스트 사례 정의:

참고

EXECUTION_TIMEOUT의 기본값은 5분입니다. 제한 시간 값을 2분으로 설정하는 것을 권장합니다.

"tests":[
   {
      "name":"my_mqtt_connect_test",
      "configuration": {
         // optional:
         "EXECUTION_TIMEOUT":"300",   // in seconds
      },
      "test":{
         "id":"MQTT_Connect",
         "version":"0.0.0"
      }
   }
]
“장치는 QoS1에 대한 임의의 주제로 돌아PUBACK갈 수 있습니다.”

이 테스트 사례는 QoS1을 사용하여 주제를 구독한 후 브로커로부터 게시 PUBACK 메시지를 받은 경우 디바이스(클라이언트)가 메시지를 반환할 수 있는지 확인합니다.

페이로드 콘텐츠 및 페이로드 크기는 이 테스트 케이스에 대해 구성할 수 있습니다. 페이로드 크기가 구성된 경우 Device Advisor는 페이로드 콘텐츠 값을 덮어쓰고 미리 정의된 페이로드를 원하는 크기로 디바이스에 보냅니다. 페이로드 크기는 0에서 128 사이의 값이며 128KB를 초과할 수 없습니다. AWS IoT Core 는 AWS IoT Core 메시지 브로커 및 프로토콜 제한 및 할당량 페이지에 표시된 대로 128KB보다 큰 게시 및 연결 요청을 거부합니다.

API 테스트 사례 정의:

참고

EXECUTION_TIMEOUT의 기본값은 5분입니다. 제한 시간 값은 2분을 권장합니다. PAYLOAD_SIZE는 0에서 128KB 사이의 값으로 구성할 수 있습니다. Device Advisor는 지정된 크기의 사전 정의된 페이로드를 디바이스에 다시 전송하므로 페이로드 크기를 정의하면 페이로드 콘텐츠가 무시됩니다.

"tests":[                            
{
        "name":"my_mqtt_client_puback_qos1",
        "configuration": {
            // optional:"TRIGGER_TOPIC": "myTopic",
            "EXECUTION_TIMEOUT":"300", // in seconds
            "PAYLOAD_FOR_PUBLISH_VALIDATION":"custom payload",
            "PAYLOAD_SIZE":"100" // in kilobytes
        },
        "test": {
            "id": "MQTT_Client_Puback_QoS1",
            "version": "0.0.0"
        }
    }
]
'지터 백오프가 있는 디바이스 연결 재시도 - CONNACK 응답 없음'

테스트 중인 디바이스가 브로커와 5회 이상 다시 연결할 때 적절한 지터 백오프를 사용하는지 확인합니다. 브로커는 테스트 CONNECT 요청 중인 디바이스의 타임스탬프를 기록하고, 패킷 검증을 수행하고, 테스트 중인 디바이스CONNACK로 를 전송하지 않고 일시 중지하고, 테스트 중인 디바이스가 요청을 다시 전송할 때까지 기다립니다. 여섯 번째 연결 시도는 통과할 수 있으며 테스트 중인 디바이스로 다시 흐를 CONNACK 수 있습니다.

위의 프로세스가 다시 수행됩니다. 전체적으로 이 테스트 케이스는 디바이스가 총 12번 이상 연결되어야 합니다. 수집된 타임스탬프는 테스트 중인 디바이스에서 지터 백오프가 사용되는지 확인하는 데 사용됩니다. 테스트 중인 디바이스에 엄격하게 지수 백오프 지연이 있는 경우 이 테스트 케이스가 경고와 함께 통과됩니다.

이 테스트 사례를 통과하려면 테스트 중인 디바이스에서 지수 백오프 및 지터 메커니즘을 구현하는 것이 좋습니다.

API 테스트 사례 정의:

참고

EXECUTION_TIMEOUT의 기본값은 5분입니다. 시간 초과 값을 4분으로 설정하는 것이 좋습니다.

"tests":[
   {
      "name":"my_mqtt_jitter_backoff_retries_test",
      "configuration": {
         // optional:
         "EXECUTION_TIMEOUT":"300",    // in seconds
      },
      "test":{
         "id":"MQTT_Connect_Jitter_Backoff_Retries",
         "version":"0.0.0"
      }
   }
]
“기계 연결 재시도와 지수 백오프 - CONNACK 응답 없음”

테스트 중인 디바이스가 브로커와 5회 이상 다시 연결할 때 적절한 지수 백오프를 사용하는지 확인합니다. 브로커는 테스트 CONNECT 요청 중인 디바이스의 타임스탬프를 기록하고, 패킷 검증을 수행하고, 클라이언트 디바이스CONNACK로 를 전송하지 않고 일시 중지하고, 테스트 중인 디바이스가 요청을 다시 전송할 때까지 기다립니다. 수집된 타임스탬프는 테스트 중인 디바이스에서 지수 백오프가 사용되는지 확인하는 데 사용됩니다.

이 테스트 사례를 통과하려면 테스트 중인 디바이스에서 지수 백오프 및 지터 메커니즘을 구현하는 것이 좋습니다.

API 테스트 사례 정의:

참고

EXECUTION_TIMEOUT의 기본값은 5분입니다. 시간 초과 값을 4분으로 설정하는 것이 좋습니다.

"tests":[
   {
      "name":"my_mqtt_exponential_backoff_retries_test",
      "configuration": {
         // optional:
         "EXECUTION_TIMEOUT":"600",  // in seconds
      },
      "test":{
         "id":"MQTT_Connect_Exponential_Backoff_Retries",
         "version":"0.0.0"
      }
   }
]
“지터 백오프로 디바이스 재연결 - 서버 연결 해제 후”

테스트 중인 디바이스가 서버에서 연결 해제된 후 다시 연결하는 동안 필요한 지터 및 백오프를 사용하는지 검증합니다. Device Advisor는 디바이스를 서버에서 5회 이상 연결 해제하고 디바이스의 MQTT 재연결 동작을 관찰합니다. Device Advisor는 테스트 중인 디바이스에 대한 CONNECT 요청의 타임스탬프를 기록하고, 패킷 검증을 수행하고, 클라이언트 디바이스CONNACK로 를 전송하지 않고 일시 중지하고, 테스트 중인 디바이스가 요청을 다시 전송할 때까지 기다립니다. 수집된 타임스탬프는 테스트 중인 디바이스가 다시 연결하는 동안 지터와 백오프가 사용되는지 확인하는 데 사용됩니다. 테스트 중인 디바이스에 엄격한 지수 백오프가 있거나 적절한 지터 백오프 메커니즘을 구현하지 않는 경우 이 테스트 케이스는 경고와 함께 통과합니다. 테스트 중인 디바이스가 선형 백오프 또는 상수 백오프 메커니즘을 구현한 경우 테스트가 실패합니다.

이 테스트 사례를 통과하려면 테스트 중인 장치에서 지수 백오프 및 지터 메커니즘을 구현하는 것이 좋습니다.

API 테스트 사례 정의:

참고

EXECUTION_TIMEOUT의 기본값은 5분입니다. 시간 초과 값을 4분으로 설정하는 것이 좋습니다.

백오프에 대한 검증을 위한 재연결 시도 횟수는 RECONNECTION_ATTEMPTS를 지정하여 변경할 수 있습니다. 번호는 5~10 사이여야 합니다. 기본값은 5입니다.

"tests":[
   {
      "name":"my_mqtt_reconnect_backoff_retries_on_server_disconnect",
      "configuration":{
         // optional:
         "EXECUTION_TIMEOUT":"300",  // in seconds
         "RECONNECTION_ATTEMPTS": 5
      },
      "test":{
         "id":"MQTT_Reconnect_Backoff_Retries_On_Server_Disconnect",
         "version":"0.0.0"
      }
   }
]
"지터 백오프로 디바이스 재연결 - 연결 상태가 불안정한 경우"

테스트 중인 디바이스가 불안정한 연결에서 다시 연결하는 동안 필요한 지터 및 백오프를 사용하는지 확인합니다. Device Advisor는 5번의 연결 성공 후 서버에서 디바이스의 연결을 해제하고 디바이스의 MQTT 재연결 동작을 관찰합니다. Device Advisor는 테스트 중인 디바이스에 대한 CONNECT 요청의 타임스탬프를 기록하고, 패킷 검증을 수행하고, 를 다시 보내고CONNACK, 연결을 끊고, 연결 해제의 타임스탬프를 기록하고, 테스트 중인 디바이스가 요청을 다시 보낼 때까지 기다립니다. 수집된 타임스탬프는 성공적이지만 불안정한 연결 후 다시 연결하는 동안 테스트 중인 디바이스가 지터와 백오프를 사용하는지 확인하는 데 사용됩니다. 테스트 중인 디바이스에 엄격한 지수 백오프가 있거나 적절한 지터 백오프 메커니즘을 구현하지 않는 경우 이 테스트 케이스는 경고와 함께 통과합니다. 테스트 중인 디바이스가 선형 백오프 또는 상수 백오프 메커니즘을 구현한 경우 테스트가 실패합니다.

이 테스트 사례를 통과하려면 테스트 중인 장치에서 지수 백오프 및 지터 메커니즘을 구현하는 것이 좋습니다.

API 테스트 사례 정의:

참고

EXECUTION_TIMEOUT의 기본값은 5분입니다. 시간 초과 값을 4분으로 설정하는 것이 좋습니다.

백오프에 대한 검증을 위한 재연결 시도 횟수는 RECONNECTION_ATTEMPTS를 지정하여 변경할 수 있습니다. 번호는 5~10 사이여야 합니다. 기본값은 5입니다.

"tests":[
   {
      "name":"my_mqtt_reconnect_backoff_retries_on_unstable_connection",
      "configuration":{
         // optional:
         "EXECUTION_TIMEOUT":"300",  // in seconds
         "RECONNECTION_ATTEMPTS": 5
      },
      "test":{
         "id":"MQTT_Reconnect_Backoff_Retries_On_Unstable_Connection",
         "version":"0.0.0"
      }
   }
]

게시

“QoS0(해피 케이스)”

테스트 중인 디바이스가 QoS0 또는 QoS1이 포함된 메시지를 게시하는지 확인합니다. 테스트 설정에서 이 주제 값 및 페이로드를 지정하여 메시지 주제 및 페이로드의 유효성을 검사할 수도 있습니다.

참고

EXECUTION_TIMEOUT의 기본값은 5분입니다. 제한 시간 값을 2분으로 설정하는 것을 권장합니다.

"tests":[
   {
      "name":"my_mqtt_publish_test",
      "configuration":{
         // optional:
         "EXECUTION_TIMEOUT":"300",  // in seconds
         "TOPIC_FOR_PUBLISH_VALIDATION": "my_TOPIC_FOR_PUBLISH_VALIDATION",
         "PAYLOAD_FOR_PUBLISH_VALIDATION": "my_PAYLOAD_FOR_PUBLISH_VALIDATION",
      },
      "test":{
         "id":"MQTT_Publish",
         "version":"0.0.0"
      }
   }
]
“QoS1 게시 재시도 - 없음PUBACK”

브로커가 를 전송하지 않는 경우 테스트 중인 디바이스가 QoS1로 전송된 메시지를 다시 게시하는지 확인합니다PUBACK. 테스트 설정에서 이 주제를 지정하여 메시지 주제의 유효성을 검사할 수도 있습니다. 메시지를 다시 게시하기 전에 클라이언트 디바이스의 연결을 끊으면 안 됩니다. 또한 이 테스트는 다시 게시된 메시지의 패킷 식별자가 원본과 같은지 확인합니다. 테스트 실행 중에 디바이스의 연결이 끊겼다가 다시 연결되면 테스트 사례가 오류 없이 재설정되며 디바이스에서 테스트 사례 단계를 다시 수행해야 합니다.

API 테스트 사례 정의:

참고

EXECUTION_TIMEOUT의 기본값은 5분입니다. 적어도 4분이 권장됩니다.

"tests":[
   {
      "name":"my_mqtt_publish_retry_test",
      "configuration":{
         // optional:
         "EXECUTION_TIMEOUT":"300",  // in seconds
         "TOPIC_FOR_PUBLISH_VALIDATION": "my_TOPIC_FOR_PUBLISH_VALIDATION",
         "PAYLOAD_FOR_PUBLISH_VALIDATION": "my_PAYLOAD_FOR_PUBLISH_VALIDATION",
      },
      "test":{
         "id":"MQTT_Publish_Retry_No_Puback",
         "version":"0.0.0"
      }
   }
]
'보관된 메시지 게시'

테스트 중인 디바이스가 retainFlag가 true로 설정된 메시지를 게시하는지 확인합니다. 테스트 설정에서 이 주제 값 및 페이로드를 지정하여 메시지 주제 및 페이로드의 유효성을 검사할 수 있습니다. PUBLISH 패킷 내에서 retainFlag 전송된 이 true로 설정되지 않으면 테스트 사례가 실패합니다.

API 테스트 사례 정의:

참고

EXECUTION_TIMEOUT의 기본값은 5분입니다. 제한 시간 값을 2분으로 설정하는 것을 권장합니다. 이 테스트 케이스를 실행하려면 디바이스 역할에 iot:RetainPublish 작업을 추가합니다.

"tests":[
   {
      "name":"my_mqtt_publish_retained_messages_test",
      "configuration":{
         // optional:
         "EXECUTION_TIMEOUT":"300",  // in seconds
         "TOPIC_FOR_PUBLISH_RETAINED_VALIDATION": "my_TOPIC_FOR_PUBLISH_RETAINED_VALIDATION",
         "PAYLOAD_FOR_PUBLISH_RETAINED_VALIDATION": "my_PAYLOAD_FOR_PUBLISH_RETAINED_VALIDATION",
      },
      "test":{
         "id":"MQTT_Publish_Retained_Messages",
         "version":"0.0.0"
      }
   }
]
'사용자 속성을 포함한 게시'

테스트 중인 디바이스가 올바른 사용자 속성이 포함된 메시지를 게시하는지 확인합니다. 테스트 설정에서 이름-값 페어를 설정하여 사용자 속성의 유효성을 검사할 수 있습니다. 사용자 속성이 제공되지 않거나 일치하지 않는 경우 테스트 케이스가 실패합니다.

API 테스트 사례 정의:

참고

이는 MQTT5 유일한 테스트 사례입니다.

EXECUTION_TIMEOUT의 기본값은 5분입니다. 제한 시간 값을 2분으로 설정하는 것을 권장합니다.

"tests":[
   {
      "name":"my_mqtt_user_property_test",
      "test":{
        "USER_PROPERTIES": [
            {"name": "name1", "value":"value1"},
            {"name": "name2", "value":"value2"}
        ],
        "EXECUTION_TIMEOUT":"300",  // in seconds
      },
      "test":{
         "id":"MQTT_Publish_User_Property",
         "version":"0.0.0"
      }
   }
]

Subscribe

“구독 가능(해피 케이스)”

테스트 중인 디바이스가 MQTT 주제를 구독하는지 확인합니다. 테스트 설정에서 이 주제를 지정하여 테스트 중인 디바이스가 구독하는 주제의 유효성을 검사할 수도 있습니다.

API 테스트 사례 정의:

참고

EXECUTION_TIMEOUT의 기본값은 5분입니다. 제한 시간 값을 2분으로 설정하는 것을 권장합니다.

"tests":[
   {
      "name":"my_mqtt_subscribe_test",
      "configuration":{
         // optional:
         "EXECUTION_TIMEOUT":"300",  // in seconds
         "TOPIC_LIST_FOR_SUBSCRIPTION_VALIDATION":["my_TOPIC_FOR_PUBLISH_VALIDATION_a","my_TOPIC_FOR_PUBLISH_VALIDATION_b"]
      },
      "test":{
         "id":"MQTT_Subscribe",
         "version":"0.0.0"
      }
   }
]
“재시도 구독 - 아니요SUBACK”

테스트 중인 디바이스가 실패한 MQTT 주제 구독을 재시도하는지 확인합니다. 그러면 서버가 를 기다리고 를 보내지 않습니다SUBACK. 클라이언트 디바이스가 구독을 다시 시도하지 않으면 테스트가 실패합니다. 클라이언트 디바이스는 동일한 패킷 ID로 실패한 구독을 다시 시도해야 합니다. 테스트 설정에서 이 주제를 지정하여 테스트 중인 디바이스가 구독하는 주제의 유효성을 검사할 수도 있습니다. 테스트 실행 중에 디바이스의 연결이 끊겼다가 다시 연결되면 테스트 사례가 오류 없이 재설정되며 디바이스에서 테스트 사례 단계를 다시 수행해야 합니다.

API 테스트 사례 정의:

참고

EXECUTION_TIMEOUT의 기본값은 5분입니다. 시간 초과 값을 4분으로 설정하는 것이 좋습니다.

"tests":[
   {
      "name":"my_mqtt_subscribe_retry_test",
      "configuration":{
         "EXECUTION_TIMEOUT":"300",  // in seconds
         // optional:
         "TOPIC_LIST_FOR_SUBSCRIPTION_VALIDATION":["myTOPIC_FOR_PUBLISH_VALIDATION_a","my_TOPIC_FOR_PUBLISH_VALIDATION_b"]
      },
      "test":{
         "id":"MQTT_Subscribe_Retry_No_Suback",
         "version":"0.0.0"
      }
   }
]

Keep-Alive

“Mqtt No Ack PingResp”

이 테스트 사례는 테스트 중인 디바이스가 ping 응답을 받지 못했을 때 연결이 해제되었는지 확인합니다. 이 테스트 사례의 일환으로 Device Advisor는 게시, 구독 및 ping 요청을 AWS IoT Core 위해 에서 보낸 응답을 차단합니다. 또한 테스트 중인 디바이스가 MQTT 연결을 끊는지 확인합니다.

API 테스트 사례 정의:

참고

EXECUTION_TIMEOUT의 기본값은 5분입니다. 시간 제한을 keepAliveTime 값의 1.5배보다 크게 설정하는 것이 좋습니다.

이 테스트의 최대 keepAliveTime 시간은 230초를 초과하지 않아야 합니다.

"tests":[
    {
       "name":"Mqtt No Ack PingResp",
       "configuration": 
          //optional:
          "EXECUTION_TIMEOUT":"306",   // in seconds
       },
       "test":{
          "id":"MQTT_No_Ack_PingResp",
          "version":"0.0.0"
       }
    }
]

영구 세션

‘영구 세션(해피 케이스)’

이 테스트 케이스는 영구 세션에서 연결이 끊어질 때 디바이스 동작을 검증합니다. 테스트 케이스는 디바이스가 다시 연결되고, 명시적으로 재구독하지 않은 채로 트리거 주제에 대한 구독을 다시 시작하고, 주제에 저장된 메시지를 수신하고, 영구 세션에서 예상대로 작동할 수 있는지 확인합니다. 이 테스트 사례가 통과하면 클라이언트 디바이스가 예상대로 AWS IoT Core 브로커와 지속적인 세션을 유지할 수 있음을 나타냅니다. AWS IoT 영구 세션에 대한 자세한 내용은 MQTT 영구 세션 사용을 참조하세요.

이 테스트의 경우 클라이언트 디바이스는 깨끗한 세션 플래그가 false로 설정된 CONNECT AWS IoT Core 상태로 를 실행한 다음 트리거 주제를 구독해야 합니다. 구독에 성공하면 AWS IoT Core Device Advisor에서 디바이스의 연결을 해제합니다. 디바이스가 연결이 끊긴 상태인 동안 QoS 1 메시지 페이로드가 해당 주제에 저장됩니다. 그런 다음 Device Advisor는 클라이언트 디바이스가 테스트 엔드포인트에 다시 연결할 수 있도록 허용합니다. 이 시점에서 영구 세션이 있으므로 클라이언트 디바이스는 추가 SUBSCRIBE 패킷을 전송하지 않고 주제 구독을 재개하고 브로커로부터 QoS 1 메시지를 수신해야 합니다. 다시 연결한 후 클라이언트 디바이스가 추가 SUBSCRIBE 패킷을 전송하여 트리거 주제를 다시 구독하거나 클라이언트가 트리거 주제에서 저장된 메시지를 수신하지 못하면 테스트 사례가 실패합니다.

API 테스트 사례 정의:

참고

EXECUTION_TIMEOUT의 기본값은 5분입니다. 시간 초과 값을 최소한 4분으로 설정하는 것이 좋습니다. 첫 번째 연결에서 클라이언트 디바이스는 이전에 구독한 적이 없는 TRIGGER_TOPIC을 명시적으로 구독해야 합니다. 테스트 케이스를 통과하려면 클라이언트 디바이스가 QoS 1을 사용하여 TRIGGER_TOPIC을 성공적으로 구독해야 합니다. 다시 연결한 후 클라이언트 디바이스는 활성 영구 세션이 있음을 이해해야 합니다. 따라서 트리거 주제에서 보낸 저장된 메시지를 수락하고 해당 특정 메시지에 PUBACK 대해 반환해야 합니다.

"tests":[
   {
      "name":"my_mqtt_persistent_session_happy_case",
      "configuration":{
         //required:
         "TRIGGER_TOPIC": "myTrigger/topic",
         // optional:
         // if Payload not provided, a string will be stored in the trigger topic to be sent back to the client device
         "PAYLOAD": "The message which should be received from AWS IoT Broker after re-connecting to a persistent session from the specified trigger topic.",            
         "EXECUTION_TIMEOUT":"300" // in seconds
      },
      "test":{
         "id":"MQTT_Persistent_Session_Happy_Case",
         "version":"0.0.0"
      }
   }
]
“영구 세션 - 세션 만료”

이 테스트 케이스는 연결이 해제된 디바이스가 만료된 영구 세션에 다시 연결할 때 디바이스 동작을 검증하는 데 도움을 줍니다. 세션이 만료되면 디바이스가 새 SUBSCRIBE 패킷을 명시적으로 전송하여 이전에 구독한 주제를 다시 구독할 것으로 예상됩니다.

첫 번째 연결 중에 테스트 디바이스가 AWS IoT 브로커CONNECT와 함께 가 될 것으로 예상합니다. 영구 세션을 시작하기 위해 CleanSession 플래그가 false로 설정되기 때문입니다. 그러면 디바이스가 트리거 주제를 구독할 것입니다. 그런 다음 영구 세션을 성공적으로 구독하고 시작한 후 AWS IoT Core Device Advisor에서 디바이스 연결을 해제합니다. 연결이 끊긴 후 AWS IoT Core Device Advisor를 사용하면 테스트 디바이스가 테스트 엔드포인트와 다시 연결할 수 있습니다. 이때 테스트 디바이스가 다른 CONNECT 패킷을 전송하면 AWS IoT Core Device Advisor는 영구 세션이 만료되었음을 나타내는 CONNACK 패킷을 다시 보냅니다. 테스트 디바이스는 이 패킷을 올바르게 해석해야 하며 영구 세션이 종료될 때 동일한 트리거 주제를 다시 구독할 것으로 기대됩니다. 테스트 디바이스가 주제 트리거를 다시 구독하지 않으면 테스트 케이스가 실패합니다. 테스트를 통과하려면 디바이스가 영구 세션이 종료되었음을 이해하고 두 번째 연결에서 동일한 트리거 주제에 대한 새 SUBSCRIBE 패킷을 다시 보내야 합니다.

테스트 디바이스가 이 테스트 케이스를 통과하면 디바이스가 영구 세션 만료 시 기대되는 방식으로 재연결을 처리할 수 있다는 뜻입니다.

API 테스트 사례 정의:

참고

EXECUTION_TIMEOUT의 기본값은 5분입니다. 시간 초과 값을 최소한 4분으로 설정하는 것이 좋습니다. 테스트 디바이스는 이전에 구독한 적이 없는 TRIGGER_TOPIC을 명시적으로 구독해야 합니다. 테스트 사례를 전달하려면 테스트 디바이스가 CleanSession 플래그가 false로 설정된 CONNECT 패킷을 전송하고 QoS 1로 트리거 주제를 성공적으로 구독해야 합니다. 연결에 성공하면 AWS IoT Core Device Advisor가 디바이스 연결을 끊습니다. 연결이 끊어지면 AWS IoT Core 디바이스 어드바이저는 디바이스가 다시 연결되도록 허용하며, TRIGGER_TOPIC AWS IoT Core Device Advisor가 영구 세션을 종료했을 것이므로 디바이스가 동일한 를 다시 구독할 것으로 예상됩니다.

"tests":[
   {
      "name":"my_expired_persistent_session_test",
      "configuration":{
         //required:
         "TRIGGER_TOPIC": "myTrigger/topic",
         // optional:       
         "EXECUTION_TIMEOUT":"300" // in seconds
      },
      "test":{
         "id":"MQTT_Expired_Persistent_Session",
         "version":"0.0.0"
      }
   }
]