WEBVTT

00:00:00.000 --> 00:00:02.580
마이크로소프트 날리지 너겟지위 또 다른 에피소드에 오신 것을 환영합니다.

00:00:02.700 --> 00:00:04.020
진행을 맡은 미로 피터스입니다.

00:00:04.220 --> 00:00:05.660
자, 이런 상황을 가정해보겠습니다.

00:00:05.980 --> 00:00:08.880
비즈니스 센트럴에서 작업하다가 작은 변경이 하나 필요해졌습니다.

00:00:09.060 --> 00:00:12.200
고객 레코드에 필드를 추가하거나 다른 승인 단계를 설정하거나

00:00:12.200 --> 00:00:14.520
주문 개시 전에 확인하는 규칙이 필요한 경우죠.

00:00:14.660 --> 00:00:18.620
그런데 누군가 AL 확장 기능, 테이블, 페이지, 코드 유닛을 언급하면

00:00:18.620 --> 00:00:21.380
갑자기 그 작은 요청이 완전히 새로운 언어처럼 들리게 됩니다.

00:00:21.640 --> 00:00:24.400
분명 언어는 맞지만 그렇다고 미스터리하게 느낄 필요는 없습니다.

00:00:24.680 --> 00:00:27.020
비즈니스 센트럴을 사무용 건물이라고 생각해보세요.

00:00:27.020 --> 00:00:30.320
AL은 개발자에게 건물 자체를 허물지 않고도 방이나 양식,

00:00:30.660 --> 00:00:32.680
새로운 규칙을 추가할 수 있는 지침을 제공합니다.

00:00:32.840 --> 00:00:35.320
오늘의 지식 한 조각, 날리지 너겟은 바로 이것입니다.

00:00:35.480 --> 00:00:37.480
이 에피소드가 끝날 때 쯤이면 AL 개발이 무엇인지,

00:00:37.760 --> 00:00:38.760
왜 확장 기능이 존재하는지,

00:00:39.020 --> 00:00:41.640
그리고 커스텀 작업이 비즈니스 센트럴에 어떻게 적용되는지 알게 될 것입니다.

00:00:41.820 --> 00:00:44.480
기업들이 왜 비즈니스 센트럴을 커스터마이징하는지 알아보겠습니다.

00:00:44.720 --> 00:00:48.060
비즈니스 센트럴은 이미 재무, 고객, 판매 주문, 재고 송장 등

00:00:48.060 --> 00:00:50.260
매일의 업무를 스프레드시트나 개별도구 더미가 아닌

00:00:50.260 --> 00:00:51.840
하나의 연결된 시스템에서 처리합니다.

00:00:52.000 --> 00:00:54.920
많은 기업에게 기본 설정만으로도 업무의 대부분은 해결됩니다.

00:00:55.120 --> 00:00:56.620
하지만 문제는 여기서 시작됩니다.

00:00:56.820 --> 00:00:58.420
똑같이 일하는 기업은 하나도 없습니다.

00:00:58.720 --> 00:01:00.540
다른 회사에서는 전혀 쓰지 않는 배치, 배치,

00:01:00.720 --> 00:01:02.480
세부 정보가 필요한 식품 유통업체를 예로 들어보죠.

00:01:02.620 --> 00:01:05.760
송장 발행 전 특별한 승인 절차가 필요한 서비스 업종도 있습니다.

00:01:06.040 --> 00:01:08.680
할인을 위해 보상 등급을 원하는 소매업체도 있죠.

00:01:08.920 --> 00:01:12.860
또는 자신들만의 용어필드와 내부 규칙이 담긴 양식이 필요한 곳도 있습니다.

00:01:12.860 --> 00:01:16.260
기업은 필드 하나가 없다고 해서 운영 방식을 바꾸지는 않을 것입니다.

00:01:16.440 --> 00:01:20.500
그렇다고 모든 작은 요청이 전체 시스템을 위험하게 바꾸는 상황으로 이어지는 것도 원치 않으실 겁니다.

00:01:20.700 --> 00:01:22.360
과거에는 그것이 더 큰 문제였습니다.

00:01:22.720 --> 00:01:26.040
이전 시스템에서는 개발자가 원본 코드를 열어 직접 편집했습니다.

00:01:26.320 --> 00:01:28.720
다음 업데이트가 오기 전까지는 잘 작동했죠.

00:01:28.900 --> 00:01:31.660
그러고 나면 기업은 한쪽에는 마이크로소프트 위의 새 버전이,

00:01:32.020 --> 00:01:36.700
다른 한쪽에는 자체 변경 사항이 남게 되어 업데이트를 진행하기 전에 누군가의 모든 것을 조정해야 했습니다.

00:01:36.900 --> 00:01:41.200
세입자마다 계획 없이 벽을 뚫고 새 케이블을 설치하는 사무실을 상상해보세요.

00:01:41.440 --> 00:01:44.120
한동안은 작동하겠지만 건물을 수리해야 할 때가 오면

00:01:44.120 --> 00:01:46.380
아무도 그 케이블이 누구 것인지 알 수 없게 됩니다.

00:01:46.580 --> 00:01:48.800
비즈니스 센트럴은 다른 방식을 택합니다.

00:01:49.040 --> 00:01:51.600
개발자는 표준 애플리케이션을 다시 작성하는 대신

00:01:51.600 --> 00:01:53.760
표준 구성 요소는 그대로 유지하면서

00:01:53.760 --> 00:01:56.580
회사만의 변경 사항은 별도의 추가 기능으로 구축하여

00:01:56.580 --> 00:01:58.860
시스템의 지원 지점을 통해 연결되도록 합니다.

00:01:59.060 --> 00:02:00.980
이러한 분리는 업데이트 시 중요합니다.

00:02:01.240 --> 00:02:03.320
마이크로소프트는 건물의 자기 부분을 업데이트하고

00:02:03.320 --> 00:02:05.920
커스텀 작업은 자신의 공간에 그대로 유지되기 때문입니다.

00:02:06.080 --> 00:02:08.760
물론 소프트웨어 변경인 만큼 여전히 테스트와 수정은 필요하지만

00:02:08.760 --> 00:02:11.240
개발자가 마이크로소프트 위 원본 코드 내부에서

00:02:11.240 --> 00:02:13.620
모든 변경 사항을 복사하고 다시 작업할 필요는 없습니다.

00:02:13.900 --> 00:02:16.180
그렇다면 기업은 실제로 무엇을 커스터마이징 할까요?

