İçindekiler

Entegrasyonlar

Her bağlayıcı, bilinen bir türün yapılandırılmış bir örneğidir. Tek bir arayüzün arkasında, tek bir kuyrukla, tek bir yeniden deneme politikasıyla ve tek bir ölü mektup durumuyla çalışır.

Neden bu şekilde #

Bu pazardaki yerleşik entegrasyon yöntemi, karşı sistemin veritabanına doğrudan yazmaktır. Her entegrasyonun ayrı bir proje, her yükseltmenin ayrı bir risk olmasının sebebi budur. Rutix’te dış dünyaya açılan her şey aynı üç parçadan geçer: bir bağlayıcı kaydı, bir iş kuyruğu ve bir sağlık görünümü.

Sipariş yolunda hiçbir adım bir ERP’yi beklemez. İş kuyruğa alınır ve uç hemen döner: bir dağıtıcının akşamı, SAP yeniden başlatılıyor diye durmamalıdır.

Bağlayıcı türleri #

Tür	Desteklediği işlemler
SAP, Netsis, Logo, Mikro	order.push, invoice.push, payment.push, customer.pull, product.pull, stock.pull, price.pull
e-Fatura	invoice.send, invoice.status, invoice.cancel, taxpayer.check
WhatsApp	message.send, template.send, message.status
Ödeme ağ geçidi	link.create, link.status, refund.create
Lisans kontrolü	licence.check, licence.bulk_check

Bir bağlayıcı ayrıca yön (dışa, içe ya da çift yönlü), bir yapılandırma sözlüğü ve isteğe bağlı bir zamanlama aralığı taşır. Durumu devre dışı, aktif, bozulmuş ya da hatalı olabilir.

Simülasyon mutlu yolu değil, hata biçimlerini modelliyor #

Simülasyonun amacı ekranı doldurmak değil, entegratörün gerçekte karşılaşacağı durumları önceden karşılaştırmak. Cevaplar belirlenimci — aynı belge her seferinde aynı şekilde başarısız olur — çünkü rastgele başarısız olan bir sandık, hata yollarını test etmenin en kötü yoludur.

ERP gönderimi eşzamansızdır. Cevap “kuyruğa alındı” der ve kayıt zamanı boştur. Bir belgeyi kabul etmek onu kaydetmek değildir.
e-Fatura gönderimi mali numarasız döner. Durum “beklemede”, fiş numarası yok. Kabul sonradan, ret günler sonra gelir ve bunu ayrı bir durum sorgusu çözer. Gönderimi kabul sayan bir kod, burada “kesildi” görünüp GİB’de reddedilmiş faturalar üretir.
WhatsApp 24 saatlik oturum penceresini uygular. Pencerenin dışında yalnızca şablon mesaj gider.
Hatalar sınıflandırılır. Zaman aşımı ve kilitlenme yeniden denenir; kapanmış muhasebe dönemi ve eksik eşleme denenmez. Kapanmış bir dönemi beş kez denemek yalnızca onu düzeltecek insanı geciktirir.
Zorlanmış hata. Bağlayıcı yapılandırmasına bir hata kodu yazılabilir; bağlayıcı o kodla ve istenirse yeniden denenebilir olarak başarısız olur. Bu, hem testler hem de kendi hata yollarını kanıtlamak isteyen bir entegratör için var.

İşin yaşam döngüsü #

1
Kuyruğa alınır
İş, bağlayıcıdan kiracı, organizasyon birimi, tür ve yönü devralır; hemen sıraya girer. Uç 202 Accepted döner.
2
Çalıştırılır
Önce sonlanmış işler elenir: başarılı, ölü mektuba düşmüş ya da iptal edilmiş bir iş yeniden yürütülmez. Başarıyla tamamlanmış bir invoice.send işine ikinci kez basmak aynı faturayı ikinci kez göndermek olurdu — ve o düğme, destek mühendisinin çift tıkladığı bir düğmedir.
3
Desteklenmeyen işlem hemen elenir
Bağlayıcının yapamayacağı bir işlem, herhangi bir ağ denemesinden önce ölü mektuba düşer. Bu kontrol eskiden adaptörün içinde, simüle edilen ağ hatasının arkasındaydı: “bu bağlayıcı bunu yapamaz”, altı kere birinde “hız sınırı, yeniden denenecek” olarak dönüyordu — hiç var olmayacak bir işlem için.
4
Başarısızsa geri çekilerek yeniden denenir
Bekleme süresi 4 saniyeden başlayıp dörder katına çıkar (4 sn, 16 sn, 64 sn, 256 sn), tavanı bir saattir. Varsayılan deneme hakkı beştir. Yeniden denenemeyecek bir hata ya da hakların tükenmesi işi ölü mektuba düşürür.
5
Düzeltildikten sonra tekrar kuyruğa
Yeniden çalıştırma (replay) deneme sayacını sıfırlar ve işi yeniden sıraya koyar. Sorunun sebebi düzeltildikten sonra bir işi tekrar denemenin bilinçli yolu budur.

