Line Messaging API 사용

* 코딩 -> 테스트 -> 배포 -> 테스트 단계에서, fpm warning | Fatal 로그 등 이슈가 생겨야지만 뒤늦게 에러 핸들링하는 문제가 생김.

최소한 테스트 단계 혹은, 이슈 사항을 푸시받아서 고칠 수 있는 계기가 필요.

그래서 Line Messaging API 를 이용해서 fpm 경고 이상의 이벤트가 발생시, 개발자 방에 에러 로그를 푸시하는 것을 구현.

삽질 후, 정리하는 간략한 절차.

1. Line Developer 에서 계정 생성후, Messaging API Service 를 등록.

  - 계정 생성, 서비스 등록 등 기본적인 내용은 쉽게 찾아 볼 수 있어서 어렵지 않았음.

2. ssl 인증서 준비

  

  - Line Messaging API 서비스는 신뢰받는 SSL 인증서가 필요하기 때문. ssl 인증서를 발급 받은 후에, 설정 페이지에서 유효한지 확인할 수 있는 Webhook URL 입력창이 있음.

  - https 통신이기 때문에 https://ServerDomain/path/to/wenhook.php 경로에 대응하는 훅(hook) 파일을 생성하고, 테스트하는데 애를 좀 먹음..

3. line-bot-sdk 를 프로젝트에 포함.

  

  - ACCESS_TOKEN, ACCESS_SECRET 비밀 정보와, 라인 이벤트 발생시 webhook 파일에서 캐치할 수 있는 정보들(replyToken, room_id etc..) 을 조합하여 필요한 기능 구현

  - 라인 봇 -> (이벤트) -> webhook -> (이벤트 핸들링).  이 과정 속에서 필요한 정보, 얻을 수 있는 정보, 동작방식을 명확히 알고 있지 못해서 불필요한 삽질을 하였음. 참고로 webhook Request/Response 는 Json 형식으로 SDK API Docs 에 설명이 잘 나와 있었음.

 - php 를 사용하고 있기 때문에, webhook 파일의 확장자는 .php 였고 sdk 는 컴포저를 통해 설치하였다. (sdk 또한 많은 언어 버전이 존재)

4. white list !!!

  - 당연한거지만 webhook 을 통한 이벤트 핸들링에서의 signature 뿐만 아니라 IP Domain 에 대한 출입 허용을 Line 페이지에서 White List 란 설정에 webhook.php 가 있는 서버를 등록해주어야 하는데, 삽질을 하다보니 간과하고 마지막에 시간을 또 허비하였음.

각각의 단계에서 조그마한 삽질이 있긴 했었지만, 1~4번 이외에 큰 문제 없이 에러로그를 푸시받을 수 있었다. 

ps) 참고로 글을 작성하는 시점에서 Messaging API Service 는 한달에 100,000 건정도 이상.. 기억에 의존하는거라 정확하진 않지만, 원하는 기능을 위해 사용하기에는 충분히 큰 콜 수를 보장하므로 돈 걱정은 하지 않았다.

추가로 구현할 만한 작은 기능으로는, BitBucket Pull Request, Branch Merge 같은 이벤트 발생시 알림이나, 특정 명령어 커맨드를 입력받아서 어떤 작업(?) 을 할 수 있을 것 같다. 기능 자체는 제한적이다보니 엄~청 대단한 무언가를 만들기는 쉽진 않을 것 같다.

오늘 들었던 흥미로운 소식은..

http://m.news.naver.com/read.nhn?oid=028&aid=0002369755&sid1=105&backUrl=%2Fhome.nhn&light=off

인공지능끼리 협상 테스트 도중에 새로운 언어까지 생성했다는 소식.