Insurance Company Job Notification
InsurGateway, bir işe (job) yeni aksiyon eklendiğinde bu bildirimler ile sigorta şirketine haber verir. Sigorta şirketi, iş değişikliklerini polling ile takip etmek yerine kendi ucunda oluşturur/günceller.
Bildirimi tetikleyen olay, işe yeni bir aksiyon eklenmesidir. Her aksiyon, işin o anki aşamasını (Stage) taşır ve tek bir bildirim üretir. İşin kendi bilgilerinin değişmesi (107) ve poliçe isteğinin başka şirkette poliçeleşme nedeniyle geçersiz kalması (108) ayrı bildirimlerle iletilir; bu iki tip kendi sayfalarında anlatılmıştır.
40’tan fazla aşama 7 bildirim tipine gruplanmıştır ve her tipin kendi Payload modeli vardır. Gövde iki bölümden oluşur: her tipte gönderilen sabit alanlar en üst seviyede yer alır, tipe göre değişen model ise Payload alanında, JSON olarak serialize edilmiş string halinde gönderilir. Gövdedeki NotificationType alanı, Payload alanının hangi modeli taşıdığını belirtir; böylece aşama başına ayrı model yerine tip başına tek model parse edilir.
Endpointler
Sigorta şirketi InsurGateway’e yalnızca base URL bildirir. Path’ler sabittir ve tüm sigorta şirketleri için aynıdır; InsurGateway bunları base URL’in sonuna ekler.
Tüm isteklerde Content-Type: application/json gönderilir. 7 bildirim tipinin tamamı aynı /notification adresine atılır; tip, gövdedeki NotificationType alanından anlaşılır.
Kimlik Doğrulama
Sigorta şirketi aşağıdaki iki yöntemden birini seçer ve gerekli bilgileri InsurGateway’e bildirir:
Login
Yalnızca Login yöntemini seçen sigorta şirketleri bu endpoint’i sunar. InsurGateway, bildirim göndermeden önce bu endpoint’ten token alır ve token’ı geçerlilik süresi boyunca saklayıp sonraki bildirimlerde yeniden kullanır; her bildirim için ayrı login isteği atılmaz.
İstek
Cevap
Başarılı cevap 2xx durum koduyla dönmelidir. 2xx dışındaki bir durum kodu veya Token alanı boş bir cevap, login’in başarısız olduğu anlamına gelir; bu durumda bildirim gönderilmez ve Retry takvimine göre yeniden denenir.
Notification
Referans numarası ve sabit alanlar üstte, tipe göre değişen içerik Payload alanındadır. Payload, JSON olarak serialize edilmiş bir string gönderilir: önce NotificationType değeri okunur, ardından Payload string’i o tipe karşılık gelen modele deserialize edilir.
Ortak Alanlar
Aşağıdaki alanlar 7 tipin tamamında, gövdenin en üst seviyesinde yer alır.
EventTypene işe yarar:JobCreated, işin ilk kez oluşturulması gerektiğini bildirir.StageChangedise mevcut bir işin güncellenmesidir. Kayıtlı olmayan bir iş içinStageChangedgelirse (örneğin ilk bildirim teslim edilememişse) iş yine deJobIdile oluşturulabilmelidir.
Stage → NotificationType Eşleştirmesi
Bu tabloda yer almayan bir aşama için bildirim gönderilmez.
Payload Modelleri
Aşağıdaki alanlar gövdenin en üst seviyesinde değil, Payload string’i deserialize edildiğinde elde edilen modelde yer alır. Hangi modelin geldiğini ortak alanlardaki NotificationType belirler.
100 — Premium
Prim ve prim revize aşamaları.
101 — Policy
Poliçe aşamaları.
Poliçe alanları yalnızca
PolicyMadeaşamasında dolar ve ana poliçeyi taşır; diğer aşamalardanullgelir. Toplu poliçede (BatchPolicyMade) poliçe alanlarınullgelir, kesilen poliçelerBatchItemsiçindedir.
102 — Endorsement
Zeyil aşamaları.
Zeyil alanları yalnızca
EndorsementMadeaşamasında dolar ve yapılan zeyili taşır; diğer aşamalardanullgelir. Toplu zeyilde (BatchEndorsementMade) zeyil alanlarınullgelir, yapılan zeyillerBatchItemsiçindedir.
103 — Message
Mesaj aşaması. Bildirim, mesaj karşı tarafa iletildikten sonra gönderilir.
104 — Approvement
Doküman onay aşamaları.
Attachments: Şu sürümde dizi her zaman boş gönderilir. Alan, ileride doküman bilgisi eklendiğinde modelin değişmemesi için şemada yer alır.
105 — Info
Bilgi bekleme aşamaları.
106 — Removed
İstek geri çekme aşamaları.
Ortak Alt Modeller
RejectReason — reddedilme aşamalarında dolar, diğer aşamalarda null gelir.
BatchItem — 100 Premium, 101 Policy ve 102 Endorsement tiplerindeki BatchItems dizisinin eleman şeması.
Attachment — 103 Message ve 104 Approvement tiplerindeki Attachments dizisinin eleman şeması. Şu sürümde dizi her zaman boş gelir.
Parse Edilmiş Gövde Örnekleri
Aşağıdaki örneklerde
Payload, okunabilirlik için parse edilmiş (nesne) haliyle gösterilmiştir. Gerçek gövdedePayloadbu nesnenin serialize edilmiş string halidir; gerçek biçim için yukarıdaki Notification bölümündeki örnek isteğe bakın.Ayrıca okunabilirlik için değeri
nullolan bazı alanlar çıkarılmıştır. Gerçek gövdede modelin tüm alanları yer alır; değeri olmayanlarnullolarak gönderilir, atlanmaz.
101 Policy — poliçe gerçekleşti:
100 Premium — prim reddedildi:
105 Info — kurum dışı bilgi bekleniyor:
Örneklerdeki
ReferenceNodeğerleri temsilidir; gerçek değer InsurGateway tarafından üretilir ve opak bir string olarak ele alınmalıdır.
Beklenen Cevap
Başarı: 2xx aralığında herhangi bir HTTP durum kodu yeterlidir. Cevap gövdesi değerlendirilmez; belirli bir cevap şeması beklenmez.
Hata (retry tetikler): 2xx dışındaki her durum kodu başarısız sayılır ve yeniden gönderim zincirini başlatır. Bağlantı hatası, zaman aşımı gibi ulaşım katmanı sorunları da aynı şekilde ele alınır.
Retry
Retry’lar tükendiğinde bildirim düşer ve tekrar gönderilmez. Her deneme aynı gövdeyle, dolayısıyla aynı ReferenceNo ile gönderilir.
Dikkat Edilmesi Gerekenler
Sıralama garantisi yoktur. Aynı işe ait bildirimler kronolojik sırayla teslim edilmeyebilir: bir bildirim retry zincirindeyken sonraki aşamanın bildirimi önce ulaşabilir. İşin durumu belirlenirken OccurredAt alanı kullanılmalı ve daha eski bir olay daha yeni bir olayın üzerine yazılmamalıdır.
Aynı bildirim birden çok kez ulaşabilir. Yeniden gönderim, istek alınmış ama cevap InsurGateway’e ulaşmamışsa da tetiklenir. İşleme idempotent olmalıdır; tekilleştirme anahtarı ReferenceNo alanıdır.
Sorun bildirirken ReferenceNo iletilmelidir. InsurGateway her gönderim denemesini bu numarayla kayıt altına alır; bir bildirimle ilgili inceleme bu numara üzerinden yapılır.
Bilinmeyen alanlar ve tipler yok sayılmalıdır. Şemaya ileride yeni alan, NotificationType aralığına yeni tip eklenebilir; parse işlemi bilinmeyen alanlarda hata vermemeli, tanınmayan NotificationType değerinde 2xx dönüp bildirimi atlamalıdır.
Aşama kodu esas alınmalıdır. StageName görünen addır ve değişebilir; iş kuralları Stage kodu üzerinden kurulmalıdır.
