Logic App Yeniden Gönderme: clientTrackingId ve sourceHistoryName Rehberi

Azure Logic Apps, iş süreçlerini otomatikleştirmek için güçlü, bulut tabanlı bir platform sunar. Ancak, her zaman her şeyin sorunsuz gitmesi mümkün değildir. Bazen dış sistemlerden kaynaklanan geçici hatalar, hatalı veri girişleri veya beklenmedik durumlar, Logic App iş akışlarınızın başarısız olmasına neden olabilir. İşte bu noktada, başarısız olan bir Logic App çalışmasını yeniden gönderme yeteneği kritik bir öneme sahiptir. Bu teknik makale, Logic Apps’te yeniden gönderme (resubmission) davranışını, özellikle clientTrackingId ve sourceHistoryName parametreleri bağlamında detaylı bir şekilde açıklayacaktır. Bu kavramları anlayarak, iş akışlarınızdaki hataları daha etkin bir şekilde ayıklayabilir, süreçlerinizi daha tutarlı bir şekilde izleyebilir ve sorun giderme süreçlerinizi önemli ölçüde hızlandırabilirsiniz. Bu rehber, Logic Apps’e yeni başlayanlardan deneyimli geliştiricilere kadar her seviyeden okuyucuya hitap edecek şekilde tasarlanmıştır. Başarısız olan bir Logic App’i yeniden çalıştırmak için hangi adımları izlemeniz gerektiğini ve bu süreçte arka planda nelerin gerçekleştiğini adım adım keşfedeceğiz. Gelin, bu karmaşık ama bir o kadar da güçlü konuyu birlikte aydınlatalım.

Modern iş süreçleri genellikle birbirine bağlı birçok sistem ve hizmetten oluşur. Bu karmaşık yapılar içerisinde, bir otomasyon akışının herhangi bir adımında yaşanabilecek bir aksaklık, tüm sürecin durmasına veya yanlış sonuçlar üretmesine neden olabilir. Azure Logic Apps, bu tür iş akışlarını tasarlamak ve yürütmek için esnek bir ortam sunsa da, dış bağımlılıklar veya öngörülemeyen durumlar nedeniyle iş akışlarının başarısız olması kaçınılmazdır. Bir veritabanı bağlantısının anlık olarak kesilmesi, üçüncü taraf bir API’nin geçici olarak yanıt vermemesi, ağ sorunları veya işlenen verilerdeki beklenmedik bir format hatası gibi durumlar, bir Logic App çalışmasının başarısızlıkla sonuçlanmasına yol açabilir. Bu tür durumlarda, tüm iş akışını en baştan tetiklemek, zaman ve kaynak israfına yol açabilir, özellikle de sorunun temelinde yatan nedenin geçici olduğu biliniyorsa. İşte bu noktada Logic Apps’in “yeniden gönderme” (resubmission) özelliği devreye girer.

Yeniden gönderme, başarısız olan bir Logic App çalışmasını, genellikle aynı giriş verileriyle veya küçük ayarlamalarla tekrar deneme yeteneğidir. Bu özellik, iş akışlarınızın dayanıklılığını ve hata toleransını önemli ölçüde artırır. Örneğin, bir satış siparişi işleme Logic App’iniz varsa ve bu uygulama, bir ödeme ağ geçidine bağlanırken geçici bir hata nedeniyle başarısız olursa, siparişin yeniden manuel olarak oluşturulması yerine, başarısız olan çalışmanın basitçe yeniden gönderilmesi, süreci devam ettirebilir. Bu, hem zaman kazandırır hem de manuel müdahale ihtiyacını azaltarak operasyonel verimliliği artırır. Ancak, yeniden gönderme işlemi basit bir “tekrar dene” düğmesi tıklamasından çok daha fazlasını ifade eder. Arka planda, bu yeniden denemelerin nasıl ilişkilendirildiği, orijinal çalışmayla bağlantısının nasıl kurulduğu ve hata ayıklama süreçleri için hangi bilgilerin kullanılabileceği gibi önemli sorular ortaya çıkar. Bu soruların yanıtları, clientTrackingId ve sourceHistoryName gibi kritik parametrelerde yatar.

