작업 허브를 통해 데이터 공유

Looker의 내장 대상에 콘텐츠를 전달하는 것 외에도 작업(통합이라고도 함)을 사용하여 작업 허브 서버를 통해 Looker와 통합된 타사 서비스에 콘텐츠를 전송할 수도 있습니다.

작업 허브 서버를 통해 제공되는 작업은 action LookML 매개변수로 정의되는 데이터 작업과 다릅니다.

이 페이지에서는 Looker 작업 허브에 추가 또는 자체 비공개 작업 허브 서버에 추가하도록 요청할 수 있는 커스텀 작업 빌드 옵션을 안내합니다. 또한 오프라인 작업 허브 서버를 가동하여 맞춤 작업을 테스트하거나 비공개 작업 허브 서버를 실행하는 방법도 설명합니다.

아래 그래픽은 비공개 호스팅 작업 허브 또는 Looker 호스팅 작업 허브를 통해 작업을 통합하는 데 사용할 수 있는 워크플로 옵션을 보여줍니다.

작업이 작업 허브에 추가되면 Looker 관리자는 이러한 서비스를 Looker 콘텐츠를 전송하는 데 사용할 수 있도록 사용 설정할 수 있습니다.

Looker 작업 허브를 통해 Looker 통합을 사용하고 비공개 또는 커스텀 작업을 호스팅하려는 경우 여러 작업 허브를 설정할 수도 있습니다. 각 작업 허브의 작업은 관리 패널의 작업 페이지에 표시됩니다.

Looker 작업 허브

Looker는 Looker&Action API를 구현하고 인기 있는 작업을 노출하는 스테이트리스(Stateless) 서버인 Looker Action Hub를 호스팅하고 제공합니다. 사용자가 작업을 사용하여 전송하는 모든 데이터는 Looker 인스턴스가 아닌 Looker Action Hub 서버에서 일시적으로 처리됩니다.

Looker는 이미 여러 서비스와 통합되었습니다. 기존 서비스를 사용 설정하는 방법을 알아보려면 관리자 설정 - 작업 문서 페이지를 참고하세요.

Looker 작업 허브 요구사항

Looker 통합을 사용하려면 Looker 작업 허브가 Looker 인스턴스와 통신하고 이 요구사항을 충족할 수 있어야 합니다. 고객이 호스팅하는 인스턴스 관리자는 Looker Action Hub의 Looker 통합, 특히 스트리밍 결과를 지원하거나 OAuth를 사용하는 통합을 선택할 때 추가 요인을 고려해야 할 수 있습니다.

Looker 작업 허브는 다음과 같은 방법으로 API 요청을 주고받을 수 있어야 합니다.

Looker 배포에서 이러한 요청을 처리할 수 없거나 Looker 인스턴스에서 IP 허용 목록 기능을 사용 설정한 경우 로컬 작업 허브 서버를 설정하여 비공개 Looker 통합 또는 커스텀 작업을 제공하는 것이 좋습니다. 고객이 호스팅하는 인스턴스의 관리자는 OAuth 및 스트리밍 작업 전용 로컬 작업 서버를 배포할 수도 있습니다.

Looker 인스턴스의 Looker 작업 허브 네트워크 요청

actions.looker.com에 대한 요청은 동적 IP 주소로 변환됩니다. Looker 인스턴스의 발신 요청은 다음 엔드포인트에 도달할 수 있어야 합니다.

actions.looker.com/
actions.looker.com/actions/<name>/execute
actions.looker.com/actions/<name>/form

여기서 name은 작업의 프로그래매틱 이름입니다.

Looker 사용자 작업이 Looker Action Hub 네트워크에 요청됨

Looker 사용자의 브라우저에서 다음 Looker Action Hub 엔드포인트 (OAuth용)에 요청할 수 있어야 합니다.

actions.looker.com/actions/<name>/oauth

여기서 name은 작업의 프로그래매틱 이름입니다.

Looker 작업 허브 네트워크에서 Looker 인스턴스로 보내는 요청

Looker 작업 허브는 스트리밍 결과를 지원하거나 OAuth를 사용하는 작업을 Looker 인스턴스에 요청해야 합니다.

스트리밍 작업을 사용하면 모든 결과를 제공하는 쿼리를 사용할 수 있습니다. OAuth가 사용 설정된 작업은 OAuth 2.0 흐름을 통해 사용자별 인증을 사용합니다. OAuth 작업은 Looker Action Hub가 스테이트리스(Stateless) 및 멀티 테넌트이므로 소스 사용자 Looker 인스턴스에 사용자 인증 정보를 저장해야 하며, 사용자별 사용자 인증 정보를 저장하지 않습니다.

Looker 작업 허브에서 Looker 인스턴스로 보내는 요청의 형식은 다음과 같습니다.

