jjongjjong-e 님의 블로그

[Dynamics365] 개발자 초급 코스 - 5. TempDB vs InMemory 임시 테이블 조회 기능 구현

jjongjjong-e — Sun, 5 Jul 2026 23:00:21 +0900

D365 F&O(X++) 환경에서 대량의 데이터를 화면에 유연하게 보여주거나, 복잡한 비즈니스 로직으로 가공된 데이터를 보고서로 출력해야 할 때 가장 먼저 머릿속에 떠오르는 기술이 무엇인가요?

바로 임시 테이블(Temporary Table)일 것입니다.

임시 테이블은 복잡한 데이터 바인딩을 단순화하고, 복잡한 Join 연산을 데이터베이스 외부에서 처리할 수 있게 돕는 강력한 도구입니다.

하지만 D365 F&O에는 크게 TempDB와 InMemory라는 두 가지 강력한 임시 테이블 유형이 존재하며, 각각의 작동 메커니즘과 최적의 사용 시나리오가 다릅니다.

오늘은 이 두 임시 테이블의 핵심 차이점을 비교해 보고, 실무에서 바로 활용할 수 있는 SalesTable 기반의 조회 화면 구현 예제를 소스 코드와 함께 자세히 살펴보겠습니다.

1. TempDB vs InMemory: 핵심 아키텍처 비교

두 기술은 데이터를 임시로 저장한다는 목적은 같지만, "데이터가 물리적으로 어디에 저장되고 어떻게 통신하는가"에서 결정적인 차이가 있습니다.

구분 TempDB 테이블 (TempDB Table) InMemory 테이블 (InMemory Table)

구분	TempDB	InMemory
물리적 저장 위치	SQL Server의 tempdb 시스템 데이터베이스	AOS(Application Object Server) 서버의 메모리
데이터 임계치 초과 시	항상 SQL Server 디스크/메모리에서 처리됨	메모리가 부족할 경우 AOS 서버 디스크 캐시 파일로 페이징
주요 용도	- 대량의 데이터 처리 - 다른 일반 테이블과의 복잡한 Join 연산 - insert_recordset 등 DB단 일괄 처리	- 소량 데이터 가공 - 빈번한 단일 레코드 읽기/쓰기 - 빠른 인메모리 연산이 필요할 때
데이터 바인딩 API	linkPhysicalTableInstance()	setTmpData()
성능적 특징	SQL Server 내에서 쿼리가 직접 수행되므로 복잡한 필터 및 조인 성능 우수	AOS 메모리 내 직접 접근으로 단일 Record 단위 I/O 속도가 극도로 빠름

다음과 같은 이유로 대량데이터에서 InMemory 사용은 지양합니다.

티어(Tier) 간 데이터 이동 오버헤드 (AOS ↔ DB)
- 일반적인 운영 데이터(예: 매출 주문, 고객 정보)는 SQL 데이터베이스 서버에 있습니다.
- AOS 메모리에 있는 InMemory 테이블과 DB에 있는 일반 테이블을 JOIN하려면, SQL 서버가 AOS의 데이터를 알지 못하므로 AOS 메모리의 데이터를 DB로 통째로 전송하거나, AOS가 DB에서 데이터를 건건이 가져와 루프를 돌며 매칭해야 합니다. 이 과정에서 엄청난 네트워크 I/O와 CPU 부하가 발생합니다.
쿼리 옵티마이저의 부재
- InMemory 테이블끼리 JOIN을 하더라도, 이는 SQL 서버가 아닌 X++ 커널의 로컬 쿼리 프로세서가 연산을 담당합니다.
- SQL 서버처럼 대용량 처리에 최적화된 고급 조인 알고리즘(Hash Join, Merge Join)이나 통계 정보를 활용하지 못하고, 대부분 단순한 중첩 루프 조인(Nested Loop Join) 방식으로 처리됩니다. 데이터가 만 건, 십만 건으로 늘어나면 연산 횟수가 기하급수적으로 증가합니다.

2. 실습을 위한 AOT 오브젝트 구성

이번 예제는 HDG_TempDB라는 모델 내에 구현되었습니다. 실습 화면을 구성하기 위해 AOT에 다음과 같은 네 가지 오브젝트를 생성했습니다.

TempDB 테이블 (HDG_SalesInquiryTmpDB)
- 핵심 설정: 테이블 속성 중 TableType을 TempDB로 지정합니다. 이 설정으로 인해 이 테이블은 SQL Server의 tempdb 영역에 생명 주기를 갖게 됩니다.
InMemory 테이블 (HDG_SalesInquiryInMemory)
- 핵심 설정: 테이블 속성 중 TableType을 InMemory로 지정합니다. 이 테이블은 AOS 서버 메모리 영역을 활용하게 됩니다.
조회 화면 Form (HDG_SalesInquiry)
- 하나의 화면 내에 두 종류의 임시 테이블 동작 방식을 직관적으로 비교할 수 있도록 두 개의 탭(Tab)을 생성하고, 각각의 그리드(Grid)에 데이터소스를 바인딩합니다.
Display 메뉴 아이템 (HDG_SalesInquiry)
- 사용자가 메뉴나 대시보드에서 이 조회 화면을 호출할 수 있도록 연결하는 엔트리 포인트입니다.

실제 구현 GITHUB : HDG-Dynamics365-FnO-Samples/HDG_TempDB at main · ans1148/HDG-Dynamics365-FnO-Samples

3. 핵심 구현 코드 및 동작 원리 파헤치기

임시 테이블을 다룰 때 가장 까다롭고 자주 실수하는 부분이 바로 "데이터소스 바인딩"입니다. 코드 단에서 데이터를 아무리 열심히 밀어 넣어봤자 화면(Form Data Source)과 올바르게 연결해주지 않으면 화면에는 빈 그리드만 출력됩니다.

아래는 Form의 초기화 시점(init 메소드)에서 두 임시 테이블의 데이터를 생성하고 바인딩하는 전체 X++ 코드입니다.

[Form]
public class HDG_SalesInquiry extends FormRun
{
    /// <summary>
    /// Form 초기화 시점에 각 임시 테이블의 데이터를 채우고 화면 데이터소스에 바인딩합니다.
    /// </summary>
    public void init()
    {
        super();

        // 1. TempDB 데이터 로드 및 화면 바인딩 실행
        this.fillTempDB();

        // 2. InMemory 데이터 로드 및 화면 바인딩 실행
        this.fillInMemory();
    }

    /// <summary>
    /// TempDB에 데이터를 삽입하고 Form 데이터소스에 물리적 인스턴스를 바인딩합니다.
    /// </summary>
    private void fillTempDB()
    {
        HDG_SalesInquiryTmpDB tmpDB;
        SalesTable salesTable;

        // SalesTable에서 최근 생성된 10개의 주문 데이터를 조회하여 임시 테이블 버퍼에 삽입합니다.
        while select firstonly 10 SalesId, CustAccount from salesTable
            order by salesTable.CreatedDateTime desc
        {
            tmpDB.clear();
            tmpDB.SalesId = salesTable.SalesId;
            tmpDB.CustAccount = salesTable.CustAccount;
            
            // 실무 팁: Display Method 호출 최소화를 위해 마스터 데이터는 데이터 로드 시점에 미리 가공하여 채워둡니다.
            tmpDB.CustName = CustTable::find(salesTable.CustAccount).name();
            tmpDB.insert();
        }

        // [★중요★] TempDB 바인딩 핵심 메커니즘
        // TempDB는 물리적인 테이블 인스턴스가 SQL Server 단에 실제로 매번 새로 생성됩니다.
        // 그렇기 때문에 데이터를 채워 넣은 '물리적 인스턴스 버퍼(tmpDB)'를 
        // linkPhysicalTableInstance() 메소드를 사용해 Form의 데이터소스(Cursor)와 반드시 맵핑해주어야 합니다.
        HDG_SalesInquiryTmpDB.linkPhysicalTableInstance(tmpDB);
        HDG_SalesInquiryTmpDB_ds.executeQuery();
    }

