Bu sürümle birlikte bileşen şeması 0.0.47'ye yükseldi. Doğrulama yapmadan önce domain projenizde @burgan-tech/vnext-schema paketini güncelleyin.

Teknik release notları için: Release v0.0.62.

1. HttpTask contentType​

HTTP Task config'ine yeni bir contentType alanı eklendi. Böylece istekler artık yalnızca application/json ile sınırlı değil — application/xml, text/plain, application/x-www-form-urlencoded gibi farklı content-type'lar desteklenir hale geldi.

Ne değişti​

• attributes.config.contentType ile request body'nin Content-Type header'ı tanımlanabilir.
• Request body byte-exact korunur; bu özellikle body'nin imzalandığı (signing) senaryolarda kritiktir — yeniden serialize edilmesi imzayı geçersiz kılardı.
• Alan opsiyoneldir; tanımlanmazsa önceki varsayılan davranış geçerlidir, mevcut tanımlar değişmeden çalışır.

{
  "attributes": {
    "type": "6",
    "config": {
      "url": "https://api.example.com/sign",
      "method": "POST",
      "contentType": "application/xml",
      "body": { "...": "..." }
    }
  }
}

Migrasyon adımları​

1. JSON dışı bir gövde gönderen veya gövdesi imzalanan HTTP task'larınızı belirleyin.
2. Bu task'ların config'ine uygun contentType değerini ekleyin.
3. @burgan-tech/vnext-schema paketini 0.0.47'ye güncelleyip npm run validate ile doğrulayın.

İlgili doküman: HTTP Task

2. State interaction / Long Poll​

State Function, client tarafında long-polling ile süreç durumunu döner. Şimdiye kadar her client, açık tutulan isteğin ne zaman sonlandırılacağını kendi tahmin ediyordu. Artık bu, state tanımında deklaratif olarak belirtilebilir.

Ne değişti​

State'lere opsiyonel bir interaction.longPoll bloğu eklendi. Runtime, isteği bir transition gerçekleşene veya fallback timeout dolana kadar açık tutar. Bu sayede bir süreç tasarımında farklı client'lar süreci kendi durak noktaları ile belirleyebilir.

{
  "key": "waiting-approval",
  "stateType": 2,
  "interaction": {
    "longPoll": {
      "terminate": true,
      "fallbackTimeoutSeconds": 30,
      "roles": [
        { "role": "client.app", "grant": "allow" }
      ]
    }
  }
}

Migrasyon adımları​

1. Client'ların long-poll yaptığı durak (bekleme) state'lerini belirleyin.
2. Bu state'lere interaction.longPoll bloğunu ekleyin; hangi rolün etkileşimi kullanacağını roles ile, sonlandırma davranışını terminate ile belirtin.
3. İstemci tarafında manuel long-poll sonlandırma mantığınız varsa, deklaratif yapıya geçirerek sadeleştirin.

İlgili dokümanlar: Workflow → State Interaction (Long Poll) · Async / Sync Yöntemi

3. Function ResponseHeader & StatusCode Forward​

Bir function onExecutionTasks ile birden fazla task çalıştırıp sonucu bir IOutputHandler ile şekillendirdiğinde, output ScriptResponse'unun taşıdığı header'lar ve status code artık nihai function HTTP yanıtına forward edilir.

Ne değişti​

• Önceden output handler yalnızca response gövdesini etkileyebiliyordu; header ve status code düşürülüyordu.
• Artık output handler, yanıt status'ünü (örn. 201, 202) ayarlayabilir ve Location, ETag gibi header'ları yayabilir.
• StandardTaskResponse zaten StatusCode ve Headers taşıyordu; bu değişiklik bunların multi-task function output'una forward edilmesini sağlar.

Migrasyon adımları​

1. Multi-task (onExecutionTasks) kullanan function'larınızda output handler'ı gözden geçirin.
2. Yanıt status code veya header'ı kontrol etmek istiyorsanız döndürdüğünüz ScriptResponse üzerinde ilgili alanları set edin.

İlgili dokümanlar: Custom Functions · Interfaces → IOutputHandler

4. vnext-runtime MCP Sunucusu​

