Sage 100 / Sage 300 接続：Sage 300 Web API の接続を確認する

1 つの接続で両製品をカバーし、variant フィールドでどちらを指すかが決まります。sage300 はサービスアドレス、会社コード、ユーザーアカウントで Sage 300 Web API に対して実際の接続テストを実行し、sage100 は利用できない旨を正直に返します。variant、ベース URL、会社、ユーザー名、パスワードを入力してテストしてください。まず Sage 300 側をご覧ください。

これは 2 つの Sage 製品のための 1 つの接続であり、最初のフィールド variant がその後のすべてを決めます。variant が sage300 の場合、接続はこのシステムが Sage 300 Web API に到達できるかを確認します。Sage 300 のユーザーアカウントで HTTP Basic 認証を行い、会社プロファイルを 1 回読み取ります。variant が sage100 の場合、テストはリクエストを一切送信しません。Sage 100 の eBusiness Web Services 呼び出しは SOAP ベースであり、そのリクエストはまず自社の WSDL で確認する必要があるため、利用できない旨を正直に返します。両製品とも範囲を明確にしてください。この接続は接続確認専用です。注文、顧客、在庫の取込は行わず、在庫の返送も行いません。Sage 300 については、そのビューが返す項目名を、まず自社導入環境の swagger で確認する必要があります。Sage 300 のテスト合格は、以下の 5 つの値がその会社に対して一緒に機能することの証明であり、それ以上ではありません。

前提条件#

• 実際に使っている製品が Sage 300 か Sage 100 か分かっていること。これで variant の値が決まり、テストでの 2 つの経路の動作はまったく異なります。
• Sage 300 の場合：Sage 300 Web API サービスがサーバー上で稼働しており、アドレスが https://server/Sage300WebApi の形式であること。ブラウザで {baseUrl}/swagger を開いて自分で確認できます。そのページが応答すれば、サービスは稼働しています。
• 統合に使う、ローカルの Sage システム内のユーザーアカウント。Sage 300 の場合は HTTP Basic で認証でき、Web API の利用が許可された Sage 300 ユーザー。Sage 100 の場合は Web Services ユーザー。これらの認証情報にクラウドでの登録はなく、アカウントは自社の Sage システム内にあります。
• 会社コード。Sage 300 の場合は Web API アドレスに現れる会社の Org ID（例：SAMINC）。Sage 100 の場合は会社コード。

認証情報の取得#

1. 他の値を集める前に、まず variant の単語を決めます。Sage 300 を使っている場合は sage300、Sage 100 の場合は sage100 と入力します。正確な単語が重要です。テストは文字通り読み取ります。
2. Sage 300 の場合、サーバーの Web API アドレス（例：https://server/Sage300WebApi）を控えます。まずブラウザで {そのアドレス}/swagger を開いてください。ページが応答すれば、アドレスが正しく、サービスが稼働しています。
3. Sage 100 の場合、代わりにサーバーの eBusiness Web Services アドレス（例：https://server/ebusinesswebservices）を控えます。Sage 管理者が保管している WSDL と一緒に準備してください。
4. 会社コードを控えます。Sage 300 の場合は Web API アドレスで使われる会社の Org ID（例：SAMINC）。Sage 100 の場合は、接続したい会社の会社コードです。
5. Sage 管理者に、ローカルの Sage システム内の統合用ユーザーアカウントを依頼し、そのユーザー名とパスワードをペアで控えます。Sage 300 の場合は HTTP Basic 認証用の Sage 300 ユーザー、Sage 100 の場合は Web Services ユーザーです。個人の日常ログインではなく、統合用に作成されたアカウントを使ってください。

Integration への入力#

