カテゴリーおよびアイテム属性の割り当て階層
典型的な e-コマース・セラーは、数千を超えるアイテムを保持しています。 アイテム定義を維持するタスクは、特にアイテムのグループが同じ属性を共有する場合に、面倒な作業になります。
例えば、すべての衣料品は、ポリエステル、コットン、デニム、またはレザーと同じ属性、材料、および値を共有します。 ここで、簡単に説明できるように、衣服の製品をジーンズ・サブグループに絞り込みます。 部門で 1000 個のジーンズが使用可能な場合、カタログ・マネージャーは、タスクを完了するために、正確に 1000 個のアイテム割り当て属性を呼び出す必要があります。 更新中に、いくつかの項目が許容される場合があります。 多数の項目を処理している場合、更新タスクはユーザー・エラーまたはプログラマチック・エラーの影響を受けやすく、結果としてストア Web サイトで検出されない項目になります。 その結果、販売機会が失われることになります。
アイテム属性維持の労力を最小限に抑えるために、カタログ・サービスではアイテム・カテゴリーの概念が導入されています。 カテゴリーでは、ジーンズなどのすべての関連アイテムのグループ化が考慮されます。 デパートでは、店の子供や男の子のジーンズの下にジーンズがあるかもしれない。 このようなジーンズ・セットは、 KangarooFitというブランドに属している可能性があります。 カタログ・マネージャーは、アイテム・カテゴリーと同じ方法でこれをモデル化できます。
N レベルのグループ化を定義できるようにする強力な階層アーキテクチャーを採用しています。このアーキテクチャーでは、各サブグループが親レベル・グループから継承されます。 特に、カテゴリーの定義は以下のもので構成されます。categoryPath-カテゴリーの階層のパス。status-保留または公開。カテゴリーを考慮する必要があるかどうかを決定します。sequenceNo-複数のカテゴリーが適用可能な場合に競合状態の競合を許可します。Item attributes-カテゴリー・レベルでアイテム属性を割り当てます。
例えば、KangarooFitブランドがFlexoDenim,と呼ばれる独自の快適素材を使用しているとすると、カタログ・マネージャーは'/KangarooFitドメインに対して素材のアイテム属性を割り当てることができます。 このように、 /Department/KangarooFitの下にあるすべてのカテゴリー (例えば、
/Department/KangarooFit/boy/jeans および/Kangaroo/girl/jeans ) は、アイテム属性として Material=FlexoDenim を継承します。 このパターンに基づいて、カタログ・マネージャーは、カテゴリー・レベルで資材アイテム属性を設定する必要があります。 カテゴリーに割り当てられたすべてのアイテムは、アイテム属性を自動的に継承します。 これにより、アプリケーションに対する更新の数が、部門内のすべてのサイズの KangarooFit ジーンズに対して 1 に削減されます。
アイテム属性をカテゴリーに付加する前に、属性およびアイテム割り当て属性の概念と同様に、最初にそれらを作成する必要があります。 また、 assignedValues は、属性 API で定義されている allowedValues のリストと一致する必要があります。