API를 사용하여 대화 상자 수정

REST API는 프로그래밍 방식으로 대화 상자 수정을 지원합니다. /dialog_nodes API를 사용하여 대화 노드를 작성, 삭제 또는 수정할 수 있습니다.

대화 상자는 상호 연결된 노드의 트리이며 올바른 특정 규칙을 준수해야 합니다. 대화 상자 노드를 변경하면 다른 노드 또는 대화 상자의 구조에 연쇄적인 영향을 줄 수 있습니다. /dialog_nodes API를 사용하여 대화 상자를 수정하기 전에 변경사항이 나머지 대화 상자에 미치는 영향을 이해해야 합니다. 현재 대화 상자의 백업 사본을 작성할 수 있습니다. 자세한 정보는 데이터 백업 및 복원 을 참조하십시오.

올바른 대화는 항상 다음 기준을 충족시킵니다.

• 각 대화 노드에는 고유 ID가 있습니다(dialog_node 특성).

• 하위 노드는 상위 노드를 인식합니다(parent 특성). 하지만 상위 노드는 하위를 인식하지 못합니다.

• 노드는 바로 이전 동위(있는 경우)를 인식합니다(previous_sibling 특성). 상위를 공유하는 모든 동위는 각 노드가 이전 노드를 가리키는 링크된 목록을 형성합니다.

• 상위의 한 하위만 첫 번째 동위가 될 수 있습니다 ( previous_sibling 가 널임을 의미함).

• 노드는 다른 상위의 하위인 이전 동위를 가리킬 수 없습니다.

• 두 노드는 동일한 이전 동위를 가리킬 수 없습니다.

• 노드는 다음에 실행될 다른 노드를 지정할 수 있습니다 ( next_step 특성).

• 노드는 자신의 상위 또는 동위가 될 수 없습니다.

• 노드는 다음 값 중 하나를 포함하는 유형 특성이 있어야 합니다. 유형 특성이 지정되지 않은 경우, 유형은 standard입니다.

  • event_handler: 프레임 노드 또는 개별 슬롯 노드에 대해 정의된 핸들러입니다.

  도구에서 슬롯이 있는 노드의 핸들러 관리 링크를 클릭하여 프레임 노드 핸들러를 정의할 수 있습니다. (도구 사용자 인터페이스는 슬롯 레벨 이벤트 핸들러를 노출하지 않지만 API를 통해 정의할 수 있습니다.)

  • frame: slot 유형의 하나 이상의 하위 노드가 있는 노드. 서비스가 프레임 노드를 종료하기 전에 모든 하위 슬롯 노드를 채워야 합니다.

  프레임 노드 유형은 도구에서 슬롯이 있는 노드로 표시됩니다. 슬롯을 포함하는 노드는 유형=frame의 노드로 표시됩니다. slot 유형의 하위 노드로 표시되는 각 슬롯에 대한 상위 노드입니다.

  • response_condition: 조건부 응답.

  도구에서 노드에 하나 이상의 조건부 응답을 추가할 수 있습니다. 사용자가 정의하는 각 조건부 응답은 JSON 기본 JSON에서 type=response_condition의 개별 노드로 표현됩니다.

  • slot: frame 유형의 노드의 하위 노드.

  이 노드 유형은 도구에서 단일 노드에 추가되는 여러 슬롯 중 하나로 표시됩니다. 이 단일 노드는 JSON에서 frame 유형의 상위 노드로 표시됩니다.

  • standard: 일반 대화 노드. 이는 기본 유형입니다.

• 동일한 상위 노드가 있는 slot 유형 노드의 경우 동위 순서 ( previous_sibling 특성으로 지정됨) 는 슬롯이 처리되는 순서를 반영합니다.

• slot 유형의 노드는 frame 유형의 상위 노드가 있어야 합니다.

• frame 유형의 노드는 적어도 하나 이상의 slot 유형의 하위 노드가 있어야 합니다.

