Yapay zekâ tarafından English dilinden çevrildi ·
Akışları oluşturanlar için 2.1.1 sürümünde üç değişiklik.Gizli anahtarlar HTTP isteği alanlarında ada göre. Bir HTTP isteği alanı artık bir gizli anahtarı adıyla gösterebilir ve değer sunucuda doldurulur. Bir çağrının adresi ve kimlik doğrulaması hâlâ uç nokta bağlantısından gelir, bkz. Bağlantılar ve gizli anahtarlar.Kalıcı webhook tetikleyicileri. Webhook tetikleyicileri artık kalıcı olarak saklanıyor ve bir kesintinin ardından otomatik olarak onarılıyor.Bildirimler için teslimat raporları. Bildirimler artık bastırılan veya başarısız olan teslimatları raporluyor; böylece gelen kutusuna bakıp tahmin yürütmek yerine hangi iletilerin gönderilmediğini görebilirsiniz. Bir akışta Notify bloğunun sonucu sayıları taşır (iletilen, başarısız, bastırılan ve diğerleri); e-posta, SMS, push ve sohbet teslimatları için bildirim günlüğü mevcuttur.
Three changes in 2.1.1 for people who build flows.
Secrets by name in HTTP request fields. An HTTP request field can now refer to a secret by its name, and the value is filled in on the server. The address and the authentication of a call still come from its endpoint connection, see Connections and secrets.
Durable webhook triggers. Webhook triggers are now stored durably and repaired automatically after an outage.
Delivery reports for notifications. Notifications now report the deliveries that were suppressed or failed, so you can see what did not go out instead of guessing from the inbox. In a flow, the Notify block’s result carries the counts (delivered, failed, suppressed and the rest); for mail, SMS, push and chat deliveries there is the notification log.
Yapay zekâ tarafından English dilinden çevrildi ·
Bir tedarikçi API’sine, anahtarı özel bir başlık satırında (X-Api-Key) göndererek veri gönderen bir akışımız var. Bu anahtar yeni adlandırılmış gizli anahtara mı taşınmalı, yoksa başka bir yere mi?
We have a flow that posts to a supplier API with the key in a custom header row (X-Api-Key). Should that move to the new named secret, or somewhere else?
Yapay zekâ tarafından English dilinden çevrildi ·
Başlıkta sabit bir anahtar için, bunu HTTP uç nokta bağlantısına koyardım: kimlik doğrulama türü header, header_name X-Api-Key ve değer header_value alanına girilir; bu değer gizli bilgi olarak saklanır. Bu durumda blok yalnızca bağlantıyı adlandırır ve bloğun headers bölümündeki satır kaldırılabilir.Kaydettikten sonra alanda “Bir değer saklanmış. Korumak için boş bırakın.” yazısı görünür ve değer hiçbir çalışma kaydına, günlüğe veya dışa aktarıma ulaşmaz. Akışı daha sonra dışa aktarırsanız, içe aktaran kişinin gizli bilgiyi yeniden girmesi gerekir.
For a fixed key in a header I’d put it on the HTTP endpoint connection: auth type header, header_name X-Api-Key, and the value goes in header_value, which is stored as a secret. Then the block only names the connection and the row in the block’s headers can go.
After saving, the field shows “A value is stored. Leave empty to keep it.” and the value never reaches a run record, a log or an export. If you export the flow later, the importer has to type the secret again.
Yapay zekâ tarafından English dilinden çevrildi ·
Webhook kısmıyla ilgili bir sorum var. “Bir kesintiden sonra onarıldı” ifadesi, kesinti sırasında gelen çağrıların daha sonra çalıştırılacağı anlamına mı geliyor, yoksa yalnızca tetikleyicinin kendiliğinden geri döneceği anlamına mı geliyor?
Question on the webhook part. Does “repaired after an outage” mean the calls that came in during the outage get run afterwards, or only that the trigger comes back by itself?
Yapay zekâ tarafından English dilinden çevrildi ·
Değişiklik günlüğü satırı tetikleyicinin kendisiyle ilgili: tetikleyici kalıcı olarak saklanır ve bir kesintiden sonra otomatik olarak onarılır.Çağrıların kendisine gelince, kesinti sırasında yaşam süresini (time-to-live) aşarak bekleyen bir webhook çağrısı kendi başına çalıştırılmaz. “Bekleme süresi aşıldı” nedeniyle Başarısız mesajlar alanına gider ve Yeniden oynat ile çalıştırılır. Yeniden oynatma orijinal kimlikleri korur, giden bloklar aynı idempotency anahtarını gönderir; çağrı yaptığınız sistem bunu tekilleştiriyorsa çağrıyı yalnızca bir kez görür. Ayrıntılar: Korumalar ve başarısız mesajlar.
The changelog line is about the trigger itself: it’s stored durably and repaired automatically after an outage.
For the calls themselves, a webhook call that waited longer than its time-to-live during an outage isn’t run on its own. It goes to Failed messages with the reason “Waited too long”, and Replay runs it. Replay keeps the original ids, and the outbound blocks send the same idempotency key, so if the system you call deduplicates it sees the call once. Details in Protections and failed messages.
Yapay zekâ tarafından English dilinden çevrildi ·
Alarm bildirimleri için bastırılmış olanları nerede görebilirim? Bunları bir flow üzerinden göndermiyoruz.
Where do I see suppressed ones for alarm notifications? We don’t send those from a flow.
Yapay zekâ tarafından English dilinden çevrildi ·
Alarmın zaman çizelgesinde. Burada Bildirildi ifadesi alıcı ve kanal sayısıyla birlikte görünür; sınırlama bir bildirimi geri tuttuğunda “Bildirim geri tutuldu” ve kimseye bildirim gönderilmediğinde Sessize alındı görünür.Bildirim günlüğünde yalnızca yapılmış denemeler bulunur (alıcı ve kanal başına gönderildi, başarısız veya beklemede). Deneme yapılmadan önce geri tutulan bir şey (bir tercih, sessiz saatler, tekrar penceresi ya da sessize alma nedeniyle) bu aşamaya ulaşmadığı için günlükte yer almaz; bu kararlar bunun yerine alarm zaman çizelgesinde gösterilir.
On the alarm’s timeline. It shows Notified with the number of recipients and channels, “Notification held back” when the throttle kept one back, and Muted when nobody was told.
The notification log only has attempts that were made (sent, failed or pending per recipient and channel). Something held back before it was attempted (by a preference, quiet hours, the repeat window or a mute) never got that far, so it is not in the log; those decisions show on the alarm timeline instead.
- Bu konuyu yanıtlamak için giriş yapmış olmalısınız.
Sohbete katılın
Soru sormak ve yanıtlamak, yararlı gönderileri beğenmek ve sorununuzu çözen yanıtı işaretlemek için oturum açın. Her katkı puan ve seviye kazandırır.