    /// <summary>
    /// InMemory에 데이터를 삽입하고 Form 데이터소스에 포인터를 바인딩합니다.
    /// </summary>
    private void fillInMemory()
    {
        HDG_SalesInquiryInMemory tmpInMemory;
        SalesTable salesTable;

        // InMemory 임시 테이블용 로컬 버퍼에 데이터를 삽입합니다.
        while select firstonly 10 SalesId, CustAccount from salesTable
            order by salesTable.CreatedDateTime desc
        {
            tmpInMemory.clear();
            tmpInMemory.SalesId = salesTable.SalesId;
            tmpInMemory.CustAccount = salesTable.CustAccount;
            tmpInMemory.CustName = CustTable::find(salesTable.CustAccount).name();
            tmpInMemory.insert();
        }

        // [★중요★] InMemory 바인딩 핵심 메커니즘
        // InMemory 임시 테이블은 메모리 상에 존재하는 데이터의 포인터 주소를 
        // setTmpData() 메소드를 통해 Form 데이터소스에 그대로 전달하여 화면과 연결합니다.
        HDG_SalesInquiryInMemory.setTmpData(tmpInMemory);
        HDG_SalesInquiryInMemory_ds.executeQuery();
    }
}

4. 실무자를 위한 딥다이브 & 성능 최적화 팁 (Deep Dive)

블로그를 찾아주신 개발자분들을 위해, 실무 설계 단계에서 놓치기 쉬운 성능 최적화 포인트 2가지를 공유합니다.

팁 1. while select 루프 대신 insert_recordset 사용하기

위 예제 코드에서는 가독성을 위해 while select 안에서 하나씩 insert() 하는 방식을 사용했습니다. 하지만 실제 운영 환경(Production)에서 수백, 수천 건 이상의 데이터를 핸들링해야 한다면 이 방식은 심각한 성능 저하를 일으킵니다.

특히 TempDB의 경우 물리적으로 데이터베이스 레벨에서 처리되므로, 아래와 같이 한 번의 SQL 호출로 데이터를 밀어 넣는 insert_recordset 구문을 사용하는 것이 압도적으로 유리합니다.

// 예시: insert_recordset을 활용한 대용량 처리 기법 (AOS-DB 간 통신 횟수를 획기적으로 줄여줍니다)
insert_recordset tmpDB (SalesId, CustAccount)
    select SalesId, CustAccount from salesTable
    where salesTable.CreatedDateTime >= datetimeValue;

팁 2. 언제 무엇을 선택해야 할까요? (결정 가이드)

TempDB를 선택해야 하는 경우:
- 화면에서 사용자가 임시 테이블을 기준으로 다른 마스터 테이블(예: CustTable, InventTable)과 복잡한 Join 및 필터링 검색을 수행해야 할 때.
- 처리해야 하는 대상 데이터가 예측하기 어려울 정도로 많거나 대용량일 때.
InMemory를 선택해야 하는 경우:
- 화면에 단순히 뿌려주기만 하면 되는 독립적인 휘발성 가공 데이터일 때.
- 데이터의 총량이 수십~수백 건 미만으로 매우 적고 단순 루프 연산이 주를 이룰 때.

마치며

이번 포스팅에서는 D365 F&O 개발 시 필수적으로 이해해야 하는 두 가지 형태의 임시 테이블, TempDB와 InMemory에 대해 알아보고 구현 코드까지 살펴보았습니다.

핵심은 TempDB는 linkPhysicalTableInstance(), InMemory는 setTmpData()를 사용한다는 점, 그리고 데이터 용량과 쿼리의 복잡도에 따라 인프라 환경을 고려해 알맞은 테이블 타입을 선택해야 한다는 것입니다.

작은 아키텍처의 차이를 이해하는 것이 곧 성능 최적화된 고품질 ERP 개발의 시작입니다.

오늘 준비한 내용이 여러분의 개발 업무에 큰 도움이 되길 바랍니다! 질문이나 다른 좋은 의견이 있다면 언제든 댓글로 남겨주세요.

[Dynamics365] 개발 초급자 코스 - 4. 운영환경의 데이터베이스 로컬 환경에 적용하기

jjongjjong-e — Mon, 11 May 2026 01:03:46 +0900

D365 F&O 개발을 하다 보면 운영 환경이나 Sandbox(UAT)의 실데이터를 로컬 개발 환경에서 테스트하거나 디버깅해야 할 일이 자주 발생한다.

오늘은 SqlPackage.exe를 활용하여 데이터베이스를 Export하고, 로컬 DB(AxDB)에 적용하는 전체 과정을 정리해본다.

1. 준비 작업: SqlPackage 설치 및 경로 확인

가장 먼저 필요한 Tool은 SqlPackage이다.

다운로드: Download and Install SqlPackage - SQL Server | Microsoft Learn
- Tip: 설치 관리자보다는 .ZIP 파일 형태로 다운로드하여 원하는 경로에 압축을 푸는 것을 추천한다.
실행 경로 예시:
- C:\Program Files\Microsoft SQL Server\170\DAC\bin (SQL Server 버전 및 설치 방식에 따라 다를 수 있음)

2. 운영/Sandbox DB 내보내기

1) 먼저 SandBox 에 Production database 를 Refresh(덮어쓰기) 한다.

2) Sandbox 에 있는 데이터 베이스를 Export 한다.

3) Export 가 완료되면 Asset library > Database backup 에서 Database 를 다운로드 한다.

Managed 환경이 아닌 환경에서 Export 할 경우 다음과 같은 Script를 실행한다.

# SqlPackage 경로로 이동 cd "C:\Program Files\Microsoft SQL Server\170\DAC\bin\" # Export 실행 ./SqlPackage.exe /a:export /ssn:localhost /sdn:AxDB /tf:J:\MSSQL_BACKUP\AxDB_20251027.bacpac /p:CommandTimeout=1200 /p:VerifyFullTextDocumentTypesSupported=false /SourceTrustServerCertificate:True

/ssn: 원본 서버 주소 (보통 로컬이면 localhost)

/sdn: 원본 DB 명 (일반적으로 AxDB)

/tf: 생성될 파일 경로 및 이름

/SourceTrustServerCertificate:True: 연결 인증서 관련 에러 방지

3. 로컬 환경에 데이터 가져오기

명령 프롬프트(CMD)를 관리자 권한으로 실행한 뒤 다운로드한 .bacpac 파일을 새 이름으로 Import를 진행한다.

# Import 실행
./SqlPackage.exe /a:import /sf:I:\MSSQL_BACKUP\hcc-uatbackup.bacpac /tsn:localhost /tdn:AxDB_20251110 /p:CommandTimeout=1200 /TargetTrustServerCertificate:True

/sf: 가져올 파일 경로
/tdn: 로컬에 생성할 새로운 DB 이름 (기존 AxDB와 충돌을 피하기 위해 날짜 등을 붙임)
/TargetTrustServerCertificate:True: 로컬 방화벽 정책이나 인증서 에러 발생 시 /ttsc:true 옵션과 동일한 역할을 수행합니다.

4. 가져온 Database 에 다음과 같은 쿼리 실행

CREATE USER axdeployuser FROM LOGIN axdeployuser
EXEC sp_addrolemember 'db_owner', 'axdeployuser'

CREATE USER axdbadmin FROM LOGIN axdbadmin
EXEC sp_addrolemember 'db_owner', 'axdbadmin'

CREATE USER axmrruntimeuser FROM LOGIN axmrruntimeuser
EXEC sp_addrolemember 'db_datareader', 'axmrruntimeuser'
EXEC sp_addrolemember 'db_datawriter', 'axmrruntimeuser'

CREATE USER axretaildatasyncuser FROM LOGIN axretaildatasyncuser

CREATE USER axretailruntimeuser FROM LOGIN axretailruntimeuser

CREATE USER axdeployextuser FROM LOGIN axdeployextuser

CREATE USER [NT AUTHORITY\NETWORK SERVICE] FROM LOGIN [NT AUTHORITY\NETWORK SERVICE]
EXEC sp_addrolemember 'db_owner', 'NT AUTHORITY\NETWORK SERVICE'

