SAP Business One: Integration Service Sürekli Duruyorsa

SAP Business One Integration Service, panolar, olay iletimi ve Business One'a yapılan bağlantıların büyük bölümü için temel oluşturur. Devre dışı kaldığında nadiren yüksek sesle bir çökme yaşanır. Çoğu zaman artık hiçbir şey olmaz ve bu ancak rakamlar eksik kaldığında fark edilir. Aşağıdaki tanı yolu bir müşteri vakasına değil, SAP dokümantasyonuna ve SAP Community'den belgelenmiş hata örüntülerine dayanmaktadır.

Integration Service'in arkasında hangi servisler var?

Integration Service tek bir servis değil, birbirine bağımlı Windows servislerinden oluşan bir zincirdir: Tomcat tabanlı Integration Service, Event Sender, System Landscape Directory ve DIProxy etrafında en az iki servis. Yalnızca uygun ada sahip servise bakan kişi, arızayı yanlış yerde arar.

SAP belgesi DIProxy Configuration (Integration Framework for SAP Business One, SAP Global Roll-out, Ekim 2018, yazar Bo Zhao) iki DIProxy servisini net biçimde birbirinden ayırır. DI Proxy Service „the main service which is listening on port 2099 by default for the DI-API calls“ olarak tanımlanır. Onun yanında DI Proxy Service Monitor bulunur; SAP'ye göre bu, „the daemon service used to restart the DI Proxy automatically when the process stopped unexpectedly“ hizmetidir. Bu ikinci satır belgenin en önemli cümlesidir: SAP, beklenmedik çökmeler öngörüldüğü için beraberinde bir bekçi köpeği sunar.

Bu altyapının sistemin bir parçası olduğunu SAP'nin kendisi ifade eder: SAP'nin Global Roll-out ekibinde Product and Topic Expert olan Miriam Rieger, „The integration framework for SAP Business One is a Web browser-based solution to design integration flows for exchanging data between different systems“ diye yazar; bu ifade SAP Community'nin merkezi B1if blogunda (14 Ağustos 2018, Mayıs 2020'de güncellendi, yaklaşık 96.100 görüntülenme) yer alır.

Servis neden sadece bir kez değil, tekrar tekrar duruyor?

Business One'da tekrarlanan durmalar çoğunlukla bir çökme değil, yapılandırılmış bir yeniden başlatmadır. DIProxy, olası bellek sızıntılarını sınırlamak için onu planlı biçimde yeniden başlatan parametrelerle birlikte gelir. Bunu bilmeyen kişi, günlerce var olmayan bir hatayı arar.

• MAXDIERRORS: varsayılan olarak yerinde (on-premise) kurulumlarda 50, bulut kurulumlarında 200. SAP'ye göre bu değer „the count of DI-errors that may happen until the DIProxy will be restarted for the sake of potential memory leaking“ anlamına gelir.
• RESTARTPERIOD: varsayılan olarak yerinde 60, bulutta 0. Bu değer, aynı nedenle, bir sonraki planlı yeniden başlatmaya kadar geçen süreyi dakika cinsinden belirtir.
• MAXACCESES: varsayılan olarak 0, yani sınırsız. SAP, çok sayıda eşzamanlı erişim olduğunda DIProxy'nin kapatılmasının „a very long time“ sürebileceği konusunda uyarır. Yönetici bunu tam olarak „durduruluyor“ durumunda takılı kalmış bir servis olarak görür.

Bu nedenle tanı için önemli olan durmanın kendisi değil, sıklığıdır. Saatte bir kısa süreliğine kaybolması, yerinde kurulumların varsayılan değerleriyle örtüşen bir beklentidir. Buna karşılık birkaç dakikada bir kaybolması örtüşmez.

