T-Soft kullanan mağazalarda mobil uygulama projesi genelde iyi başlar. Veri REST uçlarından JSON olarak gelir, ürün listelemek ilk gün çalışır, ekranlar hızlı çıkar. Sorunlar ikinci haftada başlar: bir sabah uygulama tüm isteklerde yetkisiz yanıt döndürür, kimse ne değiştiğini bilmez. Sebep neredeyse her zaman aynıdır ve bu yazının merkezinde duruyor: token yönetimi.
Aşağıda T-Soft tarafının gerçek resmini anlatıyoruz: veri hangi katmandan okunur, jeton ömrü nasıl yönetilir, yanıtlar neden yalnızca HTTP koduna bakılarak yorumlanamaz, üyelik nasıl ortak kalır ve fiyatı hangi kalemler belirler. Teknoloji seçimi ve mağaza yayın süreci gibi ortak konular mobil uygulama yaptırma rehberinde duruyor.
T-Soft mobil uygulama veriyi nereden alır?
T-Soft, dışarıya REST uçları açan barındırılan bir altyapıdır. Panelde bir API erişimi tanımlandıktan sonra ürün, kategori, varyant, stok, fiyat, üye, sipariş ve kargo tarafındaki veriler bu uçlar üzerinden okunur ve yazılır. Yanıtlar JSON olduğu için mobil tarafta çözümleme maliyeti düşüktür; SOAP tabanlı altyapılara göre veri katmanı belirgin biçimde daha hafiftir.
Bu avantaj, yanlış bir sonuca götürmesin: uygulama bu uçlara doğrudan bağlanmamalı. Sebebi yalnızca performans değil güvenlik. API erişim bilgisi uygulama paketine konduğunda, o paket çözüldüğünde okunabilir hale gelir ve eline geçen kişi yalnızca uygulamayı değil panelinizi de sorgulayabilir. Bu bilgi kendi sunucunuzda kalmalı, uygulama kendi servis katmanınıza bağlanmalıdır.
Servis katmanının ikinci işi biçimlendirmedir. Panel uçları yönetim mantığına göre tasarlanmıştır; bir ürün kaydı, mobil ürün kartında hiç kullanılmayacak onlarca alan taşır. Ara katman bu veriyi ekranın ihtiyacına indirir, önbellekler ve mobil için hazır hale getirir. Uygulamanın hızlı hissettirmesinin sebebi budur: ekranlar zaten cihazda kuruludur, inen tek şey sadeleşmiş veridir.
Token yönetimi: T-Soft entegrasyonunun asıl zor kısmı
T-Soft tarafında istekler jeton ile yetkilendirilir. Jeton bir kez alınır, isteklerde taşınır ve süresi dolar. Kulağa basit geliyor; pratikte üç ayrı yerde hata üretiyor.
1. Jetonun süresi dolduğunda ne oluyor?
Süresi dolmuş bir jetonla yapılan istek yetkisiz yanıt döner. Kodunuz bu durumu ayrıca ele almıyorsa, hata mesajı kullanıcıya "bir şeyler ters gitti" olarak yansır ve uygulama kullanılamaz hale gelir. Doğru davranış, yetkisiz yanıtı yakalayıp jetonu tazelemek ve isteği bir kez daha denemektir. Bu yeniden deneme sınırlı olmalıdır; sonsuz döngüye giren yenileme mantığı, panel tarafında gereksiz yük ve kendi sunucunuzda kilitlenme üretir.
2. Eşzamanlı yenileme yarışı
Asıl sinsi sorun bu. Uygulamanız aynı anda beş istek gönderiyor ve beşi de süresi dolmuş jetonla yetkisiz yanıt alıyor. Her biri bağımsız olarak "jetonu yenileyeyim" diyorsa beş ayrı yenileme isteği gider. Sonuçta bir jeton geçerli olur, diğerleri geçersiz kalır ve uygulama rastgele isteklerde hata vermeye başlar. Teşhisi zor, çünkü hata tekrarlanabilir değildir.
Çözüm, jetonu tek bir yerden yöneten bir bileşen kurmaktır. Yenileme gerektiğinde ilk istek kilidi alır, jetonu tazeler, diğerleri sonucu bekler. Buna ek olarak jetonu son ana bırakmayıp süresi dolmadan önce yenilemek, kullanıcıya hiç yansımayan bir akış sağlar.
3. Jeton nerede saklanıyor?
Jeton uygulamanın belleğinde tutuluyorsa her açılışta yeniden alınır ve gereksiz istek üretilir. Cihazda saklanıyorsa ve şifresiz duruyorsa güvenlik sorunu olur. Doğru yer, kendi sunucunuzdaki servis katmanıdır: jeton orada tutulur, uygulama panelin jetonunu hiç görmez, yalnızca kendi oturum bilgisini taşır. Bu ayrım sayesinde uygulamayı güncellemeden erişim bilgisini değiştirebilirsiniz.
Yanıtı yalnızca HTTP koduna bakarak yorumlamayın
REST uçlarıyla çalışırken sık yapılan bir varsayım, isteğin başarılı sayılması için HTTP durum kodunun yeterli olduğudur. Uygulamada bu her zaman geçerli olmuyor: bazı işlemler başarılı bir durum koduyla dönerken yanıt gövdesinde işlemin gerçekleşmediğini ve sebebini bildirir. Sipariş oluşturma, stok düşme ve üye kaydı gibi işlemlerde bu ayrımı atlamak, uygulamada "siparişiniz alındı" yazan ama panelde karşılığı olmayan durumlara yol açar.
Kural olarak: yazma işlemlerinde yanıt gövdesindeki sonuç bilgisi kontrol edilmeli, hata mesajı günlüğe yazılmalı ve kullanıcıya gösterilecek metin bu mesajdan türetilmemelidir. Panel kaynaklı hata metinleri son kullanıcı için yazılmamıştır; kullanıcıya anlaşılır bir mesaj gösterip ayrıntıyı kayıt altına almak doğru yaklaşımdır.
T-Soft uygulama entegrasyonu: hangi iş nerede duruyor?
| İş | Nerede yapılır | Neden |
|---|---|---|
| API erişim bilgisi ve jeton | Kendi sunucunuzdaki servis katmanı | Uygulama paketine konan her bilgi okunabilir |
| Katalog, kategori, arama | Servis katmanındaki önbellek | Ekranların beklemesiz açılması ve panel yükünün azalması |
| Stok ve fiyat doğrulaması | Sipariş anında panelden | Yoğun günlerde tükenmiş ürünün satılmaması |
| Üyelik, adres, sipariş geçmişi | T-Soft üye kaydı | Müşteri verisinin tekil kalması |
| Sipariş oluşturma ve ödeme | Panel tarafı | Taksit, kargo ve kupon kurallarının tek kaynakta kalması |
| Müşteri grubu ve özel fiyat | Panelden okunur | Bayi fiyatlarının uygulamada kopyalanmaması |
| Arayüz, gezinme, bildirim | Uygulama | Mobil davranışa göre ayrı kurgulanır |
Tablodaki sınır tek cümleyle şu: veri ve iş kuralları panelde, deneyim uygulamada. Bu sınır korunduğunda panelde bir kampanya tanımladığınızda uygulamada hiçbir şey yapmanız gerekmez; bozulduğunda ise her panel değişikliğinin uygulamaya elle taşınması gerekir.
Üyelik ve sipariş: iki ayrı sistem oluşmaz
T-Soft'ta üye kaydı panelin kendi kaydıdır. Uygulama bu kaydın üzerine oturum açtığında müşteri sitede ve uygulamada aynı kişidir. Bunun somut karşılıkları: kayıtlı adresler iki kanalda ortaktır, sipariş geçmişi tek listedir, müşteri grubu ve varsa özel fiyatlandırma uygulamada da geçerlidir, pazarlama izinleri tek yerden yönetilir.
Bayi satışı yapan mağazalarda bu maddenin ağırlığı daha da artıyor. Grup bazlı fiyat kuralları panelde tanımlıysa ve uygulama kendi fiyat listesini tutuyorsa, ilk fiyat güncellemesinde bayi yanlış fiyat görür. Bu tür bir hatanın maliyeti perakendedekinden yüksektir çünkü karşı taraf da ticari bir işletmedir.
Sipariş tarafında da akış bölünmez: uygulamadan verilen sipariş panele düşer, aynı numaralandırmayı alır, aynı kargo ve fatura sürecinden geçer. Kanal ayrımını raporlamada görmek isterseniz siparişe etiket eklenir; operasyon ikiye ayrılmaz.
T-Soft mağaza uygulaması: ekran kurgusu neye göre değişir?
Bir T-Soft mağaza uygulaması, panelin veri modelini olduğu gibi ekrana dökmez. Yeniden düşünülmesi gereken başlıklar:
- Kategori yerine arama. Panelde kategori ağacı yönetim kolaylığı için derinleşir; mobilde her seviye ek dokunuş demektir. Uygulamada gezinmeyi sığ tutup aramayı ana yol yapmak gerekir. Katalog genişse aramanın yazım hatasını tolere etmesi ve eş anlamlıları bilmesi, anlam tabanlı arama ile mümkün olur.
- Varyant seçimi. Renk görsel olarak, beden büyük dokunma hedefleriyle sunulmalı; stokta olmayan kombinasyonlar seçilemez şekilde işaretlenmelidir.
- Hızlı yeniden sipariş. Tekrar eden alım yapan müşteri kitleniz varsa, geçmiş siparişi tek dokunuşla sepete alma ekranı uygulamanın en çok kullanılan yeri olur.
- Sipariş ve kargo takibi. Uygulamayı açma sebeplerinin başında gelir; alt sekmelerden birinde durmalıdır. Kargo bilgisini ayrıca kargo bildirimi gibi kanallarla desteklemek, uygulamayı indirmeyen müşteriyi de kapsar.
- Bağlantı kopunca ne olacağı. Zayıf bağlantıda son görülen listelerin gösterilmesi ve sepetin korunması, mobilde en çok fark edilen ayrıntılardan biridir.
T-Soft mobil uygulama yaptırmak: hazırlık listesi
T-Soft mobil uygulama yaptırmak isteyen mağazalarda görüşmeye şu başlıklar hazır gelirse proje hızlı ilerliyor:
- API erişiminin tanımlı olması. Yetkilerin hangi kapsamda verileceği ilk konuşulacak konudur.
- Ürün ve varyant kodlarının tekilliği. Aynı kodun iki üründe kullanılması, sipariş ve stok tarafında teşhisi zor hatalar üretir.
- Müşteri grubu yapısının netliği. Kaç grup var, hangi fiyat kuralı hangi gruba bağlı; bu tablo uygulamanın fiyat gösterim mantığını belirler.
- Kargo ve ödeme seçeneklerinin listesi. Uygulamada hangi seçeneklerin görüneceği kapsam görüşmesinde yazılır.
- Görsel varlıklar. Ürün görsellerinin çözünürlüğü ve varyantlara bağlılığı, uygulamanın görünen kalitesini doğrudan belirler.
Mağazanız başka bir altyapıdan T-Soft'a yeni taşındıysa uygulama projesini hemen başlatmak yerine katalog tarafının oturmasını beklemek daha verimli olur; taşıma sonrası veri düzeni konusunu mağaza taşıma ve veri aktarımı yazısında ele aldık.
T-Soft mobil uygulama fiyatları hangi kalemlerden oluşuyor?
| Kalem | Bütçeye etkisi | Açıklama |
|---|---|---|
| Servis katmanı ve senkron | Taban | Jeton yönetimi, önbellek ve artımlı senkron kurulumu |
| Arayüz tasarımı | Orta | Şablon uyarlama ile markaya özel ekran kurgusu arasında ciddi fark var |
| Bayi / grup fiyatlandırma | Orta | Oturuma göre fiyat, toplu sepet ve yeniden sipariş ekranları |
| Çoklu dil ve para birimi | Orta | İçerik yönetimi ve biçimlendirme kuralları eklenir |
| Segmentli bildirim | Orta | Davranışa göre gönderim, toplu duyurudan farklı bir kurgudur |
| Üçüncü taraf sistemler | Değişken | Sadakat, canlı destek, analitik araçları ayrı entegrasyon kalemidir |
| Bakım | Süreklilik | İşletim sistemi ve mağaza politikası değişiklikleri düzenli iş üretir |
Teklifleri karşılaştırırken tek soru çoğu şeyi ayırıyor: uygulama üye ve sipariş verisini nerede tutuyor? Kendi tarafında kopya tutan çözümlerin ilerleyen aylardaki maliyetini e-ticaret mobil uygulaması yazısında ayrıntılandırdık.
T-Soft'a bağlı uygulama mı, sıfırdan isteğe özel uygulama mı?
Bu yazının konusu birinci iş kolumuz: mevcut T-Soft mağazanızın üzerine kurulan, panelle ortak çalışan uygulama. Burada panel iş kurallarının sahibidir; uygulama, servis katmanı üzerinden aynı veriyi mobil deneyime çevirir ve ikinci bir yönetim ekranı ortaya çıkmaz.
İkinci iş kolumuz, panelin veri modeline sığmayan işler. Depo ve sayım uygulamaları, saha satış ekipleri için sipariş toplama araçları, servis ve bakım takibi, cihazla konuşan uygulamalar bu tarafa girer. Burada uygulamanın kendi sunucusu ve veri modeli sıfırdan yazılır; T-Soft varsa yalnızca bir veri kaynağı olur. İki kolun kapsamı ve süreç farkları mobil uygulama hizmet sayfamızda yazılı.
Sık karşılaşılan sorunlar
| Belirti | Gerçek sebep | Ne yapmalı |
|---|---|---|
| Uygulama bir anda tüm isteklerde yetkisiz dönüyor | Jeton süresi dolmuş, yenileme akışı yok | Yetkisiz yanıtta jetonu tazeleyip isteği bir kez yeniden deneyin |
| Hatalar rastgele geliyor, tekrar edilemiyor | Eşzamanlı istekler ayrı ayrı jeton yeniliyor | Yenilemeyi tek bileşene ve kilide bağlayın |
| Uygulamada sipariş oluştu görünüyor, panelde yok | Yanıt gövdesindeki başarı bilgisi kontrol edilmemiş | Yazma işlemlerinde gövdeyi doğrulayın |
| Bayi yanlış fiyat görüyor | Fiyat listesi uygulama tarafında kopyalanmış | Fiyatı oturuma göre panelden okuyun |
| Listeler yavaş açılıyor | Her ekran doğrudan panele gidiyor | Servis katmanında önbellek kurun |
| Tükenen ürün satılıyor | Stok yalnızca önbellekten okunuyor | Sipariş anında kaynaktan doğrulayın |
| Kullanıcıya anlamsız hata metinleri görünüyor | Panel hata mesajları doğrudan ekrana basılıyor | Ayrıntıyı günlüğe yazın, kullanıcıya sade mesaj gösterin |
Özet
T-Soft tarafında mobil uygulama, veri katmanı açısından rahat bir altyapı üzerinde çalışır: JSON yanıtlar, tanıdık REST kalıpları, mobil için düşük çözümleme maliyeti. Projeyi zorlaştıran şey bu kolaylığın verdiği güvenle jeton yönetimini hafife almak. Jetonu tek merkezden yöneten, süresi dolmadan yenileyen ve erişim bilgisini uygulamanın dışında tutan bir servis katmanı kurulduğunda geriye kalan iş, iyi bir arayüz ve dürüst bir kapsamdır. Üye kaydı panelde tekil kalır, sipariş tek akışta ilerler, fiyat kuralları tek yerde tanımlanır. Uygulamanın en değerli kanalı olan bildirimi kurgularken push bildirim yazısındaki izin zamanlamasına ve frekans dengesine bakmakta fayda var. Kapsam konuşmak isterseniz destek@stools.digital adresinden ya da 0547 007 54 24 numarasından ulaşabilirsiniz.