vNext bileşenlerini, canlı runtime verisini ve statik vnext-meta'yı MCP uyumlu ajanlara (Claude Code, Cursor, CI, hosted asistanlar) sunan standalone bir Model Context Protocol sunucusu (vnext-runtime) hayata geçirildi. Böylece AI toolları ile doğrudan runtime bazında AI agent yapılandırmaları kullanılabilir.

Ne değişti​

• Sunucu, Orchestration HTTP API'yi tiplenmiş bir HttpClient ile çağırır; DB / Redis / Dapr referansı yoktur.
• İki transport: stdio (lokal IDE) ve Streamable HTTP (hosted / CI).
• Her instance tek domain sunar (Mcp:Domain); HTTP transport'ta sabit bir Mcp:ApiKey ile yetkilendirilir (stdio gated değildir).
• Tool grupları: ComponentTools, RuntimeTools, MetaTools ve AllowMutations ile açılan MutatingRuntimeTools.

dotnet tool install -g BBT.Workflow.Mcp
claude mcp add vnext-runtime \
  --env Mcp__OrchestrationBaseUrl=http://localhost:4201 \
  --env Mcp__Domain=<your-domain> \
  -- vnext-mcp

Migrasyon adımları​

1. Lokal IDE için dotnet tool ile kurun (BBT.Workflow.Mcp), Mcp__Domain ve Mcp__OrchestrationBaseUrl ortam değişkenlerini verin.
2. Hosted/CI için Docker image'ı (ghcr.io/burgan-tech/vnext/mcp-server) HTTP transport ile çalıştırın ve Mcp__ApiKey ile koruyun.
3. Mutasyon araçlarına (start/transition/publish/invalidate) ihtiyaç yoksa AllowMutations=false (varsayılan) bırakın.

İlgili doküman: vnext-runtime MCP Server

5. Davranış Değişikliği — Deny-only Rol Grant'ları Blacklist​

Yetkilendirme modelinde bir roles / queryRoles setinin niyeti artık iki şekilde yorumlanır:

• Set içinde en az bir allow varsa → allow-list (whitelist): yalnızca eşleşen allow rolleri geçer (varsayılan deny). Mevcut davranış.
• Set yalnızca deny içeriyorsa → blacklist: listelenenler dışındaki herkese izin verilir (varsayılan allow). Yeni davranış.

Her iki durumda da DENY her zaman ALLOW'u geçersiz kılar. Bu sayede "X hariç herkese izin ver" kuralı, izinli her rolü tek tek saymadan ifade edilebilir.

:::warning Geriye dönük etki Yalnızca deny grant'ı içeren mevcut bir set, önceki sürümde pratikte herkesi engelleyebilirken, bu sürümde listelenenler dışındaki herkese açık hale gelir. :::

Migrasyon adımları​

1. Tüm transition roles, flow/state queryRoles, state alias.roles ve master şema x-roles tanımlarınızı tarayın.
2. Yalnızca deny içeren setleri belirleyin; niyetiniz "herkesi engelle" idiyse en az bir allow grant'ı ile allow-list'e çevirin.
3. Niyetiniz gerçekten "listelenenler hariç herkese izin" ise mevcut deny-only set'i koruyabilirsiniz.

İlgili doküman: Yetkilendirme (Authorization)

6. Async Continuation — Doğrudan Dapr-enqueue + Outbox Fallback​

v0.0.60'taki yapılandırılabilir asenkron transition modlarının üzerine, continuation'lar artık doğrudan Dapr üzerinden kuyruğa alınabilir; doğrudan enqueue yolu kullanılamadığında transactional outbox dayanıklılık fallback'i devreye girer. Bu, sağlıklı koşullarda async continuation gecikmesini azaltırken dayanıklılık garantisini korur.

Migrasyon adımları​

1. sync=true / sync=false davranışı için Async / Sync Yöntemi sayfasına bakın.
2. Bu sürüm dayanıklılık değişiklikleri için EF Core migration'ları içerir — db-migrator image'ı ile şema güncellemesini uygulayın.

İlgili doküman: Async / Sync Yöntemi

7. Düzeltmeler​

Bu düzeltmeler çoğunlukla otomatik olarak geçerlidir; ek migrasyon adımı gerektirmez:

• SOAP Task derleme + escaping (#738): SoapTask mapping'i CS0012 ile derlenemiyordu ve varsayılan yolda XML özel karakter escaping'i tutarsızdı; düzeltildi.
• ChainToken gate (#730): Parent instance Busy subtype taşırken child sub-process'in Ready'ye geçişi yanlışlıkla reddediliyordu; düzeltildi.
• Domain replacement (#729): Source domain ile eşleşen subprocess referansları atlanıyordu; replacement artık doğru yeniden yazıyor.

Özet​

• HttpTask contentType ile farklı content-type desteği + imzalama için byte-exact body.
• State interaction.longPoll ile deklaratif, rol bazlı long-poll sonlandırma; client'lar kendi durak noktalarını belirler.
• Multi-task function output'unda header/status code nihai yanıta forward edilir.
• vnext-runtime MCP ile component/runtime/meta keşfi AI toollarına açılır (stdio + Streamable HTTP).
• Deny-only rol grant setleri artık blacklist (default allow); DENY > ALLOW korunur.
• Async continuation doğrudan Dapr-enqueue + outbox fallback ile çalışır.
• Bileşen şeması 0.0.47'ye yükseldi.

Teknik release notları: Release v0.0.62

Bu sürümle birlikte bileşen şeması 0.0.46'ya yükseldi. Doğrulama yapmadan önce domain projenizde @burgan-tech/vnext-schema paketini güncelleyin.

Teknik release notları için: Release v0.0.60.

1. Mappings Bileşeni & Custom C# Helper'lar​

vNext'e yeni bir sistem bileşeni eklendi: sys-mappings (kısaca Mappings). Mapping bileşeni, script mapping kodlarının yeniden kullanılabilir, versiyonlanabilir ve daha verimli kullanılmasını sağlar. Ayrıca plugin özelliği ile 3rd-party kütüphane/DLL'leri embed ederek kullanım sağlar — bu da business case'lerinde sıkça ihtiyaç duyulan ayrı "utilities API" gereksinimini ortadan kaldırır.

Ne değişti​

• Geliştiriciler kendi C# yardımcı sınıflarını .csx olarak — tıpkı flow, task ve view'lar gibi — bir bileşen olarak yükleyebilir.
• Bu helper'lar bir flow tanımının mapping'inden referans verilir; runtime önce helper sınıflarını derler, ardından mapping'i bunlara karşı derleyip çalıştırır.
• Helper'lar sandbox altında, içerik hash'i ile cache'lenerek çalıştırılır.

Domain projesi yapılandırması​

Bu bölümdeki adımlar mevcut bir domain projesini v0.0.60'a taşırken atılır. Çalışan bir referans için vnext-example reposuna bakın — aşağıdaki yapılandırmanın tamamı orada hazırdır.

1. Mappings/ dizini​

Domain bileşen ağacına Mappings/ dizini eklenir. Her mapping bir .json tanım dosyası + src/ altında karşılık gelen bir .csx kaynak dosyasıdır:

├── <domain>/                       # ör. core/
│   ├── Extensions/
│   ├── Functions/
│   ├── Schemas/
│   ├── Tasks/
│   ├── Views/
│   ├── Workflows/
│   └── Mappings/                   # YENİ
│       └── account-opening/        # iş akışı/alan bazlı klasör
│           ├── initial-mapping.json
│           ├── json-helper.json
│           ├── rsa-crypto.json
│           └── src/
│               ├── InitialTransMapping.csx
│               ├── JsonHelper.csx
│               └── RsaCryptoHelper.csx
├── vnext.config.json

2. vnext.config.json​

paths ve exports bloklarına mappings eklenir (diğer bileşenlerle aynı hizada):

{
  "domain": "core",
  "paths": {
    "componentsRoot": "core",
    "schemas": "Schemas",
    "workflows": "Workflows",
    "tasks": "Tasks",
    "views": "Views",
    "functions": "Functions",
    "extensions": "Extensions",
    "mappings": "Mappings"
  },
  "exports": {
    "schemas": [],
    "workflows": [],
    "tasks": [],
    "views": [],
    "functions": [],
    "extensions": [],
    "mappings": []
  }
}

3. Domain tooling script'lerine mappings desteği​

Domain projesindeki bileşen keşfi test.js, validate.js, setup.js, index.js, build.js script'leri üzerinden yapılır. Bileşen türleri bu script'lerde listelendiği için, mappings'i her birine eklemek gerekir. (Yeni proje şablonlarında bu satırlar zaten gelir; eski projelerde elle eklenir.)

setup.js · index.js · build.js · validate.js — getPathsConfig içindeki defaults paths objesine:

const defaults = {
  componentsRoot: 'core',
  schemas: 'Schemas',
  workflows: 'Workflows',
  tasks: 'Tasks',
  views: 'Views',
  functions: 'Functions',
  extensions: 'Extensions',
  mappings: 'Mappings'        // YENİ
};

index.js — getMappings() getter'ı ve getAvailableTypes dönüşü:

// Get all mappings
getMappings: function() {
  const domainDir = findDomainDirectory();
  if (!domainDir) return {};
  const pathsConfig = getPathsConfig();
  return loadJsonFiles(path.join(domainDir, pathsConfig.mappings));   // YENİ
},

getAvailableTypes: function() {
  const pathsConfig = getPathsConfig();
  return [pathsConfig.schemas, pathsConfig.workflows, pathsConfig.tasks,
          pathsConfig.views, pathsConfig.functions, pathsConfig.extensions,
          pathsConfig.mappings];                                      // YENİ
},

build.js — reference build'deki componentDirs dizisine pathsConfig.mappings eklenir.

validate.js — dört noktada genişletilir:

// requiredExports ve componentGetters dizilerine:
'getMappings',
// vnextDirs ve expectedDirs dizilerine:
pathsConfig.mappings,
// directoryToSchemaType eşlemesine (mapping → 'mapping' şeması):
[pathsConfig.mappings]: 'mapping',

validate.js, mappings dizinini 'mapping' şema tipine eşler; şema @burgan-tech/vnext-schema paketinden (mapping-definition.schema.json) yüklenir — script'e ayrı bir şema dosyası eklemeye gerek yoktur.

test.js — beklenen export/dizin listelerine:

// expected exports ve getters dizilerine:
'getMappings',
// expectedTypes ve expectedDirs dizilerine:
'Mappings',

Mapping objesindeki scripts bloğu​

Tüm mapping objelerinde (viewRule, rule, transition mapping, subflow mapping, task mapping, extension/function task mapping) yeni bir scripts objesi tanımlanabilir. scripts.helpers[] bir referans dizisidir (string değil — key/version/domain/flow alanları olan objeler), scripts.allowedAssemblies[] ise o mapping'e özel sandbox izinlerini global temel listenin üzerine ekler:

{
  "mapping": {
    "location": "./src/UserSessionMapping.csx",
    "code": "",
    "encoding": "NAT",
    "scripts": {
      "helpers": [
        {
          "key": "json-helper",
          "version": "1.0.0",
          "domain": "core",
          "flow": "sys-mappings"
        }
      ],
      "allowedAssemblies": [
        "Newtonsoft.Json"
      ]
    }
  }
}

Aynı scripts bloğu flow konfigürasyonuna da (attributes.scripts) eklenebilir:

{
  "attributes": {
    "type": "F",
    "scripts": {
      "helpers": [
        { "key": "rsa-crypto", "version": "1.0.0", "domain": "core", "flow": "sys-mappings" }
      ],
      "allowedAssemblies": [ "System.Security.Cryptography" ]
    }
  }
}

REF encoding​

code encoding tipine yeni bir değer eklendi: REF. Bir mapping, kod gömmek yerine bir sys-mappings bileşenine referans verebilir:

{
  "mapping": {
    "encoding": "REF",
    "code": {
      "key": "initial-mapping",
      "version": "1.0.0",
      "flow": "sys-mappings",
      "domain": "core"
    }
  }
}

Kısıt: sys-mappings bileşeninin kendisi REF kullanamaz — referans hedefinin kendisidir, kendine referans veremez.

Sandbox​

Helper'lar iki katmanlı derleme zamanı kapısı (reference allow-list + yasaklı API analizörü) ile kısıtlanır ve paylaşımlı, toplanabilir bir AssemblyLoadContext içinde derlenir. allowedAssemblies ile mapping bazında verilen izinler global temel listenin (Scripting:Sandbox:AllowedAssemblies) üzerine eklenir — yani bir flow, herkesin temel listesini genişletmeden yalnızca kendi helper'ının ihtiyacı olan assembly'yi açar.

Migrasyon adımları​

1. Domain altında Mappings/ dizinini oluşturun ve vnext.config.json'ın paths + exports bloklarına mappings ekleyin.
2. Bileşen keşfini yapan tooling script'lerini (test.js, validate.js, setup.js, index.js, build.js) yukarıdaki "Domain tooling script'lerine mappings desteği" bölümüne göre güncelleyin.
3. Tekrar eden mapping kodlarını sys-mappings bileşenlerine çıkarın; flow/mapping'lerden scripts.helpers[] ile referans verin. Kodu gömmek yerine paylaşmak için mapping encoding'ini REF yapabilirsiniz.
4. Helper'ınızın baz dışı bir assembly'ye ihtiyacı varsa scripts.allowedAssemblies[] ile tanımlayın. Sandbox ayarları (varsayılan ban listesi, using'ler, referanslar) için Scripting / Sandbox Yapılandırması sayfasına bakın.
5. npm run validate ve npm run build ile yapılandırmayı doğrulayın.

Referans (vnext-example)​

Tüm bu yapılandırmanın çalışan hali burgan-tech/vnext-example reposunda hazırdır:

• vnext.config.json — paths.mappings + exports.mappings.
• core/Mappings/account-opening/initial-mapping.json · rsa-crypto.json ve src/ altındaki .csx dosyaları — örnek mapping/helper bileşenleri.
• core/Workflows/account-opening/account-opening-workflow.json — attributes.scripts.helpers ve encoding: "REF" kullanımı.
• Tooling: setup.js · index.js · build.js · validate.js · test.js.

İlgili dokümanlar: Mapping Bileşeni (sys-mappings) · Mapping Rehberi · Scripting / Sandbox Yapılandırması

2. State Alias — Rol Bazlı State Görünürlüğü​

State Function, client tarafında long-polling ile süreç durumunu döner. Client'ta başlayan bir iş akışı backoffice'e geçtiğinde Fraud, KPS, Limit gibi iç kontrol state'lerine uğrar. Client bu noktada sorgulama yaptığında ham state.key döner — iç süreç adımlarının client'a sızması bir güvenlik açığı oluşturabilir.

Ne değişti​

State'lere opsiyonel bir alias[] dizisi tanımlanabilir. Alias, aktör/rol bazlı yapı sayesinde hangi client'ın ne göreceğini belirler; aynı zamanda çoklu-dil (multi-localization) desteği sağlar. İç state kimliği değişmez — alias yalnızca sunum katmanını etkiler; transition'lar, kalıcılık ve iş akışı mantığı aynı state.key üzerinden çalışmaya devam eder.

Her alias öğesi şu alanları taşır:

{
  "alias": [
    {
      "name": "Değerlendirme Aşamasında",
      "roles": [
        { "role": "backoffice.operator", "grant": "allow" }
      ],
      "labels": [
        { "label": "Operasyon İncelemesinde", "language": "tr" },
        { "label": "Under Operational Review", "language": "en" }
      ]
    }
  ]
}

Birden fazla iç state aynı dış alias'a eşlenebilir. Çözümleme isteği yapan aktörün rollerini her alias'ın roles listesine göre değerlendirir; eşleşme varsa istek dilindeki label, o dilde label yoksa alias.name döner; hiçbir alias eşleşmezse state.key'e geri düşer.

Migrasyon adımları​

1. Client'a sızması istenmeyen iç state'leri belirleyin (ör. Fraud/KPS/Limit).
2. Bu state'lere uygun alias[] tanımları ekleyin; hangi rolün hangi label'ı göreceğini roles + labels ile belirtin.
3. Çok dilli kullanımda her dil için labels girişi ekleyin; rol modeli ve DENY/ALLOW önceliği için Yetkilendirme sayfasına bakın.

İlgili dokümanlar: Workflow → State Alias · Yetkilendirme

3. FunctionScope Zorunluluğu ve Tutarlı Yanıt​

FunctionScope, fonksiyon çağrısının her iki giriş noktasında (GetFunctionByKeyAsync ve GetFunctionByInstanceAsync) artık tutarlı şekilde uygulanır:

Ne değişti​

Eski davranışta scope kısmen uygulanıyordu: guard yalnızca Flow üyeliğini ve yalnızca bir instance varken kontrol ediyordu. Sonuç olarak Instance/Flow kapsamlı fonksiyonlar domain seviyesindeki uçtan kısıtsız çağrılabiliyor, scope hataları ise tesadüfi 404 olarak sızıyor ve rol kapsamı (authorize role evaluation) ele alınmıyordu.

Yeni davranışta authorize rol değerlendirmesi yapılır ve scope/tanım eksikliği veya yetki ihlali durumunda 403 Forbidden (FunctionScopeNotSatisfied) döner.

Migrasyon adımları​

1. Fonksiyonlarınızın scope değerlerini gözden geçirin: F kapsamlı bir fonksiyonun ilgili flow'un workflow.Functions listesinde tanımlı olduğundan emin olun.
2. Domain seviyesindeki uçtan Instance/Flow kapsamlı fonksiyon çağıran client'ları güncelleyin.
3. Hata yönetiminde scope ihlallerinin artık 404 değil 403 döndüğünü dikkate alın.

İlgili doküman: Function

4. Operations & Observability​

publish endpoint'i OpenAPI'de gizlendi​

publish endpoint'i varsayılan olarak OpenAPI'de expose ediliyordu. Bu, OpenAPI okunarak API'nin bileşen yükleme bilgisini açığa çıkarıyordu. Endpoint artık API Explorer / OpenAPI çıktısında gizlidir.

Production'da Swagger UI kapalı​

Swagger arayüzü production ortamında tüm API host'larında kapatıldı; public production yüzeyi artık API explorer'ı sunmaz.

Migrasyon adımları​

1. Production'da Swagger UI'a bağımlı araç/akış varsa bunları kaldırın veya non-production ortamlara taşıyın.
2. publish işlemini OpenAPI üzerinden keşfeden entegrasyonları gözden geçirin; endpoint artık API Explorer'da listelenmez.

5. Yapılandırılabilir Asenkron Transition İşletimi​

sync=false (asenkron) işletim için durable bir yöntem implemente edildi. Artık asenkron işlemlerde her transition scale edilebilir ve outbox yapısı ile retry edilebilir hale geldi.

Ne değişti​

• Continuation'lar inline çalışmak yerine (opsiyonel olarak outbox üzerinden) kuyruğa alınarak dayanıklılık (durability) kazanır.
• Busy durumundaki instance'lara erişim, bir chain ownership token sistemiyle kontrol edilir; eşzamanlı zincirlerin birbirini ezmesi önlenir.
• Heartbeat'i bayatlamış (takılı kalmış) instance'ları otomatik toparlayan bir chain reaper servisi devreye alındı.

Migrasyon adımları​

1. sync=true / sync=false davranışı ve karar kriterleri için Async / Sync Yöntemi sayfasına bakın.
2. Bu sürüm, dayanıklılık refactor'ü için EF Core migration'ları içerir — db-migrator image'ı ile şema güncellemesini uygulayın.

İlgili doküman: Async / Sync Yöntemi

Özet​

• sys-mappings bileşeni + sandbox'lı custom C# helper'lar; scripts.helpers[] (obje referansı) / scripts.allowedAssemblies[] ve REF encoding.
• State alias ile rol bazlı, çoklu-dil state maskeleme (DENY > ALLOW); iç state'ler client'a sızmaz.
• FunctionScope her çağrı yolunda tutarlı; ihlaller artık 403 döner.
• Operations: publish endpoint'i OpenAPI'de gizli, production Swagger kapalı.
• Asenkron transition durable işletim: outbox ile retry, chain ownership token, chain reaper.
• Bileşen şeması 0.0.46'ya yükseldi.

Teknik release notları: Release v0.0.60

SOAP Task: Doğrudan SOAP Entegrasyonu​

Bu sürümün en büyük eklentilerinden biri, SOAP 1.1 ve 1.2 protokolüyle web servislere doğrudan bağlanabilen SoapTask (Tip: 16).

Özellikle eski core banking ve middleware servislerle çalışırken ayrı bir adapter veya dönüştürme katmanına gerek kalmadan, SOAP endpoint'leri doğrudan task olarak tanımlayabilirsiniz:

{
  "attributes": {
    "type": "16",
    "config": {
      "url": "https://api.example.com/services/CustomerService",
      "soapAction": "http://example.com/GetCustomer",
      "soapVersion": "1.1",
      "acceptedStatusCodes": ["500"]
    }
  }
}

acceptedStatusCodes: ["500"] tanımlamak önemli: SOAP servisler hata durumunda genellikle HTTP 500 üzerinden SOAP Fault döner. Bu ayar olmadan task başarısız sayılır; bu ayarla birlikte OutputHandler'ınıza ulaşır ve fault'u orada handle edebilirsiniz.

Mapping içinde SoapTask sınıfından SetUrl, SetBody, SetSoapAction, AddHeader ve benzeri setter metodlara erişebilirsiniz.

Tam referans için SOAP Task dökümanına bakabilirsiniz.

ScriptBase XML Yardımcıları​

SOAP Task ile birlikte, mapping script'lerinde XML işlemeyi kolaylaştıran iki yeni ScriptBase metodu eklendi:

ParseXml hiçbir zaman exception fırlatmaz; geçersiz veya boş input için null döner. Bu sayede OutputHandler içinde savunmacı XML işleme güvenli bir şekilde yapılabilir.

Functions: POST, PATCH ve DELETE Desteği​

Function endpoint'leri artık GET'in yanı sıra POST, PATCH ve DELETE verb'lerini de destekliyor. Hem domain-level hem de instance-level fonksiyonlarda geçerli:

GET    /api/v1/{domain}/functions/{function}
POST   /api/v1/{domain}/functions/{function}
PATCH  /api/v1/{domain}/functions/{function}
DELETE /api/v1/{domain}/functions/{function}

Bu değişiklik, function endpoint'lerinin tam CRUD senaryolarını karşılamasını sağlıyor. Ayrı BFF katmanı geliştirme ihtiyacı minimize ediliyor.

Aynı sürümde rawResponse alanı da eklendi. rawResponse: true ayarlandığında, mapped rawData platformun standart response modeline sarılmadan doğrudan döndürülür. Legacy API'lerden geçiş senaryolarında işe yarar.

İş Akışı Job Timeout Modeli​

Bir transition job'ı çalışırken platform çöker veya beklenmedik bir hata oluşursa, instance Busy durumunda kalıyordu. Bu sürümde üç katmanlı bir timeout modeli devreye girdi:

300 saniye dolduğunda:

1. Instance Busy → Faulted olarak güncellenir
2. JOB_EXECUTION_TIMEOUT kodu ile bir incident oluşturulur
3. Açık InstanceTransition kaydı kapatılır

Recovery işlemi, tetikleyici token iptal edilmiş olsa bile her zaman tamamlanır (CancellationToken.None kullanılır). Host kapanırken (SIGTERM) recovery atlanır, sadece MarkAsProcessed çalışır.

Deployment Dokümantasyonu​

Yeni bir Deployment bölümü eklendi. Bu bölüm iki rehber içeriyor:

• Helm Chart — vNext'i Kubernetes cluster'ınıza veya local Minikube ortamınıza OCI chart (ghcr.io/burgan-tech/vnext) ile kurma adımları.
• Release Viewer — Tenant'ınızdaki domain'leri, çalışan Helm chart versiyonlarını ve uygulama versiyonlarını görsel olarak izleyen araç.

Transition Annotations: Standart Key'ler​

v0.0.54'te eklenen annotations alanı için artık platform tarafından tanınan standart key'ler belgelendi. Bu key'leri kullanan UI SDK'ları tutarlı davranış sergileyebilir:

"annotations": {
  "ui/visibility-channel": "IbIvnApp|backoffice",
  "ui/priority": "1",
  "ui/intent": "cancel"
}

View Konsepti: State View ve Transition View​

View Concept rehberi platform tarafından önerilen etkileşim modelini artık açıkça belgeliyor:

• State View — state'e bağlı, read-only ekran. Instance'ın mevcut durumunu gösterir.
• Transition View — transition'a bağlı form ekranı. Kullanıcıdan girdi alır ve transition'ı tetikler.

State Function yanıtındaki hasView alanı, istemcinin doğrudan transition mı göndereceğine yoksa önce View Function'ı mı çağıracağına karar vermesini sağlar.

Özet​

Teknik detaylar, konfigürasyon örnekleri ve issue referansları için v0.0.55 Release Notes sayfasına bakabilirsiniz.

vNext Runtime Platform Team
Mayıs 2026