clientTrackingId, her bir Logic App çalışmasına atanan benzersiz bir izleme kimliğidir. Bu kimlik, farklı sistemler veya loglar arasında bir iş akışının tüm yaşam döngüsünü takip etmek için hayati öneme sahiptir. Bir e-ticaret sitesinden gelen siparişin, Logic App üzerinden envanter sistemine, ardından faturalandırma hizmetine ve son olarak kargo şirketine iletilmesi gibi karmaşık bir senaryoda, clientTrackingId, bu adımların her birini tek bir mantıksal işlem altında birleştirmemizi sağlar. Başarısız bir çalışmanın yeniden gönderilmesi durumunda, clientTrackingId‘nin nasıl davranacağı, izlenebilirlik açısından kritik bir faktördür. Benzer şekilde, sourceHistoryName, yeniden gönderilen bir Logic App çalışmasının hangi orijinal başarısız çalışmadan türediğini gösteren bir referanstır. Bu parametre, özellikle hata ayıklama ve denetim (audit) süreçlerinde, bir hatanın kökenini hızlıca bulmak ve nedenini anlamak için paha biçilmez bilgiler sunar. İlerleyen bölümlerde, bu iki önemli kimliğin Logic App yeniden gönderme senaryolarında nasıl çalıştığını ve onları nasıl etkin bir şekilde kullanabileceğimizi daha detaylı inceleyeceğiz. Bu sayede, hem iş akışlarınızın güvenilirliğini artıracak hem de sorun giderme yeteneklerinizi güçlendireceksiniz.

Logic Apps Temelleri ve İzlenebilirliğin Önemi: clientTrackingId Nedir?

Logic Apps dünyasına adım attığımızda, karşımıza çıkan ilk kavramlar iş akışları, tetikleyiciler ve eylemlerdir. Bir Logic App iş akışı, temelde bir dizi adımdan oluşan, belirli bir tetikleyici ile başlayan ve çeşitli eylemleri sırayla veya paralel olarak yürüten otomasyon sürecidir. Tetikleyiciler (Triggers), bir Logic App’in ne zaman çalışacağını belirleyen olaylardır. Bunlar bir HTTP isteği, belirli bir zaman çizelgesi, bir e-posta geldiğinde veya bir dosya depolama alanında bir değişiklik olduğunda tetiklenebilir. Eylemler (Actions) ise tetikleyici sonrasında veya diğer eylemlerin ardından gerçekleştirilen adımlardır; örneğin bir veritabanına veri yazmak, bir e-posta göndermek, bir dış API’yi çağırmak veya bir koşulu kontrol etmek gibi. Bu temel yapı taşları, iş süreçlerinin dijitalleştirilmesinde ve otomasyonunda büyük esneklik sağlar. Ancak, bu otomasyonların güvenilirliğini ve anlaşılırlığını sağlamak, özellikle hata ayıklama ve izleme söz konusu olduğunda, belirli mekanizmalar gerektirir. İşte bu noktada clientTrackingId gibi izleme kimlikleri devreye girer.

clientTrackingId, Azure Logic Apps’teki her bir iş akışı çalışmasına otomatik olarak atanan benzersiz bir GUID (Globally Unique Identifier) değeridir. Bu kimlik, bir Logic App çalışmasının tüm adımlarını, farklı sistemler arasında ve çeşitli log kayıtlarında tek bir “korelasyon kimliği” altında birleştirmek için kullanılır. Bu sayede, karmaşık bir iş akışı, birden fazla Logic App’i, Azure Fonksiyonunu, Azure Service Bus’ı veya başka bir Azure kaynağını içerse bile, tüm bu parçacıklar aynı clientTrackingId ile ilişkilendirilebilir. Bu, uçtan uca izlenebilirlik (end-to-end traceability) sağlamanın temelidir. Örneğin, bir müşteri siparişi bir e-ticaret sisteminden geldiğinde, bu siparişin işlenmesi için tetiklenen Logic App’in her adımı (stok kontrolü, ödeme, sevkiyat bildirimi) aynı clientTrackingId ile izlenebilir. Eğer herhangi bir adımda bir hata oluşursa, bu kimlik sayesinde ilgili tüm logları ve hata mesajlarını kolayca bulabiliriz.

Varsayılan olarak, Logic App bir tetikleyici tarafından her çalıştırıldığında yeni ve benzersiz bir clientTrackingId otomatik olarak oluşturulur. Ancak, bazı senaryolarda, bu kimliği manuel olarak atamak isteyebiliriz. Özellikle dış sistemlerden gelen olaylarla Logic App tetiklendiğinde ve bu dış sistemin kendi benzersiz bir işlem kimliği varsa, bu kimliği clientTrackingId olarak kullanarak izlenebilirliği artırabiliriz. Örneğin, bir HTTP isteği tetikleyicisi kullanıyorsanız, isteğin başlıklarına (headers) özel bir clientTrackingId ekleyebilirsiniz. Bu, Logic App çalışmasını, istek gönderen sistemdeki orijinal işlemle doğrudan ilişkilendirme imkanı sunar. Aşağıdaki kod bloğu, bir HTTP tetikleyicisi kullanırken özel bir clientTrackingId‘nin nasıl gönderilebileceğini göstermektedir. Bu, hata ayıklama sırasında belirli bir isteğin neden başarısız olduğunu anlamak için büyük kolaylık sağlar ve özellikle kurumsal düzeydeki entegrasyon senaryolarında paha biçilmez bir araçtır.

