DCL (angl. Data Control Language) je namenjen zagotavljanju varnosti na podatkovni bazi. Z ukazom »GRANT« se dodeljujejo pravice uporabnikom oziroma dostopi do posameznih objektov. Z ukazom »REVOKE« se le - te pravice odvzemajo. Tako določenim uporabnikom se lahko dodelijo pravice do vpogleda podatkov v tabelah, nekaterim lahko tudi spremembo oziroma vpis podatkov, ali pa celo spremembo objektov. TCL (angl. Transaction Control Language) je namenjen upravljanju s transakcijami na bazi. Z ukazom »COMMIT«
potrdimo spremembe, ki si jih prej na bazi naredil z DML ukazi, ali pa jih razveljaviš z ukazom
»ROLLBACK« [vir: lastni].
19
4 Proces uvajanja nove aplikacije
V tej razdelku si bomo podrobneje ogledali celoten postopek od oddane zahteve za nov produktu, pa do zadnje točke, ki je uporaba produkcijo. Opisan pa je tudi postopek načrtovanja aplikacije, razvoj ter test aplikacije, in postopek prenosa aplikacije na produkcijo.
4.1 Poslovni proces
4.1.1 Zahteva za razvoj aplikacije
Razvoj novega izdelka se vedno začne z idejo. V našem primeru se je pojavila ideja o razvoju nove aplikacije s katero bi izboljšali trenuten način dela zaradi prihranka na času zaposlenih, posledično tudi denarju in pa zadovoljstvu strank oziroma uporabnikov. Vsaka zahteva za nov produkt potrebuje tudi poslovni načrt. V poslovnem načrtu je potrebno predvideti strošek razvoja ter vzdrževanja novega produkta, ter prihranek z uvedbo tega produkta. V kolikor je strošek višji od dolgoročnega prihranka razvoj produkta namreč ni smiseln. Predvideti je potrebno tudi časovni plan izvedbe projekta, ter morebitna tveganja pri razvoju produkta.
V kolikor poslovni načrt potrdi smotrnost razvoja produkta je potrebno napisati zahtevo za razvoj produkta z vsemi potrebnimi specifikacijami. Delovanje produkta mora biti napisano natančno in jasno z vsemi podrobnostmi. Brez teh podatkov razvijalec težko načrtuje razvoj aplikacije, v primeru napačne interpretacije zahteve pa lahko pride tudi do napačnega delovanja aplikacije oziroma v neskladju z pričakovanji. Na podlagi zahtev se na koncu izvajajo tudi testi produkta.
4.1.2 Načrtovanje aplikacije
Pred pričetkom programiranja je potrebno pripraviti tudi načrt izvedbe produkta. Ta načrt tudi napišemo v dokument s tehnično specifikacijo. Ker bo zaradi načina delovanja naš novi produkt del že v obstoječega sistema CRM je zelo pomembno kako bomo te nove funkcionalnost umestili v obstoječ sistem. Podatke o stranki mora v naši aplikaciji namreč odpreti avtomatsko, torej moramo te podatke pridobiti iz sistema CRM. V sistem CRM pa mora aplikacija v zgodovino stranke zapisati vsebino ter čas poslanega sporočila SMS. Predvideti pa
moramo tudi v katerem meniju v sistemu CRM se bo nahajala aplikacija, ter kateri uporabniki bodo imeli dostop do katerih funkcionalnosti.
Potrebno se je tudi odločiti v katerem programskem jeziku se bo pisala koda. Glede nato, da je CRM narejen kot spletna aplikacija in večinoma napisan v jeziku ASP.net, smo se tudi sami odločili napisati aplikacijo v tem programskem jeziku, za oblikovanje pa uporabili CSS in Bootstrap. Za bazo smo uporabili obstoječo bazo sistema CRM, Oracle podatkovno bazo. Na baznem nivoju predvidimo dve novi tabeli ter eno proceduro. Potrebujemo novo tabelo za shranjevanje predlogov tekstov, saj nam ta način omogoča lažjo administracijo teh tekstov in pa tabelo v katero se bodo vpisovala poslana sporočila SMS teksti ter številka MSISDN. Na bazi pa je potrebna nova procedura, ki naredi HTTP poizvedbo za pošiljanje sporočila SMS.
Navodila za HTTP poizvedbo, ki pošilja sporočilo SMS smo sicer našli na spletni strani A1.si, saj smo za pošiljanje uporabili A1 SMS center.
4.1.3 Razvoj aplikacije
Razvoj aplikacije pomeni izvedbo načrtovane arhitekture aplikacije. Za pisanje kode aplikativnega dela uporabimo program Notepad++, ki omogoča preprosto in hitro pisanje kode v večini programskih jezikov, omogoča pa tudi dodatke, ki nam olajšajo pisanje kode. Za razvoj objektov na podatkovni bazi uporabimo program SQL Detective. SQL Detective je enostaven vmesnik za uporabo Oracle podatkovnih baz. Z njim lahko enostavno naredimo ter spreminjamo objekte na podatkovni bazi in upravljamo s podatki v tabelah.
Kodo najprej napišemo na razvojnem okolju, ki je namenjeno pisanju nove kode. V našem primeru, kjer na sistemu lahko hkrati dela več različnih razvijalcev, ima vsak razvijalec svoje okolje za razvoj. S tem preprečimo, da več programerjev hkrati programira v istem delu programa oz. kode, ter s tem spreminja oziroma briše kodo drug drugemu. Ko je koda pripravljena jo na test prenesemo s pomočjo orodja GIT. Uporaba orodja GIT je enostavna, orodje pa GIT omogoča hkratno delo več razvijalcev na istem delu kode. Omogoča tudi revizijo oziroma pregled vseh sprememb v kodi. GIT je sicer brezplačen sistem, v orodju pa se beležijo vse spremembe v kodi, tako na nivoju aplikacije kot tudi nivoju podatkovnih baz. Tako vidimo kdo je spreminjal določen del kode, kaj je spreminjal ter z katerim razlogom. Ko na testnem okolju prestane teste, GIT uporabimo tudi za prenos kode iz testnega sistema na produkcijo. V kolikor bi bilo na testu v našem delu kode več sprememb, ki niso naše, nam GIT omogoča preprost prenos na produkcijo le naše kode.
21 4.1.4 Test aplikacije
Ko je program napisan do konca, izvedemo vsaj osnovne teste na razvojnem okolju. Če vse deluje po pričakovanjih kodo prestavimo na testno okolje. Testiranje v našem primeru izvaja oddelek za testiranje. Testiranje izvajajo po predpisanih scenarijih, ki se pripravijo na podlagi zahtev za razvoj produkta. Preverja se torej, ali program omogoča vse zahtevane funkcionalnosti, oziroma če te funkcionalnosti delujejo kot je zahtevano, preveriti pa je potrebno tudi morebitno delovanje ob vpisu napačnih podatkov.
V oddelku za testiranje imajo tudi več izkušenj s testiranjem, so bolj natančni, posledično pa opazijo tudi kakšne druge manjše napake, ki smo jih sami mogoče spregledali. Tudi sicer je bolje, da testiranje izvede druga oseba kot je razvijala program, saj razvijalec že podzavestno pozna delovanje aplikacije ter njeno uporabo, posledično pa ne klika ostalih kombinacij, ki jih morebiti drugi uporabniki, ki aplikacije ne poznajo tako dobro. Ko so potrjeni vsi testni scenariji pa je koda pripravljena na prenos na produkcijo.
4.1.5 Prenos kode na produkcijo
Glede nato, da je naša aplikacija del večjega sistema CRM, za podporo sistema pa skrbi več ljudi, jim je pred prenosom na produkcijo potrebno predati potrebna znanja za upravljanje oziroma podporo aplikacije. Predamo jim tehnično specifikacijo produkta, pokažemo delovanje aplikacije z vidika uporabnika ter pokažemo tudi glavne dele kode.
Za prenos na produkcijo si že prej pripravimo plan prenosa, da prenos poteka brez težav, in da se prenese vso potrebno kodo. Pri tem nam je v pomoč GIT, saj imamo vse spremembe zabeležene pod istim zahtevkom. Prenos kode na produkcijske strežnike se praviloma izvaja izven delovnega časa oz. angleško »business hours«, da preprečimo vpliv na uporabnike v primeru kakršnihkoli težav pri prenosu kode. V našem primeru to naredimo v večernih urah, saj ima CRM takrat manj aktivnih uporabnikov kot na primer čez dan. Zaradi uporabe aplikacije na več virtualnih strežnikih, moramo biti obvezno pozorni, da spremembe prenesemo na vse strežnike. Za prenos sprememb na podatkovno bazo, pa se je potrebno o tem predhodno dogovoriti z administratorji podatkovne baze, ter jim posredovati uradno zahtevo za prenos kode. Sami namreč na produkciji nimamo vseh pravic. Koda se na produkcijsko podatkovno bazo prenaša iz testnega baze. Prav tako moramo obvestiti uporabnike z najavo del, da so seznanjeni o spremembah ter o morebitnih težavah. Ko je opravljen prenos na produkcijo
naredimo še osnovne teste delovanja tudi na produkciji. V kolikor karkoli ni kot smo pričakovali, moramo imeti pripravljen scenarij, da vse vrnemo v prejšnje stanje. Nova koda lahko namreč povzroči tudi nepričakovane težave ali pa celo na produkcijskem okolju ne deluje kot je bilo zahtevano. Zato je potrebni imeti pripravljen obratni scenarij prenosa na produkcijo, torej da vrnemo kodo nazaj v prvotno stanje.
4.2 Delovanje aplikacije in umestitev v obstoječ sistem CRM
Naša aplikacija je samo del celotnega sistema CRM. V aplikaciji smo uporabili veliko že prej razvitih funkcionalnosti. Uporabili smo podatke o strankah ter na primer obstoječo funkcionalnost prikazovanja zgodovine uporabnika. Tudi prijava v sistem CRM oziroma dostop do naše aplikacije je narejen na podlagi obstoječih uporabniških imen.
4.2.1 Upravljanje uporabnikov sistema CRM
Uporabnikom se dostop do sistema CRM dodeljuje na podlagi uradnega zahtevka, ki se ga odda preko zato namenjenega orodja. Nove dostope lahko zahtevajo samo vodje ali nadrejeni.
Uporabnika nato dodajamo preko aplikacije za administracijo, do katere imamo dostop v sistemu CRM kot administratorji sistema. Aplikacija za kreacijo uporabnika je preprosta. V aplikaciji imamo pred definirane različne tipe profilov za različne oddelke v podjetju (klicni center, prodajalec, IT, naročniška služba,…). Na podlagi zahtevka dodelimo pravi profil uporabnika, izberemo uporabniško ime, ter vpišemo še podatke kot so ime in priimek, e-mail naslov in telefonska številka. Aplikacija za administracijo avtomatsko naredi zapise v podatkovni bazi v potrebne tabele. V eni tabeli so zapisi o uporabniku, v drugi pa so definirani dostopi, ki jih ima uporabnik. Vsak uporabnik sistema CRM mora na tri mesece menjati geslo.
Le - to, mora biti dolgo vsaj osem znakov, vsebovati mora tudi vsaj eno veliko črko, en posebni znak ter dve številki. Če uporabnik pozabi svoje geslo, mora oddati zahtevek za ponastavitev gesla. Kot administratorji imamo le mi dostop, da lahko naredimo ponastavitev gesla za druge uporabnike. Geslo pa se potem ponastavi na privzeto geslo. Dostop do naše aplikacije za pošiljanje sporočil SMS sicer omogočimo samo določenim tipom profila v sistemu CRM, za katere je bil ta dostop zahtevan. V menijih v sistemu CRM se uporabnikom prikazujejo samo aplikacije do katerih imajo definirane dostope.
23 4.2.2 Umestitev aplikacije v obstoječ sistem
Aplikacijo umestimo v meni z zapisom v tabelo, kjer imamo zapise vseh menijev v sistemu CRM. Na sliki 9 je prikazan izpis poizvedbe. V to tabelo v polje »TXT« zapišemo ime aplikacije, kot jo bomo poimenovali v meniju, v drugo polje »URL« pa ime datoteke na strežniku, v katerem se nahaja koda aplikacije. V tej tabeli tudi definiramo kje v meniju se bo nahajala naša aplikacija. Meniji imajo namreč drevesno strukturo, v polju »LEVEL_NR«
določimo na katerem nivoju v meniju bo ta naš meni, ter v polju »PARENT«, kateri meni je nad njim. LEVEL_NR 1 pomeni, da je nad njim le en zapis, zapis, ki ima vrednost »NR« 26.
Definicija, kateri profili imajo dostop do tega menija pa je v drugi tabeli povezani z to po polju.