Apex Programlama Dili Nedir ve Bir CRM'i Neden Tek Platforma Bağlar?
Apex, yalnızca Salesforce sunucularında çalışan, Java'ya benzeyen, güçlü tipli ve nesne yönelimli bir programlama dilidir. Tek bir işi var: standart davranışın yetmediği yerde, veritabanının hemen yanında sunucu tarafı iş mantığı çalıştırmak.
Türkçe kaynaklarda Apex bir kariyer başlığı olarak anlatılır. Bu yazı başka bir soruya cevap veriyor: bir CRM'de kod yazma yeteneği tam olarak ne kazandırır, karşılığında ne bağlar, ve kod yazmadan nereye kadar gidilir.
Aşağıda Apex'in ne olduğu, ne zaman devreye girdiği, governor limitlerinin neden var olduğu, kodun neden taşınamadığı ve kod yazmadan hangi işlerin yapılabildiği anlatılıyor. Sonda Rapitek CRM'in bu konudaki açık sınırı var.
Yazıdaki Apex ve Salesforce bilgileri Ağustos 2026 itibarıyla, sağlayıcının kendi kamuya açık belgelerine dayanır.
Apex kodu, koştuğu platformun içinde kalır. Platform değiştiğinde satırlar taşınmaz; taşınan şey o satırların hangi iş kuralına hizmet ettiğinin tarifidir.
İçindekiler
Apex tam olarak nedir?
Apex bir uygulama dili değil, bir platform dilidir. Kodu kendi bilgisayarınızda yazarsınız ama kaynak kod, derlenmiş biçimiyle birlikte platformun kendi meta veri deposunda durur; sürüm yönetimi de dağıtım da o deponun kurallarına göre işler.
Dilin karakteri üç cümlede özetlenir. Sözdizimi Java'ya yakındır, bu yüzden Java bilen bir geliştirici kısa sürede okuyabilir. Güçlü tiplidir, yani tip hataları çalışma anında değil derleme anında yakalanır. Veritabanı sorgusu dilin içine gömülüdür: SOQL ile yazdığınız sorgu ayrı bir dize değil, derleyicinin denetlediği bir ifadedir.
Apex'i sıradan bir sunucu dilinden ayıran asıl şey, veriye olan mesafesidir. Kod, sorguladığı veritabanıyla aynı yerde koşar; ağ üzerinden konuşmaz. Bir sipariş kaydedilirken yüz satırlık bir hesaplamayı milisaniyeler içinde yapabilmesinin sebebi budur.
Bunun bedeli de aynı yerdedir. Aynı sunucuda çok sayıda başka müşterinin kodu koşuyor. Sizin kodunuzun onların performansını bozmaması gerekir. Governor limitleri tam olarak bu yüzden vardır.
Apex ne zaman devreye girer: tetikleyiciler, sınıflar ve toplu işler
Apex kodu kendiliğinden çalışmaz; bir olaya bağlanır. Pratikte dört giriş kapısı vardır.
Tetikleyiciler (trigger) bir kayıt eklenirken, güncellenirken veya silinirken çalışır. Kayıt veritabanına yazılmadan önce çalışan before tetikleyicisi alan değerlerini değiştirebilir; yazıldıktan sonra çalışan after tetikleyicisi ilgili başka kayıtları oluşturabilir. Bir nesnenin birden çok tetikleyicisi varsa çalışma sırası garanti edilmez; sıraya bağlı davranış yazan bir ekip için bu bir tasarım kısıtıdır.
Sınıflar (class) arayüzdeki bir düğmenin, bir ekranın ya da bir akışın çağırdığı iş mantığını taşır. Yeniden kullanılabilir olan kısım burada durur.
Asenkron işler uzun süren işlemler içindir: Batch Apex büyük kayıt kümelerini parçalara bölerek işler, Queueable sıraya alınmış tek bir işi çalıştırır, Scheduled Apex bir işi takvime bağlar.
Callout ise dış bir servise HTTP isteği atar. Tetikleyicinin içinden doğrudan çağrılamaz; asenkron bir bağlama taşınması gerekir.
Bir Apex tetikleyicisi hangi sırayla çalışır
-
1
Kayıt belleğe yüklenir
Gelen değerler kaydın mevcut hâliyle birleştirilir ve sistem doğrulamaları koşar. Bu aşamada henüz hiçbir özel kod çalışmamıştır. Aşağıdaki sıra, sağlayıcının Ağustos 2026'da kamuya açık belgelerinde tarif ettiği kaydetme düzenidir.
-
2
before tetikleyicileri çalışır
Kayıt henüz veritabanına yazılmadığı için alan değerleri burada doğrudan değiştirilir; ayrı bir güncelleme işlemi açmak gerekmez.
-
3
Doğrulama kuralları koşar
Zorunlu alanlar, alan biçimleri ve özel doğrulama kuralları denetlenir. Kural ihlali işlemi burada geri alır.
-
4
Kayıt veritabanına yazılır
Kayıt yazılır ama işlem henüz kalıcı değildir. Bu noktadan sonra kaydın kimliği artık bellidir.
-
5
after tetikleyicileri çalışır
Kaydın kimliğine ihtiyaç duyan işler burada yapılır: ilgili kayıt oluşturma, bağlı kayıt güncelleme, sayaç yazma.
-
6
İşlem kalıcı hâle gelir
Commit sonrası mantık — e-posta gönderimi ve asenkron işler — buradan sonra tetiklenir. Hata alırsa ana işlem geri alınmaz.
Governor limitleri: çok kiracılı mimarinin faturası
Governor limit, tek bir işlemde bir müşterinin harcayabileceği kaynak tavanıdır. Sınırı aşan kod hata verip durur; yavaşlamaz, kuyruğa girmez, uyarı vermez.
Sebebi mimaridir. Salesforce çok kiracılı bir platformdur: aynı uygulama sunucusu üzerinde çok sayıda müşterinin kodu koşar. Bir müşterinin döngü içinde sorgu açan kodu sınırsız çalışabilseydi, komşusunun sistemi yavaşlardı. Sınır bir ceza değil, paylaşım kuralıdır.
Pratik sonucu şudur: Apex'te doğru kod yazmak, tek tek kayıtlarla değil kayıt kümeleriyle düşünmek demektir. Döngünün içinde sorgu açan kod on kayıtla çalışır, iki yüz kayıtla sorgu tavanına çarpar. Apex eğitimlerinde dile değil bu tek alışkanlığa ayrılmış bölümler bulunmasının sebebi budur.
Apex'te çarpılan yürütme sınırları
| Sınır | Senkron işlem | Asenkron işlem |
|---|---|---|
| SOQL sorgusu | 100 | 200 |
| SOQL ile dönen kayıt | 50.000 | 50.000 |
| DML deyimi | 150 | 150 |
| Yığın belleği (heap) | 6 MB | 12 MB |
| CPU süresi | 10 saniye | 60 saniye |
Kod neden taşınmaz, veri neden taşınır?
Bir CRM'i değiştirdiğinizde iki ayrı şey taşınır: veri ve iş mantığı. Veri taşınabilir bir varlıktır; iş mantığı, yazıldığı platformun diline gömülmüştür.
Apex tarafında bu ayırım çok nettir. Tetikleyicileriniz, sınıflarınız ve toplu işleriniz başka bir sisteme kopyalanamaz — hedef sistemde onları çalıştıracak bir çalışma zamanı yoktur. Yeni platformda aynı davranış, o platformun kendi araçlarıyla yeniden kurulur.
Veri tarafında durum daha iyidir ve bunu ölçtük. Salesforce'un müşteri adayı dışa aktarım dosyasını Rapitek CRM'in içe aktarma sihirbazına verdiğimizde, 19 sütun başlığının 19'u doğru alanla eşleşti. Aynı testi HubSpot kişi dışa aktarımıyla yaptığımızda 17 başlığın 13'ü eşleşti ve ikisi yanlış alana bağlandı — yani eşleşme ekranda gözden geçirilmek zorunda.
Bu yüzden göç vaadi dürüst kurulmalı. Sıfır veri kaybı garantisi vermiyoruz; ürün verimiz tersini söylüyor. Erişebildiğimiz 8 kiracıda çalıştırılan 34 içe aktarma işinden 16'sı hatayla bitti. Doğru cümle şu: eşleştirmeyi ekranda siz onaylarsınız, karmaşık göçlerde aktarımı REST API üzerinden projeye özel yazarız.
Apex olmadan yapılan dört iş
Alan ve nesne eklemek
Rapitek CRM'de yeni bir alan ya da yeni bir nesne yönetim ekranından eklenir; derleme, test kapsamı ve dağıtım gerekmez. Ölçüldü: 19 kiracı kod yazmadan toplam 277 özel alan tanımlamış, bir kiracı 9 özel nesne eklemiş.
Otomasyon kurmak
Görsel iş akışı motoru kayıt oluşunca alan doldurma, görev açma, bildirim gönderme ve dış servise webhook atma adımlarını kod olmadan zincirler. Akışların koşum geçmişi tutulur.
Dışarıdan okuyup yazmak
REST API OAuth2 ile korunur; composite ucu tek istekte 25 alt-istek, toplu uç tek çağrıda 200 kayıt taşır. Nesne şemasını dışarıdan okumak için describe ucu vardır.
Arayüz dilini düzeltmek
Arayüzdeki metinlerin tamamı kiracının kendi veritabanında durur. Yanlış çevrilmiş bir dizgeyi yönetici ekrandan düzeltir; yeni sürüm beklemek gerekmez.
Peki Apex öğrenmeye değer mi?
Soru iki farklı kişiden geliyor ve iki farklı cevabı var.
Geliştiriciyseniz Apex hâlâ değerli bir beceridir. Salesforce kurulu bir taban taşıyor ve o tabanın bakımı kod bilen insan istiyor. Öğrenme yolu da açıktır: sağlayıcı bir geliştirici ortamı ve kendi eğitim platformunu sunuyor. Koşullarını burada yazmıyoruz — sağlayıcının kendi sayfasında duruyor ve değişebiliyor. Üretime kod almak içinse ayrı bir şart vardır: Salesforce, kendi belgelerine göre bir dağıtımın geçebilmesi için Apex kodunun en az yüzde 75'inin testlerle kapsanmasını zorunlu tutar.
Bir işletmeyseniz soru tersine döner. "Apex bilen birini bulmalı mıyım?" sorusu, aslında "CRM'imin çalışması bir geliştiriciye bağlı olsun mu?" sorusudur. Mekanizma şu: kodla çözülen bir ihtiyaç, karşılanmak için geliştirici zamanı bekler; geliştirici zamanı kıtsa ihtiyaç kuyruğa girer. Kod yazılamayan bir platformda ise bedel başka yerdedir: yapılandırmayla çözülemeyen ihtiyaç hiç karşılanmaz. Bunu kendi projelerimizde iki yönde de gördük.
İkisinin arasında dürüst bir orta yol var: yapılandırmayla çözülebilen işleri yapılandırmayla çözmek, gerçekten kod isteyen işleri de sistemin dışında, API'nin ucunda tutmak. O zaman kod sizin deponuzda kalır, platformun içinde değil.
Rapitek CRM'de bunun karşılığı ne?
Rapitek CRM'de özelleştirme üç yerden yapılır ve üçü de kod dağıtımı gerektirmez: ekrandan alan ve nesne ekleme, görsel iş akışı, ve dışarıdan REST API.
Dördüncü bir yol daha var. Rapitek CRM bir MCP paketi yayınlıyor; müşteri kendi yapay zekâ istemcisini CRM'e bağlayıp kayıt okutabiliyor ve yazdırabiliyor. Paket kurulum ekranından indiriliyor ve 18 araç taşıyor.
Entegrasyon tarafındaki somut kanıt şu: bir müşteri kurulumunda, bize ait olmayan üçüncü taraf bir ERP entegratörü bu API üzerinden kayıt okudu ve yazdı. Ölçüm tek bir kurulumdan geliyor ve tek kurulum olarak aktarılıyor — yaygın bir uygulama olduğunu söylemiyoruz.
Bizim sınırlarımız
Rapitek CRM'de Apex diye bir dil yok ve benzeri de yok. Sunucularımızda müşteri kodu çalıştırmıyoruz; müşterinin yazdığı kodun koşabileceği bir yüzey açmıyoruz. Bu bir yol haritası maddesi değil, mimari bir tercih. CRM verileriniz size ait ayrı bir veritabanında tutulur: ayrı tablo dosyaları, ayrı yedek ve ayrı dosya alanı. Bu ayırım uygulama ayarında değil veritabanı düzeyindedir; o veritabanının yanında keyfi kod çalıştırmak bu ayırımı zayıflatır.
Salesforce'tan kod göçü diye bir hizmetimiz yok. Tetikleyicileriniz, sınıflarınız ve toplu işleriniz otomatik dönüşmez; aynı davranış Rapitek CRM'in kendi araçlarıyla yeniden kurulur ve bu bir tasarım işidir, bir dönüştürücü işi değil.
Kutudan çıkan bir Salesforce modülümüz de yok. Göç, dışa aktarılan CSV dosyaları ve gerektiğinde REST API üzerinden projeye özel yazılan bir aktarımla yapılır. Sihirbazın ölçülen tavanı iki kalemde duruyor: bir dosya en fazla 25 MB, bir iş en fazla 100.000 satır. İki tavan da içe aktarma tarafında ölçüldü.
Belge imzalama ekranı üründe kurulu ama sahada ölçülmedi: ölçüm günü bakılan 8 kiracının 8'inde de 0 imza ve 0 imza talebi vardı. Sözleşme akışını buna göre planlayın.
Apex hakkında sık sorulan sorular
Apex sadece Salesforce'ta mı çalışır?
Governor limit nedir ve neden vardır?
Apex öğrenmek için lisans satın almam gerekir mi?
Rapitek CRM'de hazır bir Apex karşılığı var mı?
Salesforce'taki Apex özelleştirmelerimi taşıyabilir miyim?
Salesforce'tan Rapitek CRM'e geçiş ne kadar sürer?
Apex ile REST API arasındaki fark ne?
İlgili içerikler
- Salesforce nedir? — Apex'in üzerinde çalıştığı platformun kendisi.
- PaaS nedir? — Apex'i mümkün kılan hizmet modelinin tanımı.
- SaaS nedir? — CRM'lerin bugün satıldığı model.
- CRM tarihi — özelleştirmenin altmış yılda nasıl yer değiştirdiği.
- Entegrasyonlar — bugün çalışanlar ve talep üzerine kurduklarımız.
CRM'inizi kod yazmadan kendi sürecinize göre kurun
Rapitek CRM'i kuran ekip, Salesforce döneminde 200'den fazla kurumsal CRM projesi tamamladı. Ürün yeni, ekip değil: alanları, aşamaları ve raporları biz yapılandırıyoruz, verinizi biz aktarıyoruz, ekibinize Türkçe eğitimi biz veriyoruz.
Kod yazmadan nereye kadar gidilebileceğini keşif görüşmesinde kendi süreçlerinizle birlikte çıkarıyoruz; kapsam yazılı belirlenir.
Kerim Yıldırım
Kurucu, Rapitek CRM · Salesforce döneminde 200'den fazla kurumsal CRM projesi
Kaynaklar
Bu yazıdaki dış olgular şu birincil kaynaklara dayanıyor:
