무료 온라인 액세스 Workday.Workday-Pro-Integrations.v2026-01-08.q18 모의 시험 (Page 3)

Workday-Pro-Integrations 문제 6

커넥터에서 필드 재정의로 사용되는 계산된 필드가 출력에 나타나지 않습니다. 필드에 값이 있다고 가정할 때, 이 문제가 발생하는 원인은 무엇일까요?

A. Connector 계산 필드 웹 서비스에 대한 액세스가 제공되지 않습니다.

B. 계산된 필드의 모든 인스턴스에 대한 액세스가 제공되지 않습니다.

C. 계산된 필드의 모든 필드에 대한 액세스가 제공되지 않았습니다.

D. 계산된 필드 데이터 소스에 대한 액세스가 제공되지 않았습니다.

Workday-Pro-Integrations 문제 7

스타일시트 컨텍스트에서 네임스페이스의 목적은 무엇입니까?

A. 코드에서 사용할 수 있는 요소를 제공합니다.

B. 출력할 시작 태그와 끝 태그 이름을 나타냅니다.

C. 프로세서가 액세스할 수 있는 데이터를 제한합니다.

D. 변환된 결과의 파일 이름을 제어합니다.

정답: A

스타일시트 맥락에서, 특히 XSLT(Extensible Stylesheet Language Transformations)가 일반적으로 사용되는 Workday의 문서 변환 시스템 내에서 네임스페이스는 요소와 속성의 범위와 정체성을 정의하는 데 중요한 역할을 합니다. Workday의 통합 방식과 표준 XSLT 원칙에 따르면, 정답은 네임스페이스가 "코드에서 사용할 수 있는 요소를 제공한다"는 것입니다. 자세한 설명은 다음과 같습니다.
* 네임스페이스의 정의 및 목적:
* XML 기반 스타일시트(예: XSLT)의 네임스페이스는 요소와 속성을 고유한 식별자(일반적으로 URI(Uniform Resource Identifier))로 그룹화하여 이름 충돌을 방지하는 메커니즘입니다. 이를 통해 동일한 문서 또는 변환 프로세스 내에서 서로 다른 어휘나 스키마가 모호함 없이 공존할 수 있습니다.
* 안에
XSLT, 네임스페이스는 xmlns 속성을 사용하여 스타일시트에 선언됩니다(예: xmlns:xsl="
XSLT 자체의 경우 "http://www.w3.org/1999/XSL/Transform" 참조). 이러한 선언은 스타일시트에서 사용할 수 있는 요소 및 함수 집합을 정의합니다.
<xsl:template>, <xsl:value-of> 또는 <xsl:for-each>.
* 예를 들어, Workday 데이터(자체 XML 스키마 사용)를 변환할 때 Workday 특정 요소를 참조하는 네임스페이스를 정의하여 스타일시트가 해당 요소를 올바르게 식별하고 조작할 수 있습니다.
* Workday 컨텍스트에서의 적용:
* Workday의 문서 변환 통합에서 네임스페이스는 Workday(예: Core Connector 출력) 또는 외부 시스템의 XML 데이터를 처리할 때 필수적입니다. 네임스페이스는 XSLT 프로세서가 소스 XML의 올바른 요소를 인식하고 변환 규칙을 적절하게 적용할 수 있도록 합니다.
* 네임스페이스가 없으면 프로세서가 이름은 같지만 의미가 다른 요소를 잘못 해석할 수 있습니다(예: <name>이 스키마마다 다를 수 있음). 네임스페이스를 제공함으로써 스타일시트는 특정 요소 및 속성 어휘에 접근하여 변환 논리를 정확하게 코딩할 수 있습니다.
* 다른 옵션이 잘못된 이유:
* B. 출력할 시작 및 종료 태그 이름을 나타냅니다. 이는 네임스페이스가 출력의 구조(시작 및 종료 태그)를 지정하지 않기 때문에 잘못된 설명입니다. 이는 XSLT 템플릿 규칙과 출력 지침(예: <xsl:output> 또는 리터럴 결과 요소)에 의해 결정됩니다. 네임스페이스는 요소의 정체성만 정의할 뿐, 출력에서의 위치나 형식은 정의하지 않습니다.
* C. 프로세서가 액세스할 수 있는 데이터 제한: 네임스페이스는 서로 다른 요소 집합을 구분하는 데 도움이 되지만, 본질적으로 데이터 액세스를 제한하지는 않습니다. 제한은 네임스페이스 자체가 아니라 스타일시트 내의 보안 설정이나 XPath 표현식에 따라 결정됩니다.
* D. 변환된 결과의 파일 이름을 제어합니다. 네임스페이스는 출력 파일 이름과 아무런 관련이 없습니다. Workday에서 변환된 결과의 파일 이름은 일반적으로 스타일시트의 네임스페이스가 아닌 통합 첨부 서비스 또는 전송 설정(예: SFTP 또는 이메일 구성)에 의해 관리됩니다.
* 실제 예:
* 직원 데이터가 포함된 Workday XML 파일을 사용자 지정 형식으로 변환한다고 가정해 보겠습니다. 스타일시트에는 다음이 포함될 수 있습니다.
<xsl:스타일시트
버전="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:wd="http://www.workday.com
/ns"
>
<xsl:template match="wd:직원">
<직원 이름><xsl:value-of select="wd:이름"/></직원 이름>
</xsl:템플릿>
</xsl:스타일시트>
* 여기서 wd 네임스페이스는 <wd:Employee>와 같은 Workday 특정 요소에 대한 액세스를 제공합니다.
<wd:Name>은 XSLT 프로세서가 데이터를 추출하고 변환하는 데 사용할 수 있습니다.
Workday Pro 통합 학습 가이드 참조:
* Workday 통합 시스템 기본 사항: 스타일시트 내에서 요소를 식별하는 네임스페이스의 역할을 포함하여 XML 및 XSLT 기본 사항을 설명합니다.
* 문서 변환 모듈: XSLT에서 네임스페이스가 Workday XML 데이터를 처리하는 데 어떻게 사용되는지 강조하고 변환 논리에 대한 어휘를 제공하는 역할을 강조합니다(예:
"XSLT 네임스페이스 이해하기").
* 핵심 커넥터 및 문서 변환 과정 매뉴얼: Workday 특정 스키마를 처리하기 위해 네임스페이스를 선언하는 XSLT 스타일시트의 예를 포함하며, 이를 통해 사용 가능한 요소를 제공한다는 점을 강조합니다.
* Workday 커뮤니티 문서: 네임스페이스는 변환 시나리오에서 Workday의 XML 출력과 외부 시스템 요구 사항 간의 호환성을 보장하는 데 중요하다는 점을 설명합니다.