UPDATE T1
SET T1.storageproviderid = 0
    , T1.accessinformation = ''
    , T1.modifiedby = 'Admin'
    , T1.modifieddatetime = getdate()
FROM docuvalue T1
WHERE T1.storageproviderid = 1 --Azure storage

DROP PROCEDURE IF EXISTS SP_ConfigureTablesForChangeTracking
DROP PROCEDURE IF EXISTS SP_ConfigureTablesForChangeTracking_V2
GO
-- Begin Refresh Retail FullText Catalogs
DECLARE @RFTXNAME NVARCHAR(MAX);
DECLARE @RFTXSQL NVARCHAR(MAX);
DECLARE retail_ftx CURSOR FOR
SELECT OBJECT_SCHEMA_NAME(object_id) + '.' + OBJECT_NAME(object_id) fullname FROM SYS.FULLTEXT_INDEXES
    WHERE FULLTEXT_CATALOG_ID = (SELECT TOP 1 FULLTEXT_CATALOG_ID FROM SYS.FULLTEXT_CATALOGS WHERE NAME = 'COMMERCEFULLTEXTCATALOG');
OPEN retail_ftx;
FETCH NEXT FROM retail_ftx INTO @RFTXNAME;

BEGIN TRY
    WHILE @@FETCH_STATUS = 0 
    BEGIN 
        PRINT 'Refreshing Full Text Index ' + @RFTXNAME;
        EXEC SP_FULLTEXT_TABLE @RFTXNAME, 'activate';
        SET @RFTXSQL = 'ALTER FULLTEXT INDEX ON ' + @RFTXNAME + ' START FULL POPULATION';
        EXEC SP_EXECUTESQL @RFTXSQL;
        FETCH NEXT FROM retail_ftx INTO @RFTXNAME;
    END
END TRY
BEGIN CATCH
    PRINT error_message()
END CATCH

CLOSE retail_ftx; 
DEALLOCATE retail_ftx; 
-- End Refresh Retail FullText Catalogs

--Begin create retail channel database record--
declare @ExpectedDatabaseName nvarchar(64) = 'Default';
declare @DefaultDataGroupRecId BIGINT;
declare @ExpectedDatabaseRecId BIGINT; 
IF NOT EXISTS (select 1 from RETAILCONNDATABASEPROFILE where NAME = @ExpectedDatabaseName)
BEGIN 
 select @DefaultDataGroupRecId = RECID from RETAILCDXDATAGROUP where NAME = 'Default'; 
 insert into RETAILCONNDATABASEPROFILE (DATAGROUP, NAME, CONNECTIONSTRING, DATASTORETYPE)
 values (@DefaultDataGroupRecId, @ExpectedDatabaseName, NULL, 0); 
 select @ExpectedDatabaseRecId = RECID from RETAILCONNDATABASEPROFILE where NAME = @ExpectedDatabaseName; 
 insert into RETAILCDXDATASTORECHANNEL (CHANNEL, DATABASEPROFILE)
 select RCT.RECID, @ExpectedDatabaseRecId from RETAILCHANNELTABLE RCT
 inner join RETAILCHANNELTABLEEXT RCTEX on RCTEX.CHANNEL = RCT.RECID
        update RETAILCHANNELTABLEEXT set LIVECHANNELDATABASE = @ExpectedDatabaseRecId where LIVECHANNELDATABASE = 0
END; 
--End create retail channel database record

위 쿼리 실행중 오류가 나는 쿼리는 무시하고 진행해도 상관없다.

5. Local 환경 중지

Service 에서 아래 3가지 항목을 중지한다.

World Wide Web Publishing Service
Microsoft Dynamics 365 Unified Operations: Batch Management Service
Management Reporter 2012 Process Service

6. Database 이름 변경

기존에 사용중이던 AxDB 는 이름을 다른 것으로 변경한다.

그다음 새로 업로드한 Database 를 AxDB 로 변경한다.

변경하는 쿼리는 아래를 참고한다.

-- 1. 기존 DB를 싱글 유저 모드로 전환하여 연결 끊기 및 이름 변경
ALTER DATABASE AxDB SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
ALTER DATABASE AxDB MODIFY NAME = AxDB_Old;

-- 2. 새로 가져온 DB의 이름을 AxDB로 변경
ALTER DATABASE AxDB_20251110 MODIFY NAME = AxDB;

-- 3. 멀티 유저 모드로 복구 (정상 사용 설정)
ALTER DATABASE AxDB SET MULTI_USER WITH ROLLBACK IMMEDIATE;

7. "5. Local 환경 중지" 에서 실행했던 서비스를 다시 실행시키고, Full Database synchronize, Admin provision 을 진행한다.

이 과정은 D365 F&O 개발 환경 구축 및 유지보수의 핵심이다.

특히 SqlPackage 경로와 파라미터 옵션(/ttsc 등)만 잘 숙지해도 시행착오를 크게 줄일 수 있습니다.

더 자세한 시나리오는 MS Learn - DB Movement Scenario 문서를 참고하시기 바랍니다.

[Dynamics365] 개발 초급자 코스 - 3. 간단한 데이터 조회 및 관리 화면 만들기

jjongjjong-e — Mon, 20 Apr 2026 22:57:41 +0900

오늘은 앞서 작성한 Model 위에서 간단한 테이블 생성 부터 입력, 조회 화면까지 만들어본다.

시나리오: 회사의 사무용 비품(노트북, 모니터, 키보드 등)을 등록하고 조회하는 간단한 화면 생성.
테이블 : HDG_AssetTable
주요 필드 구성:
- 비품 코드 (AssetId): 고유 식별자 (String)
- 비품 명칭 (AssetName): 명칭 (String)
- 비품 분류 (AssetCategory): 가구, 전자제품, 소모품 등 (Base Enum)

1. 다중언어의 기본 - Label 생성

첫 번째 단계에서는 다중언어의 기본인 Label 을 생성한다.

Add > New item... > Label File > 이름을 지정 후 Add

다중언어를 입력한 언어를 선택 후 Next

각각 언어에 맞게 ID와 다중언어 라벨을 지정

사용방법 : @{{Label 파일}}:{{Label ID}} ( 예시 : @HDG:AssetId )

2: 데이터의 기본 - Table 및 EDT 생성

두 번째 단계에서는 데이터를 저장할 '테이블'을 생성한다.

1) EDT(Extended Data Type) 생성

D365에서 EDT는 데이터의 '설계도'와 같다.

한 번 정의하면 여러 테이블에서 재사용할 수 있으며, 레이블(Label)이나 정렬 방식을 일괄 관리할 수 있다.

생성 항목:
1. HDG_AssetId (String): 비품을 식별하는 고유 코드
2. HDG_AssetName (String): 비품의 명칭
EDT를 사용하는 이유:
- 재사용성: 여러 테이블에서 '비품 코드'를 사용할 때, 동일한 길이와 속성을 유지할 수 있다.
- 유지보수성: AssetId의 길이를 10자에서 20자로 늘려야 할 때, EDT만 수정하면 이를 사용하는 모든 테이블에 즉시 반영된다.
- Label 관리: 사용자에게 보여질 이름(예: "비품 번호")을 한 곳에서 관리하여 UI의 일관성을 제공한다.
- Table Relation 정의: EDT 를 통해 어떠한 테이블을 위해 정의되었는지 확인이 가능하다.

EDT String 생성 > Label 지정 > String Size 지정

위 예시에서는 EDT는 Model 을 관리목적상 분리하였다. 실습에서는 같은 Model 에서 진행하도록 한다.

2) Base Enum 생성

비품의 종류(전자제품, 가구, 소모품 등)처럼 정해진 선택지 중 하나를 고르는 데이터는 Base Enum으로 관리한다.

생성 항목: HDG_AssetCategory
Elements 구성:
- None (0)
- Electronic (1) - 전자제품
- Furniture (2) - 가구
- Supplies (3) - 소모품
장점: 데이터베이스에는 숫자로 저장되어 가볍고, 코드에서는 이름으로 호출할 수 있어 가독성이 높다.

