마이크로소프트 날리지 너겟지위 또 다른 에피소드에 오신 것을 환영합니다.진행을 맡은 미로 피터스입니다.자, 이런 상황을 가정해보겠습니다.비즈니스 센트럴에서 작업하다가 작은 변경이 하나 필요해졌습니다.고객 레코드에 필드를 추가하거나 다른 승인 단계를 설정하거나주문 개시 전에 확인하는 규칙이 필요한 경우죠.그런데 누군가 AL 확장 기능, 테이블, 페이지, 코드 유닛을 언급하면갑자기 그 작은 요청이 완전히 새로운 언어처럼 들리게 됩니다.분명 언어는 맞지만 그렇다고 미스터리하게 느낄 필요는 없습니다.비즈니스 센트럴을 사무용 건물이라고 생각해보세요. AL은 개발자에게 건물 자체를 허물지 않고도 방이나 양식,새로운 규칙을 추가할 수 있는 지침을 제공합니다.오늘의 지식 한 조각, 날리지 너겟은 바로 이것입니다.이 에피소드가 끝날 때 쯤이면 AL 개발이 무엇인지,왜 확장 기능이 존재하는지,그리고 커스텀 작업이 비즈니스 센트럴에 어떻게 적용되는지 알게 될 것입니다.기업들이 왜 비즈니스 센트럴을 커스터마이징하는지 알아보겠습니다.비즈니스 센트럴은 이미 재무, 고객, 판매 주문, 재고 송장 등매일의 업무를 스프레드시트나 개별도구 더미가 아닌하나의 연결된 시스템에서 처리합니다.많은 기업에게 기본 설정만으로도 업무의 대부분은 해결됩니다.하지만 문제는 여기서 시작됩니다.똑같이 일하는 기업은 하나도 없습니다.다른 회사에서는 전혀 쓰지 않는 배치, 배치,세부 정보가 필요한 식품 유통업체를 예로 들어보죠.송장 발행 전 특별한 승인 절차가 필요한 서비스 업종도 있습니다.할인을 위해 보상 등급을 원하는 소매업체도 있죠.또는 자신들만의 용어필드와 내부 규칙이 담긴 양식이 필요한 곳도 있습니다.기업은 필드 하나가 없다고 해서 운영 방식을 바꾸지는 않을 것입니다.그렇다고 모든 작은 요청이 전체 시스템을 위험하게 바꾸는 상황으로 이어지는 것도 원치 않으실 겁니다.

과거에는 그것이 더 큰 문제였습니다.이전 시스템에서는 개발자가 원본 코드를 열어 직접 편집했습니다.다음 업데이트가 오기 전까지는 잘 작동했죠.그러고 나면 기업은 한쪽에는 마이크로소프트 위의 새 버전이,다른 한쪽에는 자체 변경 사항이 남게 되어 업데이트를 진행하기 전에 누군가의 모든 것을 조정해야 했습니다.세입자마다 계획 없이 벽을 뚫고 새 케이블을 설치하는 사무실을 상상해보세요.한동안은 작동하겠지만 건물을 수리해야 할 때가 오면아무도 그 케이블이 누구 것인지 알 수 없게 됩니다.비즈니스 센트럴은 다른 방식을 택합니다.개발자는 표준 애플리케이션을 다시 작성하는 대신표준 구성 요소는 그대로 유지하면서회사만의 변경 사항은 별도의 추가 기능으로 구축하여시스템의 지원 지점을 통해 연결되도록 합니다.이러한 분리는 업데이트 시 중요합니다.마이크로소프트는 건물의 자기 부분을 업데이트하고커스텀 작업은 자신의 공간에 그대로 유지되기 때문입니다.물론 소프트웨어 변경인 만큼 여전히 테스트와 수정은 필요하지만개발자가 마이크로소프트 위 원본 코드 내부에서모든 변경 사항을 복사하고 다시 작업할 필요는 없습니다.그렇다면 기업은 실제로 무엇을 커스터마이징 할까요?커스터마이징은 데이터를 추가합니다.표준 시스템은 배송 지침, 내부 위험 점수, 멤버십 등급,외부 시스템 링크와 같은 정보를 저장하지 않으니까요.또한 직원이 올바른 순서로 업무를 수행하도록 안내하는 화면을 추가합니다.필수 문서가 누락되었을 때 주문을 중단하는 것과 같은 규칙을 적용하기도 합니다.사용자 지정 작업은 사람들이 수동 단계를 피하도록 돕기도 합니다.매주 금요일마다 직원이 비즈니스 센트럴에서 다른 도구로 고객 데이터를 복사하고 조건을 직접 확인한 다음 관리자에게 보고서를 보내는 상황을 상상해보세요.잘 설계된 변경 작업은 해당 정보를 비즈니스 센트럴 내에 유지하고 규칙을 일관되게 적용하며 직원에게 일상 업무에 맞는 버튼이나 페이지를 제공합니다.

