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

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

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

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

작업을 시작하려면 다음 중 하나를 수행합니다.

• Looker 작업 허브에서 사용할 수 있는 Looker의 기존 작업을 사용합니다.
• 맞춤 작업을 빌드하고 Looker 작업 허브에 게시하여 공개합니다.
• 커스텀 작업을 빌드하여 비공개 용도로 비공개 작업 허브 서버에 게시합니다.

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

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

Looker 작업 허브

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

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

Looker 작업 허브 요구사항

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

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

• Looker 인스턴스에서 Looker 작업 허브 네트워크로
• Looker 사용자 브라우저에서 Looker Action Hub 네트워크로
• Looker 작업 허브 네트워크에서 Looker 인스턴스로

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

Looker 인스턴스에서 Looker Action Hub 네트워크로의 요청

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 작업 허브 엔드포인트에 요청할 수 있어야 합니다 (OAuth의 경우).

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

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

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

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

스트리밍 작업을 사용하면 모든 결과를 제공하는 쿼리를 사용할 수 있습니다. OAuth가 사용 설정된 작업은 OAuth 2.0 흐름을 통해 사용자별 인증을 사용합니다. OAuth 작업은 스테이트리스(Stateless)이고 멀티테넌시이며 Looker 작업 허브는 어떠한 종류의 사용자별 사용자 인증 정보도 저장하지 않으므로 소스 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 작업 허브에는 요청이 항상 전송되는 고정 이그레스 IP 주소(35.153.89.114, 104.196.138.163, 35.169.42.87)가 있습니다. IP 허용 목록을 사용 설정한 Looker 호스팅 인스턴스의 관리자는 스트리밍 결과를 지원하거나 OAuth를 사용하는 작업을 사용하려면 이러한 IP 주소를 추가해야 합니다.

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

Looker 통합을 사용하려면 Looker 작업 허브가 Looker 인스턴스와 통신하고 이 요구사항을 충족할 수 있어야 합니다. 여러 이유로 고객 호스팅 Looker 인스턴스에는 이것이 항상 가능한 것은 아닙니다. Looker 작업 허브와 Looker 인스턴스 간의 양방향 통신이 불가능한 경우 Looker 작업 허브에서 지연 쿼리나 사용할 수 없는 작업과 같이 예상치 못한 동작이나 원치 않는 동작이 나타날 수 있습니다.

Looker 관리자가 Looker 인스턴스와 통신할 수 없는 잠재적인 문제를 해결하기 위해 Looker 관리자는 아래 제시된 해결책 중 하나를 구현할 수 있습니다. Looker 인스턴스의 아키텍처에 따라 적절한 솔루션 또는 솔루션의 조합이 결정됩니다.

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

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

• 앞서 언급한 해결 방법이 모두 Looker 인스턴스 아키텍처에 적합하지 않으면 Looker 관리자는 모든 작업 또는 스트리밍 결과를 지원하거나 OAuth를 사용하는 작업에만 고객 호스팅 작업 허브를 배포할 수 있습니다.

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

고객이 호스팅하는 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 [e-mail]:looker-open-source/actions.git
   

2. actions/src/actions 디렉터리에 작업 이름이 있는 디렉터리를 만듭니다. 예를 들면 다음과 같습니다.

   mkdir actions/src/actions/my_action
   

3. 작업을 실행하는 데 필요한 파일로 디렉터리를 채웁니다. 예시 파일 구조는 작업 GitHub 저장소를 참고하세요.

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

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

작업 작성

Looker 작업 허브 서버의 설계 요구사항은 스테이트리스(Stateless)로 유지되므로 작업 애플리케이션이나 서비스에 정보를 저장하는 것이 허용되지 않습니다. 작업을 실행하는 데 필요한 모든 정보는 작업 파일의 요청 호출 내에서 제공해야 합니다.

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

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

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

작업 파일을 작성할 때 액션 정의에 필수로 표시된 다음 매개변수를 하나 이상 포함합니다.

매개변수	필수	설명	데이터 유형
name	예	작업의 고유한 이름입니다. Looker 작업 허브의 모든 작업에서 고유해야 합니다.	문자열
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	아니요	이 동작과 호환되는 필수 필드의 설명 목록입니다. 이 목록에 항목이 여러 개 있는 경우 2개 이상의 필드가 필요합니다.	RequiredField
supportedDownloadSettings	아니요	데이터 무제한 스트리밍을 용이하게 하기 위해 작업에 일회용 다운로드 URL을 전송할지 여부를 결정하는 부울입니다. 매개변수는 true/false 부울인 usesStreaming 매개변수에 의해 설정됩니다. usesStreaming = true이면 supportedDownloadSettings = url입니다. usesStreaming = false이면 supportedDownloadSettings = push입니다.	불리언
usesOAuth	아니요	작업이 OAuth 작업인지 결정하는 부울입니다. 이렇게 하면 이 작업의 특정 사용자에 대해 state를 설정할 수 있도록 일회용 링크가 전송되는지 여부가 결정됩니다.	불리언
usesStreaming	아니요	작업이 스트리밍 쿼리 결과를 지원하는지 여부를 결정하는 부울 값 통합 서비스 목록에서 결과 스트리밍 가능 여부 열을 선택합니다. 결과를 스트리밍하는 작업에는 로컬 작업 허브 서버를 구성해야 할 수 있습니다. 자세한 내용은 OAuth 또는 스트리밍을 사용하는 작업의 로컬 작업 허브 설정하기를 참고하세요.	불리언
minimumSupportedVersion	아니요	작업이 관리자 패널의 작업 허브 목록에 표시되는 최소 Looker 버전입니다.	문자열

