メインコンテンツにスキップ
バージョン: 1.x

アーキテクチャ

このページでは、開発者や上級ユーザー向けに WCPOS の技術アーキテクチャを説明します。

二部構成のシステム​

WCPOS は二部構成のシステムとして設計されています:

  1. PHP プラグイン: サーバー上でホストされる比較的小さなプラグインで、WooCommerce REST API を POS 固有のエンドポイントで拡張します。

  2. JavaScript クライアント: ブラウザー、デスクトップアプリ、または iOS/Android アプリでローカルに実行されます。

これは 2 つの別々の世界だと考えることができます:

  • PHP の世界 は、WordPress と WooCommerce を使ってデータ管理が行われる場所です。
  • JavaScript の世界 は、レジが必要とするストアデータのローカルでオフライン対応のコピーを保持し、高速な検索と即時の応答に最適化されています。
SVG not found

データ同期​

v1.10.0 で変更

v1.10.0 は、以前のレプリケーション層を専用の同期エンジンに置き換えます。以下の概要は短縮版です — 完全な説明は同期エンジンの仕組みにあります。

クライアントはローカルファーストです: すべての画面はデバイスのローカルデータベースを読み書きし、バックグラウンドの同期エンジンがそのデータベースと WooCommerce を収束させ続けます。エンジンはストア全体をやみくもにミラーするのではなく、画面が実際に必要とするものに基づいて動作します:

  • 変更検出: POS は軽量な変更ログを条件付きリクエストでポーリングします。アイドル状態のストアは、本文のない単一の 304 で応答します。
  • 宣言された需要: 画面が表示している内容を宣言し、エンジンはそれにリクエストが必要か、それともローカルですでに応答済みかを判断します。
  • シードとレーン: 範囲を限定したカタログシード、最近の注文のウィンドウ、アイドル時のメンテナンスレーンが、デバイスごとに調整できるスケジュールでローカルデータを埋めて検証します。
  • 永続的な書き込み: 売上や編集はローカルにキューされて WooCommerce にドレインされ、サーバーが拒否したものについては目に見える形で復旧できます。

同期される対象: 商品とバリエーション、カテゴリー／タグ／ブランド、顧客、税率、クーポン（Pro）、注文。決済ゲートウェイはチェックアウト時に取得されます。

アーキテクチャの長所と短所​

良い点 😊悪い点 😟
ローカルデータの検索は瞬時データの同期を保つのが難しい
キャッシュされたデータをオフラインで利用可能WooCommerce REST API による制約を受ける
デスクトップ、iOS、Android 向けにより優れたネイティブアプリを作成できるWordPress のテーマやフックで POS アプリをカスタマイズできない

ローカルデータベース​

クライアントは各デバイスのローカルデータベースにデータを保存します — Web アプリとデスクトップアプリは ワーカー内で動作する OPFS（Origin Private File System）ストレージ を使用し、モバイルアプリはファイルシステムエンジンを通じて同じオンディスク形式を使用します。すべてのプラットフォームが 1 つのストレージ形式と復旧ツールを共有します。これにより次のことが実現します:

  • 永続性: データはブラウザーの再起動やデバイスの再起動を経ても保持されます
  • パフォーマンス: ネットワーク遅延のない高速なクエリ — フィルタリング、並べ替え、ページネーションはストレージ層の内部で実行されるため、表示されるページ分の行だけが UI に届きます
  • オフライン閲覧: キャッシュされたデータはインターネットなしでも引き続きアクセスできます

サイト + ストア + レジ担当者の組み合わせごとに独自のローカルデータベースが割り当てられるため、1 台のデバイス上でレジ担当者やストアがローカルデータを共有することはありません。アップグレードでローカルデータベースがその場で移行されることはなく、アプリは常に権威あるコピーであるサーバーから再ダウンロードします。

チェックアウトのアーキテクチャ​

チェックアウトのプロセスは、WooCommerce の Order Pay ページを読み込む iframe/webview を使用します。このアプローチには次の利点があります:

  • 既存の決済ゲートウェイを活用: 任意の WooCommerce 決済ゲートウェイを POS で動作させられます
  • セキュリティの維持: 決済処理は WooCommerce の安全なインフラを通じて行われます
  • 複雑さの軽減: 決済ゲートウェイの統合を再実装する必要がありません

API 拡張​

PHP プラグインは、POS 固有の機能のための追加エンドポイントで WooCommerce REST API を拡張し、専用の wcpos/v1 と wcpos/v2 の名前空間の下に登録します — wcpos/v2 は v1.10.0 の同期サーフェスを担っており、これがアプリとプラグインのバージョンが足並みをそろえて出荷される理由です。入門については WooCommerce REST API を参照してください。

wcpos/v2 名前空間​

v1.10 は wcpos/v2 REST 名前空間を導入します。同期はここに存在し、以前は wcpos/v1 から提供されていた共有 POS サービスが、現在は wcpos/v2 から提供されます（wcpos/v1 のサービスルートは、その v2 実装へのパススルーです）。wcpos/v1 のルートは後方互換性のために引き続き登録されますが、凍結されています — 現在のクライアントはもうそれらを呼び出しません。

これらのエンドポイントと連携する場合に重要な点:

  • v2 のルートは常に登録されます。 古い woocommerce_pos_sync_api_enabled オプションは削除されました。API をオンまたはオフにするフラグはもうありません。
  • 公開エンドポイント。 wcpos/v2/site、wcpos/v2/ping、wcpos/v2/echo は公開されています（制約の厳しいホスト向けのトランスポートフォールバックを含む、機能と接続性のプローブに使用されます）。
  • 注文は UUID を主キーとします。 通信上の注文の同一性は UUID です。従来の wooOrderId フィールドは注文プルのエンベロープから廃止されました。注文メタデータは、単一の正規化処理を通じて通信上で型付けされます。
  • 明細の価格保存が文書化されています — サードパーティの同期との互換性のためです — POS の価格上書きがどのように保存されるかを参照してください。
  • POS の既定の商品並び順 は、現在 名前の昇順 です（以前は menu_order, id）。
  • 廃止された従来のメソッド。 いくつかの従来の API\Settings コントローラーのメソッド（例: get_general_settings()、update_access_settings()、get_general_endpoint_args()、remove_license_transient()）は削除されました。クラスのエイリアスは残りますが、それらのメソッドは残りません。
Pro もこの分割を反映します

WCPOS Pro は同じ V1/V2 の分割に従います — その共有サービスは wcpos/v2 に昇格され、注文データは v1 に凍結されたままです。ストアスコープの商品価格設定は v2 のレーンで動作し、レジのストアスコープが注文の書き込みに引き継がれるため、複数ストアの注文が適切なストアに対して価格と税を計算します。Proを参照してください。