00:02:16.440 --> 00:02:18.020
커스터마이징은 데이터를 추가합니다.

00:02:18.240 --> 00:02:21.500
표준 시스템은 배송 지침, 내부 위험 점수, 멤버십 등급,

00:02:21.740 --> 00:02:24.100
외부 시스템 링크와 같은 정보를 저장하지 않으니까요.

00:02:24.220 --> 00:02:27.500
또한 직원이 올바른 순서로 업무를 수행하도록 안내하는 화면을 추가합니다.

00:02:27.700 --> 00:02:31.420
필수 문서가 누락되었을 때 주문을 중단하는 것과 같은 규칙을 적용하기도 합니다.

00:02:31.640 --> 00:02:34.480
사용자 지정 작업은 사람들이 수동 단계를 피하도록 돕기도 합니다.

00:02:34.480 --> 00:02:41.340
매주 금요일마다 직원이 비즈니스 센트럴에서 다른 도구로 고객 데이터를 복사하고 조건을 직접 확인한 다음 관리자에게 보고서를 보내는 상황을 상상해보세요.

00:02:41.540 --> 00:02:48.120
잘 설계된 변경 작업은 해당 정보를 비즈니스 센트럴 내에 유지하고 규칙을 일관되게 적용하며 직원에게 일상 업무에 맞는 버튼이나 페이지를 제공합니다.

00:02:48.300 --> 00:02:49.860
잘못된 통념을 바로 잡아보겠습니다.

00:02:50.180 --> 00:02:51.920
모든 것을 커스터마이징해서는 안됩니다.

00:02:52.080 --> 00:02:54.660
표준 비즈니스 센트럴에는 이미 많은 프로세스가 내장되어 있습니다.

00:02:54.920 --> 00:02:58.380
단지 이전 시스템과 달라 보인다는 이유만으로 무언가를 변경하면 나중에 추가적인 작업이 발생합니다.

00:02:58.380 --> 00:03:01.220
따라서 좋은 사용자 지정 작업은 명확한 비즈니스 이유에서 시작됩니다.

00:03:01.380 --> 00:03:04.620
사람들이 어떤 문제를 겪고 있나요? 대신 어떤 일이 일어나야 하나요?

00:03:04.740 --> 00:03:07.040
표준 제품으로 이미 처리할 수 있는 일은 아닐까요?

00:03:07.200 --> 00:03:10.620
표준 제품이 그 요구사항을 충족하지 못할 때 AL이 등장합니다.

00:03:10.860 --> 00:03:18.860
AL은 비즈니스 센트럴 자체에 집중하여 데이터베이스 수준에서 레코드를 읽고 추가하고 변경하는 동시에 페이지, 보고서 및 기타 애플리케이션 영역에서 일어나는 일을 제어합니다.

00:03:19.040 --> 00:03:24.360
또한 값을 계산하고 데이터를 이동하며 프로세스 전반에서 규칙이 위반될 경우 메시지를 표시합니다.

00:03:24.360 --> 00:03:34.040
하나의 언어로 하기에는 많은 작업이지만, AL은 모든 유형의 소프트웨어를 위한 범용 도구가 아니면 공개 쇼핑 웹사이트, 모바일 게임 또는 독립형 데스크톱 앱을 만드는 데 선택하지는 않습니다.

00:03:34.240 --> 00:03:40.920
AL은 오직 한 가지 목적, 즉 비즈니스 센트럴 내부의 데이터와 동작을 형성하여 시스템이 기업의 운영 방식과 일치하도록 만드는 데 존재합니다.

00:03:41.080 --> 00:03:42.780
다음으로 바로 이 점을 살펴보겠습니다.

00:03:43.220 --> 00:03:45.880
AL과 확장 기능, 안전한 애드온 모델입니다.

00:03:46.180 --> 00:03:49.380
AL은 애플리케이션 언어, 애플리케이션 랭귀지, 위 약자입니다.

00:03:49.380 --> 00:03:57.460
이는 마이크로소프트 위 비즈니스 센트럴 용 프로그래밍 언어이며, 개발자에게 새로운 비즈니스 기능을 만들거나 기존 시스템의 동작 방식을 변경할 수 있는 구조화된 방법을 제공합니다.

00:03:57.640 --> 00:04:00.800
하지만 확장 기능, 익스텐션이라는 단어는 AL만큼이나 중요합니다.

00:04:00.960 --> 00:04:03.800
확장 기능은 비즈니스 센트럴에 설치할 수 있는 별도의 앱입니다.

00:04:04.000 --> 00:04:08.480
이는 표준 비즈니스 센트럴 애플리케이션을 건드리지 않고 기업의 사용자 지정 작업을 보관합니다.

00:04:08.680 --> 00:04:12.100
핸드북을 새로 쓰는 것보다는 승인된 페이지를 추가하는 것이라고 생각하세요.

00:04:12.340 --> 00:04:15.120
그렇죠. 원본 규칙을 지우지 않고 따르는 페이지들 말입니다.

00:04:15.120 --> 00:04:19.140
기술적인 세부사항처럼 들릴 수 있지만, 시간이 지남에 따라 사용자 지정 작업이 유지되는 방식을 바꿉니다.

00:04:19.240 --> 00:04:22.220
회사가 특별한 팀을 위한 새로운 사무실 공간이 필요하다고 상상해보세요.

00:04:22.460 --> 00:04:26.100
예전 방식은 본 건물의 벽을 허물고 구조 자체를 바꾸는 것을 의미했습니다.

00:04:26.400 --> 00:04:32.040
당장은 문제를 해결할 수 있어도 원래 건물이 설계도와 달라지기 때문에 나중에 수리하는 것은 악몽이 될 수 있습니다.

00:04:32.240 --> 00:04:34.520
확장 기능, 익스텐션은 다르게 작동합니다.

00:04:34.720 --> 00:04:38.040
건물에는 이미 문과 콘센트 그리고 공간을 추가하기 위한 규칙이 마련되어 있습니다.

00:04:38.300 --> 00:04:40.580
승인된 연결 지점을 통해 새로운 방을 짓는 것입니다.

00:04:40.580 --> 00:04:44.960
방은 회사 소유이지만, 메인 건물은 모든 맞춤형 벽을 허물지 않고도 계속 유지 보수할 수 있습니다.

00:04:45.160 --> 00:04:47.740
그것이 바로 비즈니스 센트럴 확장 기능이 작동하는 방식입니다.

