XML entegrasyonunda:

“XML'i 15 dakikada bir güncelleyelim.”

kararı vermek operasyonun yalnızca bir bölümüdür.

Asıl teknik soru bundan sonra başlar:

15 dakikada bir tam olarak hangi işlem çalışacak?

Örneğin tek bir XML güncellemesi gerçekte şu işlemlerden oluşabilir:

tedarikçi XML'ini indir

↓

dosyanın sağlıklı olduğunu kontrol et

↓

ürün kayıtlarını parse et

↓

alanları normalize et

↓

SKU eşleştirmesini yap

↓

stok ve fiyatları doğrula

↓

değişiklikleri hesapla

↓

mağaza verisini güncelle

↓

satış kanallarına gönder

↓

sonucu logla

Bu işlemlerin tamamını tek bir:

“XML güncelle”

komutunun içine kontrolsüz biçimde koymak, katalog büyüdükçe yönetimi zorlaştırabilir.

Zamanlanmış XML güncelleme planının amacı:

yalnızca görevin saatini belirlemek değil, veri akışının hangi sırayla ve hangi güvenlik koşulları altında çalışacağını belirlemektir.

Ulu İthalat'ın canlı XML Bayilik sayfasında ürün, fiyat, stok ve görsel bilgilerinin XML yoluyla satış kanallarına aktarılabildiği ve özellikle stok ile fiyat değişikliklerinin düzenli takip edilmesinin önemli olduğu belirtiliyor.

XML Zamanlanmış Güncelleme Nedir?

XML zamanlanmış güncelleme; entegrasyon işlemlerinin manuel olarak başlatılmasını beklemek yerine önceden belirlenmiş bir çalışma planı üzerinden otomatik yürütülmesidir.

Örneğin sistem:

belirlenmiş aralık geldi

↓

Supplier-A XML görevini başlat

↓

feed'i doğrula

↓

başarılıysa değişiklikleri işle

↓

sonucu satış kanallarına gönder

↓

job durumunu kaydet

şeklinde çalışabilir.

Buradaki:

“belirlenmiş aralık ne olmalı?”

sorusu 110'un konusudur.

117 ise:

“o aralık geldiğinde operasyon nasıl güvenli çalışacak?”

sorusunu cevaplar.

1. Önce Güncelleme Sıklığı Kararını Ayrı Tutun

Zamanlama planına başlamadan önce:

15 dakika

1 saat

günde birkaç kez

gibi çalışma sıklığının zaten belirlenmiş olması gerekir.

Canlı XML Güncelleme Sıklığı Nasıl Belirlenir? içeriği bu kararın stok değişim hızı, fiyat değişimleri, feed boyutu, işlem süresi ve kaynak tazeliğine göre verilmesini ayrıntılı biçimde ele alıyor.

117 bu kararı tekrar hesaplamamalıdır.

2. Sıklık ile Zamanlama Planı Aynı Şey Değildir

Örneğin:

Sıklık: saatte bir.

Bu yalnızca periyodu belirtir.

Zamanlama planı ise şunları da tanımlar:

• hangi dakikada başlayacak,
• hangi tedarikçi önce çalışacak,
• hangi job diğerini bekleyecek,
• önceki job bitmediyse ne olacak,
• hata olursa yeniden denenecek mi,
• hangi satış kanalları güncellenecek,
• başarı nasıl doğrulanacak.

Dolayısıyla 117'nin konusu orchestration olmalıdır.

3. Bütün XML İşlemlerinin Envanterini Çıkarın

İlk adım mevcut görevleri listelemektir.

Örneğin:

Supplier-A feed download

Supplier-A import

Supplier-B feed download

stok güncelleme

fiyat güncelleme

pasif ürün kontrolü

pazaryeri stok gönderimi

pazaryeri fiyat gönderimi

gibi.

Ne çalıştığı bilinmeden sağlıklı zamanlama oluşturulamaz.

4. Her Göreve Açık Bir İsim Verin

Örneğin:

SUPPLIER_A_FETCH

SUPPLIER_A_VALIDATE

SUPPLIER_A_IMPORT

MARKETPLACE_STOCK_PUSH

gibi.

Bu özellikle hata loglarında:

