|
<< Click pentru afișare cuprins >> Navigare:
SmartCash Everywhere REST Server > Studii De Caz > Model general de implementare a interfetei in aplicatia generatoare de clienti fidelizabili |
Recomandam urmatorul model de implementare a integrarii pe partea de utilizator aplicatie web:
1. In backend-ul aplicatiei terte ce va fi expus administratorilor aplicatiei, trebuie sa se implementeze o sectiune de setari specifica (sa spunem Integrare SmartCash RMS).
2. In aceasta sectiune utilizatorul final, fara interventia nimanui, pe baza detelor proprii de acces trebuie sa poata customiza setarile necesare accesarii serviciu REST specific propriului lant de magazine. In acest scop este necesara salvarea la nivelul aplicatiei externe a urmatoarelor informatii:
a. Adresa serviciului web propriu <SmartCash Everywhere REST Server>: este o adresa IP sau un nume de domeniu calificat (de exemplu: 5.67.124.6 sau everywhere.myshop.ro).
b. Portul de comunicatie <Port>: de exemplu 443 sau 80 sau 8080, etc. Pot exista si porturi nestandard HTTPS de exemplu, de aceea portul poate avea orice valoare.
c. Protocolul <Protocol>: Poate avea doar doua valori: HTTP sau HTTPS.
d. Numele de acces la serviciul SmartCash Everywhere setat la nivelul aplicatiilor SmartCash RMS <Nume Acces>: Username SmartCash RMS;
e. Parola de acces la serviciul SmartCash Everywhere <Parola Acces>: Parola utilizator SmartCash RMS;
f. Cod de aplicatie alocat aplicatiei terte in sistemul SmartCash RMS. Acest cod, de tip intreg, va fi utilizat la orice apel de metoda REST efectuata de catre o aplicatie terta si trebuie definit mai intai la nivelul aplicatiei SmartCash RMS. <ID Aplicatie>: de exemplu 101.
g. Codul de Furnizor de Fidelizare alocat cardurilor emise in aplicatia terta. Pentru acest cod in SmartCash RMS este folosita notiune de cod de Furnizor de Fidelizare. <ID Furnizor Fidelizare>: de exemplu 1255.
h. Codul programului de fidelizare SmartCash RMS la care clientii adaugati de aplicatia terta vor fi automat asociati. Are o valoare intreaga si poate sa lipseasca. Daca nu este furnizat la apelul metodei SaveCustomer, clientul nu va beneficia de nici o reducere sau alta forma de fidelizare, trebuind asociat de la nivelul centrale SmartCash RMS. <Cod Program Fidelizare SmartCash> : exemplu 36.
i. Codul categoriei implicite de clienti la care va fi alocat automat clientul la adaugare. Se stabileste in SmartCash si se salveaza in optiunile aplicatiei terte. Are o valoare intreaga. <Cod Categorie Clienti>: de exemplu 15.
4. In aceeasi interfata de setari, se vor implementa si doua butoane de test care trebuie sa apeleze metodele REST: GetApplicationVersion si WhoisServer. Ambele trebuie sa intoarca raspunsul serviciului REST in timp real intr-un mesaj simplu in vederea testarii functionarii acestuia, precum si pentru verificarea rapida a versiunii acestuia. Butoanele se pot numi: <Verificare Versiune Server REST> si eventual chiar <Whois Server>.
5. In aceeasi interfata de control specifica integrarii SmartCash RMS se vor introduce controale care sa defineasca modul de generare al codurilor de carduri emise de catre aplicatia terta pentru reteaua respectiva de magazine.
Recomandam in general utilizarea de coduri EAN13 deoarece ele se pot citi cu acelasi scaner cu care se si vinde in magazine. Pentru mai multa flexibilitate, se poate implementa de exemplu un selector pentru 3 tipuri de coduri: EAN8, EAN13 sau QRCode iar pentru EAN-uri sa se permita introducerea unui prefix care sa ajute la determinarea rapida a sursei de provenienta a codurilor la vizualizarea codului tiparit pe un card. Pornind de la aceste optiuni se pot genera consecutiv sau aleator coduri de card, singura constrangere fiind aceea ca ele sa fie unice in contextul aplicatiei terte pentru comerciantul respectiv. Daca se opteaza pentru generarea consecutiva poate fi furnizata o optiune suplimentara care sa contina numarul de la care sa se inceapa numerotarea consecutiva a cardurilor nou generate de aplicatia terta.
Sunt deci necesare urmatoarele controale: <Tip Cod Carduri> cu valorile EAN8, EAN13, QRCode, si <Prefix Coduri Card> de exemplu 55 si eventual <Start Numerotare Carduri> de exemplu 100. (pentru un card tip EAN13 un exemplu ar fi 5500000001007. De retinut obligativitatea aplicatiei terte ca in cazul codurilor EAN sa calculeze caracterul de control (al 13-lea sau al 8-lea) corespunzator codului de card generat. In acest caz codul trebuie transmis integral prin interfata pentru a pueta fi utilizt in magazine.
6. La fiecare solicitare de adaugare de nou client in aplicatia terta, specific lantului comercial interconectat prin interfata, platforma terta trebuie sa apeleze metoda REST SaveCustomer, furnizand campurile corespunzatoare din documentatie.
7. In caz de eroare la adaugare (de exemplu serviciul REST este down, sau s-a facut o eroare de generare si codul de card exista deja) eroarea se va salva intr-un sistem de logging si poate fi transmisa automat si pe o adresa de e-mail de administrare cont. In acest mod administratorul sistemului SmartCash RMS va fi instiintat si desi nu s-a putut adauga automat, va putea reconcilia problema in programul SmartCash RMS adaugand manual codul de client generat din aplicatia terta.
Observatie importanta!
Codul de card generat de catre aplicatia terta si transmis prin interfata este gestionat la nivelul sistemului SmartCash RMS exclusiv in contextul codului <ID Furnizor Fidelizare> alocat aplicatiei terte. Prin urmare este in intregime la latitudinea acesteia modul si formatul de cod generat pentru carduri. Singura conditie este ca el sa fie unic in sistemul tert.