{
  "trigger": {
    "type": "HttpRequest",
    "inputs": {
      "method": "POST",
      "relativePath": "/processOrder",
      "headers": {
        "x-ms-client-tracking-id": "myCustomOrderID-12345"
      }
    }
  },
  "actions": {
    "process_data": {
      "type": "ApiConnection",
      "inputs": {
        "host": {
          "connection": {
            "name": "@parameters('$connections')['sql']['connectionId']"
          }
        },
        "method": "post",
        "path": "/datasets/@{encodeURIComponent('default')}/tables/@{encodeURIComponent('Orders')}/items",
        "body": {
          "OrderID": "myCustomOrderID-12345",
          "CustomerName": "John Doe"
        }
      }
    }
  }
}

Bu örnekte, HTTP isteğinin başlığında x-ms-client-tracking-id özel bir değerle ayarlanmıştır. Logic App çalıştığında, bu başlık değeri otomatik olarak Logic App'in clientTrackingId olarak kabul edilecek ve Azure Monitor veya Application Insights gibi izleme araçlarında bu kimlik altında tüm loglar toplanacaktır. Yeniden gönderme durumunda, orijinal clientTrackingId'nin korunması veya yeni bir kimlik atanması, izleme stratejiniz üzerinde önemli etkilere sahiptir. Genellikle, Logic App portalından manuel olarak yeniden gönderilen bir çalışma, orijinal clientTrackingId'yi korurken, API aracılığıyla yapılan programatik yeniden göndermelerde bu kimliği manuel olarak kontrol etme esnekliğiniz bulunur. Bu esneklik, karmaşık hata kurtarma senaryolarında, iş akışınızın izlenebilirlik gereksinimlerine göre uyarlanabilirlik sağlar. Böylece, Logic Apps'inizdeki herhangi bir aksaklığı hızlıca tespit edebilir, nedenini anlayabilir ve çözüme kavuşturabilirsiniz.

Yeniden Gönderme ve Kaynak Takibi: sourceHistoryName'in Gücü

clientTrackingId'nin Logic App iş akışlarının genel izlenebilirliğini sağladığını anlamıştık. Şimdi ise, özellikle başarısız bir çalışmanın tekrar denendiği "yeniden gönderme" (resubmission) senaryolarında kritik bir rol oynayan sourceHistoryName kavramına odaklanalım. Bir Logic App çalışması başarısız olduğunda, bu hatanın nedenini anlamak ve sorunu giderdikten sonra işlemi yeniden başlatmak isteriz. Ancak, sadece iş akışını yeniden çalıştırmak yeterli değildir; yeniden çalıştırılan bu yeni iş akışının, hangi orijinal (ve başarısız) çalışmanın bir denemesi olduğunu bilmek, hata ayıklama, denetim ve izleme açısından hayati önem taşır. İşte sourceHistoryName tam da bu ihtiyacı karşılar.

sourceHistoryName, yeniden gönderilen bir Logic App çalışmasının, kaynaklandığı orijinal çalışmanın geçmiş kimliğine (run history ID) referans veren bir parametredir. Yani, bir Logic App çalışmasını manuel olarak Azure portalı üzerinden yeniden gönderdiğinizde veya programatik olarak bir API çağrısı ile yeniden başlattığınızda, yeni oluşturulan çalışma, bu parametre sayesinde orijinal başarısız çalışmayla ilişkilendirilir. Bu ilişki, hata ayıklayıcıların, operasyon ekiplerinin ve denetçilerin, bir hatanın tekrarlayan denemeler zincirindeki yerini ve evrimini anlamalarına olanak tanır. Örneğin, bir veritabanı bağlantı hatası nedeniyle başarısız olan bir işlemden sonra, bağlantı sorununu giderip iş akışını yeniden başlattığınızda, yeni çalışan iş akışının sourceHistoryName'ine bakarak, onun ilk hatanın bir sonucu olduğunu ve belirli bir hata kurtarma çabasının parçası olduğunu hızlıca anlayabilirsiniz. Bu, bir olayın yaşam döngüsünü tam olarak takip etmek için güçlü bir mekanizma sunar.