잘못된 통념을 바로 잡아보겠습니다.모든 것을 커스터마이징해서는 안됩니다.표준 비즈니스 센트럴에는 이미 많은 프로세스가 내장되어 있습니다.단지 이전 시스템과 달라 보인다는 이유만으로 무언가를 변경하면 나중에 추가적인 작업이 발생합니다.따라서 좋은 사용자 지정 작업은 명확한 비즈니스 이유에서 시작됩니다.사람들이 어떤 문제를 겪고 있나요? 대신 어떤 일이 일어나야 하나요?표준 제품으로 이미 처리할 수 있는 일은 아닐까요?표준 제품이 그 요구사항을 충족하지 못할 때 AL이 등장합니다. AL은 비즈니스 센트럴 자체에 집중하여 데이터베이스 수준에서 레코드를 읽고 추가하고 변경하는 동시에 페이지, 보고서 및 기타 애플리케이션 영역에서 일어나는 일을 제어합니다.또한 값을 계산하고 데이터를 이동하며 프로세스 전반에서 규칙이 위반될 경우 메시지를 표시합니다.하나의 언어로 하기에는 많은 작업이지만, AL은 모든 유형의 소프트웨어를 위한 범용 도구가 아니면 공개 쇼핑 웹사이트, 모바일 게임 또는 독립형 데스크톱 앱을 만드는 데 선택하지는 않습니다. AL은 오직 한 가지 목적, 즉 비즈니스 센트럴 내부의 데이터와 동작을 형성하여 시스템이 기업의 운영 방식과 일치하도록 만드는 데 존재합니다.다음으로 바로 이 점을 살펴보겠습니다. AL과 확장 기능, 안전한 애드온 모델입니다. AL은 애플리케이션 언어, 애플리케이션 랭귀지, 위 약자입니다.이는 마이크로소프트 위 비즈니스 센트럴 용 프로그래밍 언어이며, 개발자에게 새로운 비즈니스 기능을 만들거나 기존 시스템의 동작 방식을 변경할 수 있는 구조화된 방법을 제공합니다.하지만 확장 기능, 익스텐션이라는 단어는 AL만큼이나 중요합니다.확장 기능은 비즈니스 센트럴에 설치할 수 있는 별도의 앱입니다.이는 표준 비즈니스 센트럴 애플리케이션을 건드리지 않고 기업의 사용자 지정 작업을 보관합니다.