00:04:47.920 --> 00:04:50.940
기본 애플리케이션에는 마이크로소프트가 제공하는 표준 작업이 포함되어 있습니다.

00:04:51.200 --> 00:04:56.080
확장 기능을 사용하면 고유한 필드, 화면, 버튼, 규칙, 보고서, 심지어 다른 시스템과의 연결까지 추가할 수 있습니다.

00:04:56.240 --> 00:05:01.640
특정 비즈니스 작업이 발생할 때 반응할 수 있지만, 이는 표준 애플리케이션에 연결하는 지원되는 방식을 통해서만 이루어집니다.

00:05:01.800 --> 00:05:03.280
그래서 경계가 내장되어 있습니다.

00:05:03.600 --> 00:05:04.520
이는 좋은 일입니다.

00:05:04.520 --> 00:05:08.740
경계가 없으면 작은 사용자 지정 요청이 건드리지 말아야 할 깊은 영역까지 침범할 수 있습니다.

00:05:08.940 --> 00:05:16.440
확장 기능을 사용하면 개발자는 명확한 개최 유형과 정의된 연결 지점을 사용하여 작업함으로, 나중에 다른 사람이 코드를 읽을 때 이해하기가 더 쉽습니다.

00:05:16.620 --> 00:05:19.980
이 접근 방식은 클라우드 버전의 비즈니스 센트럴 애도 완벽하게 부합합니다.

00:05:20.320 --> 00:05:22.700
마이크로소프트는 서비스를 정기적으로 업데이트합니다.

00:05:22.900 --> 00:05:27.720
회사는 변경 사항 발생 후, 특히 변경된 제품 부품에 의존하는 경우 확장 기능을 테스트해야 합니다.

00:05:27.940 --> 00:05:30.620
소프트웨어가 유지 관리의 필요성을 완전히 없애주지는 않습니다.

00:05:30.620 --> 00:05:36.420
하지만 사용자 지정 코드를 별도로 유지하면 모든 업데이트가 기존 수정 사항을 대대적으로 재구축해야 하는 상황이 될 가능성이 줄어듭니다.

00:05:36.560 --> 00:05:41.020
이전 다이나믹스 NAV 시스템에 대해 이야기할 때 사람들이 C, AL을 언급하는 것을 들을 수 있습니다.

00:05:41.240 --> 00:05:46.540
C, AL은 개발자가 종종 원래 애플리케이션 개최를 직접 변경하던 초기 개발 모델에서 나왔습니다.

00:05:46.780 --> 00:05:49.760
많은 기업이 수년간 그런 방식으로 성공적으로 시스템을 운영했지만,

00:05:50.180 --> 00:05:55.200
이는 사용자 지정 작업을 표준 코드와 훨씬 더 밀접하게 결합시켰고, 업데이트 시 많은 비교 및 복구 작업이 필요했습니다.

00:05:55.480 --> 00:05:58.020
AL은 비즈니스 센트럴 룰랩 기반 개발로 전환했습니다.

00:05:58.020 --> 00:06:01.200
그렇다고 모든 확장 기능이 크거나 복잡하다는 의미는 아닙니다.

00:06:01.360 --> 00:06:05.380
어떤 확장 기능은 고객 레코드에 필드를 추가하고 익숙한 화면에 표시하는 정도일 수 있습니다.

00:06:05.600 --> 00:06:11.740
다른 확장 기능은 특정 비즈니스 유형을 위한 전체 솔루션으로서 고유한 레코드, 프로세스, 페이지 및 보고서를 포함할 수 있습니다.

00:06:11.940 --> 00:06:13.780
둘 다 동일한 기본 아이디어를 따릅니다.

00:06:14.100 --> 00:06:17.880
사용자 지정 앱은 비즈니스 센트럴을 제작성하여 숨기는 대신 그 옆에서 공존합니다.

00:06:18.080 --> 00:06:20.080
둘 이상의 확장 기능을 설치할 수도 있습니다.

00:06:20.080 --> 00:06:27.980
한 회사가 급여 관리를 위해 소프트웨어 파트너의 확장 기능을 사용하고, 배송을 위해 다른 확장 기능을 사용하며, 회사에만 중요한 규칙을 위해 작은 내부 확장 기능을 사용할 수 있습니다.

00:06:28.180 --> 00:06:33.580
비즈니스 센트럴은 이러한 확장 기능들이 플랫폼 규칙을 따르고 충돌하지 않는 한 하나의 작동 시스템으로 통합합니다.

00:06:33.760 --> 00:06:36.220
따라서 AL은 단순한 코드 작성 방식이 아닙니다.

00:06:36.220 --> 00:06:42.460
개발자가 이러한 추가 앱을 만드는데 사용하는 언어이며, 확장 기능은 이러한 변경 사항을 비즈니스 센트럴로 전달하는 컨테이너입니다.

00:06:42.620 --> 00:06:47.480
이 모델을 사용하면 기업은 표준 제품의 형태를 유지하여 관리 편의성을 높이면서도 시스템을 맞춤화할 수 있습니다.

00:06:47.680 --> 00:06:50.980
이제 이러한 확장 기능 중 하나를 열어 그 안에 구성 요소를 살펴보겠습니다.

00:06:51.340 --> 00:06:54.060
AL 확장 프로그램 내의 주요 AL 구성 요소들입니다.

00:06:54.260 --> 00:06:56.600
개발자 들은 개체, 오브젝트를 다룹니다.

00:06:56.780 --> 00:07:02.680
개체는 정보 저장, 화면 표시, 규칙 실행, 문서 생성과 같은 명확한 작업을 수행하는 앱의 이름이 지정된 조각입니다.

00:07:02.680 --> 00:07:06.940
이러한 작업들을 개별적으로 파악하게 되면 AL은 코드의 거대한 장벽처럼 느껴지지 않게 됩니다.

00:07:07.100 --> 00:07:09.260
비즈니스 정보가 저장되는 곳부터 시작해보겠습니다.

00:07:09.600 --> 00:07:11.860
비즈니스 센트럴에서 테이블은 데이터를 저장합니다.

00:07:12.040 --> 00:07:14.940
테이블을 특정 유형의 레코드를 위한 디지털 캐비닛이라고 생각하세요.

00:07:15.140 --> 00:07:19.100
한 캐비닛에는 고객, 다른 캐비닛에는 품목, 또 다른 캐비닛에는 판매 주문이 들어갈 수 있습니다.

00:07:19.320 --> 00:07:21.440
각 레코드는 그 캐비닛 안의 파일 하나와 같습니다.