1. Integration → コネクタマーケットプレイス → Sage 100 / Sage 300 → 新規接続を開きます。
2. variant、必須、製品バリアント：Sage 300 を使っている場合は単語 sage300、Sage 100 の場合は sage100 と入力します。sage300 は Sage 300 Web API（OData）へ向かいます。sage100 は Sage 100 eBusiness Web Services（SOAP）へ向かいますが、まず WSDL の確認が必要で、まだテストは開放されていません。
3. base_url、必須、サービスベース URL：Sage 300 の場合は Web API アドレス（例：https://server/Sage300WebApi）を貼り付けます。Sage 100 の場合は、代わりに eBusiness Web Services アドレス（例：https://server/ebusinesswebservices）を貼り付けます。
4. company、必須、会社コード：Sage 300 の場合は Web API アドレスに入る会社の Org ID（例：SAMINC）を入力します。Sage 100 の場合は会社コードを入力します。
5. username、必須、ユーザー名：ローカルの Sage システム内の統合アカウントのユーザー名を入力します。sage300 の場合は Sage 300 ユーザー、sage100 の場合は Web Services ユーザーです。例の形式は、この接続用に作成された API ユーザー名です。
6. password、必須、パスワード：同じアカウントのパスワードを貼り付けます。パスワード型のフィールドで、秘密情報として保存されます。ユーザー名とパスワードは同じアカウントのものでなければなりません。

接続テスト#

接続テストをクリックします。何が起こるかは variant によって決まり、テストはまずこのフィールドを読みます。variant が空の場合、テストは MISSING_VARIANT で止まります。sage300 でも sage100 でもない場合は INVALID_VARIANT で止まります。variant が sage100 の場合、テストは直ちに ERP_ENDPOINTS_PENDING の結果を返し、リクエストは一切送信しません。これは今日の Sage 100 に対する正直な答えであり、他のフィールドの入力ミスではありません。variant が sage300 の場合、テストは他の 4 フィールドを確認し、いずれかが未入力なら MISSING_BASE_URL、MISSING_COMPANY、MISSING_USERNAME、MISSING_PASSWORD で止まります。その後、HTTP Basic（ユーザー名とパスワード）で認証し、12 秒の制限の中で {base}/v1.0/-/{company}/CS/CSCompanyProfile にある会社プロファイルを読み取ります。これは要求できる最も軽いメタデータです。200 の応答で合格となります。401 は INVALID_TOKEN、403 は MISSING_SCOPE、404 は NOT_FOUND として報告されます。各意味は下の FAQ をご覧ください。

Mapping / テンプレート選択#

この接続には設定する標準 Mapping も、選ぶテンプレートもありません。Sage 300 では、ビューが返す項目名は導入環境ごとの swagger に従うため、注文・在庫・顧客のマッピングは、データ接続を準備する際に自社サーバーの {baseUrl}/swagger で確認します。ここで推測したり入力したりするものではありません。Sage 100 では、SOAP リクエスト自体をまず WSDL で確認する必要があります。その導入ごとの確認が完了するまでは、この接続はテスト手順で行う接続確認にとどまります。推測したマッピングに合わせるために、Sage のビュー名や項目名を変更しないでください。

有効化#

Sage 300 の場合、テスト合格後に接続を有効化すると、確認済みの値で Integration に保存され、後で同じアカウントで同じ会社を再確認できます。有効化でデータフローが始まることはありません。この接続では注文、顧客、在庫はどちらの方向にも移動しません。統合アカウントのパスワードが後に変更された場合は、ここのパスワードフィールドを更新して再テストしてください。Sage 100 の場合、まだ有効化するものはありません。テスト結果がすでに状態を示しており、他のフィールドを変更しても変わりません。

よくある質問#

Sage 100 を使っていて、テストが ERP_ENDPOINTS_PENDING を返す

この結果は Sage 100 では想定内であり、入力した内容が原因ではありません。テストが variant を sage100 と読み取った時点で、リクエストを一切送信せずにこの結果を返します。Sage 100 の接続は SOAP 方式の eBusiness Web Services を通るため、そのリクエストはまず自社導入環境の WSDL で確認する必要があるからです。今日、どのアドレス、会社コード、ユーザー名、パスワードを入力しても、この結果は変わりません。

