SAP Mobile Development Kit este o platformă de dezvoltare de aplicații web și mobile, event driven, bazată pe metadata. Odată dezvoltată, aplicația poate fi lansată în SAP Mobile Services și transformată în cod nativ pentru IOS sau Android. Nu este prima incursiune SAP în lumea mobile. Cu ani în urmă, aplicațiile mobile SAP puteau fi scrise direct în Fiori UI5 și rulate în SAP Fiori Client for mobile. Această tehnologie este acum înlocuită de SAP Mobile Services.
În toamna anului 2023 am participat, alături de alți colegi din Nagarro, la un curs intensiv de SAP Mobile Services la sediul SAP din Walldorf, unde au fost prezente și alte companii de profil. Evenimentul presupunea o prezentare generală a frameworkului urmată de o parte practică, și anume, dezvoltarea unei aplicații. Cu așteptări mari și avantajul unui backend deja construit în SAP CAPm, am considerat că putem fi printre favoriții acestui eveniment. Faptul că din trei developeri doar unul era specializat pe frontend nu ne-a îngrijorat, dimpotrivă, acest ușor dezavantaj doar aducea caracter echipei și făcea concursul mai interesant.
Atât de siguri eram de reușită încât ne-am gândit că o singură aplicație într-un framework străin, scrisă în două zile este un task mult prea ușor. Așa că am decis să facem două aplicații. Sigur, asta va egala terenul și le va da celorlalte echipe o șansă să ne ajungă din urmă.
SAP Mobile Services suportă aplicații native SDK în Swift/Java/Kotlin, dar și hibride cu MDK în Javascript. Ca urmare, ne-am propus să scriem aplicația atât în Mobile Development Kit cu Javascript, cât și în Software Development Kit și SWIFT pentru IOS în XCODE, să ne formăm o idee mai bună despre Mobile Services.
Era doar un mic impediment că nimeni nu avea experiență în IOS development. Aveam, totuși, două zile să învățăm Swift, SDK și MDK.
Fig. 1: Arhitectura SAP Mobile Services - sursă imagine
După multe ore de încercări, am constatat că am subestimat poate dificultatea taskului din fața noastră. Backendul încă nu era conectat la frontend din cauza unor probleme de acces, SDK-ul în SWIFT nu se scria așa de ușor și know-how-ul nostru de UI5, iterația precedentă de tehnologie UI SAP, nu ne era prea de folos aici. Sunt elemente comune cu Fiori UI5, dar experiența de dezvoltare pare una nouă, nerespectând tradiționala arhitectură Model-View-Controller din Fiori. Artefacte din MDK pot fi considerate modele, views sau controlere, dar interacțiunea dintre ele nu este un pattern MVC classic.
Totuși, făceam mici progrese la aplicația scrisă în MDK/Javascript, acum cu un JSON temporar pe post de backend. Nu e mult, dar este muncă cinstită.
În total, în două zile am reușit să facem o aplicație de tip master-detail cu niște ODATA function calls la backendul mult prea complicat pentru nevoile noastre. Dar, am observat că toate echipele întâmpinau dificultăți. Nouă ne-au dat de cap anumite probleme tehnice și de infrastructură. Totuși, eram siguri de capabilitățile noastre și am decis să folosim MDK pentru următorul Proof of Concept.
Acest prototip urma să ajute în Warehouse Managementul unei companii producatoare de sticlă și ceramică care avea deja o implementare ERP în SAP Business Technology Platform.
Fig. 2: Arhitectura SAP MDK - sursă imagine
La prima vedere SAP Mobile Development Kit părea simplu. Se integrează în landscape-ul SAP Business Technology Platform cu care aveam deja tangențe. Developmentul se face într-un VSCode în cloud care pare doar să aibă alt nume, Bussines Application Studio. Git este integrat, la fel și CloudFoundry.
Paginile pot fi create atât prin drag-and-drop, cât și JSON metadata. Controalele UI au multe funcționalități deja built-in: citire barcode, sortare, binding cu datamodel, eventuri etc.
Multe elemente din Fiori par să fie optimizate pentru fast-development în MDK printr-un concept numit Actions. Aceste acțiuni pot fi orice de la calluri spre backend, navigație în și spre alte aplicații, barcode scanere, popups, închidere de pagini etc. Restul de development se face cu celelalt concept important din MDK: Reguli. Regulile sunt fișiere de javascript care pot fi atașate la evenimente din controale UI, pot chema acțiuni sau alte reguli, pot genera pagini cu JSON metadata, pot fi folosite în data formatting etc.
Fig. 3: Action creation wizard
Mai jos avem un exemplu de regulă de navigație spre o pagină, bazat pe un răspuns din backend.
In evenimentul de onClick atașam NavigationFromRule.js unde, în funcție de rezultatul unei acțiuni ODATA către endpoint-ul CAPm, afisăm o pagină. În caz de eroare deschidem un ToastMessage cu un text localizat sau eroarea de la endpoint.
Toate acțiunile au fost create înainte cu ActionWizard.
/**
* rule for navigation to a page based on odata call
* results
* @param {IClientAPI} clientAPI
*/
export default function NavigationfromRule(clientAPI) {
//call a CAPm o data backend function
return clientAPI.executeAction(
'/ProjectName/Actions/odata/MyOdatacall.action')
.then(function (results) {
//do something based on odata results
// ...
//call a navigation action to a prebuilt page
return clientAPI.executeAction(
'/ProjectName/Actions/navigation/'+
'NextPageNavigatio.action');
})
.catch(function (err) {
//error handling with localized message based on
//logon language
let oError = clientAPI.localizeText("ServerError')
//predefined in i18n model
let pageproxy = clientAPI.getPageProxy();
pageproxy.setActionBinding({
"message": oError
//or just err object from server
});
return clientAPI.executeAction(
'/ProjectName/Actions/Messages/'+
'ToastActionWithToast.action');
});
}După cum se observă mecanismul de traducere de resurse este același ca în UI5, bazat pe modelul I18n, incredibil de ușor în a crea o aplicație cross-language.
În ciuda dificultăților inițiale cu backendul, observăm că MDK se integrează perfect cu CAP atât prin acțiuni, cât și direct binding în proprietățile controalelor UI.
Deployment-ul e mult mai ușor ca în SAP Fiori. Un simplu click face ca în sub 1 minut aplicația să apară în Mobile SCVS app de pe propriul telefon. Acest app container se gasește în appstore-ul ios sau android. Sigur, pentru a avea o aplicație independentă am avea nevoie de un .ipk, .apk sau .aab. SAP oferă și acest serviciu prin Mobile Cloud Build Service integrat în Mobile Services Cockpit din BTP.
Recunosc că la început era o plăcere să dezvoltăm aplicația în SAP MDK, cel puțin așa părea la nivelul de Proof of Concept. Pe măsură ce aplicația creștea în complexitate unele din avantaje se transformau ușor în dezavantaje.
Controalele UI oferite nu păreau sa acopere toate nevoile de dezvoltare și crearea de noi controale era mult mai laborioasă ca în React sau chiar FioriUI5. Custom controls în UI5 se scriau practic singure, dar aici din scurta interacțiune cu un custom map control am realizat că am nevoie de multă rabdare și puțin nativescript, un limbaj care rulează direct pe device-ul nativ, cu access la controale și api-uri din device.
Routingul din MDK face structura aplicației mai greu de înțeles la o prima vedere, decât vechiul mecanismul din UI5 format din rute și target-uri în manifest.json. Acest lucru se simte pe masură ce aplicația crește.
Nici FioriUI5 nu era prima mea alegere ca UIFramework, dar folosindu-l nu am simțit că lupt cu framework-ul în rezolvarea unui task. Cel puțin așa am simțit încercând să customizez un control UI existent, sau să inserez reguli de formatare în binding.
Ocazional Bussines Application Studio raportează erori inexistente care dispar după o minimă investigație, doar ca în 5 minute ExplorerPanel-ul să fie roșu din nou, fără sa afecteze buildul. După câteva zile de erori false am ajuns să nu mai dau importanță Problems Panel-ului care strigă 'Lup', până inevitabil fac o eroare de sintaxă.
Dar pe departe cel mai puțin plăcut lucru este randarea inconsistentă de controale UI între IOS și Android.
Fig 4. Mobile Cloud Build.
Dar poate suntem prea duri cu MDK, multe din problemele de mai sus se pot rezolva pe măsură ce învățăm să îl folosim. Cu siguranță, la următorul proiect vom avea o experiența mai bună știind tot ce știm acum.
Celelalte probleme sunt sigur că vor fi rezolvate de echipa de dezvoltare din SAP, care este mai mult decât amabilă în a răspunde la emailuri, chiar și acelor developeri care poate nu citesc integral documentația. Pentru cei care doresc sa afle mai multe despre MDK, periodic în https://community.sap.com/ apare un articol cu titlul What's new in Mobile development kit.