00:07:21.800 --> 00:07:24.540
고객 테이블은 각 고객에 대한 레코드를 하나씩 포함합니다.

00:07:24.720 --> 00:07:27.640
품목 테이블은 각 제품에 대한 레코드를 하나씩 포함합니다.

00:07:27.640 --> 00:07:36.960
회사의 표준 비즈니스 센트럴에서 저장하지 않는 정보가 필요한 경우 확장 기능을 통해 보상 등급, 장비 점검, 프로젝트 승인 등을 위한 자체 테이블을 만들 수 있습니다.

00:07:37.160 --> 00:07:39.760
필드는 각 레코드 안에 이름이 지정된 공간입니다.

00:07:39.980 --> 00:07:46.620
고객 테이블에는 세부 정보를 위한 필드가 포함되어 있으므로 고객 레코드의 이름, 주소, 결제 조건, 전화번호를 포함할 수 있습니다.

00:07:46.820 --> 00:07:51.700
필드에는 텍스트, 날짜, 금액, 예, 아니오, 답변 또는 고정된 목록에서의 선택사항을 저장할 수 있습니다.

00:07:51.880 --> 00:07:53.780
필드는 다른 레코드를 가리킬 수도 있습니다.

00:07:53.780 --> 00:07:56.840
예를 들어, 고객 레코드에는 보상 아이디 필드가 포함될 수 있습니다.

00:07:57.040 --> 00:08:00.920
직원들은 이미 텍스트를 입력하는 대신 별도의 보상 테이블에서 보상 등급을 선택합니다.

00:08:01.100 --> 00:08:04.460
이러한 연결은 모두가 동일한 알려진 목록에서 선택하도록 하여 데이터를 깔끔하게 유지합니다.

00:08:04.620 --> 00:08:06.220
즉, 테이블은 사실 관계를 저장합니다.

00:08:06.400 --> 00:08:08.360
그렇다면 사람들은 어떻게 이러한 사실을 보고 다룰까요?

00:08:08.580 --> 00:08:09.140
페이지입니다.

00:08:09.340 --> 00:08:11.220
페이지는 비즈니스 센트럴에서 여는 화면입니다.

00:08:11.420 --> 00:08:12.780
고객 카드는 하나의 페이지입니다.

00:08:12.980 --> 00:08:14.640
판매 주문 목록도 하나의 페이지입니다.

00:08:14.840 --> 00:08:18.080
페이지는 사용자가 무엇을 보고, 입력하고, 검색하고, 조치를 취할 수 있는지 제어합니다.

00:08:18.080 --> 00:08:20.020
작업에 따라 적합한 페이지가 다릅니다.

00:08:20.200 --> 00:08:23.920
카드 페이지는 한 번에 한 명이 고객이나 하나의 품목과 같은 단일 레코드에 집중합니다.

00:08:24.120 --> 00:08:26.240
목록 페이지는 많은 레코드를 행으로 보여주며,

00:08:26.640 --> 00:08:29.580
빠르게 훑어보거나 필터링하거나 무언가를 찾을 때 유용합니다.

00:08:29.800 --> 00:08:34.400
워크시트 페이지는 사용자가 여러 줄의 정보를 함께 입력하거나 처리하는 작업을 지원합니다.

00:08:34.640 --> 00:08:36.120
테이블은 정보를 저장합니다.

00:08:36.380 --> 00:08:38.440
페이지는 정보를 사용자에게 보여줍니다.

00:08:38.680 --> 00:08:41.820
이러한 분리는 데이터의 저장 위치를 바꾸지 않고도 화면을 변경할 수 있거나,

00:08:41.820 --> 00:08:47.740
여러 팀이 동일한 레코드에 대해 서로 다른 보기가 필요할 때 동일한 테이블을 여러 페이지에서 재사용할 수 있게 해줌으로 유용합니다.

00:08:47.900 --> 00:08:51.480
그렇다면 데이터가 이미 표준 비즈니스 센트럴 레코드에 속해 있다면 어떻게 해야 할까요?

00:08:51.640 --> 00:08:54.980
단지 추가 필드 하나가 필요하다고 해서 고객 테이블을 새로 만들지는 않을 것입니다.

00:08:55.180 --> 00:08:56.720
이때는 테이블 확장을 사용합니다.

00:08:56.920 --> 00:09:00.040
테이블 확장을 사용하면 기존 고객 테이블에 필드를 추가할 수 있습니다.

00:09:00.260 --> 00:09:02.480
표준 고객 레코드는 원래 위치에 그대로 유지되면서,

00:09:02.880 --> 00:09:05.860
확장을 통해 표준 필드 옆에 회사 고유의 세부 정보를 추가하게 됩니다.

00:09:05.860 --> 00:09:11.120
예를 들어 보상 아이디, 배송 메모, 계정관리자 또는 비즈니스의 다른 부분과 연결되는 필드 등이 있을 수 있습니다.

00:09:11.320 --> 00:09:14.520
하지만 테이블에 필드를 추가한다고 해서 자동으로 화면에 나타나는 것은 아닙니다.

00:09:14.700 --> 00:09:16.640
이를 위해서는 페이지 확장을 사용해야 합니다.

00:09:16.820 --> 00:09:20.000
페이지 확장은 기존 페이지의 필드, 그룹 또는 작업을 추가합니다.

00:09:20.200 --> 00:09:22.500
고객을 조회하면서 보상 등급을 선택해야 하는 경우,

00:09:22.940 --> 00:09:27.380
페이지 확장을 사용하면 직원들이 이미 작업 중인 고객 카드에 보상 아이디 필드를 배치할 수 있습니다.

00:09:27.640 --> 00:09:29.900
이렇게 하면 익숙한 사용자 경험을 유지할 수 있습니다.

00:09:29.900 --> 00:09:33.380
간단한 세부 정보 때문에 사용자를 별도의 사용자 지정 화면으로 이동시키는 대신,

00:09:33.380 --> 00:09:35.780
이미 알고 있는 페이지에 해당 정보를 추가하는 것입니다.

00:09:35.920 --> 00:09:40.620
페이지 확장을 사용하여 작업을 시작하는 버튼이나 메뉴 명령 같은 작업 항목을 추가할 수도 있습니다.

00:09:40.860 --> 00:09:44.540
예를 들어 고객 카드의 보상 목록을 여는 보상 작업을 포함할 수 있습니다.

00:09:44.800 --> 00:09:47.360
화면 뒤편에는 비즈니스 규칙을 저장할 공간이 필요합니다.

