Logo Tiger ile Salesforce arasında entegrasyon kurarken zorlanacağınız yer Salesforce tarafı değil. Salesforce’un dışarıya açılma biçimi standart ve belgeli. Zorluk Logo tarafında: veriye hangi yoldan erişeceğiniz, o yolun neyi yapıp neyi yapamadığı ve verinin gerçekte nasıl durduğu.
Bu yazı, tamamlanmış bir Logo Tiger entegrasyonundan çıkan kararları ve tökezlenen yerleri anlatıyor. Genel ERP entegrasyonu prensipleri için ERP entegrasyonunda nelere dikkat etmeli yazımıza bakabilirsiniz; burada doğrudan Logo’ya özgü kısımlar var.
Logo verisine üç yoldan erişilir, üçü de aynı şeyi yapmaz
Projenin ilk kararı bu ve çoğu zaman teknik tercihten çok lisans meselesidir.
| Yol | Ne için uygun | Kısıtı |
|---|---|---|
| Logo REST servisi | Okuma ve yazma, modern arayüz | ClientId/ClientSecret gerektirir; her kurulumda bulunmaz |
| Logo Objects (COM) | Kayıt yazma — Logo’nun kendi iş kurallarını çalıştırır | Ayrı lisans, Windows’a bağımlı, yavaş ve kırılgan |
| Doğrudan SQL okuma | Hızlı ve esnek okuma | Yazma için kullanılmamalı; şema bilgisi gerektirir |
Pratikte en sağlıklı kurgu ikisini birlikte kullanmak: okuma SQL’den, yazma Logo Objects üzerinden. SQL’e doğrudan kayıt atmak Logo’nun doğrulama ve numaralandırma mantığını atlar; bir gün muhasebe tarafında açıklaması zor bir tutarsızlık olarak karşınıza çıkar.
REST servisi mevcutsa en temiz yol odur. Ama projeye başlamadan önce müşterinin elinde ClientId ve ClientSecret olup olmadığını sorun. “Vardır herhalde” varsayımıyla planlanan bir mimari, ikinci haftada baştan kurgulanır.
Ara katman neden gerekiyor?
Salesforce bir bulut uygulaması; Logo çoğunlukla şirket içindeki bir sunucuda çalışıyor. Salesforce’un Logo veritabanına doğrudan bağlanması ne mümkün ne de doğru.
Araya, Logo’nun bulunduğu sunucuda çalışan küçük bir servis koyuyorsunuz. Bu servis Logo’yla konuşur, dışarıya yalnızca ihtiyaç duyulan uç noktaları açar. Çalışan bir kurguda şunlar vardı:
- .NET tabanlı bir servis, Windows servisi ya da IIS altında barındırılan bir uygulama olarak
- Uç nokta başına ayrı adres — ürün, fiyat, stok, cari, fatura ayrı ayrı
- API anahtarı ile kimlik doğrulama, sağlık kontrolü (
/health) hariç tutularak - Sayfalama — Salesforce çağrı başına sınırlı veri işleyebildiği için şart
- Dosya bazlı log — sorun çıktığında Logo mu Salesforce mu diye tartışmamak için
Bir ayrıntı: servisi dışarıya açma işi genelde müşterinin BT ekibiyle yürür ve tahmin edilenden uzun sürer. Port, güvenlik duvarı, sertifika ve IP kısıtlaması adımlarını proje planına baştan koyun.
Logo’nun tablo yapısında bilinmesi gerekenler
Tablo adları firma numarasını taşır
Logo’da tablolar LG_<firma>_ITEMS, LG_<firma>_CLCARD gibi adlarla durur. Hareket tabloları ayrıca dönem numarası taşır: LG_<firma>_<dönem>_CLFLINE. Sorgularınızı bu önekleri sabit yazarak kurmayın; yapılandırmadan okunsun.
Yıl değişince firma değişebilir — ve bu bir tuzak
Bazı şirketler her yıl Logo’da yeni bir firma açıyor. Bunun entegrasyon açısından sonucu ciddi: LOGICALREF değerleri her yıl sıfırlanıyor. Yani geçen yılın 15 numaralı faturasıyla bu yılın 15 numaralı faturası farklı belgeler.
LOGICALREF’i tek başına eşleştirme anahtarı yaparsanız, yıl dönümünde kayıtlar üst üste yazılır. Çözüm: anahtara firma ve dönem önekini eklemek. Hareket verisinde bu tercih değil zorunluluk.
Aynı sebeple fiş numarası da anahtar olamaz — yıllar arasında tekrarlıyor.
Stok tek satırda durmaz
Stok toplamlarını tutan görünüm, ürün ve ambar kırılımında tarih bazlı hareket satırları içeriyor. Yani “şu ürünün şu ambardaki stoğu” diye tek bir satır yok; toplamak gerekiyor.
İki tuzak daha var. Ambar numarası -1 olan satırlar “tüm ambarlar” anlamına gelen kümülatif kayıtlar; dışlanmazsa stok iki katı çıkar. Ve “gerçek stok” çoğu kurulumda fiili stok ile rezerve üretim miktarının toplamı — tek bir kolondan okunmuyor.
Formülü tahmin etmeyin. Müşterinin Logo danışmanından yazılı olarak isteyin, sonra sonucu Logo ekranındaki rakamla karşılaştırın.
Fiyat listesi tek değil, çakışıyor
Fiyat tablosunda bir ürün için aynı anda birden fazla geçerli satış fiyatı bulunabiliyor: farklı bayi listeleri, kampanyalar, sözleşmeye bağlı özel fiyatlar. Baktığımız bir veride, aynı ürün ve aynı döviz için birden fazla geçerli fiyat taşıyan yüzlerce çift vardı ve çoğunda fiyatlar birbirinden farklıydı.
Öncelik alanı genelde boş geldiği için ayırt edici olmuyor, tarih filtresi de çakışmayı çözmüyor. Birileri bir kural koymak zorunda: en yeni başlangıç tarihli olan mı kazanacak, yoksa belirli bir liste mi esas alınacak? Bu iş kararıdır, geliştiricinin verebileceği bir karar değildir.
Bir de veri kalitesi var: fiyat kolonunda 0,00007 gibi anlamsız değerlere rastlamak şaşırtıcı olmuyor. Bunları aktarmadan önce ne yapacağınıza karar verin — aynen geçirmek, atlamak ya da işaretleyip raporlamak.
Logo’ya kayıt yazmak: Logo Objects gerçeği
Cari kart veya sipariş yazacaksanız Logo Objects’e gireceksiniz. Belgelendirmesi zayıf ve öğrenme eğrisi diktir. Yaşadığımız üç somut sorun:
- Nesne tipi sabiti yanlışsa sessizce başarısız olur. Her kayıt türünün kendi sayısal karşılığı var. Yanlış sabitle nesne yine oluşuyor, ama alanları boş kalıyor ve kaydetme adımı açıklamasız hata veriyor. Doğru sabiti bulana kadar hatanın nereden geldiği anlaşılmıyor.
- Alan adları tahmin edilemiyor. Logo ekranındaki etiketle Objects’teki alan adı örtüşmüyor. “Özel Kod” için beklediğiniz ad çalışmıyor, “Posta Kodu” için yazdığınız kısaltma kabul edilmiyor. Daha kötüsü, bazı adlar kabul ediliyor ama değer başka bir alana düşüyor — mahalle ile ilçe bu şekilde yer değiştirebiliyor. Yazdıktan sonra kaydı Logo ekranından gözle kontrol etmek şart.
- İlk çağrı yavaş. Oturum açma birkaç saniye sürüyor. Oturumu tekil (singleton) tutup ayakta bırakırsanız sonraki çağrılar anında dönüyor. Ayrıca COM nesneleri tek iş parçacığı modelinde çalıştığı için çağrıların uygun iş parçacığında yürütülmesi gerekiyor; bu detay atlanırsa hatalar rastgele ve tekrarlanamaz görünür.
Pratik öneri: yazma tarafını geliştirirken her denemede hangi alanın set edilemediğini tek tek loglayın. Toplu “başarısız” mesajı size hiçbir şey söylemez; alan bazlı log doğru ismi bulmanın en hızlı yolu.
Veri kalitesi, entegrasyondan önce çözülmesi gereken iş
Mükerrer cari kontrolünü vergi numarası üzerinden yapmayı planlıyorsanız, önce o alana bakın. Gerçek kurulumlarda gördüklerimiz:
- Aynı dolgu değerinin (1111111111 gibi) yüzlerce kartta tekrarlaması
- Tire, boşluk ve rastgele karakterlerden oluşan “numaralar”
- Yurtdışı müşterilere elle uydurulmuş seriler
- Geçerli görünen numaraların bile birden fazla kartta geçmesi
Bunun sonucu şu: vergi numarası tek başına güvenilir bir anahtar değil. Uygulanabilir kural, sorgunun birden fazla kart döndürdüğü durumlarda o numarayı ayırt edici saymamak ve mükerrer kontrolünü atlamak. Kusurlu ama dürüst bir çözüm; alternatifi yanlış kartı güncellemek.
İl ve ilçe verisi de benzer durumda. Bir kurulumda 81 olması gereken il kodu sayısı 100’ün üzerindeydi, yüzlerce kayıtta ilçe kodu boştu ve yurtdışı carilerin il kodu alanına ülke kodu yazılmıştı. Bu veriyi Salesforce’a kaynak olarak taşımak yerine, Salesforce’ta bağımlı seçim listesi kurup adresi oradan beslemek daha sağlıklı.
Başlamadan önce karara bağlanacaklar
- Hangi erişim yolu? REST lisansı var mı, Objects lisansı var mı, SQL erişimi verilecek mi?
- Hangi veri hangi yöne akacak? Ürün, fiyat ve stok neredeyse her zaman Logo’dan Salesforce’a. Cari ve sipariş yönü tartışmalıdır ve iş sürecine bağlıdır.
- Eşleştirme anahtarları ne olacak? İş kodları (ürün kodu, cari kodu) iç referanslardan daha dayanıklıdır.
- Fiyat çakışmasında hangi kural? Yazılı olarak.
- Hata olduğunda ne olacak? Nereye loglanacak, kim görecek, tekrar denenecek mi?
Beşinci madde en çok atlanan. Entegrasyonun sessizce durması, hiç kurulmamış olmasından daha tehlikeli — çünkü ekip veriye güvenmeye devam ediyor.
Sıkça Sorulan Sorular
Logo Tiger Salesforce entegrasyonu için ayrı lisans gerekiyor mu?
Erişim yoluna bağlı. REST servisi için istemci bilgileri, Logo Objects için ayrı bir lisans gerekiyor. Yalnızca okuma yapacaksanız SQL erişimi yeterli olabilir. Projeye başlamadan önce elinizde hangisinin olduğunu netleştirin.
Salesforce Logo veritabanına doğrudan bağlanabilir mi?
Hayır, ve bağlanması da istenmez. Logo sunucusunda çalışan bir ara katman servisi kurulur; Salesforce yalnızca o servisin açtığı uç noktalarla konuşur.
Logo’ya kayıt yazarken SQL kullanılabilir mi?
Teknik olarak mümkün, pratikte yapılmamalı. Doğrudan SQL yazımı Logo’nun doğrulama kurallarını ve numaralandırma mantığını atlar. Yazma işlemleri Logo Objects veya REST servisi üzerinden yapılmalı.
Her yıl yeni firma açılması entegrasyonu nasıl etkiler?
İç referans numaraları sıfırlandığı için eşleştirme anahtarlarına firma ve dönem öneki eklenmesi gerekir. Aksi halde yıl dönümünde yeni kayıtlar eskilerin üzerine yazar.
Entegrasyon ne kadar sürer?
Kapsama bağlı. Ürün, stok ve fiyat gibi tek yönlü okuma entegrasyonları görece hızlı ilerler. Cari ve sipariş yazımı, iş kurallarının netleştirilmesi gerektiği için daha uzun sürer. Veri temizliği çoğu projede takvimi uzatan asıl kalem.
Stok ve fiyat ne sıklıkla güncellenmeli?
Çoğu şirket için saatlik ya da günlük yeterli. Anlık senkron nadiren gerekli ve maliyeti yüksek. Hareket tarihine göre değişenleri çekmek, her seferinde tüm veriyi taşımaktan çok daha verimli.
Sonuç
Logo Tiger entegrasyonunda zaman, kod yazmaktan çok üç şeye gidiyor: doğru erişim yolunu seçmek, Logo’nun veriyi nasıl sakladığını anlamak ve mevcut verinin kalitesiyle yüzleşmek. Bu üçü çözüldüğünde geri kalanı rutin bir geliştirme işi.
Vintera Tech, Salesforce Select Partner olarak Logo Tiger entegrasyonlarını uçtan uca kuruyor. Mevcut Logo kurulumunuzu ve ihtiyacınızı ücretsiz ön görüşmede değerlendiriyoruz.
Ücretsiz değerlendirme isteyin →
Son güncelleme: 28 Eylül 2026