핸드북을 새로 쓰는 것보다는 승인된 페이지를 추가하는 것이라고 생각하세요.그렇죠. 원본 규칙을 지우지 않고 따르는 페이지들 말입니다.기술적인 세부사항처럼 들릴 수 있지만, 시간이 지남에 따라 사용자 지정 작업이 유지되는 방식을 바꿉니다.회사가 특별한 팀을 위한 새로운 사무실 공간이 필요하다고 상상해보세요.예전 방식은 본 건물의 벽을 허물고 구조 자체를 바꾸는 것을 의미했습니다.당장은 문제를 해결할 수 있어도 원래 건물이 설계도와 달라지기 때문에 나중에 수리하는 것은 악몽이 될 수 있습니다.확장 기능, 익스텐션은 다르게 작동합니다.건물에는 이미 문과 콘센트 그리고 공간을 추가하기 위한 규칙이 마련되어 있습니다.승인된 연결 지점을 통해 새로운 방을 짓는 것입니다.방은 회사 소유이지만, 메인 건물은 모든 맞춤형 벽을 허물지 않고도 계속 유지 보수할 수 있습니다.그것이 바로 비즈니스 센트럴 확장 기능이 작동하는 방식입니다.기본 애플리케이션에는 마이크로소프트가 제공하는 표준 작업이 포함되어 있습니다.확장 기능을 사용하면 고유한 필드, 화면, 버튼, 규칙, 보고서, 심지어 다른 시스템과의 연결까지 추가할 수 있습니다.특정 비즈니스 작업이 발생할 때 반응할 수 있지만, 이는 표준 애플리케이션에 연결하는 지원되는 방식을 통해서만 이루어집니다.그래서 경계가 내장되어 있습니다.이는 좋은 일입니다.경계가 없으면 작은 사용자 지정 요청이 건드리지 말아야 할 깊은 영역까지 침범할 수 있습니다.확장 기능을 사용하면 개발자는 명확한 개최 유형과 정의된 연결 지점을 사용하여 작업함으로, 나중에 다른 사람이 코드를 읽을 때 이해하기가 더 쉽습니다.이 접근 방식은 클라우드 버전의 비즈니스 센트럴 애도 완벽하게 부합합니다.마이크로소프트는 서비스를 정기적으로 업데이트합니다.회사는 변경 사항 발생 후, 특히 변경된 제품 부품에 의존하는 경우 확장 기능을 테스트해야 합니다.

소프트웨어가 유지 관리의 필요성을 완전히 없애주지는 않습니다.하지만 사용자 지정 코드를 별도로 유지하면 모든 업데이트가 기존 수정 사항을 대대적으로 재구축해야 하는 상황이 될 가능성이 줄어듭니다.이전 다이나믹스 NAV 시스템에 대해 이야기할 때 사람들이 C, AL을 언급하는 것을 들을 수 있습니다. C, AL은 개발자가 종종 원래 애플리케이션 개최를 직접 변경하던 초기 개발 모델에서 나왔습니다.많은 기업이 수년간 그런 방식으로 성공적으로 시스템을 운영했지만,이는 사용자 지정 작업을 표준 코드와 훨씬 더 밀접하게 결합시켰고, 업데이트 시 많은 비교 및 복구 작업이 필요했습니다. AL은 비즈니스 센트럴 룰랩 기반 개발로 전환했습니다.그렇다고 모든 확장 기능이 크거나 복잡하다는 의미는 아닙니다.어떤 확장 기능은 고객 레코드에 필드를 추가하고 익숙한 화면에 표시하는 정도일 수 있습니다.다른 확장 기능은 특정 비즈니스 유형을 위한 전체 솔루션으로서 고유한 레코드, 프로세스, 페이지 및 보고서를 포함할 수 있습니다.둘 다 동일한 기본 아이디어를 따릅니다.사용자 지정 앱은 비즈니스 센트럴을 제작성하여 숨기는 대신 그 옆에서 공존합니다.둘 이상의 확장 기능을 설치할 수도 있습니다.한 회사가 급여 관리를 위해 소프트웨어 파트너의 확장 기능을 사용하고, 배송을 위해 다른 확장 기능을 사용하며, 회사에만 중요한 규칙을 위해 작은 내부 확장 기능을 사용할 수 있습니다.비즈니스 센트럴은 이러한 확장 기능들이 플랫폼 규칙을 따르고 충돌하지 않는 한 하나의 작동 시스템으로 통합합니다.따라서 AL은 단순한 코드 작성 방식이 아닙니다.개발자가 이러한 추가 앱을 만드는데 사용하는 언어이며, 확장 기능은 이러한 변경 사항을 비즈니스 센트럴로 전달하는 컨테이너입니다.이 모델을 사용하면 기업은 표준 제품의 형태를 유지하여 관리 편의성을 높이면서도 시스템을 맞춤화할 수 있습니다.