00:09:47.560 --> 00:09:49.720
그 공간은 보통 코드 유닛, 코드 유닛이 담당합니다.

00:09:49.900 --> 00:09:53.600
코드 유닛에는 특정 작업을 수행하는 명령된 코드 조각인 AL 프로시저가 포함되어 있습니다.

00:09:53.600 --> 00:09:59.080
페이지, 보고서 또는 기타 프로세스에서 지원을 요청할 때 작업을 처리하는 백오피스 팀이라고 생각하면 됩니다.

00:09:59.260 --> 00:10:02.780
보상 등급에 따라 고객에게 적용될 할인이 결정된다고 가정해보겠습니다.

00:10:03.180 --> 00:10:07.040
할인 계산 로직은 고객 카드 페이지 자체가 아닌 코드 유닛에 두어야 합니다.

00:10:07.260 --> 00:10:13.040
그러면 영업 프로세스, 보고서 또는 추후 생성될 페이지에서 동일한 규칙을 여러 곳에 복사할 필요 없이 재사용할 수 있습니다.

00:10:13.260 --> 00:10:15.460
하나의 규칙을 하나의 장소에서 관리하는 것입니다.

00:10:15.660 --> 00:10:18.680
비즈니스 센트럴에는 다양한 작업을 위한 다른 개체 유형도 포함되어 있습니다.

00:10:18.680 --> 00:10:23.240
보고서는 데이터를 수집하여 송장이나 판매 보고서와 같은 문서 또는 레이아웃으로 표시합니다.

00:10:23.380 --> 00:10:28.480
커리는 특정 기간 동안 특정 품목을 주문한 고객이 누구인지와 같이 데이터에 대한 집중적 인질문을 던집니다.

00:10:28.640 --> 00:10:35.440
예를 들어, XML 포트는 다른 시스템이 비즈니스 센트럴과 정보를 교환해야 할 때 데이터를 구조화된 형식으로 가져오거나 내보내는 데 도움을 줍니다.

00:10:35.640 --> 00:10:39.320
이러한 요소들을 조합하면 소규모 고객 보상 확장을 구현하는 모습을 그려볼 수 있습니다.

00:10:39.560 --> 00:10:41.900
보상 테이블은 각 등급과 할인율을 저장합니다.

00:10:41.900 --> 00:10:44.920
보상 페이지를 통해 직원들은 해당 등급을 관리할 수 있습니다.

00:10:45.160 --> 00:10:50.120
고객 테이블 확장은 각 고객에게 보상 아이디를 추가하고, 고객 카드 페이지 확장은 이를 화면에 표시합니다.

00:10:50.120 --> 00:10:54.280
페이지 작업은 보상 목록을 열고, 코드 유닛은 할인 규칙을 계산합니다.

00:10:54.480 --> 00:10:56.580
각 개체는 작업의 한 부분을 처리합니다.

00:10:56.800 --> 00:11:01.900
이를 통해 6개월 후 비즈니스 규칙이 변경될 때 확장을 더 쉽게 읽고, 테스트하고, 변경할 수 있습니다.

00:11:02.100 --> 00:11:06.420
하지만 비즈니스 규칙은 누군가 주문을 정기할 때와 같이 정확한 시점에 실행되어야 하는 경우가 많습니다.

00:11:06.600 --> 00:11:08.140
이때 트리거와 이벤트가 필요합니다.

00:11:08.320 --> 00:11:10.320
이벤트, 트리거, 그리고 비즈니스 규칙.

00:11:10.460 --> 00:11:12.000
자, 고객 보상 필드를 추가했습니다.

00:11:12.280 --> 00:11:12.720
좋습니다.

00:11:12.980 --> 00:11:14.100
진짜 질문은 이건입니다.

00:11:14.260 --> 00:11:16.380
비즈니스 센트럴은 언제 그 필드를 실제로 사용해야 할까요?

00:11:16.380 --> 00:11:18.360
판매 주문을 정기하려고 한다고 가정해봅시다.

00:11:18.520 --> 00:11:21.440
시스템이 최종 항목을 생성하기 전에 추가 확인이 하나 필요합니다.

00:11:21.620 --> 00:11:25.040
할인이 적용되기 전에 고객에게 승인된 보상 등급이 필요할 수도 있습니다.

00:11:25.240 --> 00:11:29.140
또는 주문이 진행되기 전에 필수 배송 문서가 존재해야 할 수도 있습니다.

00:11:29.400 --> 00:11:35.480
적절한 시점에 확인이 필요하지만, 규칙 하나를 추가하기 위해 전체 판매 정기 프로세스를 자신의 확장 프로그램에 복사하고 싶지는 않을 것입니다.

00:11:35.660 --> 00:11:38.180
그 프로세스는 이미 백그라운드에서 많은 것을 처리합니다.

00:11:38.380 --> 00:11:41.760
복사하게 되면 향후 모든 변경 사항을 유지 관리해야 하는 부담이 생깁니다.

00:11:41.960 --> 00:11:42.880
이상적이지 않습니다.

00:11:42.880 --> 00:11:45.520
그래서 AL은 개발자에게 코드를 실행하는 몇 가지 방법을 제공합니다.

00:11:45.640 --> 00:11:47.960
어떤 것을 선택할지는 무엇을 실행해야 하는지에 따라 다릅니다.

00:11:48.140 --> 00:11:49.420
첫 번째로, 트리거입니다.

00:11:49.640 --> 00:11:52.760
트리거는 AL 개체 내부에서 코드가 실행될 수 있는 명명된 지점입니다.

00:11:52.980 --> 00:11:56.000
누군가 테이블 필드의 값을 변경하면 트리거가 코드를 실행합니다.

00:11:56.180 --> 00:11:58.660
페이지가 열리거나 닫힐 때 트리거가 코드를 실행합니다.

00:11:58.840 --> 00:12:03.860
보고서, 커리, XML 포트, 테이블, 확장 프로그램, AO 등 모두 개발자가 규칙을 추가할 수 있는 이러한 지점을 가지고 있습니다.

00:12:04.060 --> 00:12:05.740
고객의 보상 아이디 필드를 예로 들어보겠습니다.

00:12:05.740 --> 00:12:08.940
사용자가 보상 등급을 선택하면 유효성 검사 트리거가 실행될 수 있습니다.

00:12:09.100 --> 00:12:10.860
코드는 고객이 차단되었는지 확인합니다.

00:12:11.000 --> 00:12:12.640
보상 등급이 존재하는지 확인합니다.