Workday-Pro-Integrations 문제 8

아래 질문에 답하려면 다음 시나리오를 참조하세요. 통합 이벤트 보고서에는 다음과 같은 실행이 포함되어 있습니다(날짜 형식: MM/DD/YYYY):
실행 #1
* Core Connector: Worker Integration System은 2024년 5월 15일 오전 3시에 출시되었습니다.
* 입력 시점: 2024년 5월 15일 오전 3시 00분
* 발효일: 2024년 5월 15일
* 마지막 성공 시점: 2024년 5월 1일 오전 3시
* 마지막 성공적인 발효일: 2024년 5월 1일
2번째 달리기
* Core Connector: Worker Integration System은 2024년 5월 31일 오전 3시에 출시되었습니다.
* 입력 시점: 2024년 5월 31일 오전 3시 00분
* 발효일: 2024년 5월 31일
* 마지막 성공 시점: 2024년 5월 15일 오전 3시
* 최종 성공 적용일: 2024년 5월 15일 2024년 5월 13일, 브라이언 힐의 급여가 인상됩니다. 새 급여는 2024년 4월 30일자로 $90,000.00로 책정되었습니다. 다음 중 브라이언 힐의 급여 변동 사항이 적용되는 것은 무엇입니까?

A. Brian Hill은 두 통합 실행 모두에 포함될 예정입니다.

