Paraşüt entegrasyonlarında kodun zor kısmı yoktur; dokümantasyon açık ve arayüz düzenli. Projeyi geciktiren şey neredeyse her zaman aynı: erişim anahtarının açılması. Biz de takvimi buna göre kuruyoruz.
Paraşüt bulut tabanlı bir ön muhasebe ürünüdür; veritabanına doğrudan bağlanmak gündemde değildir, entegrasyon tamamen API üzerinden kurulur.
Resmi API dokümantasyonu Paraşüt’ün kendi GitHub organizasyonunda açık şekilde yayımlanır ve apidocs.parasut.com adresinden okunur. Bu, entegrasyon planını tahmine değil belgeye dayandırmayı mümkün kılar.
Erişim için gereken client_id ve client_secret bilgileri Paraşüt’ten talep edilmek zorundadır; resmi OpenAPI tanımı bunun için destek adresine başvuru notu içerir. Projenin ilk maddesi kod yazmak değil, bu anahtarın açılmasıdır.
Kimlik doğrulama OAuth 2.0 ile yapılır; erişim jetonu resmi spec’e göre iki saat geçerlidir ve yenileme jetonuyla tazelenir. Entegrasyon katmanı jeton yaşam döngüsünü kendisi yönetmelidir.
Resmi OpenAPI açıklaması “10 saniyede 10 istek” sınırını yayımlıyor; sınır aşımında dönen yanıt ve başlıklar ise belgelenmemiş. API’nin webhook yayınladığına dair doğrulanabilir bir kaynak da bulunmuyor. Bu yüzden entegrasyonu baştan hız sınırlama, yeniden deneme, kademeli bekleme ve zamanlanmış çekme ile kuruyoruz.
Önce iyi haber: dokümantasyon açık ve üreticinin kendi hesabında
Türkiye’deki muhasebe yazılımı entegrasyonlarında en sık karşılaşılan sorun, belgenin olmaması ya da yalnızca bayi kanalından dağıtılmasıdır. Paraşüt bu açıdan ayrışıyor: API dokümantasyonu üreticinin kendi GitHub organizasyonunda, parasutcom/api-doc deposunda “Documentation for Parasut API V4” başlığıyla açık şekilde duruyor. Yayın adresi apidocs.parasut.com; eski api.parasut.com/docs adresi de kalıcı yönlendirmeyle buraya gidiyor.
Bunun proje üzerindeki etkisi doğrudan. Teklif aşamasında hangi kaynakların mevcut olduğunu, hangi alanların zorunlu olduğunu ve hangi ilişkilerin kurulabildiğini okuyarak görebiliyoruz. Yani “bakalım çıkar mı” demeden kapsam çizebiliyoruz. Bizim gibi sabit fiyatla çalışan bir taraf için belgenin açık olması, riskin küçülmesi demek.
Adres kalıbı da düzenli: taban adres https://api.parasut.com/v4 üzerine kurulu ve resmi spec’e göre tüm uç noktalar /v4/{company_id} altında, yani şirket kimliğini içeren bir kalıpla ilerliyor. Yani çağrılar hesap bazlı bağlamlanıyor; birden fazla şirketi olan bir yapıda bu bağlamın yapılandırmadan gelmesi gerekiyor, koda gömülmemesi gerekiyor. Kaynak adları ve alan ayrıntıları proje başında güncel dokümantasyondan teyit ediliyor — açık dokümantasyonun tam da bu yüzden değeri var.
Ama açık dokümantasyon, entegrasyonun kolay olacağı anlamına gelmiyor; işin niteliğini değiştiriyor. Zor kısım artık “veri nerede” sorusu değil, “bu veriyi hangi sıklıkta, hangi sırayla ve hangi hata senaryosuna dayanıklı şekilde taşıyacağız” sorusu. Bu sayfanın geri kalanı büyük ölçüde o sorunun cevabı.
Projenin ilk maddesi kod değil: erişim anahtarının açılması
Paraşüt entegrasyonu planlarken ilk söylediğimiz cümle şu oluyor: takvimin başlangıç noktası geliştirmeye başladığımız gün değil, anahtarın elinize geçtiği gün. Çünkü erişim için gereken client_id ve client_secret bilgileri Paraşüt’ten talep edilmek zorunda; deneme hesabında da aynı yolun geçerli olup olmadığı üreticiden teyit edilir.
Bu, bizim çıkardığımız bir yorum değil. Paraşüt’ün resmi OpenAPI tanımında, istemci kimliği için destek@parasut.com adresine başvurulması gerektiğine dair bir not yer alıyor. Yani idari adım, üreticinin kendi belgesinde bir ön koşul olarak tanımlanmış durumda.
Bu ön koşulun yarattığı tipik sorun teknik değil, planlama kaynaklı. Firma entegrasyon kararını alıyor, geliştirici ekip hazır bekliyor, ama anahtar henüz talep edilmemiş oluyor. Sonuç: proje ilk haftasını bekleyerek geçiriyor ve bu gecikme haksız yere yazılım tarafına fatura ediliyor.
Bizim çalışma biçimimiz bu riski baştan kaldırıyor. Keşif görüşmesinin çıktısında iki ayrı iş listesi oluyor: bizim yapacaklarımız ve sizin yapacaklarınız. Anahtar talebi ikinci listenin ilk satırı ve takvim o satırın tamamlanmasına bağlanıyor. Anahtar gelmeden başlayabileceğimiz işler — veri modeli çıkarımı, eşleme tablosu tasarımı, kuyruk ve hata akışı altyapısı — paralel yürüyor, ama canlı bağlantı gerektiren hiçbir kalemi taahhüt takvimine yazmıyoruz.
OAuth 2.0: jeton yaşam döngüsü entegrasyonun sorumluluğunda
Paraşüt tarafında kimlik doğrulama OAuth 2.0 ile yapılıyor. Jeton, https://api.parasut.com/oauth/token ucundan alınıyor ve istek gövdesinde izin türü, istemci kimliği, istemci gizli anahtarı, kullanıcı adı ve şifre taşınıyor. Alınan erişim jetonu sonraki çağrılarda yetkilendirme başlığında taşıyıcı jeton olarak gönderiliyor. Erişim jetonu resmi spec’e göre iki saat geçerli; süresi dolduğunda yenileme jetonuyla tazeleniyor.
Bu modelin mimari sonucu, masaüstü ürünlerdeki “her istekte kimlik bilgisi taşı” yaklaşımından farklı: kimlik bilgileri tek bir yerde, jeton değişimi tek bir yerde olmalı ve tüm çağrılar bu ortak katmandan geçmeli. Her servis çağrısının kendi jetonunu almaya çalıştığı bir kurgu hem gereksiz istek üretir hem de yarış durumları yaratır.
Bir de eskime sorunu var. Süresi dolmuş jetonla yapılan çağrı reddedilir; entegrasyon bunu bir iş hatası sanıp kaydı başarısız işaretlerse, ortada aslında var olmayan bir veri kaybı görünür. Bu yüzden jeton eskimesini iş hatasından ayırıp otomatik tazeleme ve tek seferlik yeniden deneme ile ele alıyoruz.
Gizli anahtarın saklanması da bu bölümün bir parçası. İstemci gizli anahtarı ve hesap şifresi hiçbir koşulda kod deposuna, yapılandırma dosyasına düz metin olarak ya da istemci tarafına yazılmaz; sunucu tarafında, erişimi sınırlı bir sır yönetimi katmanında tutulur. Bu, tercih değil asgari koşul.
Paraşüt tarafında kimlik doğrulama ve bağlam bilgileri. Alan adları ve yol kalıbı proje başında güncel dokümantasyondan teyit edilir; aşağıdaki tablo tasarım kararlarını göstermek içindir.
Bilgi
Nerede kullanılır
Entegrasyona etkisi
client_id / client_secret
Jeton alma isteğinde
Üreticiden talep edilir; proje takviminin başlangıç koşuludur
Kullanıcı adı ve şifre
Jeton alma isteğinde
Sır yönetimi katmanında tutulur, koda ve istemciye yazılmaz
Erişim jetonu
Her API çağrısının yetkilendirme başlığında
Resmi spec’e göre iki saat geçerlidir; tek merkezden yönetilir, çağrı başına alınmaz
Yenileme jetonu
Erişim jetonu süresi dolduğunda
Tazeleme otomatik olur; eskime iş hatasıyla karıştırılmaz
Şirket bağlamı
Kaynak yollarında
Yapılandırmadan gelir; çok şirketli yapıda kod değişikliği gerekmez
İstek limiti yayımlanmış, aşım davranışı yayımlanmamış — ikisi de tasarım girdisi
Bazı ürünlerde istek limitleri aşım davranışıyla birlikte rakam rakam yayımlanır; entegrasyonu ona göre kurarsınız, sınırı da sınırı aştığınızda ne olacağını da bilirsiniz. Paraşüt tarafında tablo yarım: resmi OpenAPI (swagger) açıklaması “10 saniyede 10 istek” sınırını yayımlıyor, ancak sınır aşıldığında dönen yanıt ve başlıklar belgelenmemiş — açıkça tanımlanmış bir aşım davranışı veya kalan hakkı bildiren bir yanıt başlığı bulamadık. Bu yüzden bu sayfada üreticinin yazdığından fazlasını yazmıyoruz — belgelenmemiş bir davranışı uydurmak, bu sayfanın tüm değerini yok eder.
Sınırı bilinen ama aşım davranışı bilinmeyen bir yüzeyle çalışmanın doğru karşılığı temkinli mühendisliktir. Çağrı katmanını baştan bu sınırın altında kalacak şekilde hızlandırıyor, üstüne yeniden deneme ve kademeli bekleme mantığı koyuyoruz: bir çağrı reddedildiğinde hemen tekrar denemiyoruz, bekleme süresini kademeli olarak artırıyor ve tekrar denemeleri rastgele bir gecikmeyle dağıtıyoruz. Böylece karşı taraf yoğunsa onu daha da zorlamıyoruz; boşluk açıldığında ise akış kendiliğinden toparlanıyor.
Aynı mantığın ikinci ayağı hız değil, hacim tarafında. Toplu aktarımları tek seferde değil, kontrollü partiler halinde gönderiyoruz; partiler arasında nefes payı bırakıyoruz ve toplu işleri mesai dışı saatlere yayabiliyoruz. Bir ilk yükleme sırasında binlerce kaydı art arda göndermek, aşım davranışı belgelenmemiş bir yüzeyde alınacak en gereksiz risk.
Üçüncü ayak görünürlük. Başarısız çağrılar sessizce kaybolmuyor: sebebiyle birlikte kaydediliyor, listeleniyor ve yeniden denenebiliyor. Sessiz başarısızlık, entegrasyon projelerindeki en sinsi sorundur — özellikle karşı tarafın aşım davranışını belgeden bilmediğiniz durumlarda.
Senkronizasyonu neden zamanlanmış çekme ile kuruyoruz
Entegrasyon planlarken sorulan ilk sorulardan biri “Paraşüt bize haber verir mi” oluyor. Dürüst cevap şu: Paraşüt API’sinin webhook yayınladığına dair doğrulanabilir bir kaynak bulunmuyor. Ortada karışıklık yaratan bir durum var — Paraşüt’ün e-Ticaret tarafında pazaryeri bildirimlerinin tüketilmesine dair kılavuzlar mevcut. Ama bir ürünün başka sistemlerin bildirimlerini alıyor olması, kendi API’sinin dışarıya bildirim yayınladığı anlamına gelmez. Bu ikisini karıştırmak, temeli olmayan bir mimari üzerine proje kurmaya yol açar.
Bu yüzden senkronizasyonu zamanlanmış çekme ile kurguluyoruz ve bunu bir eksiklik gidermesi olarak değil, açık bir tasarım tercihi olarak yazıyoruz. Belirlenen aralıklarla, son çalışma anından beri değişenleri hedefleyen dar sorgularla veri çekiliyor; her turun nereden devam edeceği kalıcı olarak saklanıyor, böylece bir tur atlansa bile veri kaybı olmuyor.
Zamanlanmış çekmenin iki klasik tuzağı var ve ikisini de baştan kapatıyoruz. Birincisi mükerrer işleme: aynı kayıt iki turda birden yakalandığında ikinci kez işlenmemeli. Bunu kayıt kimliği üzerinden kurulan bir işlenmişlik kontrolüyle çözüyoruz. İkincisi ise turların üst üste binmesi: bir tur uzun sürdüğünde bir sonraki tur başlarsa aynı veri iki akışta birden işlenir. Bunu tek çalışan kilidiyle engelliyoruz.
Sıklık ayarı ise iş ihtiyacına göre belirleniyor. Fatura tarafında dakikalar mertebesinde bir gecikme çoğu firma için sorun değil; stok ve sipariş tarafında beklenti daha sıkı olabiliyor. Bu kararı keşifte birlikte veriyoruz, çünkü sıklık arttıkça hem yük hem de hata yüzeyi büyüyor.
Okuma ve yazma: risk veritabanında değil, mükerrer kayıtta
Masaüstü muhasebe ürünlerinde okuma-yazma tartışması “veritabanına dokunalım mı” ekseninde döner. Paraşüt bulutta çalıştığı için o tartışma burada yok; her iki iş de aynı API üzerinden yapılıyor. Ama risk ortadan kalkmıyor, sadece yer değiştiriyor: ön muhasebede en pahalı hata, bozulan bir tablo değil, iki kez oluşan bir fatura.
Okuma — sayfalama ve tutarlılık
Okuma tarafında kayıt bozma riski yok; dikkat edilmesi gereken şey verinin eksiksiz ve tutarlı alınması.
Büyük listeler tek seferde değil sayfalanarak alınır; sayfa sınırı ve sıralama alanı açıkça belirlenir, varsayılana güvenilmez
Sayfalama sırasında yeni kayıt eklenirse kayma oluşabilir — bu yüzden sayfalamayı değişmez bir sıralama alanı üzerine kurarız
Şirket bağlamı yapılandırmadan gelir; çok şirketli hesaplarda yanlış bağlamla çekilen veri hata vermez, sessizce yanlış rapor üretir
Raporlama ihtiyacı sürekliyse veriyi her seferinde API’den çekmek yerine, sizin tarafınızda tutulan ve zamanlanmış çekme turlarıyla güncellenen yerel bir kopya kurmak hem paneli hızlandırır hem çağrı hacmini düşürür
Yazma — mükerrer kayıt en büyük tehdit
Yazma tarafında asıl tehlike başarısız istek değil, sonucu belirsiz kalan istektir. Çağrı gönderilmiş, ağ kesilmiş, yanıt alınamamış olabilir. Bu durumda kayıt oluştu mu oluşmadı mı bilinmez. Körlemesine tekrar denemek, muhasebe tarafında aynı faturanın iki kez oluşması anlamına gelir — ve bunu temizlemek, entegrasyondan kazanılan tüm zamandan daha pahalıya mal olur.
Bu yüzden her yazma işlemini idempotent kurguluyoruz: kendi tarafımızdaki kaydın benzersiz bir karşılığını tutuyor, Paraşüt tarafındaki kimliği geri yazıyor ve tekrar denemeden önce kaydın gerçekten oluşup oluşmadığını kontrol ediyoruz. Yanıtı belirsiz kalan istekler otomatik olarak “doğrula, sonra karar ver” akışına giriyor.
İkinci disiplin: eşleme tablosu. Cari, ürün ve birim eşleşmeleri kodda gömülü değil, yönetilebilir bir tabloda tutuluyor. Yeni bir ürün ya da cari eklendiğinde geliştirici çağırmak gerekmiyor. Bu, entegrasyon bakımının en büyük gizli maliyet kalemini baştan ortadan kaldırıyor.
Üçüncüsü: silme yetkisi. Silme akışlarını mümkün olduğunca entegrasyon dışında bırakıyoruz. İptal ve düzeltme işlemlerini, ürünün kendi mantığına uygun şekilde güncelleme üzerinden kurguluyoruz — yanlış çalışan bir döngünün geri alınamaz sonuç üretmesini engellemenin en ucuz yolu budur.
Sürüm yükseltmesi: karar sizde değil ve bu iyi bir şey
Masaüstü muhasebe programlarında sürüm yükseltmesi entegrasyonun klasik kâbusudur: tarih seçilir, yedek alınır, gece çalışılır ve bir sabah entegrasyon çalışmayı bırakır. Bulut ürünlerde bu ritüel yok. Paraşüt tek bir sürüm olarak çalışır; güncelleme üreticinin takvimine göre gelir ve müşteri bunu onaylamaz.
Bu farkın entegrasyon tarafındaki karşılığı çoğunlukla avantaj. Her müşteride farklı bir sürümle uğraşmıyoruz; “sizde V16 mı V17 mi” sorusu gündeme gelmiyor. Şema takibi, veritabanı nesnelerinin bozulması, yükseltme sonrası yeniden eşleme gibi kalemler tamamen listeden düşüyor. Arayüzün kendisi de sürümlü bir yüzey olarak tanımlanmış — adres kalıbının içindeki sürüm işareti, büyük değişikliklerin yönetilen bir şekilde geleceğini gösteriyor.
Sorumluluk tarafı şu: yükseltme zamanını siz seçmediğiniz için entegrasyonun dayanıklı olması gerekiyor. Bilmediği bir alan geldiğinde patlamaması, beklediği bir alan boş geldiğinde kaydı sessizce yok saymaması, başarısız çağrıları kuyrukta tutup yeniden denemesi gerekiyor. Bunlar sonradan eklenen özellikler değil, ilk günden yazılan davranışlar.
Burada somut bir kırılma örneği vermiyoruz, çünkü elimizde doğrulanmış bir örnek yok ve olmayan bir örneği uydurmak bu sayfanın güvenilirliğini bitirir. Yazdığımız şey bir tahmin değil, bir duruş: değişimin ne zaman geleceğini bilmediğiniz bir yüzeyle çalışıyorsanız, entegrasyonu değişimi kaldıracak şekilde yazarsınız.
Teslim sonrası 15 gün ücretsiz hata düzeltme sözleşmenin standart maddesi. Sonrasında izleme devreye giriyor: başarısız çağrılar, jeton tazeleme hataları ve senkronizasyon turlarının sağlığı takip edilmezse bir sorun ancak kullanıcı şikâyetiyle fark edilir. İzlemeyi sürdürmek isteyen firmalar için bu, bakım sözleşmesinde ayrı bir hizmet olarak yazılır.
Yazılım ajansları ve muhasebe ofisleri için: geliştirme tarafını devralıyoruz
Paraşüt’ün etrafındaki ekosistem, klasik ERP bayi yapısından farklı işliyor. Burada iki tipik muhatap var: kendi müşterisine e-ticaret veya özel uygulama yapan yazılım ajansları ve müşterilerinin ön muhasebesini yürütürken tekrar eden veri girişinden kurtulmak isteyen muhasebe ofisleri.
İki durumda da tablo benzer: ihtiyaç net, ürün bilgisi zaten sizde, eksik olan tek şey entegrasyonu yazacak ve yaşatacak mühendislik kapasitesi. Bizim önerdiğimiz iş bölümü bu boşluğa oturuyor — müşteri ilişkisi, ürün danışmanlığı ve mali süreçlerin sorumluluğu sizde kalır, API üzerinden yazılacak entegrasyon kodu ve bakımı bizde olur.
Beyaz etiketli çalışabiliriz: müşteriye karşı görünen taraf siz olursunuz, biz tamamen arka planda kalırız
Anahtar talebi ve hesap yönetimi müşterinin kendi hesabında yürür; biz süreci teknik olarak destekler, sizin yerinize taahhüt vermeyiz
Birden çok müşteride tekrarlanan aynı akış için tek bir entegrasyon gövdesi kurar, müşteri bazlı yapılandırmayla çoğaltırız
Sabit fiyatla çalıştığımız için müşterinize verdiğiniz teklifin geliştirme kalemini kesin rakamla yazabilirsiniz
Kodun dokümantasyonu ve yapılandırma haritası size teslim edilir; iş birliği sonlansa bile elinizde çalışır bir varlık kalır
Sahada nasıl görünüyor?
E-ticaret siparişinden faturaya kesintisiz akış
Mağazada oluşan sipariş, Paraşüt tarafında ilgili kayıtlara dönüşüyor. Aynı sipariş ağ kesintisi sonrası tekrar gönderilse bile idempotent yazma sayesinde ikinci bir fatura oluşmuyor; muhasebe ekibi mükerrer kayıt temizlemekle uğraşmıyor.
Saha tahsilat ve cari bakiye görünürlüğü
Saha ekibi müşteri ziyaretinde güncel bakiyeyi kendi uygulamasından görüyor, tahsilat kaydı Paraşüt’e aktarılıyor. Bakiye, son senkron turunda yerel tabloya yazılan değerden okunduğu için ekran anında açılıyor; her ziyarette API’ye gidilmiyor.
Muhasebe ofisinde tekrar eden giriş yükünün kalkması
Müşterilerin farklı kanallardan gelen belgeleri tek bir akışta toplanıp Paraşüt’e aktarılıyor. Zamanlanmış çekme turları değişenleri yakalıyor, işlenmişlik kontrolü aynı belgenin iki kez işlenmesini engelliyor.
Ürün ve cari eşlemesinin yönetilebilir hale gelmesi
Kendi sisteminizdeki ürün ve cari kodlarının Paraşüt karşılıkları yönetilebilir bir eşleme tablosunda tutuluyor. Yeni ürün eklendiğinde geliştirici çağırmak gerekmiyor; eşleme ekrandan yapılıyor ve akış kesintisiz devam ediyor.
Senkronizasyon sağlık panosu
Her çekme turunun ne zaman çalıştığı, kaç kayıt işlendiği ve hangi kayıtların hata aldığı tek ekranda izleniyor. Başarısız kayıtlar sebebiyle listeleniyor ve tek tıkla yeniden denenebiliyor; sessiz başarısızlık ihtimali ortadan kalkıyor.
Referans iş birliği
Entegrasyon tarafında yeni bir hat kuruyoruz ve ilk projeleri referans iş birliğiyle yürütüyoruz: projenin sonunda ölçülebilir sonuçları vaka çalışması olarak yayımlamamıza ve sizi referans göstermemize izin veren firmalara özel koşul uyguluyoruz. Karşılığında alacağınız şey standart bir paket değil, süreçlerinize göre yazılmış bir sistem — ve geliştiren ekibe doğrudan erişim.
Sık sorulan sorular
Paraşüt veritabanına doğrudan bağlanabilir misiniz?
Hayır. Paraşüt bulut tabanlı bir üründür; veritabanı sizin makinenizde durmaz ve doğrudan erişim diye bir seçenek gündemde değildir. Entegrasyon tamamen API üzerinden kurulur. Bunu bir kısıt olarak görmüyoruz: şema takibi, tablo tahmini ve sürüm geçişi sonrası yeniden eşleme gibi masaüstü dertleri bu sayede hiç gündeme gelmiyor.
Entegrasyona ne zaman başlayabiliriz?
Takvimin başlangıç noktası geliştirmeye başladığımız gün değil, erişim anahtarının elinize geçtiği gün. Paraşüt tarafında client_id ve client_secret bilgileri üreticiden talep edilmek zorunda; deneme hesabında da aynı yolun geçerli olup olmadığı üreticiden teyit edilir. Bu, bizim yorumumuz değil; resmi OpenAPI tanımında istemci kimliği için destek@parasut.com adresine başvurulması gerektiğine dair bir not yer alıyor. Keşif çıktısında iki ayrı iş listesi veriyoruz ve anahtar talebi sizin listenizin ilk satırı oluyor. Anahtar beklenirken veri modeli, eşleme tablosu ve hata akışı gibi işleri paralel yürütüyoruz; canlı bağlantı gerektiren kalemleri ise takvime yazmıyoruz.
Paraşüt’ün istek limiti nedir?
Resmi OpenAPI (swagger) açıklaması “10 saniyede 10 istek” sınırını yayımlıyor. Yayımlanmayan kısım aşım davranışı: sınır aşıldığında dönen yanıt ve başlıklar belgelenmemiş, kalan hakkı bildiren bir yanıt başlığı da bulamadık. Bu yüzden burada üreticinin yazdığından fazlasını yazmıyoruz — belgelenmemiş bir davranışı uydurmak entegrasyon planını çürük bir temele oturtur. Entegrasyonu baştan bu sınırın altında kalacak şekilde ve temkinli yazıyoruz: hız sınırlama, yeniden deneme ve kademeli bekleme mantığı devrede, toplu aktarımlar kontrollü partiler halinde gönderiliyor ve başarısız çağrılar sebebiyle kaydedilip yeniden denenebiliyor. Yarın sınır değişse ya da aşım davranışı belgelense bile yazdığımız entegrasyonun değişmesi gerekmez.
Paraşüt bize değişiklikleri webhook ile bildirir mi?
Paraşüt API’sinin webhook yayınladığına dair doğrulanabilir bir kaynak bulunmuyor. Burada bir karışıklık kaynağı var: Paraşüt’ün e-Ticaret tarafında pazaryeri bildirimlerinin tüketilmesine dair kılavuzlar mevcut, ama bir ürünün başka sistemlerin bildirimlerini alıyor olması kendi API’sinin dışarıya bildirim yayınladığı anlamına gelmez. Bu yüzden senkronizasyonu zamanlanmış çekme ile kurguluyoruz: belirlenen aralıklarla, son turdan beri değişenleri hedefleyen dar sorgularla veri çekiliyor, her turun nereden devam edeceği kalıcı olarak saklanıyor, işlenmişlik kontrolü ve tek çalışan kilidi ile mükerrer işleme engelleniyor.
Aynı fatura iki kez oluşur mu?
Doğru kurulmuş bir entegrasyonda oluşmaz, ama bu kendiliğinden olmaz. Asıl tehlike başarısız istek değil, sonucu belirsiz kalan istektir: çağrı gönderilmiş, bağlantı kopmuş, yanıt alınamamıştır. Körlemesine tekrar denemek tam da bu noktada mükerrer kayıt üretir. Bu yüzden her yazma işlemini idempotent kurguluyoruz — kendi tarafımızdaki kaydın benzersiz karşılığını tutuyor, Paraşüt tarafındaki kimliği geri yazıyor ve tekrar denemeden önce kaydın gerçekten oluşup oluşmadığını doğruluyoruz. Yanıtı belirsiz kalan istekler otomatik olarak “önce doğrula, sonra karar ver” akışına giriyor.
Paraşüt güncellenirse entegrasyon bozulur mu?
Bulut ürünlerde yükseltme bir karar anı değil; güncelleme üreticinin takvimine göre gelir ve siz onaylamazsınız. Bu çoğunlukla avantaj: her müşteride farklı sürümle uğraşmıyoruz, şema takibi ve yükseltme sonrası yeniden eşleme gibi kalemler listeden düşüyor. Sorumluluk tarafı ise entegrasyonun dayanıklı olması: bilmediği alan geldiğinde patlamaması, beklediği alan boş geldiğinde kaydı sessizce yok saymaması, başarısız çağrıları kuyrukta tutup yeniden denemesi. Bu davranışlar bir “ileride ekleriz” listesi değil, ilk teslimin parçasıdır. Somut bir kırılma örneği vermiyoruz çünkü elimizde doğrulanmış bir örnek yok.
Paraşüt iş ortağı mısınız?
Hayır. Paraşüt’le ya da başka bir yazılım üreticisiyle iş ortaklığı, çözüm ortaklığı veya bayilik sözleşmemiz yok; bağımsız bir geliştirme ekibiyiz. Hesap açılışı, abonelik, anahtar talebi ve ürün danışmanlığı sizin kendi kanalınıza ait ve o alana girmiyoruz. Yaptığımız iş, ürünün açık şekilde yayımlanmış API dokümantasyonu üzerinden entegrasyon geliştirmek. Yazılım ajansları ve muhasebe ofisleriyle de taşeron geliştirme modelinde çalışıyoruz: müşteri ilişkisi sizde kalır, kod ve bakım bizde olur.
İstanbul’dayız; sizin Mersin’de olmanız sorun olur mu?
Paraşüt için olmaz. Ürün bulutta, entegrasyon tamamen API üzerinden; keşif görüşmesi de geliştirme de uzaktan yürür ve Türkiye’nin her ilinde aynı şekilde çalışırız. Yerinde bulunmamızın anlam taşıdığı tek durum sahadır — depo, mağaza ya da üretim tarafında bir kurulum varsa. Bunu Mersin, Tarsus, Adana, Hatay, İskenderun ve Osmaniye’de yerinde yapıyoruz; diğer illerde saha montajı gerekirse seyahat takvime başta yazılır.
Hangi programı kullandığınızı, sahada hangi verinin elle girildiğini ve neyi otomatikleştirmek istediğinizi anlatın. İlk görüşmede teknik olarak mümkün olup olmadığını ve hangi yöntemle yapılacağını netleştiriyoruz.
Bu sayfada adı geçen ürün ve markalar ilgili firmaların tescilli ticari markalarıdır. D'Cloud Software bağımsız bir yazılım geliştiricisidir; anılan firmaların yetkili bayisi, çözüm ortağı veya iş ortağı değildir. Entegrasyon hizmeti, ürünlerin kendi belgelenmiş arayüzleri ve veri erişim yöntemleri üzerinden sunulur.