00:12:12.840 --> 00:12:14.640
다른 필드를 업데이트해야 하는지도 확인합니다.

00:12:14.840 --> 00:12:18.320
확인은 나중에 실수를 발견했을 때가 아니라 값이 변경되는 바로 그 시점에 이루어집니다.

00:12:18.460 --> 00:12:21.300
트리거는 규칙이 해당 개체와 밀접하게 관련되어 있을 때 효과적입니다.

00:12:21.500 --> 00:12:23.520
하지만 비즈니스 센트럴은 이벤트도 사용합니다.

00:12:23.740 --> 00:12:24.860
이벤트는 공지와 같습니다.

00:12:25.260 --> 00:12:28.260
애플리케이션의 한 부분이 무언가 발생했을 때 이를 보냅니다.

00:12:28.260 --> 00:12:34.000
레코드가 삽입되기 직전이거나 문서가 정기되기 직전이거나 프로세스가 완료되었다는 알림일 수 있습니다.

00:12:34.200 --> 00:12:36.460
확장 프로그램은 해당 공지를 수신할 수 있습니다.

00:12:36.700 --> 00:12:38.800
수신하는 코드를 이벤트 구독자라고 합니다.

00:12:39.040 --> 00:12:40.540
특정 이름의 이벤트를 기다립니다.

00:12:40.840 --> 00:12:44.320
비즈니스 센트럴 이 해당 이벤트를 발생시키면 구독자는 자신의 프로 시절을 실행합니다.

00:12:44.480 --> 00:12:46.420
표준 프로세스는 계속 제어권을 유지합니다.

00:12:46.620 --> 00:12:50.800
예를 들어 비즈니스 센트럴 이 판매 주문 정기 프로세스를 시작할 때 계속하기 전에 이벤트를 발생시킵니다.

00:12:50.960 --> 00:12:53.080
귀하의 리워드 확장 기능이 해당 알림을 수신합니다.

00:12:53.080 --> 00:12:55.540
고객의 리워드 아이디와 할인 규칙을 확인합니다.

00:12:55.720 --> 00:12:59.440
그런 다음 프로세스를 계속 진행하거나 명확한 메시지와 함께 중단시킵니다.

00:12:59.580 --> 00:13:02.740
표준 정기 프로세스는 여전히 비즈니스 센트럴 위 영역입니다.

00:13:02.940 --> 00:13:06.520
귀하의 확장 기능은 해당 연결 지점에 회사별 규칙을 추가할 뿐입니다.

00:13:06.720 --> 00:13:09.720
온 비포, 나온 애프터 같은 이벤트 이름을 자주 듣게 될 것입니다.

00:13:09.940 --> 00:13:12.780
온 비포는 작업이 완료되기 전에 코드가 실행됨을 의미합니다.

00:13:12.980 --> 00:13:15.280
다음 단계를 방지할 수 있는 검사에 매우 적합합니다.

00:13:15.520 --> 00:13:18.400
아, 조건이 충족되지 않을 때 판매 주문을 중단하는 것과 같죠.

00:13:18.560 --> 00:13:20.600
애프터는 작업이 이미 발생했음을 의미합니다.

00:13:20.600 --> 00:13:25.000
이제 대응할 수 있습니다. 관련 레코드를 생성하거나 메모를 업데이트하거나 다른 작업을 시작할 수 있습니다.

00:13:25.200 --> 00:13:27.440
이름을 통해 타이밍을 알 수 있으며 타이밍은 중요합니다.

00:13:27.640 --> 00:13:29.780
정기 후에 실행되는 규칙은 정기를 막을 수 없습니다.

00:13:30.080 --> 00:13:32.840
너무 일찍 실행되는 규칙은 필요한 데이터를 가지고 있지 않을 수 있습니다.

00:13:33.060 --> 00:13:36.300
따라서 개발자는 비즈니스 규칙이 무엇을 언제 해야 하는지에 따라 이벤트를 선택합니다.

00:13:36.480 --> 00:13:38.220
코드는 작업에서 시작될 수도 있습니다.

00:13:38.480 --> 00:13:42.420
사용자가 리워드 상태 확인 버튼을 클릭하면 해당 작업이 프로시저를 호출합니다.

00:13:42.660 --> 00:13:45.760
코드는 한 개체가 변수를 통해 다른 개체를 호출할 때 실행될 수도 있습니다.

00:13:46.020 --> 00:13:47.840
기술적으로 들리지만 간단한 원리입니다.

00:13:47.840 --> 00:13:50.780
확장 기능의 한 부분이 다른 부분의 작업을 수행하도록 요청하는 것입니다.

00:13:50.940 --> 00:13:52.300
변수가 그 과정을 돕습니다.

00:13:52.540 --> 00:13:55.660
변수는 코드가 실행되는 동안 값을 담고 있는 명명된 공간입니다.

00:13:55.880 --> 00:14:00.000
숫자, 텍스트, 날짜 또는 현재 고객과 같은 비즈니스 센트럴 레코드일 수도 있습니다.

00:14:00.240 --> 00:14:02.220
AL에서는 바을 사용하여 선언합니다.

00:14:02.460 --> 00:14:07.280
예를 들어 리워드 프로시 저는 커스터머라는 변수를 사용하여 현재 고객 레코드를 담을 수 있습니다.

00:14:07.500 --> 00:14:10.260
디스카운트 퍼센트라는 다른 변수는 할인율을 담습니다.

00:14:10.460 --> 00:14:12.000
이는 영구적인 레코드가 아닙니다.

00:14:12.180 --> 00:14:14.160
단지 해당 코드 조각을 위한 작업값일 뿐입니다.

00:14:14.160 --> 00:14:16.280
코드가 어디에 위치하는지에 대해 이야기해보겠습니다.

00:14:16.580 --> 00:14:19.560
규칙이 여러 곳에서 사용될 수 있다면 코드 유닛에 넣으십시오.

00:14:19.660 --> 00:14:26.320
그러면 고객 카드, 판매 프로세스, 보고서가 각각의 버전을 갖는 대신 동일한 할인 프로 시절을 호출할 수 있습니다.

00:14:26.580 --> 00:14:28.160
이는 흔한 문제를 방지합니다.

00:14:28.380 --> 00:14:33.860
한 화면은 10% 할인을 적용하고 다른 화면은 5%를 적용하여 어떤 규칙을 신뢰해야 할지 모르는 상황 말입니다.