B. Brian Hill은 두 번째 통합 실행에만 포함됩니다.

C. Brian Hill은 첫 번째 통합 실행에만 포함됩니다.

D. 브라이언 힐은 두 통합 실행 모두에서 제외됩니다.

정답: D

이 시나리오는 통합 이벤트 보고서에 자세히 설명된 두 가지 실행을 포함하는 Core Connector: Worker 통합을 포함합니다. 목표는 2024년 4월 30일부터 적용되고 2024년 5월 13일에 입력된 Brian Hill의 보상 변경 사항이 두 실행의 날짜 시작 매개변수를 기준으로 두 실행 중 하나에 포함될지 여부를 판단하는 것입니다. 각 실행을 변경 사항 세부 정보와 비교하여 올바른 답을 찾아 보겠습니다.
Workday에서는 Core Connector: 증분 모드에서의 작업자 통합(다음이 존재함을 나타냄)
"마지막 성공" 매개변수는 트랜잭션 로그를 기반으로 변경 사항을 처리하고, 변경 사항이 입력된 시점(Entry Moment)과 변경 사항이 적용되는 시점(Effective Date)을 기준으로 필터링합니다. 이 통합은 다음과 같은 변경 사항을 캡처합니다.
* 진입 순간은 진입 순간의 마지막 성공 시점과 진입 순간의 시점 사이에 해당합니다.
* 발효일은 마지막 성공적인 발효일과 발효일 사이에 해당합니다.
브라이언 힐의 보상 변경 사항은 다음과 같습니다.
* 입력 시점: 2024년 5월 13일(시간이 지정되지 않았으므로, 오후 11시 59분 59초 전 또는 그 사이에 발생한 것으로 추정).
* 발효일: 2024년 4월 30일.
실행 #1 분석
* 출시일: 2024년 5월 15일 오전 3시
* 입력 시점 기준: 2024년 5월 15일 오전 3시 00분 00초 - 변경 사항이 입력된 가장 최근 시점입니다.
* 발효일: 2024년 5월 15일 - 변경 사항에 대한 최신 발효일입니다.
* 마지막 성공 시점: 2024년 5월 1일 오전 3시 00분 00초 - 진입 순간의 시작점입니다.
* 마지막 성공적인 발효일: 2024년 5월 1일 - 발효일의 시작점입니다.
실행 #1에 Brian의 변경 사항을 포함하려면:
* 시작 시점(2024년 5월 13일)은 2024년 5월 1일 오전 3시와 2024년 5월 15일 오전 3시 사이여야 합니다. 2024년 5월 13일이 이 범위에 속하므로(변경 사항이 2024년 5월 1일 오전 3시 이전에 입력되었다고 가정할 경우)
(다른 규정이 없는 한 합리적으로 인정되는) 2024년 5월 15일 기준이 충족됩니다.
* 유효 날짜(04/30/2024)는 05/01/2024(마지막 성공적인 유효 날짜)와 05 사이여야 합니다.
2024년 15월 15일(시행일). 그러나 2024년 4월 30일은 2024년 1월 5일 이전이므로 이 조건은 충족되지 않습니다.
Brian의 변경 사항의 유효 날짜(2024년 4월 30일)가 마지막 성공적인 유효 날짜(2024년 5월 1일)보다 앞서기 때문에
/2024), 실행 #1에는 이 변경 사항이 포함되지 않습니다. 증분 모드에서 Workday는 마지막으로 성공적으로 적용된 적용 날짜 이전의 적용 날짜를 가진 변경 사항을 제외합니다. 이러한 변경 사항은 이전 실행(실행 #1의 기준일인 2024년 5월 1일 이전)에서 처리된 것으로 간주되기 때문입니다.
실행 #2 분석
* 출시일: 2024년 5월 31일 오전 3시
* 입력 시점: 2024년 5월 31일 오전 3시 00분 00초 - 변경 사항이 입력된 가장 최근 시점입니다.
* 발효일: 2024년 5월 31일 - 변경 사항에 대한 최신 발효일입니다.
* 마지막 성공 시점: 2024년 5월 15일 오전 3시 00분 00초 - 진입 순간의 시작점입니다.
* 마지막 성공적인 발효일: 2024년 5월 15일 - 발효일의 시작점입니다.
2번째 실행에 Brian의 변경 사항을 포함하려면:
* 입장 순간(2024년 5월 13일)은 2024년 5월 15일 오전 3시와 2024년 5월 31일 오전 3시 사이여야 합니다. 단, 2024년 5월 13일은 2024년 5월 15일 오전 3시 이전이므로 이 조건은 충족되지 않습니다.
* 유효 날짜(04/30/2024)는 05/15/2024(마지막 성공적인 유효 날짜)와 05 사이여야 합니다.
2024년 31월 31일(시행일). 2024년 4월 30일이 2024년 5월 15일 이전이므로 이 조건도 충족되지 않습니다.
실행 #2에서는 진입 순간(05/13/2024)이 진입 순간의 마지막 성공 기준(05/15/2024 3)보다 앞서 있습니다.
00:00 AM), 즉 이 실행의 감지 창 시작 지점 이전에 변경 사항이 입력되었음을 의미합니다.
또한, 발효일(2024년 4월 30일)은 마지막 성공적인 발효일(2024년 5월 15일)보다 훨씬 이전입니다.
두 필터 모두 Run #2에서 Brian이 변경한 내용을 제외합니다.
결론
* 실행 #1: 적용 날짜(2024년 4월 30일)가 마지막 성공적인 적용 날짜(2024년 5월 1일)보다 이전이기 때문에 제외되었습니다.
* 실행 #2: 진입 시점(2024년 5월 13일)이 마지막 성공 진입 시점(2024년 5월 15일 오전 3시) 이전이고, 발효일(2024년 4월 30일)이 마지막 성공 발효일(2024년 5월 15일) 이전이기 때문에 제외되었습니다.
브라이언 힐의 변경 사항은 통합이 실행 #1 이전에 증분 방식으로 실행되었다면 (2024년 5월 1일 이전) 이전 실행에서 처리되었을 것입니다. 적용 날짜(2024년 4월 30일)가 두 실행의 기준선보다 이전이기 때문입니다. 제공된 매개변수를 고려할 때, 실행 #1과 실행 #2 모두 이 변경 사항을 반영하지 않으므로, D. 브라이언 힐은 두 통합 실행 모두에서 제외됩니다. 정답은 다음과 같습니다.
Workday Pro 통합 학습 가이드 참조
* Workday 통합 학습 가이드: 핵심 커넥터: Worker - "증분 처리" 섹션에서는 마지막 성공 실행을 기준으로 입력 순간과 유효 날짜를 기준으로 변경 사항이 필터링되는 방식을 설명합니다.
* Workday 통합 학습 가이드: 출시 매개변수 - "진입 순간의 마지막 성공"과 "마지막 성공 발효일"이 이전 거래를 제외하고 새로운 변경 사항을 감지하기 위한 시작점을 정의하는 방법에 대한 자세한 설명입니다.
* Workday 통합 학습 가이드: 변경 감지 - 마지막 성공적인 적용 날짜 이전의 적용 날짜가 있는 변경 사항은 이전 실행에서 처리된 것으로 간주되고 증분 모드에서는 건너뜁니다.

