أنظمة بيانات المنتجات اللي فعلاً تشتغل: من الـ ERP للقناة

مشكلة بيانات المنتجات اللي ما حدا يحكي عنها

بيانات المنتجات تبان بسيطة بجدول بيانات. اسم، وصف، سعر، صورة. بعدين الواقع يضرب. عندك 50,000 منتج بـ 200 خاصية لكل واحد، بـ 12 لغة، من 3 أنظمة مصدر، موزعة على 5 قنوات إخراج، وجودة البيانات غير متسقة عبرها كلها.

المشكلة الحقيقية مو تخزين بيانات المنتج. أي قاعدة بيانات تسوي هالشي. المشكلة الحقيقية هي الـ pipeline: كيف البيانات تتدفق من الأنظمة المصدر عبر التعزيز لقنوات الإخراج، مع التحقق بكل مرحلة وصيغ مختلفة لكل وجهة.

صممنا أنظمة بيانات منتجات لمصنعين B2B بتصنيفات هرمية معقدة، ومحتوى متعدد اللغات، وتكامل ERP، وإخراج متعدد القنوات (ويب، بحث، سوق، تصدير). هالمقال يغطي أنماط الهندسة المعمارية. لتنفيذ PIM تحديداً، شوف دليل تنفيذ PIM. لأنماط workflow في Pimcore، شوف دليل Pimcore workflow.

الـ Pipeline: من المصدر للقناة

┌──────────────┐     ┌──────────────┐     ┌──────────────┐
│   المصادر     │     │   الماستر     │     │   القنوات     │
│               │     │               │     │               │
│  ERP/SAP     │────▶│  نظام PIM    │────▶│  الموقع       │
│  الموردين    │     │  (Pimcore,    │     │  فهرس البحث  │
│  جداول بيانات│     │   Akeneo)     │     │  السوق        │
│  إدخال يدوي │     │               │     │  طباعة/PDF    │
│              │     │  تعزيز       │     │  API الشركاء  │
│              │     │  تحقق        │     │  تغذية بيانات │
│              │     │  موافقة      │     │               │
└──────────────┘     └──────────────┘     └──────────────┘

طبقة المصدر

المنتجات تدخل النظام من مصادر متعددة. كل مصدر عنده جودة بيانات مختلفة، وصيغ مختلفة، وتكرار تحديث مختلف.

طبقة الاستيراد لازم تتعامل مع: ربط الحقول (المورد يسميه "item_name"، الـ ERP يسميه "MATNR")، تحويل البيانات (السعر من EUR لسنتات)، إزالة التكرار (نفس المنتج من مصدرين)، وحل التعارضات (أي مصدر يفوز لأي حقل).

هذي بالضبط المشكلة اللي يحلها Vendure Data Hub Plugin مع 9 extractors و61 transform operator وربط حقول قابل للتخصيص.

طبقة الماستر (PIM)

الـ PIM هو المصدر الوحيد للحقيقة لبيانات المنتج. كل حقل عنده قيمة رسمية وحدة. كل تغيير مسجل بالنسخ. كل منتج يمر بسير عمل تحريري قبل النشر.

مسؤوليات PIM الرئيسية:

• تعزيز البيانات: إضافة أوصاف وصور وترجمات ما تيجي من الـ ERP
• التصنيف: تعيين المنتجات لتصنيفات هرمية مع خصائص محددة النوع
• التحقق: التأكد إن الحقول المطلوبة معبأة قبل النشر
• سير العمل: مراجعة تحريرية وموافقة قبل ما البيانات توصل لقنوات الإخراج
• تتبع النسخ: تتبع كل تغيير، دعم تحرير المسودات بدون تأثير على البيانات المنشورة

طبقة القنوات

كل قناة إخراج تحتاج بيانات المنتج بصيغة مختلفة:

نفس بيانات المنتج، محولة بشكل مختلف لكل قناة. الـ PIM يخزن البيانات الرئيسية. طبقة التوزيع تحول وتوصل.

أنظمة التصنيف

المنتجات عندها خصائص. حذاء عنده مقاس ولون ومادة ونوع نعل. صنبور عنده معدل تدفق ونوع توصيل وتشطيب وشهادة. سيرفر عنده CPU وRAM وتخزين ووحدات rack.

الخصائص المسطحة مقابل Classification Store

الخصائص المسطحة (أعمدة على جدول المنتج) تشتغل للكتالوجات البسيطة مع منتجات موحدة. كل منتج عنده نفس الحقول.

Classification Stores (key-value ديناميكي مع مجموعات) تشتغل للكتالوجات المتنوعة حيث أنواع المنتجات المختلفة عندها خصائص مختلفة.