00:14:34.060 --> 00:14:38.740
공유 비즈니스 규칙을 하나의 코드 유닛에 보관하면 확장 기능의 해당 결정에 대한 단일 소스가 생깁니다.

00:14:38.920 --> 00:14:41.340
즉, 트리거는 개체와 밀접한 규칙을 처리합니다.

00:14:41.340 --> 00:14:44.880
이벤트를 통해 확장 기능은 비즈니스 센트럴 자체 프로세스에 반응할 수 있습니다.

00:14:45.060 --> 00:14:47.180
코드 유닛은 공유 로직을 하나로 묶어줍니다.

00:14:47.380 --> 00:14:52.900
이러한 조각들이 연결되면 다음 질문은 개발자가의 모든 AL 코드를 어디서 작성, 테스트, 검사하는가입니다.

00:14:53.100 --> 00:14:57.540
AL 개발은 일반적으로 데코드라고 불리는 비주얼 스튜디오 코드에서 이루어집니다.

00:14:57.720 --> 00:14:59.920
AL 파일을 작성하기 위한 작업 공간입니다.

00:15:00.140 --> 00:15:01.960
확장 기능을 체계적으로 관리해줍니다.

00:15:02.200 --> 00:15:06.140
문제를 찾아내고 완성된 앱을 테스트를 위해 비즈니스 센트럴 환경으로 전송합니다.

00:15:06.380 --> 00:15:09.100
하지만 데코드 자체는 일반적인 코드 편집기일 뿐입니다.

00:15:09.100 --> 00:15:11.660
마이크로소프트 위 AL 언어 확장이 필요합니다.

00:15:11.820 --> 00:15:14.680
이 확장은 데코드의 비즈니스 센트럴 위 작동 방식을 알려줍니다.

00:15:14.840 --> 00:15:16.820
입력하는 동안 개체 이름을 제한할 수 있습니다.

00:15:17.060 --> 00:15:18.700
게시하기 전에 오류를 지적해줍니다.

00:15:18.900 --> 00:15:20.880
필드와 프로시저를 탐색하는 데 도움을 줍니다.

00:15:21.080 --> 00:15:23.340
그리고 프로젝트를 비즈니스 센트럴 환경에 연결합니다.

00:15:23.540 --> 00:15:25.260
덕분에 추측할 필요가 많이 줄어듭니다.

00:15:25.480 --> 00:15:29.180
새로운 AL 프로젝트를 시작할 때 데코드에서 알고 명령을 실행할 수 있습니다.

00:15:29.440 --> 00:15:32.900
이 명령은 기본 프로젝트 폴더와 확장 기능 이름, 게시자, 버전,

00:15:32.900 --> 00:15:35.800
사용할 비즈니스 센트럴 환경을 설정하는 파일을 생성합니다.

00:15:35.960 --> 00:15:38.480
그 프로젝트 폴더를 확장 기능의 작업대라고 생각하세요.

00:15:38.720 --> 00:15:40.300
모든 AL 파일이 그곳에 속합니다.

00:15:40.500 --> 00:15:42.780
한 파일에는 테이블을, 다른 파일에는 페이지 확장을 담을 수 있고,

00:15:43.120 --> 00:15:44.440
코드 유닛은 별도의 파일을 가질 수 있습니다.

00:15:44.620 --> 00:15:47.720
이렇게 하면 프로젝트를 열었을 때 방대한 문서를 일일이 스크롤할 필요 없이

00:15:47.720 --> 00:15:49.200
필요한 부분을 바로 찾을 수 있습니다.

00:15:49.420 --> 00:15:52.720
코드가 테스트할 준비가 되면 데코드는 이를 앱 패키지로 컴파일합니다.

00:15:52.960 --> 00:15:55.240
그것이 바로 확장 기능에 설치 가능한 버전입니다.

00:15:55.240 --> 00:15:58.840
비즈니스 센트럴은 해당 패키지를 읽어 환경의 확장 기능을 추가합니다.

00:15:59.000 --> 00:16:02.200
누락된 필드, 오타 또는 앱 빌드를 방해하는 문제가 있으면

00:16:02.200 --> 00:16:05.660
패키지가 비즈니스 센트럴에 도달하기 전에 데코드가 알려줍니다.

00:16:05.880 --> 00:16:08.080
테스트는 먼저 샌드박스에서 수행해야 합니다.

00:16:08.280 --> 00:16:10.100
샌드박스는 실제 업무에 영향을 주지 않고

00:16:10.100 --> 00:16:13.000
변경 사항을 시도해볼 수 있는 별도의 비즈니스 센트럴 환경입니다.

00:16:13.180 --> 00:16:15.680
확장 기능을 개시하고 페이지를 열어 변경 사항을 확인하고

00:16:15.680 --> 00:16:18.740
테스트 레코드를 입력하여 규칙이 예상대로 작동하는지 확인합니다.

00:16:18.940 --> 00:16:20.200
그러한 분리는 중요합니다.

00:16:20.200 --> 00:16:22.800
직원들이 업무를 보는 중에 새로운 유효성 검사 규칙이

00:16:22.800 --> 00:16:24.940
판매 주문을 차단하는 상황을 원치 않을 테니까요.

00:16:25.060 --> 00:16:26.540
샌드박스에서는 실수해도 괜찮고

00:16:26.540 --> 00:16:28.620
테스트 데이터를 삭제하거나 코드를 수정하고

00:16:28.620 --> 00:16:30.740
다시 개시해도 실제 레코드에는 영향을 주지 않습니다.

00:16:30.880 --> 00:16:33.720
때로는 코드가 실행되는데 결과가 여전히 잘못되어 보일 때가 있습니다.

00:16:34.000 --> 00:16:35.420
그럴 때 디버깅이 도움이 됩니다.

00:16:35.680 --> 00:16:38.160
코드의 중단점을 설정하고 프로세스를 시작하면

00:16:38.160 --> 00:16:40.260
실행 중에 확장 기능이 일시 중지됩니다.

00:16:40.480 --> 00:16:44.060
일시 중지된 상태에서 현재 고객, 선택된 보상 등급,

00:16:44.140 --> 00:16:47.140
프로시저가 계산한 할인율과 같은 값을 검사할 수 있습니다.

00:16:47.140 --> 00:16:51.440
규칙이 실패한 이유를 추측하는 대신 코드가 정확히 무엇을 수신했는지 확인할 수 있습니다.

00:16:51.640 --> 00:16:54.480
개발팀은 기트를 사용하여 작업 기록을 유지하기도 합니다.

