{"id":32965,"date":"2025-10-27T23:31:40","date_gmt":"2025-10-27T20:31:40","guid":{"rendered":"https:\/\/fatihsoysal.com\/blog\/logic-app-yeniden-gonderme-clienttrackingid-ve-sourcehistoryname-rehberi\/"},"modified":"2025-10-27T23:31:40","modified_gmt":"2025-10-27T20:31:40","slug":"logic-app-yeniden-gonderme-clienttrackingid-ve-sourcehistoryname-rehberi","status":"publish","type":"post","link":"https:\/\/fatihsoysal.com\/blog\/logic-app-yeniden-gonderme-clienttrackingid-ve-sourcehistoryname-rehberi\/","title":{"rendered":"Logic App Yeniden G\u00f6nderme: clientTrackingId ve sourceHistoryName Rehberi"},"content":{"rendered":"

<\/p>\n

Azure Logic Apps, i\u015f s\u00fcre\u00e7lerini otomatikle\u015ftirmek i\u00e7in g\u00fc\u00e7l\u00fc, bulut tabanl\u0131 bir platform sunar. Ancak, her zaman her \u015feyin sorunsuz gitmesi m\u00fcmk\u00fcn de\u011fildir. Bazen d\u0131\u015f sistemlerden kaynaklanan ge\u00e7ici hatalar, hatal\u0131 veri giri\u015fleri veya beklenmedik durumlar, Logic App i\u015f ak\u0131\u015flar\u0131n\u0131z\u0131n ba\u015far\u0131s\u0131z olmas\u0131na neden olabilir. \u0130\u015fte bu noktada, ba\u015far\u0131s\u0131z olan bir Logic App \u00e7al\u0131\u015fmas\u0131n\u0131 yeniden g\u00f6nderme yetene\u011fi kritik bir \u00f6neme sahiptir. Bu teknik makale, Logic Apps’te yeniden g\u00f6nderme (resubmission) davran\u0131\u015f\u0131n\u0131, \u00f6zellikle clientTrackingId<\/code> ve sourceHistoryName<\/code> parametreleri ba\u011flam\u0131nda detayl\u0131 bir \u015fekilde a\u00e7\u0131klayacakt\u0131r. Bu kavramlar\u0131 anlayarak, i\u015f ak\u0131\u015flar\u0131n\u0131zdaki hatalar\u0131 daha etkin bir \u015fekilde ay\u0131klayabilir, s\u00fcre\u00e7lerinizi daha tutarl\u0131 bir \u015fekilde izleyebilir ve sorun giderme s\u00fcre\u00e7lerinizi \u00f6nemli \u00f6l\u00e7\u00fcde h\u0131zland\u0131rabilirsiniz. Bu rehber, Logic Apps’e yeni ba\u015flayanlardan deneyimli geli\u015ftiricilere kadar her seviyeden okuyucuya hitap edecek \u015fekilde tasarlanm\u0131\u015ft\u0131r. Ba\u015far\u0131s\u0131z olan bir Logic App’i yeniden \u00e7al\u0131\u015ft\u0131rmak i\u00e7in hangi ad\u0131mlar\u0131 izlemeniz gerekti\u011fini ve bu s\u00fcre\u00e7te arka planda nelerin ger\u00e7ekle\u015fti\u011fini ad\u0131m ad\u0131m ke\u015ffedece\u011fiz. Gelin, bu karma\u015f\u0131k ama bir o kadar da g\u00fc\u00e7l\u00fc konuyu birlikte ayd\u0131nlatal\u0131m.<\/p>\n

Modern i\u015f s\u00fcre\u00e7leri genellikle birbirine ba\u011fl\u0131 bir\u00e7ok sistem ve hizmetten olu\u015fur. Bu karma\u015f\u0131k yap\u0131lar i\u00e7erisinde, bir otomasyon ak\u0131\u015f\u0131n\u0131n herhangi bir ad\u0131m\u0131nda ya\u015fanabilecek bir aksakl\u0131k, t\u00fcm s\u00fcrecin durmas\u0131na veya yanl\u0131\u015f sonu\u00e7lar \u00fcretmesine neden olabilir. Azure Logic Apps, bu t\u00fcr i\u015f ak\u0131\u015flar\u0131n\u0131 tasarlamak ve y\u00fcr\u00fctmek i\u00e7in esnek bir ortam sunsa da, d\u0131\u015f ba\u011f\u0131ml\u0131l\u0131klar veya \u00f6ng\u00f6r\u00fclemeyen durumlar nedeniyle i\u015f ak\u0131\u015flar\u0131n\u0131n ba\u015far\u0131s\u0131z olmas\u0131 ka\u00e7\u0131n\u0131lmazd\u0131r. Bir veritaban\u0131 ba\u011flant\u0131s\u0131n\u0131n anl\u0131k olarak kesilmesi, \u00fc\u00e7\u00fcnc\u00fc taraf bir API’nin ge\u00e7ici olarak yan\u0131t vermemesi, a\u011f sorunlar\u0131 veya i\u015flenen verilerdeki beklenmedik bir format hatas\u0131 gibi durumlar, bir Logic App \u00e7al\u0131\u015fmas\u0131n\u0131n ba\u015far\u0131s\u0131zl\u0131kla sonu\u00e7lanmas\u0131na yol a\u00e7abilir. Bu t\u00fcr durumlarda, t\u00fcm i\u015f ak\u0131\u015f\u0131n\u0131 en ba\u015ftan tetiklemek, zaman ve kaynak israf\u0131na yol a\u00e7abilir, \u00f6zellikle de sorunun temelinde yatan nedenin ge\u00e7ici oldu\u011fu biliniyorsa. \u0130\u015fte bu noktada Logic Apps’in “yeniden g\u00f6nderme” (resubmission) \u00f6zelli\u011fi devreye girer.<\/p>\n

Yeniden g\u00f6nderme, ba\u015far\u0131s\u0131z olan bir Logic App \u00e7al\u0131\u015fmas\u0131n\u0131, genellikle ayn\u0131 giri\u015f verileriyle veya k\u00fc\u00e7\u00fck ayarlamalarla tekrar deneme yetene\u011fidir. Bu \u00f6zellik, i\u015f ak\u0131\u015flar\u0131n\u0131z\u0131n dayan\u0131kl\u0131l\u0131\u011f\u0131n\u0131 ve hata tolerans\u0131n\u0131 \u00f6nemli \u00f6l\u00e7\u00fcde art\u0131r\u0131r. \u00d6rne\u011fin, bir sat\u0131\u015f sipari\u015fi i\u015fleme Logic App’iniz varsa ve bu uygulama, bir \u00f6deme a\u011f ge\u00e7idine ba\u011flan\u0131rken ge\u00e7ici bir hata nedeniyle ba\u015far\u0131s\u0131z olursa, sipari\u015fin yeniden manuel olarak olu\u015fturulmas\u0131 yerine, ba\u015far\u0131s\u0131z olan \u00e7al\u0131\u015fman\u0131n basit\u00e7e yeniden g\u00f6nderilmesi, s\u00fcreci devam ettirebilir. Bu, hem zaman kazand\u0131r\u0131r hem de manuel m\u00fcdahale ihtiyac\u0131n\u0131 azaltarak operasyonel verimlili\u011fi art\u0131r\u0131r. Ancak, yeniden g\u00f6nderme i\u015flemi basit bir “tekrar dene” d\u00fc\u011fmesi t\u0131klamas\u0131ndan \u00e7ok daha fazlas\u0131n\u0131 ifade eder. Arka planda, bu yeniden denemelerin nas\u0131l ili\u015fkilendirildi\u011fi, orijinal \u00e7al\u0131\u015fmayla ba\u011flant\u0131s\u0131n\u0131n nas\u0131l kuruldu\u011fu ve hata ay\u0131klama s\u00fcre\u00e7leri i\u00e7in hangi bilgilerin kullan\u0131labilece\u011fi gibi \u00f6nemli sorular ortaya \u00e7\u0131kar. Bu sorular\u0131n yan\u0131tlar\u0131, clientTrackingId<\/code> ve sourceHistoryName<\/code> gibi kritik parametrelerde yatar.<\/p>\n

clientTrackingId<\/code>, her bir Logic App \u00e7al\u0131\u015fmas\u0131na atanan benzersiz bir izleme kimli\u011fidir. Bu kimlik, farkl\u0131 sistemler veya loglar aras\u0131nda bir i\u015f ak\u0131\u015f\u0131n\u0131n t\u00fcm ya\u015fam d\u00f6ng\u00fcs\u00fcn\u00fc takip etmek i\u00e7in hayati \u00f6neme sahiptir. Bir e-ticaret sitesinden gelen sipari\u015fin, Logic App \u00fczerinden envanter sistemine, ard\u0131ndan faturaland\u0131rma hizmetine ve son olarak kargo \u015firketine iletilmesi gibi karma\u015f\u0131k bir senaryoda, clientTrackingId<\/code>, bu ad\u0131mlar\u0131n her birini tek bir mant\u0131ksal i\u015flem alt\u0131nda birle\u015ftirmemizi sa\u011flar. Ba\u015far\u0131s\u0131z bir \u00e7al\u0131\u015fman\u0131n yeniden g\u00f6nderilmesi durumunda, clientTrackingId<\/code>‘nin nas\u0131l davranaca\u011f\u0131, izlenebilirlik a\u00e7\u0131s\u0131ndan kritik bir fakt\u00f6rd\u00fcr. Benzer \u015fekilde, sourceHistoryName<\/code>, yeniden g\u00f6nderilen bir Logic App \u00e7al\u0131\u015fmas\u0131n\u0131n hangi orijinal ba\u015far\u0131s\u0131z \u00e7al\u0131\u015fmadan t\u00fcredi\u011fini g\u00f6steren bir referanst\u0131r. Bu parametre, \u00f6zellikle hata ay\u0131klama ve denetim (audit) s\u00fcre\u00e7lerinde, bir hatan\u0131n k\u00f6kenini h\u0131zl\u0131ca bulmak ve nedenini anlamak i\u00e7in paha bi\u00e7ilmez bilgiler sunar. \u0130lerleyen b\u00f6l\u00fcmlerde, bu iki \u00f6nemli kimli\u011fin Logic App yeniden g\u00f6nderme senaryolar\u0131nda nas\u0131l \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 ve onlar\u0131 nas\u0131l etkin bir \u015fekilde kullanabilece\u011fimizi daha detayl\u0131 inceleyece\u011fiz. Bu sayede, hem i\u015f ak\u0131\u015flar\u0131n\u0131z\u0131n g\u00fcvenilirli\u011fini art\u0131racak hem de sorun giderme yeteneklerinizi g\u00fc\u00e7lendireceksiniz.<\/p>\n

Logic Apps Temelleri ve \u0130zlenebilirli\u011fin \u00d6nemi: clientTrackingId Nedir?<\/h2>\n

Logic Apps d\u00fcnyas\u0131na ad\u0131m att\u0131\u011f\u0131m\u0131zda, kar\u015f\u0131m\u0131za \u00e7\u0131kan ilk kavramlar i\u015f ak\u0131\u015flar\u0131, tetikleyiciler ve eylemlerdir. Bir Logic App i\u015f ak\u0131\u015f\u0131, temelde bir dizi ad\u0131mdan olu\u015fan, belirli bir tetikleyici ile ba\u015flayan ve \u00e7e\u015fitli eylemleri s\u0131rayla veya paralel olarak y\u00fcr\u00fcten otomasyon s\u00fcrecidir. Tetikleyiciler (Triggers), bir Logic App’in ne zaman \u00e7al\u0131\u015faca\u011f\u0131n\u0131 belirleyen olaylard\u0131r. Bunlar bir HTTP iste\u011fi, belirli bir zaman \u00e7izelgesi, bir e-posta geldi\u011finde veya bir dosya depolama alan\u0131nda bir de\u011fi\u015fiklik oldu\u011funda tetiklenebilir. Eylemler (Actions) ise tetikleyici sonras\u0131nda veya di\u011fer eylemlerin ard\u0131ndan ger\u00e7ekle\u015ftirilen ad\u0131mlard\u0131r; \u00f6rne\u011fin bir veritaban\u0131na veri yazmak, bir e-posta g\u00f6ndermek, bir d\u0131\u015f API’yi \u00e7a\u011f\u0131rmak veya bir ko\u015fulu kontrol etmek gibi. Bu temel yap\u0131 ta\u015flar\u0131, i\u015f s\u00fcre\u00e7lerinin dijitalle\u015ftirilmesinde ve otomasyonunda b\u00fcy\u00fck esneklik sa\u011flar. Ancak, bu otomasyonlar\u0131n g\u00fcvenilirli\u011fini ve anla\u015f\u0131l\u0131rl\u0131\u011f\u0131n\u0131 sa\u011flamak, \u00f6zellikle hata ay\u0131klama ve izleme s\u00f6z konusu oldu\u011funda, belirli mekanizmalar gerektirir. \u0130\u015fte bu noktada clientTrackingId<\/code> gibi izleme kimlikleri devreye girer.<\/p>\n

clientTrackingId<\/code>, Azure Logic Apps’teki her bir i\u015f ak\u0131\u015f\u0131 \u00e7al\u0131\u015fmas\u0131na otomatik olarak atanan benzersiz bir GUID (Globally Unique Identifier) de\u011feridir. Bu kimlik, bir Logic App \u00e7al\u0131\u015fmas\u0131n\u0131n t\u00fcm ad\u0131mlar\u0131n\u0131, farkl\u0131 sistemler aras\u0131nda ve \u00e7e\u015fitli log kay\u0131tlar\u0131nda tek bir “korelasyon kimli\u011fi” alt\u0131nda birle\u015ftirmek i\u00e7in kullan\u0131l\u0131r. Bu sayede, karma\u015f\u0131k bir i\u015f ak\u0131\u015f\u0131, birden fazla Logic App’i, Azure Fonksiyonunu, Azure Service Bus’\u0131 veya ba\u015fka bir Azure kayna\u011f\u0131n\u0131 i\u00e7erse bile, t\u00fcm bu par\u00e7ac\u0131klar ayn\u0131 clientTrackingId<\/code> ile ili\u015fkilendirilebilir. Bu, u\u00e7tan uca izlenebilirlik (end-to-end traceability) sa\u011flaman\u0131n temelidir. \u00d6rne\u011fin, bir m\u00fc\u015fteri sipari\u015fi bir e-ticaret sisteminden geldi\u011finde, bu sipari\u015fin i\u015flenmesi i\u00e7in tetiklenen Logic App’in her ad\u0131m\u0131 (stok kontrol\u00fc, \u00f6deme, sevkiyat bildirimi) ayn\u0131 clientTrackingId<\/code> ile izlenebilir. E\u011fer herhangi bir ad\u0131mda bir hata olu\u015fursa, bu kimlik sayesinde ilgili t\u00fcm loglar\u0131 ve hata mesajlar\u0131n\u0131 kolayca bulabiliriz.<\/p>\n

Varsay\u0131lan olarak, Logic App bir tetikleyici taraf\u0131ndan her \u00e7al\u0131\u015ft\u0131r\u0131ld\u0131\u011f\u0131nda yeni ve benzersiz bir clientTrackingId<\/code> otomatik olarak olu\u015fturulur. Ancak, baz\u0131 senaryolarda, bu kimli\u011fi manuel olarak atamak isteyebiliriz. \u00d6zellikle d\u0131\u015f sistemlerden gelen olaylarla Logic App tetiklendi\u011finde ve bu d\u0131\u015f sistemin kendi benzersiz bir i\u015flem kimli\u011fi varsa, bu kimli\u011fi clientTrackingId<\/code> olarak kullanarak izlenebilirli\u011fi art\u0131rabiliriz. \u00d6rne\u011fin, bir HTTP iste\u011fi tetikleyicisi kullan\u0131yorsan\u0131z, iste\u011fin ba\u015fl\u0131klar\u0131na (headers) \u00f6zel bir clientTrackingId<\/code> ekleyebilirsiniz. Bu, Logic App \u00e7al\u0131\u015fmas\u0131n\u0131, istek g\u00f6nderen sistemdeki orijinal i\u015flemle do\u011frudan ili\u015fkilendirme imkan\u0131 sunar. A\u015fa\u011f\u0131daki kod blo\u011fu, bir HTTP tetikleyicisi kullan\u0131rken \u00f6zel bir clientTrackingId<\/code>‘nin nas\u0131l g\u00f6nderilebilece\u011fini g\u00f6stermektedir. Bu, hata ay\u0131klama s\u0131ras\u0131nda belirli bir iste\u011fin neden ba\u015far\u0131s\u0131z oldu\u011funu anlamak i\u00e7in b\u00fcy\u00fck kolayl\u0131k sa\u011flar ve \u00f6zellikle kurumsal d\u00fczeydeki entegrasyon senaryolar\u0131nda paha bi\u00e7ilmez bir ara\u00e7t\u0131r.<\/p>\n

{\n  \"trigger\": {\n    \"type\": \"HttpRequest\",\n    \"inputs\": {\n      \"method\": \"POST\",\n      \"relativePath\": \"\/processOrder\",\n      \"headers\": {\n        \"x-ms-client-tracking-id\": \"myCustomOrderID-12345\"\n      }\n    }\n  },\n  \"actions\": {\n    \"process_data\": {\n      \"type\": \"ApiConnection\",\n      \"inputs\": {\n        \"host\": {\n          \"connection\": {\n            \"name\": \"@parameters('$connections')['sql']['connectionId']\"\n          }\n        },\n        \"method\": \"post\",\n        \"path\": \"\/datasets\/@{encodeURIComponent('default')}\/tables\/@{encodeURIComponent('Orders')}\/items\",\n        \"body\": {\n          \"OrderID\": \"myCustomOrderID-12345\",\n          \"CustomerName\": \"John Doe\"\n        }\n      }\n    }\n  }\n}\n<\/pre>\n
<\/code><\/p>\n
Bu \u00f6rnekte, HTTP iste\u011finin ba\u015fl\u0131\u011f\u0131nda x-ms-client-tracking-id<\/code> \u00f6zel bir de\u011ferle ayarlanm\u0131\u015ft\u0131r. Logic App \u00e7al\u0131\u015ft\u0131\u011f\u0131nda, bu ba\u015fl\u0131k de\u011feri otomatik olarak Logic App'in clientTrackingId<\/code> olarak kabul edilecek ve Azure Monitor veya Application Insights gibi izleme ara\u00e7lar\u0131nda bu kimlik alt\u0131nda t\u00fcm loglar toplanacakt\u0131r. Yeniden g\u00f6nderme durumunda, orijinal clientTrackingId<\/code>'nin korunmas\u0131 veya yeni bir kimlik atanmas\u0131, izleme stratejiniz \u00fczerinde \u00f6nemli etkilere sahiptir. Genellikle, Logic App portal\u0131ndan manuel olarak yeniden g\u00f6nderilen bir \u00e7al\u0131\u015fma, orijinal clientTrackingId<\/code>'yi korurken, API arac\u0131l\u0131\u011f\u0131yla yap\u0131lan programatik yeniden g\u00f6ndermelerde bu kimli\u011fi manuel olarak kontrol etme esnekli\u011finiz bulunur. Bu esneklik, karma\u015f\u0131k hata kurtarma senaryolar\u0131nda, i\u015f ak\u0131\u015f\u0131n\u0131z\u0131n izlenebilirlik gereksinimlerine g\u00f6re uyarlanabilirlik sa\u011flar. B\u00f6ylece, Logic Apps'inizdeki herhangi bir aksakl\u0131\u011f\u0131 h\u0131zl\u0131ca tespit edebilir, nedenini anlayabilir ve \u00e7\u00f6z\u00fcme kavu\u015fturabilirsiniz.<\/p>\n
Yeniden G\u00f6nderme ve Kaynak Takibi: sourceHistoryName'in G\u00fcc\u00fc<\/h2>\n
clientTrackingId<\/code>'nin Logic App i\u015f ak\u0131\u015flar\u0131n\u0131n genel izlenebilirli\u011fini sa\u011flad\u0131\u011f\u0131n\u0131 anlam\u0131\u015ft\u0131k. \u015eimdi ise, \u00f6zellikle ba\u015far\u0131s\u0131z bir \u00e7al\u0131\u015fman\u0131n tekrar denendi\u011fi \"yeniden g\u00f6nderme\" (resubmission) senaryolar\u0131nda kritik bir rol oynayan sourceHistoryName<\/code> kavram\u0131na odaklanal\u0131m. Bir Logic App \u00e7al\u0131\u015fmas\u0131 ba\u015far\u0131s\u0131z oldu\u011funda, bu hatan\u0131n nedenini anlamak ve sorunu giderdikten sonra i\u015flemi yeniden ba\u015flatmak isteriz. Ancak, sadece i\u015f ak\u0131\u015f\u0131n\u0131 yeniden \u00e7al\u0131\u015ft\u0131rmak yeterli de\u011fildir; yeniden \u00e7al\u0131\u015ft\u0131r\u0131lan bu yeni i\u015f ak\u0131\u015f\u0131n\u0131n, hangi orijinal (ve ba\u015far\u0131s\u0131z) \u00e7al\u0131\u015fman\u0131n bir denemesi oldu\u011funu bilmek, hata ay\u0131klama, denetim ve izleme a\u00e7\u0131s\u0131ndan hayati \u00f6nem ta\u015f\u0131r. \u0130\u015fte sourceHistoryName<\/code> tam da bu ihtiyac\u0131 kar\u015f\u0131lar.<\/p>\n
sourceHistoryName<\/code>, yeniden g\u00f6nderilen bir Logic App \u00e7al\u0131\u015fmas\u0131n\u0131n, kaynakland\u0131\u011f\u0131 orijinal \u00e7al\u0131\u015fman\u0131n ge\u00e7mi\u015f kimli\u011fine (run history ID) referans veren bir parametredir. Yani, bir Logic App \u00e7al\u0131\u015fmas\u0131n\u0131 manuel olarak Azure portal\u0131 \u00fczerinden yeniden g\u00f6nderdi\u011finizde veya programatik olarak bir API \u00e7a\u011fr\u0131s\u0131 ile yeniden ba\u015flatt\u0131\u011f\u0131n\u0131zda, yeni olu\u015fturulan \u00e7al\u0131\u015fma, bu parametre sayesinde orijinal ba\u015far\u0131s\u0131z \u00e7al\u0131\u015fmayla ili\u015fkilendirilir. Bu ili\u015fki, hata ay\u0131klay\u0131c\u0131lar\u0131n, operasyon ekiplerinin ve denet\u00e7ilerin, bir hatan\u0131n tekrarlayan denemeler zincirindeki yerini ve evrimini anlamalar\u0131na olanak tan\u0131r. \u00d6rne\u011fin, bir veritaban\u0131 ba\u011flant\u0131 hatas\u0131 nedeniyle ba\u015far\u0131s\u0131z olan bir i\u015flemden sonra, ba\u011flant\u0131 sorununu giderip i\u015f ak\u0131\u015f\u0131n\u0131 yeniden ba\u015flatt\u0131\u011f\u0131n\u0131zda, yeni \u00e7al\u0131\u015fan i\u015f ak\u0131\u015f\u0131n\u0131n sourceHistoryName<\/code>'ine bakarak, onun ilk hatan\u0131n bir sonucu oldu\u011funu ve belirli bir hata kurtarma \u00e7abas\u0131n\u0131n par\u00e7as\u0131 oldu\u011funu h\u0131zl\u0131ca anlayabilirsiniz. Bu, bir olay\u0131n ya\u015fam d\u00f6ng\u00fcs\u00fcn\u00fc tam olarak takip etmek i\u00e7in g\u00fc\u00e7l\u00fc bir mekanizma sunar.<\/p>\n
Logic App portal\u0131ndan bir \u00e7al\u0131\u015fmay\u0131 yeniden g\u00f6ndermek olduk\u00e7a basittir. Ba\u015far\u0131s\u0131z olan bir \u00e7al\u0131\u015fma ge\u00e7mi\u015fini a\u00e7t\u0131\u011f\u0131n\u0131zda, genellikle \"Yeniden G\u00f6nder\" (Resubmit) d\u00fc\u011fmesini g\u00f6r\u00fcrs\u00fcn\u00fcz. Bu d\u00fc\u011fmeye t\u0131klad\u0131\u011f\u0131n\u0131zda, Logic App otomatik olarak yeni bir \u00e7al\u0131\u015fma ba\u015flat\u0131r ve bu yeni \u00e7al\u0131\u015fman\u0131n sourceHistoryName<\/code>'ini, yeniden g\u00f6nderdi\u011finiz orijinal \u00e7al\u0131\u015fman\u0131n kimli\u011fine (\u00f6rne\u011fin, 08587121234567890123456789012<\/code> gibi bir de\u011fer) ayarlar. Bu, Azure'\u0131n y\u00f6netti\u011fi otomatik bir s\u00fcre\u00e7tir ve \u00e7o\u011fu senaryo i\u00e7in yeterli izlenebilirli\u011fi sa\u011flar. Ancak, daha geli\u015fmi\u015f senaryolarda, \u00f6rne\u011fin otomatik hata kurtarma sistemleri kurarken, Logic App API'sini veya Azure CLI\/PowerShell komutlar\u0131n\u0131 kullanarak programatik olarak yeniden g\u00f6nderme yapman\u0131z gerekebilir. Bu durumlarda, sourceHistoryName<\/code> parametresini manuel olarak belirleme esnekli\u011finiz vard\u0131r. Bu, birden fazla Logic App'in birbirini tetikledi\u011fi veya farkl\u0131 sistemlerden gelen olaylarla karma\u015f\u0131k kurtarma mekanizmalar\u0131 uygulad\u0131\u011f\u0131n\u0131z senaryolarda \u00e7ok faydal\u0131d\u0131r. Do\u011fru sourceHistoryName<\/code>'i ayarlamak, yeniden g\u00f6nderilen \u00e7al\u0131\u015fman\u0131n neden ve hangi ba\u011flamda tetiklendi\u011fini anlaman\u0131za yard\u0131mc\u0131 olur, b\u00f6ylece denetim ve hata raporlama s\u00fcre\u00e7leri \u00e7ok daha anlaml\u0131 hale gelir.<\/p>\n
\n  Uzman \u0130pucu: Kurumsal uygulamalarda, yeniden g\u00f6nderme i\u015flemlerini otomatikle\u015ftirmek i\u00e7in Azure Functions veya Azure Event Grid ile entegrasyonlar d\u00fc\u015f\u00fcnebilirsiniz. Bu sayede, belirli hata kodlar\u0131na veya i\u015f ko\u015fullar\u0131na g\u00f6re dinamik olarak yeniden g\u00f6nderme kararlar\u0131 alabilir ve bu s\u00fcre\u00e7te clientTrackingId<\/code> ile sourceHistoryName<\/code>'i programatik olarak kontrol ederek eksiksiz izlenebilirlik sa\u011flayabilirsiniz. Bu t\u00fcr otomasyonlar, sistemlerinizin kendi kendini iyile\u015ftiren (self-healing) yeteneklerini \u00f6nemli \u00f6l\u00e7\u00fcde art\u0131r\u0131r.\n<\/div>\n
Vaka Analizi: Hatal\u0131 Veri D\u00f6n\u00fc\u015f\u00fcm\u00fcnde \u0130zlenebilirlik<\/h3>\n<\/p>\n
Bir e-ticaret platformundan gelen \u00fcr\u00fcn bilgilerini i\u015fleyen bir Logic App'iniz oldu\u011funu varsayal\u0131m. Bu Logic App, \u00fcr\u00fcn verilerini al\u0131r, belirli d\u00f6n\u00fc\u015f\u00fcmlerden ge\u00e7irir ve envanter veritaban\u0131na kaydeder. Bir g\u00fcn, d\u0131\u015f platformdan gelen \u00fcr\u00fcn verilerinden biri beklenenden farkl\u0131 bir formatta gelir (\u00f6rne\u011fin, fiyat alan\u0131 metin olarak gelirken say\u0131 beklenir) ve bu, Logic App'inizin veri d\u00f6n\u00fc\u015f\u00fcm eylemini ba\u015far\u0131s\u0131z k\u0131lar. \u0130lk \u00e7al\u0131\u015fma, bu format hatas\u0131 nedeniyle ba\u015far\u0131s\u0131z olur ve \"\u00c7al\u0131\u015fma Ge\u00e7mi\u015fi\"nde k\u0131rm\u0131z\u0131 bir uyar\u0131 ile g\u00f6sterilir. Operasyon ekibi sorunu tespit eder, veri kayna\u011f\u0131ndaki hatay\u0131 d\u00fczeltir ve ard\u0131ndan ba\u015far\u0131s\u0131z olan Logic App \u00e7al\u0131\u015fmas\u0131n\u0131 Azure portal\u0131ndan \"Yeniden G\u00f6nder\" d\u00fc\u011fmesini kullanarak tekrar dener. Bu yeni \u00e7al\u0131\u015fma ba\u015far\u0131yla tamamlan\u0131r. Bu senaryoda, yeni ba\u015far\u0131l\u0131 \u00e7al\u0131\u015fman\u0131n sourceHistoryName<\/code>'i, ilk ba\u015far\u0131s\u0131z \u00e7al\u0131\u015fman\u0131n kimli\u011fini i\u00e7erir. Bu sayede, hem ba\u015far\u0131l\u0131 hem de ba\u015far\u0131s\u0131z olan t\u00fcm denemeleri birbiriyle ili\u015fkilendirebilir ve bu \u00fcr\u00fcn verisi i\u00e7in ya\u015fanan problemin t\u00fcm evrimini tek bir yerden izleyebilirsiniz. Bu, hem sorunun k\u00f6k neden analizi i\u00e7in de\u011ferli bilgiler sunar hem de denetim s\u00fcre\u00e7lerinde, bir hatan\u0131n nas\u0131l giderildi\u011fini ve i\u015f ak\u0131\u015f\u0131n\u0131n nas\u0131l ba\u015far\u0131yla tamamland\u0131\u011f\u0131n\u0131 kan\u0131tlama yetene\u011fi sa\u011flar. Dolay\u0131s\u0131yla, sourceHistoryName<\/code>, Logic Apps'teki hata y\u00f6netimini ve izlenebilirli\u011fi derinlemesine kavrayarak, daha g\u00fcvenilir ve y\u00f6netilebilir otomasyonlar olu\u015fturman\u0131z i\u00e7in vazge\u00e7ilmez bir ara\u00e7t\u0131r.<\/p>\n
Logic App Yeniden G\u00f6nderme Mekanizmas\u0131: Ad\u0131m Ad\u0131m \u0130\u015fleyi\u015f ve Geli\u015fmi\u015f Senaryolar<\/h2>\n
Logic App yeniden g\u00f6nderme mekanizmas\u0131, basit bir \"tekrar dene\" komutundan daha fazlas\u0131n\u0131 i\u00e7erir ve bir i\u015f ak\u0131\u015f\u0131n\u0131n nas\u0131l \u00e7al\u0131\u015ft\u0131\u011f\u0131na dair \u00f6nemli detaylar\u0131 bar\u0131nd\u0131r\u0131r. Bu b\u00f6l\u00fcmde, yeniden g\u00f6nderme s\u00fcrecinin ad\u0131m ad\u0131m nas\u0131l i\u015fledi\u011fini, hangi verilerin tekrar kullan\u0131ld\u0131\u011f\u0131n\u0131 ve hangi k\u0131s\u0131mlar\u0131n yeniden de\u011ferlendirildi\u011fini derinlemesine inceleyece\u011fiz. Ayr\u0131ca, daha karma\u015f\u0131k senaryolar i\u00e7in programatik yeniden g\u00f6nderme y\u00f6ntemlerine ve parametrelerin nas\u0131l manip\u00fcle edilebilece\u011fine de\u011finece\u011fiz. Bu bilgiler, Logic App i\u015f ak\u0131\u015flar\u0131n\u0131zdaki ba\u015far\u0131s\u0131zl\u0131klar\u0131 daha bilin\u00e7li bir \u015fekilde y\u00f6netmenize ve hata ay\u0131klama s\u00fcre\u00e7lerinizi optimize etmenize yard\u0131mc\u0131 olacakt\u0131r.<\/p>\n
Yeniden G\u00f6nderme Y\u00f6ntemleri ve S\u00fcrecin Ba\u015flang\u0131c\u0131<\/h3>\n
Bir Logic App \u00e7al\u0131\u015fmas\u0131n\u0131 yeniden g\u00f6ndermenin \u00fc\u00e7 temel yolu vard\u0131r:<\/p>\n
    \n
  1. Azure Portal \u00dczerinden:<\/strong> En yayg\u0131n ve en basit y\u00f6ntemdir. Ba\u015far\u0131s\u0131z olan bir \u00e7al\u0131\u015fma ge\u00e7mi\u015fi g\u00f6r\u00fcn\u00fcm\u00fcnde \"Yeniden G\u00f6nder\" butonuna t\u0131klaman\u0131z yeterlidir. Bu y\u00f6ntemle, Logic App otomatik olarak orijinal tetikleyici giri\u015flerini kullanarak yeni bir \u00e7al\u0131\u015fma ba\u015flat\u0131r. clientTrackingId<\/code> genellikle korunur ve sourceHistoryName<\/code> orijinal \u00e7al\u0131\u015fman\u0131n kimli\u011fine ayarlan\u0131r.<\/li>\n
  2. REST API Kullanarak:<\/strong> Daha esnek ve otomatize edilmi\u015f senaryolar i\u00e7in Logic Apps REST API'si \u00fczerinden programatik olarak yeniden g\u00f6nderme yapabilirsiniz. Bu y\u00f6ntem, \u00f6zellikle belirli ko\u015fullara g\u00f6re otomatik hata kurtarma sistemleri veya toplu yeniden denemeler olu\u015fturmak istedi\u011finizde kullan\u0131\u015fl\u0131d\u0131r.<\/li>\n
  3. Azure PowerShell veya Azure CLI ile:<\/strong> REST API'ye sar\u0131lm\u0131\u015f komutlar arac\u0131l\u0131\u011f\u0131yla yeniden g\u00f6nderme yapma imkan\u0131 sunar. Script tabanl\u0131 otomasyonlar i\u00e7in idealdir.<\/li>\n<\/ol>\n
    Yeniden g\u00f6nderme i\u015flemi ba\u015flat\u0131ld\u0131\u011f\u0131nda, Logic App, orijinal \u00e7al\u0131\u015fman\u0131n tetikleyici ge\u00e7mi\u015fini ve giri\u015f verilerini inceler. Burada dikkat edilmesi gereken en \u00f6nemli nokta, Logic App'in yeniden g\u00f6nderme s\u0131ras\u0131nda tetikleyiciyi yeniden de\u011ferlendirip de\u011ferlendirmeyece\u011fidir. Varsay\u0131lan olarak, Logic App'in tetikleyici k\u0131sm\u0131, orijinal \u00e7al\u0131\u015fman\u0131n tetikleyici girdileriyle atlan\u0131r ve do\u011frudan tetikleyicinin \u00e7\u0131kt\u0131lar\u0131n\u0131 kullanarak ilk eylemden devam eder. Bu, \u00f6zellikle zamana dayal\u0131 veya olay tabanl\u0131 tetikleyiciler i\u00e7in \u00f6nemlidir, \u00e7\u00fcnk\u00fc tetikleyicinin yeniden \u00e7al\u0131\u015ft\u0131r\u0131lmas\u0131 istenmeyen yan etkilere neden olabilir (\u00f6rne\u011fin, ayn\u0131 olay\u0131n iki kez i\u015flenmesi).<\/p>\n
    Tetikleyici Durumlar\u0131n\u0131n Rol\u00fc ve Veri Ak\u0131\u015f\u0131<\/h3>\n
    Yeniden g\u00f6nderme s\u0131ras\u0131nda, Logic App motoru orijinal \u00e7al\u0131\u015fman\u0131n tetikleyici durumunu kontrol eder. E\u011fer tetikleyici, ba\u015far\u0131l\u0131 bir \u015fekilde tetiklenmi\u015f ve \u00e7\u0131kt\u0131 \u00fcretmi\u015fse, yeniden g\u00f6nderme i\u015flemi bu \u00e7\u0131kt\u0131lar\u0131 do\u011frudan al\u0131r ve ilk eyleme iletir. Yani, tetikleyici eylemi yeniden y\u00fcr\u00fct\u00fclmez. Ancak, e\u011fer orijinal \u00e7al\u0131\u015fma tetikleyici a\u015famas\u0131nda ba\u015far\u0131s\u0131z olmu\u015fsa (\u00f6rne\u011fin, bir HTTP iste\u011fi tetikleyicisi hi\u00e7 yan\u0131t alamam\u0131\u015fsa), yeniden g\u00f6nderme tetikleyiciyi yeniden deneyecektir. Bu ayr\u0131m, idempotency (tekrarlanabilirlik) ve veri tutarl\u0131l\u0131\u011f\u0131 a\u00e7\u0131s\u0131ndan kritik \u00f6neme sahiptir.<\/p>\n
    clientTrackingId<\/code> ve sourceHistoryName<\/code> bu s\u00fcre\u00e7te nas\u0131l davran\u0131r? Daha \u00f6nce de belirtildi\u011fi gibi, Azure Portal \u00fczerinden yap\u0131lan yeniden g\u00f6ndermelerde clientTrackingId<\/code> genellikle orijinal kimlikle ayn\u0131 kal\u0131r. Bu, yeniden denenen i\u015f ak\u0131\u015f\u0131n\u0131n hala ayn\u0131 mant\u0131ksal i\u015flemin bir par\u00e7as\u0131 oldu\u011funu g\u00f6sterir. sourceHistoryName<\/code> ise, yeni \u00e7al\u0131\u015fman\u0131n orijinal ba\u015far\u0131s\u0131z \u00e7al\u0131\u015fmaya bir referans olarak atan\u0131r. Programatik olarak yeniden g\u00f6nderme yaparken, hem clientTrackingId<\/code>'yi hem de sourceHistoryName<\/code>'i kendi ihtiya\u00e7lar\u0131n\u0131za g\u00f6re belirleme esnekli\u011finiz vard\u0131r. Bu, denetim veya \u00f6zel hata raporlama gereksinimleriniz oldu\u011funda \u00e7ok g\u00fc\u00e7l\u00fc bir \u00f6zelliktir. \u00d6rne\u011fin, belirli bir hata nedeniyle otomatik olarak yeniden g\u00f6nderilen \u00e7al\u0131\u015fmalara \u00f6zel bir clientTrackingId<\/code> \u00f6neki ekleyebilir veya sourceHistoryName<\/code>'i, birden fazla Logic App'i i\u00e7eren karma\u015f\u0131k bir kurtarma i\u015f ak\u0131\u015f\u0131ndaki ana i\u015flem kimli\u011fine ayarlayabilirsiniz.<\/p>\n
    Programatik Yeniden G\u00f6nderme \u00d6rne\u011fi<\/h3>\n
    Azure REST API'sini kullanarak bir Logic App \u00e7al\u0131\u015fmas\u0131n\u0131 programatik olarak nas\u0131l yeniden g\u00f6nderece\u011finize dair basit bir \u00f6rnek a\u015fa\u011f\u0131dad\u0131r. Bu, genellikle PowerShell veya di\u011fer programlama dilleri arac\u0131l\u0131\u011f\u0131yla \u00e7a\u011fr\u0131l\u0131r:<\/p>\n
    # De\u011fi\u015fkenlerinizi ayarlay\u0131n\n$resourceGroupName = \"MyLogicAppResourceGroup\"\n$logicAppName = \"MyOrderProcessingLogicApp\"\n$runId = \"08587121234567890123456789012\" # Yeniden g\u00f6ndermek istedi\u011finiz ba\u015far\u0131s\u0131z Logic App \u00e7al\u0131\u015fmas\u0131n\u0131n kimli\u011fi\n$subscriptionId = \"YOUR_SUBSCRIPTION_ID\"\n$accessToken = (Get-AzAccessToken).Token # Azure'a kimlik do\u011frulamas\u0131 yap\u0131lm\u0131\u015f olmal\u0131\n\n$uri = \"https:\/\/management.azure.com\/subscriptions\/$subscriptionId\/resourceGroups\/$resourceGroupName\/providers\/Microsoft.Logic\/workflows\/$logicAppName\/runs\/$runId\/resubmit?api-version=2019-05-01\"\n\n$headers = @{\n    \"Authorization\" = \"Bearer $accessToken\"\n    \"Content-Type\" = \"application\/json\"\n    \"x-ms-client-tracking-id\" = \"CustomResubmit-$((Get-Date).Ticks)\" # \u0130ste\u011fe ba\u011fl\u0131 \u00f6zel clientTrackingId\n    \"x-ms-source-history-name\" = $runId # Bu, varsay\u0131lan olarak API taraf\u0131ndan eklenir, ancak manuel de eklenebilir.\n}\n\nInvoke-RestMethod -Uri $uri -Method POST -Headers $headers\n<\/pre>\n
    <\/code><\/p>\n
    Bu \u00f6rnekte, Invoke-RestMethod<\/code> kullanarak belirli bir Logic App \u00e7al\u0131\u015fmas\u0131n\u0131 yeniden g\u00f6nderiyoruz. x-ms-client-tracking-id<\/code> ba\u015fl\u0131\u011f\u0131n\u0131 kullanarak iste\u011fe ba\u011fl\u0131 olarak \u00f6zel bir izleme kimli\u011fi atayabiliriz. Bu, programatik kontrol\u00fcn g\u00fcc\u00fcn\u00fc g\u00f6stermektedir. Bu t\u00fcr programatik yetenekler sayesinde, hatal\u0131 durumdaki i\u015f ak\u0131\u015flar\u0131n\u0131 otomatik olarak tespit edip yeniden ba\u015flatabilen, b\u00f6ylece operasyonel m\u00fcdahale gereksinimini minimuma indiren karma\u015f\u0131k otomasyon \u00e7\u00f6z\u00fcmleri geli\u015ftirebilirsiniz. Yeniden g\u00f6nderme mekanizmas\u0131n\u0131 ve parametrelerini do\u011fru anlamak, Logic App tabanl\u0131 \u00e7\u00f6z\u00fcmlerinizin hem daha dayan\u0131kl\u0131 hem de daha \u015feffaf olmas\u0131n\u0131 sa\u011flar.<\/p>\n
    En \u0130yi Uygulamalar, Hata Ay\u0131klama \u0130pu\u00e7lar\u0131 ve Mobil Uyumlu Y\u00f6netim<\/h2>\n
    Logic Apps'te yeniden g\u00f6nderme yetene\u011fi g\u00fc\u00e7l\u00fc bir ara\u00e7 olsa da, bu yetene\u011fi etkin ve verimli kullanmak i\u00e7in belirli en iyi uygulamalar\u0131 ve geli\u015fmi\u015f teknikleri bilmek \u00f6nemlidir. \u0130\u015f ak\u0131\u015flar\u0131n\u0131z\u0131 tasarlarken, y\u00f6netirken ve hatalar\u0131n\u0131 ay\u0131klarken izleyece\u011finiz stratejiler, \u00e7\u00f6z\u00fcm\u00fcn\u00fcz\u00fcn genel g\u00fcvenilirli\u011fini ve s\u00fcrd\u00fcr\u00fclebilirli\u011fini belirler. Ayr\u0131ca, g\u00fcn\u00fcm\u00fcz\u00fcn mobil odakl\u0131 d\u00fcnyas\u0131nda, Logic App \u00e7\u00f6z\u00fcmlerinin y\u00f6netim ve izleme aray\u00fczlerinin mobil cihazlarda da sorunsuz \u00e7al\u0131\u015fabilmesi, operasyonel ekipler i\u00e7in b\u00fcy\u00fck kolayl\u0131k sa\u011flar.<\/p>\n
    \u0130dempotency ve Hata \u0130\u015fleme Stratejileri<\/h3>\n
    Yeniden g\u00f6nderme i\u015flemleri i\u00e7in en \u00f6nemli tasar\u0131m prensiplerinden biri idempotency<\/strong>'dir. \u0130dempotent bir i\u015flem, ayn\u0131 girdilerle birden fazla kez \u00e7al\u0131\u015ft\u0131r\u0131ld\u0131\u011f\u0131nda, sistem \u00fczerinde yaln\u0131zca bir kez \u00e7al\u0131\u015ft\u0131r\u0131lm\u0131\u015f gibi ayn\u0131 sonucu \u00fcretir. Yani, ayn\u0131 i\u015flemi iki kez ger\u00e7ekle\u015ftirmek, bir kez ger\u00e7ekle\u015ftirmekle ayn\u0131 etkiyi yarat\u0131r. \u00d6rne\u011fin, bir veritaban\u0131na yeni bir kay\u0131t ekleyen bir Logic App eylemi, e\u011fer ikinci kez \u00e7al\u0131\u015ft\u0131r\u0131ld\u0131\u011f\u0131nda \u00e7ift kay\u0131t (duplicate entry) olu\u015fturuyorsa idempotent de\u011fildir. Ancak, mevcut bir kayd\u0131 g\u00fcncelleyen bir eylem genellikle idempotent olabilir. Logic App'lerinizi idempotent olacak \u015fekilde tasarlamak, yeniden g\u00f6nderme veya otomatik tekrar deneme durumlar\u0131nda istenmeyen yan etkilerin (\u00f6rne\u011fin, \u00e7ift \u00f6demeler, yanl\u0131\u015f stok g\u00fcncellemeleri) \u00f6n\u00fcne ge\u00e7er. Bunu sa\u011flamak i\u00e7in:<\/p>\n
      \n
    • Benzersiz anahtarlar (Unique keys) kullanarak veri ekleme\/g\u00fcncelleme i\u015flemlerini y\u00f6netin.<\/li>\n
    • \u0130\u015flem durumlar\u0131n\u0131 takip eden bir denetim tablosu kullan\u0131n ve bir i\u015flemin zaten tamamlan\u0131p tamamlanmad\u0131\u011f\u0131n\u0131 kontrol edin.<\/li>\n
    • If-Match<\/code> veya If-None-Match<\/code> gibi HTTP ba\u015fl\u0131klar\u0131n\u0131 kullanarak \u00e7ak\u0131\u015fmalar\u0131 \u00f6nleyin.<\/li>\n<\/ul>\n
      Hata i\u015fleme stratejileri de kritik \u00f6neme sahiptir. Logic Apps, eylemlere \"retry policy\" (yeniden deneme politikas\u0131) atama ve \"scope\" (kapsam) kullanarak hata yakalama imkan\u0131 sunar. Ge\u00e7ici a\u011f hatalar\u0131 gibi durumlarda yeniden deneme politikalar\u0131 yeterli olabilirken, i\u015f mant\u0131\u011f\u0131 hatalar\u0131 veya d\u0131\u015f sistemlerden gelen kal\u0131c\u0131 sorunlar i\u00e7in kapsamlar ve \"Configure run after\" (sonra \u00e7al\u0131\u015ft\u0131r\u0131 yap\u0131land\u0131r) \u00f6zellikleri ile daha sofistike hata i\u015fleme ak\u0131\u015flar\u0131 tasarlayabilirsiniz. \u00d6rne\u011fin, bir API \u00e7a\u011fr\u0131s\u0131 ba\u015far\u0131s\u0131z olursa, bir e-posta g\u00f6nderebilir veya sorunu otomatik olarak d\u00fczeltmeye \u00e7al\u0131\u015fan ba\u015fka bir Logic App'i tetikleyebilirsiniz.<\/p>\n
      \n  Uzman \u0130pucu: Her Logic App eylemi i\u00e7in varsay\u0131lan bir yeniden deneme politikas\u0131 bulunur. Performans ve dayan\u0131kl\u0131l\u0131k aras\u0131nda bir denge kurarak bu politikalar\u0131 \u00f6zel ihtiya\u00e7lar\u0131n\u0131za g\u00f6re ayarlay\u0131n. Uzun s\u00fcreli gecikmeler veya b\u00fcy\u00fck y\u00fckler i\u00e7in \u00fcstel geri \u00e7ekilme (exponential backoff) stratejisi genellikle en iyisidir.\n<\/div>\n
      Geli\u015fmi\u015f \u0130zleme ve Hata Ay\u0131klama \u0130pu\u00e7lar\u0131<\/h3>\n
      clientTrackingId<\/code> ve sourceHistoryName<\/code>, Logic Apps'in yerle\u015fik izleme ara\u00e7lar\u0131nda (\u00c7al\u0131\u015fma Ge\u00e7mi\u015fi, Tetikleyici Ge\u00e7mi\u015fi) zaten g\u00f6r\u00fcn\u00fcr. Ancak, daha derinlemesine analiz i\u00e7in Azure Monitor ve Application Insights gibi hizmetlerle entegrasyon kurmak \u00e7ok faydal\u0131d\u0131r. Bu hizmetler:<\/p>\n
        \n
      • Merkezi Loglama:<\/strong> Logic App loglar\u0131n\u0131 di\u011fer Azure kaynaklar\u0131n\u0131zla (Azure Functions, API Management vb.) tek bir yerde toplar.<\/li>\n
      • Korelasyon ID'leri:<\/strong> clientTrackingId<\/code>'yi kullanarak farkl\u0131 hizmetler aras\u0131ndaki olaylar\u0131 ili\u015fkilendirebilir ve u\u00e7tan uca i\u015flemin tam bir g\u00f6r\u00fcn\u00fcm\u00fcn\u00fc elde edebilirsiniz.<\/li>\n
      • Uyar\u0131lar ve Metrikler:<\/strong> \u0130\u015f ak\u0131\u015flar\u0131n\u0131z\u0131n performans\u0131 ve hata oranlar\u0131 hakk\u0131nda uyar\u0131lar olu\u015fturabilir, \u00f6zel metrikler toplayabilirsiniz.<\/li>\n
      • Sorgu Dili (KQL):<\/strong> G\u00fc\u00e7l\u00fc Kusto Query Language (KQL) kullanarak loglar \u00fczerinde karma\u015f\u0131k sorgular \u00e7al\u0131\u015ft\u0131rabilir, belirli hata paternlerini veya yeniden g\u00f6nderme zincirlerini kolayca bulabilirsiniz.<\/li>\n<\/ul>\n
        Hata ay\u0131klama yaparken, clientTrackingId<\/code>'yi bir filtre olarak kullanmak, ilgili t\u00fcm log kay\u0131tlar\u0131n\u0131 ve \u00e7al\u0131\u015fma ge\u00e7mi\u015flerini h\u0131zl\u0131ca bulman\u0131za yard\u0131mc\u0131 olur. \u00d6zellikle yeniden g\u00f6nderilen bir \u00e7al\u0131\u015fma s\u00f6z konusu oldu\u011funda, sourceHistoryName<\/code>'i kullanarak orijinal ba\u015far\u0131s\u0131z \u00e7al\u0131\u015fmay\u0131 tespit edebilir ve hatan\u0131n k\u00f6k nedenini daha h\u0131zl\u0131 anlayabilirsiniz. Azure portal\u0131ndaki \"\u00c7al\u0131\u015fma Ge\u00e7mi\u015fi\" g\u00f6r\u00fcn\u00fcm\u00fcnde, ba\u015far\u0131s\u0131z bir ad\u0131m\u0131 t\u0131klayarak hatan\u0131n detaylar\u0131n\u0131 ve o ad\u0131ma giren ve \u00e7\u0131kan verileri incelemek, sorunu anlamak i\u00e7in ilk ad\u0131md\u0131r.<\/p>\n
        Mobil Uyumlu Y\u00f6netim ve Analiz<\/h3>\n
        Modern DevOps ve operasyonel ekipler, genellikle hareket halindeyken sistemlerini izleme ve y\u00f6netme ihtiyac\u0131 duyarlar. Azure portal\u0131, mobil cihazlar \u00fczerinden de eri\u015filebilir olsa da, karma\u015f\u0131k log analizleri ve detayl\u0131 i\u015f ak\u0131\u015f\u0131 denetimleri i\u00e7in tam bir taray\u0131c\u0131 deneyimi gerektirebilir. Ancak, y\u00f6netim konsollar\u0131n\u0131n ve log aray\u00fczlerinin mobil uyumlu (responsive) HTML ile tasarlanmas\u0131, deneyimi \u00f6nemli \u00f6l\u00e7\u00fcde iyile\u015ftirir.<\/p>\n
        Logic Apps'in \u00e7al\u0131\u015fma ge\u00e7mi\u015fi ve izleme verileri, Azure Mobil Uygulamas\u0131 \u00fczerinden s\u0131n\u0131rl\u0131 bir \u015fekilde g\u00f6r\u00fcnt\u00fclenebilir. Daha geli\u015fmi\u015f mobil uyumlu \u00e7\u00f6z\u00fcmler i\u00e7in:<\/p>\n
          \n
        • \u00d6zel Panolar:<\/strong> Azure Dashboard'lar\u0131 veya \u00f6zel Power BI panolar\u0131 olu\u015fturarak \u00f6nemli metrikleri ve uyar\u0131lar\u0131 mobil cihazlarda optimize edilmi\u015f bir \u015fekilde g\u00f6r\u00fcnt\u00fcleyebilirsiniz. Bu panolar, clientTrackingId<\/code> ve sourceHistoryName<\/code> gibi kritik izleme verilerini \u00f6zetleyebilir.<\/li>\n
        • Log Analizi Ara\u00e7lar\u0131:<\/strong> Azure Monitor Log Analytics'in kendi web aray\u00fcz\u00fc responsive bir tasar\u0131ma sahiptir, ancak karma\u015f\u0131k KQL sorgular\u0131 mobil klavyelerle yazmak zor olabilir. Mobil dostu bir aray\u00fcz i\u00e7in \u00f6nceden tan\u0131mlanm\u0131\u015f KQL sorgular\u0131 i\u00e7eren basit web uygulamalar\u0131 geli\u015ftirebilirsiniz.<\/li>\n
        • Bildirimler:<\/strong> Logic App hatalar\u0131 veya yeniden g\u00f6nderme durumlar\u0131 i\u00e7in Azure Monitor uyar\u0131lar\u0131n\u0131 mobil bildirimlerle (e-posta, SMS, Azure Mobile App push bildirimleri) entegre edin. Bu sayede, \u00f6nemli olaylardan an\u0131nda haberdar olabilirsiniz.<\/li>\n<\/ul>\n
          Bir web uygulamas\u0131 tasarlarken, mobil uyumluluk i\u00e7in HTML ve CSS'i do\u011fru kullanmak esast\u0131r. \u00d6rne\u011fin, bir log tablosunu mobil cihazda d\u00fczg\u00fcn g\u00f6r\u00fcnt\u00fclemek i\u00e7in a\u015fa\u011f\u0131daki gibi basit bir CSS yakla\u015f\u0131m\u0131 d\u00fc\u015f\u00fcn\u00fclebilir:<\/p>\n
          \n  \n    \n      \n        \n      \n    <\/tbody>\n  <\/table>\n<\/div>\n\n\n
          clientTrackingId<\/th>\n        sourceHistoryName<\/th>\n        Durum<\/th>\n        Zaman<\/th>\n      <\/tr>\n    <\/thead>\n