hangi görev başarısız oldu?

sorusunu kolaylaştırır.

5. Tek Büyük Job Yerine Mantıksal Aşamalar Düşünün

Örneğin:

XML_SYNC

isimli dev bir işlem yerine:

FETCH

↓

VALIDATE

↓

IMPORT

↓

PUBLISH

katmanları ayrılabilir.

Bu sayede:

dosya indirildi ancak validation başarısız oldu

gibi durumlar daha açık görülebilir.

6. XML'i İndirme ile Canlı Veriyi Güncellemeyi Ayırın

XML URL'sine erişmek:

kaynak alma aşamasıdır.

Ürün stoğunu değiştirmek:

uygulama aşamasıdır.

İkisini tek işlem gibi görmek yerine:

fetch başarılı

↓

validation başarılı

↓

apply

şeklinde güvenlik kapısı oluşturulabilir.

7. Validation Başarısızsa Apply Job'ı Çalışmamalıdır

Örneğin feed:

• yarım,
• bozuk,
• beklenenden çok küçük,
• stok alanı eksik

geldi.

Bu durumda:

dosyayı aldık → ürünleri güncelle

akışı durdurulabilir.

Böylece hatalı XML'in canlı kataloğa yayılması önlenir.

8. Job Bağımlılıklarını Açıkça Belirleyin

Örneğin:

PRICE_PUSH

görevi:

XML_IMPORT

başarılı olmadan başlamamalıdır.

Benzer şekilde:

MARKETPLACE_STOCK_PUSH

önce mağaza stoğunun başarıyla güncellenmesini beklemelidir.

Bu yapı görevler arasında bir bağımlılık zinciri oluşturur.

9. Sadece Saat Vererek Bağımlılık Oluşturmayın

Riskli örnek:

14:00 → XML import

14:05 → pazaryeri push

XML import normalde 3 dakika sürüyor olabilir.

Ama bugün:

12 dakika

sürdüyse 14:05 görevi henüz hazır olmayan veriyi gönderebilir.

Bu nedenle mümkün olduğunda:

saat bağımlılığı

yerine:

önceki job başarı durumu

kullanılmalıdır.

10. Güncelleme Zincirini Bir State Machine Gibi Düşünebilirsiniz

Örneğin:

SCHEDULED

↓

RUNNING

↓

FETCHED

↓

VALIDATED

↓

APPLIED

↓

PUBLISHED

↓

SUCCESS

veya:

FAILED

durumları bulunabilir.

Bu, uzun XML işlemlerinin hangi aşamada olduğunu görmeyi kolaylaştırır.

11. Her Çalışmaya Benzersiz Sync ID Verin

Örneğin:

SYNC-20260823-0012

Bu kimlik:

• download,
• validation,
• import,
• marketplace update

loglarının tamamında kullanılabilir.

Sonradan tek bir senkronizasyon uçtan uca takip edilebilir.

12. Zamanlama Tanımını Merkezi Bir Yerde Tutun

Farklı sunuculara dağılmış onlarca ayrı cron kaydı operasyonu takip etmeyi zorlaştırabilir.

Modern scheduler yapıları görev takvimini uygulama içerisinde merkezi olarak tanımlayabilir. Örneğin Laravel'in güncel scheduler dokümantasyonu görevlerin uygulama içerisinde tanımlanabildiğini ve schedule:list benzeri araçlarla planlanan görevlerin ve bir sonraki çalışma zamanlarının görüntülenebildiğini açıklıyor.

Genel ilke:

zamanlama görünür ve denetlenebilir olmalıdır.

13. Scheduler ile İş Mantığını Birbirinden Ayırın

Scheduler'ın görevi:

“şimdi çalıştır.”

demektir.

XML iş mantığı ise:

• feed'i indir,
• kontrol et,
• ürünleri eşleştir,
• stokları hesapla

gibi işlemlerdir.

İş mantığını doğrudan cron satırlarına gömmek yerine ayrı job/command yapısında tutmak yönetimi kolaylaştırabilir.

14. Tedarikçileri Aynı Dakikada Başlatmak Zorunda Değilsiniz

Örneğin 10 tedarikçi XML'i:

00. dakikada

aynı anda başlarsa:

