Atlassian Jira Cloud

Atlassian Jira Cloud (Core) 플로우 설정

이 주제는 Openflow Connector for Jira Cloud의 core 플로우인 Atlassian Jira Cloud (Core) 플로우를 설치하고 구성하는 단계를 설명해요. agile 플로우는 Set up the Atlassian Jira Cloud (Agile) flow에 별도로 문서화되어 있어요.

출처: Snowflake 문서

본문

참고: 이 커넥터는 Snowflake Connector Terms가 적용돼요.

이 주제는 Openflow Connector for Jira Cloud의 core 플로우인 Atlassian Jira Cloud (Core) 플로우를 설치하고 구성하는 단계를 설명해요. agile 플로우는 Set up the Atlassian Jira Cloud (Agile) flow에 별도로 문서화되어 있어요.

전제 조건(Prerequisites)

  1. About Openflow Connector for Jira Cloud을 검토했는지 확인해요.
  2. Set up Openflow - BYOC 또는 Set up Openflow - Snowflake Deployments를 설정했는지 확인해요.
  3. Openflow - Snowflake Deployments를 사용한다면 configuring required domains을 검토하고, Jira Cloud 커넥터에 필요한 도메인에 대한 액세스를 부여했는지 확인해요.

자격 증명 가져오기

Jira Cloud 관리자로서 Atlassian 계정에서 다음 작업을 수행해요:

  1. API tokens 페이지로 이동해요.
  2. Create API token with scopes를 선택해요.
  3. Create an API token 대화상자에서 API 토큰의 설명적인 이름을 제공하고 API 토큰의 만료 날짜를 선택해요. 만료 날짜는 1~365일로 할 수 있어요.
  4. API 토큰 앱 Jira를 선택해요.
  5. 사용하려는 기능에 따라 필요한 스코프를 선택해요. 자세한 내용은 Required API scopes를 참고해요.
  6. Create token을 선택해요.
  7. Copy your API token 대화상자에서 Copy를 선택해 생성된 API 토큰을 복사한 다음 커넥터 파라미터에 붙여넣거나 안전하게 저장해요.
  8. Close를 선택해 대화상자를 닫아요.

Required API scopes

스코프가 있는 Atlassian API 토큰은 클래식(classic)(더 넓음, 권장)과 세부(granular)(더 좁음) 스코프를 모두 나열해요. 클래식 스코프가 권장 시작 집합이에요. 조직이 더 좁은 토큰을 요구할 때 세부 스코프를 사용해요. 세부 토큰은 Atlassian이 엔드포인트에 나열한 모든 스코프가 필요하지 하나만은 필요하지 않아요.

core flow는 항상 다음 클래식 기준 스코프(또는 활성화한 각 테이블에 대한 동등한 세부 집합)가 필요해요:

  • read:jira-work
  • read:jira-user(사용자와 사용자 그룹, 그리고 시작 시 GET /rest/api/3/myself에 대해 실행되는 연결 검증과 시간대 조회를 포함)

API 토큰 소유자는 수집하려는 모든 프로젝트에 대해 추가로 Browse projects Jira 권한이 필요해요.

선택적 테이블을 켜는 Enabled Tables 파라미터는 Enabled tables configuration을 참고해요.

다음 표는 각 대상 테이블, 권장 클래식 스코프, Atlassian이 엔드포인트에 문서화한 전체 세부 스코프 집합, 그리고 커넥터가 호출하는 엔드포인트에 대한 링크를 나열해요:

테이블 클래식 스코프(권장) 세부 스코프 Jira API 참조 추가 Jira 권한
ISSUE (항상) read:jira-work read:issue-details:jira, read:field.default-value:jira, read:field.option:jira, read:field:jira, read:group:jira, read:jql:jira, validate:jql:jira Parse JQL query 및 Search for issues using JQL 관련 프로젝트에 대한 Browse projects
PROJECT (항상) read:jira-work read:issue-type:jira, read:project:jira, read:project.property:jira, read:user:jira, read:application-role:jira, read:avatar:jira, read:group:jira, read:issue-type-hierarchy:jira, read:project-category:jira, read:project-version:jira, read:project.component:jira Get projects paginated 관련 프로젝트에 대한 Browse projects
USER (항상) read:jira-user read:user:jira, read:application-role:jira, read:avatar:jira, read:group:jira Get all users (default) Browse users and groups (전역)
FIELD (항상) read:jira-work read:field:jira, read:avatar:jira, read:project-category:jira, read:project:jira, read:field-configuration:jira Get fields 없음
CHANGELOG read:jira-work read:issue-meta:jira, read:avatar:jira, read:issue.changelog:jira Bulk fetch changelogs 관련 프로젝트에 대한 Browse projects
COMMENT read:jira-work read:comment:jira, read:comment.property:jira, read:group:jira, read:project:jira, read:project-role:jira, read:user:jira, read:avatar:jira Get comments 관련 프로젝트에 대한 Browse projects
ISSUE_REMOTE_LINK read:jira-work read:issue.remote-link:jira, read:status:jira Get remote issue links 관련 프로젝트에 대한 Browse projects
ISSUE_SECURITY_SCHEME manage:jira-project read:issue-security-level:jira, read:issue-security-scheme:jira Get issue security schemes Administer Jira (전역)
ISSUE_TYPE read:jira-work read:issue-type:jira, read:avatar:jira, read:project-category:jira, read:project:jira Get all issue types for user 없음
ISSUE_VOTE read:jira-work read:issue.vote:jira, read:user:jira, read:application-role:jira, read:avatar:jira, read:group:jira Get votes 관련 프로젝트에 대한 Browse projects. 투표자 세부 정보를 반환하려면 View voters and watchers도 필요
ISSUE_WATCHER read:jira-work read:issue.watcher:jira, read:user:jira, read:avatar:jira Get issue watchers 관련 프로젝트에 대한 Browse projects. API 토큰 소유자가 아닌 워처의 세부 정보를 반환하려면 View voters and watchers도 필요
PERMISSION manage:jira-configuration read:permission:jira Get all permissions 없음
PRIORITY manage:jira-configuration 없음 Search priorities 없음
PROJECT_COMPONENT read:jira-work read:project:jira, read:project.component:jira, read:user:jira, read:application-role:jira, read:avatar:jira, read:group:jira Get project components paginated 관련 프로젝트에 대한 Browse projects
PROJECT_VERSION read:jira-work read:project-version:jira Get project versions paginated 관련 프로젝트에 대한 Browse projects
RESOLUTION read:jira-work read:resolution:jira Search resolutions 없음
STATUS manage:jira-configuration read:workflow:jira Search statuses paginated 관련 프로젝트에 대한 Administer projects 또는 Administer Jira (전역)
USER_GROUP read:jira-user read:group:jira Get user groups Browse users and groups (전역)
WORKLOG read:jira-work read:comment:jira, read:group:jira, read:issue-worklog:jira, read:issue-worklog.property:jira, read:project-role:jira, read:user:jira, read:avatar:jira Get IDs of updated worklogs 및 Get worklogs 없음. 제한된 작업 기록은 API 토큰 소유자가 허용된 프로젝트 역할 또는 그룹에 속할 때만 반환
DELETED_ISSUE (Deletes Fetch Strategy = AUDIT) manage:jira-configuration read:audit-log:jira, read:user:jira Get audit records Administer Jira (전역). 감사 로그는 최소 하나의 Jira 제품이 유료 플랜일 때만 사용 가능

ISSUE, CHANGELOG, COMMENT, ISSUE_REMOTE_LINK, ISSUE_VOTE, ISSUE_WATCHER 테이블의 경우, 이슈에 이슈 수준 보안이 구성되어 있으면 API 토큰 소유자도 그 이슈를 볼 수 있는 권한이 있어야 해요.

