# Akıllı Gateway Modeli

Bankacılık hizmetlerinde kullanılan tüm fonksiyonları REST API'ler üzerinden sunmak ve iş akışlarını görsel bir arabirimle hazırlayıp devreye alabilmek amacıyla oluşturulmuş bir çözüm yaklaşımdır.

@startuml

rectangle "Akıllı Gateway Modeli" {

package "Ocelot Gateway" as ocelot <<ocelot>> {
artifact "Yönetim Servisleri" as ocelot_management_services
artifact "Kayıtlı Servisler" as ocelot_registered_services
}

package "Service Orkestrasyonu" as zeebe {
component zeebe_workflow << zeebe >> [
<b>Süreç Motoru </b>
]
component zeebe_exporter << zeebe exporter >> [
<b>Süreç Bilgi Kaydı </b>
Yugabyte Exporter
]
}

package "Yönetim Paneli" as ui_serviceManager <<MAUI>> {
card uc_service_registration [
<b>Servis Kaydı</b>
+Servis konfigürasyonları
]

card uc_atomic_compose [
<b>Atomic Servis Kompozisyonu</b>
+Atomik akışlar
+Sadece Ocelot Worker
]

card uc_long_compose [
<b>Süreç Kompozisyonu</b>
+Uzun soluklu akışlar
+Domain specific Worker'lar
]
}
     
database yugabyte [
<b>Yugabyte Db </b>
Kubernetes native SQL ve NoSql veri tabanı 
<i>ACID destegi</i>
====
Tüm servis kayıtları
Servislerin configürasyonları
İş akışların persistance bilgileri
]


database elk [
<b>Elastic & Kibana </b>
====
APM Veri akışı
Servis çağrıları iz kayıtları
]
}

uc_service_registration --> ocelot_management_services

ocelot_management_services --> yugabyte
ocelot_management_services --> elk
ocelot_management_services --> zeebe_workflow 

zeebe_exporter --> yugabyte

uc_long_compose --> ocelot_management_services
uc_atomic_compose --> ocelot_management_services

@enduml

## Yönetim Paneli
Yönetim paneli temelde dört temel ana fonksiyonu yerine getirmek için tasarlanmıştır.

### 1 - Servis Kaydı
* Kurum içinde geliştirilen servisler
* Üçüncü kişiler tarafından geliştirilmiş ve banka içerisine alınmış servisler
* Serverless olarak tasarlanmış ve dağıtılmış servisler
* Kurum dışında bulunan (Mernis, İYS gibi) entegre olunmuş servisler

Direk sistemler ve kullanıcılar tarafından tüm servislerin sadece **gateway** üzerinden erişimi hedeflenmektedir. Bu kapsamda kurum içinde bulunan tüm servislerin kaydı yapılır.

Servis kaydı sırasında;
* Erişim kontrolü (Authentication) için gereken konfigürasyonu yapılır. Bu kapsamda;
* Erişimin tek bileşen mi, çoklu bileşenlemi sağlanacağı
* İzin verilen bileşenler
* API Key/Client secret izni verilecek mi ?
* Erişim için region sınırı verilecek mi (Banka içi, belirli İP)
:::info
1. Bileşenler bağımsız şekilde sisteme eklenebilmeli. *Belirli bir interfaceden türemiş bağımsız paketler ile tanımlanacak şekilde.*
a. Compile time registration ile paketler projeye eklenip kullanıma sunulur.
b. Kullanıcı arabirimleri sadece Interface üzerinden haberleşir, bileşenleri bilmez.
2. Bileşenlerin kompozisyonu ile olşuturulan erişim akışları tanımlanmalı. **Zeebe ?** Bu akışlar servislerle ilişkilendirilmeli.
3. API Key/Client Secret için akış tanımı dikkate alınmalı. Maker/Checker süreci, sözleşme kontrolü gibi konular için dinamik yaklaşım hedeflenmeli.
:::
* Yetkilendirme (Authorization) için gereken konfigürasyon yapılır. Bu kapsamda;
* Parametreler (Url ve Body) ile kontrol eklenebilmesi
* Zaman sınırlandırılması konulması beklenmektedir.
:::info
1. Parametreler ile yetkilendirme kontrolü için gereken methodlar bir interface üzerinden tanımlanıp compile time registration ile projeye dahil edilir.
:::
* Rate Limiting ile kullanıcı özelinde veya servis özelinde belli CRON formatında belirli frekanslarda yapılabilir çağrı sayısı belirlenebilir.
* API Quota ile kullanıcı özelinde belli CRON formatında maksimum çağrı sayısı belirlenebilir
:::info
1. Rate Limiting ve API Quota kullanıcı rolleri için genel (Müşteriler günde 10 ayda maksimum 50 fatura sorgulayabilir.) tanımlamalar yapılabilir.
2. Rate Limiting ve API Quota kullanıcı özelinde (385552069002 TCKN li müşteri günde 1000 fatura sorgulayabilir.) tanımlama yapılabilir.
:::

