Looker 문서를 보고 있습니다. Looker Studio 문서는 https://support.google.com/looker-studio를 참조하세요.

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

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

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

작업을 사용하려면 다음 중 하나를 수행하세요.

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

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

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

Looker 작업 허브

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

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

Looker 작업 허브 요구사항

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

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

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 작업 허브 네트워크로의 요청

Looker 사용자의 브라우저는 다음 Looker 작업 허브 엔드포인트(OAuth의 경우)에 요청을 전송할 수 있어야 합니다.

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

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

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

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

스트리밍 작업을 통해 모든 결과를 제공하는 쿼리를 사용하는 작업을 사용 설정할 수 있습니다. OAuth가 사용 설정된 작업은 OAuth 2.0 흐름을 통해 사용자별 인증을 사용합니다. Looker 작업 허브는 스테이트리스(Stateless)이고 멀티 테넌트이며 어떠한 종류의 사용자별 사용자 인증 정보도 저장하지 않으므로 OAuth 작업은 해당 소스 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 관리자가 public_host_url 라이선스 기능을 사용 설정하기 위해 Google Cloud 영업팀에 문의할 수 있습니다. 이 라이선스 기능은 관리자가 인스턴스 <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 파일이 공개 서버에서 호스팅되어야 합니다. 하지만 이 솔루션은 권장되지 않습니다.

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

커스텀 작업 빌드

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

다음과 같은 방법으로 커스텀 작업을 만들 수 있습니다.

개발 저장소 설정
작업 작성
작업 테스트
Looker 작업 허브 또는 자체 비공개 작업 허브 서버에서 작업 게시 및 사용 설정

모든 작업과 마찬가지로 특정 매개변수로 LookML 모델을 구성해야 작업을 통해 데이터를 전송할 수 있습니다.

개발 저장소 설정

Looker 작업 허브는 TypeScript로 작성된 Node.js 서버입니다. 최신 JavaScript 기반의 작은 레이어로 프로그래밍 오류를 포착하는 데 도움이 되는 유형 정보를 추가합니다. JavaScript에 익숙하다면 대부분의 TypeScript 언어에 익숙할 것입니다.

Looker 작업 허브를 실행하려면 다음 소프트웨어가 필요합니다.

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

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

looker-open-source/actions 저장소를 로컬에서 클론합니다.
```
git clone git@github.com:looker-open-source/actions.git
```
actions/src/actions 디렉터리에 작업 이름이 있는 디렉터리를 만듭니다. 예를 들면 다음과 같습니다.
```
mkdir actions/src/actions/my_action
```
작업을 실행하는 데 필요한 파일로 디렉터리를 채웁니다. 파일 구조 예시는 작업 GitHub 저장소를 참조하세요.

Looker는 다음을 추가하는 것도 권장합니다.

작업의 인증 목적과 방법을 설명하는 리드미
Looker 작업 허브(또는 Looker 인스턴스의 비공개 작업 허브)와 Looker 데이터 전송 창에 표시할 PNG 아이콘
작업 코드에서 실행하려는 테스트에 대한 파일(작업 테스트와 다름)

작업 작성

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

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

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

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

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

Looker 작업 허브 작업의 예시는 GitHub에서 참조로 확인할 수 있습니다.

지원되는 작업 유형

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

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

커스텀 작업에 사용자 속성 추가

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

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

Looker 관리자가 user_attribute_param에 해당하는 사용자 속성을 생성해야 할 수 있습니다(아직 없는 경우).
작업 대상에 콘텐츠를 제공해야 하는 사용자 또는 사용자 그룹에 대해 사용자 속성에 유효한 값을 정의하세요. (이 사용자에게는 send_to_integration 권한도 있어야 합니다.)
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에 표시되지 않음을 의미합니다. 여러 사용자 속성 하위 매개변수를 지정할 수 있습니다.

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

셀 수준 작업의 `requiredField` 매개변수

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

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

지원되는 데이터 형식

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

OAuth 작업 구성

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

Looker 작업 OAuth 흐름

Looker 작업 허브의 작업은 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(...) 메서드를 호출하여 필요한 정보를 추출하고 인증 서버에서 수신한 상태 또는 auth을 수신하거나 저장하려고 시도하는 OauthAction 메서드에 의해 구현되어야 합니다.

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

Looker 작업 허브 저장소에 작업 파일 추가

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

작업 파일(예: my_action.ts)을 actions/src/actions/index.ts에 추가합니다.
```
import "./my_action/my_action.ts"
```
작업을 작성할 때 사용한 Node.js 패키지 요구사항을 추가합니다. 예를 들면 다음과 같습니다.
```
yarn add aws-sdk
yarn add express
```
Looker 작업 허브 서버의 Node.js 종속 항목을 설치합니다.
```
yarn install
```
작성한 테스트를 실행합니다.

yarn test

작업 테스트

전체 테스트를 위해 비공개 작업 허브 서버를 호스팅하여 Looker 인스턴스에 대해 작업을 시도할 수 있습니다. 이 서버는 유효한 SSL 인증서가 있는 공개 인터넷에 있어야 하며 Looker와의 연결 또는 HTTPS 요청을 시작하고 수신할 수 있어야 합니다. 이를 위해 다음 예에 표시된 것처럼 Heroku와 같은 클라우드 기반 플랫폼을 사용할 수 있습니다. 또는 앞에서 설명한 요구사항을 충족하는 모든 플랫폼을 사용할 수 있습니다.