각 Enum 값 별로 Label 은 따로 지정하도록 한다.

3) Table 생성 및 필드 구성

이제 앞서 만든 EDT와 Enum을 조합하여 실제 데이터를 담을 HDG_AssetTable을 생성합니다.

필드 추가:
- AssetId (EDT: HDG_AssetId 연결)
- AssetName (EDT: HDG_AssetName 연결)
- AssetCategory (Base Enum: HDG_AssetCategory 연결)

AssetId 필드에 EDT 를 지정하면 String Size 가 상속되는 것을 확인할 수 있다.

Table 주요 속성 설정:
- Label: "사무용 비품" (사용자 화면에 표시될 테이블 이름)
- Title Field 1: AssetId
- Title Field 2: AssetName (레코드 식별 시 주로 보일 필드 지정)

4) Primary Index 설정

중복된 비품 코드가 들어오지 않도록 인덱스를 설정해야 한다.

Index 생성: AssetIdx라는 이름의 인덱스를 만들고 AssetId 필드를 추가한다.
필드 속성 설정:
- Allow Duplicates: No (중복 방지)
- Alternate Key: Yes
Table 수준 설정:
- 테이블의 Primary Index 속성에서 방금 만든 AssetIdx를 선택한다.
- 이렇게 설정하면 시스템은 AssetId가 고유함을 보장하며, 조회 성능 또한 최적화된다.

Index 생성

필드 속성 지정

Primary Index 지정

3. Form Design - 'Simple List' 패턴 적용

1) Form 생성 및 Data Source 연결

화면 개발의 시작은 데이터를 어디서 가져올지 정의하는 것에서 시작된다.

Form 생성: 프로젝트에서 Add > New Item > Form을 선택하여 생성한다. (HDG_AssetTable)
Data Source 지정: 생성된 Form의 Data Sources 노드에 이전 세션에서 만든 AssetTable을 드래그 앤 드롭으로 추가한다.
Caption 지정: 화면의 제목을 지정한다.

2) Simple List 패턴 적용

D365는 디바이스 환경에 최적화된 UI를 제공하기 위해 패턴 검사기를 운영한다. 'Simple List'는 마스터 데이터를 한눈에 조회하고 편집하기에 가장 적합한 패턴이다.

패턴 지정: Design 노드에서 우클릭 후 Apply pattern > Simple List를 선택한다.
패턴의 역할: 패턴을 적용하면 화면 구성에 필요한 필수 컨트롤 목록이 나타난다. 개발자는 이 가이드를 따라 컨트롤을 배치하기만 하면 표준 디자인이 완성된다.
시각적 일관성: 패턴을 사용하면 해상도 변화에 따라 UI가 유동적으로 대응하며, 사용자에게 시스템 전반에 걸친 일관된 경험을 제공한다.

3) 디자인 구조 잡기: Action Pane, Filter, Grid

Simple List 패턴은 크게 세 가지 영역으로 구성된다.

① Action Pane (기능 영역)

화면 최상단에 위치하며, 새 레코드 생성, 삭제, 저장 등의 버튼이 배치되는 곳이다.
Design 노드 아래에 Action Pane 컨트롤을 추가한다. 별도의 커스텀 버튼이 없어도 시스템 표준 버튼이 자동으로 생성된다.

② Custom Filter Group (조회 영역)

사용자가 특정 데이터를 빠르게 찾을 수 있도록 필터 기능을 제공한다.
Group 컨트롤을 추가하고 속성에서 Custom and Quick Filters 패턴을 적용한다.
이를 통해 사용자는 비품 코드나 명칭으로 실시간 검색을 수행할 수 있다.

③ Grid (데이터 영역)

실제 데이터가 리스트 형태로 출력되는 핵심 컨트롤이다.
Grid 컨트롤을 추가하고 Data Source 속성을 HDG_AssetTable로 연결한다.
Data Sources 노드에 있는 필드들(AssetId, AssetName, AssetCategory 등)을 Grid 내부로 드래그하여 배치한다.

최종적으로 완성된 모습

Pro-Tip: 디자인 가이드라인 준수의 이유

"구조화된 UI가 유지보수 비용을 결정한다."

Metadata-Driven UI: D365의 UI는 코드가 아닌 메타데이터 기반으로 작동한다. 패턴을 준수해야만 향후 플랫폼 업데이트 시 UI 깨짐 현상을 방지할 수 있다.

사용자 편의성: 전 세계 모든 D365 모듈은 동일한 패턴을 공유한다. 사용자가 별도의 교육 없이도 새로운 화면의 사용법을 직관적으로 이해할 수 있게 한다.

필수 속성 점검: 패턴 적용 후 Pattern 담긴 컨트롤에 누락된 요소가 있다면 Visual Studio가 오류 메시지로 안내하므로, 실수 없는 완벽한 화면 구성이 가능하다.

4. 사용자 접근 권한: Menu Item 생성

Dynamics 365 F&O에서 Form은 단독으로 실행될 수 없으며, 반드시 Menu Item을 통해 호출된다. 이는 UI와 내비게이션을 분리하여 보안 및 관리 효율성을 높이기 위함이다.

1) Display Menu Item 생성 및 Form 연결

Menu Item 생성: 프로젝트에서 Add > New Item > Display Menu Item을 생성한다. (HDG_AssetTable)
Object 연결: 속성 창의 Object Type을 Form으로 설정하고, Object 속성에서 이전에 만든 Form( HDG_AssetTable)을 선택한다.
Label 설정: 사용자에게 보여질 메뉴 명칭(예: "비품 관리")을 작성한다. 이는 사용자 편의성과 직결되는 필수 작업이다.

2) 메뉴 확장(Menu Extension)을 통한 배치

Menu Item만 생성해서는 사용자가 화면에서 찾을 수 없다. 기존 시스템 메뉴에 이를 등록해야 한다.

Menu Extension 생성: Application Explorer에서 Menus > MainMenu 혹은 특정 모듈 메뉴(예: FleetManagement)를 찾아 우클릭 후 Create extension을 선택한다. 만약 Create Extension 이 비활성화 되어 있다면 Model Reference 를 추가한다.
항목 추가: 확장된 메뉴 구조에서 원하는 위치(예: Rentals )에 방금 만든 Display Menu Item을 드래그하여 배치한다.

5. 실습 및 검증: 빌드와 실행

모든 객체 생성이 완료되었다면, 메타데이터를 컴파일하고 데이터베이스에 물리적인 변화를 반영할 차례다.

1) 솔루션 빌드 및 DB 동기화(DB Sync)

Build 수행: 전체 솔루션을 빌드한다. 이 과정에서 구문 오류나 패턴 위반 여부를 최종 확인한다.
Database Synchronize: 새로운 테이블이나 필드가 추가되었으므로, SQL Server에 실제 테이블 구조를 생성하기 위해 DB Sync를 수행한다. 이 과정을 거쳐야만 런타임에서 데이터 오류가 발생하지 않는다.

2) 웹 브라우저 실행 및 테스트

화면 접속: 빌드가 완료되면 웹 브라우저를 통해 시스템에 접속한다. 메뉴를 통해 들어가거나, URL 끝에 &mi=MenuItemName을 붙여 직접 호출한다.
데이터 입력 테스트: New 버튼을 눌러 비품 정보를 입력하고 저장이 정상적으로 이루어지는지 확인한다.
조회 및 필터 기능 검증: 앞서 설정한 QuickFilter를 통해 특정 비품이 올바르게 검색되는지, 그리드의 정렬 기능이 작동하는지 테스트한다.

[Dynamics365] 개발 초급자 코스 - 2. 아키텍쳐 (Model, Layer, Project)

jjongjjong-e — Tue, 3 Feb 2026 21:01:07 +0900

Dynamics 365의 언어인 X++을 잘 작성하는 것도 중요하지만, 그 이전에 아키텍쳐를 이해해야 정확한 코드 관리가 가능하다.