Classification Store:
├── مجموعة: الأبعاد
│   ├── Key: width (float, وحدة: mm)
│   ├── Key: height (float, وحدة: mm)
│   └── Key: depth (float, وحدة: mm)
├── مجموعة: تقنية
│   ├── Key: flow_rate (float, وحدة: l/min)
│   ├── Key: pressure (float, وحدة: bar)
│   └── Key: connection_type (select: 3/8", 1/2", 3/4")
├── مجموعة: الشهادات
│   ├── Key: ce_mark (boolean)
│   ├── Key: tuv (boolean)
│   └── Key: energy_label (select: A-G)

الـ Classification Stores تتوسع لآلاف الخصائص بدون تغييرات بالـ schema. خصائص جديدة هي تهيئة، مو migration. لكنها أصعب بالاستعلام (بحث key-value بدل وصول الأعمدة) وأصعب بالتحقق (الـ schema ديناميكي).

بـ Pimcore، الـ Classification Store يوفر هالقدرة جاهزة مع قيم محلية، وتنظيم بالمجموعات، وتكامل مع واجهة الإدارة.

إدارة المتغيرات

المنتجات مع متغيرات (مقاس، لون، تهيئة) هي المصدر الرئيسي لتعقيد البيانات.

هندسة المتغيرات

منتج (أب)
├── name: "Running Shoe Pro"
├── description: "..."
├── brand: "..."
├── images: [hero.jpg, detail.jpg]
│
├── متغير: مقاس 40، أسود
│   ├── sku: "RSP-40-BLK"
│   ├── price: 12900  (سنتات)
│   ├── stock: 15
│   └── ean: "4012345678901"
│
├── متغير: مقاس 40، أبيض
│   ├── sku: "RSP-40-WHT"
│   ├── price: 12900
│   ├── stock: 8
│   └── ean: "4012345678902"
│
└── متغير: مقاس 42، أسود
    ├── sku: "RSP-42-BLK"
    ├── price: 12900
    ├── stock: 0  (نفذ المخزون)
    └── ean: "4012345678903"

بيانات موروثة مقابل خاصة بالمتغير:

• موروثة (من الأب): الاسم، الوصف، العلامة التجارية، التصنيف، الصور المشتركة
• خاصة بالمتغير: SKU، السعر، المخزون، EAN، المقاس، اللون، صور خاصة بالمتغير

نموذج الوراثة يقلل التكرار. غير وصف المنتج مرة وحدة، يتحدث لكل المتغيرات. لكن التجاوزات الخاصة بالمتغير لازم تكون ممكنة (سعر مختلف حسب المقاس، صورة مختلفة حسب اللون).

الانفجار التوافقي

منتج بـ 5 مقاسات و8 ألوان عنده 40 متغير. أضف 3 مواد وصار عندك 120. أضف عرضين وصار عندك 240. أغلب هالتوليفات ما تتواجد فعلياً كمنتجات حقيقية.

الحلول:

• متغيرات صريحة فقط: أنشئ فقط التوليفات الموجودة فعلاً. بدون توليد تلقائي.
• مصفوفة التوفر: حدد أي توليفات صالحة. ولد تلقائياً فقط الصالحة.
• متغيرات افتراضية: احسب وقت الاستعلام من مجموعات الخصائص. ما تخزن سجلات فردية.

خط الأصول

صور المنتج، الرسومات التقنية، ملفات PDF، والنماذج ثلاثية الأبعاد تحتاج خطها الخاص.

رفع/استيراد
  │
  ├── تحقق الصيغة (النوع، الحجم، الدقة)
  ├── استخراج البيانات الوصفية (EXIF، الأبعاد)
  ├── توليد الصور المصغرة (أحجام متعددة)
  ├── توزيع CDN
  └── ربط بالمنتج/المتغير

تحديات الأصول

خصوصاً لـ Pimcore، وثقنا bug بالأداء حيث استعلامات أبعاد الأصول تسبب I/O على التخزين البعيد بكل عرض صفحة. الحل موضح بـ دليل ترقية Pimcore.

التوزيع متعدد القنوات

التوزيع المبني على الأحداث

لما منتج ينشر بالـ PIM، أحداث تفعل التوزيع لكل قناة:

// الـ PIM ينشر المنتج -> الأحداث تفعل تحديثات القنوات
eventBus.on('product.published', async (product) => {
    await Promise.allSettled([
        searchIndexer.index(product),           // تحديث البحث
        feedGenerator.queue(product),            // وضع بقائمة تغذيات السوق
        cacheInvalidator.invalidate(product.id), // إبطال كاش الموقع
        partnerApi.notify(product.id),           // إشعار أنظمة الشركاء
    ]);
});

كل محول قناة يحول البيانات الرئيسية لصيغة خاصة بالقناة:

// الموقع: بيانات كاملة مع حقول SEO
function toWebProduct(product: PimProduct): WebProduct {
    return {
        slug: product.slug,
        name: product.name,
        description: product.description,
        seoTitle: product.seoTitle || product.name,
        seoDescription: product.seoDescription || truncate(product.description, 160),
        images: product.images.map(img => ({
            url: cdn.getUrl(img, 'large'),
            alt: img.alt || product.name,
        })),
        variants: product.variants.filter(v => v.active),
        // ... بيانات المنتج الكاملة
    };
}

// تغذية السوق: صيغة خاصة بالمنصة
function toGoogleMerchantItem(product: PimProduct, variant: PimVariant): MerchantItem {
    return {
        id: variant.sku,
        title: `${product.name} - ${variant.size} ${variant.color}`,
        description: stripHtml(product.description),
        link: `https://shop.example.com/p/${product.slug}`,
        image_link: cdn.getUrl(product.images[0], 'large'),
        price: `${(variant.price / 100).toFixed(2)} EUR`,
        availability: variant.stock > 0 ? 'in_stock' : 'out_of_stock',
        brand: product.brand,
        gtin: variant.ean,
        condition: 'new',
    };
}

جودة البيانات

التحقق الآلي

interface ValidationRule {
    field: string;
    check: (value: any, product: Product) => boolean;
    message: string;
    severity: 'error' | 'warning';
}

const VALIDATION_RULES: ValidationRule[] = [
    { field: 'name', check: (v) => v && v.length > 3, message: 'الاسم لازم يكون 3 أحرف على الأقل', severity: 'error' },
    { field: 'description', check: (v) => v && v.length > 50, message: 'الوصف يفضل يكون 50 حرف على الأقل', severity: 'warning' },
    { field: 'images', check: (v) => v && v.length > 0, message: 'مطلوب صورة وحدة على الأقل', severity: 'error' },
    { field: 'price', check: (v) => v && v > 0, message: 'السعر لازم يكون موجب', severity: 'error' },
    { field: 'ean', check: (v) => !v || isValidEan(v), message: 'صيغة EAN غير صالحة', severity: 'error' },
    { field: 'categories', check: (v) => v && v.length > 0, message: 'مطلوب تصنيف واحد على الأقل', severity: 'error' },
];

شغل التحقق قبل النشر. امنع النشر عند الأخطاء. اعرض التحذيرات لكن اسمح بالنشر. تتبع نتائج جودة البيانات لكل منتج، لكل تصنيف، ولكل مورد.

الأخطاء الشائعة

1. ما في مصدر وحيد للحقيقة. إذا نفس بيانات المنتج موجودة بالـ ERP والـ PIM ونظام التجارة بدون ماستر واضح، التعارضات محتومة.

2. الـ ERP كـ PIM. أنظمة ERP تخزن بيانات تشغيلية (SKU، سعر، مخزون). ما تتعامل مع محتوى غني (أوصاف، صور، ترجمات). لا تحاول تخليها تسوي هالشي.

3. ما في ملكية للحقول. بدون قواعد واضحة أي مصدر يملك أي حقل، الاستيراد يكتب فوق التعزيز اليدوي. شوف دليل Pimcore workflow لنمط ملكية الحقول.

4. نفس الصيغة لكل القنوات. كل قناة تحتاج بيانات مختلفة. تغذية Google Merchant وAPI الموقع عندهم حقول وصيغ وتكرارات تحديث مختلفة.

5. ما في تحقق قبل النشر. المنتجات تنشر بصور ناقصة، أوصاف فاضية، أو EANs غير صالحة. التحقق الآلي يمنع هالشي.

6. تجاهل تعقيد المتغيرات. التوليد التلقائي لكل التوليفات الممكنة ينشئ آلاف المتغيرات الوهمية. أنشئ فقط التوليفات الحقيقية المتوفرة.

النقاط الرئيسية

• الـ pipeline هي الهندسة المعمارية. من المصدر للماستر للقناة. كل مرحلة عندها مسؤوليات مختلفة، صيغ بيانات مختلفة، ومتطلبات جودة مختلفة.

• الـ PIM هو المصدر الوحيد للحقيقة. مو الـ ERP، مو نظام التجارة، مو جدول البيانات. ماستر رسمي واحد مع تتبع النسخ وسير العمل.

• الـ Classification Stores تتعامل مع تنوع الخصائص. لما أنواع المنتجات المختلفة عندها خصائص مختلفة، key-value ديناميكي مع مجموعات يتوسع أفضل من أعمدة ثابتة.

• كل قناة تاخذ تحويلها الخاص. الموقع، البحث، السوق، الطباعة، وAPI الشركاء كلهم يحتاجون صيغ مختلفة من نفس البيانات الرئيسية.

• جودة البيانات نظام، مو خطوة. تحقق آلي، نتائج جودة، قواعد حظر عند النشر. مستمر، مو مرة وحدة.

نحن نصمم أنظمة بيانات المنتجات كجزء من ممارستنا بـ التجارة الإلكترونية وهندسة البيانات. إذا تحتاج مساعدة بهندسة PIM أو خطوط بيانات المنتجات، تواصل مع فريقنا أو اطلب عرض سعر.