Sık Yapılan ABAP Hataları

Bu hafta bir projede bazı çıktı ve programları düzeltiyoruz. Bu düzeltmeler esnasında; çok önemli bazı noktaların atlandığını fark ettik. Başkalarına da faydası olabilir diye; gördüğümüz noktaları bütün ABAP’çılarla paylaşmak istedim.

SmartForm Algoritmaları

Öncelikle; baktığımız bazı örneklerde; form içerisinde ölçü birimi dönüşümü, dağıtım kanalına bağlı hesaplamalar gibi algoritmalar gördük. SmartForm içerisinde algoritma yazılması, formu tanımayan birinin sonradan düzeltme yapmasını çok zor hale getiriyor. Bunun yanı sıra; toplu çıktılarda performans problemine de yol açabilmektedir. Bu tarz algoritmaları SmartForm içinde değil, SmartForm’u çağıran program içerisinde yazmalıyız.

Formun tek görevi, algoritmaları ve hesaplamaları tamamlanmış değişkenleri alıp çıktıya yansıtmak olmalı. SmartForm içerisinde kod yazılabilen bölgeleri; tutar / miktarı metine çevirmek, ara toplam aldırmak, sayıyı yazıya çevirmek gibi ufak tefek işler haricinde kullanmayalım.

Hard Coded Miktar Dönüşümleri

Bir diğer nokta, miktar hesaplamalarıyla ilgili. Yine birçok noktada; değerleri Hard Coded bir şekilde 1000’e bölmek, 10’la çarpmak gibi yaklaşımlar gördük. Bu tarz işlemler; Sandbox içerisindeki belli örneklerin doğru çalışmasını sağlıyormuş gibi gözükse de; size verilen örnek haricinde başka ölçü birimleri içeren durumlarda büyük hatalara yol açıyor. Burada dikkat edilmesi gereken noktalar şunlar:

• Fiyat okurken, fiyat birimini de mutlaka dikkate alın. Mesela VBAP-NETPR’den çektiğiniz tutar, her zaman 1 birimin fiyatı değildir. VBAP-KPEIN ve VBAP-KMEIN bazındaki fiyattır. Elinizdeki örnekte VBAP-KPEIN = 1000 (KG) diye Hard Coded bir şekilde 1000’e bölme işlemi yaptığınızda, fiyat birimi 50 Koli olan bir örnek doğru çalışmamaktadır.
  
• KG -> TON, MM -> Metre gibi malzemeden bağımsız miktar dönüşümleri için UNIT_CONVERSION_SIMPLE fonksiyonunu kullanabilirsiniz.
  
• Belli bir malzeme için miktar dönüşümü yapıyorsanız, MD_CONVERT_MATERIAL_UNIT fonksiyonunu kullanabilirsiniz.
  

Hard Coded Değerler

Hard Coded demişken; program içerisinde satış organizasyonu, dağıtım kanalı gibi değerlerin Hard Coded gömüldüğünü de gördük. Bu işi genelde User Exit yazan modülcüler yapar; bize hiç yakışmıyor  Mesela size “20 dağıtım kanalında KG, 30 dağıtım kanalında ADT görmek istiyoruz” diye bir talep geldi diyelim. Kodu şöyle yazmak iyi bir fikir değildir:

if lv_vtweg eq ‘0020’.

lv_meins = ‘KG’.

Endif.

if lv_vtweg eq ‘0030’.

lv_meins = ‘ST’.

Endif.

Bunun yerine; şu yapıda bir Z’li tablo yaratın (adına ZVTWEG diyelim) ve bakım ekranını da üretin:

VTWEG	MEINS
0020	KG
0030	ST

Kodda yapmanız gereken şey ise şudur:

Select single meins into lv_meins from zvtweg where vtweg eq lv_vtweg.

