Özelleştirme Tuzağı Oluşturmadan SAP ME Genel API'lerini Kullanma

Açılış perspektifi

SAP ME etrafında özel geliştirmeler sıklıkla gereklidir. Asıl soru, platformun genişletilip genişletilmeyeceği değil, gelecekteki desteği gereksiz yere zorlaştırmadan bunun nasıl yapılacağıdır. Genel API stratejisinin önemli olduğu yer burasıdır. Ekiplere, davranışlara anlık kısayollardan daha temiz bir şekilde erişmek ve bunları genişletmek için desteklenen bir yol sağlar.

Referansın açıkça ortaya koyduğu şey

Kitapta genel API web hizmetleri, Java API'leri, Javadoc erişimi ve SAP MII veya harici tüketiciler aracılığıyla yürütme anlatılmaktadır. Bu değerlidir çünkü geliştirmeyi kontrolsüz özelleştirmeden ziyade disiplinli bir mühendislik faaliyeti olarak çerçeveler. Başka bir deyişle SAP ME genişleme bekliyor. Sadece anlaşılan arayüzler aracılığıyla gerçekleşmesini bekliyor.

Gerçek risk kodlama değil, sahipliktir

Bir ekibin teknik olarak bir geliştirme oluşturup oluşturamayacağı konusunda nadiren endişelenirim. Bir yıl sonra takımın bunu destekleyip destekleyemeyeceği konusunda endişeleniyorum. Yetersiz şekilde belgelenen hizmet çağrıları, belirsiz istisna yönetimi ve katmanlara dağılmış iş mantığı, uzun vadeli kırılganlık yaratır. Özel bir şey oluşturmadan önce kullanım senaryosunu, sahibini, beklenen yaşam döngüsünü ve geri alma planını tanımlayın.

Pratik bir uzatma kural kitabı

İş ihtiyacının açık olduğu ve standart ürünün bunu net bir şekilde ifade etmediği durumlarda genel API'leri kullanın. Özel davranışı dar tutun. Belge girişleri, çıktıları, bağımlılıkları ve arıza yönetimi. MII işlemlerini, web hizmetlerini ve SDK mantığını gizli bağımlılıklardan oluşan bir labirente dönüştürmekten kaçının. Özelleştirmenin amacı, teknik zeka değil, sürdürülebilirlik ile iş uyumu olmalıdır.

Hızlı paket servisi

• Desteklenen API'leri gelişigüzel değil bilinçli olarak kullanın.
• Gerçek kişiselleştirme riski uzun vadeli desteklenebilirliktir.
• Her uzantıyı daha sonra başkası sahip olacakmış gibi belgeleyin.