이번 글에서는 개발 아키텍쳐의 핵심요소인 Model과 Layer, Project에 대해서 알아본다.

1. Layer

Layer는 코드의 우선순위를 결정하는 수직적 계층이다. AX 시절부터 이어져온 구조로 8개의 기본 레이어와 8개의 패치 레이어(xxP)로 구성되어 있다.

Layer 계층

* 주요 레이어 계층 구조 (하위 -> 상위 순)

SYS (System): Microsoft가 작성한 핵심 표준 코드.
ISV (Independent Software Vendor): 외부 독립 소프트웨어 개발사(ISV)가 개발한 솔루션.
VAR (Value Added Reseller): 지역 파트너사가 여러 고객사를 위해 개발한 솔루션. (EX: 모든 고객사에 들어가는 부가세 패키지)
CUS (Customer): 특정 고객사의 요구에 맞춘 커스터마이징 코드.
USR (User): 개별 설치 환경에서의 최종 수정 사항.

AX 때까지만 해도 상위 Layer 가 하위 Layer 를 덮어버리는 Overshadow 라는 개념을 충분히 이해해야했지만, Dynamics365 로 개발환경이 넘어오면서 부터는 크게 중요하지 않다.

2. Model

Dynamics365 개발에서는 Layer는 이제 Model이 속할 수 있는 '영역'을 제공할 뿐, 실제 모든 개발 요소는 Model 내에서 관리된다.

Model은 Layer 에 종속되지만, 개발자가 실제 제어하고 관리해야할 실체는 Model이다.

* 모델관리의 핵심 포인트

배타적 소속성: 하나의 개체는 특정 레이어 안의 단 하나의 모델에만 존재할 수 있다.
논리적·물리적 단위: 모델은 XML 파일들의 집합이며, 개발자가 프로젝트를 생성할 때 지정하는 가장 중요한 기준이다.
종속성 관리 (Dependency): 모델은 다른 모델을 참조(Reference)해야만 해당 기능을 확장할 수 있다. 레이어가 수직적인 서열이라면, 모델은 그 안에서 그물망 같은 참조 관계를 형성한다.

3. Project

Visual Studio에서의 프로젝트는 소스 코드를 물리적으로 담는 것이 아니라, 특정 모델 내의 요소들을 편집하기 위한 논리적 참조 목록 이다.

모델 귀속: 모든 프로젝트는 생성 시 반드시 하나의 'Model'에 연결된다다.
필터링된 뷰: 프로젝트는 수만 개의 표준 개체 중 현재 내가 수정하거나 생성해야 할 개체들만 모아놓은 역할을 한다.

4. 왜 Layer보다 Model 이 중요해 졌는가?

AX 2012까지는 레이어의 우선순위를 이용해 코드를 덮어쓰는 오버레이어링(Overlayering)이 가능했다.

하지만 Dynamics365는 이를 금지하고 확장(Extension) 방식을 강제하면서 패러다임이 크게 바뀌었다.

구분	과거 (AX)	현재 (Dynamics365)
핵심 기제	오버레이어링 (하위 코드 무시)	확장 (표준 코드 유지 및 기능 추가)
관리 대상	레이어 우선순위 (Overshadowing)	모델 간 참조 및 종속성 (Dependency)
업데이트	코드 병합(Merge)의 고통 발생	표준 모델 업데이트 시 영향 최소화

* 모델 중심 관리의 이점

모듈화: 기능을 기능별로 모델 단위로 쪼개어 배포할 수 있다.
배포 효율: 패키지(Package)는 모델들의 집합이며, 수정된 모델이 포함된 패키지만 빌드하여 배포 효율을 높인다.
유지보수성: Microsoft 가 배포하는 코드와 고객만을 위한 코드의 병합이 발생할 가능성이 사라진다.

* 모델 중심 관리의 제약

표준 비즈니스 프로세스의 강제: 과거 AX 시절에는 표준 로직이 고객사의 비즈니스 프로세스와 맞지 않을 경우, 해당 코드를 주석 처리하거나 삭제하고 새로운 로직을 채워 넣을 수 있었다. 그러나 Dynamics365 에서는 표준 로직을 무시할수 없기 때문에, 다소 복잡한 우회 로직을 설계해야한다.
확장 지점(CoC)의 의존성: 표준 기능을 수정하려면 Microsoft가 열어둔 Delegate나 Wrapper(CoC)를 사용해야 한다.
* 문제: 만약 특정 메서드가 private이거나 확장 가능한 구조로 설계되지 않았다면, 개발자는 해당 기능을 수정할 방법이 없다. 이 경우 비효율적인 우회 구현을 해야만 한다.
설계의 복잡도 증가: 단순히 코드를 고치는 것이 아니라, 기존 로직의 실행 전과 후를 고려하여 기능을 덧붙여야 하므로 설계 난이도가 높다.

5. 실습

이제 Model 과 Project 생성을 실습해보자.

1) Model 생성

Extensions > Dynamics365 > Model Management > Create Model..

Model Name 을 지정하고, Layer 는 cus나 var 로 지정한다.

Create new package 를 선택한다.

어떠한 Model 를 Reference 할지 선택한다.

보통 ApplicationSuite, ApplicationCommon, ApplicationPlatform, ApplicationFoundation 등은 많이 참조하게 되므로 기본적으로 선택하는 것이 좋다.

최종 확인 후 Next를 선택한다.

PackagesLocalDirectory 내부에 Model 명 폴더가 생겼다면 Model 생성 성공이다.

2) Project 생성

File > New > Project...

Finance Operations 선택

적절한 Project name 입력 후 Create

아무런 설정을 하지않으면 Fleet Management로 Project의 Model 속성이 지정된다.

오른쪽 버튼을 클릭하여 속성으로 진입한다.

Model 을 지정하고 OK를 클릭한다.

Project 뒤에 Model 이 잘 변경되었는지 확인한다.

이제 이 Project에서 생성한 Object는 모두 HDG 이라는 Model 에 종속되게 된다.

마치며..

실습을 통해 Model이 Layer 에 종속되고, Project는 Model 에 종속된다는 것을 확인하였다.

또한 이제 Dynamics365 개발을 하기 위해서는 표준을 수정하는 것이 아니라 표준과 '공존' 하는 법을 배워야한다는 것을 명심해야한다.

단순한 Coder 가 아닌 ERP 프로세스를 이해하는 개발자가 되는 날을 위해 화이팅..!

[Dynamics365] 개발 초급자 코스 - 1. 환경(Local VM) 세팅

jjongjjong-e — Mon, 22 Dec 2025 22:34:20 +0900

Dynamics365의 개발 환경은 크게 Cloud Hosted Environment(CHE)와 Local VM(VHD) 이 있다.

그 중 Local VM 환경 최초 셋업과 그 구성에 대해 간단히 알아보자.

MS 가이드 : Deploy and access development environments - Finance & Operations | Dynamics 365 | Microsoft Learn

0. 시작하기 전 준비사항 (Prerequisites)

하드웨어: 최소 16GB RAM (32GB 권장), i5 이상의 프로세서.
저장공간: SSD 필수, 최소 250GB~300GB의 여유 공간.

1. LCS에서 VHD 파일 다운로드

가장 먼저 LCS에서 VHD 파일을 다운로드 받아야한다.

1) LCS (lcs.dynamics.com) 이동

2) Shared asset library 이동

3) Downloadable VHD 이동

4) 가장 최신의 VM 파일 모두 다운로드

10.0.43 버전을 설치하려면 해당 버전의 모든 파트 파일을 한 폴더에 받아야한다.

5) 1번 파일을 열어서 압축을 해제

6) VHD 파일 확인

2. Hyper-V 설정 및 VM 생성

Dynamics 365 VHD는 Windows의 가상화 기술인 Hyper-V를 기반으로 작동한다.

윈도우 Home 사용자 주의사항

Windows Home 을 쓰면은 따로 Hyper-V 활성화가 필요한데 활성화 방법은 아래 블로그대로 따라하면 금방 설정이 가능하다.
윈도우11 Home에서 Hyper-V 설치 및 활성화 방법 - GeeKorea