GET <host_looker_url>/downloads/<random_40_char_token>
POST <host_looker_url>/action_hub_state/<random_40_char_token>

이러한 URL은 Looker 작업 허브로 전송되기 전에 Looker 인스턴스의 스팟에서 생성됩니다. 따라서 Looker 작업 허브는 <host_looker_url>를 IP 주소로 확인하고 Looker 인스턴스가 있는 네트워크에 요청할 수 있어야 합니다.

Looker Action Hub에는 요청이 항상 발생하는 고정 이그레스 IP 주소(35.153.89.114, 104.196.138.163, 35.169.42.87)가 있습니다. IP 허용 목록을 사용 설정한 Looker 호스팅 인스턴스의 관리자는 이러한 IP 주소를 추가하여 스트리밍 결과를 지원하거나 OAuth를 사용하는 모든 작업을 사용해야 합니다.

고객 호스팅 인스턴스 고려사항

Looker 통합을 사용하려면 Looker 작업 허브가 Looker 인스턴스와 통신하고 이 요구사항을 충족할 수 있어야 합니다. 여러 가지 이유로 고객이 호스팅하는 Looker 인스턴스에서는 이 작업을 항상 실행할 수 있는 것은 아닙니다. Looker Action Hub와 Looker 인스턴스 간의 양방향 커뮤니케이션이 불가능한 경우 Looker Action Hub가 대기 중인 쿼리나 사용할 수 없는 작업과 같이 예상치 못한 동작이나 바람직하지 않은 동작을 보일 수 있습니다.

Looker 관리자는 아래 제시된 해결 방법 중 하나를 사용하여 Looker 작업 허브가 Looker 인스턴스와 통신할 수 없는 잠재적 문제를 해결합니다. 적합한 솔루션 또는 솔루션의 조합은 Looker 인스턴스의 아키텍처에 따라 다릅니다.

  • 고객 호스팅 인스턴스를 Looker Action Hub가 변환할 수 없습니다. 즉, Looker 작업 허브가 Looker 인스턴스에서 요청을 수신할 수 없는 경우 Looker 관리자는 Looker 계정 관리자에게 public_host_url 라이선스 기능을 사용 설정하도록 요청할 수 있습니다. 해당 라이선스 기능에는 관리자가 <host_looker_url> 인스턴스와 다른 결정 가능한 <public_host_url> 호스트 이름을 지정할 수 있는 --public-host-url 시작 옵션이 표시됩니다. public_host_url는 일부 특정 Looker Action Hub 콜백 URL의 호스트 이름을 재정의하고 public_host_url를 공개적으로 인식 가능한 이름으로 사용하는 역방향 프록시를 통해 이러한 콜백 URL을 라우팅합니다. 이 역방향 프록시는 Looker Action Hub의 고정 이그레스 IP 주소의 요청만 수락합니다. 이 방법을 사용하는 Looker 관리자는 Looker Action Hub가 Looker 인스턴스에 요청하는 이그레스 IP 주소(35.153.89.114, 104.196.138.163, 35.169.42.87)를 허용 목록에 추가해야 합니다.

  • 고객 호스팅 인스턴스 URL이 Looker 인스턴스에서 확인 가능하지만 Looker 작업 허브에서 Looker 인스턴스로 요청을 전송할 수 없는 경우 사용자는 스트리밍 결과를 지원하거나 OAuth를 사용하는 작업을 구성하거나 사용하지 못할 수 있습니다. 이 문제를 해결하려면 Looker 관리자가 Looker Action Hub가 Looker 인스턴스에 요청하는 이그레스 IP 주소(35.153.89.114, 104.196.138.163, 35.169.42.87)를 허용 목록에 추가해야 합니다.

  • 위에 언급된 솔루션 중 어느 것도 Looker 인스턴스 아키텍처에 적합하지 않은 경우 Looker 관리자는 모든 작업 또는 스트리밍 결과를 지원하거나 OAuth를 사용하는 작업에만 고객 호스팅 작업 허브를 배포할 수 있습니다.

  • 고객 호스팅 작업 허브를 배포하려면 Looker 작업 허브와 통신할 수 있도록 JAR 파일을 공개 서버에서 호스팅해야 합니다. 그러나 Looker에서는 이 솔루션을 추천하지 않습니다.

고객이 호스팅하는 Looker 인스턴스에서 OAuth 및 스트리밍 작업을 사용할 수 없는 또 다른 이유는 인스턴스가 이 목록에 없는 인증 기관 (CA)에서 발급한 SSL 인증서를 사용하는 경우입니다.

맞춤 액션 만들기

이 섹션에서는 Looker Action Hub 소스 코드를 사용하여 커스텀 작업을 작성하고 테스트하는 단계를 설명합니다. 작동하는 코드 예를 확인하려면 GitHub의 looker-open-source/actions 저장소에서 기존 작업을 확인하세요.