특정 역할이나 그룹으로 제한된 코멘트는 토큰 스코프나 권한 구성과 관계없이 API 토큰 소유자가 해당 역할이나 그룹의 구성원일 때만 표시돼요.

ISSUE_REMOTE_LINK 테이블은 Jira에서 이슈 연결(issue linking)이 활성화되어 있어야 해요. ISSUE_VOTE와 ISSUE_WATCHER 테이블은 각각 사용자가 이슈에 투표하고 워치할 수 있게 하는 Jira 설정이 필요해요.

스코프가 없는 토큰도 지원되며, 오로지 API 토큰 소유자의 권한에 기반해 액세스를 부여돼요. 다만 세밀한 액세스 제어를 위해 스코프가 있는 토큰을 권장해요.

Snowflake 계정 설정하기

Openflow 관리자로서 Snowflake 계정을 설정하려면 다음 작업을 수행해요. 기본 SNOWFLAKE_MANAGED 인증 전략을 사용하면 런타임의 execute-as 역할이 커넥터가 Snowflake에 접근할 때 사용하는 신원이 되므로, 그 역할에 다음 권한을 부여해요.

참고: Openflow - BYOC Deployments에 커넥터를 배포하고 권장하는 SNOWFLAKE_MANAGED 대신 KEY_PAIR 인증 전략을 사용한다면, 런타임의 관리 토큰에 의존하는 대신 이 같은 execute-as 역할을 서비스 사용자에게 부여해요. 서비스 사용자를 만들려면 Set up key-pair authentication for Openflow - BYOC Deployments을 참고해요.

데이터베이스, 스키마, 웨어하우스 만들기

  1. 대상 데이터베이스를 만들어요: 
    USE ROLE OPENFLOW_ADMIN;
CREATE DATABASE IF NOT EXISTS <destination_database>;
  2. 대상 스키마를 만들어요: 
    CREATE SCHEMA IF NOT EXISTS <destination_database>.<destination_schema>;
  3. 런타임의 execute-as 역할에 필요한 권한을 부여해요: 
    GRANT USAGE ON DATABASE <destination_database> TO ROLE OPENFLOW_<RUNTIME_NAME>_EXECUTE_AS_RL;
GRANT USAGE ON SCHEMA <destination_database>.<destination_schema> TO ROLE OPENFLOW_<RUNTIME_NAME>_EXECUTE_AS_RL;
GRANT CREATE TABLE ON SCHEMA <destination_database>.<destination_schema> TO ROLE OPENFLOW_<RUNTIME_NAME>_EXECUTE_AS_RL;
  4. 웨어하우스를 만들거나(기존 것을 사용하거나) 사용 권한을 부여해요: 
    CREATE WAREHOUSE IF NOT EXISTS <openflow_warehouse>
  WITH
  WAREHOUSE_SIZE = 'XSMALL'
  AUTO_SUSPEND = 300
  AUTO_RESUME = TRUE;

GRANT USAGE, OPERATE ON WAREHOUSE <openflow_warehouse> TO ROLE OPENFLOW_<RUNTIME_NAME>_EXECUTE_AS_RL;
  5. 커넥터가 수집한 테이블에 액세스가 필요한 다른 Snowflake 사용자가 있다면(예: Snowflake에서 커스텀 처리), 그 사용자에게 execute-as 역할을 부여해요.

커넥터 설정하기

core flow는 Atlassian Jira Cloud (Core) 프로세스 그룹으로 제공돼요. 데이터 엔지니어로서 그것을 설치하고 구성하려면 다음 작업을 수행해요.

커넥터 설치하기

데이터 엔지니어로서 커넥터를 설치하려면:

  1. Openflow의 Connector library 탭으로 이동해요.
  2. Openflow 커넥터 페이지에서 커넥터를 찾고 Install을 선택해요.
  3. Select runtime 대화상자에서 Available runtimes 드롭다운 목록에서 런타임을 선택하고 Install을 클릭해요.