이제 이러한 확장 기능 중 하나를 열어 그 안에 구성 요소를 살펴보겠습니다. AL 확장 프로그램 내의 주요 AL 구성 요소들입니다.개발자 들은 개체, 오브젝트를 다룹니다.개체는 정보 저장, 화면 표시, 규칙 실행, 문서 생성과 같은 명확한 작업을 수행하는 앱의 이름이 지정된 조각입니다.이러한 작업들을 개별적으로 파악하게 되면 AL은 코드의 거대한 장벽처럼 느껴지지 않게 됩니다.비즈니스 정보가 저장되는 곳부터 시작해보겠습니다.비즈니스 센트럴에서 테이블은 데이터를 저장합니다.테이블을 특정 유형의 레코드를 위한 디지털 캐비닛이라고 생각하세요.한 캐비닛에는 고객, 다른 캐비닛에는 품목, 또 다른 캐비닛에는 판매 주문이 들어갈 수 있습니다.각 레코드는 그 캐비닛 안의 파일 하나와 같습니다.고객 테이블은 각 고객에 대한 레코드를 하나씩 포함합니다.품목 테이블은 각 제품에 대한 레코드를 하나씩 포함합니다.회사의 표준 비즈니스 센트럴에서 저장하지 않는 정보가 필요한 경우 확장 기능을 통해 보상 등급, 장비 점검, 프로젝트 승인 등을 위한 자체 테이블을 만들 수 있습니다.필드는 각 레코드 안에 이름이 지정된 공간입니다.고객 테이블에는 세부 정보를 위한 필드가 포함되어 있으므로 고객 레코드의 이름, 주소, 결제 조건, 전화번호를 포함할 수 있습니다.필드에는 텍스트, 날짜, 금액, 예, 아니오, 답변 또는 고정된 목록에서의 선택사항을 저장할 수 있습니다.필드는 다른 레코드를 가리킬 수도 있습니다.예를 들어, 고객 레코드에는 보상 아이디 필드가 포함될 수 있습니다.직원들은 이미 텍스트를 입력하는 대신 별도의 보상 테이블에서 보상 등급을 선택합니다.이러한 연결은 모두가 동일한 알려진 목록에서 선택하도록 하여 데이터를 깔끔하게 유지합니다.즉, 테이블은 사실 관계를 저장합니다.그렇다면 사람들은 어떻게 이러한 사실을 보고 다룰까요?

페이지입니다.페이지는 비즈니스 센트럴에서 여는 화면입니다.고객 카드는 하나의 페이지입니다.판매 주문 목록도 하나의 페이지입니다.페이지는 사용자가 무엇을 보고, 입력하고, 검색하고, 조치를 취할 수 있는지 제어합니다.작업에 따라 적합한 페이지가 다릅니다.카드 페이지는 한 번에 한 명이 고객이나 하나의 품목과 같은 단일 레코드에 집중합니다.목록 페이지는 많은 레코드를 행으로 보여주며,빠르게 훑어보거나 필터링하거나 무언가를 찾을 때 유용합니다.워크시트 페이지는 사용자가 여러 줄의 정보를 함께 입력하거나 처리하는 작업을 지원합니다.테이블은 정보를 저장합니다.페이지는 정보를 사용자에게 보여줍니다.이러한 분리는 데이터의 저장 위치를 바꾸지 않고도 화면을 변경할 수 있거나,여러 팀이 동일한 레코드에 대해 서로 다른 보기가 필요할 때 동일한 테이블을 여러 페이지에서 재사용할 수 있게 해줌으로 유용합니다.그렇다면 데이터가 이미 표준 비즈니스 센트럴 레코드에 속해 있다면 어떻게 해야 할까요?단지 추가 필드 하나가 필요하다고 해서 고객 테이블을 새로 만들지는 않을 것입니다.이때는 테이블 확장을 사용합니다.테이블 확장을 사용하면 기존 고객 테이블에 필드를 추가할 수 있습니다.표준 고객 레코드는 원래 위치에 그대로 유지되면서,확장을 통해 표준 필드 옆에 회사 고유의 세부 정보를 추가하게 됩니다.예를 들어 보상 아이디, 배송 메모, 계정관리자 또는 비즈니스의 다른 부분과 연결되는 필드 등이 있을 수 있습니다.하지만 테이블에 필드를 추가한다고 해서 자동으로 화면에 나타나는 것은 아닙니다.이를 위해서는 페이지 확장을 사용해야 합니다.페이지 확장은 기존 페이지의 필드, 그룹 또는 작업을 추가합니다.고객을 조회하면서 보상 등급을 선택해야 하는 경우,페이지 확장을 사용하면 직원들이 이미 작업 중인 고객 카드에 보상 아이디 필드를 배치할 수 있습니다.