Logic App portalından bir çalışmayı yeniden göndermek oldukça basittir. Başarısız olan bir çalışma geçmişini açtığınızda, genellikle "Yeniden Gönder" (Resubmit) düğmesini görürsünüz. Bu düğmeye tıkladığınızda, Logic App otomatik olarak yeni bir çalışma başlatır ve bu yeni çalışmanın sourceHistoryName'ini, yeniden gönderdiğiniz orijinal çalışmanın kimliğine (örneğin, 08587121234567890123456789012 gibi bir değer) ayarlar. Bu, Azure'ın yönettiği otomatik bir süreçtir ve çoğu senaryo için yeterli izlenebilirliği sağlar. Ancak, daha gelişmiş senaryolarda, örneğin otomatik hata kurtarma sistemleri kurarken, Logic App API'sini veya Azure CLI/PowerShell komutlarını kullanarak programatik olarak yeniden gönderme yapmanız gerekebilir. Bu durumlarda, sourceHistoryName parametresini manuel olarak belirleme esnekliğiniz vardır. Bu, birden fazla Logic App'in birbirini tetiklediği veya farklı sistemlerden gelen olaylarla karmaşık kurtarma mekanizmaları uyguladığınız senaryolarda çok faydalıdır. Doğru sourceHistoryName'i ayarlamak, yeniden gönderilen çalışmanın neden ve hangi bağlamda tetiklendiğini anlamanıza yardımcı olur, böylece denetim ve hata raporlama süreçleri çok daha anlamlı hale gelir.

Vaka Analizi: Hatalı Veri Dönüşümünde İzlenebilirlik

Bir e-ticaret platformundan gelen ürün bilgilerini işleyen bir Logic App'iniz olduğunu varsayalım. Bu Logic App, ürün verilerini alır, belirli dönüşümlerden geçirir ve envanter veritabanına kaydeder. Bir gün, dış platformdan gelen ürün verilerinden biri beklenenden farklı bir formatta gelir (örneğin, fiyat alanı metin olarak gelirken sayı beklenir) ve bu, Logic App'inizin veri dönüşüm eylemini başarısız kılar. İlk çalışma, bu format hatası nedeniyle başarısız olur ve "Çalışma Geçmişi"nde kırmızı bir uyarı ile gösterilir. Operasyon ekibi sorunu tespit eder, veri kaynağındaki hatayı düzeltir ve ardından başarısız olan Logic App çalışmasını Azure portalından "Yeniden Gönder" düğmesini kullanarak tekrar dener. Bu yeni çalışma başarıyla tamamlanır. Bu senaryoda, yeni başarılı çalışmanın sourceHistoryName'i, ilk başarısız çalışmanın kimliğini içerir. Bu sayede, hem başarılı hem de başarısız olan tüm denemeleri birbiriyle ilişkilendirebilir ve bu ürün verisi için yaşanan problemin tüm evrimini tek bir yerden izleyebilirsiniz. Bu, hem sorunun kök neden analizi için değerli bilgiler sunar hem de denetim süreçlerinde, bir hatanın nasıl giderildiğini ve iş akışının nasıl başarıyla tamamlandığını kanıtlama yeteneği sağlar. Dolayısıyla, sourceHistoryName, Logic Apps'teki hata yönetimini ve izlenebilirliği derinlemesine kavrayarak, daha güvenilir ve yönetilebilir otomasyonlar oluşturmanız için vazgeçilmez bir araçtır.

Logic App Yeniden Gönderme Mekanizması: Adım Adım İşleyiş ve Gelişmiş Senaryolar

Logic App yeniden gönderme mekanizması, basit bir "tekrar dene" komutundan daha fazlasını içerir ve bir iş akışının nasıl çalıştığına dair önemli detayları barındırır. Bu bölümde, yeniden gönderme sürecinin adım adım nasıl işlediğini, hangi verilerin tekrar kullanıldığını ve hangi kısımların yeniden değerlendirildiğini derinlemesine inceleyeceğiz. Ayrıca, daha karmaşık senaryolar için programatik yeniden gönderme yöntemlerine ve parametrelerin nasıl manipüle edilebileceğine değineceğiz. Bu bilgiler, Logic App iş akışlarınızdaki başarısızlıkları daha bilinçli bir şekilde yönetmenize ve hata ayıklama süreçlerinizi optimize etmenize yardımcı olacaktır.

Yeniden Gönderme Yöntemleri ve Sürecin Başlangıcı

Bir Logic App çalışmasını yeniden göndermenin üç temel yolu vardır:

1. Azure Portal Üzerinden: En yaygın ve en basit yöntemdir. Başarısız olan bir çalışma geçmişi görünümünde "Yeniden Gönder" butonuna tıklamanız yeterlidir. Bu yöntemle, Logic App otomatik olarak orijinal tetikleyici girişlerini kullanarak yeni bir çalışma başlatır. clientTrackingId genellikle korunur ve sourceHistoryName orijinal çalışmanın kimliğine ayarlanır.
2. REST API Kullanarak: Daha esnek ve otomatize edilmiş senaryolar için Logic Apps REST API'si üzerinden programatik olarak yeniden gönderme yapabilirsiniz. Bu yöntem, özellikle belirli koşullara göre otomatik hata kurtarma sistemleri veya toplu yeniden denemeler oluşturmak istediğinizde kullanışlıdır.
3. Azure PowerShell veya Azure CLI ile: REST API'ye sarılmış komutlar aracılığıyla yeniden gönderme yapma imkanı sunar. Script tabanlı otomasyonlar için idealdir.