İş durumları: beklemede, çalışıyor, başarılı, yeniden denenecek, ölü mektup ve iptal. Kuyruğu boşaltma (drain) çağrısı, sırası gelmiş işleri en eskiden başlayarak çalıştırır — biriken bir yığın, birikme sırasıyla erisin.

Sağlık #

Sağlık ucu tek bir görünümde şunları döner: bağlayıcıların durumu ve üst üste kaç kez başarısız oldukları, duruma göre iş sayıları, ölü mektup sayısı, sağlıksız bağlayıcı sayısı ve en eski bekleyen işin yaşı.

Sondaki sayı, kuyruk derinliğinden daha iyi bir alarmdır: eriyen derin bir kuyruk sorun değildir, tıkanmış sığ bir kuyruk sorundur.

Bağlayıcının durumu da başarısızlıkla birlikte yükselir: üç ardışık hatada “bozulmuş”, beşte “hatalı”. İki kez başarısız olan bir bağlayıcının günü kötüdür; beş kez başarısız olanın birinin bakmasına ihtiyacı vardır.

Web kancaları #

Bir abonelik bir URL, dinlenecek olay türleri ve isteğe bağlı bir açıklama taşır. Olay türü tam eşleşme, * ya da bir_şey.* önek kalıbı olabilir.

Paylaşılan gizli anahtar sunucuda üretilir ve yalnızca bir kez gösterilir. Çağıran tarafın verdiği bir anahtar, genellikle başka bir yerden yeniden kullanılan bir anahtar olur.

Tablo dosyasından içe aktarma #

Bir dağıtıcı, iki başka sistemden geçmiş bir dosyada dört bin dükkânla gelir. İçe aktarma bu yüzden kendi katmanına sahip ve Türkçe verinin iki sessiz hata biçimine karşı özellikle korunuyor.

Sayılar. “45.000” değişmez kültürle okunduğunda kırk beştir. ₺45.000’lik bir risk limiti ₺45 olur, hiçbir hata çıkmaz, o dükkânın her siparişi risk askısına düşer. Sayılar hangi ayıracın son geldiğine bakılarak okunuyor. Gerçekten belirsiz olan “45,000” sessizce tahmin edilmiyor: satır her iki okumasıyla işaretleniyor ve kararı bir insan veriyor.
Başlıklar. Eşleştirme, Türkçedeki dört i’yi bilen bir katlamadan geçiyor. ş→s ve ğ→g de bilerek katlanıyor: dağıtıcılar bunları yıllar önce bozmuş sistemlerden dışa aktarıyor ve “MUSTERI KODU” ile “Müşteri Kodu” aynı sütun.
Kodlama. Türkçe Windows’ta Excel, CSV’yi Windows-1254 ile yazar. UTF-8 diye okununca “Şevket” “Þevket” olur ve bu isim veritabanına yazılıp müşterinin kendi faturasına basılır. Dosyalar önce katı biçimde UTF-8 denenip 1254’e düşülerek çözülüyor; tersi her zaman “başarılı olur”.

Deneme çalıştırması varsayılandır. Rapor, hangi satırın hangi alanı neyle değiştireceğini tek tek gösterir ve okunamayan tek bir satır dosyanın tamamını yazmaz. Yarım bir içe aktarım hiç yapmamaktan kötüdür, çünkü dağıtıcı hangi yarısının indiğini söyleyemez.

İşleme yetkisi ayrıdır: temsilcinin tezgâhta telefon numarası düzeltmek için taşıdığı yetki, dört bin risk limitini el terminalinden yeniden yazmanın yolu olmamalıdır.