다음과 같은 방법으로 맞춤 작업을 만들 수 있습니다.

  1. 개발 저장소 설정
  2. 작업 쓰기
  3. 작업 테스트
  4. Looker 작업 허브 또는 자체 비공개 작업 허브 서버에서 작업 게시 및 사용 설정

다른 작업과 마찬가지로 작업을 사용하여 데이터를 전송하려면 먼저 특정 매개변수로 LookML 모델을 구성해야 할 수 있습니다.

개발 저장소 설정

Looker Action Hub는 프로그래밍 오류를 포착하는 데 도움이 되는 유형 정보를 추가하는 최신 자바스크립트 위에 있는 작은 레이어인 TypeScript로 작성된 Node.js 서버입니다. 자바스크립트에 익숙하다면 TypeScript 언어도 대부분 익숙할 것입니다.

Looker Action Hub를 실행하려면 다음 소프트웨어가 필요합니다.

  • Node.js
  • 노드 버전 관리자(NVM — 적절한 Node.js 버전 선택)
  • Yarn (종속 항목 관리)

필수 소프트웨어를 설치했으면 개발 환경을 설정할 수 있습니다. 아래 예시에서는 Git을 사용합니다.

  1. 로컬에서 looker-open-source/actions 저장소를 클론합니다.

    git clone git@github.com:looker-open-source/actions.git
    
  2. actions/src/actions 디렉터리에 작업 이름이 포함된 디렉터리를 만듭니다. 예를 들면 다음과 같습니다.

    mkdir actions/src/actions/my_action
    
  3. 작업을 실행하는 데 필요한 파일을 디렉터리에 입력하기 시작합니다. 예시 파일 구조는 작업 GitHub 저장소를 참고하세요.

Looker에서 다음 항목도 추가할 것을 권장합니다.

  • 작업 인증의 목적과 수단을 설명하는 README
  • PNG 아이콘을 사용하여 Looker 작업 허브 (또는 Looker 인스턴스의 비공개 작업 허브)와 Looker 데이터 전송 창에 표시
  • 작업 코드에서 실행하려는 테스트용 파일(작업 테스트와 다름)

작업 작성

Looker Action Hub 서버의 디자인 요구사항은 완전히 스테이트리스(Stateless)로 유지되므로 작업 애플리케이션이나 서비스에 정보를 저장하는 것이 허용되지 않습니다. 작업 처리에 필요한 모든 정보는 작업 파일의 요청 호출 내에 제공되어야 합니다.

작업 파일의 정확한 콘텐츠는 서비스, 작업이 작동하는 유형 또는 수준, 지정해야 하는 데이터 또는 시각화 형식에 따라 다릅니다. OAuth 2.0 승인 흐름을 위해 구성할 수도 있습니다.

작업 파일은 /execute API 메서드를 기반으로 합니다. 사용자가 Looker 내에서 작업을 실행할 때마다 Looker API 요청에 DataActionRequest가 전달됩니다. DataActionRequest에는 작업을 실행하는 데 필요한 모든 데이터와 메타데이터가 포함됩니다. 작업을 실행하기 전에 사용자로부터 추가 정보를 수집하는 데 사용할 수 있는 /form 메서드도 있습니다. /form에 지정한 필드는 사용자가 작업을 데이터 전송 대상으로 선택할 때 보내기 또는 일정 팝업에 표시됩니다.

Looker Action API를 사용하는 경우 이러한 매개변수의 형식은 다르게 표시될 수 있습니다.

액션 파일을 작성할 때 액션 정의에 최소한 필수로 표시된 다음 매개변수를 포함하세요.