• CPU,
• RAM,
• network,
• database

yükü bir anda artabilir.

Görevler örneğin farklı dakikalara dağıtılabilir.

Bu staggering yaklaşımıdır.

15. Zaman Dağılımını Sıklık Kararıyla Karıştırmayın

Supplier A ve B'nin ikisi de:

saatte bir

çalışabilir.

Ancak:

A → :05

B → :20

şeklinde planlanabilir.

İkisi de aynı sıklıktadır fakat aynı anda çalışmaz.

Bu 117'nin özgün alanlarından biridir.

16. Ağır ve Hafif Görevleri Ayırın

Örneğin:

stok kontrolü

çok hızlı olabilir.

Ancak:

20.000 görsel indirme

uzun sürebilir.

İki görevin aynı işlem penceresine yerleştirilmesi diğer kritik stok/fiyat güncellemelerini geciktirebilir.

17. Görsel Güncellemelerini Kritik Stok Job'ından Ayırabilirsiniz

Stok:

sipariş alınabilirliğini etkiler.

Görsel değişikliği ise genellikle aynı zaman hassasiyetine sahip değildir.

Bu nedenle:

stok/fiyat hızlı görevler

ile:

ürün içerik/görsel ağır görevleri

farklı job gruplarında çalıştırılabilir.

18. Önceki Job Bitmeden Yeni Job Başlatılmamalıdır

Örneğin görev:

10 dakikada bir

tetikleniyor.

Ancak bugünkü işlem:

17 dakika

sürdü.

Yeni çalışma önceki bitmeden başlarsa aynı ürünler iki süreç tarafından eş zamanlı güncellenebilir.

Canlı 110 içeriği de bu riski özellikle ele alıyor.

117'de ise bunun zamanlama planına hangi koruma olarak ekleneceği açıklanmalıdır.

19. Overlap Lock Kullanın

Scheduler altyapısı izin veriyorsa görev:

zaten çalışıyorsa ikinci kopyasını başlatma

şeklinde tanımlanabilir.

Güncel Laravel scheduler örneğinde withoutOverlapping mekanizması önceki görev hâlâ çalışıyorsa yeni scheduled çalışmanın çakışmasını engellemek için kullanılabiliyor.

Bu genel prensip XML senkronizasyonlarında özellikle değerlidir.

20. Kilidin Sonsuza Kadar Takılı Kalmamasını Planlayın

Sunucu beklenmedik biçimde kapanırsa:

RUNNING

veya lock durumu geride kalabilir.

Bu durumda job bir daha başlamayabilir.

Kullanılan scheduler'ın:

• lock expiration,
• stale lock cleanup

mekanizması bilinmelidir.

21. Çoklu Sunucuda Aynı Görevin Birden Fazla Kez Çalışmasını Önleyin

Uygulama birkaç sunucuda çalışıyorsa her sunucu aynı scheduled job'ı başlatabilir.

Sonuç:

aynı XML üç kez işlenebilir.

Bazı scheduler altyapıları görevin yalnızca tek sunucuda yürütülmesine yönelik atomik kilit mekanizmaları sağlar; güncel Laravel dokümantasyonunda onOneServer bunun örneklerinden biridir.

22. Scheduler ile Queue Aynı Şey Değildir

Scheduler:

işin ne zaman başlayacağını

belirler.

Queue:

başlatılan işin nasıl ve hangi worker tarafından işleneceğini

yönetebilir.

Örneğin scheduler:

14:00 → Supplier A güncellemesini başlat.

Queue:

10.000 ürünü parça parça işle.

Bu iki katmanın görevleri ayrıdır.

23. Büyük Feed'lerde Chunk İşleme Kullanılabilir

Örneğin:

50.000 ürün

tek büyük job içerisinde işlenmek yerine:

1–1.000

1.001–2.000

gibi gruplara ayrılabilir.

Bu:

• timeout,
• memory,
• retry

yönetimini kolaylaştırabilir.

Ancak bütün parçaların aynı feed snapshot'ına ait olduğu korunmalıdır.

24. Chunk'ların Aynı Veri Sürümünü Kullandığını Doğrulayın

İlk 5.000 ürün:

Feed V1

son 5.000 ürün:

Feed V2

üzerinden işlenirse katalog karışık snapshot haline gelebilir.

Bu nedenle tek senkronizasyonda mümkünse:

tek doğrulanmış feed snapshot

kullanılmalıdır.

25. Paralel İşlem Kullanırken Ürün Çakışmasını Kontrol Edin

Paralel worker'lar performansı artırabilir.

Ancak iki worker aynı:

SKU

üzerinde aynı anda işlem yapıyorsa race condition oluşabilir.

Chunk tasarımı ürün kayıtlarını güvenli biçimde ayırmalıdır.

26. Tedarikçi İstek Limitlerini Zamanlama Planına Ekleyin

Tedarikçi:

• istek limiti,
• belirli erişim saatleri,
• minimum kontrol aralığı

uygulayabilir.

Scheduler bu sınırları görmezden gelmemelidir.

Aksi halde sık retry veya paralel job kaynağı gereksiz yere yükleyebilir.

27. Timeout Süresini Job Tipine Göre Belirleyin

XML download:

10 saniyede bitebilir.

Büyük katalog importu:

dakikalar sürebilir.

Bütün işlemlerde tek timeout değeri kullanmak uygun olmayabilir.

fetch timeout

ve:

processing timeout

ayrı değerlendirilebilir.

28. Başarısız Görev İçin Retry Politikası Belirleyin

Örneğin feed geçici olarak erişilemiyor.

İlk hata sonrası:

yeniden dene

mantığı kullanılabilir.

Ancak retry'nin:

• kaç kez,
• ne aralıkla,
• hangi hata türlerinde

çalışacağı belirlenmelidir.

29. Her Hatayı Retry Etmeyin

Network timeout

geçici olabilir.

Ancak:

XML schema tamamen değişti

ise aynı job'ı 20 kez tekrar çalıştırmak sonucu değiştirmeyebilir.

Hatalar:

RETRYABLE

ve:

NON_RETRYABLE

olarak sınıflandırılabilir.

30. Retry'lerde Kademeli Bekleme Kullanılabilir

İlk başarısızlık sonrası kısa,

sonraki başarısızlıklarda daha uzun

bekleme kullanılabilir.

Amaç kaynak sunucuyu arka arkaya yoğun biçimde sorgulamamaktır.

31. Maksimum Retry Sayısını Belirleyin

Sonsuz retry:

• sunucu yükü,
• log şişmesi,
• kaynak yükü

oluşturabilir.

Belirli sayıdan sonra job:

FAILED

durumuna alınarak alarm üretebilir.

32. Kaçırılan Çalışmalar İçin Politika Oluşturun

Sunucu 2 saat kapalı kaldı.

Normalde XML dört kez çalışacaktı.

Sunucu açıldığında:

dört eski sync'i sırayla çalıştırmak

gerekli olmayabilir.

Bazı operasyonlarda yalnızca:

en güncel feed'i işle

daha anlamlı olabilir.

Bu karar feed türüne göre verilmelidir.

33. “Catch-Up” İşlemi Katalogu Boğmamalıdır

Normalde:

saatlik job.

Sistem 12 saat kapalı.

Tekrar açılınca:

12 ayrı tam katalog importu

aynı anda başlatılırsa yüksek yük oluşabilir.

Missed-run politikası önceden tanımlanmalıdır.

34. Manuel Çalıştırma Seçeneği Bulundurun

Scheduled job çalışıyor olsa bile bazen:

şimdi tekrar güncelle

ihtiyacı doğabilir.

Manuel çalıştırmada da:

• overlap,
• validation,
• loglama

kuralları atlanmamalıdır.

35. Manuel Job Zamanlanmış Job'la Çakışmamalıdır

Operatör manuel sync başlattı.

İki dakika sonra scheduled sync zamanı geldi.

İki işlem aynı anda başlamamalıdır.

Manual ve scheduled tetikleyiciler aynı lock sistemini kullanabilir.

36. Dry-Run Modu Faydalıdır

Zamanlanmış görev gerçek veri yazmadan:

kaç ürün değişecek

kaç stok sıfırlanacak

kaç fiyat değişecek

kaç hata oluşacak

raporu üretebilir.