참고: 커넥터를 설치하기 전에, 수집된 데이터를 저장할 Snowflake에 데이터베이스와 스키마를 만들었는지 확인해요.

  1. Snowflake 계정 자격 증명으로 배포에 인증하고, 런타임 애플리케이션이 Snowflake 계정에 접근하는 것을 허용하라는 프롬프트가 나오면 Allow를 선택해요. 커넥터 설치 과정은 완료되는 데 몇 분이 걸려요.
  2. Snowflake 계정 자격 증명으로 런타임에 인증해요. Openflow 캔버스에 커넥터 프로세스 그룹이 추가된 상태로 나타나요. 가져온 후 core flow는 캔버스에서 Atlassian Jira Cloud (Core) 프로세스 그룹으로 나타나요.

커넥터 구성하기

  1. 가져온 Atlassian Jira Cloud (Core) 프로세스 그룹을 마우스 오른쪽 버튼으로 클릭하고 Parameters를 선택해요.
  2. Flow parameters에 설명된 대로 필수 파라미터 값을 채워요.

Flow parameters

core flow는 다음 파라미터 컨텍스트를 사용해요:

Jira Cloud (Core) Source Parameters

파라미터 설명
Jira Email 인증에 사용되는 Atlassian 계정의 이메일 주소
Jira API Token Atlassian Jira 계정의 API 액세스 토큰. 구성할 스코프는 Required API scopes를 참고
Environment URL Atlassian Jira 환경의 URL. 예: https://your-domain.atlassian.net

Jira Cloud (Core) Destination Parameters

파라미터 설명 필수
Destination Database 데이터가 저장될 데이터베이스. Snowflake에 이미 존재해야 함. 이름은 대소문자를 구분함. 인용되지 않은 식별자는 대문자로 제공 예
Destination Schema 데이터가 저장될 스키마. Snowflake에 이미 존재해야 함. 이름은 대소문자를 구분함. 인용되지 않은 식별자는 대문자로 제공. 예: CREATE SCHEMA SCHEMA_NAME 또는 CREATE SCHEMA schema_name: SCHEMA_NAME 사용. CREATE SCHEMA "schema_name" 또는 CREATE SCHEMA "SCHEMA_NAME": 각각 schema_name 또는 SCHEMA_NAME 사용 예
Snowflake Authentication Strategy 다음 중 하나: Snowflake Openflow Deployment 또는 BYOC: SNOWFLAKE_MANAGED 사용(이 토큰은 Snowflake가 자동 관리함). BYOC 배포는 SNOWFLAKE_MANAGED를 사용하려면 이전에 execute-as roles을 구성해야 함. BYOC: 대안으로 BYOC는 인증 전략 값으로 KEY_PAIR를 사용할 수 있음 예
Snowflake Account Identifier 다음 중 하나: SNOWFLAKE_MANAGED 인증 전략: 비어 있어야 함. KEY_PAIR: [organization-name]-[account-name] 형식의 Snowflake 계정 이름 예
Snowflake Private Key 다음 중 하나: SNOWFLAKE_MANAGED 인증 전략: 비어 있어야 함. KEY_PAIR: PKCS8 표준에 따라 형식화되고 표준 PEM 헤더·푸터를 포함하는 인증용 RSA 개인 키. Snowflake Private Key File 또는 Snowflake Private Key 중 하나는 정의해야 함 아니요
Snowflake Private Key File 다음 중 하나: SNOWFLAKE_MANAGED 인증 전략: 개인 키 파일은 비어 있어야 함. KEY_PAIR: PKCS8 표준에 따라 형식화되고 표준 PEM 헤더·푸터를 포함하는 인증용 RSA 개인 키가 들어 있는 파일을 업로드. 헤더 줄은 -----BEGIN PRIVATE로 시작함. Reference asset 체크박스를 선택해 개인 키 파일을 업로드 아니요
Snowflake Private Key Password 다음 중 하나: SNOWFLAKE_MANAGED 인증 전략: 비어 있어야 함. KEY_PAIR: Snowflake 개인 키 파일과 연결된 비밀번호 제공 아니요
Snowflake Role 다음 중 하나: SNOWFLAKE_MANAGED 인증 전략: 런타임의 execute-as 역할(또는 그 역할에 부여된 하위 역할) 사용. execute-as 역할은 Openflow UI에서 런타임의 View Details로 이동해 찾을 수 있음. KEY_PAIR: 서비스 사용자에 대해 구성된 유효한 역할 사용 예
Snowflake Username 다음 중 하나: SNOWFLAKE_MANAGED 인증 전략: 비어 있어야 함. KEY_PAIR: Snowflake 인스턴스에 연결하는 데 사용되는 사용자 이름 제공 예
Snowflake Warehouse 쿼리를 실행하는 데 사용되는 Snowflake 웨어하우스 예