매개변수 필수 설명 데이터 유형
name 작업의 고유한 이름입니다. Looker Action Hub의 모든 작업에서 고유해야 합니다. 문자열
url 이 작업에 대한 /execute 엔드포인트의 절대 URL입니다. 문자열
label 사람이 읽을 수 있는 작업 라벨입니다. 문자열
supportedActionTypes 작업이 지원하는 작업 유형의 목록입니다. 유효한 값은 "cell", "query", "dashboard"입니다. 문자열
formURL 아니요 이 작업에 대한 /form 엔드포인트의 절대 URL입니다. 문자열
description 아니요 작업에 대한 설명입니다. 문자열
params 아니요 작업에 사용할 parameters 배열입니다. 각 매개변수의 이름, 라벨, 설명을 문자열 형식으로 포함합니다. 관리 패널의 작업 사용 설정 페이지에 표시되는 필드입니다. 사용자가 작업 대상에 데이터를 전달하는 방법을 관리하려면 사용자에게 정의된 값이 있어야 하는 사용자 속성지정할 수 있습니다. parameters
supportedFormats 아니요 작업이 지원하는 데이터 형식의 목록입니다. 유효한 값은 "txt", "csv", "inline_json", "json", "json_detail", "json_detail_lite_stream", "xlsx", "html", "wysiwyg_pdf", "assembled_pdf", and "wysiwyg_png".입니다. 문자열
supportedFormattings 아니요 작업이 지원하는 형식 지정 옵션의 목록입니다. 유효한 값은 "formatted", "unformatted"입니다. 문자열
supportedVisualizationFormattings 아니요 작업에서 지원하는 시각화 형식 지정 옵션의 목록입니다. 유효한 값은 "apply", "noapply"입니다. 문자열
iconName 아니요 작업의 아이콘 이미지를 나타내는 데이터 URI입니다. 문자열
requiredFields 아니요 이 작업과 호환되는 필수 필드의 설명 목록입니다. 이 목록에 항목이 여러 개 있는 경우 작업에는 두 개 이상의 필드가 필요합니다. RequiredField
supportedDownloadSettings 아니요 작업의 일회용 다운로드 URL 전송 여부를 결정하는 부울로, 데이터 무제한 스트리밍을 용이하게 합니다. 매개변수는 true/false 부울인 usesStreaming 매개변수에 의해 설정됩니다. usesStreaming = true이면 supportedDownloadSettings = url입니다. usesStreaming = false이면 supportedDownloadSettings = push입니다. 불리언
usesOAuth 아니요 작업이 OAuth 작업인지 여부를 결정하는 부울입니다. 이렇게 하면 이 작업의 특정 사용자에게 state를 설정하기 위해 일회용 링크가 전송될지 여부가 결정됩니다. 불리언
usesStreaming 아니요 작업이 스트리밍 쿼리 결과를 지원하는지 여부를 결정하는 부울입니다. 통합 서비스 목록에서 결과 스트리밍 가능/아니요 열을 선택합니다. 결과를 스트리밍하는 작업에는 로컬 작업 허브 서버를 구성해야 할 수 있습니다. 자세한 내용은 Looker 고객센터의 OAuth 또는 스트리밍을 사용하는 작업에 로컬 작업 허브 설정 도움말을 참고하세요. 불리언
minimumSupportedVersion 아니요 관리자 패널 작업 허브 목록에 작업이 표시되는 최소 Looker 버전입니다. 문자열

Looker Action Hub 작업의 예시는 GitHub에 나와 있습니다.

지원되는 작업 유형

Looker는 작업의 supportedActionTypes 매개변수에 지정된 세 가지 작업 유형(쿼리, 셀, 대시보드)을 지원합니다.

  • 쿼리 수준 작업: 전체 쿼리를 전송하는 작업입니다. 예를 들어 세그먼트 작업은 쿼리 수준의 작업입니다.
  • 셀 수준 작업: 셀 수준 작업은 데이터 테이블에서 특정 단일 셀의 값을 전송합니다. 이 작업 유형은 action 매개변수를 사용하여 측정기준 또는 측정에 대해 정의할 수 있는 데이터 작업과 다릅니다. 테이블 내의 특정 셀에서 정보를 전송하기 위해 Looker는 태그를 사용하여 작업을 해당 셀에 매핑합니다. 작업은 requiredFields에서 지원하는 태그를 지정해야 합니다. 작업 및 필드를 매핑하려면 LookML의 필드가 LookML tags 매개변수로 매핑되는 태그를 지정해야 합니다. 예를 들어 Twilio Message 작업phone 태그를 사용하므로 LookML 개발자가 Twilio 작업이 표시할 전화번호 필드를 제어할 수 있습니다.
  • 대시보드 수준 작업: 대시보드 수준 작업은 대시보드의 이미지 전송을 지원합니다. 예를 들어 SendGrid 작업은 이메일을 통해 대시보드 이미지를 전송합니다.

맞춤 작업에 사용자 속성 추가

맞춤 작업의 경우 작업 파일의 params 매개변수에 사용자 속성을 추가할 수 있습니다. 매개변수가 필요한 경우 콘텐츠를 보내거나 예약할 때 작업을 대상 옵션으로 보려면 각 사용자에게 send_to_integration 권한 외에도 사용자 계정 또는 사용자가 속한 사용자 그룹에 정의된 속성 값이 있어야 합니다.

작업에 사용자 속성을 추가하려면 다음 단계를 따르세요.

  1. user_attribute_param에 아직 없는 경우 Looker 관리자가 user_attribute_param에 해당하는 사용자 속성을 만들어야 합니다.
  2. 액션 대상에 콘텐츠를 전달해야 하는 사용자 또는 사용자 그룹의 사용자 속성에 유효한 값을 정의합니다. (이 사용자에게도 send_to_integration 권한이 있어야 합니다.)
  3. params 매개변수는 Looker 관리자가 관리자 패널의 작업 목록에서 작업 사용 설정 페이지에 구성해야 하는 양식 필드를 나타냅니다. 작업 파일의 params 매개변수에 다음을 포함합니다.
  params = [{
    description: "A description of the param.",
    label: "A label for the param.",
    name: "action_param_name",
    user_attribute_name: "user_attribute_name",
    required: true,
    sensitive: true,
  }]