Yeni schedule canlıya alınmadan önce bu modda denenebilir.

37. Aynı İşlemin Tekrar Çalıştırılması Güvenli Olmalıdır

Bir job:

başarısız göründü.

Operatör tekrar çalıştırdı.

Aynı ürün:

iki kez oluşmamalı,

aynı stok hareketi iki kez uygulanmamalıdır.

Bu nedenle scheduled işlemler mümkün olduğunca idempotent tasarlanmalıdır.

38. İlk Import ile Scheduled Update'i Ayırın

İlk XML aktarımı:

• ürün oluşturma,
• görseller,
• açıklamalar,
• kategoriler

gibi kapsamlı olabilir.

Rutin scheduled update ise:

• fiyat,
• stok,
• aktiflik

gibi kritik alanlarla sınırlı olabilir.

Canlı 110 içeriğinde de ilk aktarım ile rutin güncellemenin ayrılması öneriliyor.

117'de bunun farklı job planlarına dönüştürülmesi sahiplenilmelidir.

39. İçerik Güncelleme Job'ını Fiyat/Stok Job'ından Ayırabilirsiniz

Örneğin:

kritik sync

fiyat + stok

content sync

ürün adı + görsel + açıklama

olabilir.

Böylece ağır içerik işlemi kritik ticari verinin zamanında aktarılmasını engellemez.

40. Fiyat ve Stok Aynı Snapshot'tan Geliyorsa Tutarlılığı Koruyun

Feed aynı anda:

stok 10

ve:

yeni maliyet 150 TL

gönderiyor olabilir.

Stok bugünkü feed'den,

fiyat dünün feed'inden

işlenirse iki alan farklı veri dönemlerini temsil edebilir.

Hangi alanların birlikte güncellenmesi gerektiği planlanmalıdır.

41. Satış Kanalına Gönderimi Import Başarısına Bağlayın

Örneğin:

XML validation başarısız.

Ama pazaryeri push job'ı yine çalıştı.

Bu durumda eski veya yarım veri kanala gönderilebilir.

Daha kontrollü yapı:

IMPORT_SUCCESS

olmadan:

CHANNEL_PUSH

başlatmamak olabilir.

42. Partial Success Durumunu Ayrı Planlayın

10.000 ürünün:

9.950'si başarılı,

50'si hatalı.

Ne olacak?

İki seçenek olabilir:

9.950'yi yayınla, 50'yi review'a al

veya:

bütün batch'i durdur.

Bu iş kuralı scheduled job tasarımında önceden belirlenmelidir.

43. Başarısız Job Sonrasında Önceki Güvenilir Veri Korunmalıdır

XML job başarısız oldu diye:

• stokları sıfırlamak,
• fiyatları silmek,
• ürünleri pasife almak

genel varsayılan davranış olmamalıdır.

116 numaralı stok sıfırlama konusu özellikle bu güvenlik alanını derinleştirir.

117'de ise başarısız scheduled job'ın:

yanlış takip job'larını tetiklememesi

önemlidir.

44. Bakım ve Deploy Dönemlerini Planlayın

Yazılım güncellemesi sırasında:

• database migration,
• kod değişikliği,
• queue restart

yapılıyor olabilir.

Aynı anda ağır XML importunun çalışması istenmeyebilir.

Scheduler altyapısının bakım modunda görev davranışı bilinmelidir. Güncel Laravel scheduler dokümantasyonu scheduled task'ların bakım modundaki davranışını ve görevlerin geçici olarak duraklatılmasını ayrıca destekliyor.

45. Scheduled Job'ı Gerektiğinde Kontrollü Durdurabilin

Tedarikçi XML'i bozuldu.

Entegrasyon her 15 dakikada aynı hatayı uyguluyor.

Böyle bir durumda:

kodu deploy etmeden schedule'ı geçici durdurabilme

yeteneği operasyon açısından yararlı olabilir.

Durum düzeldikten sonra kontrollü biçimde yeniden başlatılabilir.

46. Timezone'u Açıkça Tanımlayın

Özellikle sistem:

• farklı ülke sunucusu,
• farklı tedarikçi,
• farklı kanal

kullanıyorsa:

14:00 hangi timezone?

sorusu önemlidir.