Jira Cloud (Core) Ingestion Parameters

파라미터 설명
Enabled Tables 채울 선택적 테이블의 쉼표로 구분된 목록. 전체 값 목록과 활성화할 테이블에 대한 안내는 Enabled tables configuration을 참고. 기본값: CHANGELOG, COMMENT, ISSUE_TYPE, PRIORITY, RESOLUTION, STATUS, WORKLOG
Issue Fields 필드 부분집합을 검색하기 위해 각 이슈에 대해 반환할 필드 목록. 사용 가능한 값과 커스텀 필드 처리는 Issue fields configuration을 참고. 기본값: *standard
Project Keys Filter 수집을 특정 프로젝트로 제한하는 선택적 쉼표로 구분된 Jira 프로젝트 키 목록. 비어 있으면 API 토큰 소유자가 접근할 수 있는 모든 프로젝트가 가져와짐. 예: PROJ1, PROJ2
Deletes Fetch Strategy 삭제된 이슈를 가져오는 전략. 삭제 추적을 건너뛰려면 NONE, Jira 감사 로그 엔드포인트에서 삭제된 이슈를 가져오려면 AUDIT로 설정. AUDIT 전략은 API 토큰 소유자의 Administer Jira 전역 권한과 manage:jira-configuration 스코프가 필요. 기본값: NONE
Merge Interval 저널-대상(journal-to-destination) 병합 작업 사이의 시간 간격. 병합이 실행되면 Snowflake 웨어하우스가 재개됨. 이전 병합 이후 새 데이터가 로드되지 않았으면 병합은 건너뜀. 기본값: 1 min

플로우 실행하기

  1. 캔버스를 마우스 오른쪽 버튼으로 클릭하고 Enable all Controller Services를 선택해요.
  2. Atlassian Jira Cloud (Core) 프로세스 그룹을 마우스 오른쪽 버튼으로 클릭하고 Start를 선택해요. 플로우가 데이터 수집을 시작해요. 첫 실행 시 플로우는 대상 스키마에 필요한 Snowflake 테이블을 만들어요. core flow가 만드는 전체 테이블 목록과 어떤 선택적 테이블이 채워지는지 제어하는 파라미터는 Destination tables을 참고해요.

커넥터 상태 재설정하기

프로젝트 필터를 변경하거나 처음부터 수집을 다시 시작해야 한다면 수집 상태를 지워야 해요. core flow는 프로세서별 상태가 아니라 중앙 집중식 상태 서비스를 사용해요.

상태를 재설정하려면:

  1. Atlassian Jira Cloud (Core) 프로세스 그룹을 마우스 오른쪽 버튼으로 클릭하고 Stop을 선택해요.
  2. 프로세스 그룹의 Controller Settings로 이동해요.
  3. StandardJiraIngestionStateService 컨트롤러 서비스를 찾아 View State를 선택해요.
  4. Clear State를 선택해요. 이렇게 하면 모든 프로젝트 추적, 페이지네이션, 타임스탬프 상태가 지워져요.
  5. 선택적으로 필요한 경우 커넥터 파라미터를 업데이트해요.
  6. Atlassian Jira Cloud (Core) 프로세스 그룹을 마우스 오른쪽 버튼으로 클릭하고 Start를 선택해요.