Looker 작업 허브 작업의 예는 GitHub를 참고하세요.

지원되는 작업 유형

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

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

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

맞춤 작업의 경우 액션 파일의 params 매개변수에 사용자 속성을 추가할 수 있습니다. 매개변수가 필요한 경우 각 사용자는 send_to_integration사용자 권한과 함께 사용자 계정 또는 본인이 속한 사용자 그룹에 정의된 이 속성 값을 가지고 있어야 콘텐츠를 전송 또는 예약할 때 대상 유형으로 작업을 확인할 수 있습니다.

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

1. user_attribute_param에 해당하는 사용자 속성을 아직 만들지 않았다면 Looker 관리자가 해당 속성을 만들어야 할 수 있습니다.
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 매개변수

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

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

지원되는 데이터 형식

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

OAuth 작업 구성

OAuth 사용 작업은 IP 허용 목록 기능이 사용 설정되어 있거나 Looker 작업 허브 요구사항을 수용할 수 없는 Looker 인스턴스의 Looker 작업 허브에서 구성할 수 없습니다. OAuth 작업을 구성하는 방법에 대한 자세한 내용은 OAuth 또는 스트리밍을 사용하는 작업의 로컬 작업 허브 설정 권장사항 페이지를 참조하세요.

사용자가 OAuth를 사용하여 작업에 인증할 수 있도록 작업을 구성할 수 있습니다. Looker 작업 허브는 스테이트리스(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_url의 state 매개변수로 저장되어야 합니다. 예를 들면 다음과 같습니다.

{
        "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 형식이며 인증에서 결과를 반환하는 데 사용되는 엔드포인트입니다.

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

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

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의 Git 저장소를 구성합니다.

   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을 만들고 저장합니다. 저장된 디자인의 오른쪽 상단에서 메뉴를 클릭하고 작업을 대상으로 보내기를 선택합니다. 전송 양식이 있는 경우 Looker에서 전송됨 창에 양식을 렌더링합니다.

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

셀 수준 작업 테스트

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

• 작업이 오류 없이 전달되면 작업을 게시할 준비가 된 것입니다.
• 작업을 비공개로 계속 호스팅하려면 비공개 작업 허브에 게시하세요.
• 모든 Looker 고객이 사용할 수 있도록 작업을 게시하려면 Looker 작업 허브에 게시 섹션을 참고하세요.

맞춤 작업 게시 및 사용 설정

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

• Looker 작업 허브에 게시: 이렇게 하면 Looker를 사용하는 모든 사용자에게 내 작업이 제공됩니다.
• 비공개 작업 허브 서버에 게시: 이렇게 하면 Looker 인스턴스에서만 작업을 사용할 수 있습니다.

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

Looker 작업 허브에 게시

이 접근 방식은 가장 쉽고 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 작업 허브를 비공개 작업 허브 서버에 포크해야 합니다.

작업에 사용할 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 매개변수로 지정해야 합니다.

작업으로 데이터 전송

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

• 데이터 셀 제공
• Look 또는 Explore에서 전체 대시보드 또는 쿼리 실행하기

모바일 데이터 전송

필드 수준 작업은 관리자 패널의 작업 페이지에 '필드를 통해 사용할 수 있는 작업' 또는 통합 서비스 목록의 필드에서 사용 가능 열에 예가 포함된 설명으로 표시됩니다.

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

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

1. Look, 대시보드 또는 탐색에서 전달하려는 데이터를 확인합니다. 서비스에서 '필드에 태그가 지정된...

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

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

대시보드 또는 쿼리 데이터 전달

쿼리 수준 작업은 관리 패널의 작업 페이지에 '작업이 태그된 필드가 있는 쿼리에 사용할 수 있습니다' 또는 '모든 쿼리와 함께 사용할 수 있습니다'라는 설명이 표시됩니다. 통합 서비스 목록의 전송 또는 예약 가능 열에 따라 모든 행 (살펴보기 또는 탐색)을 게재할 수 있습니다. 쿼리 수준 작업은 탐색 또는 보기의 전체 쿼리 결과를 지정된 서비스로 전달하도록 설계되었습니다.

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

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

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

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