פיתוח החלפת נתונים מותאם אישית ל-1C ול-1C-Bitrix

ה-CommerceML הסטנדרטי פותר 80% מהמשימות הטיפוסיות: מוצרים, מחירים, מלאי, הזמנות. אבל כשחברה מחזיקה 50,000 פריטים עם סדרות, מאפיינים ומספר מחירים, ההחלפה הסטנדרטית הופכת לבעיה. העברות נתונים נמשכות ימים, ובשגיאה הקטנה ביותר נוצרים כפילויות ופערים. החלפה מותאמת אישית מבטלת את המורכבויות הללו באמצעות מיפוי מדויק ועיבוד מקבילי. אנו מפתחים אינטגרציות סוהר: מבדיקת היתכנות ועד תמיכה בייצור. בואו נפרק מתי יש צורך בהחלפה מותאמת אישית, אילו ארכיטקטורות עובדות, וכיצד להימנע מטעויות נפוצות.

בניגוד ל-CommerceML, REST API מותאם אישית מעביר רק רשומות שהשתנו — זה מהיר פי 5 בריצה הראשונה. החלפה מונעת אירועים דרך webhook מספקת עדכניות בזמן אמת, לא פעם בשעה. ארכיטקטורה כזו מתאימה יותר לחנויות עם תעבורה גבוהה.

מתי יש צורך בהחלפה מותאמת אישית?

ההחלפה הסטנדרטית נשברת במצבים הבאים:

• תצורת 1C לא סטנדרטית ללא תמיכה ב-CommerceML (פתרונות ספציפיים לתעשייה, תצורות מותאמות אישית)
• העברת נתונים שאינם קיימים ב-CommerceML: בקשות, מכרזים, כרטיסי שירות
• דרישות זמן אמת: עדכון מלאי מיד עם השינוי ב-1C
• טרנספורמציה מורכבת של נתונים: נתונים ממספר ספריות 1C המשולבים לאובייקט Bitrix אחד
• אינטגרציה של מערכות מרובות: 1C + CRM + Bitrix דרך שער יחיד

דוגמה מהפרקטיקה: חברת ייצור העבירה ל-Bitrix לא רק מוצרים אלא גם מפרטים לרכיבים הקשורים לכל הזמנה. CommerceML לא יכול להעביר קינון רב-רמות; נאלצנו לתכנן חוזה JSON עם מערכים מקוננים.

אפשרויות ארכיטקטוניות להחלפה מותאמת אישית

אפשרות 1: שירותי HTTP של 1C (REST API)

תצורות מודרניות (UT 11.4+, ERP 2.5+, KA 2.5+) תומכות בפרסום שירותי HTTP. 1C מפורסם על שרת אינטרנט (Apache/nginx), ו-Bitrix ניגש לנקודות הקצה דרך REST.

class OneCApiClient { private string $baseUrl; private string $token; public function getProducts(array $filters = [], int $limit = 100, int $offset = 0): array { return $this->request('GET', '/hs/exchange/products', [ 'modified_since' => $filters['modified_since'] ?? null, 'limit' => $limit, 'offset' => $offset, ]); } public function createOrder(array $orderData): array { return $this->request('POST', '/hs/exchange/orders', $orderData); } public function updateOrderStatus(string $orderId, string $status): bool { $result = $this->request('PUT', "/hs/exchange/orders/{$orderId}/status", [ 'status' => $status, ]); return $result['success'] ?? false; } private function request(string $method, string $path, array $data = []): array { $ch = curl_init(); $url = $this->baseUrl . $path; if ($method === 'GET' && $data) { $url .= '?' . http_build_query($data); } curl_setopt_array($ch, [ CURLOPT_URL => $url, CURLOPT_RETURNTRANSFER => true, CURLOPT_HTTPHEADER => [ 'Authorization: Bearer ' . $this->token, 'Content-Type: application/json', ], CURLOPT_CUSTOMREQUEST => $method, ]); if ($method !== 'GET') { curl_setopt($ch, CURLOPT_POSTFIELDS, json_encode($data)); } $response = curl_exec($ch); $httpCode = curl_getinfo($ch, CURLINFO_HTTP_CODE); curl_close($ch); if ($httpCode !== 200 && $httpCode !== 201) { throw new \RuntimeException("1C API error: HTTP {$httpCode}. Response: {$response}"); } return json_decode($response, true); } } 

אפשרות 2: החלפה מונעת אירועים (webhooks מ-1C)

1C שולח בקשת HTTP ל-Bitrix כאשר נתונים משתנים. לשם כך, מתווספת בתצורת 1C הרשמה לאירועים (שינוי מלאי, שינוי סטטוס הזמנה) ובקשת HTTP בעת טריגר.

בצד Bitrix — נקודת קצה לקבלת אירועים:

// /local/api/1c/webhook.php $payload = json_decode(file_get_contents('php://input'), true); $eventType = $payload['event_type'] ?? ''; switch ($eventType) { case 'stock_changed': StockSyncHandler::handle($payload['products']); break; case 'order_status_changed': OrderStatusHandler::handle($payload['order_id'], $payload['status']); break; case 'price_changed': PriceSyncHandler::handle($payload['prices']); break; } http_response_code(200); echo json_encode(['ok' => true]); 

החלפה מונעת אירועים מספקת עדכניות נתונים בזמן אמת — ללא סקירה מתוזמנת. זה חשוב במיוחד לחנויות מקוונות עם תעבורה גבוהה.

טרנספורמציית נתונים

