Otomotiv DMS API Entegrasyon Rehberi

1. Bayi olayı ve doğru kaynak ile başlayın

"CRM'i DMS'e bağla" bir entegrasyon şartnamesi değildir. Yararlı bir gereksinim şöyle görünür: nitelikli bir potansiyel müşteri işleme dönüştüğünde müşteriyi ve aracı oluşturun veya eşleştirin, onayı ve potansiyel müşteri kökenini koruyun, DMS tanımlayıcılarını döndürün ve durum değişirse CRM'i bilgilendirin. Bu gereksinim bir olayı, kayıtları, sahipliği ve beklenen geri bildirimi tanımlar.

Her akış için her niteliğin yetkili sistemini yazın. CRM iletişim tercihlerinin ve potansiyel müşteri aşamasının sahibi olabilir. DMS rezerve edilmiş iş emrinin ve faturanın sahibi olabilir. OEM sistemi garanti yetkilendirmesinin sahibi olabilir. Araç telemetrisi, ayrı bir erişim düzenlemesi yoluyla bir OEM veri sahibinden gelebilir. İki sistem, öncelik olmadan aynı alanı düzenleyebiliyorsa entegrasyon tutarlılık yerine çakışma yaratır.

STAR'ın 2026 Automotive Retail Domain Model'i, bayi ve OEM operasyonları genelinde faydalı bir başvuru terminolojisi sunar. Parçalar, borç hesapları, muhasebe, bordro ve insan kaynakları gibi satış ve operasyon alanlarını, modern JSON ve OpenAPI hizalamasıyla birlikte kapsar. [1] STAR'ın Deal API'si ayrıca ortak müşteri, araç, fiyat, finans ve işlem durumu yapılarını tanımlar. [2] Bu standartlar belirsizliği azaltabilir; ancak Avrupa'ya özgü mali ve OEM'e özgü uzantılar yine de yönetişim gerektirir.

2. API, olay ve toplu işlem kalıplarını bilinçli olarak seçin

Senkron REST API'leri, bir araç getirme, kullanılabilirliği doğrulama veya rezervasyon oluşturma gibi kullanıcının anında yanıt gerektirdiği durumlarda uygundur. Asenkron olaylar veya web kancaları, bir aracın satışa hazır hâle gelmesi veya faturanın muhasebeleştirilmesi gibi durum değişikliklerine uygundur. Toplu dosyalar; yüksek hacimli değerleme, eski OEM raporlaması veya gerçek zamanlı aksiyonun gerekli olmadığı planlı muhasebe dışa aktarmaları için geçerliliğini korur.

En sağlam mimari genellikle her üçünü de birleştirir. Bir potansiyel müşteri senkron olarak oluşturulabilir, durum değişiklikleri olay olarak yayımlanabilir ve gece yapılan bir mutabakat kaçırılan veya eşleşmeyen kayıtları belirleyebilir. Gerçek zaman yanıt verebilirliği artırır; mutabakat tamlığı korur. Toplu işlemi belirsiz gecikme için bir bahane değil bir kontrol olarak ele alın.

Olay sözleşmelerini yinelenen iletim ve olağandışı sıralama için tasarlayın. Bir alıcı, idempotans anahtarı kullanarak aynı olayı birden fazla kez güvenle işlemelidir. Olayların benzersiz bir kimliğe, türe, zaman damgasına, üretene, şema sürümüne, korelasyon kimliğine ve iş nesnesi kimliğine ihtiyacı vardır. Ağ iletim sırasının iş sırasına eşit olduğunu varsaymaktan kaçının. Geç gelen bir olayın geçerli, eskimiş veya telafi edici olup olmadığına karar vermek için yeterli durum bilgisini saklayın.

3. Kimlik eşleştirme maliyetli parçalanmayı önler

Müşteri adları, e-posta adresleri ve tescil numaraları değişir. Şasi numaraları güçlü araç tanımlayıcılarıdır; ancak satın alma yolculuğunun erken aşamasında yanlış girilebilir veya mevcut olmayabilir. Bayi, şube, çalışan, OEM kampanyası ve iş emri kimlikleri sistemler arasında farklılık gösterebilir. Kanonik bir tanımlayıcı stratejisi hem dahili kimlikleri hem de kaynak sistem kimliklerini korumalıdır.

Eşleştirme kuralları açıklanabilir ve risk tabanlı olmalıdır. Tam bir şasi numarası araç eşleşmesi önermek için yeterli olabilir; ancak müşteri eşleştirmesi doğrulanmış iletişim verileri ile birlikte manuel inceleme gerektirebilir. Yalnızca iki kişi aynı ismi paylaştığı için asla birleştirme yapmayın. Birleştirmenin neden gerçekleştiğini, kimin onayladığını ve nasıl geri alınabileceğini kaydedin. Kökeni üzerine yazmak yerine bir çapraz referans tablosu tutun.

Aynı disiplin bağlantılı araç verilerini destekler. COVESA'nın Vehicle Signal Specification'ı araç sinyalleri için ortak bir hiyerarşi sunarken W3C VISS 2, VSS tabanlı bilgilere erişmek için bir JSON hizmeti tanımlar. [3] [4] Bu standartlar telemetri anlamını ve erişim kalıplarını tanımlar; bayi müşterilerini, iş emirlerini veya yasal izinleri değil. Bir DMS entegrasyon katmanı bu alanları açıkça birbirine bağlamalıdır.

