ERP API entegrasyonunda mükerrer kayıtları azaltmak için her işleme kalıcı bir kimlik verilmeli, tekrar gelen istek aynı işlemle eşleştirilmeli ve sonuç belirsizken yeni kayıt açılmamalıdır. Bu rehber depo ve sipariş akışlarında kullanılabilecek tasarım kararlarını açıklar. Posingo depo çözümü gibi mevcut sistemlerle bağlantının kapsamı ayrıca doğrulanmalıdır.
Mükerrer kayıt hangi durumda oluşur?
Mükerrer kayıt, tek bir iş olayının sistemde birden fazla bağımsız işlem gibi tutulmasıdır. Siparişin iki kez açılması, aynı kabulün iki stok girişine dönüşmesi veya bir teslimatın tekrar kaydedilmesi buna örnektir. Sorun yalnız kullanıcının aynı düğmeye iki kez basmasından kaynaklanmaz.
İstek hedef sisteme ulaşmış ve kayıt oluşturulmuş olabilir; buna rağmen yanıt istemciye dönmeden bağlantı sonlanabilir. Gönderen sistem sonucu göremediği için isteği yeniden iletir. İkinci istek yeni işlem kabul edilirse aynı fiziksel olay iki kez işlenir. Bu nedenle “yanıt gelmedi” ile “işlem yapılmadı” aynı durum olarak ele alınmamalıdır. Aradaki belirsizlik uygulama tasarımında görünür olmalıdır.
Başka bir örnekte iki farklı cihaz aynı kaynak kaydı aynı anda gönderir. Kullanıcı arayüzünde düğmeyi pasifleştirmek bu yarışı tek başına engellemez. Birden fazla servis, zamanlanmış aktarım veya olay bildirimi de devrede olabilir. Koruma yalnız ekran üzerinde değil, kaydı kabul eden tarafta ve veri saklama katmanında birlikte düşünülür. Hangi katmanın hangi sorumluluğu taşıdığı yazılı sözleşmeye bağlanır.
İşlem kimliği ile ürün kimliği neden farklı olmalıdır?
Ürün kimliği neyin hareket ettiğini, işlem kimliği ise hangi olayın işlendiğini anlatır. Aynı ürün gün içinde birçok kez satılabilir veya kabul edilebilir. Bu nedenle ürün barkodunu tek başına tekrar kontrol anahtarı yapmak geçerli yeni hareketleri engelleyebilir.
Bir depo kabulünde kaynak belge numarası, belge satırı ve hareket türü birlikte iş olayını tanımlayabilir. Buna karşılık belgenin düzeltilmesi yeni bir sürüm veya ayrı düzeltme işlemi gerektirebilir. Kimlik modeli hazırlanırken işletmenin gerçek belge davranışı incelenir. Şirket ve şube sınırları da hesaba katılır; farklı şirketlerde aynı belge numarasının bulunması tek olay oldukları anlamına gelmez.
Kimlik mümkünse ilk gönderimden önce üretilir ve tekrar denemelerde korunur. Her ağ isteğinde yeni kimlik oluşturulursa hedef sistem önceki girişimle bağlantı kuramaz. Buna karşılık birbirinden bağımsız işlemlerde aynı kimliğin yeniden kullanılması da hatalıdır. Kimliğin ne zaman üretileceği, hangi kapsamda tekil olduğu ve ne kadar saklanacağı açıkça tanımlanmalıdır. Bu karar salt teknik rastgele sayı üretiminden daha geniştir.
Aynı işlemin yeniden gönderilmesi nasıl yönetilir?
İdempotent işleme yaklaşımı, aynı işlem anahtarıyla yinelenen isteğin ikinci bir iş etkisi oluşturmamasını hedefler. Hedef taraf önceki girişimi tanır ve tanımlanan sözleşmeye göre kayıtlı sonucu veya mevcut durumu döndürür. Davranış kullanılan API tarafından gerçekten desteklenmeli ve test edilmelidir.
Bu yaklaşımda anahtarın yanında gönderilen verinin tutarlılığı da önemlidir. Aynı kimlikle farklı miktar gönderilirse bunun tekrar mı yoksa değişiklik mi olduğu belirsizleşir. Güvenli tasarım bu farkı sessizce kabul etmek yerine açıklanabilir bir uyuşmazlık olarak ele alır. Değişiklik gerekiyorsa sürüm veya düzeltme akışı kullanılır. Kullanıcının ilk gönderimde üç, sonraki denemede dört adet girmesi ayrıca değerlendirilmelidir.
Her API aynı başlığı, saklama süresini veya hata davranışını kullanmaz. Bir hizmetin dokümanındaki yöntemi başka ERP’ye aynen taşımak uygun değildir. Hedef sistemin mevcut uç noktaları ve işlem sınırları incelenir. Resmî destek yoksa iki taraf arasında ek bir eşleştirme katmanı tasarlanabilir; fakat bunun da veri kaydıyla tutarlı çalışması gerekir. Bir bellekte tutulan geçici liste kalıcı güvence olarak sunulmamalıdır.
Eşzamanlı istekler için veri tarafında ne gerekir?
Aynı kimlikle iki istek aynı anda geldiğinde kontrol ve kayıt tek bir tutarlı işlem olarak ele alınmalıdır. Önce sorgulayıp ardından bağımsız kayıt açmak, arada başka isteğin de geçmesine izin verebilir. Veri tabanındaki uygun tekillik kuralları ve işlem sınırları bu nedenle önemlidir.
“Bu numara var mı?” sorusuna iki işçi aynı anda hayır yanıtı alabilir. İkisi de kayıt eklemeye çalıştığında uygulama mantığı tek başına yeterli olmayabilir. Seçilen veri yapısına uygun tekil anahtar ve hata yönetimi tasarlanır. İkinci istek reddedildiğinde kullanıcıya anlamsız sistem hatası göstermek yerine mevcut işlemin durumu bulunur. Böylece teknik koruma operasyonel olarak da anlaşılabilir hale gelir.
Tekillik anahtarını gereğinden geniş seçmek farklı şirketlerin veya farklı hareket türlerinin çakışmasına neden olabilir. Çok dar seçmek ise aynı olayın iki kimlikle geçmesine izin verebilir. Model örnek belgeler üzerinden sınanır. Veri tabanı kısıtı, uygulama doğrulaması ve API yanıtı aynı iş kuralını anlatmalıdır. Bir katmanda kabul edilen, diğerinde farklı yorumlanan kimlikler ileride zor bulunan tutarsızlıklar oluşturabilir.
Tekrar deneme ve hata türleri nasıl ayrılır?
Her hata yeniden gönderilerek çözülemez. Geçersiz ürün kodu veya yetkisiz işlem gibi durumlar veri ya da erişim düzeltmesi gerektirirken geçici bağlantı sorunlarında kontrollü tekrar değerlendirilebilir. Yeniden deneme kararı, hedef API’nin sözleşmesi ve mevcut işlem durumu üzerinden verilmelidir.
| Durum | Önce kontrol edilecek nokta | İşleme yaklaşımı |
|---|---|---|
| Yanıt alınamadı | Hedefte işlem oluşmuş mu? | Aynı kimlikle durum sorgusu / kontrollü tekrar |
| Veri doğrulama hatası | Ürün, birim ve zorunlu alanlar | Veriyi düzeltip tanımlı akışı uygulama |
| Yetki reddi | Hesap ve işlem izni | Yetkiyi inceleme; kör tekrar yapmama |
| Geçici hizmet sorunu | API tekrar politikası | Sınırlı ve aralıklı deneme |
| Aynı kimlik, farklı içerik | Kaynakta değişiklik var mı? | Uyuşmazlığı görünür yapma |
Tekrarların aralığı ve üst sınırı önceden belirlenir. Hızlı ve sınırsız yeniden gönderim, zaten zorlanan sistemi daha fazla meşgul edebilir. Deneme sayısı dolduğunda kayıt kaybolmamalı; yetkili inceleme listesine alınmalıdır. Liste üzerinde kaynak işlem, son yanıt, zaman ve yapılabilecek sonraki adım görünür olmalıdır. Personelin aynı belgeyi elle tekrar oluşturması gerekiyorsa bunun da önceki girişimle ilişkisi kontrol edilir.
İşlem durumları kullanıcıya nasıl gösterilmelidir?
Kullanıcı yalnız başarı veya hata görürse belirsiz işlemi tekrar başlatabilir. Hazırlandı, gönderildi, sonucu bekleniyor, doğrulandı ve inceleme gerekiyor gibi durumlar iş akışına göre tanımlanabilir. Her durumun hangi kanıtla değişeceği de açıklanmalıdır.
“Gönderildi” demek hedefte kayıt oluştuğunu kanıtlamaz. Benzer şekilde teknik başarı yanıtı, bütün bağlı işlerin tamamlandığı anlamına gelmeyebilir. Örneğin sipariş kabul edilmiş ama sonraki stok ayırma adımı henüz bitmemiş olabilir. Ekran işletmenin gerçekten ihtiyaç duyduğu iş durumunu göstermelidir. Teknik taşıma sonucu ile işin tamamlanması ayrı alanlarda izlenebilir; ikisi aynı etiket altında karıştırılmaz.
Belirsiz durumda sistem mevcut işlem kimliğiyle sorgu yapabiliyorsa önce bu yol kullanılır. Sorgu desteği yoksa hedef tarafla mutabakat yöntemi belirlenir. Operatöre “tekrar gönder” düğmesi sunmak kolaydır; fakat hangi durumda kullanılacağı tanımlanmazsa korumayı zayıflatır. Yetkili yeniden işleme, kaynağı ve gerekçesi görülen ayrı bir olay olarak kayda alınmalıdır.
Olay bildirimleri ve çift yönlü aktarım nasıl ele alınır?
Bir iş olayının bildirimi birden fazla kez ulaşabilir; tasarım tekrarları tanıyacak şekilde hazırlanmalıdır. Çift yönlü aktarımda ise iki sistemin aynı kaydı karşılıklı güncelleyerek döngü oluşturması önlenmelidir. Kaynak sistem, olay kimliği ve sürüm bilgisi burada birlikte değerlendirilir.
Örneğin depoda değişen teslimat durumu ERP’ye gider; ERP aynı değişikliği yeniden depo uygulamasına bildirebilir. Uygulama bunu yeni olay sanarsa zincir uzar. Hangi alanın hangi sistemde sahip olduğu ve gelen güncellemenin kaynağı belirlenir. Her sistemin her alanı aynı anda değiştirmesi yerine sorumluluk sınırları yazılır. Gerçek bir kullanıcı düzeltmesi ile aktarımın geri yansıması ayırt edilmelidir.
Bildirimlerin sırası da her zaman işin oluşma sırasıyla aynı olmayabilir. Daha eski sürüm geç gelirse yeni durumu geriye almamalıdır. Bunun nasıl çözüleceği kaydın anlamına bağlıdır; yalnız zaman damgasına bakmak bazı yapılarda yeterli olmaz. Sürüm ve izin verilen durum geçişleri örneklerle test edilir. Entegrasyon kapsamına bu istisnalar eklenmeden yalnız normal akışı gösteren demo yeterli kabul edilmez.
Mutabakat raporu hangi sorulara cevap vermelidir?
Mutabakat, kaynak ve hedef sistemde aynı işlemin beklenen karşılığının bulunup bulunmadığını inceler. Yalnız toplam kayıt sayısını karşılaştırmak tekil hata bulmak için yetersiz kalabilir. İşlem kimliği, satır, miktar ve durum gibi alanlar ihtiyaç kapsamında eşleştirilmelidir.
Bir sistemde on, diğerinde on kayıt olması iki tarafın uyumlu olduğunu kanıtlamaz. Bir kayıt eksikken başka biri iki kez işlenmiş olabilir. Bu nedenle toplamların yanında tekil eşleşmeler görülür. Zaman aralığı ve şirket kapsamı aynı tutulur. Henüz işlenmesi beklenen kayıtlar ile gerçekten kayıp görünen kayıtlar ayrılır; işlem gecikmesinden doğan geçici fark kalıcı veri kaybı diye raporlanmaz.
Mutabakat listesi düzeltme süreciyle tamamlanmalıdır. Kaydı kimin inceleyeceği, hangi kanıtla yeniden işleyeceği ve hangi durumda karşı kayıt açılacağı belirlenir. Eski kaydı silerek sayıları eşitlemek geçmişi anlaşılmaz hale getirir. Düzeltmeler gerekçesiyle izlenir. Uygulamaya özel bu akış, özel yazılım entegrasyonu görüşmesinde örnek belgelerle netleştirilebilir.
Pilot kabul testinde hangi senaryolar çalıştırılmalıdır?
Pilot, aynı isteğin tekrar gönderilmesi ve eşzamanlı ulaşması gibi zor durumları da kapsamalıdır. Beklenen sonuç testten önce yazılmalı, iki sistemin verisi birlikte incelenmelidir. Sadece ekrandaki başarı mesajına bakarak mükerrer kayıt koruması doğrulanmış sayılmaz.
| Test | Beklenen davranış | Kanıt |
|---|---|---|
| Aynı isteği iki kez gönderme | İkinci iş etkisi oluşmaz | Kaynak/hedef işlem eşleşmesi |
| İki eşzamanlı istek | Tek geçerli işlem | Kalıcı kayıtta tekillik |
| Yanıtın kaybolması | Sonuç sorgulanabilir | Kimlik ve hedef kayıt ilişkisi |
| Aynı kimlikte farklı miktar | Açık uyuşmazlık | Hata ve inceleme kaydı |
| Eski olayın geç ulaşması | Yeni durumu bozmaz | Sürüm ve durum geçmişi |
Test ortamında kullanılan örnek işlemlerin gerçek ticari kayıtlardan ayrılması gerekir. Hedef sistemin test desteği, erişim sınırları ve veri temizliği yöntemi belirlenir. Aynı senaryo birden fazla kez çalıştırıldığında sonuçların neden aynı veya farklı olduğu açıklanabilmelidir. Test raporuna kullanılan sürüm ve API uç noktası da yazılır. Sonraki değişikliklerde hangi kabul maddesinin yeniden çalıştırılacağı böylece bilinir.
Kayıtlar ve erişim bilgileri nasıl sınırlandırılmalıdır?
İnceleme kayıtları sorunu açıklayacak kadar bilgi içermeli, gereksiz hassas veriyi yaymamalıdır. İşlem kimliği, durum ve hata sınıfı çoğu teşhis için temel başlangıçtır. Parola, erişim anahtarı veya tüm müşteri verisi günlük dosyasına gelişigüzel yazılmamalıdır.
Hata kaydına tüm isteği olduğu gibi eklemek kolay görünür; fakat içinde kişisel bilgiler veya hizmet erişim bilgileri bulunabilir. Hangi alanların maskeleneceği önceden belirlenir. Destek ekibinin hangi kayıtlara erişeceği de rol bazında değerlendirilir. Örnek talep paylaşılırken gerçek kimlik bilgileri yerine güvenli test değerleri kullanılmalıdır. Saklama süresi ise işletmenin kendi veri yönetimi gereksinimleriyle belirlenir.
İşlem kimliği kullanıcı ekranında görülebilir; buna karşın bu kimlik tek başına yetki vermemelidir. Bir kaydın numarasını bilen kişinin başka şirketin verisine erişememesi gerekir. Bu nedenle tekrar kontrolü ile yetkilendirme birbirinin yerine geçmez. Entegrasyon tasarımında bağlantı güvenliği, şirket sınırı ve işlem tekrarları ayrı kabul maddeleri olarak ele alınmalıdır.
Devreye alma ve değişiklik yönetimi nasıl yapılır?
Entegrasyonun ilk sürümü kadar sonraki alan değişiklikleri de işlem kimliğini ve veri eşleşmesini etkileyebilir. Yeni sürüme geçerken bekleyen işlemlerin hangi kuralla tamamlanacağı belirlenmelidir. Eski ve yeni biçimin bir süre birlikte çalışması gerekiyorsa bu durum açıkça tasarlanır.
Örneğin belge numarası biçimi değiştiğinde geçmiş işlem anahtarlarını yeni yöntemle tekrar üretmek aynı olayı farklı gösterebilir. Bu nedenle kimlik üretim kuralı gelişigüzel değiştirilmez. Gerekirse sürüm bilgisi korunur ve eski kayıtların hangi yöntemle sorgulanacağı tanımlanır. Aktarım durdurulacaksa iş kuyruğundaki kayıtların kaybolmadığı görülür. Yeniden başlatma işlemi, eski olayları yeni ticari işlemler gibi üretmemelidir.
Devreye alma sonrasında hata türleri, bekleyen işlem yaşı ve mutabakat farkları izlenebilir. Hedef sayılar gerçek başlangıç ölçümünden sonra belirlenir; ölçülmeyen iyileştirme oranı yazılmaz. İşletmeye özel API bağlantısı, yalnız veri gönderme kodundan ibaret değildir. Süreç sahiplerinin anlayabildiği durumlar, tekrar yönetimi ve düzeltme akışı birlikte teslim edilmelidir.
Operasyon ekibi belirsiz kaydı nasıl incelemelidir?
İnceleme ekranı teknik hatayı göstermekle kalmamalı, personelin hangi iş olayına baktığını açıklamalıdır. Kaynak belge, hedef karşılığı ve son durum aynı bağlamda görülmelidir. Yetkili karar verilmeden belirsiz kayıt yeni bir işlem olarak açılmamalıdır.
Örneğin bir kabul belgesi için depo görevlisi stok girişinin yapıldığını düşünürken ERP sorumlusu aktarımın tamamlanmadığını görebilir. İki ekip farklı ekranlara baktığı için aynı işlem hakkında farklı karar verebilir. Ortak işlem kimliği bu konuşmayı belirli bir kayda bağlar. İnceleme notunda kimin hangi sistemde hangi kanıtı gördüğü yer alır. Böylece telefonla verilen sözlü onaylar tek bilgi kaynağı olmaz.
Elle düzeltme yetkisi az sayıda role verilebilir; hangi işlem türlerinin düzeltilebileceği ayrıca tanımlanır. Düzeltme sonrasında yeniden mutabakat yapılır ve eski belirsiz durum kapatılır. Teknik ekip yeni sürüm yayınladığında personelin kullandığı hata açıklamaları da güncellenir. İyi tasarlanmış bir entegrasyon, sorun yaşandığında ekibin kendi geçici yöntemlerini üretmesine ihtiyaç duymadan anlaşılır bir inceleme yolu sunar. Eğitim örneklerinde normal aktarımın yanında böyle bir belirsiz olayın tamamlanması da gösterilmelidir.
Sıkça Sorulan Sorular
İşlem kimliği ile sipariş numarası aynı şey midir?
Her zaman değildir. Sipariş numarası işletmenin belge kimliği olabilir; işlem kimliği belirli bir aktarım veya iş olayını tanımlar. Aynı siparişin oluşturma, düzeltme ve iptal olayları ayrı ele alınabilir. İlişki entegrasyon sözleşmesinde yazılmalıdır.
Zaman aşımından sonra istek hemen tekrar gönderilebilir mi?
Önce hedef API’nin sözleşmesi ve mevcut işlem durumu kontrol edilmelidir. Yanıtın gelmemesi kaydın oluşmadığını göstermez. Tekrar destekleniyorsa aynı işlem kimliği korunur; belirsiz durum için sorgu veya mutabakat yöntemi kullanılır.
Düğmeyi pasifleştirmek mükerrer kayıtları önler mi?
Kullanıcının art arda tıklamasını azaltabilir; ancak başka cihazları, servisleri veya eşzamanlı istekleri kapsamaz. Kalıcı koruma hedef kabul mantığı ve uygun veri tekillik kurallarıyla birlikte tasarlanır. Ekran önlemi bu yapının yalnız bir parçasıdır.
Bütün API’lerde aynı tekrar anahtarı kullanılabilir mi?
API’lerin desteklediği alan, saklama süresi ve hata davranışı farklıdır. Her bağlantı için güncel doküman ve gerçek test gerekir. Bir hizmette kullanılan başlığın başka sistemde aynı işlevi gördüğü varsayılmamalıdır.
Aynı ürünün ikinci satışı yanlışlıkla engellenir mi?
Tekrar kontrolü yalnız ürün barkoduna kurulursa böyle bir risk doğabilir. Kimlik iş olayını tanımlamalıdır. Farklı satışlar yeni işlemlerdir; aynı satışın ağ nedeniyle yeniden gönderilmesi ise önceki işlemle eşleşmelidir.
Mutabakat raporunda yalnız toplamları görmek yeterli mi?
Toplamların eşit olması tekil kayıtların eşleştiğini kanıtlamaz. Bir eksik kayıt başka bir tekrarın arkasında gizlenebilir. İşlem, satır, miktar ve durum gibi alanlar aynı kapsam ve zaman aralığında incelenmelidir.
Bu yöntem Posingo’da hazır bir özellik olarak var mı?
Bu yazı belirli bir ürünün API özelliğini ilan etmez; entegrasyon tasarım yaklaşımını açıklar. Kullanılacak sistemin uç noktaları ve desteklenen davranışı ayrıca doğrulanır. Gereken özel bağlantı kapsamı örnek iş akışı üzerinden belirlenir.
Karekod Yazılım entegrasyon kapsamını nasıl netleştirir?
Kaynak ve hedef sistemler, örnek belgeler, alan sahipliği, hata senaryoları ve kabul testleri birlikte değerlendirilir. Özel geliştirme ihtiyacı bu incelemeyle belirlenir. Mesai saatleri içinde uzaktan teknik görüşme için temsilî işlem örnekleri hazırlanabilir.
Mevcut iki sistem arasında tekrar eden kayıtları incelemek için Karekod Yazılım ile entegrasyon görüşmesi planlayın. Kaynak belge, işlem kimliği ve hedefte oluşan kayıt örneği üzerinden kapsam belirlenebilir.
İlgili rehberler
- Karekod entegrasyonlu özel yazılım
- Yazılım entegrasyonu kullanım alanları
- Mobil yazılım çözümleri
- Stok hareketlerinin kayıt düzeni
Naron Bilişim Teknolojileri San. ve Tic. A.Ş.