Workday-Pro-Integrations 문제 9

아래 질문에 답하려면 다음 XML과 변환된 출력 예를 참조하세요.

wd:Report_Entry 출력의 변형된 예;

위의 Transformed_Record 예제에서 학위 데이터를 생성하기 위해 onwd: Educationj3group과 일치하는 템플릿의 XSLT 구문은 무엇입니까?

A.

B.

C.
{<디>}:

정답: A

Workday 통합에서 XSLT는 웹 서비스 지원 보고서 또는 EIB의 출력과 같은 XML 데이터를 타사 시스템에서 원하는 형식으로 변환하는 데 사용됩니다. 이 시나리오에서는 제공된 XML의 wd:Education_Group 요소와 일치하는 XSLT 템플릿을 만들고, 이를 변환하여 Transformed_Record 예시에 표시된 형식으로 학위 데이터를 생성해야 합니다. 목표는 각 학위(예: "California University MBA" 및 "Georgetown University BS")를 <Degrees> 부모 요소 내의 <Degree> 요소로 출력하는 것입니다.
옵션 A가 옳은 이유는 다음과 같습니다.
* 템플릿 매칭: <xsl:template match="wd:Education_Group">은 wd를 올바르게 타겟팅합니다.
XML의 Education_Group 요소에는 여러 개의 wd:Education 요소가 포함되어 있으며, 각 요소에는 wd:Degree 자식이 있습니다(예: <wd:Education>California University</wd).
교육><wd:학위>MBA</wd:학위>).
* 변환 논리:
* <Degree>는 Transformed_Record 예제의 구조(예: <Degree>California University MBA</Degree>)와 일치하여 각 교육 그룹에 대한 외부 <Degree> 요소를 생성합니다.
* <xsl:copy><xsl:value-of select="*"/></xsl:copy>는 자식 요소의 내용을 복사합니다(wd:
Education 및 wd:Degree)를 사용하여 해당 값을 단일 문자열로 연결합니다. select="*"는 wd:Education_Group의 모든 자식 요소를 대상으로 하며, xsl:value-of는 해당 자식 요소의 텍스트 콘텐츠(예:
예를 들어, "캘리포니아 대학교"와 "MBA"는 "캘리포니아 대학교 MBA"가 됩니다.)
* 이 접근 방식을 사용하면 각 wd:Education_Group이 wd:Education과 wd:Degree 값의 결합된 텍스트를 사용하여 단일 <Degree> 요소로 변환되어 예제 출력과 일치합니다.
* 컨텍스트 및 출력: 템플릿은 각 wd:Education_Group에서 작동하여 Transformed_Record에 표시된 중첩 구조를 생성합니다(예: <Degrees><Degree>CaliforniaUniversity MBA<
/Degree><Degree>조지타운 대학교 학사</Degree></Degrees>), 부모 템플릿이나 추가 논리가 <Degrees>의 <Degree> 요소를 래핑한다고 가정합니다.
다른 옵션은 왜 안 되나요?
* 나.
XML
랩카피
<xsl:template match="wd:교육_그룹">
<학위>
<xsl:값-선택="*"/>
</도>
</xsl:템플릿>
이 코드는 <xsl:value-of select="*"/>를 <xsl:copy> 없이 사용하는데, 이는 모든 자식 요소의 연결된 텍스트를 출력하지만 XML 구조나 서식을 유지하지 않습니다. 적절한 <Degree> 태그 없이 일반 텍스트(예: "California UniversityMBACalifornia UniversityB.S.")를 생성하여 예시의 구조화된 출력과 일치하지 않습니다.
* 씨.
XML
랩카피
<xsl:template match="wd:교육_그룹">
<학위>
<xsl:복사 선택="*"/>
</도>
</xsl:템플릿>
여기서는 <xsl:copy select="*"/>를 사용하지만, <xsl:copy>는 select 속성을 사용하지 않고 현재 노드만 복사합니다. 이로 인해 잘못된 XSLT 구문이 생성되어 원하는 출력을 생성하지 못하고, 결과적으로 잘못된 결과를 초래합니다.
* 디.
XML
랩카피
<xsl:template match="wd:교육_그룹">
<학위>
<xsl:복사-선택="*"/>
</도>
</xsl:템플릿>
여기서는 <xsl:copy-of select="*"/>를 사용하는데, 이는 모든 자식 노드(예: wd:Education 및 wd:Degree)를 요소 구조까지 그대로 복사하여 <Degree><wd:Education>California University</wd와 같은 출력을 생성합니다.
교육><wd:Degree>MBA</wd:Degree></Degree>. 이는 Transformed_Record 예제의 병합되고 연결된 텍스트 형식(예: <Degree>California University MBA</Degree>)과 일치하지 않으므로 올바르지 않습니다.
Workday 통합을 위해 XSLT에서 이를 구현하려면 다음을 수행합니다.
* 옵션 A의 템플릿을 사용하여 wd:Education_Group과 일치시키고 <xsl:copy><xsl:value-of select="를 적용합니다.
*"/></xsl:copy> wd:Education 및 wd:Degree 값을 하나로 연결하여 출력합니다.
<Degree> 요소를 사용합니다. 이렇게 하면 변환이 Transformed_Record 예제와 일치하여 통합 출력에 필요한 형식을 생성합니다.
참고문헌:
* Workday Pro 통합 학습 가이드: "Workday 통합을 위한 XSLT 변환" 섹션
- <xsl:template>, <xsl:copy>, <xsl:value-of>를 사용하여 XML 데이터를 변환하는 방법에 대해 자세히 설명합니다. 여기에는 wd:Education_Group과 같은 그룹화된 요소를 처리하는 것도 포함됩니다.
* Workday EIB 및 웹 서비스 가이드: "보고서 데이터를 위한 XML 및 XSLT" 장 - Workday XML의 구조(예: wd:Education_Group, wd:Education, wd:Degree)와 XSLT를 사용하여 교육 데이터를 평면화된 형식으로 변환하는 방법을 설명합니다.
* Workday 보고 및 분석 가이드: "웹 서비스 지원 보고서" 섹션 - 타사 시스템에 맞게 데이터를 연결하고 재구성하는 예를 포함하여 변환을 위해 보고서 출력을 XSLT와 통합하는 방법을 다룹니다.