Yeniden gönderme işlemi başlatıldığında, Logic App, orijinal çalışmanın tetikleyici geçmişini ve giriş verilerini inceler. Burada dikkat edilmesi gereken en önemli nokta, Logic App'in yeniden gönderme sırasında tetikleyiciyi yeniden değerlendirip değerlendirmeyeceğidir. Varsayılan olarak, Logic App'in tetikleyici kısmı, orijinal çalışmanın tetikleyici girdileriyle atlanır ve doğrudan tetikleyicinin çıktılarını kullanarak ilk eylemden devam eder. Bu, özellikle zamana dayalı veya olay tabanlı tetikleyiciler için önemlidir, çünkü tetikleyicinin yeniden çalıştırılması istenmeyen yan etkilere neden olabilir (örneğin, aynı olayın iki kez işlenmesi).

Tetikleyici Durumlarının Rolü ve Veri Akışı

Yeniden gönderme sırasında, Logic App motoru orijinal çalışmanın tetikleyici durumunu kontrol eder. Eğer tetikleyici, başarılı bir şekilde tetiklenmiş ve çıktı üretmişse, yeniden gönderme işlemi bu çıktıları doğrudan alır ve ilk eyleme iletir. Yani, tetikleyici eylemi yeniden yürütülmez. Ancak, eğer orijinal çalışma tetikleyici aşamasında başarısız olmuşsa (örneğin, bir HTTP isteği tetikleyicisi hiç yanıt alamamışsa), yeniden gönderme tetikleyiciyi yeniden deneyecektir. Bu ayrım, idempotency (tekrarlanabilirlik) ve veri tutarlılığı açısından kritik öneme sahiptir.

clientTrackingId ve sourceHistoryName bu süreçte nasıl davranır? Daha önce de belirtildiği gibi, Azure Portal üzerinden yapılan yeniden göndermelerde clientTrackingId genellikle orijinal kimlikle aynı kalır. Bu, yeniden denenen iş akışının hala aynı mantıksal işlemin bir parçası olduğunu gösterir. sourceHistoryName ise, yeni çalışmanın orijinal başarısız çalışmaya bir referans olarak atanır. Programatik olarak yeniden gönderme yaparken, hem clientTrackingId'yi hem de sourceHistoryName'i kendi ihtiyaçlarınıza göre belirleme esnekliğiniz vardır. Bu, denetim veya özel hata raporlama gereksinimleriniz olduğunda çok güçlü bir özelliktir. Örneğin, belirli bir hata nedeniyle otomatik olarak yeniden gönderilen çalışmalara özel bir clientTrackingId öneki ekleyebilir veya sourceHistoryName'i, birden fazla Logic App'i içeren karmaşık bir kurtarma iş akışındaki ana işlem kimliğine ayarlayabilirsiniz.

Programatik Yeniden Gönderme Örneği

Azure REST API'sini kullanarak bir Logic App çalışmasını programatik olarak nasıl yeniden göndereceğinize dair basit bir örnek aşağıdadır. Bu, genellikle PowerShell veya diğer programlama dilleri aracılığıyla çağrılır:

# Değişkenlerinizi ayarlayın
$resourceGroupName = "MyLogicAppResourceGroup"
$logicAppName = "MyOrderProcessingLogicApp"
$runId = "08587121234567890123456789012" # Yeniden göndermek istediğiniz başarısız Logic App çalışmasının kimliği
$subscriptionId = "YOUR_SUBSCRIPTION_ID"
$accessToken = (Get-AzAccessToken).Token # Azure'a kimlik doğrulaması yapılmış olmalı

$uri = "https://management.azure.com/subscriptions/$subscriptionId/resourceGroups/$resourceGroupName/providers/Microsoft.Logic/workflows/$logicAppName/runs/$runId/resubmit?api-version=2019-05-01"

$headers = @{
    "Authorization" = "Bearer $accessToken"
    "Content-Type" = "application/json"
    "x-ms-client-tracking-id" = "CustomResubmit-$((Get-Date).Ticks)" # İsteğe bağlı özel clientTrackingId
    "x-ms-source-history-name" = $runId # Bu, varsayılan olarak API tarafından eklenir, ancak manuel de eklenebilir.
}

Invoke-RestMethod -Uri $uri -Method POST -Headers $headers