00:16:54.640 --> 00:16:57.620
기트은 시간이 지남에 따라 프로젝트 파일의 변경 사항을 기록합니다.

00:16:57.820 --> 00:16:59.780
누군가 규칙을 변경해 문제가 발생하면

00:16:59.780 --> 00:17:03.340
팀은 버전을 비교하고 변경 사항을 확인하여 필요시 되돌릴 수 있습니다.

00:17:03.540 --> 00:17:06.860
이는 여러 개발자가 동일한 확장을 함께 작업할 때도 도움이 됩니다.

00:17:07.100 --> 00:17:09.920
초보자에게는 작게 시작하는 것이 가장 좋은 방법입니다.

00:17:10.160 --> 00:17:12.060
먼저 비즈니스 센트럴 사용법을 익힌 다음

00:17:12.060 --> 00:17:14.140
테이블 하나와 페이지 하나를 만들어보세요.

00:17:14.140 --> 00:17:17.300
그 다음 표준 페이지를 확장하고 간단한 비즈니스 규칙을 추가하여

00:17:17.300 --> 00:17:20.400
이벤트와 설치 데이터가 프로젝트에 어떻게 적용되는지 배워보세요.

00:17:20.640 --> 00:17:23.800
이제 실제 비즈니스에서 사용할 수 있는 작은 애드온을 통해

00:17:23.800 --> 00:17:25.520
이러한 요소들을 연결해 보겠습니다.

00:17:26.560 --> 00:17:29.480
고객 보상 애드온을 구축하는 간단한 예시입니다.

00:17:29.820 --> 00:17:32.040
실제 AL 확장은 어떤 모습일까요?

00:17:32.260 --> 00:17:34.460
간단한 예시를 통해 자세히 알아보겠습니다.

00:17:34.760 --> 00:17:38.540
회사가 각기 다른 할인율이 적용되는 고객 보상 등급을 원한다고 가정해봅시다.

00:17:38.700 --> 00:17:40.940
먼저 보상 테이블을 생성하는 것으로 시작합니다.

00:17:40.940 --> 00:17:45.540
각 파일의 아이디, 설명, 할인율이 담긴 디지털 서류함이라고 생각하면 됩니다.

00:17:45.800 --> 00:17:48.200
예를 들어 골드 등급은 10% 할인을 받는 시기죠.

00:17:48.360 --> 00:17:51.300
직원들은 기술적인 도구를 다루지 않고도 해당 등급을 관리할 수 있어야 합니다.

00:17:51.460 --> 00:17:54.160
그래서 보상 목록을 볼 수 있는 보상 목록 페이지와 등급을 생성하거나

00:17:54.160 --> 00:17:56.520
수정할 수 있는 보상 카드 페이지라는 두 개의 페이지를 추가합니다.

00:17:56.720 --> 00:17:59.320
직원들은 개발 환경을 열지 않고도 새로운 등급을 추가하거나

00:17:59.320 --> 00:18:01.860
비율을 조정하거나 현재 상태를 검토할 수 있습니다.

00:18:02.100 --> 00:18:05.480
다음으로 고객 테이블을 확장하여 보상 아이디라는 세 필드를 추가합니다.

00:18:05.480 --> 00:18:08.240
이 필드는 각 고객을 하나의 보상 레코드와 연결하며

00:18:08.240 --> 00:18:12.120
직원들이 이미 고객 정보를 관리하는 고객 카드 페이지에 바로 배치합니다.

00:18:12.280 --> 00:18:16.520
그런 다음 보상 작업을 추가하여 동일한 카드에서 보상 목록을 직접 열 수 있게 합니다.

00:18:16.740 --> 00:18:19.240
할인 규칙 자체는 코드 유닛 내부에 존재합니다.

00:18:19.460 --> 00:18:21.520
다른 프로세스에서 고객의 할인이 필요할 때

00:18:21.520 --> 00:18:25.320
모든 페이지에서 반복적으로 계산하는 대신 해당 코드 유닛을 호출합니다.

00:18:25.540 --> 00:18:26.480
매우 효율적이죠.

00:18:26.740 --> 00:18:30.380
설치 코드 유닛은 확장이 처음 설치될 때 기본 보상 등급을 추가합니다.

00:18:30.380 --> 00:18:34.280
또한 이벤트 구독자가 판매 과정 중 선택된 보상 등급을 확인하여

00:18:34.280 --> 00:18:36.500
정확한 시점에 회사 규칙을 적용합니다.

00:18:36.660 --> 00:18:39.520
작은 확장이지만 무엇이 포함되어 있는지 살펴보세요.

00:18:39.740 --> 00:18:44.240
데이터 테이블, 사용자 화면, 탐색 작업, 설정 로직, 비즈니스 규칙이 모두 함께 작동합니다.

00:18:44.400 --> 00:18:46.080
그것이 바로 AL의 진정한 힘입니다.

00:18:46.240 --> 00:18:47.080
자, 좋습니다.

00:18:47.280 --> 00:18:49.380
결론적으로 여러분의 AL 개발 시작점입니다.

00:18:49.580 --> 00:18:50.760
핵심 내용은 다음과 같습니다.

00:18:51.080 --> 00:18:53.700
AL 개발을 통해 핵심 애플리케이션을 건드리지 않고도

00:18:53.700 --> 00:18:56.540
회사에 필요한 특정 기능을 비즈니스 센트럴에 추가할 수 있습니다.

00:18:56.820 --> 00:18:58.720
처음부터 모든 것을 구축할 필요는 없습니다.

00:18:58.720 --> 00:19:02.220
필드 하나, 페이지 확장 하나, 그리고 명확한 규칙 하나로 시작하세요.

00:19:02.380 --> 00:19:04.240
그것이 여러분의 첫 번째 빌딩 블록입니다.

00:19:04.460 --> 00:19:07.620
이번 지식 정보가 유익하셨다면 즐겨 찾는 팟캐스트 플랫폼에서 구독하시고

00:19:07.620 --> 00:19:10.560
이제 막 비즈니스 센트럴 개발을 시작하는 분들께 공유해주세요.

00:19:10.700 --> 00:19:13.700
다음 시간에는 또 다른 퍼즐 조각을 맞춰볼 예정이니 함께 해주시기 바랍니다.

00:19:13.940 --> 00:19:15.260
저는 메르코 피터스였으며

00:19:15.260 --> 00:19:19.480
지금까지 M365 FM에서 제공하는 마이크로소프트 지식 정보 시간이었습니다.