### 2 - Atomic Servis Kompozisyonu
Kullanıcılar kayıtlı olan servisleri kullanarak servis kompozisyonu yapabilirler. Servislerden servis türetme ile paralel, seri veya kompleks akış ile çağrılması gereken servis çağrıları ile yeni servisler türetilebilir.

:::info
Kullanıcı arabiriminde [bpmn.io](https://demo.bpmn.io)'nun özelleştirilmiş versiyonu kullanılır.
Özelleştirme ile sadece geliştirilecek **Ocelot Worker** kullanılacaktır. Ocelot worker sadece kayıtlı servislerin çağrılamasını sağlayan özelleşmiş worker.

Ocelot worker için ayrıca özelleşmiş bir kullanıcı arabirim elementi geliştirilerek kayıtlı servislerin seçilebildiği bir properties panel genişletmesi tasarlanmalıdır.

[bpmn-js-examples](https://github.com/bpmn-io/bpmn-js-examples) adresinde özelleşmiş arabirim geliştirme örneklerine erişilebilir.

Kompozisyon sonucu oluşan servisler **CreateWorkflowInstanceWithResult** yaklaşımı ile çağrılıp çalıştırılır. https://camunda.com/blog/2019/10/0-22-awaitable-outcomes/
:::

:::danger
Servis kompozisyonunda kompozisyona dahil olan servisler talep yapan kullanıcı hakları (**impersonation**) ile çalışır. Ayrıca bir servis yetkilendirmesi yapılmaz.

*Performans açısından sadece sunulan servisin erişim ve yetkilendirme kontrolü yapılıp kompozisyona dahil olan servislerde güvenlik bileşenlerini çalıştırmama opsiyonu eklenmeli mi ?*
:::

### 3 - Süreç Kompozisyonu
Anında tamamlanmayan, sürecin en az bir noktasında kullanıcı ile etkileşime giren iş akışlarının modellenmesi ve servis olarak kullanıma açılması süreç kompozisyonu ile yapılır.

Süreç kompozisyonunda temel varsayımlar;

* Süreç kompozisyonları BPMN ile tasarlanır.
* Kullanıcıdan beklenen veriler için özelleşmiş bir *Receive Task Worker* ile alınır.

:::info
**Receive Data Worker: Receive Task Worker**
1. Kullanıcıdan istenecek verilerin tanımlandığı form referans bilgisini içerir. Form referansı kayıtlı formlar arasında seçilir.
2. Verileri alırken alırken kullanılıcak servis url referansı seçilir.

**Form Kayıtları**
Veri alımı için form oluşturabilecek kadar sematic form bilgisi de içerir. https://github.com/formio gibi bir model oluşturulur.

**Servis Kayıtları**
Servis kayıtları
Bir servis birden fazla akış için kullanılıyor olabilir. Örneğin işe başlayan biri için İK iki ayrı akış, yardım masası bir akış işletiyor olabilir. Tek bir servis verilecek biri işe başladı mesajı ile tüm akışlar aynı anda başlayabilir.
:::

# Servis Detayları
:::warning
Kullanıcı arabimiri teknolji katmanları, cold & hot load yaklaşımları, micro frontend değerlendirmesi farklı belge içerisinde değerlendirilir.
:::

## Form Yönetimi

Form tanımı temel olarak servis parametlerini, parametreler ile ilgili doğrulama kurallarını, parametrelerin kullanıcı arabiriminde alınma detayını içeririr.

Form tanımları temelde iki ana işlem için kullanılır;
1. Süreç Servisleri (*Receive Data Worker*) oluşturulurken gereken body tanımlarını(parametrelerini) tanımlamak için.
2. Kullanıcı arabiriminde süreç ilerletilirken beklenen veriler için arabirimi oluşturmak için.

### GET /gateway/forms
Sisteme kayıtlı olan formları sorgulamak için kullanılır.

#### Query Parameters

page-size = 20
page-index = 3
name = "retail-loan-appliation-operation-%"

Name parametresinde sql like yaklaşımı ile sorgulama yapılabilir.

#### Response

[
  {
    "name": "form-retail-loan-appliation-operation-invioce-check",
    "label": "Kredi Başvuruları Fatura Kontrolü",
    "parameters": [
      {
        "type": "parameter",
        "value-type": "number",
        "label": "First Name",
        "key": "citizenship-number",
        "validate": {
          "required": true
        }
      },
      {
        "type": "textfield",
        "value-type": "text",
        "input-mask": "",
        "label": "First Name",
        "key": "first-name",
        "placeholder": "Enter your first name",
        "prefix": "",
        "suffix": "",
        "multiple": false,
        "default-value": "",
        "validate": {
          "required": false,
          "minLength": "",
          "maxLength": "",
          "pattern": ""
        }
      },
      ...
    ]
  }
]

### POST /gateway/forms/
Name ile kıyaslayarak var olan bir formu günceller, olmayan bir form ise yeni form olarak yaratır.

### DELETE /gateway/forms/{name}
Name parametresi ile geçilen formu siler.

Eğer form bir servis ile ilişkilendirilmiş ise silme işlemi iptal edilir. Formun silinmesi için öncelikle servis ilişkilerinin kaldırılması gerekmektedir.

### GET /gateway/forms/{name}/services
Parametre olarak geçilen formun ilişikili olduğu servisleri döner.

[
  {
    "name": "service-retail-loan-appliation-operation-invioce-check",
    "label": "Kredi Başvuruları Fatura Kontrolü Aksiyonu",
    "form": "form-retail-loan-appliation-operation-invioce-check",
    "http-method": "POST | GET | PUT | PATCH | DELETE",
    "processes": [
      {
        "type": "long | atomic",
        "name": "process-retail-loan-appliation",
        "label": "Kredi Başvurusu"
      }
    ]
  }
]

## Servis Yönetimi
Servislerin kayıt edilmesi, konfigürasyon güncellemelerinin yapılması ve servisler ile ilgili izleme işlemlerinin yapılması bütünsel bir servis yönetim servisleri sunulur.

:::warning
Servis yönetimi atomik servisleri ve süreç içindeki servisleride döner ve yönetir.
:::

### GET /gateway/services
Sisteme kayıtlı olan servisleri sorgulamak için kullanılır.

#### Query Parameters

page-size = 20
page-index = 3
name = "services-process%"

Name parametresinde sql like yaklaşımı ile sorgulama yapılabilir.

#### Response

[
  {
    "name": "/mernis/kps/query-person/{citizenship-number}",
    "label": "Kredi Başvuruları Fatura Kontrolü Aksiyonu",
    "http-method": "GET"
  }
]

## Atomik Servis Yönetimi

## Süreç Yönetimi
2. Süreçlerde kullanmak üzere (*Receive Data Worker*) bir servis *end point* oluşturarak. Bu servisler **Süreç Servisi** olarak anılacaktır.

## Modül Yönetimi

## Kullanıcı Yönetimi