Bu örnekte, Invoke-RestMethod kullanarak belirli bir Logic App çalışmasını yeniden gönderiyoruz. x-ms-client-tracking-id başlığını kullanarak isteğe bağlı olarak özel bir izleme kimliği atayabiliriz. Bu, programatik kontrolün gücünü göstermektedir. Bu tür programatik yetenekler sayesinde, hatalı durumdaki iş akışlarını otomatik olarak tespit edip yeniden başlatabilen, böylece operasyonel müdahale gereksinimini minimuma indiren karmaşık otomasyon çözümleri geliştirebilirsiniz. Yeniden gönderme mekanizmasını ve parametrelerini doğru anlamak, Logic App tabanlı çözümlerinizin hem daha dayanıklı hem de daha şeffaf olmasını sağlar.

En İyi Uygulamalar, Hata Ayıklama İpuçları ve Mobil Uyumlu Yönetim

Logic Apps'te yeniden gönderme yeteneği güçlü bir araç olsa da, bu yeteneği etkin ve verimli kullanmak için belirli en iyi uygulamaları ve gelişmiş teknikleri bilmek önemlidir. İş akışlarınızı tasarlarken, yönetirken ve hatalarını ayıklarken izleyeceğiniz stratejiler, çözümünüzün genel güvenilirliğini ve sürdürülebilirliğini belirler. Ayrıca, günümüzün mobil odaklı dünyasında, Logic App çözümlerinin yönetim ve izleme arayüzlerinin mobil cihazlarda da sorunsuz çalışabilmesi, operasyonel ekipler için büyük kolaylık sağlar.

İdempotency ve Hata İşleme Stratejileri

Yeniden gönderme işlemleri için en önemli tasarım prensiplerinden biri idempotency'dir. İdempotent bir işlem, aynı girdilerle birden fazla kez çalıştırıldığında, sistem üzerinde yalnızca bir kez çalıştırılmış gibi aynı sonucu üretir. Yani, aynı işlemi iki kez gerçekleştirmek, bir kez gerçekleştirmekle aynı etkiyi yaratır. Örneğin, bir veritabanına yeni bir kayıt ekleyen bir Logic App eylemi, eğer ikinci kez çalıştırıldığında çift kayıt (duplicate entry) oluşturuyorsa idempotent değildir. Ancak, mevcut bir kaydı güncelleyen bir eylem genellikle idempotent olabilir. Logic App'lerinizi idempotent olacak şekilde tasarlamak, yeniden gönderme veya otomatik tekrar deneme durumlarında istenmeyen yan etkilerin (örneğin, çift ödemeler, yanlış stok güncellemeleri) önüne geçer. Bunu sağlamak için:

• Benzersiz anahtarlar (Unique keys) kullanarak veri ekleme/güncelleme işlemlerini yönetin.
• İşlem durumlarını takip eden bir denetim tablosu kullanın ve bir işlemin zaten tamamlanıp tamamlanmadığını kontrol edin.
• If-Match veya If-None-Match gibi HTTP başlıklarını kullanarak çakışmaları önleyin.

Hata işleme stratejileri de kritik öneme sahiptir. Logic Apps, eylemlere "retry policy" (yeniden deneme politikası) atama ve "scope" (kapsam) kullanarak hata yakalama imkanı sunar. Geçici ağ hataları gibi durumlarda yeniden deneme politikaları yeterli olabilirken, iş mantığı hataları veya dış sistemlerden gelen kalıcı sorunlar için kapsamlar ve "Configure run after" (sonra çalıştırı yapılandır) özellikleri ile daha sofistike hata işleme akışları tasarlayabilirsiniz. Örneğin, bir API çağrısı başarısız olursa, bir e-posta gönderebilir veya sorunu otomatik olarak düzeltmeye çalışan başka bir Logic App'i tetikleyebilirsiniz.

Gelişmiş İzleme ve Hata Ayıklama İpuçları

clientTrackingId ve sourceHistoryName, Logic Apps'in yerleşik izleme araçlarında (Çalışma Geçmişi, Tetikleyici Geçmişi) zaten görünür. Ancak, daha derinlemesine analiz için Azure Monitor ve Application Insights gibi hizmetlerle entegrasyon kurmak çok faydalıdır. Bu hizmetler:

• Merkezi Loglama: Logic App loglarını diğer Azure kaynaklarınızla (Azure Functions, API Management vb.) tek bir yerde toplar.
• Korelasyon ID'leri: clientTrackingId'yi kullanarak farklı hizmetler arasındaki olayları ilişkilendirebilir ve uçtan uca işlemin tam bir görünümünü elde edebilirsiniz.
• Uyarılar ve Metrikler: İş akışlarınızın performansı ve hata oranları hakkında uyarılar oluşturabilir, özel metrikler toplayabilirsiniz.
• Sorgu Dili (KQL): Güçlü Kusto Query Language (KQL) kullanarak loglar üzerinde karmaşık sorgular çalıştırabilir, belirli hata paternlerini veya yeniden gönderme zincirlerini kolayca bulabilirsiniz.

