SiteGenesis, Salesforce 2018'de halefi olarak Storefront Reference Architecture'ı (SFRA) çıkarmadan önce B2C Commerce sitelerinin üzerinde çalıştığı vitrin framework'üdür. Birinden diğerine geçmek bir sürüm yükseltmesi değildir: ikisi platformu, veriyi ve ISML şablon dilini paylaşır, ancak vitrin kodunun neredeyse hiçbirini paylaşmaz.

Bu rehber; Salesforce'un SiteGenesis desteği konusundaki gerçek tutumunu, üç gerçekçi geçiş yolunu, kod envanterini, her SiteGenesis kavramının SFRA'daki karşılığını, SEO'nun nasıl korunacağını ve geri alınabilir bir canlıya geçişi ele alıyor. Platformun kendisi için SFCC rehberiyle başlayın.

SiteGenesis'in desteği sona eriyor mu?

Hayır. Salesforce ne SiteGenesis ne de pipeline'lar için bir destek sonu (end-of-life) tarihi açıkladı:

Aralık 2025'te yayımlanan bir Salesforce bilgi bankası makalesi, B2C Commerce pipeline'larını kullanımdan kaldırma ve yalnızca JavaScript controller'ları zorunlu kılma planı olmadığını belirtiyor.
SFRA çıktığında yazılan SFRA SSS sayfası, SiteGenesis kullanan işletmelerin geçmek zorunda olmadığını ve SiteGenesis'in yüksek öncelikli hata ve güvenlik düzeltmeleri almaya devam ettiğini söylüyor. Bu lansman dönemine ait bir tutum: geri çekilmedi, ama bir tarih de taşımıyor.

Değişen, SiteGenesis'in etrafındaki her şey:

Salesforce'un vitrin seçim rehberi Storefront Next'i (önerilen), SFRA'yı, ikisinin hibritini ve özel bir yapıyı listeliyor. SiteGenesis seçenekler arasında yok.
Salesforce Payments bir SFRA plug-in cartridge'ı olarak geliyor; SiteGenesis'te belgelenmiş geçici çözüm onu cartridge path'e kütüphane olarak eklemek ve Salesforce bunun her durumda çalışmadığını not ediyor.
Pipeline çalıştıran legacy job'lar deprecated durumda ve Administration > Operations > Jobs (Deprecated) altında listeleniyor.

Asıl soru, yerinde saymanın maliyeti.

SiteGenesis ile SFRA arasındaki gerçek farklar

"SiteGenesis" iki ayrı kod tabanını kapsar. Salesforce dokümantasyonunun SiteGenesis Pipeline Processor (SGPP) dediği orijinal sürüm, istekleri pipeline'larla işler: Eclipse eklentisi UX Studio'da düzenlenen, node'ları pipelet ve script çağıran ve şablon render eden XML akışları. Sonraki SiteGenesis JavaScript Controllers (SGJC) sürümü ise app_storefront_core üzerine katmanlanan app_storefront_controllers içinde CommonJS controller'lar kullanır.

Alan	SiteGenesis	SFRA
İstek işleme	Pipeline'lar (SGPP) veya JavaScript controller'lar (SGJC)	Route'ları `server` modülüyle kaydedilen controller'lar
Temel kod	`app_storefront_core`, SGJC'de ek olarak `app_storefront_controllers`	`app_storefront_base` ve `server`'ı barındıran `modules` cartridge'ı
Özelleştirme	Temel cartridge'ın önüne konan override cartridge	`server.append`, `prepend` veya `replace` kullanan overlay cartridge'lar
Şablon verisi	Genellikle `pdict` içindeki Script API nesneleri	`cartridge/models` içinde üretilen düz JSON view model'ler
İstek ve oturum mantığı	`OnRequest` ve `OnSession` pipeline'ları veya controller'ları	`dw.system.request.onRequest` ve `onSession` hook'ları
Front end	SiteGenesis'in kendi markup'ı, stilleri ve script'leri	`sgmf-scripts` ile derlenen Bootstrap 4 ve jQuery
Ek özellikler	Plug-in cartridge'ları overlay etmek zor	Tek path üzerinde base, plug-in, LINK ve custom katmanlar