여기서 user_attribute_name관리 패널의 사용자 섹션에 있는 사용자 속성 페이지의 이름 입력란에 정의된 사용자 속성입니다. required: true는 사용자가 해당 사용자 속성에 null이 아닌 유효한 값을 정의해야 데이터를 전송할 때 작업을 볼 수 있으며 sensitive: true은 사용자 속성이 암호화되어 입력되면 Looker UI에 표시되지 않음을 의미합니다. 여러 개의 사용자 속성 하위 매개변수를 지정할 수 있습니다.

  1. 업데이트를 작업 허브 서버에 배포합니다.
    • 새 작업을 추가하는 경우 Looker 관리자는 관리자 패널의 작업 페이지에서 작업 옆에 있는 사용 설정 버튼을 클릭하여 작업을 사용 설정해야 합니다.
    • 기존 작업을 업데이트하는 경우 새로고침 버튼을 클릭하여 작업 목록을 새로 고칩니다. 그런 다음 설정 버튼을 클릭합니다.
  2. 작업 설정/사용 설정 페이지에서 Looker 관리자는 적절한 필드 오른쪽에 있는 사용자 속성 아이콘 을 클릭하고 원하는 사용자 속성을 선택하여 사용자 속성에서 정보를 가져오도록 작업의 양식 필드를 구성해야 합니다.

셀 수준 작업의 매개변수 requiredField

셀 수준 작업의 경우 모델의 LookML 필드를 구성하여 작업 파일의 requiredFields 매개변수에 작업이 지원하는 태그를 지정하여 해당 작업 대상에 데이터를 전송할 수 있습니다.

매개변수 필수 설명 데이터 유형
tag 아니요 태그가 있으면 이 태그가 있는 필드와 일치합니다. 문자열
any_tag 아니요 필드가 있으면 tag를 대체하고 제공된 태그가 있는 필드와 일치합니다. 문자열
all_tags 아니요 필드가 있으면 tag를 대체하고 제공된 모든 태그가 있는 필드와 일치합니다. 문자열

지원되는 데이터 형식

DataActionRequest 클래스는 작업에 사용할 수 있는 데이터 전송 형식을 정의합니다. 쿼리 수준 작업의 경우 요청에 여러 형식의 첨부파일도 포함됩니다. 이 작업은 supportedFormats를 하나 이상 지정하거나 사용자가 가능한 모든 형식을 지정하여 형식을 선택하도록 할 수 있습니다. 셀 수준 작업의 경우 셀 값이 DataActionRequest에 표시됩니다.

OAuth 작업 구성

OAuth 사용 작업은 IP 허용 목록 기능이 사용 설정되어 있거나 Looker Action Hub 요구사항을 수용할 수 없는 Looker 인스턴스용 Looker 작업 허브에서 구성할 수 없습니다. OAuth 작업을 구성하는 방법에 대한 자세한 내용은 Looker 고객센터에서 OAuth 또는 스트리밍을 사용하는 작업에 로컬 작업 허브 설정 도움말을 참조하세요.

사용자가 OAuth를 사용하여 작업에 인증할 수 있도록 작업을 구성할 수 있습니다. Looker Action Hub는 스테이트리스(Stateless)로 유지되어야 하지만 Looker Action API의 양식 요청을 통해 상태를 시행할 수 있습니다.

Looker 작업 OAuth 흐름

Looker Action Hub의 경우 Hub.Action 대신 OAuthAction을 확장하여 작업에 사용자를 인증하는 데 필요한 OAuth 메서드를 나타내는 부울을 설정할 수 있습니다. OAuth 사용 또는 상태 사용 설정 작업의 경우 Looker에서 사용자별 작업 상태를 저장하므로 각 작업과 사용자 조합에 독립적인 OAuth 이벤트가 포함됩니다.

작업을 만드는 흐름에는 일반적으로 /form 요청과 /execute 요청이 차례로 포함됩니다. OAuth의 경우 /form 요청에 사용자가 대상 서비스 내에서 인증되었는지 확인하는 메서드가 있어야 합니다. 사용자가 이미 인증된 경우 이 작업은 /execute 요청에 필요한 내용에 따라 일반 /form를 반환해야 합니다. 사용자가 인증되지 않은 경우 작업은 OAuth 흐름을 초기화하는 링크를 반환합니다.

OAuth URL로 상태 저장