이렇게 하면 익숙한 사용자 경험을 유지할 수 있습니다.간단한 세부 정보 때문에 사용자를 별도의 사용자 지정 화면으로 이동시키는 대신,이미 알고 있는 페이지에 해당 정보를 추가하는 것입니다.페이지 확장을 사용하여 작업을 시작하는 버튼이나 메뉴 명령 같은 작업 항목을 추가할 수도 있습니다.예를 들어 고객 카드의 보상 목록을 여는 보상 작업을 포함할 수 있습니다.화면 뒤편에는 비즈니스 규칙을 저장할 공간이 필요합니다.그 공간은 보통 코드 유닛, 코드 유닛이 담당합니다.코드 유닛에는 특정 작업을 수행하는 명령된 코드 조각인 AL 프로시저가 포함되어 있습니다.페이지, 보고서 또는 기타 프로세스에서 지원을 요청할 때 작업을 처리하는 백오피스 팀이라고 생각하면 됩니다.보상 등급에 따라 고객에게 적용될 할인이 결정된다고 가정해보겠습니다.할인 계산 로직은 고객 카드 페이지 자체가 아닌 코드 유닛에 두어야 합니다.그러면 영업 프로세스, 보고서 또는 추후 생성될 페이지에서 동일한 규칙을 여러 곳에 복사할 필요 없이 재사용할 수 있습니다.하나의 규칙을 하나의 장소에서 관리하는 것입니다.비즈니스 센트럴에는 다양한 작업을 위한 다른 개체 유형도 포함되어 있습니다.보고서는 데이터를 수집하여 송장이나 판매 보고서와 같은 문서 또는 레이아웃으로 표시합니다.커리는 특정 기간 동안 특정 품목을 주문한 고객이 누구인지와 같이 데이터에 대한 집중적 인질문을 던집니다.예를 들어, XML 포트는 다른 시스템이 비즈니스 센트럴과 정보를 교환해야 할 때 데이터를 구조화된 형식으로 가져오거나 내보내는 데 도움을 줍니다.이러한 요소들을 조합하면 소규모 고객 보상 확장을 구현하는 모습을 그려볼 수 있습니다.보상 테이블은 각 등급과 할인율을 저장합니다.보상 페이지를 통해 직원들은 해당 등급을 관리할 수 있습니다.고객 테이블 확장은 각 고객에게 보상 아이디를 추가하고, 고객 카드 페이지 확장은 이를 화면에 표시합니다.

페이지 작업은 보상 목록을 열고, 코드 유닛은 할인 규칙을 계산합니다.각 개체는 작업의 한 부분을 처리합니다.이를 통해 6개월 후 비즈니스 규칙이 변경될 때 확장을 더 쉽게 읽고, 테스트하고, 변경할 수 있습니다.하지만 비즈니스 규칙은 누군가 주문을 정기할 때와 같이 정확한 시점에 실행되어야 하는 경우가 많습니다.이때 트리거와 이벤트가 필요합니다.이벤트, 트리거, 그리고 비즈니스 규칙.자, 고객 보상 필드를 추가했습니다.좋습니다.진짜 질문은 이건입니다.비즈니스 센트럴은 언제 그 필드를 실제로 사용해야 할까요?판매 주문을 정기하려고 한다고 가정해봅시다.시스템이 최종 항목을 생성하기 전에 추가 확인이 하나 필요합니다.할인이 적용되기 전에 고객에게 승인된 보상 등급이 필요할 수도 있습니다.또는 주문이 진행되기 전에 필수 배송 문서가 존재해야 할 수도 있습니다.적절한 시점에 확인이 필요하지만, 규칙 하나를 추가하기 위해 전체 판매 정기 프로세스를 자신의 확장 프로그램에 복사하고 싶지는 않을 것입니다.그 프로세스는 이미 백그라운드에서 많은 것을 처리합니다.복사하게 되면 향후 모든 변경 사항을 유지 관리해야 하는 부담이 생깁니다.이상적이지 않습니다.그래서 AL은 개발자에게 코드를 실행하는 몇 가지 방법을 제공합니다.어떤 것을 선택할지는 무엇을 실행해야 하는지에 따라 다릅니다.첫 번째로, 트리거입니다.트리거는 AL 개체 내부에서 코드가 실행될 수 있는 명명된 지점입니다.누군가 테이블 필드의 값을 변경하면 트리거가 코드를 실행합니다.페이지가 열리거나 닫힐 때 트리거가 코드를 실행합니다.보고서, 커리, XML 포트, 테이블, 확장 프로그램, AO 등 모두 개발자가 규칙을 추가할 수 있는 이러한 지점을 가지고 있습니다.고객의 보상 아이디 필드를 예로 들어보겠습니다.사용자가 보상 등급을 선택하면 유효성 검사 트리거가 실행될 수 있습니다.

