接続の確立
接続プロファイルの設定
[CData]リボンから[データの取得]をクリックし、[取得元:NetSuite]> 設定済みの接続 を選択してCData クエリウィンドウを起動します。新しい接続を設定するには、[新しいNetSuite 接続]をクリックします。ここでは、接続の設定、接続のテスト、および接続プロファイルの保存を行うことができます。
NetSuite への接続
NetSuite は現在、2つの異なるAPI を提供しています。- SuiteTalk はNetSuite との通信に使用する、SOAP ベースのより古いサービスです。多くのエンティティを幅広くサポートし、INSERT / UPDATE / DELETE を完全にサポートします。 しかしデータの抽出用ツールは低機能で、SELECT 時のパフォーマンスは極めて低いです。テーブルを結合するよい方法もありません。データのグループ化および集計はこのAPI からは利用できず、 そのためこれらの操作をサポートするには、すべてをクライアントサイドで実行しなければなりません。
- SuiteQL は新しいAPI です。サービスとのSQL ライクな通信方法を実現するため、JOIN の機能はより豊富になり、GROUP BY や集計機能もサポートします。 加えて、抽出したいカラムだけを取得する機能も完全にサポートします。そのため、データを抽出する際のパフォーマンスがSuiteTalk より大幅に向上しています。ただし、サポートされるのはデータの抽出のみです。
NetSuite に接続するには、以下を行う必要があります。
- Schema を設定して、接続に使用するAPI を指定。
データを取得するだけの場合は、SuiteQL の使用をお勧めします。データの取得および変更が必要な場合は、SuiteTalk の使用をお勧めします。 - 使用するAPI に適した接続オプションを設定します。(それぞれのAPI で、許可の設定 で説明するように、利用可能な接続オプションが異なることに注意してください。)
- SuiteTalk に接続する場合は、NetsuiteMetadataFolder を指定することをお勧めします。 NetSuite Metadata Folder は、NetSuite のメタデータファイルが格納されるフォルダです。指定しない場合は、フォルダの場所は自動的に選択されます。 テーブルに関するメタデータをリスト化する際のロード時間を速くするには、このプロパティを設定してください。
- 接続するすべてのユーザーが、NetSuite Web サービス経由で接続するためのAccountId 上の権限を持っていることを確認してください。このプロパティは、OAuth 1.0(トークンベース認証)およびOAuth 2.0 の両方で必須です。必須およびオプションの権限について詳しくは、許可の設定 を参照してください。
Web サービス権限用のロールを作成または編集するには:
- NetSuite にログインします。
- 新しいロールを作成する必要がある場合は、[セットアップ]->[ユーザーとロール]->[ロールの管理]->[New]の順に進みます。
既存のロールを変更する必要がある場合は、[セットアップ]->[ユーザーとロール]->[ロールの管理]に移動して、変更するロールを選択します。 - [アクセス許可]->[セットアップ]をクリックします。
- SOAP Web サービスとREST Web サービスの権限を追加します。
- その他、さまざまなエンティティやトランザクションを扱うために必要な権限を追加します。(許可の設定 を参照してください。)
- [設定]メニューから[ユーザーとロール]->[ユーザー管理]に移動します。作成したユーザーまたは変更したユーザを選択します。
- [アクセス]タブで、新しく作成したロールを追加します。
- 新しいユーザーまたは変更されたユーザーを保存します。
NetSuite への認証
このセクションでは、SuiteTalk の初期のバージョン(Basic 認証を使用)、SuiteTalk の以降のバージョン、およびSuiteQL のすべてのバージョンからNetSuite に認証する方法について説明します。
SuiteTalk 2020.2 以前のバージョン
2020.2現在、NetSuite はBasic(ユーザーネーム / パスワード)認証をサポートしていません。Version が2020.2以下の値に設定されている場合、CData Excel Add-In for NetSuite はユーザーネームとパスワード での接続を引き続きサポートしますが、すべてのお客様が次に記載のOAuth とトークンベース認証システムに移行することを推奨します。
SuiteTalk の初期バージョンで引き続きBasic 認証を使用するには、AuthScheme をBasic に設定して、ユーザー / パスワード資格情報をサポートします。ただし、これを使用するにはVersion に過去のバージョンを手動で指定する必要があります。
トークンベースまたはOAuth 2.0 認証のいずれかをサポートするには、AuthScheme をOAuth に設定します。
SuiteTalk またはSuiteQL
NetSuite は2つの形式のOAuth 認証を提供します。- トークンベース認証(TBA)は、基本的にOAuth 1.0 で、OAuthAccessToken とOAuthAccessTokenSecret を実行時ではなくNetSuite UI 内で作成します。 TBA は、2020.2 以降のSuiteTalk およびSuiteQL の両方で利用可能です。
- OAuth 2.0 認証は、SuiteQL でのみ利用できます。OAuth 2.0 認証を強制するには、次のいずれかを実行します。
- OAuthVersion を使用するAPI に明示的に設定、または
- Schema をSuiteQL に設定
Note: SuiteTalk を使用している場合、OAuthVersion を SuiteTalk に設定しても、OAuth 2.0 は使用できないことに注意してください。SuiteTalk はOAuth 2.0 をサポートしません。
トークンベースまたはOAuth 2.0 認証のいずれかをサポートするには、AuthScheme をOAuth に設定します。
トークンベース認証(OAuth 1.0)
トークンベース認証(TBA)は基本的にOAuth 1.0 です。TBA は、SuiteTalk およびSuiteQL Schema のどちらでも使用可能です。
トークンベース認証は、権限を持った管理者がOAuthClientId、OAuthClientSecret、 OAuthAccessToken、およびOAuthAccessTokenSecret をNetSuite UI 内で 直接作成することで実行されます。
TBA の使用をサポートするには、AuthScheme をToken に設定し、以下で説明するようにNetSuite UI でトークンを作成します。
NetSuite UI でのトークンの作成
多くのNetSuite 管理者は、NetSuite UI で直接トークンを作成して割り当てることを好みます。 トークン経由で接続することで、ユーザーはOAuth アクセストークンを生成するための通常の手順をスキップできます。 これにより、管理者はアクセス権の付与をより直接的に制御できるようになります。 しかし、新しいトークンを作成する必要があるたびに、UI で手動で操作を行う必要が生じます。
NetSuite UI で直接トークンを作成して割り当てる代わりに、次の手順に従ってください。
- NetSuite で、管理者権限を持つアカウントを使用してログインします。
- [セットアップ]->[会社]->[機能の有効化]->[SuiteCloud]->[認証の管理]の順に進みます。
- トークンベース認証およびTBA:認可フローを選択します。
- 変更を保存します。
- [セットアップ]->[統合]->[統合の管理]の順に進みます。
- 新しい統合を作成して、[トークンベース認証]を選択します。
統合が作成されると、Cunsumer Key とConsumer Secret が表示されます。これらは、直接OAuthClientId とOAuthClientSecret 接続プロパティにマップされます。 - Cunsumer Key およびConsumer Secret の値を記録します。
- 新しいロールを作成するか、既存のロールを編集するには、[セットアップ]->[ユーザーとロール]->[ロールの管理]の順に進みます。
- [アクセス許可]->[セットアップ]に移動します。
- ロールに次の権限を割り当てます。User Access Token: Full、Access Token Management: Full、 Web Servies: Full。
- [リスト]->[従業員]->[従業員]にリストされているユーザーに新しいロールを追加するには、従業員を選択し、 [アクセス]->[ロール]に移動します。
- [セットアップ]->[ユーザーとロール]->[アクセストークン]の順に進み、新しいアクセストークンを作成します。
- アプリケーション名には、先ほど作成した統合を指定します。これを、前のステップで作成または更新したのと同じユーザーとロールに割り当てます。
- アクセストークンを作成すると、Token Id とToken Secret が表示されます。これらは、直接OAuthAccessToken とOAuthAccessTokenSecret にマップされます。これらを書き留めます。
アクセストークンが作成されたら、前の手順で取得した値を使用して接続することができます。接続する前に、少なくとも次の接続プロパティを指定します。
- AccountId = 接続するアカウント。
- OAuthClientId = アプリケーションの作成時に表示されるConsumer Key。
- OAuthClientSecret = アプリケーションの作成時に表示されるConsumer Secret。
- OAuthAccessToken = アクセストークンが作成されたときのToken Id。
- OAuthAccessTokenSecret = アクセストークンが作成されたときのToken Secret。
OAuth 2.0
NetSuite SuiteTalk は、OAuth 2.0 認証をサポートしています。すべてのOAuth フローで、この認証を有効にするにはAuthScheme をOAuth に設定する必要があります。さらに、接続先のアカウントを指定するには、AccountId が必要です。 Web アプリケーション経由で認証したい場合は、カスタムOAuth アプリケーションの作成 で説明するようにカスタムOAuth アプリケーションを作成する必要があります。以下のサブセクションでは、3つの一般的な認証フローでのNetSuite への認証について詳しく説明します。
- デスクトップ:ユーザーのローカルマシン上でのサーバーへの接続で、テストやプロトタイピングによく使用されます。埋め込みOAuth またはカスタムOAuth で認証されます。
- Web:共有ウェブサイト経由でデータにアクセスします。カスタムOAuth でのみ認証されます。
- ヘッドレスサーバー:他のコンピュータやそのユーザーにサービスを提供する専用コンピュータで、モニタやキーボードなしで動作するように構成されています。埋め込みOAuth またはカスタムOAuth で認証されます。
カスタムOAuth アプリケーションの作成についての情報と、埋め込みOAuth 認証情報を持つ認証フローでもカスタムOAuth アプリケーションを作成したほうがよい場合の説明については、カスタムOAuth アプリケーションの作成 を参照してください。
NetSuite で利用可能な接続文字列プロパティの全リストは、Connection を参照してください。
デスクトップアプリケーション
CData は、デスクトップでの認証を簡略化する埋め込みOAuth アプリケーションを提供します。 また、NetSuite コンソールで設定および登録するカスタムOAuth アプリケーションを介してデスクトップから認証することもできます。詳しくは、カスタムOAuth アプリケーションの作成 を参照してください。接続の前に、以下の変数を設定します。
- AccountId = 接続するアカウント。
- InitiateOAuth = GETANDREFRESH。OAuthAccessToken を自動的に取得およびリフレッシュするために使用します。
- カスタムOAuth アプリケーションのみ:
- OAuthClientId = カスタムOAuth アプリケーションの登録時に割り当てられたクライアントId。
- OAuthClientSecret = カスタムOAuth アプリケーションの登録時に割り当てられたクライアントシークレット。
- CallbackURL = カスタムOAuth アプリケーションの登録時に定義されたリダイレクトURI。
接続すると、本製品 はデフォルトブラウザでNetSuite のOAuth エンドポイントを開きます。ログインして、アプリケーションにアクセス許可を与えます。
アクセストークンの期限が切れたときは、本製品 は自動でアクセストークンをリフレッシュします。
OAuth アクセストークンの自動リフレッシュ:
本製品 がOAuth アクセストークンを自動的にリフレッシュするようにするには、次のように設定します。
- はじめてデータに接続する際、次の接続プロパティを設定します。
- AccountId = 接続するアカウント。
- InitiateOAuth = REFRESH。
- OAuthClientId = アプリケーション設定のクライアントId。
- OAuthClientSecret = アプリケーション設定のクライアントシークレット。
- OAuthAccessToken = GetOAuthAccessToken によって返されたアクセストークン。
- OAuthSettingsLocation = 本製品 がOAuth 値を保存する場所のパス。これは接続間で維持されます。
- その後のデータ接続では、以下を設定します。
- InitiateOAuth
- OAuthSettingsLocation
OAuth アクセストークンの手動リフレッシュ:
OAuth アクセストークンを手動でリフレッシュするために必要な唯一の値は、OAuth リフレッシュトークンです。
- ExpiresIn 期間(GetOAuthAccessToken が返す)が経過した後にOAuthAccessToken を手動でリフレッシュするには、RefreshOAuthAccessToken ストアドプロシージャを呼び出します。
- 次の接続プロパティを設定します。
- AccountId = 接続するアカウント。
- OAuthClientId = アプリケーション設定のクライアントId。
- OAuthClientSecret = アプリケーション設定のクライアントシークレット。
- RefreshOAuthAccessToken を呼び出し、OAuthRefreshToken にGetOAuthAccessToken によって返されたOAuth リフレッシュトークンを設定します。
- 新しいトークンが取得できたら、OAuthAccessToken プロパティにRefreshOAuthAccessToken によって返された値を設定します。これで新規接続が開かれます。
OAuth リフレッシュトークンを保存し、OAuth アクセストークンの有効期限が切れた後に手動でリフレッシュできるようにします。
同時リクエスト
NetSuite はアカウント毎に一定数の同時リクエストのみ受け付け、接続毎に設定できます。 (デフォルトは通常5です。)同時リクエストの最大数がすでに使用されているときに別のリクエストが 行われた場合、ユーザーは"Only one request may be made against a session at a time" エラーを受け取ることがあります。CData Excel Add-In for NetSuite は、同時リクエスト制限を超えないように追加のリクエストを遅延させることで、この状況に 対処しようとします。ただし、アカウントに複数のマシンやアプリケーションから接続がある場合、 この処理を適切に実行することができないことがあります。
接続プロパティ
最後に、Connection プロパティを参照してください。接続の確立に使用できるさまざまなオプションの説明があります。
接続の管理
NetSuite への認証に成功すると、インポートするデータをカスタマイズすることができます。詳しくは、接続の管理 を参照してください。
関連項目
- データのクエリ:[データ選択]ウィザードを使用してスプレッドシートにデータをプルします。また、ここではスケジュールされたデータのリフレッシュも設定できます。
- Excel アドインの使用:利用可能なCData Excel 関数 を使用するなど、NetSuite データとやり取りする他の方法が見つかります。