他のフィールドを繰り返し変更しないでください。それらは原因ではありません。確認するのは 1 つだけです。実際に Sage 300 を使っている場合は、経路が間違っていたため、variant を sage300 に変更して再テストしてください。本当に Sage 100 の場合は、サービスアドレス、会社コード、Web Services ユーザーを WSDL と一緒に準備しておき、Sage 100 の経路が開放されてからこの接続を完了してください。

テストが MISSING_VARIANT または INVALID_VARIANT で止まる

テストは他の何よりも先に variant を読みます。この 1 単語がテスト全体の経路を決めるためです。MISSING_VARIANT はフィールドが空であることを意味します。INVALID_VARIANT は、その中の単語が接続が受け付ける 2 つの単語のどちらでもないことを意味します。製品名を別の形式で書いたり、余分な単語やスペースを入れたりすると、どの経路にも進みません。

variant には正確に 1 単語だけを入力してください。Sage 300 は sage300、Sage 100 は sage100 です。スペースや余分な単語は入れません。保存して再テストしてください。

Sage 300 のテストが INVALID_TOKEN（401）で失敗する

Sage 300 Web API が HTTP Basic 認証を受け付けませんでした。ユーザー名とパスワードのペアが拒否されています。よくある原因は、入力・コピーのミス、控えた後にパスワードが変更されたこと、または別のアカウントのパスワードとの組み合わせです。

Sage 管理者から、その 1 つの統合アカウントのユーザー名とパスワードを再取得し、余分なスペースなしでコピーし、ユーザー名が username、パスワードが password に入っていることを確認して再テストしてください。アカウントのパスワードが Sage でリセットされた場合は、ここでも新しいものを使ってください。

Sage 300 のテストが MISSING_SCOPE（403）で失敗する

認証は機能しましたが、その Sage 300 ユーザーには Web API の利用が許可されていません。アドレスと会社には到達しています。不足しているのはアカウント自体の Web API 権限であるため、アドレスや会社コードを変更しても解決しません。

Sage 管理者に、そのユーザーが Sage 300 Web API を使えるよう許可してもらうか、すでに権限を持つ別の Sage 300 ユーザーを提供してもらってください。アカウントが変わる場合は、ここの username と password を更新して再テストしてください。

Sage 300 のテストが NOT_FOUND（404）で失敗する

テストが要求する会社プロファイルが、そのアドレス、その会社では見つかりませんでした。会社コードがそのサーバー上の会社の Org ID と一致していないか、base_url が Sage 300 Web API のルートを指していません。アドレスのわずかな違いでも同じ結果になります。

まずブラウザで {baseUrl}/swagger を開いてください。応答しない場合は応答するまで base_url を修正し、アドレスが Web API のルート（例：https://server/Sage300WebApi）で終わっていることを確認します。swagger が応答する場合は、company を Web API アドレスで使われる Org ID（例：SAMINC）と照合して、再テストしてください。

Sage 300 のテストが MISSING_BASE_URL、MISSING_COMPANY、MISSING_USERNAME、MISSING_PASSWORD で止まる

sage300 の経路では、結果に空になっているフィールドが正確に表示されます。テストは variant の後にこの 4 フィールドを確認し、すべて揃うまで何も送信しません。会社プロファイルの読取には、アドレス、会社、Basic 認証が揃っている必要があるためです。

結果に表示されたフィールド（サービスベース URL、会社コード、ユーザー名、パスワード）を、集めた値で入力し、保存して再テストしてください。不足の結果が出なくなるまで繰り返してください。

Sage 300 のテストは合格したが、注文・在庫・顧客が同期されない

これは値の入力ミスではなく、この接続の現在の範囲です。テストは、Basic 認証と会社プロファイルの読取が機能することだけを証明します。データの移動はまだこの接続の一部ではありません。Sage 300 のビューが返す項目名は導入環境ごとの swagger に従い、まず自社サーバーの {baseUrl}/swagger で確認する必要があるためです。

Sage 300 のテスト合格は、この会社について接続が確認済みであるとして扱い、注文・在庫・顧客の作業は当面 Sage 300 自体で続けてください。導入環境向けにデータ接続が準備される際は、この確認済みの値と swagger から開始します。認証情報を集め直す必要はありません。