Aynı ihtiyaç, iki farklı çözüm

Bir önceki yazıda MESSAGE komutunun kullanıcıyla nasıl senkron bir şekilde etkileştiğini (kullanıcının önündeki ekranda bir pencere açıp cevap beklediğini) anlatmıştım. Ama bazı bildirimlerin kullanıcının o an ekranda olup olmamasıyla ilgisi yoktur — "siparişiniz onaylandı" gibi bir bildirimi, kullanıcı sistemde aktif değilken de göndermek isteyebilirsiniz. İşte tam bu noktada PUSHNOTIFICATION devreye giriyor; MESSAGE'dan farklı olarak senkron değildir ve bir pencere açıp cevap beklemez.

Neden ayrı bir komut var

MESSAGE, bir dialog'un aktif olduğu, kullanıcının o anda o ekranla etkileşimde olduğu senkron bir akış varsayar. PUSHNOTIFICATION ise arka planda, kullanıcının o anki ekranından bağımsız olarak bir bildirim göndermek için tasarlanmış — mobil push bildirimlerine ya da web tarayıcı bildirimlerine benzer bir model. Belgelere göre bu özellik "24.12.26-01" build'inden itibaren destekleniyor — yani eski bir CANIAS ortamında bu komutu ararsanız bulamayabilirsiniz, önce build numarasını kontrol edin.

Temel kullanım mantığı

/* Bir sipariş onaylandığında ilgili kullanıcıya arka planda bildirim gönderir. */
PARAMETERS:
    STRING KULLANICIADI,
    STRING SIPARISNO;

LOCAL:
    STRING BASLIK;
    STRING METIN;

BASLIK = 'Sipariş Onaylandı';
METIN  = SIPARISNO + ' numaralı siparişiniz onaylandı.';

PUSHNOTIFICATION KULLANICIADI BASLIK METIN;

(Gerçek parametre listesi ve seçenekler build'e göre değişebilir; kullanmadan önce ortamınızdaki PUSHNOTIFICATION komutunun tam imzasını DEVT01/IDE içi yardım üzerinden doğrulamanızı öneririm — burada asıl önemli olan komutun senkron olmayan doğasını kavramak.)

MESSAGE ile PUSHNOTIFICATION arasındaki fark, tablo halinde

MESSAGE PUSHNOTIFICATION
Etkileşim Senkron, cevap bekler Asenkron, cevap beklemez
Hedef Aktif oturumdaki kullanıcı Belirtilen kullanıcı (aktif olmasa da)
Kullanım amacı Onay almak, bilgilendirmek, hata göstermek Arka plan bildirimi göndermek
Batch modda davranış Otomatik cevaplanır (IASBATCHERR'a düşer) Değişmez, normal şekilde gönderilir

Diğer uyarı seçenekleri: ATTENTION ve ALERT

Belgeler, MESSAGE ve PUSHNOTIFICATION dışında farklı arayüzlere sahip ATTENTION ve ALERT komutlarından da bahsediyor. Bunlar, MESSAGE'ın standart pencere modelinden farklı, daha hafif ya da farklı görsel biçimde uyarı göstermek için kullanılabiliyor. Belirli bir ekranda hangi komutun uygun olduğuna karar verirken, kullanıcı deneyimi açısından "bu bilgi kullanıcının işini durdurmasını mı gerektiriyor (MESSAGE), yoksa arka planda bilgilendirme mi yeterli (PUSHNOTIFICATION/ALERT)" sorusunu sormak iyi bir başlangıç noktası.

Sık yapılan hatalar

  • Eski bir build'de PUSHNOTIFICATION aramak — belirtilen build'den (24.12.26-01) öncesindeki ortamlarda bu komut bulunmaz; "komut tanınmıyor" hatası aldığınızda önce application server'ın build numarasını kontrol edin.
  • Kritik bir onay akışını PUSHNOTIFICATION ile kurmaya çalışmak — bu komut cevap beklemediği için, "kullanıcı onaylamadan işlem devam etmesin" gibi bir akış için uygun değildir; böyle bir ihtiyaç için MESSAGE ... TYPE CONFIRMATION doğru araçtır.
  • Kullanıcı aktif olmadığında bildirimin "kaybolacağını" varsaymak — asıl fark tam olarak bunun tersi: PUSHNOTIFICATION'ın var olma sebebi kullanıcı aktif olmasa bile bildirimi ulaştırabilmek; bu davranışı test ederken kullanıcıyı sistemden çıkışta test etmeyi unutmayın, aksi halde iki komut arasındaki asıl farkı hiç gözlemlemezsiniz.

Sıradaki adım

Sıradaki yazıda dialog yaşam döngüsüne (BEFORE, AFTER, ONSHOW olayları) dönüp, bu bildirim ve mesaj çağrılarının genelde hangi olayda tetiklenmesi gerektiğine değineceğim.