Modern scheduler'lar görev timezone'u tanımlayabilir; ayrıca daylight-saving kullanan zaman dilimlerinde görevin iki kez çalışması veya hiç çalışmaması gibi riskler oluşabileceği de güncel Laravel dokümantasyonunda belirtiliyor.

47. Zamanlama Planında Sunucu Saatine Körü Körüne Güvenmeyin

Uygulama:

UTC

kullanıyor olabilir.

Operasyon paneli:

yerel saat

gösterebilir.

Tedarikçi:

başka timezone

kullanabilir.

Loglarda zaman bilgisi mümkün olduğunca açık tutulmalıdır.

48. Başarı ve Hata Callback'leri Kullanılabilir

Scheduled job bittiğinde sistem:

SUCCESS

veya:

FAILED

sonucuna göre farklı aksiyon alabilir.

Örneğin güncel Laravel scheduler'ında başarı ve başarısızlık için ayrı callback/hook mekanizmaları bulunuyor.

Genel prensip:

job bitti → sonucu değerlendir → sonraki aksiyonu buna göre tetikle

olmalıdır.

49. Başarısız Görev İçin Alarm Oluşturun

Bir XML güncellemesi birkaç gün hiç çalışmazsa:

“scheduled” olması tek başına işe yaramaz.

Örneğin alarm:

Supplier-A XML sync failed

Son başarılı çalışma: ...

Hata aşaması: FETCH

gibi bilgi sunabilir.

50. “Çalıştı” ile “Başarılı Güncelledi” Ayrımını Koruyun

Cron saatinde tetiklendi.

Bu sadece:

job başladı

demektir.

Gerçek başarı:

feed indirildi

validation geçti

veriler uygulandı

kanal gönderimi tamamlandı

gibi aşamalardan sonra belirlenmelidir.

51. last_attempt ve last_successful_sync Ayrı Tutulmalıdır

Örneğin:

Son deneme:

15:00

Son başarılı:

12:00

ise sistem üç saattir güncel veri alamıyor olabilir.

Canlı 110 içeriği de bu ayrımı özellikle öneriyor.

117'de bu bilgi scheduler dashboard'unun temel metriklerinden biri olabilir.

52. Scheduled Job Dashboard'u Oluşturabilirsiniz

Örneğin panel:

Supplier A

Son başarı → 15:00

Son süre → 3 dk 20 sn

Sonuç → SUCCESS

Sonraki çalışma → 16:00

gösterebilir.

Böylece cron dosyalarına bakmadan operasyon görülebilir.

53. Sonraki Çalışma Zamanının Görünmesi Faydalıdır

Operatör:

“Bu XML bir daha ne zaman çalışacak?”

sorusuna cevap verebilmelidir.

Bazı scheduler sistemleri görevlerin ve sonraki çalışma zamanlarının listelenmesine yönelik yerleşik komutlar sunar.

Bu yalnızca geliştirici için değil operasyon kontrolü için de yararlıdır.

54. Job Çalışma Süresini Kaydedin

Örneğin:

normal:

4 dakika.

Bugün:

28 dakika.

Bu durum:

• feed büyümesi,
• database yavaşlığı,
• kaynak problemi

olabilir.

Scheduled plan yalnızca start time değil duration da izlemelidir.

55. Beklenen Süreyi Aşan Job İçin Alarm Kurabilirsiniz

Görev teknik olarak hâlâ:

RUNNING

olabilir.

Ancak normalin çok üzerinde çalışıyorsa:

stuck job

ihtimali vardır.

Bu durumda yeni job'ın overlap nedeniyle sürekli atlanması da mümkündür.

56. Tedarikçi Bazlı Bağımsızlık Sağlayın

Supplier A feed'i bozuldu.

Supplier B sağlıklı.

A'daki hata:

bütün XML senkronizasyon sistemini

durdurmamalıdır.

Tedarikçi job'ları yeterince bağımsız tasarlanabilir.

57. Bir Tedarikçinin Ağır Job'ı Diğerlerini Bloke Etmemelidir

Supplier A:

50.000 ürün.

Supplier B:

500 ürün.

Tek işlem kuyruğunda A bütün kapasiteyi kullanıyorsa B'nin kritik stok değişiklikleri gecikebilir.