윈도우11 Home에서 Hyper-V 설치 및 활성화 방법 - GeeKorea

다양한 버전의 운영 체제를 사용하는 사용자라면 가상 머신 플랫폼은 없어서는 안될 중요한 기능이지만 Home 버전에서는 Hyper-V를 지원하지 않습니다. 이 가이드는 Windows 11 Home에서 Hyper-V 설치 및

geekorea.com

1) 가상컴퓨터 새로 만들기

새로만들기 > 가상컴퓨터

컴퓨터 이름 지정

1세대 지정

메모리는 원활한 개발을 위해서는 최소 16GB할당

네트워크는 각자 PC에 맞게끔 설정

위에서 내려받았던 하드디스크 파일 연결

2) CPU 개수 설정

만들어진 VM 클릭 > 설정

프로세서는 4~8개로 각 PC 설정에 맞게 지정

3. 초기 부팅 및 Windows License 연장

1) VM 부팅

VM 클릭 후 시작

2) 최초 패스워드 pass@word1 입력 후 로그인

pass@word1 입력

3) Windows License 연장

각 VM은 보통 신규 VHD가 출시되면 6개월 정도의 Windows License 유효기간을 준다.

각 개발환경별로 정해진 수만큼 (아마 4~5회정도로 기억한다) 6개월 씩 연장할 수 있으니 유효기간이 만료됐다면 꼭 연장하도록하자.

4) CMD(관리자권한으로 실행) 명령어 실행

5) 재부팅 후 연장 확인

4. Azure App Registration (인증 설정)

로컬 환경은 클라우드와 달리 로그인을 처리해줄 주체가 없으므로, 직접 Azure(Entra ID)에 앱을 등록하여 연결해야 한다.

반드시 Dynamics365 개발을 진행할 계정이 속해있는 Azure Tenant에서 아래 절차를 진행하도록한다.

1) Azure App 생성 (MS 가이드)

Microsoft Entra ID > 앱 등록 이동

이름 입력 후 등록

2) Redirection URI 구성

https://usnconeboxax1aos.cloud.onebox.dynamics.com/
https://usnconeboxax1aos.cloud.onebox.dynamics.com/oauth/

3) App ID 복사

등록된 App ID를 복사

4) 바탕화면의 "Generate Self-Signed Certificates" 권리자 권한으로 실행

5) 3)에서 복사했던 App ID 붙여넣고 입력

App ID 입력 / N 입력

6) 정상적으로 App이 등록되었는지 확인

5. Admin provisioning 등록 (관리자 권한 부여)

개발환경의 관리자 권한을 부여할 계정을 입력하는 단계이다.

최초 개발환경 세팅뿐만 아니라 Database를 복사한 후에도 진행하는 단계이다.

1) C:\AOSService\PackagesLocalDirectory\bin 이동

2) AdminUserProvisioning 관리자 권한으로 실행

3) 계정 입력 후 Submit

실패 시: 인터넷 연결 상태와 DNS 설정을 확인하고 VM을 재부팅한 뒤 다시 시도해본다.

6. 컴퓨터 이름 변경

나중에 팀원과의 개발 협업을 하기 위해서는 Azure Devops 연결을 해야한다.

그중에서도 TFVC(Team foundation version control)은 각 사용자의 컴퓨터명이 관리키가 되기 때문에 꼭 변경해준다.

물론 이제는 TFVC 보다는 Git 을 사용하게끔 권장하지만 아직 각 회사나 고객사 성격에 따라 TFVC을 사용하는 경우도 있기 때문에 꼭 변경해준다.

1) Server manager > Local Server > Computer name > Change > 이름 입력 후 OK > 재부팅

7. (Optional) Visual studio, SSMS 관리자 권한 실행 아이콘 만들기

Dynamics365 개발을 하기위해서는 Visual studio와 SSMS 를 항상 관리자 권한으로 실행이 필요하다.

1) Visual studio 를 Taskbar에 고정 후 오른쪽 버튼 > 설정

2) Advanced > Run as administrator 체크

3) SSMS 도 1), 2) 과정 반복

8. 환경 접근 테스트 ( 최초 URL : usnconeboxax1aos.cloud.onebox.dynamics.com )

Dynamics365 홈페이지

마치며..

이제 Dynamics 365 F&O Local VM 구축이 완료되었다.

다음 포스팅에서는 간단한 X++ 모델을 알아본다음, Visual Studio에서 프로젝트를 생성하고 첫 개발을 시작해볼 예정이다.

[Dynamics365] Azure Synapse Link

jjongjjong-e — Tue, 11 Nov 2025 23:07:34 +0900

Dynamics365 F&O의 Database 를 외부로 복사하는 방법 중 하나인 Azure Synapse Link에 대해서 알아보겠다.

1. Azure Synapse Link란 무엇인가?

Azure Synapse Link는 기존에 Export to data lake 를 대체해서 나온 기능이다.

BYOD의 단점을 보완하고 Dataverse의 Synapse Link 기능의 장점을 잘 섞어서 만들어진 기능인데 꽤나 강력한 기능이다.

Microsoft 문서에 나온 특징은 다음과 같다.

- You can choose both standard and custom finance and operations entities and tables.
=> Entity 뿐만 아니라 일반적인 Table 도 Export가 가능하다.(BYOD는 Entity만 가능했지만 Table도 Export가 가능해졌다)

- Continuous replication of entity and table data is supported. Create, update, and delete (CUD) transactions are also supported.
=> CUD 트랜잭션 포함해서 지속적인 Entity와 Table 복사가 이루어진다.

- You can link or unlink the environment to Azure Synapse Analytics and/or Data Lake Storage Gen2 in your Azure subscription. You don't have to go to the Azure portal or Microsoft Dynamics Lifecycle Services for system configuration.
=> 설정을 위해 굳이 Azure portal이나 LCS에서 할 필요없이 Azure Synapse Link나 Data lake storage Gen2에서 설정하면된다.

- You can choose data and explore by using Azure Synapse. You don't have to run external tools to configure Synapse Analytics workspaces.
=> Azure Synapse를 통해 데이터를 조회하고 탐구할수 있다. Synapse Analytics workspaces를 구성할 때에 외부 Tool은 필요없다. (이 특징은 Spark를 사용해야만 가능한 기능같다. csv로 증분 업데이트를 하면 지원하지 않는다.)

- All features of Azure Synapse Link for Dataverse are supported. These features include availability in all regions, saving as Parquet Delta files, and restricted storage accounts.
=> 모든 Azure Synapse Link for Dataverse 에서 제공하는 기능도 사용가능하다.

- The table limits in the Export to Data Lake service aren't applicable in Azure Synapse Link for Dataverse.
=> 테이블 수 제한이 없다.

- By default, saving in Parquet Delta Lake format is enabled for finance and operations data, so that query response times are faster.
=> 쿼리 응답시간이 빠른 parquet 파일로 생성이 가능하다. (사실 parquet 파일이 뭔지는 잘모르겠다. 데이터 분석쪽에서는 유명한거 같기도 한데, 사용해보니 Azure Synapse Analytics에서 직접적인 쿼리 사용이 가능했다.)

장점 밖에 없는것 같지만, 거의 유일한 단점이 하나 있다면 바로 비용적인 측면이다.
Spark 기능을 24시간 가동하게 된다면 일단 70만원부터 비용이 들게되고 Azure Data Factory 까지 쓴다면 추가적으로 비용이 발생할 수 있기 때문에 데이터 동기화 주기를 적절히 설정하는 것이 매우 중요하다.

2. Dynamics365 for Azure Synapse Link 구조

Synapse Link 를 구현하는데에는 크게 2가지 방법이 있다.

다른 블로그에 이 2가지 기능에 대해 아주 명확하게 설명한 그림이 있어서 그림과 함께 살펴보겠다.

1) CSV 형태로 증분 파일을 생성 (MS문서 : Access incremental data changes from finance and operations)