• response_condition 유형의 노드는 standard 또는 frame 유형의 상위 노드가 있어야 합니다.

• response_condition 및 event_handler 유형의 노드는 하위를 가질 수 없습니다.

• event_handler 유형의 노드는 노드 이벤트의 유형을 식별하는 다음 값 중 하나를 포함하는 event_name 특성이 있어야 합니다.

  • filled: 사용자가 슬롯의 검사 대상 필드에 지정된 조건을 충족하는 값을 제공하고 슬롯이 채워진 경우 수행할 작업을 정의합니다. 슬롯에 대해 찾음 조건이 정의된 경우에만 이 이름의 핸들러가 표시됩니다.
  • focus: 슬롯에 필요한 정보를 제공하도록 사용자에게 프롬프트를 표시하는 질문을 정의합니다. 슬롯이 필요한 경우에만 이 이름의 핸들러가 표시됩니다.
  • generic: 슬롯 또는 노드를 슬롯으로 채우는 동안 사용자가 문의할 수 있는 관련없는 질문을 처리할 수 있는 조건을 정의합니다.
  • input: 슬롯을 채우기위해 사용자로부터 수집된 값에 컨텍스트 변수를 포함하도록 메시지 컨텍스트를 업데이트합니다. 이 이름의 핸들러는 프레임 노드의 각 슬롯에서 표시되어야 합니다.
  • nomatch: 슬롯 프롬프트에 대한 사용자의 응답에 올바른 값이 없는 경우 수행할 작업을 정의합니다. 슬롯에 대해 찾을 수 없음 조건이 정의된 경우에만 이 이름의 핸들러가 표시됩니다.

  다음 다이어그램은 도구 사용자 인터페이스에서 이름 지정된 각 이벤트에 대해 트리거되는 코드를 정의하는 위치를 보여줍니다.

  

• event_handler의 event_name을 갖는 generic 유형의 노드는 slot 또는 frame 유형의 상위를 가질 수 있습니다.

• event_handler, focus, input 또는 filled의 event_name을 갖는 nomatch 유형의 노드는 slot 유형의 상위가 있어야 합니다.

• event_name이 동일한 둘 이상의 event_handler가 동일한 상위 노드와 연관된 경우 동위의 순서는 이벤트 핸들러가 실행되는 순서입니다.

• 동일한 상위 슬롯 노드를 갖는 event_handler 노드의 경우 노드 정의 배치에 관계없이 실행 순서가 동일합니다. 이벤트는 event_name에서 이 순서대로 트리거합니다.

  1. 초점
  2. 입력
  3. filled
  4. generic*
  5. nomatch
  • event_name generic 이 있는 event_handler 가 이 슬롯 또는 상위 프레임에 대해 정의된 경우, 채워진 event_handler 노드와 nomatch event_handler 노드 사이에서 실행됩니다.

다음 예제에서는 여러 수정으로 인해 연쇄 변경이 일어나는 방식을 보여줍니다.

노드 작성

다음 단순 대화 트리를 고려하십시오.

다음 본문으로 /dialog_nodes에 대한 POST 요청을 작성하여 노드를 새로 작성할 수 있습니다.

{
  "dialog_node": "node_8"
}

이제 대화는 다음과 같습니다.

** 또는 **의 값을 지정하지 않고 parentnode_8previous_sibling을 작성했으므로 이제 이 노드는 대화의 첫 번째 노드입니다. node_8 을 작성하는 것 외에도 서비스는 해당 previous_sibling 특성이 새 노드를 가리키도록 node_1 도 수정했습니다.

상위 및 이전 동위를 지정하여 대화의 다른 위치에 노드를 작성할 수 있습니다.

{
  "dialog_node": "node_9",
  "parent": "node_2",
  "previous_sibling": "node_5"
}

parent 및 previous_node 에 대해 지정하는 값은 유효해야 합니다.