코드는 고객이 차단되었는지 확인합니다.보상 등급이 존재하는지 확인합니다.다른 필드를 업데이트해야 하는지도 확인합니다.확인은 나중에 실수를 발견했을 때가 아니라 값이 변경되는 바로 그 시점에 이루어집니다.트리거는 규칙이 해당 개체와 밀접하게 관련되어 있을 때 효과적입니다.하지만 비즈니스 센트럴은 이벤트도 사용합니다.이벤트는 공지와 같습니다.애플리케이션의 한 부분이 무언가 발생했을 때 이를 보냅니다.레코드가 삽입되기 직전이거나 문서가 정기되기 직전이거나 프로세스가 완료되었다는 알림일 수 있습니다.확장 프로그램은 해당 공지를 수신할 수 있습니다.수신하는 코드를 이벤트 구독자라고 합니다.특정 이름의 이벤트를 기다립니다.비즈니스 센트럴 이 해당 이벤트를 발생시키면 구독자는 자신의 프로 시절을 실행합니다.표준 프로세스는 계속 제어권을 유지합니다.예를 들어 비즈니스 센트럴 이 판매 주문 정기 프로세스를 시작할 때 계속하기 전에 이벤트를 발생시킵니다.귀하의 리워드 확장 기능이 해당 알림을 수신합니다.고객의 리워드 아이디와 할인 규칙을 확인합니다.그런 다음 프로세스를 계속 진행하거나 명확한 메시지와 함께 중단시킵니다.표준 정기 프로세스는 여전히 비즈니스 센트럴 위 영역입니다.귀하의 확장 기능은 해당 연결 지점에 회사별 규칙을 추가할 뿐입니다.온 비포, 나온 애프터 같은 이벤트 이름을 자주 듣게 될 것입니다.온 비포는 작업이 완료되기 전에 코드가 실행됨을 의미합니다.다음 단계를 방지할 수 있는 검사에 매우 적합합니다.아, 조건이 충족되지 않을 때 판매 주문을 중단하는 것과 같죠.애프터는 작업이 이미 발생했음을 의미합니다.이제 대응할 수 있습니다. 관련 레코드를 생성하거나 메모를 업데이트하거나 다른 작업을 시작할 수 있습니다.이름을 통해 타이밍을 알 수 있으며 타이밍은 중요합니다.정기 후에 실행되는 규칙은 정기를 막을 수 없습니다.

너무 일찍 실행되는 규칙은 필요한 데이터를 가지고 있지 않을 수 있습니다.따라서 개발자는 비즈니스 규칙이 무엇을 언제 해야 하는지에 따라 이벤트를 선택합니다.코드는 작업에서 시작될 수도 있습니다.사용자가 리워드 상태 확인 버튼을 클릭하면 해당 작업이 프로시저를 호출합니다.코드는 한 개체가 변수를 통해 다른 개체를 호출할 때 실행될 수도 있습니다.기술적으로 들리지만 간단한 원리입니다.확장 기능의 한 부분이 다른 부분의 작업을 수행하도록 요청하는 것입니다.변수가 그 과정을 돕습니다.변수는 코드가 실행되는 동안 값을 담고 있는 명명된 공간입니다.숫자, 텍스트, 날짜 또는 현재 고객과 같은 비즈니스 센트럴 레코드일 수도 있습니다. AL에서는 바을 사용하여 선언합니다.예를 들어 리워드 프로시 저는 커스터머라는 변수를 사용하여 현재 고객 레코드를 담을 수 있습니다.디스카운트 퍼센트라는 다른 변수는 할인율을 담습니다.이는 영구적인 레코드가 아닙니다.단지 해당 코드 조각을 위한 작업값일 뿐입니다.코드가 어디에 위치하는지에 대해 이야기해보겠습니다.규칙이 여러 곳에서 사용될 수 있다면 코드 유닛에 넣으십시오.그러면 고객 카드, 판매 프로세스, 보고서가 각각의 버전을 갖는 대신 동일한 할인 프로 시절을 호출할 수 있습니다.이는 흔한 문제를 방지합니다.한 화면은 10% 할인을 적용하고 다른 화면은 5%를 적용하여 어떤 규칙을 신뢰해야 할지 모르는 상황 말입니다.공유 비즈니스 규칙을 하나의 코드 유닛에 보관하면 확장 기능의 해당 결정에 대한 단일 소스가 생깁니다.즉, 트리거는 개체와 밀접한 규칙을 처리합니다.이벤트를 통해 확장 기능은 비즈니스 센트럴 자체 프로세스에 반응할 수 있습니다.코드 유닛은 공유 로직을 하나로 묶어줍니다.이러한 조각들이 연결되면 다음 질문은 개발자가의 모든 AL 코드를 어디서 작성, 테스트, 검사하는가입니다.