Looker는 본문이 비어 있는 HTTP POST 요청을 ActionList 엔드포인트로 전송합니다. 작업이 정의에서 uses_oauth: true를 반환하면 작업이 Looker의 모든 /form 요청에서 일회용 state_url로 전송됩니다. state_url는 특정 작업의 사용자 상태를 설정하는 특수한 일회용 URL입니다.

사용자가 엔드포인트로 인증되지 않으면 반환된 /form에 작업의 /oauth 엔드포인트로 이동하는 oauth_link 유형의 form_field가 포함되어야 합니다. state_url는 암호화되어 반환된 oauth_urlstate 매개변수로 저장되어야 합니다. 예를 들면 다음과 같습니다.

{
        "name": "login",
        "type": "oauth_link",
        "label": "Log in",
        "description": "OAuth Link",
        "oauth_url": "ACTIONHUB_URL/actions/my_action/oauth?state=encrypted_state_url"
}

이 예에서 /oauth 엔드포인트는 사용자를 인증 서버로 리디렉션합니다. /oauth 엔드포인트는 Dropbox OauthUrl에 표시된 대로 OAuth 작업의 oauthUrl(...) 메서드에서 리디렉션을 구성합니다.

암호화된 state_url가 포함된 state 매개변수를 Looker 작업 허브에 전달해야 합니다.

작업 허브 리디렉션 URI로 상태 저장

/oauth 엔드포인트에서 작업 허브의 redirect_uri도 생성되어 작업의 oauthUrl(...) 메서드에 전달됩니다. 이 redirect_uri의 형식은 /actions/src/actions/my_maction/oauth_redirect이며 인증에서 결과를 반환할 때 사용되는 엔드포인트입니다.

이 엔드포인트는 OauthAction 메서드를 통해 필요한 oauthFetchInfo(...) 메서드를 호출하여 필요한 정보를 추출하고 인증 서버에서 수신된 상태 또는 auth를 받거나 저장하려고 시도합니다.

state는 암호화된 state_url를 복호화하여 이를 사용하여 Looker에 다시 state을 POST합니다. 다음에 사용자가 해당 작업을 요청할 때 새로 저장된 상태가 Looker Action Hub로 전송됩니다.

Looker Action Hub 저장소에 작업 파일 추가

작업 파일이 작성되면 Looker Action Hub 저장소에서 다음을 수행합니다.

  1. 작업 파일 (예: my_action.ts)을 actions/src/actions/index.ts에 추가합니다.

    import "./my_action/my_action.ts"
    
  2. 작업 작성에 사용한 모든 Node.js 패키지 요구사항을 추가합니다. 예를 들면 다음과 같습니다.

    yarn add aws-sdk
    yarn add express
    
  3. Looker Action Hub 서버의 Node.js 종속 항목을 설치합니다.

    yarn install
    
  4. 작성한 테스트를 모두 실행합니다.

yarn test

작업 테스트

완벽한 테스트를 위해 비공개 작업 허브 서버를 호스팅하여 Looker 인스턴스에 작업을 시험해 볼 수 있습니다. 이 서버는 유효한 SSL 인증서로 공개 인터넷에 있어야 하며 Looker와 연결 또는 HTTPS 요청을 주고받을 수 있어야 합니다. 이를 위해 다음 예와 같이 Heroku와 같은 클라우드 기반 플랫폼을 사용하거나 앞서 언급한 요구사항을 충족하는 모든 플랫폼을 사용할 수 있습니다.

로컬 작업 허브 서버 설정