이 방법은 Data Lake 에서 직접적으로 데이터분석을 할 필요가 없을 경우에 사용하면 좋은 방법이다.
생성, 변경, 삭제된 데이터만 증분으로 csv 파일을 생성한다.
Spark 가 필요없기 때문에 Azure Data Factory 와 Data Lake에 대한 비용만 부담하면된다.
그러나 증분된 파일에 대한 삭제관리와 트리거 같은 설정이 복잡하다.

2) Parquet 형식으로 생성 (MS문서 : Choose finance and operations data in Azure Synapse Link for Dataverse - Power Apps | Microsoft Learn)

이 방법은 Data Lake 에서 직접적으로 쿼리를 분석할 때에 좋은 방법이다.
위 방법과 달리 증분이 아닌 전체 데이터에 대해서 하나의 데이터셋에 데이터변경점을 입력한다.
Spark를 사용해야 하기 때문에 비용이 최소 월 70만원 부터 시작한다. (24시간 가동시)

3. 설정하기

각 방법에 대한 설정방법은 MS 문서의 가이드를 따라가면 되는데, MS문서의 내용 앞 뒤로 내용을 추가해서 설명하겠다.

(작성자 생각 : 왜 MS 문서는 꼭 하나의 가이드에 적지않고 다른 문서를 찾아야하는 번거로움을 만드는 걸까)

1) Parquet 형식으로 생성

우선 Azure에서 Dynamics365 와 같은 Region으로 Azure Synapse Analytics를 생성하면 Blob storage 가 같이 생성된다.

Analytics 생성 후 Workspace 에서 Apache spark pool까지 생성해주면 된다.

그 다음은 아래 지침을 잘 따라가면 바로 설정이 가능하다.

Sign in to Power Apps and select the environment you want.
On the left navigation pane, select Azure Synapse Link.
On the command bar of the Synapse Link page, select + New link to data lake.
Select Connect to your Azure Synapse Analytics workspace, and then select the Subscription, Resource group, and Workspace name.
Select Use Spark pool for processing, and then select the precreated Spark pool and storage account.
Select Next.
Add the tables you want to export. You can choose finance and operations tables provided the prerequisites are met.
Select Advanced, select Show advanced configuration settings and enter the time interval, in minutes, for how often the incremental updates should be captured. The options Append only and Partition available at the table level are ignored for finance and operations tables because the system determines the partitioning strategy.
Select Save. Tables selected are initialized and ready for reporting.

* 설정할 때에 Tenant 에 최초로 연결할 경우 아래와 같은 에러가 발생할 수 있다.

1) 다음 앱이 <GUID> 테넌트에 없습니다.

해결책 : PowerShell에서 아래 Script를 실행시키면 된다.

 Install-Module -Name Az -AllowClobber -Scope AllUsers
 Connect-AzAccount
 New-AzADServicePrincipal -ApplicationId '<GUID>'

2) 403 스토리지 계정에 액세스 할수 없습니다.

해결책 : Storage 찾아가서 IAM > Storage account contributer > Managed identity > Synapse workspace 선택해서 권한을 할당하면 된다.

2) CSV 형태로 증분 파일을 생성

이 방법은 굳이 Azure Synapse Analytics 를 생성할 필요가 없기 때문에 (물론 연결해도 상관은 없다) 바로 Blob storage를 생성하면 된다. 생성할 때에 "계층 구조 네임스페이스" 반드시 체크하는 것만 잊지말고 생성한다.

역시 마찬가지로 다음부터는 MS의 지침을 잘 따라가보도록 하자.

Sign in to Power Apps and select the environment you want.
On the left navigation pane, select Azure Synapse Link.
On the Azure Synapse Link for Dataverse page, select + New link on the command bar.
Select Subscription, Resource group and a Storage account. You don't need to provide a Synapse workspace or a Spark pool.
Select Next. The option to choose tables appears.
Select Advanced, select Show advanced configuration settings, and then enable the option Enable incremental update folder structure
In the Time interval field, choose the desired frequency for reading incremental data. Using this frequency, the system partitions data into time stamped folders such that you can read the data without being impacted by ongoing write operations.
Select the Dataverse tables you want. You can also select finance and operations tables. The options Append only and Partition available at a table level are ignored. Data files are always appended and data is partitioned yearly.
Select Save. Tables selected are initialized and you see incremental data in the storage account.

* 시간 간격 설정

각 설정 모두 시간 간격에 대한 설정을 지정해야한다.
시간 간격은 15분부터 24시간 까지 설정이 가능하다.
동기화는 시간 간격이 설정되어 있어도 그 전에 동기화 작업이 끝나지 않으면 다음 동기화 작업도 시작할 수 없기 때문에 반드시 적절한 시간을 지정하는 것이 좋다.
또한 시간 간격이 짧다는 것은 그만큼 ADF나 Spark의 가동시간이 늘어난다는 뜻이기 때문에 비용적인 측면도 같이 고려해야한다.

4. CSV 형태로 증분파일 생성 시나리오 - Azure SQL로 ADF를 사용하여 복사

1) Container 폴더 살펴보기

증분된 데이터를 갖고 있는 Blob storage

dataverse-environmentName-organizationUniqueName 으로 되어있는 Blob container를 선택하면 위와 같은 폴더 구조를 확인할 수 있다.

각 파일들의 역할은 다음과 같다.

- TimeStamp 폴더 : 증분된 시간(동기화된 시간)의 데이터를 갖고 있는 폴더

내부구조는 아래 이미지와 같으며 데이터변경이 일어난 Table에 대해 폴더를 갖는다.

TimeStamp 폴더 내 파일들

- Changelog : 안에 changelog.info 파일을 보면 현재 업데이트 중인 TimeStamp 폴더이름을 갖고 있다. 시스템이 불안정해질 수 있으므로 파일을 업데이트 하면 안된다.
- EntitySyncFailure : Azure Synapse Link에서 동기화 오류가 발생할 경우 해당 폴더내에 에러가 발생한 Table 명이 저장된다.

- model.json : 최종 업데이트가 발생한 Table 의 csv 증분 파일을 지정하고, csv의 필드구조 정의를 갖고 있다. 사실상 시나리오에서는 TimeStamp내의 model.json만 사용하면 된다.

model.json

2) 파일의 생성 흐름 파악하기 (15분 간격일 경우)

증분이 발생하면 TimeStamp 폴더가 생성된다. 그리고 changelog.info 파일에 현재 생성된 TimeStamp가 기록된다.
15분동안 변경이 발생한 데이터에 대해 TimeStamp 폴더 안에 테이블의 변경사항이 기록된 csv 파일이 생성, 변경된다.
15분이 지나면 TimeStamp 폴더 내에 변경이 발생된 csv폴더를 지정하는 model.json 파일이 생성되며, root 에 있는 model.json 폴더에 덮어쓴다.

3) 증분된 csv 파일 ADF 로 Trigger 후 Azure SQL로 복사

위 생성 흐름을 파악해보면 증분이 끝나는 시점에 데이터를 Azure SQL로 복사하면 된다.

즉, TimeStamp 내의 model.json 파일이 생성되는 시점으로 Trigger를 발생시키면 된다는 뜻이다.

자 그럼 Trigger에 대한 시점도 알겠는데 저 복잡한 폴더구조에서 어떻게 데이터를 찾아서 Azure SQL 에 복사해야할까?

그것에 대한 답은 이미 Microsoft가 Template으로 제공하고 있다.

상세한 설정과 내용은 아래 MS 가이드에 상세하게 설명되어 있으니 문서를 참고하여 설정해보자.

Dataverse용 Azure Synapse 링크를 사용하여 증분 업데이트 쿼리 및 분석 - Power Apps | Microsoft Learn

Dataverse용 Azure Synapse 링크를 사용하여 증분 업데이트 쿼리 및 분석 - Power Apps

Power Apps 및 Azure Synapse Analytics를 사용하여 사용자가 지정한 시간 간격 동안 Microsoft Dataverse 데이터에 대한 증분 업데이트를 쿼리하고 분석하는 방법을 알아봅니다.

