소개

응답하는 bot를 slack과 integromat를 제휴해 작성해, 겨우 의문이 남는 곳이 해소되었으므로, 정리했습니다.
포인트는

받은 Webhook은 3초 이내에 응답을 반환합니다

bot와 사용자 (bot 이외)를 구별하자

입니다.

메시지를 보낼 때 EventAPI 발생

인증시의 EventAPI에 대해서는, 여기 에 기재했습니다.

유저의 메세지 송신 이외에 bot로부터의 메세지 송신에 대해서도 EventAPI가 송신됩니다.

사용자가 slack에서 메시지를 보낼 때의 흐름

Webhook 내용

일부 요소는 가려져 있습니다.
사용하는 파라미터는

event.type

event.text

event.user

event.channel

webhook에 대한 응답은 3초 이내에

Webhook에 대한 요청은 bot도 사용자처럼 전송됩니다.
둘 다 응답에 상태 200을 반환하고 EventAPI로 3초 이내에 반환합니다.
이후의 처리는 bot의 userid를 취득해 필터의 대상으로 합니다.

다만, 실제로 짜낸 이 시나리오에서는 3초 이내에 리턴할 수 없는 것이 그대로 있었습니다.

취득한 text로부터 데이터를 취득

매우 적당한 테스트 데이터입니다.
data store에서 가져올 때도 다른 리소스에서 얻는 방법은 여러 가지가 있기 때문에
참고 정도로.

Bundle별로 취득한 데이터를 하나의 Bundle의 Array에

Array를 필터링하여 요소를 검색합니다.

메시지 보내기

channel에는 event.channel을 사용합니다.
메시지를 보내려면 im.open에서 채널을 열어야 하지만 bot 앱의 메시지 입력란에는 처음부터 열려 있습니다.

bot에서 메시지를 보낸 후의 흐름

요청을 받고 응답을 반환하는 것만을 적절하게 응답하면
반복 bot 메시지가 전송되는 루프로 들어갑니다.

오류로 판단되는 조건 확인

여기를 확인하십시오.
htps : // 아피. scck. 코 m / 에ぇ ぇ ぇ ぇ ぇ ょ ゔ ぇ ts ゜ ゜ ぃ え ゜ ㅇ ㅇ s

Router에서 Webhook의 응답과 텍스트 검색을 병렬로 했을 때 반복적으로 보낸 메시지가 표시되므로 직렬로 수정했습니다.
Virify 즈미의 Webhook에 3초 규칙하지 않으면 최대 3회 메시지가 던집니다.

헤더에 이유와 실시 횟수를 곱하여 전송되어 오므로, 메시지가 반복되면 필요 체크입니다.

재시도 요청을 받은 후 흐름

상태 코드에 502, header에 X-slack-No-Retry

마지막으로

integromat에서 slack을 다루는 경우, 모듈이 준비되어 있기 때문에 대체로 그쪽을 사용하면 지장은 없을까 생각합니다. workspace에 integromat 앱을 추가하는 부분이 기피 요소였습니다.
시나리오라면 API 레벨에서 무엇을 하고 있는지 알기 위해서는 서버도 필요없고, 에러 대응도 독자적으로 짜는 것이 좋은 곳이라고 생각합니다.
좋지 않은 곳에서는 Webhook 초기화에 1 초 가까이 걸리는 경우도 확인하고,
사용하는 모듈이 늘어나면 모든 것을 초기화하는 시간이 Webhook의 응답을 지연시켰다.