AL 개발은 일반적으로 데코드라고 불리는 비주얼 스튜디오 코드에서 이루어집니다. AL 파일을 작성하기 위한 작업 공간입니다.확장 기능을 체계적으로 관리해줍니다.문제를 찾아내고 완성된 앱을 테스트를 위해 비즈니스 센트럴 환경으로 전송합니다.하지만 데코드 자체는 일반적인 코드 편집기일 뿐입니다.마이크로소프트 위 AL 언어 확장이 필요합니다.이 확장은 데코드의 비즈니스 센트럴 위 작동 방식을 알려줍니다.입력하는 동안 개체 이름을 제한할 수 있습니다.게시하기 전에 오류를 지적해줍니다.필드와 프로시저를 탐색하는 데 도움을 줍니다.그리고 프로젝트를 비즈니스 센트럴 환경에 연결합니다.덕분에 추측할 필요가 많이 줄어듭니다.새로운 AL 프로젝트를 시작할 때 데코드에서 알고 명령을 실행할 수 있습니다.이 명령은 기본 프로젝트 폴더와 확장 기능 이름, 게시자, 버전,사용할 비즈니스 센트럴 환경을 설정하는 파일을 생성합니다.그 프로젝트 폴더를 확장 기능의 작업대라고 생각하세요.모든 AL 파일이 그곳에 속합니다.한 파일에는 테이블을, 다른 파일에는 페이지 확장을 담을 수 있고,코드 유닛은 별도의 파일을 가질 수 있습니다.이렇게 하면 프로젝트를 열었을 때 방대한 문서를 일일이 스크롤할 필요 없이필요한 부분을 바로 찾을 수 있습니다.코드가 테스트할 준비가 되면 데코드는 이를 앱 패키지로 컴파일합니다.그것이 바로 확장 기능에 설치 가능한 버전입니다.비즈니스 센트럴은 해당 패키지를 읽어 환경의 확장 기능을 추가합니다.누락된 필드, 오타 또는 앱 빌드를 방해하는 문제가 있으면패키지가 비즈니스 센트럴에 도달하기 전에 데코드가 알려줍니다.테스트는 먼저 샌드박스에서 수행해야 합니다.샌드박스는 실제 업무에 영향을 주지 않고변경 사항을 시도해볼 수 있는 별도의 비즈니스 센트럴 환경입니다.확장 기능을 개시하고 페이지를 열어 변경 사항을 확인하고테스트 레코드를 입력하여 규칙이 예상대로 작동하는지 확인합니다.