Bu hata örüntüsü yıllardır belgelenmektedir. Bir kullanıcı bunu 2017'de kısaca şöyle tarif eder: „sap business one integration service is stopping […] it repeats once in a while“. 2011 tarihli bir konu başlığı, yeniden başlatma sırasında „the service returns an error and status is ‚stopping‘ or ‚starting‘“ durumunun yaşandığını ve tek güvenilir çıkış yolunun bir sunucu yeniden başlatması olduğunu anlatır. Her iki gönderi de bugüne kadar yayımlanmış bir yanıt almamıştır (3 Ağustos 2026 itibarıyla kontrol edilmiştir).

Arızayı hangi sırayla tanılamalısınız?

Bu sıra, nedeni bulup bulamayacağınızı ya da yalnızca belirtiyi bastırıp bastırmayacağınızı belirler. Yeniden başlatma en sona aittir, çünkü kanıtları yok eder.

• Önce servis zinciri. Integration Service, Event Sender ve her iki DIProxy servisini ayrı ayrı kontrol edin. Monitor servisi çalışırken döngüsel olarak yeniden başlayan bir ana servis, bir daha hiç açılmayan bir servisten farklı bir durumdur.
• Günlük seviyesini hedefli biçimde yükseltin. DIProxy dizinindeki DIProxylog.properties üzerinden kontrol edilir, günlükler log alt klasöründedir. Varsayılan olarak SEVERE seviyesi, dosya başına 10.485.760 bayt ve üç dosya belirlenmiştir. SAP, hata ayıklama için „.level=FINER“ ile birlikte „java.util.logging.FileHandler.count = 10“ ayarını önerir. Varsayılan ayarlarda neden, birkaç gün sonra çoktan üzerine yazılmış olur.
• Adreslemeyi birleştirin. Toplulukta „cannot connect to SAP Business One integration service“ hatası için en sık belirtilen tetikleyici, karışık adreslemedir. İlgili konudaki bir yanıt bunu net biçimde ortaya koyar: „Can you Check if you use the same hostname or ip address in SLD landscape directory and in integration service or event sender?“ Ya her yerde ana bilgisayar adı ya da her yerde IP adresi kullanılmalıdır.
• Bağlantı noktalarını kontrol edin. DIProxy varsayılan olarak 2099 numaralı bağlantı noktasını dinler. Kendi sunucusunda çalışıyorsa bu bağlantı noktası açık olmalıdır. Birden fazla örneğin her birinin diproxyserver.properties dosyasında kendi bağlantı noktası olması gerekir.
• Yeniden başlatmayı yalnızca en son adım olarak yapın. Sistem profili değiştirildikten sonra framework, her hâlükârda Integration Service'in yeniden başlatılmasını gerektirir.

Arızayı kullanıcıdan önce görebilmeniz için izlemeye ne dahil edilmeli?

Teslimat durumunda izleme oldukça yetersizdir, bu yüzden arızalar uzun süre fark edilmeden kalır. Log Maintenance in Integration Framework (SAP Global Roll-Out, Ocak 2019, yazar Nidhi Singh) belgesine göre, „Productive System“ profilinde mesaj günlüğü varsayılan olarak etkin değildir. SAP, üretim sistemleri için en fazla en düşük seviye olan „Infoset“i önerir.

En kapsamlı sonuçları olan varsayılan değer hata işlemede yer alır: eşzamansız işlemler için her iki profilde de „Retrial after 1 minute and stop processing of following messages“ geçerlidir. Böylece tek bir hatalı mesaj, tüm kuyruğu durdurur. Servis çalışmaya devam eder, ancak entegrasyon durur. Bu, servis izlemesinin yeşil bildirdiği ama yine de hiçbir verinin gelmediği durumdur.