• 두 값 모두 기존 노드를 참조해야 합니다.
• 지정된 상위가 이전 동위의 상위(이전 동위에 상위가 없는 경우 null)와 동일해야 합니다.
• 상위는 response_condition 또는 event_handler 유형의 노드일 수 없습니다.

결과 대화는 다음과 같습니다.

서비스는 node_9을 작성하는 것 외에, 새 노드를 가리키도록 previous_siblingnode_6*의 * 특성을 자동으로 업데이트합니다.

노드를 다른 상위로 이동

다음 본문과 함께 POST /dialog_nodes/node_5 메소드를 사용하여 node_5 를 다른 상위로 이동하십시오.

{
  "parent": "node_1"
}

parent에 지정된 값이 올바른 값이어야 합니다.

• 기존 노드를 참조해야 합니다.
• 수정된 노드를 참조해서는 안됩니다 (노드는 자체 상위가 될 수 없음).
• 수정된 노드의 하위를 참조하지 않아야 합니다.
• response_condition 또는 event_handler 유형의 노드를 참조하면 안됩니다.

이 결과 다음과 같이 변경된 구조가 나타납니다.

여기서 몇 가지 상황이 발생했습니다.

• node_5가 새 상위로 이동할 때 node_7도 함께 이동했습니다(parentnode_7**의 ** 값이 변경되지 않았음). 노드를 이동하면 해당 노드의 모든 하위도 함께 이동하게 됩니다.
• previous_siblingnode_5**의 ** 값을 지정하지 않았으므로 이제 이 노드는 node_1 아래에서 첫 번째 동위가 됩니다.
• previous_siblingnode_4**의 ** 특성이 node_5로 업데이트되었습니다.
• node_9 의 previous_sibling 특성은 이제 node_2 아래의 첫 번째 동위이므로 null (으) 로 업데이트되었습니다.

동위 재시퀀싱

이제 다음 본문과 함께 POST /dialog_nodes/node_5 메소드를 사용하여 첫 번째가 아닌 두 번째 동위로 node_5 를 설정하십시오.

{
  "previous_sibling": "node_4"
}

previous_sibling을 수정할 때 새 값이 올바른 값이어야 합니다.

• 기존 노드를 참조해야 합니다.
• 수정된 노드를 참조하지 않아야 합니다 (노드는 자체 동위가 될 수 없음).
• 동일한 상위의 하위를 참조해야 합니다(모든 동위에 동일한 상위가 있어야 함).

구조는 다음과 같이 변경됩니다.

Node_7 은 상위와 함께 유지됩니다. 또한 node_4 는 이제 첫 번째 동위이므로 previous_sibling 가 null 가 되도록 수정됩니다.

노드 삭제

DELETE /dialog_nodes/node_1 메소드를 사용하여 node_1 을 삭제하십시오.

결과는 다음과 같습니다.

Node_1, node_4, node_5 및 node_7 이 모두 삭제되었습니다. 노드를 삭제하면 해당 노드의 모든 하위도 삭제됩니다. 따라서 루트 노드를 삭제하면 대화 트리의 전체 분기가 삭제됩니다. 삭제된 노드에 대한 다른 모든 참조(예: next_step 참조)가 null로 변경됩니다.

또한 node_2가 node_8을 새 이전 동위로 가리키도록 업데이트됩니다.

노드 이름 바꾸기

다음 본문과 함께 POST /dialog_nodes/node_2 메소드를 사용하여 node_2 의 이름을 바꾸십시오.

{
  "dialog_node": "node_X"
}

대화 상자의 구조가 변경되지 않았지만 변경된 이름을 반영하도록 여러 노드가 수정되었습니다.

• parentnode_9** 및 node_6의 ** 특성
• previous_siblingnode_3**의 ** 특성

삭제된 노드에 대한 다른 모든 참조(예: next_step 참조)도 변경됩니다.