Mule 4 ile kullanımı daha kolay olan yeni bir Hata Yönetimi kavramı gelmektedir. Artık her bileşen atabileceği hata türlerini bildiriyor ve tüm hataları, namespace “:” ile ayrılmış bir identifier ile hata türlerine göre yapılandırmıştır. Bu nedenle, hata türünü belirlemek (örneğin HTTP:CONNECTIVITY, DB:CONNECTIVITY vb.) ve buna göre işlem yapmak kolaydır.

Tüm hata türleri aşağıdaki hiyerarşiyi takip eder.

Tüm hatalar ya genel ya da CRITICAL’dır. Genel hiyerarşinin en üstünde, altındaki tüm türlerle eşleşmeye izin veren ANY hata tipi yer alır.

Başarısızlık için net bir neden bulunamadığında kullanılan UNKNOWN türüne dikkat etmek önemlidir. Bu hata, mevcut uygulamanın davranışını değiştirmeden gelecekte belirsiz hataların belirtilmesine izin vermek için yalnızca ANY türü aracılığıyla ele alınabilir.

Bağlayıcılar (Connectors) söz konusu olduğunda, her bağlayıcı kendi hata türü hiyerarşisini çalışma zamanı hiyerarşisini dikkate alarak tanımlar, ancak CONNECTIVITY ve RETRY_EXHAUSTED türleri tüm bağlayıcılar için ortak olduğundan her zaman mevcuttur.

Mulesoft ’ta hataları aşağıdaki gibi tanımlamanın genel olarak iki yolu vardır.

• Message Level Errors — Mule mesajı söz konusu olduğunda ortaya çıkar. Örneğin, Database sorgularında hata oluştuğunda veya harici bir API çağrılırken hata oluştuğunda (HTTP:CONNECTIVITY, DB:CONNECTIVITY, HTTP:UNAUTHORIZED) listeleyebilirsiniz.
• System Level Error — Herhangi bir Mule mesajı söz konusu olmadığında karşılabilirisiniz. Örneğin, bir JMS sağlayıcısında bağlantı sorunu olduğunda veya Veritabanında bağlantı sorunu oluştuğunda karşılaşırsınız.

Description: HTTP GET on resource ‘http://localhost:36682/testPath’ failed: unauthorized (401)

Type: HTTP:UNAUTHORIZED

Cause: a ResponseValidatorTypedException instance

Error Message: { “message” : “Could not authorize the user.” }

Yukarıdaki örnekte, hata türü HTTP:UNAUTHORIZED ’dır, sadece UNAUTHORIZED değildir. Hata türleri hem bir namespace (etki alanı) hem de bir identifier (tanımlayıcı) dan oluşur ve türleri etki alanlarına göre ayırt etmenizi sağlar (örneğin, HTTP:NOT_FOUND ve FILE:NOT_FOUND).

Hata türlerinin bir diğer önemli özelliği de bir üst türe sahip olabilmeleridir. Örneğin, HTTP:UNAUTHORIZED’in üst türü MULE:CLIENT_SECURITY’dir ve bu da üst tür olarak MULE:SECURITY’ye sahiptir.

Yukarıdaki görselde “HTTP:CONNECTIVITY” hatasını görebiliyoruz. Mule hata bileşeni ile hatanın kök nedenine ulaşabilir ve hatayı çözmek için ek bilgiler bulabiliriz.

Bu hiyerarşiler, yönlendirmenin daha genel olabileceği anlamına gelir, çünkü örneğin MULE:SECURITY için bir işleyici HTTP yetkisiz hatalarının yanı sıra OAuth hatalarını da yakalar.

Hata nesnesi özellikleri

Hata nesnesinde, hata ayrıntılarını almamıza yardımcı olan belirli özellikler vardır.

• #[error.description] — Hata açıklaması
• #[error.detailedDescription] — Hata açıklamasıdır. Bu, potansiyel olarak açıklamayla aynı veya daha kapsamlı olabilir
• #[error.errorType] — Hatayı karakterize etmek ve bir hata işleyicisi içinde yönlendirmeye izin vermek için kullanılan bir tür
• #[error.cause] — Hataya neden olan temel Java Throwable’ı
• #[error.childErrors] — Scatter-Gather gibi öğeler tarafından toplu rota hataları sağlamak için kullanılan isteğe bağlı bir iç hata koleksiyonu
• #[error.errorMessage] — Hata hakkında isteğe bağlı bir Mule mesajı