참고: 수집 상태를 지우면 커넥터가 처음부터 모든 데이터를 다시 가져와요. 대상 테이블은 truncate되지 않아요. 기존 행은 그 자리에서 업데이트되고, Jira에 더 이상 존재하지 않는 행은 _SNOWFLAKE_DELETED = TRUE로 표시돼요.

데이터 접근하기

Jira에서 가져온 데이터는 명시적 컬럼 스키마가 있는 대상 테이블에서 사용할 수 있어요. 데이터를 쿼리하기 위해 JSON 평탄화나 뷰를 사용할 필요가 없어요.

각 엔티티는 자체 테이블에 저장돼요. 예를 들어 이슈와 그 코멘트를 쿼리하려면:

SELECT i.KEY, i.SUMMARY, c.BODY AS comment_body, c.CREATED AS comment_created
FROM ISSUE i
JOIN COMMENT c ON i.ID = c.ISSUE_ID
ORDER BY c.CREATED DESC;

ISSUE 테이블은 이슈 유형, 우선순위, 해결 상태, 상태에 대한 Jira ID(표시 이름이 아니라)를 저장해요. 일치하는 조회 테이블(기본 Enabled Tables 값에 있음)을 활성화하고 조인해 이름을 해석해요:

SELECT
  i.KEY,
  i.SUMMARY,
  it.NAME AS issue_type_name,
  p.NAME AS priority_name,
  r.NAME AS resolution_name,
  s.NAME AS status_name
FROM ISSUE i
LEFT JOIN ISSUE_TYPE it ON i.ISSUE_TYPE = it.ID
LEFT JOIN PRIORITY p ON i.PRIORITY = p.ID
LEFT JOIN RESOLUTION r ON i.RESOLUTION = r.ID
LEFT JOIN STATUS s ON i.STATUS = s.ID
WHERE i._SNOWFLAKE_DELETED = FALSE;

쿼리 결과에서 삭제된 이슈를 제외하려면 커넥터가 관리하는 _SNOWFLAKE_DELETED 컬럼으로 필터링해요. 커넥터는 이슈가 Jira에서 삭제되면 일치하는 ISSUE 행에 이 플래그를 TRUE로 설정하므로 DELETED_ISSUE에 대한 안티 조인(anti-join)이 필요하지 않아요:

SELECT i.*
FROM ISSUE i
WHERE i._SNOWFLAKE_DELETED = FALSE;

DELETED_ISSUE 테이블은 삭제 타임스탬프나 삭제를 수행한 사용자가 필요할 때 여전히 유용해요. 커넥터가 관리하는 전체 메타데이터 컬럼 집합은 Connector-managed columns을 참고해요.

Enabled tables configuration

Enabled Tables 파라미터는 어떤 선택적 테이블이 채워지는지 제어해요. ISSUE, PROJECT, USER, FIELD 테이블의 수집은 항상 활성화되어 있고 비활성화할 수 없어요. ISSUE_TYPE, PRIORITY, RESOLUTION, STATUS는 ISSUE에 저장된 Jira ID를 기술적 이름으로 해석하는 조회 테이블이에요. 모든 테이블을 활성화하면 성능 문제가 발생하고 더 큰 런타임이 필요할 수 있어요.