Hata ayıklama yaparken, clientTrackingId'yi bir filtre olarak kullanmak, ilgili tüm log kayıtlarını ve çalışma geçmişlerini hızlıca bulmanıza yardımcı olur. Özellikle yeniden gönderilen bir çalışma söz konusu olduğunda, sourceHistoryName'i kullanarak orijinal başarısız çalışmayı tespit edebilir ve hatanın kök nedenini daha hızlı anlayabilirsiniz. Azure portalındaki "Çalışma Geçmişi" görünümünde, başarısız bir adımı tıklayarak hatanın detaylarını ve o adıma giren ve çıkan verileri incelemek, sorunu anlamak için ilk adımdır.

Mobil Uyumlu Yönetim ve Analiz

Modern DevOps ve operasyonel ekipler, genellikle hareket halindeyken sistemlerini izleme ve yönetme ihtiyacı duyarlar. Azure portalı, mobil cihazlar üzerinden de erişilebilir olsa da, karmaşık log analizleri ve detaylı iş akışı denetimleri için tam bir tarayıcı deneyimi gerektirebilir. Ancak, yönetim konsollarının ve log arayüzlerinin mobil uyumlu (responsive) HTML ile tasarlanması, deneyimi önemli ölçüde iyileştirir.

Logic Apps'in çalışma geçmişi ve izleme verileri, Azure Mobil Uygulaması üzerinden sınırlı bir şekilde görüntülenebilir. Daha gelişmiş mobil uyumlu çözümler için:

• Özel Panolar: Azure Dashboard'ları veya özel Power BI panoları oluşturarak önemli metrikleri ve uyarıları mobil cihazlarda optimize edilmiş bir şekilde görüntüleyebilirsiniz. Bu panolar, clientTrackingId ve sourceHistoryName gibi kritik izleme verilerini özetleyebilir.
• Log Analizi Araçları: Azure Monitor Log Analytics'in kendi web arayüzü responsive bir tasarıma sahiptir, ancak karmaşık KQL sorguları mobil klavyelerle yazmak zor olabilir. Mobil dostu bir arayüz için önceden tanımlanmış KQL sorguları içeren basit web uygulamaları geliştirebilirsiniz.
• Bildirimler: Logic App hataları veya yeniden gönderme durumları için Azure Monitor uyarılarını mobil bildirimlerle (e-posta, SMS, Azure Mobile App push bildirimleri) entegre edin. Bu sayede, önemli olaylardan anında haberdar olabilirsiniz.

Bir web uygulaması tasarlarken, mobil uyumluluk için HTML ve CSS'i doğru kullanmak esastır. Örneğin, bir log tablosunu mobil cihazda düzgün görüntülemek için aşağıdaki gibi basit bir CSS yaklaşımı düşünülebilir:

  

    

      

        
clientTrackingId
        
sourceHistoryName
        
Durum
        
Zaman
      
    
    

      
    
  

Bu, karmaşık tabloların küçük ekranlarda daha okunabilir hale gelmesini sağlayan temel bir yaklaşımdır. Her bir

elemanına dinamik olarak data-label özelliği ekleyerek, mobil görünümde başlıkların her satırda tekrarlanmasını sağlayabilirsiniz. Bu tür UI iyileştirmeleri, Logic App çözümlerinin sadece güçlü değil, aynı zamanda yönetilebilir ve erişilebilir olmasını sağlar.

Sonuç: Logic App Yönetiminde Güçlü Bir Araç

Bu kapsamlı makale boyunca, Azure Logic Apps'teki yeniden gönderme (resubmission) davranışının inceliklerini, özellikle clientTrackingId ve sourceHistoryName gibi kritik parametreler bağlamında ele aldık. Gördük ki, başarısız iş akışlarını yönetme yeteneği, modern bulut tabanlı otomasyon çözümlerinin temel taşlarından biridir. Yeniden gönderme, yalnızca basit bir tekrar deneme işlemi olmanın ötesinde, iş akışlarınızın dayanıklılığını artıran, manuel müdahaleyi azaltan ve operasyonel verimliliği yükselten stratejik bir araçtır.

clientTrackingId'nin, bir Logic App çalışmasının tüm yaşam döngüsü boyunca uçtan uca izlenebilirlik sağlayan benzersiz bir kimlik olarak nasıl hizmet ettiğini öğrendik. Bu kimlik, karmaşık sistem entegrasyonlarında hata ayıklama ve log korelasyonu için paha biçilmezdir. Diğer yandan, sourceHistoryName, yeniden gönderilen bir çalışmayı, köken aldığı orijinal başarısız çalışmayla ilişkilendirerek denetim ve hata kök neden analizi için hayati bir bağlam sunar. Bu iki parametreyi doğru bir şekilde anlamak ve kullanmak, Logic App çözümlerinizin sadece çalışmasını sağlamakla kalmaz, aynı zamanda zorlu üretim ortamlarında güvenle yönetilebilmesini de sağlar.