Default Error Handling

Artık hata türlerini ele aldığımıza ve hataların nasıl tetiklendiğini anladığımıza göre, MuleSoft’un çalışma zamanı tarafından sağlanan hata işleme konusunu ele alacağız. Herhangi bir hata işleme kodumuz yoksa, MuleSoft’un çalışma zamanı varsayılan hata işleme sağlar. Hatayı günlüğe kaydeder ve yayar.

• Default Error Handler Örnek 1;

Varsayılan hata işleyicisi hakkında bilmemiz gereken ana noktalar aşağıdaki gibidir:

Bu ekran alıntısı, HTTP Request bileşeninde hata veren bir Mule akışını ve hata işlemenin 500 HTTP durumu döndürmesini göstermektedir.

• Default Error Handler Örnek 2;

Yukarıdaki flowda gerçekleşen adımları incelersek;

1. Set Payload’a static sayı değeri atandı,
2. Is Number doğrulayıcısı, değer bir tamsayı olmadığı için Hata Nesnesi oluşturur,
3. Flow bir sonraki adıma geçmeden durdurulur,
4. #[error.description] = “payload is not a valid INTEGER value”
5. #[error.errorType] = VALIDATION:INVALID_NUMBER
6. Herhangi bir hata işleyicisi tanımlanmadığından, Mule varsayılan hata işleyicisi hatayı işler
7. “payload is not a valid INTEGER value” HTTP isteğinin gövdesinde istek sahibine döndürülen hata mesajıdır
8. HTTP Durum Kodu: 500

HTTP Request bileşeninde bir hata oluştuğunda, hata işleme akışın işlenmesini durdurur ve hatayı günlüğe kaydeden, yayan varsayılan hata işleyicisine aktarır. Varsayılan hata işleyici Mule çalışma zamanı tarafından sağlanır ve akışlarda tanımlanmış bir hata işleme olmadığında hatayı yakalar.

On-Error Continue ve On-Error Propagate

MuleSoft, gereksinimlerimize göre işlem yapan iki tür işleyici sağlar:

• On-Error Continue: Bu bileşen istisnayı işler ve hatadan dolayı Flow’u durdurmaz.
• On-Error Propagate: Bu bileşen istisnayı işler ve hatadan dolayı Flow’u durdurur.

Aslında basit örnekler bölümünde (Örnek 1 ve 2) akış düzeyinde hata işlemeyi görmüştük:

Aşağıdaki örnekte eğer flowda bir hata olurşa On-Error Propagate e düşecek, flow hata aldığı adımda durdurulacak ve Set payload ile atanan “Error Main Flow” içerisine tanımlana static değeri geri döndürecektir.

Bu oldukça basit. Peki hatalar başka bir akışta (yani bir alt akış veya alt akış) meydana geldiğinde ne olur?

Bunu göstermek için yukarıdakine çok benzer bir örnek kullanacağız, ancak bu örnekte ana akıştan bir Akış Referansı işlemcisi tarafından başvurulan bir alt akışta Is Number doğrulayıcısı bulunacaktır:

İşlerin biraz daha karmaşıklaşmaya başladığı yer burasıdır, ancak hata işleme söz konusu olduğunda temel bilgileri hatırlayalım:

On Error Propagate: RED (Error) in, RED (Error) out

On Error Continue: RED (Error) in, GREEN out

Flowdan gelen Payload hataya düşmeden devam eder;

Sub-Flow: On Error Continue

Hatanın alt akışta meydana geleceği ve hatanın alt akıştaki bir On Error Continue kapsamı tarafından yakalanacağı ilk örneğimiz:

1. Payload başarıyla “Success — Started Main Flow” a aktarılır,
2. Child flow çağrılır ve payload aktarılır,
3. Is Number doğrulayıcısına integer kontrolü eklendi ve payload integer olmadığı için bir hata nesnesi oluşturur,
4. Child Flow durdurulur,
5. #[error.description] = “Payload değeri INTEGER değil”
6. #[error.errorType] = VALIDATION:INVALID_NUMBER
7. On Error Continue hatayı işler
8. Payload’u “Error — Sub Flow” a gönderir,
9. Chil Flow başarılıymış gibi ana akışa “Error — Sub Flow” döndürülür
10. Payload ilerler
11. Payload “Success — Finished Main Flow” olarak sıfırlanır,
12. “Success — Main Flow” HTTP isteğinin gövdesinde istek sahibine döndürülür,
13. HTTP Status Code: 200