Queue veya worker öncelikleri buna göre planlanabilir.

58. Kritik Görev Öncelikleri Tanımlayın

Örneğin:

yüksek öncelik

stok/pasiflik.

orta

fiyat.

daha düşük

görsel/içerik.

Bu yalnızca örnektir.

Gerçek öncelik işletmenin riskine göre belirlenmelidir.

59. Schedule Değişikliklerini Loglayın

Örneğin:

Supplier-A:

saatlik → 30 dakikalık

olarak değiştirildi.

Kim değiştirdi?

Ne zaman?

Neden?

Bu bilgi ileride:

“Sunucu yükü neden arttı?”

veya:

“Stok güncellemeleri neden gecikti?”

sorularını açıklayabilir.

60. Zamanlanmış Güncellemeyi Bir Operasyon Planı Olarak Görün

İyi plan yalnızca:

*/15 * * * *

gibi bir cron ifadesi değildir.

Asıl sistem:

ne zaman → hangi job → hangi kaynak → hangi koşulla → hangi sırayla → hangi lock ile → hangi retry politikasıyla → hangi başarı kriteriyle → hangi sonraki görevi tetikleyerek

çalışacağını tanımlar.

117'nin ana değeri burada oluşur.

XML ZAMANLANMIŞ GÜNCELLEME KONTROL LİSTESİ

Sıklık

Çalışma aralığı 110'daki yöntemle belirlendi mi?

Görev adı

Her job ayrı isim taşıyor mu?

Tedarikçi

Job hangi kaynağa ait belli mi?

Aşama

Fetch, validate, import ve publish ayrılmış mı?

Bağımlılık

Bir job diğerinden önce yanlışlıkla başlayabilir mi?

Snapshot

Aynı senkronizasyon aynı feed sürümünü mü kullanıyor?

Overlap

Önceki job bitmeden yenisi başlayabiliyor mu?

Lock

Aynı iş ikinci kez tetikleniyor mu?

Çoklu sunucu

Aynı görev birkaç sunucuda aynı anda çalışıyor mu?

Queue

Scheduler ve ürün işleme görevleri ayrılmış mı?

Chunk

Büyük katalog güvenli parçalara ayrılıyor mu?

Rate limit

Tedarikçinin teknik sınırları dikkate alınıyor mu?

Timeout

İşlem türüne uygun mu?

Retry

Hangi hatalarda yeniden deneneceği belli mi?

Retry limiti

Sonsuz tekrar önleniyor mu?

Missed run

Kaçırılan görevlerin ne olacağı belirli mi?

Manuel çalışma

Scheduled job ile çakışıyor mu?

Dry-run

Canlı veri yazmadan test edilebiliyor mu?

Idempotency

Aynı job iki kez çalışınca duplicate oluşuyor mu?

Maintenance

Deploy sırasında job davranışı belli mi?

Timezone

Çalışma saatinin hangi timezone'a ait olduğu belirli mi?

Başarı

Başarılı sayılması için hangi aşamaların tamamlanması gerekiyor?

Hata

Başarısız job alarm üretiyor mu?

Last success

Son başarılı çalışma kaydediliyor mu?

Duration

İşlem süresi takip ediliyor mu?

Next run

Bir sonraki çalışma zamanı görülebiliyor mu?

Audit

Schedule değişiklikleri kayıt altında mı?

XML ZAMANLANMIŞ GÜNCELLEME NASIL PLANLANIR?

Pratik uygulama sırası:

1. Önce her tedarikçi için uygun güncelleme sıklığını belirleyin.

2. XML operasyonundaki bütün scheduled görevleri listeleyin.

3. Her göreve açık ve benzersiz bir isim verin.

4. Fetch, validation, import ve channel-publish aşamalarını ayırın.

5. Görev bağımlılıklarını belirleyin.

6. Tek senkronizasyonun kullanacağı feed snapshot'ını sabitleyin.

7. Tedarikçilerin çalışma saatlerini birbirine yığmadan dağıtın.

8. Kritik fiyat/stok görevlerini ağır içerik işlerinden ayırın.

9. Overlap ve lock mekanizması ekleyin.