로컬 작업 허브 서버 설정

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

시작하려면 브랜치를 만든 후 작업을 스테이징하고 커밋합니다. 예를 들면 다음과 같습니다.
```
git checkout -b my-branch-name
git add file-names
git commit -m commit-message
```
이 예시에서는 브랜치를 Heroku로 푸시하려면 명령줄에서 Heroku를 원격 옵션으로 Git 저장소를 구성합니다.
```
heroku login
heroku create
git push heroku
```
이제 Heroku가 사용할 작업 허브를 호스팅하는 공개 URL을 반환합니다. URL을 방문하거나 heroku logs를 실행하여 작업 허브가 실행 중인지 확인합니다. 공개 URL을 잊어버린 경우 명령줄에서 다음을 실행할 수 있습니다.
```
heroku info -s | grep web_url
```
Heroku가 공개 URL을 반환합니다. 예: https://my-heroku-action-server-1234.herokuapp.com

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

heroku config:set ACTION_HUB_BASE_URL="https://my-heroku-action-server-1234.herokuapp.com"

작업 허브 라벨을 설정합니다.

heroku config:set ACTION_HUB_LABEL="Your Action Hub"

Looker는 승인 토큰을 사용하여 작업 허브에 연결합니다. 명령줄에서 토큰을 생성합니다.
```
heroku run yarn generate-api-key
```
이 예시에서와 같이 Heroku를 사용하지 않는 경우 대신 다음을 사용하세요.
```
yarn generate-api-key
```
Heroku가 승인 토큰을 반환합니다. 예: Authorization: Token token="abcdefg123456789"
보안 비밀 키를 사용하여 작업 허브 보안 비밀을 설정합니다.
```
heroku config:set ACTION_HUB_SECRET="abcdefg123456789"
```
고객 호스팅 배포에는 여기에 설명되지 않은 추가 환경 변수 구성이 필요할 수 있습니다.
관리자 > 작업으로 이동하여 로컬 Looker 인스턴스에서 작업을 추가합니다.
- 작업 목록 하단에서 작업 허브 추가를 클릭합니다.
- 작업 허브 URL을 입력하고 필요한 경우 보안 비밀 키를 입력합니다.
- Looker의 관리 메뉴의 작업 목록에서 작업을 찾습니다.
- 사용 설정을 클릭합니다.

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

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

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

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

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

셀 수준 작업 테스트

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

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

커스텀 작업 게시 및 사용 설정

커스텀 작업에는 두 가지 게시 옵션이 있습니다.

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

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

Looker 작업 허브에 게시

이 접근 방식은 Looker를 사용하는 모든 사용자에게 제공하려는 모든 작업에 가장 쉽고 효과적입니다.

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

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

git push <your fork> <your development branch>

looker-open-source/actions 저장소를 대상으로 사용하여 pull 요청을 만듭니다.
Looker Marketplace 및 작업 허브 제출 양식을 작성합니다. 양식 요구사항에 대한 자세한 내용은 Looker Marketplace에 콘텐츠 제출을 참조하세요.

Looker에서 작업 코드를 검토합니다. Google은 PR을 거부할 권리를 보유하지만 문제가 있는 경우 이를 지원하고 개선하는 제안을 제공할 수 있습니다. 그런 다음 코드를 looker-open-source/actions 저장소에 병합하고 actions.looker.com에 배포합니다. 코드가 배포되면 모든 Looker 고객이 사용할 수 있습니다.
데이터 전송 옵션으로 표시되도록 Looker 인스턴스에서 작업을 사용 설정합니다.

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

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

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

작업에 사용할 LookML 모델 구성

Looker 작업 허브에서 사용할 수 있는 커스텀 작업과 작업 모두 LookML 모델의 tags 매개변수를 사용하여 관련 데이터 필드를 식별해야 합니다. 관리 패널의 작업 페이지에서 서비스에 필요한 태그(있는 경우)에 대한 정보를 제공합니다.

예를 들어 Twilio 메시지 전송 통합은 전화번호 목록으로 메시지를 전송합니다. 관리 패널의 작업 페이지에서 통합에는 'phone 태그가 지정된 필드가 있는 쿼리에 작업을 사용할 수 있습니다'라는 하위 텍스트가 표시됩니다.

즉, Twilio 메시지 전송 서비스에는 전화번호 필드가 포함되어 있고 tags 매개변수를 사용하여 쿼리의 어느 필드에 전화번호에 포함되어 있는지 식별하는 쿼리가 필요합니다. 해당 필드에 tags: ["phone"]을 지정하여 LookML에서 전화번호 필드를 식별합니다. 전화번호 필드의 LookML은 다음과 같을 수 있습니다.

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

태그가 필요하지 않은 통합에는 관리 패널의 작업 페이지에 '모든 쿼리에 작업을 사용할 수 있습니다'라는 하위 텍스트가 표시됩니다.

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

다음 단계

Look 또는 Explore 또는 대시보드의 콘텐츠를 통합 서비스에 전송하는 방법을 알아봅니다.