Gördüğünüz gibi, yukarıdaki örnekte, childFlow ‘daki bir On Error Continue kapsamı tarafından yakalandığı için (RED in, GREEN out) Mule Mesajı mainFlow ’a döndüğünde, MainFlow bir hata olduğunu fark etmez çünkü On Error Continue bir 200 success mesajı döndürür. MainFlow’a göre childFlow başarılı göründüğü için mainFlow’un işlenmesinin akış referansından sonra yeniden başladığını unutmayın.

Sub-Flow: On Error Propagate

Aşağıdaki örnekte, childFlow ‘daki hatayı işlemek için mainFlow ‘a hatayı yaydığını (RED in, RED out) görüyoruz. Bu sürecin biraz farklı göründüğünü fark edeceksiniz:

1. Payload başarıyla “Success — Started Main Flow” a aktarılır,
2. Child flow çağrılır ve payload aktarılır,
3. Is Number doğrulayıcısına integer kontrolü eklendi ve payload integer olmadığı için bir hata nesnesi oluşturur,
4. Child Flow durdurulur,
5. #[error.description] = “Payload değeri INTEGER değil”
6. #[error.errorType] = VALIDATION:INVALID_NUMBER
7. On Error Propagate hatayı işler,
8. Payload’u “Error — Sub Flow” a gönderir,
9. Chil Flow hatalıymış gibi ana akışa “Error — Sub Flow” döndürülür,
10. ChildFlow’daki hata nedeniyle Akış Referansı başarısız olur,
11. MainFlow ilerlemesi durdurulur,
12. Çünkü MainFlow için bir akış hatası işleyicisi olmadığından, bir akışın varsayılan davranışı hatayı fırlatır,
13. HTTP isteğinin gövdesinde “Payload değeri INTEGER değil” olarak istek sahibine döndürülür,
14. HTTP Status Code: 500

Burada dikkat edilmesi gereken önemli bir fark, chilFlow On Error Propagate kapsamını kullandığından, çağıran akışa (mainFlow) bir hata mesajı iletilmesidir. Bu nedenle, mainFlow’daki akış referansının yürütülmesi başarısız oldu ve bu nedenle akışın geri kalanının işlenmesi durdu. Bu nedenle, son set payload işlemi yürütülmemiş ve hata mesajı istek sahibine geri iletilmiştir.

Bu örnekle ilgili son bir not, mainFlow ’da tanımlanmış bir hata işleme olmadığı ve bu nedenle, bir akışın varsayılan davranışı hatayı yaymak olduğu için hatanın basitçe tekrar yayıldığıdır.

Şimdi, bildiklerimizi hatırlayarak, aynı örneğin başarılı bir HTTP durum kodu olan 200'ü döndürmesini nasıl sağlayabiliriz?

1. Alt akışa bir On Error Continue yerleştirin (önceki örnek)
2. Hatayı işlemek için MainFlow’a ek bir hata durumunda devam öğesi ekleyin
3. Not: Bu durumda, son Set Payload işlemi yürütülmez

Artık hataları akış düzeyinde nasıl ele alacağımızı bildiğimize göre, Hata Yönetimi stratejilerimizi belirleyebiliriz.

Logicalbond (Mulesoft Partner and Reseller)

Logicalbond, bir MuleSoft Türkiye Yetkili Satıcısı ve İş Ortağıdır. Küçük, orta ölçekli, kurumsal ve stratejik müşteriler için güvenilir entegrasyon çözümleri üretir.

Sertifikalı danışmanlarımız, müşterilerimizin gelişen ihtiyaçlarına uyum sağlamalarına yardımcı olurken aynı zamanda inovasyonu ve dijital dönüşümü destekleyen görev açısından kritik çözümler sağlama konusunda yeteneklidir.

Logicalbond’un güvenilir iş ortağınız olmasına izin verin, biz de kuruluşunuzun ve ekibinizin sürdürülebilir dijital değerler oluşturmasına yardımcı olalım. Daha fazla bilgi için lütfen www.logicalbond.com adresini ziyaret edin.