learn.microsoft.com

Template을 사용해도 데이터 복사가 끝난 폴더에 대한 삭제 관리에 대한 부분은 아직 해결되지 못했다.
이 부분을 어떻게 해결할 수 있을지에 대한 고민과 방법은 좀 더 찾아봐야할 듯 하다.

[Dynamics365] BYOD(Bring your own database) 설정하기

jjongjjong-e — Tue, 4 Nov 2025 23:14:58 +0900

Dynamics365 ERP를 다루다보면 Power BI나 타 시스템과의 인터페이스를 위해 BYOD 를 사용해야할 때가 있다.

이번 글에서는 BYOD가 어떤 것인지, 언제 써야하는지, 어떻게 설정하는지에 대해 알아본다.

1. BYOD란?

MS 공식 문서 : Bring your own database (BYOD) - Finance & Operations | Dynamics 365 | Microsoft Learn

Bring your own database (BYOD) - Finance & Operations | Dynamics 365

Learn how to export entities to your own Azure SQL database, including information about creating an SQL database and configuring the entity export option.

learn.microsoft.com

MS 공식문서에 나와있듯이 BYOD는 Data entity를 Azure SQL Database 에 Export 하는 기술이다.

MS 문서

1-1. BYOD Push option

BYOD를 설정할 때에 옵션 중에 Full push 를 할 것이냐 Incremental push를 할 것이냐가 굉장히 중요하다.

Full push (전체 푸시)	모든 데이터를 삭제 후 입력하는 방법
Incremental push (증분 푸시)	변경이 일어난 데이터에 대해서만 변경 및 삭제하는 방법

각각 방법에 대해 장단점이 있으니 적절한 정책을 갖고 운영하여야 한다.

Full push		Incremental push
장점	단점	장점	단점
Export할 때마다 전체 데이터를 복사하기 때문에 복사된 데이터에 대한 정확도가 높다.	모든 데이터에 대해 입력하기 때문에 시간이 매우 길게 소요될 수 있다. (특히 InventTrans나, GeneralJournalAccountEntry 같은 테이블이 있다면 더더욱)	변경된 데이터에 대해서만 Export 를 하기 때문에 시간적으로 효율적이다.	데이터의 정확성을 보장할 수 없다.

1-2. BYOD 증분 푸쉬의 치명적인 단점

위 표를 보면 굉장히 치명적인 말이 있다.

"데이터의 정확도를 보장할 수 없다."

아니 증분 푸쉬를 한다고 해서 왜 데이터의 정확도를 보장할 수 없는 것인가!?

증분 푸쉬는 기본적으로 Change tracking 이 Enabled 된 Entity만 설정할 수 있다는 것을 알아야한다.

그래서 Change tracking key값을 기준으로 입력, 삭제, 변경에 대한 작업을 수행하게 되는데, 만약 Export 중 배포와 같이 시스템이 다운되는 일이 발생했다면?

Dynamics365 가 기본적으로 이러한 경우에 대비해 시스템이 정상적으로 돌아오면 다시 종료됐던 시점부터 작업을 시작하게끔 하는 기능이 있지만.. Change tracking key를 놓치는 경우가 아주 가끔 발생하게 된다.

그렇게 되면 데이터가 통채로 사라지는 등 데이터의 정확도를 보장할 수 없는 경우가 발생하는 것이다.

BYOD를 통해 BI와 같은 데이터를 제공했다면 그래도 다행이겠지만, 만약 인터페이스 용으로 사용하고 있었다면 그것은 굉장히 치명적인 오류가 될 수도 있다.

따라서 증분 push 를 사용하더라도 주기적으로 Full push 를 통해 데이터의 정확도를 보장하거나 지속적인 모니터링이 필요할 것이다.

2. BYOD 사용목적

그렇다면 왜 굳이 Dynamics365 ERP에 직접 Database를 접근하지 않고 BYOD를 통해 Data를 Export를 할까?

1) 운영상의 이유

Dynamcis365 ERP가 Production(운영) 환경 부터는 직접적인 Database 접근을 허용하지 않기 때문에 외부에 data를 복사하여 접근하여야 한다.

2) 성능상의 이유

특히 Power BI가 Dynamics365 ERP의 데이터를 바라보는 방법 중에 Data Entity를 직접 OData로 접근하는 방법이 있다. 이 방법을 채택할 경우 Dynamics365 성능뿐만 아니라 Power BI의 성능에도 좋지 않을 수 있기 때문에 Database 를 따로 생성하여 데이터를 복사하는 것이다.

3) 인터페이스 구현의 이유

Power BI 뿐만 아니라 DB to DB 인터페이스 구현을 위해 BYOD를 사용하는 경우다 있다.

3. BYOD 에 대한 개인적인 견해

사실 BYOD는 위에서 서술했던 데이터 정확도의 이슈와 Export를 하는 동안 ERP의 리소스를 사용하기 때문에 ERP의 성능상에도 문제가 발생하기 때문에 잘 권장하지는 않는다. (이를 대체하기 위해 Azure Synapse Link 라는 기술을 사용하면 되지만, 잘못하면 비용이 굉장히 많이 발생하는 경우가 생긴다.)

그럼에도 불구하고 BYOD는 설정이 아주 쉽고 다른 Azure 솔루션을 사용할 필요가 없으며 비용적으로 아주 우수하다는 장점이 있기 때문에, 데이터양이 크지 않거나 중요도가 낮은 데이터를 복사할 때에는 고려해볼만한 매력적인 솔루션임에는 틀림없다.

4. BYOD 설정 방법

BYOD는 크게 다음과 같은 설정방법으로 이루어진다.

다른 블로그에서 잘 정리된 설정 방법

4-1. Azure SQL Database 생성

Azure SQL Database 를 생성하면 된다. Azure VM와 연동되는 Azure SQL 이던, PaaS형태의 Azure SQL 이던, Elastic Pool 을 사용하던 상관은 없으나 성능은 꼭 고려하여 생성하여야한다.

MS 문서에서는 최소 성능을 아래표로 구현하라고 하지만 실제로 가이드 대로 구현하면 비용적으로 몹시 부담이 클 수 있기 때문에, 최소 사양으로 생성 후 모니터링하며 성능을 서서히 올려보는 것을 권장한다.

MS 추천 SQL 성능

4-2. Entity export option 구성

Data management > Configure entity export to database 에 접근한다.

Data management

Record를 새로 생성 후 적절한 Source name과 설명을 적어준 뒤 Connection string 을 정확히 작성해야한다.

Entity store

Connection string 에 뭘 적어야할지 모르겠다면, Azure SQL 리소스의 설정 > 연결 문자열에 가면 인증방법에 따른 문자열 예시가 있으니 복사해서 사용하면 된다.

Azure 설정

Connection string을 정상적으로 작성했다면 Validate 버튼을 클릭했을 때 다음과 같은 문구가 나오면 성공이다.

4-3. Publish

이제 구성된 Entity store 에 Entity를 게시하여야 한다.

상단에 Publish 버튼을 클릭하면 Entity Grid 가 나오는데, Export 하고자 하는 Entity를 찾아서 Publish 한다.

4-4. Data management 작성

이제 Export 를 하기 위한 모든 사전작업은 완료되었고, Data management 에서 Export Entity를 작성하면 된다.

Export project

Entity name : 4-3에서 게시했던 Entity 중 하나

Target data format : 4-2에서 생성했던 Entity store 명

Default refresh type : 증분 혹은 전체 푸쉬 선

추가적으로 Project catrgory는 다른 프로젝트와의 구분 때문에 Integration으로 하는 것을 권장하나 필수는 아니다.

이제 모든 설정이 끝났으면 Export 작업을 실행해서 정상적으로 Database 에 Export 되는지 확인하면 된다.

위에서 설명한 방법 말고도 Change tracking 활성화나 Time out 과 같은 설정방법에 대해서도 MS 문서에서 설명하고 있으니 문서를 잘 참고했으면 좋겠다.