4. Güvenlik, gizlilik ve yasal erişim ayrı kontrollerdir

Kimlik doğrulama, çağıran sistemi kanıtlar. Yetkilendirme, neler yapabileceğine karar verir. İş politikası, belirli aksiyona izin verilip verilmediğine karar verir. Gizlilik hukuku hukuka uygun bir amaç ve kişisel verilerin uygun şekilde işlenmesini gerektirir. Teknik olarak müşteri dışa aktarmaya izin veren bir jeton, her dışa aktarmanın hukuka uygun olduğunu kanıtlamaz.

Paylaşılan çalışan hesapları yerine iş yükü kimlikleri kullanın. Kapsamları uç nokta, şube, amaç ve aksiyona göre sınırlayın. Gizli anahtarları döndürün, kısa ömürlü kimlik bilgilerini tercih edin, web kancalarını imzalar ve tekrar oynatma kontrolleriyle koruyun ve ayrıcalıklı işlemleri günlüğe yazın. Üretim kişisel verilerini, uygun şekilde korunmadıkça ve gerekli olmadıkça test ortamlarının dışında tutun.

GDPR; amaçla sınırlama, veri minimizasyonu, tasarım gereği gizlilik ve riskle orantılı güvenlik gerektirir. [5] AB Veri Yasası kapsamındaki bağlantılı ürün erişimi başka bir katman ekler; ancak GDPR'nin yerini almaz. Onarım ve bakım bilgilerine erişim, 2018/858 sayılı Tüzük kapsamında da doğabilir. Entegrasyon ekipleri, "araç verisi"nin tek bir izin kategorisi olduğunu varsaymak yerine her besleme için yasal ve sözleşmesel dayanağı etiketlemelidir.

5. Sürümleme ve test bayi sürekliliğini korur

Geriye dönük uyumlu eklemeleri tercih edin. Anlamı, birimleri, zorunlu alanları veya numaralandırma değerlerini sessizce değiştirmeyin. Tüketicilerin etkilenip etkilenmediğini bilmesi için kullanımdan kaldırma pencerelerini ve kullanım verilerini yayımlayın. Sürüm politikası yalnızca URL'leri değil uç noktaları, olay şemalarını ve alan anlamını da kapsamalıdır.

Sözleşme testleri, üreticinin ve tüketicinin şema üzerinde anlaştığını doğrular. Senaryo testleri iş sonucunu doğrular. Eksik isteğe bağlı alanları, geçersiz kodları, yinelenen olayları, kısmi başarısızlıkları, hız sınırlarını, süresi dolmuş kimlik bilgilerini, saat farklarını, yeniden deneme fırtınalarını ve aşağı akış kesintilerini dahil edin. Yalnızca tekil örnekleri değil toplamları da mutabık kılın: kayıtları sayın, finansal değerleri toplayın, açık durumları karşılaştırın ve belgeleri örnekleyin.

Önlenebilir bir gizlilik riski yaratmadan temsili veri kullanın. Sentetik veriler; yinelenen müşteriler, çok markalı şubeler, sınır ötesi vergi durumları, iptal edilen işlemler, garanti işleri ve stok transferleri gibi gerçek karmaşıklığı içermelidir. Lansmandan önce kontrollü bir arıza çalıştırın ve operasyonların yinelenen fatura veya kaybolan onay olmadan kurtarılabildiğini gösterin.

6. Entegrasyonları açık hizmet göstergeleriyle işletin

Her üretim akışına bir iş sahibi ve bir teknik sahip atayın. İş sahibi kabul edilebilir gecikmeyi ve mutabakatı tanımlar. Teknik sahip izleme, olayları ve değişikliği yönetir. Nöbet yolu olmayan bir gösterge paneli yalnızca dekorasyondur. Entegrasyon sağlığını operasyonel KPI'larla birlikte inceleyin; çünkü teknik olarak başarılı bir çağrı yine de yanlış bir iş durumu üretebilir.

Omnetic'in konumu

Omnetic'in belgelenmiş iş akışları, CRM, Used Car Management, Sourcing, Price Report, Stock Report ve CarAudit genelinde ortak müşteri, araç ve işlem bağlamını kullanır. Ürün materyali ayrıca bir platform katmanı olarak API'lere, web kancalarına, dış kimliklere ve planlı dışa aktarmalara atıfta bulunur. Bu, iş akışı sürekliliğine ve içgörüleri aksiyonlara yönlendirmeye dayalı bir entegrasyon anlatısını destekler.

İncelenen materyal, eksiksiz bir kamuya açık API kataloğu, sınırlar, sürüm politikası, barındırma topolojisi veya uygunluk kanıtı sunmuyor. Bayiler bu ayrıntıları istemeli ve her pazarda gereken tam OEM, finans, muhasebe ve kanal arayüzlerini test etmelidir. Omnetic, yalnızca bir API etiketi açıklık ifade ettiği için değil, gösterilmiş iş akışı ve entegrasyon kanıtı hedef mimariye uyduğu için seçilmelidir.