Bursa'da Üretim Hattında Barkodla Sipariş Takibi: Pratik Teknik Rehber

Giriş: Hangi somut problemi çözeceğiz?

Bu yazı, Bursa'da orta ölçekli bir üretim işletmesinin üretim siparişlerini barkod ile izlemek ve bu verileri yerel ERP ile güvenli, izlenebilir biçimde entegre etmek isteyen teknik ekipler için yazıldı. Amaç, hangi mimarinin daha uygulanabilir olduğu, hangi veri modellerinin işinizi kolaylaştıracağı, ASP.NET Core + SQL Server üzerinde nasıl ölçeklenebilir bir çözüm kurgulanacağı konularında somut öneriler sunmaktır. Daha geniş özel yazılım kapasitelerimiz hakkında bilgi almak için özel yazılım hizmetlerimiz sayfasını inceleyebilirsiniz.

Problemin kısa tanımı ve gereksinimler

• Gerçek zamanlı veya near-real-time üretim adımı ve barkod tarama verisi toplanmalı.
• Veriler ERP'ye hem anlık (stok, üretim ilerleme) hem de işlem sonu raporlama için aktarılmalı.
• Kesintilere karşı veri kaybı önlenmeli; idempotent entegrasyon ve retry mekanizmaları olmalı.
• Basit istasyon donanımları (barkod okuyucu+PC/tablet) ile çalışmalı; ileride IoT sensör entegrasyonu kolay olmalı.
• Yazılım C#, ASP.NET Core ve SQL Server ile yönetilebilir, izlenebilir ve test edilebilir olmalı.

Mimari yaklaşım (özet)

Önerilen mimari, üç katmandan oluşur:

• Edge/İstasyon Katmanı: Barkod okuyucu -> lokal uygulama (Windows/Linux service veya PWA) -> istasyon cache/queue.
• API Katmanı: ASP.NET Core Web API; doğrulama, idempotency, hızlı enqueue ve basit sorgular.
• İşlem & Entegrasyon Katmanı: Arka plan worker (IHostedService), mesaj kuyruğu (RabbitMQ/Azure Service Bus) veya SQL tabanlı işlem kuyruğu, ERP'ye aktarım adaptörleri.

Bu yapı, network kesintileri olduğunda istasyonun lokal kuyruğa yazmasını ve bağlantı geri geldiğinde güvenli biçimde senkronize olmasını sağlar. IoT sensörler daha sonra aynı API'ye telemetri göndererek entegre olabilir.

Basit veri akışı

• Barkod tarandı -> istasyon uygulaması lokal cache/queue'ya yazdı (timestamp, deviceId, operatorId, scannedCode, stationId).
• API'ye POST -> API doğruladı -> veriyi fast-path ile DB'ye yazdı ve işlemi bir entegrasyon kuyruğuna koydu.
• Background worker kuyruğu tüketti -> ERP'ye push (REST/Message) -> ERP cevap verdi -> sonuç DB'de güncellendi, hata durumunda retry planlandı.

SQL Server veri modeli: temel tablolar

Aşağıdaki örnek tablo yapıları, veri bütünlüğü ve performans açısından başlangıç için uygundur. Veri türleri ve indekse göre küçük değişiklikler olabilir.

• ProductionOrder: OrderId (PK, bigint), ExternalOrderNo (nvarchar), ProductCode, Quantity, Status, CreatedAt.
• ProductionStation: StationId (PK, int), Name, Location, LastSeenAt.
• BarcodeScan: ScanId (PK, bigint identity), StationId (FK), OrderId (nullable), ScannedCode (nvarchar), OperatorId, ScanTime (datetime), Processed (bit), ErrorCode (nullable).
• IntegrationQueue: QueueId (PK, bigint), Payload (nvarchar(max) or varbinary), QueueType, RetryCount, NextRetryAt, Status, CreatedAt.
• StationStatus: StationId, CurrentOrderId, Step, UpdatedAt (kısa iyi durum görünümü için).

İndeksleme: BarcodeScan için (StationId, Processed, ScanTime) veya (ScannedCode) gibi sorgu desenlerinize uygun indeks ekleyin. Archive politikası ile eski taramaları ayrı arşiv tablosuna taşıyın.

ASP.NET Core API tasarım ilkeleri

• Endpoints RESTful olsun; örnek: POST /api/scans, GET /api/orders/{id}/status.
• Authentication: TLS zorunlu, JWT veya mTLS ile servis/cihaz kimlik doğrulaması. Operatör seansları için kısa ömürlü token kullanın.
• Response minimal: POST /api/scans -> 202 Accepted + location header ile enqueue sonucu dönün; arka planda işlenir.
• Idempotency: Her scan için client tarafında uniqueScanId gönderilsin. API aynı uniqueScanId geldiğinde tekrar işlem yapmasın.
• Validation & Sanitization: Barkod formatı, istasyon yetkisi, order eşleşmesi kontrolü.

Entegrasyon stratejileri ERP ile

ERP entegrasyonu için iki ana yaklaşım:

