Farklı Barkod Okuyucu Modellerinden Gelen Verileri Normalize Etme: Teknik Rehber

Problemin tanımı: Neden heterojen barkod okuyucu parkı sorun yaratır?

Farklı marka ve model barkod okuyucuları, aynı etiketin farklı temsilini üretirse ERP/izleme katmanında veri uyuşmazlıkları meydana gelir. Örneğin; bazı cihazlar QR içeriğini URL ile, bazıları sadece payload ile; bazıları başlık/sonlandırma karakteri ekler; bazıları seri numarası ön ekini eksik gönderir. Bu durumlar barkod takip sisteminizin doğruluğunu doğrudan etkiler ve operasyonel kararları yanıltır.

Uzun kuyruklu arama niyeti (bilgi amaçlı):

Bu makale, "farklı barkod okuyucu modellerinden gelen verileri normalize etme" arayışındaki teknik kişilere hitap ediyor: cihazlardan gelen verinin nasıl loglanacağı, hangi validasyon ve normalizasyon kurallarının uygulanacağı, ASP.NET Core ile hangi API modelinin tercih edilebileceği ve SQL Server tarafında hangi saklama desenlerinin uygun olduğu gibi somut adımlar içerir. Daha kapsamlı barkod ve depo çözüm altyapılarımız için barkod-depo hizmetlerimiz sayfasına göz atabilirsiniz.

Önce semptomları ve kaynakları izole edin

• Semptom örnekleri: aynı SKU için farklı formatlarda kayıt, artan duplicate kayıtlar, ERP'de başarısız eşleştirme, zaman damgası tutarsızlıkları.
• Kaynaklar: cihaz firmware farkı, konfigürasyon (prefix/suffix), karakter kodlaması (UTF-8 vs ANSI), symbology tercihleri (Code128 vs GS1), uygulama katmanı eklentileri (prefixer), ve operatör hataları.
• Başlangıç testi: aynı etiketi farklı cihazlarla tarayıp ham payload'u tutun. Ham verinin saklanması ileride hata ayıklama için kritik önemdedir.

Adım adım çözüm: veri hattını tasarlama

Amaç, cihazlardan gelen her tarama olayının tek bir, doğrulanmış ve normalize edilmiş temsilini üretmektir. Bu hattın ana bileşenleri:

• Device Registry (cihaz kaydı)
• Ingest API / Gateway (ASP.NET Core)
• Mesaj kuyruğu / buffer (RabbitMQ, Azure Service Bus veya IoT Hub)
• Normalization worker (stateless servis)
• Persisted Events (SQL Server - ham + normalize edilmiş)
• Idempotency & Deduplication katmanı

1) Cihaz kaydı ve meta veri

Her okuyucuya benzersiz bir DeviceId atayın ve özelliklerini kayıt altına alın: model, firmware, symbologies, default-encoding, prefix/suffix konfigürasyonu. Bu kayıt, normalize işlemlerinde hangi dönüşümlerin uygulanacağını belirlemek için kullanılır.

2) Ham veriyi saklayın

Ingest API'ye gelen her tarama için ilk önce raw_event (ham payload, DeviceId, readerTimestamp, gatewayTimestamp, signal metadata) saklanmalıdır. Bu hem adli hataları izlemek hem de ileride kural değişikliklerinde geçmiş veriyi yeniden işleyebilmek için gereklidir.

3) Mesajlaşma ve güvenlik

Doğrudan ERP'ye yazmak yerine bir kuyruk katmanı kullanın. Bu, burst taramalarda veri kaybını önler ve normalize işlemlerini asenkron yapmanızı sağlar. Her mesaj şu envelope formatını taşımalı:

• deviceId
• rawPayload (base64 veya escaped string)
• readerTimestamp (cihazın gönderdiği)
• gatewayTimestamp (API alım zamanı)
• correlationId (örn. %DeviceId%-%UnixMs%-%Seq%)

Normalizasyon kuralları: örnekler ve uygulanabilir kod mantığı

Normalizasyon, cihaz bazlı poliçelere göre kural tabanlı yapılmalıdır. Tipik adımlar:

• Encoding normalize: gelen ham veriyi UTF-8'e çevirin; başarısızsa log kaydını saklayın ve işaretleyin.
• Prefix/suffix strip: Device Registry'de tanımlı sabitleri kaldırın.
• Symbology-specific parsing: GS1 yapıları, AI'lar veya seri numarası formatları için regex tabanlı ayrıştırma uygulayın.
• Timestamp normalize: cihaz saat kayması varsa gatewayTimestamp kullanarak UTC'ye dönün veya cihaz saat sapmasını Device Registry'deki offset ile düzeltin.
• Checksum doğrulama: varsa CRC/GS1 check digit kontrolü yapın; hatalıysa kayıtla birlikte hata nedenini tutun.

ASP.NET Core worker örneği (mantık): gelen mesajı al -> cihaz özelliklerini oku -> uygulanacak rule set oluştur -> applyTransforms(rawPayload) -> parseFields -> produce normalized object.

SQL Server tarafı: saklama ve idempotency

Önerilen temel tablo yapısı (özet):