Bu algoritma mantığının kullanılacağı her yerde (Hard Coded değerleri koymak yerine) bu tabloyu kullandığınızda; bu tabloda yapılacak her değişiklik bütün Z’li programlarınıza anında yansıyacaktır. Hard Coded yazmış olsanız, herhangi bir ek / değişiklik gerektiğinde bu mantığı uyguladığınız her yere ABAP müdahelesi yapmanız gerekirdi. Özellikle büyük projelerde çok fazla program / fonksiyon / method / vs olduğu için; bir süre sonra işler kontrolden çıkmaya başlıyor. Değere bağlı işleri tablo üzerinden yapmak, herşeyi daha basit ve merkezi bir hale getirir.

Aşağıya birkaç örnek tablo daha koyayım.

Belli depoları iç depo ve dış depo diye ayırmak istiyoruz diyelim; buna göre işlem yapacağız. Şöyle bir tablo işimizi görür:

LGORT	ZTYPE
1010	I – İç Depo
1020	I – İç Depo
1030	D – Dış Depo
1040	D – Dış Depo

Bir başka örnekte; parti numarasını nasıl belirleyeceğimiz konusunda bize malzeme türüne bağlı 3 farklı algoritma verdiler diyelim. Bu malzeme türlerini Hard Coded koymak yerine, malzeme türü bazında algoritmayı içeren bir Z’li tablo yapabiliriz; yeni malzeme türü eklemek veya bir malzeme türünün algoritmasını değiştirmek için ABAP müdahelesine gerek kalmaz:

MTART	ZALGORITMA
ROH	A – Malzemenin sonuna iki sıfır ekle
HALB	A – Malzemenin sonuna iki sıfır ekle
FERT	B – Üretim siparişinden al
ZFER	C – Satış siparişinden al

Birden fazla ABAP’çının çalıştığı projelerde; bir uyarlama tablosu açmadan önce bu tarz bir tabloyu açmış olabilecek ABAP’çılarla da konuşun. Aynı işi yapan iki farklı tablo olması yine programcılık mantığına aykırı olacaktır.

Unutmayın ki; sistemdeki başıboş Hard Coded değerler başıboş Repair’ler kadar tehlikeli olabilir.

İlk Kalemin Değerini Okumak

Birkaç yerde; satış belgesindeki ilk kalemin değerinin şuna benzer bir kodla alınmaya çalışıldığını gördük:

Select (…) from vbap where vbeln eq lv_Vbeln and posnr eq ‘000010’.

Bu kod, 10 numaralı kalemin silinmiş veya hiç açılmamış olduğu durumlarda çalışmayacaktır. Bunun yerine; şu yaklaşım daha doğru olacaktır:

Select single (…) from vbap where vbeln eq lv_vbeln.

Ölçü Birimi Metinleri

Bir başka noktada; şuna benzer bir koda rastladık:

if lv_vtweg eq ‘0020’.

lv_me = ‘PCS’.

else.

lv_me = ‘ADT’.

endif.

Ölçü birimini sisteme Login olunan dilde yazdırmak için write komutunu kullanabiliriz:

Write lv_meins to lv_me.

Bir başka dilde yazdırmak istiyorsak; SET COUNTRY komutunu da kullanabiliriz. Ama daha basit bir yöntem; doğrudan doğruya ölçü birimi metin tablosuna gidip dilediğimiz dildeki metni çekmek olabilir:

Select single mseh3 into lv_me

from t006a

where spras eq sy-langu

and msehi eq lv_meins.

Hard Coded Değer bölümünde anlattığım teknikle bu tekniği birleştirecek olursak; dağıtım kanalı bazlı bir tablo yaratmamız gerektiği sonucu ortaya çıkar (ZDIL diyelim):

VTWEG	SPRAS
0010	TR
0020	EN
0030	TR
0040	TR

Kodumuz ise şöyle olacaktır:

Select single mseg3 into lv_me

From t006a

Where spras eq ( select spras from ZDIL where vtweg eq lv_vtweg )

and meins eq lv_meins.

EXCEPTIONS Kullanımı

Bir fonksiyon veya Method çağırdığınızda; Exceptions bölümündeki hataları mutlaka yakalayın ve hatanın detayından kullanıcıyı haberdar edin. Önemli bir hata alındığında, program çalışmaya devam etmemelidir.

Advertisement