• Push modeli: Bizim sistemden ERP'ye REST/Queue ile anlık bildirim. Avantaj: Anlık veri; Dezavantaj: ERP API kullanılabilirliği gerektirir.
• Pull modeli: ERP belirli aralıklarla bizim entegrasyon kuyruğumuzu okur veya batch import yapar. Avantaj: ERP tarafı basit; Dezavantaj: gecikme olabilir.

Öneri: kritik operasyonlar için push + ack, raporlama için periyodik batch. Her entegrasyon mesajı için correlationId ve idempotent işaretleyici gönderin. Hatalı mesajlar için DLQ (dead-letter queue) mantığı kurun ve manuel müdahale prosedürü tanımlayın.

Hata yönetimi, retry ve idempotency

• Transient hatalar (network, timeout): exponential backoff ile retry (ör. 5 deneme: 1s, 5s, 30s, 2m, 10m).
• Kalıcı hatalar (validation, business rule): mesaj DLQ'ya düşsün ve operatör müdahalesi gereksinimini tetiklesin.
• Idempotency anahtarı: uniqueScanId veya (device+timestamp+seq) kombinasyonu ile veri tekrarını engelleyin.
• Monitoring: her retry ve DLQ olayını metrik olarak toplayın. Kibana/Prometheus gibi araçlarla alarm kurun.

Edge/İstasyon uygulaması ve IoT entegrasyonu

İstasyon uygulaması, basit bir Electron/PWA veya .NET Core worker olabilir. Gereksinimler:

• Offline çalışma: Lokal SQLite veya küçük bir queue kullanarak taramaları ön belleğe alın.
• Senaryo: ağ yok -> taramalar lokal kuyruğa yazılır; ağ geldiğinde arka plan senkronizasyonu yapar.
• Donanım entegrasyonu: barkod okuyucular genellikle HID veya serial üzerinden çalışır; device driver ve parse mantığı istasyonda ele alınmalı.
• IoT sensörler (örneğin üretim hattı sayıcıları) aynı API'ye telemetri gönderir; bu veriler StationStatus ve ProductionOrder ile ilişkilendirilebilir.

Performans ve ölçekleme ipuçları

• Yazma yoğun iş yükü için toplu insertler ve arka plan işleme kullanın. API hızlıca enqueue etsin, ağır DB işlemlerini worker'a devredin.
• EF Core yerine yoğun sorgu gerektiren yollar için Dapper veya prosedür kullanın.
• SQL Server için partitioning ve indeks bakımı planlayın; BarcodeScan tablosu hızla büyür.
• Load testing: Gerçek cihazlarla benzer frekansta yük testi yapın (ör: dakikada X scan). Bu testler deploy öncesi kritik.

Güvenlik, uyumluluk ve operasyonal iyi uygulamalar

• Veri şifreleme: TLS her yerde; hassas verileri DB'de maskeleme/şifreleme stratejisi.
• Audit log: kim, ne zaman hangi barkodu ne amaçla taradı; sorgulanabilir audit kayıtları tutun.
• Yetkilendirme: istasyon-operator seviyesinde RBAC, sadece ilgili siparişlere erişim verin.
• Yedekleme ve felaket kurtarma: SQL Server yedekleme prosedürleri ve test edilmiş restore planı olmalı.

PoC ve devreye alma aşamaları

1. Keşif (1-2 hafta): Mevcut ERP API'leri, cihazlar, ağ altyapısı ve hedef SLA'lar incelensin.
2. PoC (2-4 hafta): 1-2 istasyonda lokal cache + API + worker ile uçtan uca mini kurulum. Hedef: veri kaybı olmadan 1000 tarama/simüle edilmesi.
3. Pilot (4-8 hafta): 1 bant/hat üzerinde gerçek kullanıcılarla pilot. Operasyonel prosedür ve DLQ müdahalesi test edilir.
4. Rollout: Kademeli yayılım, eğitim, destek hattı ve operasyon rehberi ile tamamlanır. Detaylı iletişim için iletişim kanalımızı kullanabilirsiniz.

Sonuç ve hızlı kontrol listesi

Bu rehberde önerilen yaklaşım, orta ölçekli üretim tesislerinin barkod tabanlı sipariş takibini güvenilir, izlenebilir ve ERP ile entegre biçimde hayata geçirmesine yöneliktir. En önemli noktalar:

• Edge tarafında offline-first tasarım ve idempotency anahtarları.
• API katmanında hızlı enqueue, arka planda güvenli işleme.
• ERP entegrasyonunda push+batch karma stratejisi ve DLQ mekanizmaları.
• Performans için bulk işlemler, doğru indeksleme ve yük testi.

Eğer bu konuyu tesisiniz için somut bir projeye dönüştürmek isterseniz, mevcut altyapınızı ve iş akışlarınızı inceleyip bir PoC planı hazırlayabiliriz. Daha fazla bilgi ve proje talebi için lütfen özel yazılım hizmetlerimiz veya iletişim sayfasından bize ulaşın.

Kaynaklara kısa not

Bu rehberde bahsedilen yaklaşımlar sektör tecrübelerine ve genel mühendislik prensiplerine dayanır. Uygulama ayrıntıları, kullandığınız ERP, cihaz çeşitliliği ve operasyon gereksinimlerinize göre uyarlanmalıdır.