Bir B2B SaaS platformunda ödenen siparişlerin faturalarını otomatikleştirmem gerekiyordu. Firmanın kullandığı e-fatura servisiyle çalışacaktım, ancak entegrasyon için kullanılabilir bir test hesabı yoktu. Yanlış bir denemenin gerçek bir belge oluşturabilmesi, geliştirme ve yayına alma kararlarını doğrudan etkiledi.
İlk hedefim yalnız API isteğinin başarılı olması değildi. Aynı iş yeniden çalıştığında ikinci bir müşteri, sipariş veya fatura oluşturmamasını da sağlamak gerekiyordu.
Faturayı sipariş durumuna değil olaya bağlamak
Başlangıçta siparişin ödendi durumuna geçmesini yeterli bir tetikleyici saydım. Ancak hizmet akışlarının içindeki ödemeler ve abonelik yenilemeleri aynı durum geçişinden geçmiyordu. Tek bir sipariş olayı bütün gelir akışlarını temsil etmiyordu.
Fatura kaydını faturalanacak olaya bağladım. Her olayın boş bırakılamayan benzersiz anahtarı var. Kuyruk işi bu kayıt üzerinden ilerliyor; tamamlanmış bir aşamayı yeniden çalıştırmak yerine kayıtlı sonucunu kullanıyor. Böylece yeniden deneme, iş akışının baştan tekrarlanması anlamına gelmiyor.
Sahte cevapların doğrulayamadığı sözleşme
Dokümana göre yazdığım test cevapları, canlı servisin bütün davranışlarını göstermedi. Müşteri tanımlamak için seçtiğim alan, API ile oluşturulan kayıtlarda beklediğim gibi dolmuyordu. Sipariş kalemleri de sahte cevaplarımdakinden farklı bir iç yapıda dönüyordu.
Bu fark, testin neyi kanıtladığını ayırmamı sağladı: uygulama benim hazırladığım cevabı işleyebiliyordu, ancak o cevabın gerçek servis sözleşmesini temsil ettiği henüz doğrulanmamıştı. Canlı cevapların biçimi görüldükten sonra kontrolleri ve test verilerini buna göre düzelttim.
Vergi ve indirimi ayrı sözleşmeler olarak okumak
İndirim hesabında yalnız sipariş toplamının tutması yeterli değildi. Servis, fiyatı ve indirimi farklı vergi esaslarıyla bekliyordu. İndirimsiz brüt tutarı doğrudan göndermek, API isteği kabul edilse bile matrahın yanlış oluşmasına neden olabilirdi.
Bu nedenle birim fiyat, indirim ve KDV hesabını servisin beklediği alanlara göre ayrı ayrı ele aldım. Doğrulama da yalnız HTTP cevabına dayanmadı; oluşturulan belgedeki matrah ve vergi tutarı ayrıca kontrol edildi.
Otomasyonu kontrollü açmak
Yayın akışını önce otomatik gönderim kapalı çalışacak biçimde kurdum. Platformda fatura kayıtları oluşabiliyor, ancak dış servise gönderim ayrıca açılıyor. İlk belge kontrol edilmeden bütün ödemelerin otomatik faturalanması gerekmiyor.
Bu yaklaşım test ortamının yerini tutmuyor. Uygulamanın tekrar güvenliğini, dış servisin veri sözleşmesini ve firmanın belge ayarlarını farklı doğrulamalar olarak ele almayı sağlıyor. Birinin doğru olması, diğerlerinin de doğru olduğu anlamına gelmiyor.