• Servis durumu yerine kuyruğu izleyin. Queue Monitor varsayılan olarak mevcuttur. Boşalmayan bir kuyruk, en erken dürüst sinyaldir.
• Ayrıntılı günlükleri yalnızca sınırlı süreyle kullanın. SAP bunu açıkça ifade eder: „We do not recommend enabling detailed logging for an extended period, because it generates large log files for each transaction.“ Açın, hatayı yeniden oluşturun, dışa aktarın, kapatın.
• Veritabanı boyutunu değerlendirin. SAP, IFSERV şemasında BZSTIDXH ve BZSTIDXP üzerinden bir sayım sorgusu sunar. com.sap.b1i.system.xc.iodata kayıt türü baskınsa, bu sürekli tekrarlanan işlemlere, yani durmuş bir kuyruğa işaret eder.

Bunun n8n, Power Automate ve RPA workflow'ları için anlamı nedir?

Bir otomasyon workflow'u, Integration Service'in çalıştığına güvenemez. Baştan planlandığında üç önlemin uygulanması az bir maliyete mal olur.

• Hataları yutmak yerine bildirin. Hata durumunda bir kişiye mesaj gönderen bir dal, kimsenin okumadığı bir günlük kaydından daha değerlidir. NordFlux olarak her Business One bağlantısına, arayüze karşı düzenli bir test çağrısıyla birlikte tam olarak bu dalı ekliyoruz.
• Bekleme süresiyle yeniden deneyin. Tek seferlik bir deneme, her bir dakikalık yeniden başlatmada başarısız olur; sınırlı sayıda ve aralarla yapılan yeniden deneme bunu aşmayı sağlar.
• İdempotent şekilde kurgulayın. Bir çalıştırma işlem ortasında kesintiye uğrar ve daha sonra yeniden başlarsa, ikinci bir belge oluşmamalıdır. Bunun için eşleştirme amacıyla bir iş anahtarı gerekir.

Hangi erişim yolunun doğru olduğu SAP Business One Bağlama: Service Layer, OData ve RFC Middleware Karşılaştırması yazısında ele alınır. Bunun arkasındaki lisans ve araç sorusu RPA mi SAP Process Automation mı yazısında işlenir. İşletim için çerçeveyi SAP Business One Danışmanlığı sayfamızda bulabilirsiniz.

Sık Sorulan Sorular

SAP Business One Integration Service neden sürekli duruyor?

Tekrarlanan durmalar çoğunlukla bir arıza değil, yapılandırılmış bir durumdur. SAP'ye göre DIProxy, belirlenen bir sürenin ardından (RESTARTPERIOD, yerinde kurulumda varsayılan olarak 60 dakika) veya belirlenen sayıda DI hatasının ardından (MAXDIERRORS, yerinde kurulumda varsayılan olarak 50, buluttaysa 200) yeniden başlar. Önce durma sıklığını bu iki değere göre kontrol edin.

DIProxy bir çökmenin ardından otomatik olarak yeniden başlar mı?

Evet, ikinci servis çalışıyorsa. SAP bunun için DI Proxy Service Monitor'ü kurar; belgelere göre bu, „the daemon service used to restart the DI Proxy automatically when the process stopped unexpectedly“ hizmetidir. Bu servis çalışmıyorsa, çöken bir DIProxy kalıcı olarak kapalı kalır.

DIProxy'nin günlük dosyalarını nerede bulabilirim?

DIProxy dizininin log alt klasöründe, DIProxylog.properties üzerinden kontrol edilir. Varsayılan olarak SEVERE seviyesi, dosya başına 10.485.760 bayt ve üç dosya belirlenmiştir. Hata ayıklama için SAP, on dosyayla FINER seviyesini ve ardından ayarların geri alınmasını önerir.

Servis çalışıyor ama hiçbir veri gelmiyor. Bunun nedeni ne olabilir?

Genellikle durmuş bir kuyruk nedeniyledir. Eşzamansız işlemler için varsayılan ayar „Retrial after 1 minute and stop processing of following messages“ şeklindedir; tek bir hatalı mesaj, sonrasındaki tüm mesajları engeller. Servis penceresine değil, Queue Monitor'e ve mesaj günlüğünün hata bölümüne bakın.