그러한 분리는 중요합니다.직원들이 업무를 보는 중에 새로운 유효성 검사 규칙이판매 주문을 차단하는 상황을 원치 않을 테니까요.샌드박스에서는 실수해도 괜찮고테스트 데이터를 삭제하거나 코드를 수정하고다시 개시해도 실제 레코드에는 영향을 주지 않습니다.때로는 코드가 실행되는데 결과가 여전히 잘못되어 보일 때가 있습니다.그럴 때 디버깅이 도움이 됩니다.코드의 중단점을 설정하고 프로세스를 시작하면실행 중에 확장 기능이 일시 중지됩니다.일시 중지된 상태에서 현재 고객, 선택된 보상 등급,프로시저가 계산한 할인율과 같은 값을 검사할 수 있습니다.규칙이 실패한 이유를 추측하는 대신 코드가 정확히 무엇을 수신했는지 확인할 수 있습니다.개발팀은 기트를 사용하여 작업 기록을 유지하기도 합니다.기트은 시간이 지남에 따라 프로젝트 파일의 변경 사항을 기록합니다.누군가 규칙을 변경해 문제가 발생하면팀은 버전을 비교하고 변경 사항을 확인하여 필요시 되돌릴 수 있습니다.이는 여러 개발자가 동일한 확장을 함께 작업할 때도 도움이 됩니다.초보자에게는 작게 시작하는 것이 가장 좋은 방법입니다.먼저 비즈니스 센트럴 사용법을 익힌 다음테이블 하나와 페이지 하나를 만들어보세요.그 다음 표준 페이지를 확장하고 간단한 비즈니스 규칙을 추가하여이벤트와 설치 데이터가 프로젝트에 어떻게 적용되는지 배워보세요.이제 실제 비즈니스에서 사용할 수 있는 작은 애드온을 통해이러한 요소들을 연결해 보겠습니다.고객 보상 애드온을 구축하는 간단한 예시입니다.실제 AL 확장은 어떤 모습일까요?간단한 예시를 통해 자세히 알아보겠습니다.회사가 각기 다른 할인율이 적용되는 고객 보상 등급을 원한다고 가정해봅시다.먼저 보상 테이블을 생성하는 것으로 시작합니다.각 파일의 아이디, 설명, 할인율이 담긴 디지털 서류함이라고 생각하면 됩니다.예를 들어 골드 등급은 10% 할인을 받는 시기죠.

직원들은 기술적인 도구를 다루지 않고도 해당 등급을 관리할 수 있어야 합니다.그래서 보상 목록을 볼 수 있는 보상 목록 페이지와 등급을 생성하거나수정할 수 있는 보상 카드 페이지라는 두 개의 페이지를 추가합니다.직원들은 개발 환경을 열지 않고도 새로운 등급을 추가하거나비율을 조정하거나 현재 상태를 검토할 수 있습니다.다음으로 고객 테이블을 확장하여 보상 아이디라는 세 필드를 추가합니다.이 필드는 각 고객을 하나의 보상 레코드와 연결하며직원들이 이미 고객 정보를 관리하는 고객 카드 페이지에 바로 배치합니다.그런 다음 보상 작업을 추가하여 동일한 카드에서 보상 목록을 직접 열 수 있게 합니다.할인 규칙 자체는 코드 유닛 내부에 존재합니다.다른 프로세스에서 고객의 할인이 필요할 때모든 페이지에서 반복적으로 계산하는 대신 해당 코드 유닛을 호출합니다.매우 효율적이죠.설치 코드 유닛은 확장이 처음 설치될 때 기본 보상 등급을 추가합니다.또한 이벤트 구독자가 판매 과정 중 선택된 보상 등급을 확인하여정확한 시점에 회사 규칙을 적용합니다.작은 확장이지만 무엇이 포함되어 있는지 살펴보세요.데이터 테이블, 사용자 화면, 탐색 작업, 설정 로직, 비즈니스 규칙이 모두 함께 작동합니다.그것이 바로 AL의 진정한 힘입니다.자, 좋습니다.결론적으로 여러분의 AL 개발 시작점입니다.핵심 내용은 다음과 같습니다. AL 개발을 통해 핵심 애플리케이션을 건드리지 않고도회사에 필요한 특정 기능을 비즈니스 센트럴에 추가할 수 있습니다.처음부터 모든 것을 구축할 필요는 없습니다.필드 하나, 페이지 확장 하나, 그리고 명확한 규칙 하나로 시작하세요.그것이 여러분의 첫 번째 빌딩 블록입니다.이번 지식 정보가 유익하셨다면 즐겨 찾는 팟캐스트 플랫폼에서 구독하시고이제 막 비즈니스 센트럴 개발을 시작하는 분들께 공유해주세요.다음 시간에는 또 다른 퍼즐 조각을 맞춰볼 예정이니 함께 해주시기 바랍니다.

저는 메르코 피터스였으며지금까지 M365 FM에서 제공하는 마이크로소프트 지식 정보 시간이었습니다.