Geçiş sırasında iki platform davranışı önemlidir (SFRA özellikleri ve bileşenleri):

B2C Commerce, SGJC ve SFRA controller'larını eşit kabul eder ve cartridge path üzerinde istenen ada sahip ilk controller'ı çalıştırır. Eşleşen controller yoksa ilk eşleşen pipeline'ı çalıştırır; yani bir SFRA sitesinin path'inde bırakılan SiteGenesis cartridge'ı eski endpoint'lerini erişilebilir tutar.
SFRA'nın temel cartridge'ı ve server modülü, yalnızca siz onlara dokunmadığınız sürece point release'ler arasında geriye dönük uyumlu olarak garanti edilir. Özelleştirmeyi kendi app_custom_* overlay'lerinizde yapın; deseni cartridge geliştirme rehberi anlatıyor.

Geçiş yolunu seçmek

Yol 1: vitrini SFRA üzerinde yeniden inşa etmek

app_storefront_base ile başlayın, tasarımı overlay cartridge'larda yeniden kurun ve SiteGenesis özelliklerini tek tek taşıyın. SFRA SSS'si bu konuda açık: mevcut veri, iş kuralları ve back-end entegrasyonları etkilenmez; yalnızca vitrin kod tabanı değişir.

Yol 2: siteleri tek tek taşımak

SSS, SiteGenesis ve SFRA'nın farklı markalarda veya bölgelerde aynı anda çalışabileceğini doğruluyor; bedeli ek operasyonel ve kod yönetimi karmaşıklığı. Cartridge path site bazında ayarlanır ve bir code version cartridge'lardan oluşan bir klasördür; dolayısıyla tek bir code version iki yığını birden taşıyabilir. En küçük siteyle başlayın.

Salesforce, SiteGenesis ile SFRA'nın tek bir sitenin cartridge path'inde karıştırılmasını tarif etmiyor. İkisi de bir Cart controller'ı içerir ve path'teki ilk eşleşme kazanır; bu yüzden tek bir site içinde tek seferlik bir vitrin geçişi planlayın.

Yol 3: SFRA'yı atlayıp headless'a geçmek

Salesforce'un Storefront Next Migration Tool'u, canlı bir SiteGenesis, SFRA veya PWA Kit vitrinini analiz eden ve route bazında bir Storefront Next iskeleti üreten, yapay zekâ destekli bir CLI'dır. Developer preview aşamasındadır, SiteGenesis için salt okunur OCAPI ve WebDAV erişimi ister ve pipeline'ları değerlendirmez: pipeline'lar ve özel sunucu tarafı işler elle yapılmaya devam eder. Salesforce, Storefront Next'i canlı bir SFRA veya SiteGenesis sitesinin yanında çalıştırmak için Hybrid Auth'u belgeliyor. Mimari ödünleşimler SFRA mı PWA Kit mi? yazısında.

Durum	Yol
Tek site, yeniden tasarım zamanı gelmiş, Script API ve ISML ekibi	SFRA üzerinde yeniden inşa
Aynı realm'de birden fazla site	SFRA, site site, en küçüğünden başlayarak
Uzun vadeli headless planı olan React ekibi	Storefront Next; pipeline mantığını elle yapılacak iş olarak bütçeleyin
Yoğun pipeline mantığı, arayüzlü çok sayıda partner cartridge'ı	Önce SFRA; hâlâ isteniyorsa sonra headless

Adım 1: SiteGenesis kod tabanının envanterini çıkarın

Tahmini sayfa sayısına göre değil, envantere göre yapın. Her site için şunları kaydedin:

Kalem	Ne kaydedilmeli	Neden önemli
Cartridge path	Her cartridge, sırasıyla (Administration > Sites > Manage Sites)	Sizin kodunuzu, SiteGenesis temel kodunu ve partner kodunu ayırır
Pipeline'lar	Start node'lar, çağırdıkları pipelet'ler, interaction continue node'lar	Her biri bir route, script veya job step'e dönüşür
SGJC controller'ları	Her public `Controller-Function`	Bir SFRA route'una veya temel route uzantısına dönüşür
Script'ler	`.ds` ve `.js` modülleri ve pipelet çağrıları	Script API kodu taşınır; pipelet çağrılarının karşılığı yazılmalı
ISML şablonları	Sayfalar, include'lar, slot render şablonları	SFRA'nın model'lerine ve layout'larına göre yeniden yazılır
Form tanımları	Her XML dosyası, locale klasörü bazında	Format aynı; bağlantı kodu değişir
Job'lar	Legacy pipeline job'ları ve job framework step'leri	Legacy job'lar job framework'e taşınır
Hook'lar	Her `hooks.json` girdisi	Çoğu taşınır; SFRA'nın kendi uygulamalarıyla karşılaştırın
Entegrasyonlar	Sağlayıcı, sürüm, SFRA sürümünün varlığı	Çoğu zaman kritik yol
Gelen endpoint adları	Static mapping'lerde, URL kurallarında, content asset'lerde, e-postalarda ve partner callback'lerinde kullanılan adlar	Canlıya geçişten sonra hepsi çözülmeye devam etmeli

En sık atlanan son satırdır: yalnızca kodu değil, content library dışa aktarımını, e-posta şablonlarını ve partner ayarlarını da endpoint adları için tarayın. LINK cartridge'ları için SSS, SFRA lansmanında ekiplere SFRA sertifikalı sürümleri kontrol etmelerini söylemişti. Bu hâlâ geçerli: her sağlayıcının bir SFRA cartridge'ı yayımladığını doğrulayın ve geçişi kendi kurulum rehberi ve regresyon testleri olan yeni bir entegrasyon olarak ele alın.

Adım 2: SiteGenesis kavramlarını SFRA'ya eşleyin

Pipeline'lar ve SGJC controller'ları SFRA route'larına dönüşür

Bir dönüştürücü yok. Her pipeline start node'u veya SGJC public fonksiyonu, cartridge/controllers içinde server.get ya da server.post ile kaydedilen bir route'a dönüşür. server.middleware.https gibi middleware'ler pipeline'ın baştaki kontrollerini üstlenir, model'ler pipeline dictionary'nin yerini alır, res.render veya res.json da şablon render etmenin yerine geçer.

Interaction continue node'lar özel dikkat ister. Bir interaction continue node bir şablon (genellikle bir form) render eder ve aynı pipeline bir sonraki istekte devam eder; yani tek bir akış birden çok isteğe yayılır. Her birini formu render eden bir GET route'una ve formu işleyen bir POST route'una bölün.

Script API'deki dw.system.Pipeline.execute() controller'lara geçişi kolaylaştırmak için eklendi, ancak yalnızca kullanıcı etkileşimi içermeyen pipeline'ları çalıştırır. Salesforce'un controller yönergeleri controller'lardan pipelet çağırmayı kesinlikle önermiyor; pipeline çağırmayı da mevcut LINK cartridge'ları dışında "highly discouraged" (hiç tavsiye edilmez) olarak niteliyor. Bunu en fazla kısa ömürlü bir köprü olarak görün ve eşdeğeri bulunan her yerde pipelet çağrılarını Script API metotlarıyla değiştirin.

Formlar: aynı tanımlar, yeni bağlantı kodu