Programatik yeniden gönderme yetenekleri, otomasyonunuzu bir sonraki seviyeye taşımanıza olanak tanır, böylece sistemleriniz kendi kendini iyileştiren (self-healing) özellikler kazanabilir. İdempotency prensiplerine uygun tasarım, gelişmiş hata işleme stratejileri ve Azure Monitor gibi araçlarla derinlemesine izleme entegrasyonu, Logic App tabanlı çözümlerinizin hem sağlam hem de şeffaf olmasını sağlar. Son olarak, mobil uyumlu yönetim ve log analizi yaklaşımları, operasyonel ekiplerin her yerden ve her zaman sistem durumunu kontrol etmesine olanak tanır. Unutmayın, iyi yönetilen bir otomasyon, yalnızca iş yükünü azaltmakla kalmaz, aynı zamanda iş süreçlerinizin genel güvenilirliğini ve sürdürülebilirliğini de artırır. Logic App yeniden gönderme yeteneklerini ustaca kullanarak, bulut otomasyonlarınızın tüm potansiyelini açığa çıkarabilirsiniz.

Sıkça Sorulan Sorular (SSS)

1. Logic App'i yeniden göndermek ne anlama geliyor?

Logic App'i yeniden göndermek, daha önce başarısız olan veya belirli bir nedenden dolayı tamamlanamayan bir iş akışı çalışmasını, genellikle orijinal giriş verileriyle veya küçük değişikliklerle tekrar çalıştırmak anlamına gelir. Bu, geçici hatalar, dış sistem kesintileri veya veri sorunları gibi durumlar için bir kurtarma mekanizmasıdır.

2. clientTrackingId ve sourceHistoryName arasındaki fark nedir?

clientTrackingId, her bir Logic App çalışmasına atanan benzersiz bir izleme kimliğidir ve tüm iş akışı adımları ile ilgili logları korele etmek için kullanılır. sourceHistoryName ise, yeniden gönderilen bir Logic App çalışmasının hangi orijinal (başarısız) çalışmadan türediğini belirten bir referanstır. clientTrackingId genel izlenebilirlik sağlarken, sourceHistoryName yeniden gönderme zincirindeki kökeni gösterir.

3. Yeniden gönderme sırasında tetikleyici yeniden çalışır mı?

Genellikle hayır. Bir Logic App çalışması yeniden gönderildiğinde, tetikleyici eylemi atlanır ve Logic App, orijinal çalışmanın tetikleyici çıktılarını kullanarak ilk eylemden devam eder. Ancak, eğer orijinal çalışma tetikleyici aşamasında başarısız olmuşsa (yani tetikleyici hiç tetiklenememişse), yeniden gönderme tetikleyiciyi yeniden deneyecektir.

4. Yeniden gönderme işlemini otomatik hale getirebilir miyim?

Evet, Azure Logic Apps REST API'si, Azure PowerShell veya Azure CLI'yı kullanarak yeniden gönderme işlemlerini programatik olarak otomatikleştirebilirsiniz. Bu, belirli hata koşullarına veya iş mantığına göre otomatik hata kurtarma sistemleri oluşturmanıza olanak tanır.

5. Yeniden göndermeyi kullanırken veri tekrarı (duplicate data) sorununu nasıl önleyebilirim?

Veri tekrarı sorununu önlemek için iş akışlarınızı idempotent (tekrarlanabilir) olacak şekilde tasarlamalısınız. Bu, aynı girişlerle birden fazla kez çalıştırıldığında sistem üzerinde aynı etkiyi yaratmaları gerektiği anlamına gelir. Bunu sağlamak için benzersiz anahtarlar kullanabilir, durum denetimleri yapabilir veya mevcut kayıtları güncelleyen işlemler tercih edebilirsiniz.

Aşağıdaki içerikler de ilgilinizi çekebilir:

Ollama ile H100 GPU’larda Büyük Dil Modellerini (LLM) Maksimum Verimlilikle Çalıştırmak

28 Ekim 2025

No Laying Up Podcast: The Booth Vol.23 & Trap Draw İncelemesi

28 Ekim 2025

WebGL: Tarayıcıda 3D Grafikler Oluşturmanın Gücü

28 Ekim 2025

İntentler ile Atomik Olmayan Eylemleri Atomik Yapmak: Kapsamlı Rehber

28 Ekim 2025