Workday-Pro-Integrations 문제 10

EIB 통합을 위한 시퀀스 생성기를 구축하려면 어떤 작업이 필요합니까?

A. 시퀀스 생성기 규칙 구성 입력

B. ID 정의/시퀀스 생성기 생성

C. 테넌트 설정 편집 - 통합

D. 통합 시퀀스 생성기 서비스 구성

정답: B

Workday에서는 시퀀스 생성기를 사용하여 EIB(Enterprise Interface Builder)와 같은 통합 프로세스에 대한 고유한 순차적 식별자를 생성합니다. 이러한 식별자는 데이터 고유성을 보장하거나 레코드 추적에 대한 외부 시스템 요구 사항을 충족하는 데 종종 필요합니다. 이 질문은 EIB 통합을 위한 시퀀스 생성기 구축에 대한 내용이므로, Workday의 통합 구성 프레임워크를 기반으로 올바른 작업을 식별해야 합니다.
Workday의 시퀀스 생성기 이해
Workday의 시퀀스 생성기는 시작 번호, 증분, 형식 등 미리 정의된 규칙에 따라 순차 번호 또는 ID를 생성합니다. 이러한 생성기는 통합 과정에서 아웃바운드 또는 인바운드 데이터의 고유 식별자를 생성하여 일관성을 유지하고 외부 시스템 요구 사항을 준수하는 데 일반적으로 사용됩니다. EIB 통합의 경우, 시퀀스 생성기는 일반적으로 데이터 시퀀싱 또는 식별자 생성을 처리하기 위해 통합 설정의 일부로 구성됩니다.
옵션 분석
EIB 통합을 위한 시퀀스 생성기를 빌드하는 데 어떤 작업이 사용되는지 확인하기 위해 각 옵션을 평가해 보겠습니다.
* A. 시퀀스 생성기 규칙 구성
* 설명: 이 옵션은 시퀀스 생성기 규칙을 구성하도록 제안하지만, "시퀀스 생성기 규칙 구성 입력"은 Workday의 표준 작업 이름이나 기능이 아닙니다. Workday는 시퀀스 생성기 설정에 "ID 정의/시퀀스 생성기 생성"과 같은 특정 명명법을 사용합니다. 이 옵션은 Workday의 시퀀스 생성기 관련 문서화된 작업과 일치하지 않으므로 모호하거나 잘못된 것으로 보입니다.
* 정답이 아닌 이유: 이는 인식된 Workday 작업이 아니며, 시퀀스 생성기 구성은 일반적으로 이 맥락에서 "넣기" 또는 규칙 기반 구성이 아닌 특정 설정 프로세스를 통해 처리됩니다.
* B. ID 정의/시퀀스 생성기 생성
* 설명: 이것은 시퀀스 생성기를 만들고 구성하는 데 사용되는 표준 Workday 작업입니다.
Workday에서는 통합 또는 설정 도메인의 "ID 정의/시퀀스 생성기 만들기" 작업으로 이동하여 시퀀스 생성기를 정의합니다. 이 작업을 통해 시작 번호, 증분, 형식(예: 숫자, 영숫자) 및 범위(예: 테넌트 전체 또는 통합별)를 지정할 수 있습니다. EIB 통합의 경우, 이 작업은 데이터 레코드의 고유 ID 또는 시퀀스를 생성하는 데 사용됩니다.
* 정답 이유: 이 작업은 통합 가이드에 설명된 Workday 시퀀스 생성기 설정 설명서와 직접적으로 일치합니다. EIB 또는 기타 통합에서 사용할 시퀀스 생성기를 빌드하는 표준 방법입니다.
* C. 테넌트 설정 편집 - 통합
* 설명: 이 작업은 서비스 활성화, 보안 구성 또는 통합 매개변수 조정과 같은 광범위한 테넌트 수준 통합 설정을 수정하는 작업을 포함합니다. 통합 내에서 시퀀스 생성기를 사용할 수 있지만, 이 작업은 너무 상위 수준이며 시퀀스 생성기 생성 또는 구성에 대한 구체적인 내용을 다루지 않습니다.
* 정답이 아닌 이유는?: 시퀀스 생성기 설정에 충분히 세부적이지 않습니다. 시퀀스 생성기의 특정 생성보다는 테넌트 전체 통합 구성에 초점을 맞춥니다.
* D. 통합 시퀀스 생성기 서비스 구성
* 설명: 이 옵션은 통합 내에서 시퀀스 생성을 위한 서비스를 특별히 구성할 것을 제안합니다. 하지만 Workday는 "통합 시퀀스 생성기 서비스 구성"이라는 작업을 사용하지 않습니다. 시퀀스 생성기는 일반적으로 독립형 서비스가 아닌 ID 정의로 설정됩니다. 이 옵션은 잘못된 명칭이거나 비표준 용어인 것 같습니다.
* 정답이 아닌 이유: 이는 인식된 Workday 작업이 아니며, 시퀀스 생성기는 서비스 구성이 아닌 "ID 정의/시퀀스 생성기 만들기"를 통해 구성됩니다.
결론
Workday의 통합 프레임워크 및 문서에 따르면, EIB 통합을 위한 시퀀스 생성기를 구축하는 올바른 작업은 B. ID 정의/시퀀스 생성기 생성입니다. 이 작업을 통해 EIB에서 사용할 필수 매개변수(예: 시작 값, 증분, 형식)를 사용하여 시퀀스 생성기를 정의하고 구성할 수 있습니다. 이는 Workday Pro 통합 교육 자료에 설명된 대로 통합에서 고유 식별자를 보장하기 위한 표준 관행입니다.
놀라운 통찰력
Workday의 시퀀스 생성기는 매우 유연하여 직원 ID, 거래 번호 또는 통합별 시퀀스 생성 등 다양한 사용 사례에 맞게 사용자 정의가 가능하다는 점이 흥미롭습니다.
"ID 정의/시퀀스 생성기 만들기" 작업은 간단해서 기술에 익숙하지 않은 사용자도 쉽게 사용할 수 있으며, 이는 Workday의 무코드 통합 철학과 일치합니다.
주요 인용문
* Workday Pro 통합 학습 가이드, 모듈 3: EIB 구성
* Workday 통합 Cloud Connect: 시퀀스 생성기
* Workday EIB 및 시퀀스 생성기 개요
* Workday 통합 구성: ID 정의