SFRA aynı XML form tanımlarını okur. Salesforce'un form dokümantasyonu örnek olarak hâlâ SiteGenesis'in contactus.xml dosyasını kullanıyor; locale varyantları da hâlâ forms/default ve locale klasörlerinde duruyor. Değişenler şunlar: server.forms.getForm() bir JSON form nesnesi üretir, şablonlar standart HTML formları kullanır, gönderilen değerler req.form içinde gelir ve kalıcı kayıt bir route:BeforeComplete handler'ında yapılır. SFRA dinamik, multi-part, gömülü veya iç içe form içermez.

// app_custom_mybrand/cartridge/controllers/Feedback.js
'use strict';

var server = require('server');
var URLUtils = require('dw/web/URLUtils');
var csrfProtection = require('*/cartridge/scripts/middleware/csrf');

// GET: boş formu render eden pipeline dalının yerini alır
server.get('Show', server.middleware.https, csrfProtection.generateToken, function (req, res, next) {
    var feedbackForm = server.forms.getForm('feedback'); // forms/default/feedback.xml
    feedbackForm.clear();

    res.render('feedback/form', {
        feedbackForm: feedbackForm,
        actionUrl: URLUtils.url('Feedback-Submit').toString()
    });
    next();
});

// POST: interaction continue node'un devam ettiği submit'i işler
server.post('Submit', server.middleware.https, csrfProtection.validateAjaxRequest, function (req, res, next) {
    var feedbackForm = server.forms.getForm('feedback');

    if (!feedbackForm.valid) {
        res.json({ success: false });
        return next();
    }

    this.on('route:BeforeComplete', function () {
        // Kalıcı kaydı burada yapın (custom object, servis çağrısı), bir Transaction içinde
    });

    res.json({ success: true });
    return next();
});

module.exports = server.exports();

OnRequest ve OnSession hook'lara dönüşür

SFRA, SiteGenesis'in pipeline veya controller olarak uyguladığı OnRequest ve OnSession handler'larını kullanmaz; Salesforce bunların, req ve res nesnelerine erişimi olmayan hook'lar olarak uygulanmasını söylüyor. dw.system.RequestHooks extension point'lerini, cartridge'ın package.json dosyasının işaret ettiği hooks dosyasına kaydedin ("hooks": "./hooks.json"). Script path'leri bu dosyaya göre yazılır:

{
  "hooks": [
    { "name": "dw.system.request.onSession", "script": "./cartridge/scripts/hooks/request/onSession.js" },
    { "name": "dw.system.request.onRequest", "script": "./cartridge/scripts/hooks/request/onRequest.js" }
  ]
}

Her script onSession veya onRequest fonksiyonunu export eder ve bir dw.system.Status döndürür; req ve res olmadığı için global request ve session nesneleriyle çalışır.

Şablonlar, istemci tarafı kod ve content slot'lar

ISML aynı dil, ama şablonlar yeniden yazılır: SFRA şablonları JSON model'leri okur, SFRA'nın Bootstrap 4 layout'ları içinde yer alır ve CSS ile JavaScript'i assets modülü üzerinden kaydeder (assets.addCss, assets.addJs). İstemci tarafı kod, SFRA'nın sgmf-scripts ile derlenen jQuery tabanlı script'leridir; SiteGenesis istemci script'leri taşınmaz. templates/resources altındaki resource bundle'lar dosya olarak taşınır, ancak SFRA'nın anahtarlarıyla birleştirilmeleri gerekir.

Business Manager, slot ID'lerini ve şablonları cartridge path üzerindeki şablonlardan okur (content slot processing). Slot konfigürasyonları veri olarak korunur, ancak başvurdukları her <isslot> ID'si ve render şablonu yeni şablonlarda bulunmalıdır; aksi halde o içerik görünmez olur.

Job'lar job framework'e taşınır

Legacy pipeline job'ları hangi vitrini seçerseniz seçin deprecated durumda. Cartridge kökündeki bir steptypes.json, geçici bir çözüm olarak mevcut bir process pipeline'ı çalıştıran bir pipeline-step tanımlayabilir; chunk-oriented step'ler pipeline kullanamaz (custom job step'ler). Hedef durum bir CommonJS script-module-step'tir:

{
  "step-types": {
    "pipeline-step": [
      {
        "@type-id": "custom.LegacyStockExport",
        "@supports-parallel-execution": "false",
        "@supports-site-context": "true",
        "@supports-organization-context": "false",
        "description": "Interim step: runs the SiteGenesis process pipeline unchanged",
        "pipeline": "StockExport-Start",
        "status-codes": {
          "status": [
            { "@code": "ERROR", "description": "The step failed." }
          ]
        }
      }
    ],
    "script-module-step": [
      {
        "@type-id": "custom.StockExport",
        "@supports-parallel-execution": "false",
        "@supports-site-context": "true",
        "@supports-organization-context": "false",
        "description": "Replacement step written as a CommonJS module",
        "module": "int_stock_export/cartridge/scripts/steps/stockExport.js",
        "function": "execute",
        "transactional": "false",
        "timeout-in-seconds": "900",
        "status-codes": {
          "status": [
            { "@code": "ERROR", "description": "The step failed." },
            { "@code": "OK", "description": "The step finished successfully." }
          ]
        }
      }
    ]
  }
}

Her cartridge yalnızca bir steptypes.json veya steptypes.xml barındırabilir; job parametreleri ve diğer seçenekler Salesforce'un steptypes.json örneğini izler. Bir pipeline step, pipeline'ın bulunduğu cartridge'ın cartridge path'te olmasını gerektirir; bu da bu step'leri hızla emekliye ayırmak için bir neden daha.

Hook'lar ve entegrasyonlar

hooks.json içindeki hook'lar SiteGenesis kodu değil, platform extension point'leridir; bu yüzden çoğu az değişiklikle taşınır. İstisna, SFRA'nın zaten uyguladığı her şeydir. SFRA'nın temel cartridge'ı kendi sepet hesaplama hook script'ini, scripts/hooks/cart/calculate.js dosyasını içerir; JSDoc'u bu script'i vitrin ile OCAPI'nin tek bir sepet hesaplamasını paylaşmasını sağlayan kod olarak tanımlıyor. Bu yüzden özelleştirilmiş bir dw.order.calculate hook'unu kopyalamak yerine onunla karşılaştırın. Business Manager'daki servis konfigürasyonları kalır; yalnızca onları çağıran kod taşınır.

Değişmeden taşınanlar

SFRA SSS'sine göre SFRA'ya geçmek mevcut veriyi, iş kurallarını ve back-end entegrasyonlarını etkilemez. Pratikte:

Olduğu gibi taşınır	Gözden geçirilmeli
Kataloglar, price book'lar ve stok	SiteGenesis CSS sınıflarını kullanan veya SiteGenesis endpoint'lerine link veren content asset'ler
Müşteriler ve sipariş geçmişi	Slot konfigürasyonları: slot ID'leri ve render şablonları SFRA'da bulunmalı
Promosyonlar, kampanyalar ve müşteri grupları	Yalnızca SiteGenesis kodunun okuduğu custom attribute'lar ve site tercihleri
Konfigürasyon olarak URL kuralları, static mapping'ler ve yönlendirmeler	SiteGenesis'e özgü endpoint'leri hedefleyen kural ve mapping'ler
Servis konfigürasyonları	Legacy pipeline job'ları ve step'leri SiteGenesis cartridge'larından gelen job'lar

SFRA, source code yönlendirmeleri için Link-Category, Link-Page ve Link-Product route'larını, belirli pipeline'lara link veren eski content asset'leri desteklemek için de Link-CategoryProduct route'unu korur (SFRA JSDoc). Özel endpoint'ler için en ucuz çözüm çoğu zaman SFRA controller'ına ve route'una SiteGenesis'teki adı vermektir; böylece o adı kullanan her kural, mapping ve link çalışmaya devam eder.

SEO sürekliliği