• Scans_Raw (Id, CorrelationId, DeviceId, RawPayload, ReaderTs, GatewayTs, ReceivedAt)
• Scans_Normalized (Id, CorrelationId, DeviceId, PayloadType, SKU, SerialNumber, Quantity, NormalizedTs, ValidationStatus)
• Device_Metadata (DeviceId, Model, Firmware, PrefixRules, Encoding, LastSeen)

Idempotency: CorrelationId ve DeviceId kombinasyonunu unique constraint olarak kullanın. Böylece çift gönderim durumunda yeniden işleme engellenir. Ayrıca, normalize sonrası ERP'ye gönderilecek paketler için transaction log ve ack mantığı kurun.

Çakışma ve çoğaltma (deduplication) stratejileri

Deduplication için iki seviye kullanın:

• Kesin deduplication: aynı CorrelationId veya aynı DeviceId+ReaderTs+Payload hash ise tekrar saymayın.
• Yaklaşık deduplication: kısa zaman aralığında aynı SKU+seri numarası birden fazla geldiyse operatöre uyarı gönderin; otomatik merge politikası uygulayın (ör. ilk eventi kabul et, sonralarını ignore et).

Uygulamalı senaryolar

Senaryo A: Bazı cihazlar seri numarasını "SN:12345" formatında, diğerleri sadece "12345" gönderebilir. Çözüm: normalization kuralı olarak regex 'SN[:\s]*' kaldır, kalan kısmı seri numarası alanına yaz.

Senaryo B: Eski model cihaz UTC yerine yerel saat gönderiyor. Çözüm: Device Registry'de timezone offset tutup readerTimestamp'ı UTC'ye çevir. Eğer offset bilinmiyorsa gatewayTimestamp'ı fallback olarak kullanın ve veri kalitesini "estimated_ts" ile işaretleyin.

Monitoring, metrik ve geribildirim

Başarılı bir normalizasyon hattı için metrikler izlenmelidir:

• Günlük ham tarama sayısı ve normalize oranı
• Validation fail oranı (checksum, regex mismatch)
• Dedup oranı
• Cihaz bazlı hata oranı (DeviceId'ye göre)

Bu metrikleri uygulama içi dashboard veya Prometheus/Grafana ile izleyin ve belirli eşiklerde (ör. validation fail > %1) operatöre veya bakım ekibine alarm gönderin.

Test planı ve kademeli devreye alma

Kademeli rollout önerisi:

1. Önce bir test cihaz grubu seçin ve ham payload logging'i etkinleştirin.
2. Normalization kurallarını devreye alın ama ERP'ye yazmayı kapalı tutun; sonuçları paralel raporlayın (shadow mode).
3. Shadow sonuçları ile ERP çıktısını karşılaştırın; uyuşmazlıkların nedenlerini inceleyin.
4. Kurallar yeterince güvenli görünüyorsa, küçük bir üretim bölümünde aktif modda açın ve izlemeye devam edin.

Pratik ipuçları ve yaygın tuzaklar

• Cihaz firmware güncellemelerini merkezileştirin; firmware değişimi normalizasyon gereksinimini değiştirebilir.
• Operatörlerin elle eklediği prefix/suffix kullanımını mümkün olduğunca sınırlayın ve barcode etiket standardı belirleyin.
• Ham veriyi asla silmeyin; future-proof rebuild için saklayın.
• Kuyruk gecikmelerini göz önüne alın: gerçek zamanlılık gerekirken kuyruk tamponu olabilecek en kısa sürede boşaltılmalı.

Nasıl ilerlemeli? Prototip önerisi

Hızlı bir prototip için şu bileşenleri kullanabilirsiniz:

• API & Worker: ASP.NET Core Web API (minimal endpoints) ve background worker.
• Kuyruk: Azure Service Bus veya RabbitMQ (az konfigürasyonla mesaj güvencesi sağlar).
• Depolama: SQL Server, ham ve normalize tablolarla.
• IoT cihazları için: cihaz konfigürasyon yönetimi ve Device Registry.

Eğer proje ölçeği büyürse event sourcing veya stream processing (Kafka, ksqlDB) gibi daha güçlü yaklaşımlar değerlendirilebilir.

İleri entegrasyon notları

ERP entegrasyonu sırasında, normalize edilmiş kayıtları ERP'nin beklediği formatta sağlamak gerekir. Bu genellikle bir API katmanı veya batch gönderi ile yapılır. Ayrıca, iki yönlü sync gereken durumlarda ERP'den gelen stok/seri güncellemelerini de normalize pipeline'ına almak veri tutarlılığını artırır.

Sonuç ve sonraki adımlar

Farklı barkod okuyucu modellerinden gelen verilerin neden olduğu sorunlar, düzenli cihaz envanteri, ham veri saklama, kural tabanlı normalizasyon ve idempotency ile büyük ölçüde azaltılabilir. Yukarıdaki adımları küçük bir pilotla test ederek kurumunuz için uygun kural setini oluşturabilirsiniz. Teknik bir değerlendirme veya pilot kurulum planı isterseniz iletişim kanalımızdan bize ulaşabilirsiniz.

Not: Bu rehber, gerçek operasyonel problemleri çözmek için tasarlanmıştır; kopya yapıştır çözüm sunmaktan çok, kurumunuza uyarlayabileceğiniz somut teknik adımlar içerir.