이 예시에서는 looker-open-source/actions/src/actions GitHub 저장소에서 개발한 작업을 수행하고 코드를 새 Git 분기에 커밋합니다. 코드를 쉽게 추적하고 원하는 경우 Looker로 손쉽게 PR을 만들 수 있도록 분기를 사용하여 기능을 작업하는 것이 좋습니다.

  1. 시작하려면 브랜치를 만든 다음 작업을 스테이징하고 커밋합니다. 예를 들면 다음과 같습니다.

    git checkout -b my-branch-name
    git add file-names
    git commit -m commit-message
    
  2. 이 예에서는 분기를 Heroku에 푸시하려면 명령줄에서 Heroku를 사용하여 원격 저장소를 Heroku로 구성합니다.

    heroku login
    heroku create
    git push heroku
    
  3. Heroku에서 이제 사용할 작업 허브를 호스팅하는 공개 URL을 반환합니다. URL을 방문하거나 heroku logs를 실행하여 작업 허브가 실행 중인지 확인합니다. 공개 URL을 잊어버린 경우 명령줄에서 다음을 실행하면 됩니다.

    heroku info -s | grep web_url
    

    Heroku에서 공개 URL을 반환합니다. 예: https://my-heroku-action-server-1234.herokuapp.com

  4. 명령줄에서 작업 허브 기본 URL을 설정합니다.

    heroku config:set ACTION_HUB_BASE_URL="https://my-heroku-action-server-1234.herokuapp.com"
    
  5. 작업 허브 라벨을 설정합니다.

    heroku config:set ACTION_HUB_LABEL="Your Action Hub"
    
  6. Looker에서 승인 토큰을 사용하여 작업 허브에 연결합니다. 다음과 같이 명령줄에서 토큰을 생성합니다.

    heroku run yarn generate-api-key
    

    이 예에서는 Heroku를 사용하지 않는 경우 다음을 사용합니다.

    yarn generate-api-key
    

    Heroku에서 인증 토큰을 반환합니다. 예: Authorization: Token token="abcdefg123456789"

  7. 보안 비밀 키를 사용하여 작업 허브 보안 비밀을 설정합니다.

    heroku config:set ACTION_HUB_SECRET="abcdefg123456789"
    

    고객이 호스팅하는 배포에는 여기에 나와 있지 않은 추가 환경 변수의 구성이 필요할 수 있습니다.

  8. 관리 > 작업으로 이동하여 로컬 Looker 인스턴스에 작업을 추가합니다.

    • 작업 목록 하단에서 작업 허브 추가를 클릭합니다.
    • 작업 허브 URL을 입력하고 필요한 경우 보안 비밀 키를 입력합니다.
    • Looker의 관리 메뉴의 작업 목록에서 작업을 찾습니다.
    • 사용 설정을 클릭합니다.

특정 종류의 데이터를 Looker에서 전달해야 하는 작업의 경우 모든 모델을 구성하여 적절한 tags 매개변수를 포함해야 합니다.

이제 작업을 테스트할 준비가 되었습니다

대시보드 수준 및 쿼리 수준 작업 테스트

필요한 경우 Looker 인스턴스에서 태그로 LookML 모델을 구성합니다. Look을 만들고 저장합니다. 저장된 Look에서 오른쪽 상단 메뉴를 클릭하고 내 작업을 대상으로 전송을 선택합니다. 전송할 양식이 있으면 Looker에서 보낸편지함 창에 양식을 렌더링합니다.

테스트 전송을 클릭하여 데이터를 전송합니다. 작업 상태는 관리자 패널의 스케줄러 기록에 표시됩니다. 작업에 오류가 발생하면 관리자 패널에 작업이 표시되고 Looker에서 작업을 보낸 사용자에게 오류 메시지가 포함된 이메일을 보냅니다.

셀 수준 작업 테스트

작업에 적절한 태그를 사용하여 LookML 필드를 설정합니다. Looker 인스턴스에서 이 필드가 포함된 쿼리를 실행합니다. 데이터 표에서 필드를 찾습니다. 셀에서 ...을 클릭하고 드롭다운 메뉴에서 보내기를 선택합니다. 오류가 발생할 경우 오류를 해결한 후 데이터 테이블을 완전히 새로고침해야 합니다.

맞춤 작업 게시 및 사용 설정하기

맞춤 작업에는 두 가지 게시 옵션이 있습니다.

작업이 게시되면 관리 패널의 작업 페이지에서 사용 설정할 수 있습니다.

Looker Action Hub에 게시하기

이 접근 방식은 Looker를 사용하는 모든 사용자에게 제공하려는 모든 작업에 가장 쉬운 방법입니다.

작업을 테스트한 후 GitHub의 looker-open-source/actions 저장소에 PR을 제출할 수 있습니다.

  1. 다음 명령어를 입력합니다.

    git push <your fork> <your development branch>
    
  2. looker-open-source/actions 저장소를 대상으로 pull 요청을 만듭니다.

  3. Looker Marketplace 및 Action Hub 제출 양식을 작성합니다. 양식 요구사항에 관한 자세한 내용은 Looker Marketplace에 콘텐츠 제출을 참고하세요.

    Looker에서 작업 코드를 검토합니다. Google은 PR을 거부할 권리를 보유하지만 발생한 문제를 해결하고 개선을 위한 제안사항을 제공할 수 있습니다. 그런 다음 코드를 looker-open-source/actions 저장소에 병합하여 actions.looker.com에 배포합니다. 배포된 코드는 모든 Looker 고객에게 제공됩니다.

  4. Looker 인스턴스에서 작업을 사용 설정하여 데이터 전송 옵션으로 표시되도록 합니다.

비공개 작업 허브 서버에 게시하기

회사 전용이나 사용 사례별 맞춤 작업이 있는 경우 looker-open-source/actions 저장소에 작업을 추가해서는 안 됩니다. 대신 작업을 테스트하는 데 사용한 것과 동일한 Node.js 프레임워크를 사용하여 비공개 작업 허브를 만듭니다.