Vitrin değişir; URL'ler değişmemeli. İşin çoğu zaten var olan konfigürasyondur:

URL kuralları kalır. SFRA şablonları link'leri URLUtils ile standart route'lara ürettiği sürece kategori, ürün ve içerik URL'leri sitenin URL kurallarından gelir (Merchant Tools > Site > SEO & Discoverability > URL Rules). Yine de iki vitrini de tarayıp URL kümelerini karşılaştırın.
Pipeline URL'leri kontrol edilmeli. URL kuralları pipeline URL'lerini de kapsar. URL Archive eskimiş eşlemeleri güncel olanlara yönlendirir; temizlik araması da geçerli bir kategori, klasör veya pipeline'a başvurmayan eşlemeleri bulur. Canlıya geçişten sonra çalıştırın.
Static mapping'ler endpoint'leri adıyla hedefler. Her static mapping hedefi SFRA'da bulunmalıdır. Mapping'ler bir hostname alias gerektirir, staging'den production'a replike edilir ve Business Manager'da 2 MB ile sınırlıdır (daha büyük kümeler site import ile yüklenir).
Render edilen head'i karşılaştırın. Search Console'daki en önemli URL'ler için iki render arasında <title>, meta description, canonical, hreflang ve yapılandırılmış veriyi karşılaştırın. SiteGenesis şablonlarına sabit yazılmış her şey, siz taşıyana kadar eksik kalır.

! eski URL -> SFRA'nın app_storefront_base cartridge'ında bulunan endpoint
/summer-sale p,,,Link-Category,,cgid,summer-sale
/about-us p,,,Link-Page,,cid,about-us

Commerce Cloud SEO rehberi platform ayarlarını, Commerce Cloud geçiş rehberi ise yönlendirme eşlemesini ve Search Console takibini anlatıyor.

Test ve canlıya geçiş

Neler test edilmeli

URL tekrarı. Envanterdeki her URL'yi (Search Console dışa aktarımları, static mapping'ler, sitemap'ler, e-posta link'leri) SFRA staging sitesine isteyin; durum kodunu ve son URL'yi doğrulayın.
Checkout matrisi. Her ödeme ve kargo yöntemi, misafir ve kayıtlı kullanıcı, her locale.
Job'lar ve entegrasyonlar. Her job staging'de production'a benzer veriyle; her partner entegrasyonu uçtan uca.
Performans. SFRA page cache'i (sayfa önbelleği) middleware ile route bazında ayarlar: önbelleğe alınabilir sayfaların gerçekten önbelleğe alındığını doğrulayın ve gelir getiren şablonların saha verisini karşılaştırın.

Tek code version ile canlıya geçiş

Code deployment yapı taşlarını verir. Bir instance tek bir aktif code version çalıştırır; en iyi uygulama, staging'de aktif olmayan bir version'a yüklemek, test etmek ve production'a replike etmektir. Aktivasyon önbellekteki öğeleri temizler; Rollback ise önceki version hâlâ yüklüyse onu yeniden aktive eder. Cartridge'lar Administration > Sites > Manage Sites altında site bazında atanır.

Bu olgulara dayanan bir yaklaşım (staging'de prova edin; Salesforce'un öngördüğü bir prosedür değildir):

Hem SiteGenesis hem SFRA cartridge'larını içeren tek bir code version oluşturun. Sitenin cartridge path'i hâlâ SiteGenesis cartridge'larını listelediği sürece bu version'ı aktive etmek alışveriş yapanlar için hiçbir şeyi değiştirmez.
SFRA vitrininin ihtiyaç duyduğu URL kurallarını, static mapping'leri ve diğer konfigürasyonları replike edin.
Kararlaştırılan saatte sitenin cartridge path'ini SFRA yığınına çevirin ve page cache'i geçersiz kılın.
Geri almak için path'i eski haline döndürün; code deployment gerekmez.
Site stabil olduğunda SiteGenesis cartridge'larını sonraki code version'lardan çıkarın; böylece unutulmuş hiçbir pipeline erişilebilir kalmaz.

