接続の確立
Visual Studio 2022 でSSIS を有効化
Visual Studio 2022 を使用している場合、SSIS を使用するにはSQL Server Integration Services プロジェクト拡張機能をインストールする必要があります。
- 拡張機能 -> 拡張機能の管理に移動します。
- 拡張機能の管理ウィンドウの検索ボックスで"SQL Server Integration Services Projects 2022" を検索し、リストから拡張機能を選択します。
- ダウンロードをクリックします。
- Visual Studio を終了し、ダウンロードしたMicrosoft.DataTools.IntegrationServices.exe インストーラーを実行します。デフォルト設定でインストーラーを進めてください。
- Visual Studio を開きます。これで、"Integration Services Project" プロジェクトテンプレートが利用可能になるはずです。
Microsoft Dynamics 365 Business Central 接続マネージャーの追加
新しい接続マネージャーを以下のように作成します。
- "Integration Services Project" テンプレートを使用してVisual Studio プロジェクトを作成します。
- 接続マネージャーウィンドウ内で右クリックし、メニューから新しい接続を選択します。
- 説明カラムでCData Microsoft Dynamics 365 Business Central Connection Manager を選択し、追加...をクリックします。
- 次のセクションで説明するように、本製品 を設定します。
または、既存のプロジェクトがあり、CData Microsoft Dynamics 365 Business Central Source またはCData Microsoft Dynamics 365 Business Central Destination がある場合:
- データフローでCData Microsoft Dynamics 365 Business Central Source またはDestination コンポーネントを右クリックします。
- 編集...を選択し、編集ウィンドウを開きます。
- 接続マネージャー:の横にある新規作成...ボタンをクリックします。ドロップダウンのセレクターを使用して接続マネージャーを作成します。
- 次のセクションで説明するように、本製品 を設定します。
Microsoft Dynamics 365 Business Central への接続
クラウドエンドポイント
データに接続するには、OrganizationURL を指定します。OrganizationURL は、以下のいずれかです。
- https://businesscentral.dynamics.com/abc123/ などのBusiness Central アカウントへのエンドポイント。
- Web サービスのルート。
- カスタムAPI のベースURL。
オンプレミスエンドポイント
以下はオンプレミスのエンドポイントの例です。
https://base URL:port/serverinstance/api/API publisher/API group/API version/ https://base URL:port//serverinstance/ODataV4 https://myInstance/.local:7048/BC220/ODataV4URL はデフォルトでブロックされているため、管理者がアクセスを許可する必要があります。
OrganizationURL を指定する方法、および利用可能なエンドポイントについては、Business Central エンドポイント を参照してください。
組織内に複数の会社がある場合は、Company を指定して接続先の会社を特定できます。 Company を空白のままにすると、本製品 はすべての会社を個別のスキーマとして取得します。
ユーザーおよびアクセスキー
Note: クラウド版ではユーザーおよびアクセスキー認証はサポート対象外となりました。 Web Service Access Key(Basic 認証)は、オンプレミスインスタンスでは引き続きサポートされています。
Microsoft では、テストや開発にはユーザーおよびアクセスキーの使用を推奨していますが、本番環境での使用は推奨していません。
User およびAccessKey の値を取得するには、Microsoft Dynamics 365 Business Central の[ユーザー]ページに移動して[編集]をクリックします。User Name および Web Service Access Key の値は、User およびPassword 接続文字列プロパティとして入力する値です。User Name はE メールアドレス ではありません。短縮されたユーザー名です。
アクセスキー認証を使用するには、次のプロパティを設定します。
- AuthScheme:アクセスキー
- User:ログインユーザー名。
- AccessKey:アクセスキー。
Microsoft Dynamics 365 Business Central への認証
Microsoft Dynamics 365 Business Central データソースを認証する前に、OrganizationURL を接続先の組織のURL に設定する必要があります。 v1とv2のどちらを使用しているかによって、見え方が異なります。 OrganizationURL の各種フォーマットについては、Business Central エンドポイント を参照してください。以下のいずれかの方法で、Microsoft Dynamics 365 Business Central への認証を行うことができます。
アクセスキー
User およびAccessKey を設定し、Microsoft Dynamics 365 Business Central データソースへ認証します。
Entra ID(Azure AD)
Note:Microsoft はAzure AD をEntra ID にリブランドしました。ユーザーがEntra ID 管理サイトを操作する必要があるトピックでは、Microsoft が使用している名称と同じものを使用します。ただし、名前または値が"Azure AD" を参照しているCData 接続プロパティは、依然として存在します。
Microsoft Entra ID は、マルチテナント型のクラウドベースのID およびアクセス管理プラットフォームです。 OAuth ベースの認証フローに対応しており、ドライバーによるMicrosoft Dynamics 365 Business Central エンドポイントへのセキュアなアクセスを実現します。
Web アプリケーションを介したEntra ID への認証には、必ずはじめにカスタムOAuth アプリケーションを作成して登録する必要があります。 これにより、アプリケーションは独自のリダイレクトURI を定義し、クレデンシャルのスコープを管理し、組織固有のセキュリティポリシーに準拠することができるようになります。
カスタムOAuth アプリケーションの作成および登録方法の詳細については、Entra ID(Azure AD)アプリケーションの作成 を参照してください。
AuthScheme をAzureAD に設定した後の認証手順は、環境によって異なります。 デスクトップアプリケーション、Web ベースのワークフロー、またはヘッドレスシステムから接続する方法の詳細については、以下のセクションを参照してください。
デスクトップアプリケーション
デスクトップアプリケーションでは、ドライバーに組み込まれたOAuth アプリケーション、またはMicrosoft Entra ID に登録されたカスタムOAuth アプリケーションのいずれかを使用して認証を行うことができます。
オプション1:組み込みOAuth アプリケーションの使用
これはドライバーに含まれている、事前登録済みのアプリケーションです。 セットアップが簡単で、独自の認証情報を登録する必要がないため、開発環境、単一ユーザー向けツール、または迅速かつ簡単な認証が求められる構成に最適です。
次の接続プロパティを設定します。
- AuthScheme:AzureAD
- InitiateOAuth:
- GETANDREFRESH – 初回ログイン時に使用します。ログインページを起動し、トークンを保存します。
- REFRESH – すでに有効なアクセストークンおよびリフレッシュトークンを取得している場合は、この設定を使用します。保存されたトークンを再利用するため、ユーザーに再度プロンプトを表示することはありません。
接続時には、ドライバーは既定のブラウザでMicrosoft Entra のサインインページを開きます。 サインインしてアクセスを許可すると、ドライバーはアクセストークンおよびリフレッシュトークンを取得し、OAuthSettingsLocation で指定されたパスに保存します。
オプション2:カスタムOAuth アプリケーションの使用
組織でセキュリティポリシーの管理、リダイレクトURI の設定、アプリケーションのブランディングなど、より高度な制御が必要な場合は、代わりにMicrosoft Entra ID にカスタムOAuth アプリケーションを登録し、接続時にその値を指定することができます。
登録時に、以下の値を記録してください。
- OAuthClientId:カスタムOAuth アプリケーションの登録時に生成されたクライアントId。
- OAuthClientSecret:カスタムOAuth アプリケーションの登録時に生成されたクライアントシークレット。
- CallbackURL:アプリケーション登録時に定義したリダイレクトURI。
カスタムOAuth アプリケーションの登録とリダイレクトURI の設定方法の詳細については、Entra ID(Azure AD)アプリケーションの作成 を参照してください。
次の接続プロパティを設定します。
- AuthScheme: AzureAD
- InitiateOAuth:
- GETANDREFRESH – 初回ログイン時に使用します。ログインページを起動し、トークンを保存します。
- REFRESH – すでに有効なアクセストークンおよびリフレッシュトークンを取得している場合は、この設定を使用します。保存されたトークンを再利用するため、ユーザーに再度プロンプトを表示することはありません。
- OAuthClientId:カスタムOAuth アプリケーションの登録時に生成されたクライアントId。
- OAuthClientSecret:カスタムOAuth アプリケーションの登録時に生成されたクライアントシークレット。
- CallbackURL:アプリケーション登録時に定義したリダイレクトURI。
認証後、トークンはOAuthSettingsLocation に保存されます。 これらの値はセッションをまたいで保持され、アクセストークンの有効期限が切れた際に自動的に更新されるため、次回以降の接続時に再度ログインする必要はありません。
ヘッドレスマシン
CI / CD パイプライン、バックグラウンドサービス、サーバーベース連携などのヘッドレス環境では、対話型のブラウザが使用できません。 AzureAD を使用して認証するには、別のデバイス上のブラウザでOAuth フローを完了し、その認証結果をヘッドレスシステムに転送する必要があります。
セットアップオプション :
- Verifier code を取得および交換
- 別のデバイスを使用してサインインし、Verifier code を取得します。ヘッドレスシステムがこのコードを使用してトークンを要求します。
- OAuth 設定ファイルを転送
- 別のデバイスで認証を行い、その後、保存されたトークンファイルをヘッドレス環境にコピーします。
Verifier code の使用
- ブラウザを備えたデバイスで:
- カスタムOAuth アプリケーションを使用する場合は、次のプロパティを設定します。
- InitiateOAuth:OFF
- OAuthClientId:カスタムOAuth アプリケーションの登録時に生成されたクライアントId。
- OAuthClientSecret:カスタムOAuth アプリケーションの登録時に生成されたクライアントシークレット。
- GetOAuthAuthorizationUrl ストアドプロシージャを呼び出し、サインインURL を生成します。
- 返されたURL をブラウザで開きます。サインインして、ドライバーにアクセス許可を与えます。verifier code を含むコールバックURL にリダイレクトされます。
- サインイン後、リダイレクトURL のcode パラメータの値を保存します。この値は後でOAuthVerifier 接続プロパティを設定する際に使用します。
- カスタムOAuth アプリケーションを使用する場合は、次のプロパティを設定します。
- ヘッドレスマシンで:
- 次のプロパティを設定します。
- AuthScheme:AzureAD
- InitiateOAuth:REFRESH
- OAuthVerifier:保存したverifier code。
- OAuthSettingsLocation:OAuth トークンの値を保存するファイルのパス。
- カスタムアプリケーションの場合:
- OAuthClientId:カスタムOAuth アプリケーションの登録時に生成されたクライアントId。
- OAuthClientSecret:カスタムOAuth アプリケーションの登録時に生成されたクライアントシークレット。
- トークンを保存した後、以下の設定により再利用できます。
- InitiateOAuth:REFRESH
- OAuthSettingsLocation:アクセストークンの自動リフレッシュを有効にするために、この場所がドライバーに読み書きのアクセス許可を与えることを確認してください。
- カスタムアプリケーションの場合:
- OAuthClientId:カスタムOAuth アプリケーションの登録時に生成されたクライアントId。
- OAuthClientSecret:カスタムOAuth アプリケーションの登録時に生成されたクライアントシークレット。
- 次のプロパティを設定します。
OAuth 設定を転送
- ブラウザを備えたデバイスで:
- デスクトップアプリケーションセクションの説明に従って接続します。
- 接続後、トークンはOAuthSettingsLocation のファイルパスに保存されます。デフォルトのファイル名はOAuthSettings.txt です。
- ヘッドレスマシンで:
- OAuth 設定ファイルをマシンにコピーします。
- 次のプロパティを設定します。
- AuthScheme:AzureAD
- InitiateOAuth:REFRESH
- OAuthSettingsLocation:アクセストークンの自動リフレッシュを有効にするために、この場所がドライバーに読み書きのアクセス許可を与えることを確認してください。
- カスタムアプリケーションの場合:
- OAuthClientId:カスタムOAuth アプリケーションの登録時に生成されたクライアントId。
- OAuthClientSecret:カスタムOAuth アプリケーションの登録時に生成されたクライアントシークレット。
セットアップ後、ドライバーは保存されたトークンを使用してアクセストークンを自動的に更新するため、ブラウザや手動でのログインは必要ありません。
Azure サービスプリンシパル
Note:Microsoft はAzure AD をEntra ID にリブランドしました。ユーザーがEntra ID 管理サイトを操作する必要があるトピックでは、Microsoft が使用している名称と同じものを使用します。ただし、名前または値が"Azure AD" を参照しているCData 接続プロパティは、依然として存在します。
サービスプリンシパルは、Microsoft Entra ID(Azure AD)アプリケーション内のセキュリティオブジェクトであり、そのアプリケーションが特定のテナント内で何を行えるかを定義します。
サービスプリンシパルはEntra 管理センターで作成でき、Azure ポータルからもアクセス可能です。
作成プロセスの過程で、サービスプリンシパルがクライアントシークレットまたは証明書のどちらを経由してEntra リソースにアクセスするかも指定します。
接続先のサービスによっては、テナント管理者がサービスプリンシパル認証を有効にするか、サービスプリンシパルを適切なロールまたはセキュリティグループに割り当てる必要があります。
サービスプリンシパルの権限は、特定のユーザーに紐づくのではなく、割り当てられたロールに基づきます。 これらのロールは、アプリケーションがアクセスできるリソースと、実行できる操作を決定します。
サービスプリンシパルを使用して認証する場合、Entra ID(Azure AD)でのサービスプリンシパルアプリの作成 で説明するようにEntra テナントにアプリケーションを登録する必要があります。
このサブセクションでは、接続前に設定する必要があるプロパティについて説明します。 これらは、クライアントシークレットで認証するか、証明書で認証するかによって異なります。
クライアントシークレットによる認証
- AuthScheme:AzureServicePrincipal。
- AzureTenant:接続するAzure AD テナント。
- OAuthClientId:アプリケーション設定のクライアントID。
- OAuthClientSecret:アプリケーション設定のクライアントシークレット。
- InitiateOAuth:GETANDREFRESH。InitiateOAuth を使うと、OAuth 交換の繰り返しや、手動でのOAuthAccessToken 設定を避けられます。
証明書による認証
- AuthScheme:AzureServicePrincipalCert。
- AzureTenant:接続するAzure AD テナント。
- OAuthClientId:アプリケーション設定のクライアントId。
- OAuthJWTCert:JWT 証明書のストア。
- OAuthJWTCertType:JWT 証明書ストアの種類。
- InitiateOAuth:GETANDREFRESH。InitiateOAuth を使うと、OAuth 交換の繰り返しや、手動でのOAuthAccessToken 設定を避けられます。
Managed Service Identity (MSI)
Azure VM 上でMicrosoft Dynamics 365 Business Central を実行しており、マネージドID(MSI)認証情報を自動的に取得して接続したい場合は、AuthScheme を AzureMSI に設定します。
User-Managed Identities
マネージドID のトークンを取得するには、OAuthClientId プロパティを使用してマネージドID のclient_id を指定します。VM に複数のユーザーが割り当てられたマネージドID がある場合は、OAuthClientId も指定する必要があります。
NTLM
Windows 認証情報を使用して認証するには、AuthScheme をNTLM に設定します。
Negotiate
認証メカニズムをサーバーとネゴシエートするには、AuthScheme を直接本製品 に設定します。 Kerberos で認証する際に使用されます。Kerberos 経由でMicrosoft Dynamics 365 Business Central への認証を行うには、認証プロパティを定義し、Kerberos が認証チケットを取得する方法を選択する必要があります。
Kerberos を使用してMicrosoft Dynamics 365 Business Central への認証を行うには、次のプロパティを設定します。
- hive.server2.authentication:Kerberos。
- AuthScheme:NEGOTIATE。
- KerberosKDC:Kerberos KDC マシンのホスト名またはIP アドレス。
- KerberosRealm:Microsoft Dynamics 365 Business Central Kerberos プリンシパルのレルム。この値は、主たる値の'@' 記号のすぐ後にあります。
- KerberosSPN:Microsoft Dynamics 365 Business Central のKerberos プリンシパルのサービスとホスト。この値は、主たる値の'@' 記号のすぐ前にあります。
認証値に加えて、以下を設定します。
- Server:接続するMicrosoft Dynamics 365 Business Central サーバーのアドレス。
- Platform:Microsoft Dynamics 365 Business Central バージョン。
- Schema:EWS.A。
サービス間認証の有効化
Service-to-Service(S2S)認証は、統合が特定のユーザーアカウントに縛られることなく、単独で実行される必要がある場合に使用されます。S2S 認証は、多要素認証(MFA)に使用されるようなOAuth の削除されたフローではなく、クライアント資格情報を使用したOAuth 認証フローを使用します。サービス間認証を設定するには、まず、Business Central に対するAPI コールを認証するために、Azure AD テナントにアプリケーションを登録する必要があります。
Azure AD テナントに必要なアプリを登録したら、以下を実行します。
- Business Central クライアントで、Microsoft Entra applications を検索します。
- ページを開きます。
- New を選択します。Business Central クライアントは、Microsoft Entra アプリケーションカードを開きます。
- 登録したアプリケーションのアプリケーション(クライアント)ID を入力します。
- Description フィールドを完成させます。このアプリケーションがパートナーによって設定されたものである場合、このパートナーによって設定されたすべてのアプリケーションを必要に応じて将来追跡できるように、十分な識別情報を提供するようにしてください。
- State をEnabled に設定します。
- 必要に応じてオブジェクトに権限を割り当てます。
(詳しくは、https://learn.microsoft.com/ja-jp/dynamics365/business-central/ui-define-granular-permissions を参照してください。)
Note: D365 AUTOMATION とEXTEND. MGT. - ADMIN システム権限セットとユーザーグループは、オートメーションで使用されるほとんどの典型的なオブジェクトへのアクセスを可能にします。(EXTEND. MGT. - ADMIN は、以前のバージョンのD365 EXTENSION MGT アクセス許可セットの代替となります。)
- (オプション:)これまでAzure ポータルで同意の付与を行っていない場合は、Grant Consent を選択してウィザードに従います。このウィザードを開始する前に、カスタムAzure AD アプリケーションでリダイレクトURL が設定済みであることを確認してください。