자체 인프라에서 또는 클라우드 기반 애플리케이션 플랫폼 (예시에서는 Heroku 사용)을 사용하여 내부 작업 허브 서버를 설정할 수 있습니다. 배포 전에 Looker Action Hub를 비공개 작업 허브 서버에 포크하는 것을 잊지 마세요.

작업에 사용할 LookML 모델 구성

커스텀 작업 및 Looker 작업 허브에서 사용할 수 있는 작업의 경우 LookML 모델에서 tags 매개변수를 사용하여 관련 데이터 필드를 식별해야 합니다.

서비스에 필요한 태그에 대한 정보를 관리자 패널의 작업 페이지에서 제공합니다. 예를 들면 다음과 같습니다.

Zapier 통합은 모든 쿼리와 호환된다고 명시합니다. LookML 모델의 필드에 tags 매개변수를 추가할 필요는 없습니다.

하지만 Twilio Send Message 서비스는 전화번호 목록으로 메시지를 보냅니다. 전화번호 필드가 포함된 쿼리가 필요하며 tags 매개변수를 사용하여 쿼리의 어떤 필드가 전화번호가 포함되어 있는지 식별합니다. LookML에서 전화번호 필드를 지정하려면 해당 필드에 tags: ["phone"]를 지정합니다. 전화번호 필드의 LookML은 다음과 같습니다.

dimension: phone {
  tags: ["phone"]
  type: string
  sql: ${TABLE}.phone ;;
}

사용자가 서비스를 사용하여 데이터를 전송할 수 있도록 LookML 모델에서 tags 매개변수로 필수 필드를 식별해야 합니다.

작업으로 데이터 전송

데이터는 작업이 작동하는 수준에 따라 여러 가지 방법으로 전달될 수 있습니다. 작업은 필드, 쿼리 또는 대시보드 수준에서 작동하며 하나 이상의 수준에서 작동할 수 있습니다. 관리자 패널의 작업 페이지에 나열된 각 작업에는 사용 방식에 대한 설명이 있습니다. 다음과 같은 작업을 할 수 있습니다.

셀 데이터 전송 중

필드 수준 작업은 관리 패널의 작업 페이지에 '필드에 사용할 수 있는 작업'을 포함하거나 통합 서비스 목록'필드에서 사용 가능' 열에서 로 표시됩니다.

필드 수준 작업은 지정된 서비스로 데이터 셀을 전달하도록 설계되었습니다. Looker Action API를 통해 제공된다는 점을 제외하면 데이터 작업과 유사하게 작동합니다. 측정기준 또는 측정값에 action LookML 매개변수를 정의하는 대신 통합 서비스 목록이 작업에 대한 태그 열에서 관련 정보를 태그 지정하여 LookML 모델을 구성해야 합니다.

LookML 모델에서 서비스 및 태그 지정 필드를 사용 설정한 후 다음 작업을 수행할 수 있습니다.

  1. Look, 대시보드 또는 Explore에서 제공하려는 데이터를 확인합니다. 서비스가 태그가 지정된 필드가 있는 쿼리에 사용될 수 있는 경우 쿼리 또는 대시보드 타일 중 하나에 필수 태그가 있는 필드가 하나 이상 포함되어야 합니다.

  2. 보기, 대시보드 타일 또는 탐색의 각 셀에 있는 태그 지정 필드에는 줄임표 (...)로 표시되는 드롭다운 목록이 포함됩니다. 생략 부호를 클릭하면 해당 링크에 사용 가능한 작업이 표시됩니다.

  3. 작업 섹션에서 행 데이터를 수신할 서비스를 클릭합니다.

대시보드 또는 쿼리 데이터 제공

쿼리 수준 작업은 관리 패널의 작업 페이지에서 '...' 태그가 지정된 쿼리에 사용할 수 있으며 '...' 작업은 모든 쿼리에 사용할 수 있습니다. 통합 서비스 목록보내기 또는 예약 가능 열에 따라 모든 행 (보기 또는 탐색 분석)을 게재할 수 있습니다. 쿼리 수준 작업은 탐색 또는 보기의 전체 쿼리 결과를 지정된 서비스로 제공하도록 설계되었습니다.

대시보드 수준 작업은 관리 패널의 작업 페이지에 '모든 대시보드에서 사용할 수 있는 작업'이 포함된 설명에 표시됩니다. 통합 서비스 목록전송 또는 예약 가능 열에 따라 대시보드를 전송할 수 있습니다. 대시보드 수준 작업은 지정된 서비스에 대시보드를 제공하도록 설계되었습니다.

서비스를 사용 설정하고 필요한 경우 LookML 모델에서 필드를 태그합니다.

Look 또는 Explore를 전달하려면 Looks and Explores 문서 페이지를 참고하세요.

대시보드를 전송하려면 기존 대시보드 제공대시보드 예약 및 전송 문서 페이지를 참고하세요.