Aşamalı plan

Aşama	İş	Çıkış kriteri
0. Karar	SFRA mı headless mi; çoklu site realm'lerinde site sırası	Üzerinde anlaşılmış yol ve ilk site
1. Envanter	Adım 1 tablosu, site bazında	Her endpoint, job, hook ve entegrasyonun bir sahibi ve hedefi var
2. Temel	SFRA base ve `modules`, `app_custom_*` iskeleti, SFRA partner cartridge'ları, `sgmf-scripts` build'i	SFRA, sizin verinizle bir sandbox'ta çalışıyor
3. Taşıma	Route'lar, model'ler, şablonlar, formlar, hook'lar, tasarım	Özellik eşitliği listesi kapandı
4. Job'lar ve entegrasyonlar	Legacy job'lar job framework'e taşındı; regresyon testleri	Her job staging'de çalışıyor
5. SEO	URL kuralları, static mapping'ler, head etiketi karşılaştırması	URL tekrarı geçiyor
6. Prova	Staging'de canlıya geçiş ve geri alma	Süresi ölçülmüş runbook; geri alma kanıtlandı
7. Canlıya geçiş	Cartridge path değişimi, hypercare	Hatalar, dönüşüm ve tarama istatistikleri stabil
8. Devreden çıkarma	SiteGenesis cartridge'ları kaldırıldı; URL Archive temizlendi	Aktif version'da SiteGenesis kodu yok

Önemli çıkarımlar

SiteGenesis için açıklanmış bir destek sonu tarihi yok ve Salesforce'un pipeline'ları kullanımdan kaldırma planı yok. Baskı başka yerden geliyor: Salesforce Payments gibi yeni özellikler SFRA'yı hedefliyor ve vitrin seçim rehberi SiteGenesis'i listelemiyor.
Geçiş, değişmeyen veri üzerinde bir vitrin yeniden yazımıdır. Kataloglar, müşteriler, siparişler ve Business Manager konfigürasyonu kalır; controller'lar, şablonlar ve istemci kodu yeniden yazılır.
Sayfaların değil, endpoint'lerin envanterini çıkarın. URL kurallarının, static mapping'lerin, içeriğin veya partner'ların kullandığı her pipeline ya da controller adı canlıya geçişten sonra çözülmeye devam etmeli.
Pipeline'lar GET ve POST route çiftlerine, OnRequest ve OnSession hook'lara dönüşür; legacy job'lar steptypes.json'a taşınır, formlar XML tanımlarını korur.
İki yığını birden taşıyan tek bir code version, canlıya geçişi ve geri almayı bir cartridge path değişikliğine indirger. Uzun vadeli hedef headless ise önce Storefront Next'i değerlendirin; geçiş aracı pipeline mantığını elle yapılacak iş olarak bırakır.

Bir geçiş değerlendirmesi veya SFRA yeniden inşa planı için SFCC danışmanlık hizmetlerine göz atın ya da iletişime geçin.

Ek kaynaklar

SFRA Frequently Asked Questions: Salesforce'un SiteGenesis desteği, platform verisi ve LINK cartridge'ları hakkındaki tutumu.
Is there a timeline for deprecating pipelines?: pipeline'ları kullanımdan kaldırma planı olmadığını doğrulayan bilgi bankası makalesi.
SFRA Features and Components: cartridge katmanları, server modülü, controller çözümleme ve OnRequest/OnSession hook'ları.
Migrate Your Storefront to Storefront Next: geçiş aracı, SiteGenesis gereksinimleri ve sınırları.
Code Deployment: code version'lar, aktivasyon, rollback ve replikasyon.
Static Mappings for B2C Commerce: eski URL eşlemelerinin söz dizimi ve sınırları.

SiteGenesis'ten SFRA'ya Geçiş: SFCC Ekipleri için Teknik Rehber