10. Çok sunuculu sistemde tek-job çalıştırma kontrolü oluşturun.

11. Büyük kataloglarda queue/chunk modelini belirleyin.

12. Tedarikçi rate-limit ve timeout kurallarını tanımlayın.

13. Retry edilebilir ve edilemez hataları ayırın.

14. Maksimum retry ve missed-run politikalarını belirleyin.

15. Manuel çalıştırmanın da aynı güvenlik kurallarından geçmesini sağlayın.

16. Maintenance/deploy sırasında görev davranışını belirleyin.

17. Başarı, partial success ve failure kriterlerini tanımlayın.

18. Son deneme, son başarı, süre ve sonraki çalışma zamanını loglayın.

19. Önce test/dry-run ortamında bütün zinciri çalıştırın.

20. Canlıya geçtikten sonra job sürelerini, hataları ve schedule performansını düzenli izleyin.

SIK SORULAN SORULAR

XML güncelleme sıklığı ile zamanlanmış güncelleme aynı şey midir?

Hayır. Güncelleme sıklığı XML'in ne kadar sık kontrol edilmesi gerektiğini belirler. Zamanlanmış güncelleme planı ise belirlenen aralık geldiğinde hangi job'ın, hangi sırayla, hangi güvenlik kontrolleri ve hata politikalarıyla çalışacağını tanımlar.

Bütün XML tedarikçilerini aynı saatte çalıştırmak doğru mudur?

Teknik olarak mümkün olabilir ancak özellikle büyük feed'lerde CPU, ağ ve veri tabanı yükünü aynı anda artırabilir. Aynı sıklık korunurken görevler farklı dakikalara dağıtılabilir.

Önceki XML güncellemesi bitmeden yeni görev başlamalı mı?

Genellikle aynı veri üzerinde çalışan iki senkronizasyonun çakışması istenmez. Scheduler altyapıları bu amaçla overlap lock kullanabilir. Örneğin güncel Laravel scheduler withoutOverlapping mekanizması sunuyor.

XML güncellemesi hata verirse otomatik tekrar denenmeli mi?

Hata türüne bağlıdır. Geçici bağlantı problemi yeniden denenebilirken bozuk XML şeması veya yanlış mapping gibi kalıcı problemleri tekrar tekrar çalıştırmak çözüm olmayabilir. Retry edilebilir ve edilemez hatalar ayrılmalıdır.

Birden fazla sunucu varsa aynı XML görevi birkaç kez çalışabilir mi?

Scheduler her sunucuda ayrı çalışıyorsa bu risk olabilir. Kullanılan altyapıda merkezi kilit veya tek-sunucu execution mekanizması kurulmalıdır. Güncel Laravel scheduler bunun için onOneServer benzeri bir yöntem sunuyor.

ZAMANLANMIŞ XML GÜNCELLEME “CRON'A SAAT YAZMAK”TAN DAHA FAZLASIDIR

En basit sistem:

15 dakikada bir XML import çalıştır

diyebilir.

Daha kontrollü sistem ise:

zaman geldi

↓

önceki job bitmiş mi kontrol et

↓

tek sunucuda lock al

↓

doğru tedarikçi feed'ini indir

↓

snapshot oluştur

↓

feed sağlığını doğrula

↓

veriyi işle

↓

kritik kontrolleri uygula

↓

başarılı kayıtları güncelle

↓

satış kanallarını doğru sırada güncelle

↓

başarı/partial failure durumunu kaydet

↓

gerekiyorsa retry veya alarm oluştur

şeklinde çalışır.

Örneğin:

“XML saatte bir çalışıyor.”

tek başına operasyon bilgisi değildir.

Daha yararlı bilgi:

Supplier-A stok/fiyat sync'i saatte bir tetikleniyor; önceki çalışma bitmediyse başlamıyor; feed doğrulanmadan canlı veriye yazmıyor; başarısız olursa kontrollü retry yapıyor; başarı sonrası kanal gönderimini tetikliyor ve son başarılı çalışma zamanı kaydediliyor.

şeklindedir.

117'nin ana mesajı:

“Güncelleme sıklığını seçtikten sonra, o güncellemeyi güvenli ve izlenebilir bir görev zincirine dönüştürün.”