Enabled Tables의 사용 가능한 값:

  • CHANGELOG(이슈의 필드 변경 기록)
  • COMMENT(이슈의 코멘트)
  • ISSUE_REMOTE_LINK(이슈에 첨부된 원격 링크)
  • ISSUE_SECURITY_SCHEME(이슈 수준 보안 구성)
  • ISSUE_TYPE(이슈가 참조하는 이슈 유형 이름)
  • ISSUE_VOTE(이슈에 투표한 사용자)
  • ISSUE_WATCHER(이슈를 워치하는 사용자)
  • PERMISSION(전역 및 프로젝트 권한 정의)
  • PRIORITY(이슈가 참조하는 우선순위 이름)
  • PROJECT_COMPONENT(프로젝트에 정의된 컴포넌트)
  • PROJECT_VERSION(프로젝트의 릴리스 버전)
  • RESOLUTION(이슈가 참조하는 해결 상태 이름)
  • STATUS(이슈가 참조하는 상태 이름과 범주)
  • USER_GROUP(사용자별 그룹 멤버십)
  • WORKLOG(이슈의 시간 추적 항목)

이슈별 테이블(CHANGELOG, COMMENT, ISSUE_REMOTE_LINK, ISSUE_VOTE, ISSUE_WATCHER, WORKLOG)과 프로젝트별 테이블(PROJECT_COMPONENT, PROJECT_VERSION)은 Project Keys Filter가 커버하는 이슈와 프로젝트의 데이터만 수집해요.

일부 테이블은 부모 엔티티마다 한 번씩 Jira API를 호출해 채워져요(예: 사용자당 한 번 또는 이슈당 한 번). 큰 Jira 인스턴스에서 이 테이블들을 활성화하면 API 호출 수와 수집 런타임의 부하가 크게 늘어나고, 업스트림 프로세서의 백프레셔(back-pressure) 때문에 부모 테이블 채우기가 느려질 수 있어요. 해당 데이터가 필요할 때만 이 테이블들을 활성화해요.

Issue fields configuration

ISSUE 테이블 스키마는 Issue Fields 파라미터에 따라 달라져요. 이 파라미터는 필드 ID의 쉼표로 구분된 목록 또는 아래 특수 값 중 하나를 받아요. 필드 앞에 마이너스(-)를 붙여 제외할 수 있어요. 예를 들어 *all,-description은 description을 제외한 모든 필드를 반환해요.

  • *standard(기본값): 모든 비커스텀 Jira 필드를 가져옴. Jira ID를 표시 이름으로 해석하는 방법은 Accessing the data를 참고
  • *navigable: 모든 탐색 가능한(navigable) 필드를 가져옴
  • *all: 커스텀 필드를 포함한 모든 필드를 가져옴
  • 개별 필드 ID를 지정할 수 있음(예: summary,status,customfield_10001)

기본값 *standard는 커스텀 필드를 포함하지 않아요. 커스텀 필드를 수집하려면 이 파라미터를 *all로 설정하거나 커스텀 필드를 ID로 명시적으로 나열해요(예: *standard,customfield_10001). 커스텀 필드 ID를 찾으려면 이 가이드를 따라 해요.

ISSUE 테이블의 컬럼 이름은 Jira 필드 표시 이름에서 다음 방식으로 파생돼요:

  1. 표시 이름을 대문자로 변환
  2. 공백을 밑줄로 변환
  3. 문자, 숫자, 밑줄이 아닌 모든 문자 제거

예를 들어 표시 이름 OF Test (Multi-User)는 컬럼 OF_TEST_MULTIUSER가 돼요. 이 변환 후 두 필드가 같은 컬럼 이름을 만들면 두 번째 필드의 컬럼에는 이름을 고유하게 유지하기 위해 __<flattened_field_id> 접미사가 붙어요. 예를 들어 표시 이름 Custom Field와 ID customfield_1, customfield_2인 두 필드는 CUSTOM_FIELD와 CUSTOM_FIELD__CUSTOMFIELD_2 컬럼을 만들어요.

Jira 필드 타입은 다음과 같이 Snowflake 컬럼 타입에 매핑돼요:

Jira 필드 타입 Snowflake 컬럼 타입
number NUMBER
array ARRAY
progress, votes, watches, timetracking VARIANT
기타 모든 타입 VARCHAR

다음 단계

더 알아보기 (Learn more)