החלפה מותאמת אישית דורשת לוגיקת מיפוי מפורשת. מקרה מורכב טיפוסי: ב-1C, מוצר מאוחסן בשלוש ספריות מקושרות (מינוח, מאפיינים, סדרות), אבל ב-Bitrix הוא צריך להיות אלמנט אינפובלוק אחד עם הצעות מסחר.

class ProductTransformer { public function transform(array $oneCNomenclature): array { $product = [ 'NAME' => $oneCNomenclature['name'], 'CODE' => \CUtil::translit($oneCNomenclature['name'], 'ru'), 'XML_ID' => $oneCNomenclature['guid'], 'ACTIVE' => $oneCNomenclature['active'] ? 'Y' : 'N', 'DETAIL_TEXT' => $oneCNomenclature['description'], 'PROPERTY_ARTICLE' => $oneCNomenclature['article'], 'PROPERTY_BRAND' => $this->getBrandId($oneCNomenclature['manufacturer_guid']), ]; // Собираем торговые предложения из характеристик $offers = []; foreach ($oneCNomenclature['characteristics'] as $char) { $offers[] = [ 'XML_ID' => $char['guid'], 'NAME' => $oneCNomenclature['name'] . ' / ' . $char['value'], 'PROPERTY_COLOR' => $this->getColorId($char['color_guid']), 'PROPERTY_SIZE' => $char['size'], 'CATALOG_PRICE_1' => $char['price'], 'CATALOG_QUANTITY' => $char['stock'], ]; } $product['OFFERS'] = $offers; return $product; } } 

תורים לאספקה אמינה

החלפה סינכרונית ישירה נשברת כאשר אחת המערכות אינה זמינה. תכנית אמינה משתמשת בתור:

// При изменении заказа в Битрикс — добавить задачу в очередь \Bitrix\Main\EventManager::getInstance()->addEventHandler( 'sale', 'OnSaleOrderSaved', function(\Bitrix\Main\Event $event) { $order = $event->getParameter('ENTITY'); if ($order->isNew() || $order->getFields()->isChanged('STATUS_ID')) { // Добавить в очередь на передачу в 1С \MyProject\Queue\ExchangeQueue::push([ 'type' => 'order_sync', 'order_id' => $order->getId(), 'created_at' => time(), ]); } } ); 

עובד (worker) מעבד את התור ומנסה שוב כאשר 1C אינו זמין זמנית. אנו משתמשים בגישה זו בכל הפרויקטים — היא מבטיחה אספקה גם במהלך תקלות רשת.

כיצד להבטיח יציבות החלפה?

• גרסת API: class OneCApiClient { private string $baseUrl; private string $token; public function getProducts(array $filters = [], int $limit = 100, int $offset = 0): array { return $this->request('GET', '/hs/exchange/products', [ 'modified_since' => $filters['modified_since'] ?? null, 'limit' => $limit, 'offset' => $offset, ]); } public function createOrder(array $orderData): array { return $this->request('POST', '/hs/exchange/orders', $orderData); } public function updateOrderStatus(string $orderId, string $status): bool { $result = $this->request('PUT', "/hs/exchange/orders/{$orderId}/status", [ 'status' => $status, ]); return $result['success'] ?? false; } private function request(string $method, string $path, array $data = []): array { $ch = curl_init(); $url = $this->baseUrl . $path; if ($method === 'GET' && $data) { $url .= '?' . http_build_query($data); } curl_setopt_array($ch, [ CURLOPT_URL => $url, CURLOPT_RETURNTRANSFER => true, CURLOPT_HTTPHEADER => [ 'Authorization: Bearer ' . $this->token, 'Content-Type: application/json', ], CURLOPT_CUSTOMREQUEST => $method, ]); if ($method !== 'GET') { curl_setopt($ch, CURLOPT_POSTFIELDS, json_encode($data)); } $response = curl_exec($ch); $httpCode = curl_getinfo($ch, CURLINFO_HTTP_CODE); curl_close($ch); if ($httpCode !== 200 && $httpCode !== 201) { throw new \RuntimeException("1C API error: HTTP {$httpCode}. Response: {$response}"); } return json_decode($response, true); } } — עדכוני 1C אינם שוברים אינטגרציות עובדות.
• ניטור: התראות כאשר התור מפגר או זמן העיבוד חורג מהמגבלות.
• תיעוד החוזה: כל נקודת קצה, פורמט נתונים, קודי שגיאה.
• בדיקות סדירות בסביבת staging לפני עדכון תצורת 1C.

מה כלול בעבודה

• בדיקת תכנית ההחלפה הנוכחית (זיהוי צווארי בקבוק, שגיאות, כפילויות)
• עיצוב ארכיטקטורה: בחירת פרוטוקול (REST, webhook, תור), הסכמת חוזה
• פיתוח: כתיבת לקוח API, מטפלי אירועים, ממירים
• תיעוד: תיאורי נקודות קצה, פורמטים, הוראות פריסה
• בדיקות בסביבת בדיקה: כיסוי בדיקות לכל התרחישים
• השקה וניטור למשך שבועיים לאחר ההתחלה
• הדרכת צוות אחראי: כיצד להוסיף אובייקטים חדשים, לתעד שגיאות, להפעיל מחדש עיבוד

לוחות זמנים לפיתוח

צרו קשר להערכת הפרויקט שלכם — נבחר את הארכיטקטורה האופטימלית ונספק לוחות זמנים תוך יום. עם ניסיון של למעלה מ-10 שנים ועשרות אינטגרציות מוצלחות, אנו מספקים הערכות ריאליות ללא הפתעות. הזמינו בדיקת היתכנות חינם של ההחלפה הנוכחית שלכם.