How to debug services, functions in mashup using Browser DevTools
간편한 디버깅의 필요성
Thingworx Mashup 개발에는 Mashup에 연결된 Thing의 서비스, 세션 변수, UI 간의 이벤트 바인딩으로 로직을 구성하고 서비스 input/output 바인딩의 작업이 동반된다.
버튼을 누르면 텍스트를 출력하는 등의 간단한 로직의 경우에는 몇 번의 테스트 만으로도 서비스가 의도된 대로 동작하는지 확인할 수 있지만, 서비스의 개수가 많아질 수록, 바인딩된 이벤트가 많아질 수록 Mashup 기능의 복잡도가 증가하고 테스트가 힘들어 질 수 있다.
아무리 Thingworx가 Low Code Platform 이라고 할 지라도 모든 서비스에서 로그를 찍기엔 시스템 성능에 영향이 갈 수 있으니 부담스럽다.
특정 케이스로 실행시킬 때는 모든 서비스들이 의도한 대로 잘 실행되서 동작했는데 어떤 케이스 에서는 원하는대로 보이지 않는 경우도 있을 수 있다. 이 때는 연속적인 서비스들 중에 어느 서비스에서 문제를 발생시키는지 확인하기위해 일일히 몇십개가 되는 모든 서비스를 방문하여 테스트용 파라미터를 작성하고 저장해서 실행시켜보기에는 품이 너무 많이 든다.
단일 Mashup이 아니라 Mashup Container이나 Master Mashup이 지정되어있어서 여러 Mashup들이 조합된 화면이라면 문제는 더 크게 다가온다. 사실 한 화면에서 서비스가 많이 실행되는 것은 Mashup 로드 속도를 떨어트리기에 바람직한 구성은 아니긴 하지만, 간혹 모든 정보가 한 화면에서 확인 가능하기를 바라는 고객들의 요구사항이 있을 수도 있다.(물론 이런 경우는 일반적으로 집계용 서비스나 테이블을 분리하여 조회 속도를 향상시키기 위한 꼼수를 쓰는 등의 방법으로 최대한 상황을 회피하기위해 노력한다) 이런 특수한 경우에는 서비스가 백여개가 넘을수도 있고 그렇게 되면 오류가 발생했을 때 정확히 어느 서비스에서 문제되는지를 파악하기에 어려움을 겪을 수 밖에 없을 것이다.
ThingWorx Mashup
Mashup의 목적
Thingworx는 IoT 플렛폼으로 데이터를 수집하고, 수집한 데이터를 가공해서 유의미한 집계를 확인해서 보기위한 목적을 가진다.
물론 버튼과 데이터 입력등의 위젯을 통해 보고서 작성이라던가 수작업의 데이터 기입 등의 부가 기능들도 구현할 수는 있지만, 여러 제조업쪽 도입 사례들을 보면 Mashup 구현을 통한 가장 큰 목적은 가공된 데이터를 확인하는 모니터링 성향이 메인인듯 하다.
Mashup의 구성
Composer에서 Mashup을 개발하면 Mashup은 각종 서비스, 위젯, function, 세션 값들 사이를 이벤트 바인딩으로 긴밀하고 연쇄적으로 연결하고 triggering 해서 구성하게 된다.
Mashup 문제 발생 가능 지점
우리가 Mashup을 구성할 때, 화면이 의도한 대로 동작하지 않는 문제가 발생한 경우 원인이 될 가능성이 있는 부분은 한정되어있다.
- 서비스 실행에서 실행오류가 발생하여 다음 순서로 바인딩된 서비스가 실행되지 않거나 실패한 경우
- Mashup의 function/expression 기능에서 실행오류가 발생한 경우
- 위젯에서 해석할 수 없는 포멧의 값이 전달된 경우
이 중 function/expression 기능은 Mashup에서 간편하게 제공하는 js기반 가공이라 브라우저 개발자 도구에서는 디버깅이 힘들지만,
서비스는 하나의 Request로 요청되며 이는 브라우저 개발자 도구에서 순차적으로, 서비스 별로 모니터링 할 수 있으므로 확인이 간편하다.
브라우저 개발자 도구
실행방법
- F12를 통해 간편하게 개발자 도구를 실행할 수 있다.
- 브라우저 메뉴에서
도구 더보기>개발자 도구를 통해 개발자 도구를 실행할 수 있다.
네트워크(Network) 탭을 통해 서비스 호출 확인하기
Mashup 로드 후에 > test_A 실행 > test_B 실행 > test_C 실행 > test_D 실행 되는 로직이 있고, 각각의 서비스들이 선행 서비스가 호출이 완료되면 바인딩 된 다음 서비스를 실행시키는 ServiceInvokeCompleted 이벤트로 바인딩되어있다고 가정해보자.
모든 서비스가 오류없이 정상실행된 경우
모든 서비스가 오류없이 순차적으로 실행된 경우, 위의 이미지와 같이 개발자도구에서 모든 요청이 순차적으로 요청되었고, 200으로 응답코드가 반환된 것을 확인할 수 있다.
서비스 하나가 실패한 경우
위의 경우에서 test_C 서비스를 의도적으로 에러가 나게 수정하고 실행시켜 보겠다.
test_C 서비스가 500 응답코드로 실패하였고, 각 서비스들이 ServiceInvokeCompleted 이벤트로 바인딩되어있기 때문에 test_C 서비스 실행이 이벤트 발생 조건을 충족하지 못하여 test_D 서비스가 실행되지 않았음을 알 수 있다.
네트워크(Network) 탭을 통해 서비스 Input/Output 확인
브라우저 개발자 도구에서 서비스를 선택하여 해당 서비스의 Request와 Response의 상세 정보를 확인할 수 있다.
이를 통해 단일 서비스의 Input 파라미터와 Output 파라미터가 의도된 대로 흘러가는지 확인할 수 있다.
서비스 Input 파라미터 확인
확인하고자 하는 서비스를 선택하고 페이로드 탭을 확인하면 Input 파라미터 값을 확인할 수 있다.
서비스 Output 파라미터 확인
확인하고자 하는 서비스를 선택하고 응답 탭을 확인하면 Output 파라미터 값을 확인할 수 있다.
마치며
Thingworx에서도 서비스 에디터에서 테스트 데이터를 세팅하고 실행 해볼 수 있는 테스트 기능을 제공하고 있다. 하지만 글을 시작하며 개발자 도구를 사용한 테스트 필요성에 대해 이야기 했듯이, Thingworx에서 제공하는 테스트 기능은 단일 서비스 내 스크립트 범위에서만 가능하기 때문에 서비스들 간의 연결 테스트는 다른 서비스를 직접 참조하도록 스크립트를 수정/롤백 하거나 Mashup에서 바인딩을 하나씩 끊어가며 테스트 할 수 밖에 없다.
브라우저의 개발자 도구 기능을 통해 테스트의 정확도를 높이고 Thingworx 개발 효율을 향상시킬 수 있으므로 잘 활용해보자.