Ut M Proje KT Mediation

UNIVERZITET U SARAJEVU ELEKTROTEHNIKI FAKULTET ODSJEK ZA TELEKOMUNIKACIJE
MEDIATION Medijacija u upravljanju obraunom
Projekt iz predmeta Upravljanje telekomunikacijskim mreama
Elbisa olak, Meliha Duli & Erma Perenda
Sarajevo, 2012
Upravljanje TK mreama
MEDIATION - Medijacija u upravljanju obraunom
Sadraj
UVOD........................................................................................................................................... 4 1. Upravljanje obraunom ......................................................................................................... 5 1.1 Arhitektura sistema za upravljanje obraunom ...................................................................... 5 Sistem za obraun ........................................................................................................... 6 Sistem za naplatu............................................................................................................. 6 Sistem za tarifiranje ......................................................................................................... 9
1.1.1 1.1.2 1.1.3 2.
Medijacija ........................................................................................................................... 10 2.1 2.2 2.3 2.4 2.5 Potreba za medijacijom ......................................................................................................... 11 Zahtjevi prema medijacijskom sistemu ................................................................................. 12 Medijacijske karakteristike .................................................................................................... 12 Medijacijski ureaji ............................................................................................................... 14 CDR standardni format .......................................................................................................... 15 CDR format za glasovne usluge ..................................................................................... 16 CDR format za podatkovne usluge ............................................................................... 16
2.5.1 2.5.2 2.6 2.7 3.
Aktivna i pasivna medijacija .................................................................................................. 18 Rjeenja za medijaciju ........................................................................................................... 18
Medijacija i jBilling .............................................................................................................. 22 3.1 3.2 jBilling arhitektura ................................................................................................................. 22 Model baze podataka ............................................................................................................ 23 Korisnici ......................................................................................................................... 24 Item-i ............................................................................................................................. 26 Purchase Order .............................................................................................................. 27 Rauni ............................................................................................................................ 28 Plaanja.......................................................................................................................... 29 Medijacija ...................................................................................................................... 31
3.2.1 3.2.2 3.2.3 3.2.4 3.2.5 3.2.6 3.3 3.4
Instalacija Community jBilling ............................................................................................... 32 Medijacija u Community jBilling-u......................................................................................... 34 Pasivna medijacija ......................................................................................................... 34 Aktivna medijacija ......................................................................................................... 35
3.4.1 3.4.2 3.5 3.6
Opis testnog scenarija ........................................................................................................... 36 Realizacija testnog scenarija.................................................................................................. 36 Medijacijski proces ........................................................................................................ 36 2
3.6.1
Upravljanje TK mreama 3.6.2 3.6.3 3.6.4 3.6.5 3.6.6 3.6.7 3.6.8
Defincija medijacijskog formata ................................................................................... 37 ita plug-in .................................................................................................................. 39 Konfiguracija medijacije ................................................................................................ 41 Item management ......................................................................................................... 43 Kreiranje novih korisnika ............................................................................................... 45 Procesiranje s pravilima................................................................................................. 49 Rezultati medijacije ....................................................................................................... 63
ZAKLJUAK................................................................................................................................. 66 AKRONIMI.................................................................................................................................. 67 LITERATURA ............................................................................................................................... 68 Prilog ......................................................................................................................................... 69
UVOD
Razvoj drutvenih i privrednih sistema u drugoj polovici prologa stoljea doveo je do naglog porasta potreba za brzom razmjenom informacija, to je uzrokovalo nagli razvoj telekomunikacijskih sistema. Istovremeno s razvojem telekomunikacijskih sistema, javlja se potreba za nadzorom i upravljanjem takvih sistema, budui da oni postaju sve kompleksniji. Postoji vie pristupa ka upravljakom sistemu. Jedan od najpoznatijih je FCAPS model, koji opisuje pet nivoa upravljanja mreom: upravljanje grekama, upravljanje konfiguracijom, upravljanje obraunom, upravljanje performansama i upravljanje sigurnou. Sistemi za upravljanje obraunom dobijaju sve veu vanost kod mrenih operatora. U tradicionalnim telekomunikacijskim mreama, sistemi za tarifiranje i naplatu usko su vezani uz pojedine usluge, pri emu svaka usluga ima specifina pravila tarifiranja i format rauna. Proces tarifiranja i naplate svake usluge je odvojen i nezavisan, a pretplatnici pojedinih usluga definirani su u zasebnim sistemima, ime je ograniena ili oteana razmjena informacija i fleksibilnost u poslovanju. Operatori se danas suoavaju s novim izazovima na tritu, kao to su uvoenje kompleksnih multimedijalnih usluga, segmentacija pretplatnika, te upravljanje partnerima uz istovremenu potrebu za kontrolom trokova i osiguranjem prihoda. Za uspjeh multimedijalnih usluga, kljuno je kreirati nove trine pakete i poslovne modele koji e privui pretplatnike, a takoer i partnere. Trini paketi usluga moraju biti cjenovno i ponudom atraktivni, a istovremeno jednostavni i razumljivi krajnjem korisniku. Korisnik zahtjeva kontrolu trokova i personalizirani sadraj. Operatori trebaju uinkovit i nenametljiv nain kojim mogu pridobiti pretplatnikovu panju, stimulirati koritenje usluga i osigurati lojalnost. U takvom okruenju podjela pretplatnika i usluga na razliite sisteme tarifiranja i naplate vie nije poeljna niti potrebna, kako s tehnolokog, tako i s poslovnog aspekta. Od sistema za tarifiranje i naplatu zahtjeva se fleksibilnost, uz fokus na smanjenje trokova pa tradicionalni, potpuno odvojeni vertikalni sistemi naplate nisu isplativo rjeenje. Ovaj projektni zadatak ima za cilj da predstavi vanost medijacije unutar sistema za naplatu i tarifiranje. Rad je podjeljen na tri dijela. U prvom dijelu opisana je arhitektura sistema za upravljanje obraunom, uz kratki osvrt na pojedine komponente tog sistema. Drugi dio rada koncentrisan je na proces medijacije, njegovu ulogu i zahtjeve koji se postavljaju pred ovaj proces. Takoer, data su potencijalna rjeenja za medijaciju bazirana i na komercijalnim proizvodima, kao i na open-source rjeenjima. Trei dio rada opisuje jedan od iroko rasprostranjenog open-source rjeenja za medijaciju, jBilling. U ovom dijelu detaljno je opisan proces medijacije unutar ovog alata, uz naznaku svih specifinih koraka ovog procesa. U cilju ilustracije tog procesa, realiziran je jedan testni scenarij.
1. Upravljanje obraunom
Upravljanje obraunom sadri skup funkcija koje omoguavaju mjerenje koritenja mree (i servisa), te kolekciju, tarifiranje i obraun podataka o koritenju mree (servisa). Sistemi za tarifiranje i sistemi za naplatu su kljuni sastavni dijelovi svakog telekom operatora kod procesa upravljanja obraunom. Sistemom tarifiranja (engl. Charging System) nazivamo svaki proces koji u sistemu skuplja i procesira informacije o svim dogaajima vanim za tarifiranje. Sistem za obraun (engl. Accounting System) brine se o raspodijeli trokova u sluaju da vie pruatelja usluge uestvuje u kreiranju i dostavi usluge, na primjer u sluaju roaming-a. Sistem za naplatu (engl. Billing System) obavlja funkciju akumulacije svih trokova, te izdavanja rauna za krajnjeg korisnika. Nadalje, kako bi sistem tarifiranja mogao obavljati svoju zadau, on mora koristiti funkciju odreivanja tarife, jedinine cijene pojedine usluge (engl. Tariffing), te funkciju raunanja broja iskoritenih jedinica (engl. Metering). [1]
1.1 Arhitektura sistema za upravljanje obraunom

Slika 1.1 ilustrira arhitekturu sistema za upravljanje obraunom. Logiki je podjeljena na tri dijela: sistem za obraun, sistem za naplatu i sistem za tarifiranje. Sistem za naplatu je daleko sloeniji od sistema za tarifiranje.
Sl.1.1 Arhitektura sistema za upravljanje obraunom [2]
Upravljanje TK mreama 1.1.1 Sistem za obraun
Sistem za obraun sastoji se od CRM/OMOF sistema, Provisioning sistema i Network Inventory sistema. CRM (engl. Customer Relationship Management) / OMOF (engl. Order Management and Order Fulfillment) sistem je prvi sistem koji se koristi pri kreiranju korisnikog naloga. CRM je sistem kojim prilagoavamo strategiju, organizaciju i kulturu poslovanja na nain da svaki kontakt s korisnikom vodi ka dugoronom zadovoljstvu korisnika, a time i dugorono povezanoj dobiti kompanije. Pri tome se ne razmilja na nain "ta mi moemo ponuditi korisniku?", nego na nain "kako upoznati korisnika i identificirati njegove potrebe?". Osnovna ideja CRM-a je, ne vie orjentiranost kompanije prema uslugama, ve poveana briga za korisnika. Usluge moraju biti prilagoene osobnosti korisnika usluga. Ovo je danas postalo mogue razvojem baza podataka, koje omoguavaju pohranu podataka o pojedinim korisnicima, te softvera koji omoguava analizu i optimalno koritenje tih podataka. CRM uva relevantne informacije o korisniku i proizvodima i uslugama koje koristi. OMOF modul je odgovoran za praenje korisnikog naloga od njegovog nastanka pa do zavretka. CRM/OMOF modul moe komunicirati s niim slojevima na dva naina: CRM/OMOF sistem kontaktira sistem za naplatu, koji zatim kontaktira Provisioning sistem za pruanje usluge i Network inventory sistem za dodjelu telefonskih brojeva ili IP adresa, a potom sistem za naplatu vraa povratnu informaciju CRM/OMOF sistemu. Druga mogunost je da CRM/OMOF sistem direktno kontaktira Provisioning sistem za pruanje usluga, kao i Network inventory sistema za dodjelu telefonskih brojeva ili IP adresa i sl.
Provisioning sistem prima naredbe bilo od sistema za naplatu ili CRM/OMOF sistema za aktiviranje, deaktiviranje i obustavljanje usluge. Obje arhitekture su validne i ovise od toga kako je dizajnirana organizacija sistema. Po prijemu naredbe, ovaj sistem kontaktira jezgro mree za aktiviranje, deaktiviranje ili obustavljanje usluge. Nakon uspjeno obavljenog zadatka, ovaj sistem alje odgovor natrag onom sistemu koji mu je poslao naredbu. Network Inventory System (NIS) odrava listu svih mrenih identifikatora poput telefonskih brojeva, MSISDN (engl. Mobile Station International Subscriber Directory Number), IP adrese, e-mail adrese i sl. Ovisno o arhitekturi sistema, CRM/OMOF sistem moe direktno ili posredno preko sistema za naplatu kontaktirati NIS za dobijanje odreenog mrenog identifikatora i dodijeliti ga korisniku za vrijeme kreiranja korisnikog naloga. Ovaj sistem je, takoer, odgovoran za odravanje ivotnog ciklusa mrenog identifikatora, koji pri samom kreiranju korisnikog naloga postaje dostupan, a potom prolazi kroz faze aktivacije, obustavljanja, ukidanja ovisno o prirodi i ponaanju korisnika. 1.1.2 Sistem za naplatu
Sistem za naplatu je sastavljen od serije nezavisnih aplikacija koje se pokreu zajedno na jednom hardveru. Sastoji se od sljedeih dijelova: 6
Billing Engine je maina za naplatu koja za odgovarajui korisniki nalog sakuplja sljedee relevantne informacije na osnovu kojeg generira fakturu podataka (engl. invoice) koja se koristi za kreiranje rauna, koji se alje krajnjem korisniku (Sl. 1.2): svi rating CDR-ovi (engl. Call Detail Records) za korisnika u toku mjesecu; sve vrste tarifiranja (instalacija, suspenzija, ukidanje i sl.) koje se primjenjuju za korisnikov proizvod i uslugu; postoji li bilo kakav drugi oblik tarifiranja koji se primjenjuje; postoji li zaostali dug iz prethodnih rauna; da li je korisnik unaprijed platio u odreenom mjesecu; postoji li popust za korisnika; ukupni porezi i trokovi obrade rauna; da li je monitiranje prolo u dobrobit korisnika ili ne; Billing konfiguracijski parametar je potreban za pokretanje Billing Engine-a, na primjer plaanje do odreenog datuma i sl.
Iznad navedeni podaci su samo indikativni i mogu varirati ovisno o vrsti sistema za naplatu, kao i od operatora. Billing Engine maina proizvodi sirove podatke koji imaju sve potrebne informacije za generiranje konanog obrauna i ovi sirovi podaci se mogu koristiti za generiranje konane fakture koja se alje krajnjem korisniku.
Sl.1.2 Billing Engine i njegove funkcije [2]
Rating Engine prima dogaaje (jedna pojava upotrebe usluge/proizvoda) u obliku record podataka koji se zovu Call Detail Records (CDR) ili Usage Detail Records (UDR), koji opisuju koritenje proizvoda/usluge (sl. 1.3). CDR je niz podataka koji sadri informacije o pozivu kao 7
to su datum i vrijeme poziva, trajanje poziva, pozvana strana, pozivajua strana, koje se koriste za rating dogaaja. Osnovne funkcije ove maine su prihvatanje CDR-ova od sistema za medijaciju, provjera validnosti CDR-a, u sluaju duplikata odbacivanje CDR-a i slanje ovog duplog CDR-a u bazu podataka koji e biti kasnije verificiran, na osnovu izvorne adrese CDR-a pretrauje bazu podataka da utvrdi da li postoji korisniki nalog, ako ne postoji dogaaj se odbija, raunanje cijene dogaaja na osnovu tarife koja je sadrana u planu za cijene dogaaja, pohranjivanje ocjenjenog dogaaja u bazu podataka koja slui za naplatu ili se alje nekom eksternom sistemu za naplatu. Informacije korisnika odreuje plan tarifiranja u cilju izraunavanja cijene. Rating Engine koristi rating tabele i informacije o dogaaju iz CDR-a (npr. udaljenost, vrijeme, mjesto poziva, trajanje ili veliina dogaaja, itd.) kako bi izraunao stvarnu cijenu/tarifu za svaki poziv.
Sl.1.3 Rating Engine i njegove funkcije [2]
Discount Process odnose se na reduciranje cijene proizvoda ili usluge bilo na nivou vremena ili tipa korisnika/usluge. Mogu se izraunati u toku rating procesa ili billing procesa. Detaljnije o ovim procesima vidjeti u [2]. Credit Control modul omoguava pruatelju usluge monitoring kredita pretplatnika i monitoring poziva, te preuzimanje mjera protiv odreenog pretplatnika ako je potrebno. Payment Processing je obrada uplaenog rauna u sistemu za naplatu. Uplate koje naini korisnik smjetaju se u njegov korisniki raun (engl. account). Ako postoje bilo kakvi nepodmireni dugovi onda raun koji se plaa ovisi o tipu raunovodstvene metode. Postoje dva tipa raunovodstvenih metoda: Balance forward accounting (plaanje prema starosti rauna) i Open item accounting (plaanje odreenog proizvoljnog rauna). Report Generation modul je bitan za pruanje korisnih informacija za upravljanje, finansije, prodaju i performanse sistema. Izvjetaji sadre podatke koji unapreuju poslovni uspjeh, monitoring ispravnosti poslovanja, identificiranje problema kako bi se primjenile odgovarajue korektivne akcije. Postoje dvije kategorije izvjetaja: temeljni/gotovi izvjetaji 8
(generie ih sistem za naplatu) i custom izvjetaji (nisu direktno dostupni iz sistema i zahtjevaju konstruisanje odgovarajuih PL/SQL, PERL skripti). 1.1.3 Sistem za tarifiranje
Sistem za tarifiranje sastoji se sistema za medijaciju, mrenih preklopnika, DWH baze, ERP sistema i Payment gateway-a. Mreni preklopnici su odgovorni za pruanje svih usluga krajnjim korisnicima u skladu s onim uslugama koje su zakonski regularne, tj. one koje su unutar CRM/OMOF sistema aktivirane za datog korisnika. Oni su odgovorni za kontrolu poziva, preuzimanje podataka, prenos SMS-ova i na kraju generiraju zapise o pojedinostima poziva, CDR-ove. Mreni preklopnici ukljuuju MSC (engl. Mobile Switching Center), GGSN (engl. Gateway GPRS support node) i MMSC (engl. Multimedia Messaging Service Center). Skladite podataka DWH (engl. Data Ware House ) sistem je baza podataka koja sadri historijske nepromjenjive podatke, koji se prikupljaju i obrauju radi podrke sistema za naplatu. Podaci se izvlae iz raznovrsnih izvora, te se u skladu s definiranim modelom podataka uitavaju u bazu podataka i integriraju s postojeim podacima. U logikom smislu, to je centralizirana baza podataka koja se periodiki osvjeava. uvaju se informacije vezane za koritenje usluga, raune, plaanja, popuste i prilagodbe itd. Sve ove informacije se koriste za generiranje raznih vrsta izvjetaja, koji se koriste za poslovnu inteligenciju i prognozu. Enterprise Resource Planning (ERP) sistem je uobiajeni naziv za poslovni softver koji integrira aktivnosti razliitih odjela kao to su planiranje proizvodnje, nabavka dijelova, upravljanje zalihama, distribucije proizvoda i praenje narudbi. On moe objediniti aplikacijske module za finansije, raunovodstvo i upravljanje ljudskim resursima. Payment Gateway ne mora nuno biti kompletan sistem, ali predstavlja neku vrstu posrednika izmeu sistema za naplatu i plaanja putem razliitih kanala kao to su banke, kreditne kartice i dr. Svi kanali koji se koriste za plaanje koriste Payment gateway. Obino Payment gateway predstavlja neku vrstu API-a (engl. Application Programming Interface) vanjskom svijetu, u cilju obavljanja plaanja koje je direktno vezano za sistem za naplatu. API se moe koristiti od strane bilo kojeg vanjskog izvora kako bi se obavilo plaanje. Sistem za medijaciju prikuplja CDR-ove od razliitih mrenih elemenata u razliitim formatima i obrauje ih i pretvara u jedinstveni format, kompatibilan onom koji se koristi kod sistema za naplatu. Detaljnije o procesu medijacije dato je u drugom poglavlju.
2. Medijacija
Medijacija je proces koji je umetnut izmeu mrenih elemenata i downstream aplikacija. Ove aplikacije mogu biti razliitih vrsta i medijacijski proces sam moe upravljati nekom od tih vrsta podataka. Medijacija je lanac tri procesa: prikupljanje podataka, normalizacija i poslovna transformacija i dostava podataka. [9] 1. Prikupljanje podataka ukljuuje prikupljanje korisnih informacija u formi CDR-a. CDR se sakuplja od razliitog seta mrenih elemenata, rangiranih od PSTN switch-eva do MSCova, koritenjem razliitih transportnih protokola kao to su FTP, FTAM (engl. File Transfer Access and Management) i TCP streaming. Formati CDR-ova, mogu varirati zavisno od opreme koja se koristi, i mogu biti u jednom od formata: ASN.1 BAF ili fiksirana binarna irina (engl. fixed width binary)/ASCI, itd. 2. Normalizacija je proces transformacije CDR-a iz sirovog ulaznog formata u interni format prikladan za poslovne transformacije. Transformacija se izvodi koritenjem seta poslovnih pravila da odredi znaajne podatke za transakciju i okolnosti u kojima se podaci koriste. Na primjer, slanjem svih zapisa prema statistiki baziranim poslovnim aplikacijama, ali slanjem samo poziva koji traju vie od minute prema sistemu za obraun. U scenariju komunikacije podataka, proces transformacije ukljuuje apsorpciju informacija iz razliitih izvora podataka i konsolidaciju prikupljenih podataka u saet zapis. 3. Dostava podataka je posljednji korak u procesu medijacije. Ovdje, CDR je dostavljen downstream aplikaciji, koja moe biti: sistem za naplatu, sistem za upravljanje prevarama i poslovni inteligentni sistem. Ovaj korak ukljuuje sljedee procese: Kodiranje prikupljenog i transformisanog CDR-a u format, koji je prikladan za odgovarajuu downstream aplikaciju; Streaming transformisanog CDR-a za neposredno koritenje od strane downstream aplikacije u push-mode operaciji; Smjetanje podataka u fajl, tako da ih downstream aplikacije mogu koristiti u odreeno vrijeme.
10
Sl.2.1 Proces medijacije [9]
2.1 Potreba za medijacijom

Medijacijski proces omoguava pruateljima usluga da iskoriste sve prednosti njihovih mrenih korisnih podataka, koritenih ne samo za streamline nekog sistema za naplatu, nego i za strateke aplikacije, kao to su upravljanje prevarama, analize ponaanja korisnika i mreno planiranje. Fleksibilnost medijacijskog procesa omoguava operatoru da se nosi sa buduim aplikacijama koje e biti dodane i pomae im da bolje upravljaju njihovim porastom u kompleksnom okruenju, koje se brzo mijenja. Medijacijski sistem je uveden s ciljem da prui mrenim operatorima put za bre razvijanje novih aplikacija i servisa, dok titi postojee aplikacije od promjena. [9] Danas u konkurencijskom okruenju, operatori moraju da prue mnogo vie usluga, baziranih na novim tehnologijama. Medijacijski sistem omoguava ne samo neposredni obraun za nove pokrenute usluge, nego i konvergenciju obrauna, odnosno pruanje samo jednog obrauna prikupljanjem svih obraunskih informacija povezanih sa svim uslugama, koje je koristio korisnik (pretplatnik). Fleksibilnost je veoma vana sposobnost za opstanak na konkurentnom tritu i omoguavanje ovih novih karakteristika, da se mogu nositi sa poveanim tehnolokim komplikacijama i vladajuim pravilima, i sposobnost da uvedu prototip novih usluga, te da izmjere njihovo prihvaanje i interes od strane korisnika, prije nego to uloe velika sredstva za njihovu implementaciju.[9] Davatelji usluga moraju preispitati sami sebe kako e neka od sljedeih pitanja utjecati na njihov sistem za obraun: prenosivost broja; razdvojene mree (engl. unbundled networks); pristup cijenama (engl. charges) drugih ISP-ova; performanse usluga u inteligentnim mreama; konvergencija vie tipova usluga u jedan obraun. 11
Za adaptaciju i primjenu ovih promjena, fleksibilnost u njihovim medijacijskim sistemima je kljuna. Dakle, medijacijski sistem je kljuan za savladavanje sljedeih izazova: na vrijeme izbaciti nove usluge na trite (engl. time-to-market for new services); obraun za vie tipova mrenih usluga; real-time medijacija je potrebna za detalje o pozivu i informacije za naplatu; IP telefonski obraun; veleprodajni i maloprodajni obrauni; meuoperatorski ugovor je potreban; prevencija sigurnosnih prevara.
Stoga, medijacijski sistem: stavlja fokus na organizacijski end-to-end pogled na uslugu; podrava nove dodane usluge; popunjava praznine izmeu IT (engl. Information technology) i mrenih operacija; smanjuje zavisnost sistema za naplatu od mrenih elemenata; moe ubrzati uvoenje konvergentnih usluga; uteda pomou podrke za vie razliitih medijacijskih platformi; prua OSS (engl. Operation Support System) fleksibilnost da omogui spajanje i akviziciju; sposobnost integracije mree - FMI, SS7.
2.2 Zahtjevi prema medijacijskom sistemu

Zahtjevi koji se postavljaju pred medijacijski sistem su: sakupljanje podataka od interfejsa mrenih elemenata razliitih proizvoaa; podrka za uvoenje novih tehnologija; podrka za izmjene novih tehnologija; normalizacija, ujedinjenje i filtracija podataka preko razliitih tipova ureaja i proizvoaa; dostavljanje podataka razliitim sistemskim interfejsima mrenih elemenata; podrka za uvoenje novih sistema; podrka promjenama novih sistema, za upoznavanje sa novim poslovnim zahtjevima.
2.3 Medijacijske karakteristike

Na sljedeoj slici data je generalizirana arhitektura medijacijskog sistema. 12
Sl.2.2 Generalizirana arhitektura medijacijskog sistema [9]
Sakupljanje (engl. Collection) Medijacijski sistem mora sakupiti CDR-ove od razliitih mrenih elemenata, preklopnika razliitih proizvoaa, internetskog rutera, Internetskih usluga (e-mail, autentifikacija, itd.). Podaci se sakupljaju pomou razliitih protokola, traka ili diskova. Najee koriteni protokoli su: FTP preko TCP/IP, FTAM preko OSI stack-a, X.25 ili Ethernet na niovu linka. Filtracija (engl. Filtering) Medijacijski sistem filtrira CDR-ove na osnovu korisniki-konfigurisanih pravila. Svrha ove kakakteristike je razdvajanje naplativih CDR-ova, od onih nenaplativih ili da usmjeri CDR-ove prema uslugama koje se odnose na poziv ili da usmjeri i pohrani parcijalne CDR-ove generirane tokom dugotrajnih poziva. Mogu se filtrirati pogreni CDR-ovi i usmjeriti na ureaj za korekciju. Integracija, konsolidacija (engl. Consolidation) Ova karakteristika je veoma vana i specijalna za Internetski obraun. Omoguava da se napravi samo jedan CDR baziran na korisniki definiranim pravilima i omoguava prikupljanje svih obraunskih informacija od drugih srodnih CDR-ova, koji mogu dolaziti iz razliitih izvora. Prezentacija (engl. Presentation) Kao to je navedeno ranije, format sirovog CDR-a ne moe se koristiti za obraunsku aplikaciju. Prezentacijska karakteristika konvertuje CDR format u format koji se zahtjeva od strane sistema za naplatu. Mogu se modificirati i/ili dodati informacije ako su potrebne. Dodane informacije mogu biti 13
izvedene iz ostalih postojeih informacija ili dohvaene iz vanjskih izvora (npr. baze podataka). Kao izlaz ovog procesa, dobije se obraunski zapis, koji moe biti sakupljen u datoteci ili sauvan odvojeno za neposrednu distribuciju. Distribucija/Raspodjela (engl. Distribution) Obraunski zapisi se raspodjeljuju na obraunske aplikacije. Sredstva koja se obino koriste: FTP preko TCP/IP, NFS montirani disk, TCP/IP, Ethernet na nivou linka. Ope usluge (engl. General services) Osim ovih tipinih medijacijskih karakteristika, medijacijski sistem treba ope namjenske usluge: planiranje: za poetak ukupnog procesa ili samo dijela procesa; reviziju logova; praenje Monitoring; korisniki interfejs: preferira se grafiki interfejs, koji omoguava korisniku pristup svim nivoima za konfiguraciju, praenje, te reviziju funkcija; izvjetavanje: generiranje izvjetaja za prihod od osiguranja; notifikacije alarma u sluaju greke koja zahtjeva neposrednu akciju; arhiviranje: pohranjivanje sirovih CDR-ova za kasnije reprocesiranje.
2.4 Medijacijski ureaji

Medijacijski ureaji primaju, procesiraju i reformatiraju informacijske dogaaje u telekomunikacijskim mreama u format pogodan za jedan ili vie obraunskih sistema i za sisteme za podrku korisnicima. Obraene informacije se stalno ili povremeno alju sistemu za naplatu. Switch obino zapisuje korisne informacije (npr. trajanje veze) u Binary Coded Decimal (BCD) formatu i ovi zapisi su najee vlasnitvo proizvoaa switch-a. Zapisi mogu biti razliitih duina i nekoliko dogaaja mogu biti zapisani u istom sistemu za jedan poziv. Postoji najmanje 60 proizvoaa switcheva i svaki od njih ima nekoliko modela switch-eva, koji mogu dovesti do razliitih formata obrauna. Slika 2.3 prikazuje medijacijski sistem koji preuzima CDR-ove sa nekoliko razliitih switch-eva i transformie ih u standardne CDR-ove, koji se prosljeuju obraunskim sistemima. Sa slike se vidi da medijacijski ureaji imaju mogunost primanja i dekodiranja odreenih formata podataka od raznih proizvoaa switch-eva. Medijacijski ureaji konvertuju ove formate u standardni CDR format, kojeg moe koristiti sistem za naplatu.
14
Sl.2.3 Medijacijski sistem [4]
Preovladavajui ekonomski uvjeti na komunikacijskom tritu osiguravaju da su svi pruatelji usluga fokusirani na ROI (engl. Return on investment ) i na realizaciji poslovnih prednosti (engl. benefits). Svaka akcija provedena od strane neke organizacije je odmjerena prema ovim kriterijima.[9] Proizvodi se grade na bazi sljedeih naela: Brzi povratak ulaganja: prekonfigurisana integracija minimizacija cijene i vremena integracije sistema; pojedinana linija proizvodnje svi korisnici na istoj verziji software-a, minimizacija TCO-a; brzi razvoj minimizacija vremena od ugovora do povratne investicije.
Fleksibilnost: postepena implementacija olakava pomjeranje od nasljeenog sistema; konfigurabilan GUI driven parameter set-up i poslovni procesorski editor; brza implementacija usluga.
2.5 CDR standardni format

Format CDR-a ovisi o tipu usluge za koju se koristi. Tipovi usluga koje operator nudi korisnicima ukljuuju glasovne i podaktovne usluge preko mobilne ili fiksne mree, IP usluge (poput e-mail-a) i isporuku sadraja. Drugim rijeima, usluge se mogu podijeliti na glasovne i podatkovne usluge. [9] 15
Upravljanje TK mreama 2.5.1 CDR format za glasovne usluge
Glas je osnovna usluga koju prua svaki telekom operator. Postoje dvije tehnologije koje se koriste za prenos glasa: tehnologija bazirana na komutaciji kanala; tehnologija bazirana na komutaciji paketa (odnosno glas preko IP tehnologije - VoIP). Kod tehnologije bazirane na komutaciji krugova, CDR mora sadravati: jedinstveni sekvencni broj koji identificira CDR (engl. Unique Identifier Record); pozivajui broj (engl. Call Originator); pozvani broj (engl. Called Number); vrijeme poetka poziva (engl. Start Time); vrijeme zavretka poziva (engl. Stop Time). Osim toga CDR moe sadravati informacije poput: identifikator telefonske centrale, rezultat poziva (odbijen, uspostavljen), trunk ili ruta koritena za spajanje poziva, greke pri uspostavi poziva i dr. Tano snimanje svih zahtjevanih informacija u CDR/UDR zavisi od logike switch-a i specifine tabele zapisa tog switch-a. Ako bilo koja od zahtjevanih informacija nije korektna, medijacijski sistem nee prepoznati kompletan poziv i nee ga proslijediti sistemu za naplatu. Na narednoj slici je prikazana bazna struktura CDR-a.
Sl.2.4 CDR format za glasovne usluge preko tehnologije bazirane na komutaciji kanala [4]
2.5.2
CDR format za podatkovne usluge
Kao jedna od tehnologija koja prua podaktovne usluge je GPRS (engl. General Packet Radio Service). GPRS je paketska tehnologija, koja omoguava beinu komunikaciju, slanje i primanje informacije pokretnom mreom, koristei velike brzine. Standardiziran je od strane ETSI (engl. European Telecommunications Standards Institute) 2000. godine. Omoguava sljedee usluge: pristup intranetu, pristup internetu, e-mail i fax, tekstualne i slikovne poruke, chat, e-commerce i online-banking, oglaavanje, GPS (engl. Global Positioning System), automatizacija doma i dr. Kao 16
proirenje GSM mree, GPRS je dodao dva nova vora: SGSN (engl. Serving GPRS Support Node), ija je uloga u GPRS arhitekturi ekvivalentna ulozi MSC/VLR vora u postojeoj GSM arhitekturi i GGSN (engl. Gateway GPRS Support Node), koji je veinom pod ingerencijom rutera, koji podrava funkcije klasinog gateway-a, kao to su: objavljivanje pretplatnikih adresa, mapiranje adresa, povezivanje i tuneliranje paketa, prikazivanje poruka, te brojanje paketa, omoguava ifriranje, mobility management, naplaivanje i skupljanje statistikih informacija (zapisi o stanju rauna). Razliiti elementi GPRS mree sakupljaju razliite tarifne podatke [9]: SGSN generira tarifne informacije za upotrebu radio mree; GGSN generira tarifne informacije za eksternu upotrebu podaktovne mree; oba ova vora generiraju tarifne informacije o upotrebi resursa GPRS mree. GGSN CDR mora sadravati: vremenski trenutak poetka skupljanja tarifnih informacija: aktivacija PDP (engl. Packet Data Protocol) konteksta; vremenski trenutak prestanka skupljanja tarifnih informacija: deaktivacija PDP konteksta; koliinu saobraaja uplink/downlink-a; ugovoreni QoS (engl. Quality of Service); SGSN i GGSN adresu; AP (engl. Access Point) adresu; trajanje koritenja usluge. SGSN generie nekoliko tipova CDR-ova: S-CDR (SGSN-CDR), M-CDR (Mobility Management-CDR) i SMS-CDR. SGSN CDR odnosi se na koritenje radio mree i sadri iste CDR atribute kao i GGSN CDR. M-CDR odnosi se na aktivaciju upravljanja mobilnosti i sadri: vremenski trenutak poetka skupljanja: GPRS aktivacija/dolazei SGSN RA (engl. Routing Area) update; vremenski trenutak prestanka skupljanja: GPRS deaktivacija/odlazei SGSN RA update; promjenu lokacije. SGSN alje M-CDR Charging gateway1-u svaki put kada korisnik promjeni eliju, lokalno podruje ili pak routing podruje. SMS-CDR odnosi se na upotrebu SMS usluge u GPRS-u i on moe biti poslan preko tradicionalne ili pak preko GPRS backbone mree. Sadri informacije kao to su: servisni IMSI, servisni IMEI (engl. International Mobile Equipment Identity), servisni MSISDN i adresu SMS servisnog centra. Jedan PDP kontekst moe generirati nekoliko S-CDR-ova i G-CDR-ova. CDR-ovi se sistemu za naplatu alju u regularnim intervalima. CDR jednog PDP konteksta moe biti poslan od vie SGSN vorova, ako se korisnik kree i mjenja routing podruje ili u sluaju roaming-a.[9]
1
CG ima funkciju medijacije za GPRS sistem, korelira podatke dobivene iz SGSN-a i GGSN-a u jedinstveni izlazni format CDR-a, koji se dalje prosljeuje u medijaciju. 17
2.6 Aktivna i pasivna medijacija

Dosad opisan princip rada medijacijskih ureaja predstavlja pasivnu medijaciju. Aktivna medijacija opisuje funkcionalnosti sistema za medijaciju koji ima mogunost da komunicira sa pretplatnikom. Drugim rijeima, medijacijski sistem definira/generie dogaaj, a ne mreni elementi. Mreni elementi su sada zadueni za skupljane dogaaja generiranih od sistema za medijaciju. Aktivna medijacija ukljuuje mogunost autentifikacije i upita korisnika preko handset-a i inicijalizacije sesije preko koje sistem za medijaciju korisniku predstavlja itav niz izbora. Aktivna medijacijska platforma utvruje da li korisnik ima dovoljno kredita na svom raunu za koritenje drugih usluga i druge detalje. Stablina aktivna medijacija je razvijena od strane proizvoaa koji jo uvijek rukuju s jednostavnijom pasivnom medijacijom. U februaru 2004. godine na tritu se pojavio prvi aktivni konvergentni medijacijski sistem Xaccit Technologies od strane kompanija Comptel, Openet Telecom, Ace-Comm, Intec Telecom Systems, Narus i Amdocs, koje obeavaju smanjenje trokova odravanja, u odnosu na koritenja vie pasivnih medijacijskih sistema i prateih baza podataka [5].
2.7 Rjeenja za medijaciju

Kako bi se objasnila postojea rjeenja za medijaciju, neophodno je prethodno navesti tipove sistema za naplatu. [2] Najea podjela sistema za naplatu je na: Pre-pay sistem za naplatu je mehanizam naplate kod kojeg korisnik plaa unaprijed, nakon ega poinje da koristi uslugu. Obino, pre-paid korisnici ne primaju nikakve raune i oni se tarifiraju u realnom vremenu od strane iroko-dostupnih sistema za naplatu koji se nazivaju inteligentna mrea IN (engl. Inteligent Network). Post-pay sistem za naplatu predstavlja konvencionalnu naplatu, koja se koristi ve dugi niz godina. Ovdje korisnici kupuju proizvode ili usluge i koriste ih tokom nekog vremenskog perioda (obino mjesec dana) i na kraju pruatelj usluge izraunavaju agregirani obraun, kojeg alje korisniku koji su ga duni platiti. Interconnect sistem za naplatu najee se odnosi na partnerstvo razliitih operatora/davatelja usluga koji imaju zadatak da korisniku osiguraju uslugu, a prihode meusobno dijele. Roaming tarifiranje odnosi se na sluaj kada korisnik ide iz podruja pokrivenosti svog operatora u podruje drugog operatora. U cilju obezbjeivanja usluge svom korisniku i van podruja pokrivenosti, operator sklapa ugovor s drugim operatorom i duan je platiti drugom operatoru marginalne trokove. Konvergentni sistem za naplatu predstavlja san svakog velikog operatora. Odnosi se na integraciju tarifiranja svih usluga nekog korisnika u jedan raun. To znai stvaranje jedinstvenog pogleda operatora na korisnika i na sve usluge pruene tom korisniku. U posljednih nekoliko godina, sistemi za medijaciju postali su sofisticiraniji i obavljaju vei broj sloenih zadataka. Tvrdi se da e sistemi za medijaciju evoluirati do take gdje e moi obavljati tzv. 18
back office funkcije, tj. upravljanje SLA (engl. Service Level Agreement) ugovorom, obavjetavanje operatora da postoji nestaica propusnog opsega korisnicima, detektiranje i spreavanje zlonamjernih prevara. Kako svaki medijacijski sistem podrava bazu podataka u koje se upisuje korisnikovo ime, takoer korisnikovo ime stavlja se i u IP bazu podataka, te bazu podataka za beine usluge i upravo te tri baze podataka su mjesta koja omoguavaju prevare. Pri odabiru medijacijske platforme, operatori moraju uzeti u obzir svoj poslovni plan, stepen evolucije mree i marketinku strategiju. S obzirom na poveanje koritenja multimedijalnih aplikacija i podaktovnih usluga, operatori imaju zadatak da preispitaju svoj postojei sistem za medijaciju kako bi ostvarili to ekonominije strateke mogunosti medijacije [5]. Iako konvergentni medijacijski sistemi vladaju tritem, iznenaujue je to veliki broj velikih operatora jo uvijek koriste orginalne medijacijske sisteme, i kombiniraju jedan ili vie od ovih sistema za omoguavanje sistema za naplatu za razne sisteme bazirane na IP ili beinim irokopojasnim platformama. [2] Ovisno o tipu sistema za naplatu, orginalni/tradicionalni medijacijski sistemi se dijele na: Real-time sistemi za tarifiranje, poput Ericsson IN ili Nokia Siemens sistema za tarifiranje, su vrlo popularni za pruanje rjeenja za medijaciju za pre-paid proizvode i usluge. Ovi sistemi nisu dovoljno fleksibilni za obradu razliitih funkcionalnosti post-paid korisnika, poput sloene hijerarhijske baze korisnika, CDR re-rating, fleksibilni izvjetaji, roaming tarifiranje i dr. Post-paid sistemi za tarifiranje, poput Convergys Infinys ili Amdocs, su veoma dobri za postpaid proizvode i usluge. Nisu se u stanju nositi s pre-paid prometom i ne tarifiraju pozive u realnom vremenu. Ako kombinujemo gore navedene sisteme (npr. Convergys Infinys i Ericsson IN) moemo postii konvergentni medijacijski sistem. Ericssonovo rjeenje za konvergentno prikupljanje podataka (medijaciju) zove se Ericsson Multi Mediation EMM. EMM se sastoji od dva modula, modula za prikupljanje datoteka/dogaaja (engl. File/Event Module) i online modula. Modul za prikupljanje datoteka/dogaaja prikuplja podatke o usluzi iz bilo koje vieuslune i pristupne mree, neovisno o proizvoau opreme, te procesira prikupljene podatke u nerealnom ili priblino realnom vremenu, pa obraene podatke alje u sistem naplate, sistem za otkrivanje prevara (engl. Fraud) ili neki drugi sistem. Online modul omoguava dvosmjernu komunikaciju za razmjenu podataka o usluzi s mrenim elementima u realnom vremenu. Na taj nain omogueno je operatoru da naplati uslugu neposredno nakon to je koritena. [6] U sljedeim tabelama dati se proizvoai sistema za naplatu, odnosno medijacijskih sistema. Sistem Ericsson IN Nokia Siemens IN Orga Systems Web stranica http://www.ericsson.com http://www.nokiasiemensnetworks.com http://www.orga-systems.com
Tabela 2.1 Pre-paid sistemi za naplatu i tarifiranje [2]
19
Sistem Ascade i-conX Convergys Comptel Intec Systems Cerillion MTS Telarix
Web stranica www.ascade.com http://www.iconxsolutions.com/ http://www.Convergys.com http://www.comptel.fi/ http://www.intec-telecom-systems.com http://www.cerillion.com http://www.mtsint.com/ http://www.telarix.com/
Tabela 2.2 Interconnect sistemi za naplatu i tarifiranje [2]
Sistem za naplatu i tarifiranje Amdocs Convergys Cellution Comarch Comverse CSG Systems FTS HighDeal Huawei InfoDirections Kabira Technologies LHS Martin Dawes Systems Oracle RBM Sitronics
Web adresa http://www.amdocs.com http://www.Convergys.com http://www.1cellution.com/ http://www.comarch.com http://www.comverse.com http://www.csgsystems.com http://www.fts-soft.com http://www.highdeal.com http://www.huawei.com/ http://www.infodirections.com/ http://www.kabira.com/ http://www.lhsgroup.com http://www.martindawessystems.com http://www.oracle.com/index.html http://www.sitronicsts.com/en/home/index.html
Tabela 2.3 Post-paid sistemi za naplatu i tarifiranje [2]
Neki od gore navedenih sistema nude usluge i kovergentnog sistema za naplatu i tarifiranje (Ericsson, Huawei). Osim ovih komercijalnih proizvoda postoje i open-source rjeenja za medijaciju. Prednosti open-source rjeenja su u tome da su web-bazirana, mogu se proiriti i integirati za specifinu namjenu. Najrairenija open-source rjeenja za medijaciju su [7]: 20
1. AgileBill - je puten kao komercijalni proizvod 2004, a zatim kao open-source od strane svog kreatora Tony Landis-a 2008. AgileBill je aplikacija za naplatu i obraunavanje pogodna za poslovne modele tipa lanstvo/pretplata, ukljuujui Web hosting kompanije, ISP i VoIP pruatelje usluga. AgileBill ima dodatke za payment processing, Provisioning i povezivanje s third-party aplikacijama i uslugama. To je, takoer, dovelo do AgileVoice, AgileISP VoIP i ISP aplikacija za naplatu, respektivno. 2. Amberdms Billing System je sistem za naplatu koji takoer prua niz korisnih funkcija obrauna i poslovnog upravljanja. ABS ima aplikacije za fakturiranje, upravljanje uslugama, HR i vrijeme uvanja, a namijenjen je malim i srednjim poduzeima, kao i za male ISP i IT kompanije. Third-party integracija moe biti uinjena putem API-a i komercijalna podrka je dostupna od novozelandskih kompanija Amberdms. 3. Freeside je softver za naplatu, ticketing i automatski Provisioning, prilagoen za online tvrtke, ukljuujui i ISP, ITSPs, hosting i davatelje sadraja. Funkcionalnosti sistema za naplatu ukljuuje i real-time kontrolu kredita i e-potvrdnu obradu koristei popularne Payment Gateway-e, e-mail, fax, printano i online obraunavanje, kao i fleksibilan cijenovni i rating plan.
4. CitrusDB je sistem za naplatu razvijen s PHP i MySQL-om, koji se takoer moe koristiti za praenje informacija o korisnicima (CRM), uslugama, proizvodima, fakturama i kreditnim karticama, i informacijama o podrci. Cilj projekta je pruiti open-source rjeenje za CRM i sisteme za naplatu, koje se moe koristiti u mnogim razliitim uslunim djelatnostima kao to su ISP-ovi, savjetovanje i telekomunikacije. 5. Jbilling je web-bazirani sistem za naplatu razvijen u Javi. To je cross-platforma i podrava sisteme s vie baza podataka. Projekt tvrdi da moe skalirati "milion faktura", a moe se izvoditi na jednom serveru ili grupi specijaliziranih vorova. Ukljuuju automatsku generaciju faktura i Payment Processing. Detaljnije o jBilling-u dato je u treem dijelu rada.
21
3. Medijacija i jBilling
Enterprise jBilling Software je kanadska kompanija, locirana u gradu Vancouver, obalni grad smjeten u regiji Lower Mainlandu, u Britanskoj Kolumbiji. jBilling je standard za open-source softver za sisteme za naplatu. Uz poslovne mogunosti i robusnu arhitekturu, dobar je izbor za kompanije svih veliina. jBilling podrava od vrlo jednostavnih do vrlo sloenih zahtjeva sistema za naplatu. jBilling dolazi u etiri izdanja, ukljuujui Community, koji je besplatan, kao i Enterprise i Telco izdanja, koji imaju godinje naknade za licenciranje, podrku i odravanje. Ova izdanja daju takoer i izvorni kod, tako da je mogue zadrati potpunu kontrolu nad svojim rjeenjem za sistem za naplatu. Telco Hosted izdanje zahtjeva mjesene pretplate, ili godinju opciju koja nudi popust. Kao cloudbased rjeenje, Telco Hosted izdanje ne omoguava pristup izvornom kodu. Detalje o tome ta pruaju navedene verzije moe se pogledati na http://www.jbilling.com/features/compare-editions. U cilju prilagodbe jBilling-a osobnim zahtjevima sistema za naplatu, jBilling se integrie s Business Rules Management sistemom (BRMS). BRMS odrava pravila koja se izvode u produkciji sistema, ali takoer odrava repozitorij s korisnikim interfejsom pogodan kompanijama za kreiranje novih pravila, itanje, auriranje i brisanje istih. Glavne prednosti BRMS-a su: smanjiti ili ukloniti oslanjanje na IT odjele za promjene na ivim sistemima (to znai da za promjenu poslovnog pravila, ne treba promijeniti nikakav kod, to se sve ini kroz GUI ) i pojaana kontrola nad implementiranoj poslovnoj logici, za saglasno i bolje poslovno upravljanje. [8]2 Za realizaciju naeg projektnog zadatka koristit emo Community jBilling 3.0.2 release. Za razliku od prethodne Community verzije (jBilling 3.0.1), nije uveo nikakve dodatne funkcionalnosti ve je samo ispravio neke bug-ove. Ova verzija ukljuuje real-time medijaciju i sveobuhvatno upravljanje CDR-ovima u sluaju greki, zajedno s drugim poboljanjima. No, ova verzija jo uvijek ne prua sve funkcionalnosti sistema za upravljanje obraunom, poput podrke za vie procesa medijacije, poslovnih planova , specijalnih cijena i dr. Ova verzija jo uvijek slui kao osnova istraivaima u ovom polju.
3.1 jBilling arhitektura

jBilling arhitektura se sastoji od etiri odvojena dijela: Klijent obavlja sve interakcije s korisnikom (korisniki interfejs). Komunicira samo s serverom i nikad direktno s bazom podataka. Nema nikakvu poslovnu logiku. Glavni faktor ovog nivoa je Struts (http://struts.apache.org/). Ovo je implementacija paterna dizajna model-viewcontroller za web bazirane aplikacije pisane u Javi, tako da korisnici pristupaju sistemu koristei web preglednik, koji se spaja na web server gdje su JSPs (engl. JavaServer Pages) deploy-ane. Server je nositelj poslovne logike i jedino on moe da komunicira sa ostala tri nivoa. On prima zahtjeve od klijenta, te odgovara na njih tako to vri pokretanje nekog koda poslovne logike i/ili interakciju s bazom podataka. jBilling je Java EE aplikacija koje se oslanja na Spring Framework za poslovne usluge poput razgranienja na transakcijskim granicama,
2
Cjelokupan drugi dio rada je baziran na jBilling dokumentaciji preuzetoj s web stranice: http://www.jbilling.com/
22
integracija s Hibernate-om, JMS, itd. Sve to je potrebno je pokrenuti Java web server. Mogue je pokrenuti ga na bilo kojem aplikacijskom serveru, kao jednostavnu Java aplikaciju. Vano je napomenuti da je u poetku, jBilling pokretao kao EJB (engl. Enterprise Java Beans) aplikacija, koji se pokree samo na JBoss. jBilling je danas Spring aplikacija, ali njen poetak u EJB svijetu je ostavio 'oiljke' u kodu. Kljuni framework za koritenje su Spring i Hibernate, a standardno implemenitranje koristi Tomcat i ActiveMQ. Baza podataka je RDBMS (engl. Relational Database Management System) engine koja dri sve podatke. Zaduena je samo za uvanje podataka, ne uva procedure ili bilo koje druge vrste koda, a jo manje poslovnu logiku. Samo server ima pristup bazi podataka. U poetku, jBilling se pokretao na PostgreSQL, koji je prilino snaan i open-source. Vrlo lahko je pokrenuti jBilling na bilo kojoj drugoj maini, koja podrava ANSI SQL. Postoji nekoliko naina pristupa bazi podataka: kroz Hibernate persisted klase, Hibernate HQL queries, Hibernate criteria queries i preko JDBC poziva. Hibernate je preferirani nain za pristup bazi podataka. Business Rules Plug-ins vani su kod sistema za naplatu koji ele uvesti dodatna pravila plana obrauna. Dizajnirani su kao Java interfejsi. jBilling samo zna o postojanju tih interfejsa, a ne zna nita o njihovim stvarnim implementacijama.
3.2 Model baze podataka

jBilling_table sadri popis svih tabela unutar jBilling eme. Ova lista tabela se koristi za formiranje proizvoljnih asocijacija za bilo koju tabelu unutar sistema. Ovo je vano u nekim sluajevima poput jedinstvene translacijske tabele, jer bi bilo veoma kompleksno imati klju ogranienja za svaku moguu tabelu mapiranja u sistemu [10].
Sl.3. 1 Model baze podataka u jBilling-u [10]
Primjer jBilling_table je dat u nastavku. Id 10 14 21 Ime 'base_user' 'item' 'purchase_order' itd.

Tablica 3.1 Primjer jBilling_table [10]
23
Parametar international_description table_id pokazuje na jbilling_table id. Ovo omoguava mapiranje u ostale tabele unutar jBilling sistema. Ukoliko je vrijednost international_description parametra table_id=14, oznaava se opis reda za item. Ako se posmatra foreign key constraint, parametar table_id e se odnositi na tabelu kojoj se pridruuje, a parametar foreign_id e biti odgovarajui ID pridruene tabele. Na primjer, vrijednosti international_description parametara table_id=14 i foreign_id=100, oznaavaju opis reda za item sa ID vrijednou 100. Parametar international_description psudo_column je identifikator tekstualne vrijednosti. Svi opisi nisu oznaeni kao description, u nekim tabelama se umjesto toga koriste title ili name. Ovaj format tabela se koristi u jBilling-u, tako da je lahko izvriti identifikaciju pomou parametara table_id i foreign_id. 3.2.1 Korisnici
Korisnici su smjeteni u base_user tabeli. Korisnik moe da bude partner ili kupac, u zavisnosti od toga koju ulogu obavlja. Korisnik bez pridruene uloge kupca se smatra internim jBilling korisnikom, kao to je administrator ili slubenik.
Sl.3.2 Korisnici u jBilling bazi podataka [10]
Veina korisnika je opisana kontakt informacijama, koje su potrebne za naplatu. Meutim, ove informacije nisu direktno povezane sa base_user. Tabela kontakata je struktuirana tako da kontaktne
24
informacije mogu biti povezane sa bilo kojim record-om u bilo kojoj tabeli, kroz sistem. Trenutno, jBilling samo dozvoljava koritenje kontaktnih informacija kupaca.
Sl.3. 3 Kontaktne informacije kupca unutar baze podataka [10]
Moemo uoiti da contact_map tabela sadri sline osobine kao i international_description tabela navedena u prethodnom dijelu. Razlog za ovo je to to obje ove tabele koriste jbilling_table za mapiranje u ostale tabele unutar jBilling sheme, koje e se provoditi na isti nain.
25
Upravljanje TK mreama 3.2.2 Item-i
Svi item-i naloga unutar jBilling-a su smjeteni unutar item tabele. Cijena ovih item-a je smjetena u item_price tabeli, bez obzira na vrijednost cijene.
Sl.3. 4 Model Item-a u bazi podataka [10]
Item-i su okarakterisani tipom, koji je smjeten u item_type i item_type_map tabelama. Item-i mogu pripadati veem broju tipova. Tipovi su ad hoc organizacijski mehanizam, koji je koristan za kategorizaciju item-a za pravila ili logiku plug-in-a, na primjer, dodani porez ukoliko je u pitanju item poziv.
Sl.3. 5 Model item_type i item_type_map tabele [10]
Item-i su dodani na naloge ili raune kao linije (invoice_line ili order_line tabele) koristei ID item-a kao povratnu referencu. Kako se item-i mogu mijenjati tokom vremena, linije jBilling naloga i rauna uvijek imaju cijenu i opis. Podatke o item-ima jBilling koristi samo za postavljanje vrijednosti linija item_price i item_id. Ovo znai da linija uvjek pokazuje ta se tano naplauje, bez obzira na trenutne 26
promjene item-a (npr. promjene cijene, promjena opisa item-a, itd). Item-i ne sadre description polje. Svi tekstualni opis unutar jBilling-a dolaze iz tabele international_description. Opisi se sadre od vie detalja u jbilling_table i Textual Description dijelu. 3.2.3 Purchase Order
Kupovni nalozi (engl. Purchase order) predstavljaju sve trokove za kupce, ukljuujui pretplate i jednokratne kupovine. Kupovni nalozi se mogu kreirati runo kroz korisniki interfejs ili kroz proces medijacije nakon to se uitaju ulazni podaci u sistem.
Sl.3. 6 Model kupovni nalozi u jBilling bazi podataka[10]
Nalozi mogu imati nekoliko stanja, oznaenih u status_id koloni: Id 16 17 18 19 Status Aktivan, ovaj nalog moe generisati raune. Zavren, ovi trokovi naloga su ukljueni u obraun i nee se vie koristiti. Suspendiran, ovi nalozi nee genersati raune. Suspendiran-Star, nalog je suspendiran od strane procesa starenja (korisnik ima nepodmirene trokove).
Tablica 3.2 Stanja naloga [10]
27
Svaki nalog sadri skup linija naloga, gdje ove linije predstavljaju kvantitet item-a koji je kupljen na osnovu utvrene cijene. Cijena linije naloga moa biti drugaija od one u osnovnom item-u. jBilling osnovni item koristi samo za inicijalizaciju linije naloga, promjene cijene, popuste i druge dogaaje koji se javljaju nezavisno. Sami nalozi se ne plaaju, oni jednostavno predstavljaju trokove nastalih od strane kupca. Proces naplate periodino kreira raune (koji se plaaju) na osnovu kupovnog naloga korisnika. Ovo se moe pratiti putem order_process tabele, koja povezuje naloge sa raunima. 3.2.4 Rauni
Kao to se item-i koriste za kreiranje linija naloga, tako se i nalozi koriste za kreiranje rauna. Ne postoji direktna veza izmeu naloga i rauna, kao i izmeu order_line i invoice_line. Nalozi i rauni sadre mnogo istih podataka (plaen, obrisan, itd.) i ponavljajui nalozi mogu generisati vie rauna, te onda jBilling kopira podatke iz naloga u raun, prilikom kreiranja.
Sl.3. 7 Model rauna u jBilling bazi podataka [10]
Rauni ne predstavljaju uvijek trokove za jedan period. Ako raun za prethodni period nije plaen ili je samo djelimino plaen, preostali iznos je ukljuen u parametar carried_balance. U ovom sluaju, prethodni raun je oznaen kao carried, a novi raun predstavlja trenutno trokove koje korisnika treba da plati. Kao i nalozi, rauni mogu imati nekoliko stanja, oznaenih u status_id koloni: Id 26 27 28 Status Plaen Neplaen Neplaen i oznaen kao carried
Tablica 3.3 Stanja rauna [10]
28
Parametar balance predstavlja ukupan iznos za pojedini raun, ukljuujui i carried_balance. Kada se plati raun, iznos je smanjen na iznos za plaanje. Ukoliko je ukupan iznos jednak nuli, smatra se da je raun plaen. Uplate za raune se vre kroz payment_invoice tabelu. 3.2.5 Plaanja
Sl.3. 8 Modeli plaanja u jBilling bazi podataka [10]
jBilling podrava vie oblika plaanja: kreditnom karticom, automatic clearing house (ACH) direct bank transfers, i plaanje ekom. U veini sluajeva, nain plaanja je unaprijed odreen (ACH i kreditnom karticom), i plaanja se vre pomou odgovarajueg procesora plaanja. Najee se plaanje vri pomou kreditnih kartica ili ACH, a nakon to se izvri uplata preuzima se izvjetaj o uplati. Ukoliko je povratni izvjetaj uspjean, raun se smanjuje za iznos uplate.
29
Sl.3. 9 Model platnih naloga u jBilling bazi podataka [10]
U sluaju plaanja ekom, stvari funkcioniu malo drugaije. Kod plaanja ekom, prvo se kreira record plaanja, zatim se doda payment_info_check record, tako da izvor uplate moe biti praen. U svim sluajevima, record plaanja prikazuje tano koliko je plaeno, kada i od koga je plaeno. Openito, isplate su napravljene na raunu, meutim, to nije uvijek sluaj. Uplate se mogu vriti za cijeli raun, ostavljajui pozitivan iznos umjesto negativnog. U ovim sluajevima, jBilling e prvo pokuati primijeniti plaanje svih neplaenih rauna. Preostali iznos e se koristiti u sljedeem raunu, koji se generira. U tim sluajevima, mogu se vidjeti viestruki unosi u payment_invoice tabeli. Kreditne kartice i ACH plaanja e uvijek imati pridruen payment_authorization record. Autorizacija sadri sve detalje transakcije, ukljuujui kodove greaka, poruke odgovora i ostale detalje vraene od strane procesora plaanja. Detalji vezani za kreditne kartice su pohranjeni u credit_card tabelu u ifriranom obliku. Po default-u, broj kreditne kartice nikad nije dostupan u istom tekstu, samo kao ifrirani tekst.
30
Sl.3. 10 Model kreditne kartice u jBilling bazi podataka [10]
Mnogi gateway-i plaanja prevazilaze potrebu za pohranu broja kreditne kartice (ak i u ifriranom obliku), tj. pruaju ID transakcije ili ID pohrane, koji se mogu koristiti za budua plaanja kreditnom karticom, bez potrebe da se prolazi kroz sve detalje. jBilling pohranjuje ovu vrijednost kao gateway_key. Kada je poznat klju gateway-a, broj kreditne kartice je pohranjen kao zatamnjeni niz stringova, samo za svrhu prikaza (neto poput ***********1234). Svaki korisnik je mapiran sa kreditnom karticom kroz user_credit_card_map tabelu. 3.2.6 Medijacija
Medijacijski proces pohranjuje zapis svakog procesiranog dogaaja u mediation_record tabelu. Parametar mediation_record govori nam koji je zapis procesiran (id_key), kad je procesiran i ishod svakog pojedinog zapisa.
Sl.3. 11 Model medijacije u jBilling bazi podataka[10]
31
Zapisi se mogu nalaziti u nekoliko stanja oznaenih parametrom status_id: id 29 30 31 32 status Done and billable Done and not billable (no line was added) Error detected Error declared
Tablica 3.4 Stanja zapisa [10]
Svaki mediation_record, koji je dodan kao jedna linija naloga, ima pridruen mediation_record_line ulaz. Parametar mediation_record_line prikazuje koji item je dodan u liniju naloga i u kojoj koliini. Treba imati na umu da e order_lines istog item-a biti spojene zajedno u istu liniju. Ovo znai da e vie mediation_record_line unosa upuivati na istu order_line. Parametar mediation_record_line se moe posmatrati kao historijski zapis svih dogaaja koji ine medijacijski nalog.
3.3 Instalacija Community jBilling

Za instalaciju jBilling-a potreban je samo jedan uslov, a to je da ima instaliran JRE (engl. Java Run Environment). Potrebno je preuzeti posljednju verziju jBilling community 3.0.2 s web stranice: http://sourceforge.net/projects/jbilling/files/latest/download . Preuzeti binarni paket, a ne paket s izvornim kodom. Nakon download-a paketa, potrebno ga je raspakovati i konzolnom navigacijom pozicionirati se u raspakovani paket. Potom se treba pozicionirati u bin direktorij unutar raspakovanog paketa, omoguiti izvrivost svih fajlova s ekstenzijom .sh i pokrenuti jBilling pomou naredbi: chmod +x *.sh ./startup.sh Nakon toga treba otvoriti browser i unijeti sljedeu adresu: http://localhost:8080/jbilling/ , pojavit e se prozor kao na sljedeoj slici. Logovati se s LoginID='admin', password = '123qwe' i Company = 'Trend'.
32
Sl.3.12 jBilling web GUI
Verzija 3.0.2 jBilling community ima implementiran i Drools-Guvnor BRM unutar instalacije, tako da nije nita potrebno dodatno instalirati ve samo u browser unijeti adresu: http://localhost:8080/drools-guvnor/ i pojavit e se prozor kao na sljedeoj slici. Logovati se s username='admin' i password = '123qwe'.
Sl.3.13 BRM GUI
33
3.4 Medijacija u Community jBilling-u

Kako je navedeno u prvom dijelu postoje dva tipa medijacije: post-paid medijacija (pasivna) i realtime medijacija (aktivna. 3.4.1 Pasivna medijacija
Proces pasivne medijacije u jBilling-u predstavljena je na sljedeoj slici.
Sl.3.14 Pasivna medijacija [8]
1. Vanjski sistem prua uslugu korisniku. To je obino telefonski switch za telefonske pozive, ali to moe biti i bilo koji drugi sistem, poput web servera za posluivanje sadraja korisnicima interneta. 2. Vanjski sistem spaava zapise dogaaja s detaljima pruene usluge korisniku u bazu podataka. Baza je obino tekstualna datoteka, ali takoer moe biti RDBM baza ili drugi tipovi skladita. 3. Interni jBilling rasporeiva zapoinje medijacijski proces. To se dogaa periodino, obino jedanput dnevno. Proces medijacije e pronai konfigurirane plug-in-ove, koji posjeduju logiku o tome kako itati dogaaje i to uiniti s njima. Ova komponenta je 'orchestrator', tj. ne zna kako se izvrava ovaj proces. Za to se u potpunosti oslanja na plug-in-ove. Proces medijacije e itati konfiguracijske zapise. Svaki konfiguracijski zapis se pokazuje itatelju plug-ina. Proces onda zove svakog od ovih itaa plug-ina. 4. itata plug-ina zna itati dogaaje: njihov poloaj, format, kako podijeliti zapis u smislena polja podataka. Ipak, on je ogranien samo na itanje. itata ne zna znaenje polja tih podataka. 5. Grupa proitanih zapisa vraa se medijacijskom procesu kao Java objekti. 34
6. Medijacijski proces alje podatke o zapisu dogaaja procesoru plug-ina. 7. Procesor plug-in moe odluiti to e uiniti s zapisom. Standardna implementacija je plug-in na bazi pravila. To znai da e se koristiti BRMS za obradu dogaaja. Ovaj korak daje smisao podacima. Ovo je mjesto gdje se polja zapisa pretvaraju u jedinice, ili u datum, ili pak da se identificira subjekat, u sistemu za naplatu, koji plaa ovaj dogaaj. 8. Procesor vraa procesu medijacije podatke u obliku pogodnom za itanje tj. identifikacija predmet prodaje, vrijeme zbivanja dogaaja i korisnika koji uestvuje u dogaaju. 9. Proces medijacije sada moe napraviti jednostavan zahtjev jBilling jezgri za stvaranje ili auriranje naloga. Ovaj posljednji korak omoguava sistemu za naplatu da aurira svoju bazu podataka u skladu s aktivnou koju je korisnik uinio u interakciji s vanjskim sistemom u prvom koraku. 3.4.2 Aktivna medijacija
Aktivna medijacija se prvenstveno odnosi na real-time sisteme za naplatu, odnosno na pre-paid korisnike. U ovom sluaju zapisi se ne pohranjuju. Umjesto toga, oni se alju sistemu za naplatu u trenutku kada se dogode. Na slici ispod data je ilustracija osnovog toka procesa medijacije u jBillingu. itatai plug-ina imaju samo zadatak da proitaju zapise od vanjskog sistema i da ih spreme. Ako to nije potrebno, onda nisu potrebni itatai plug-in-a. Vanjski sistem zove jBilling svaki put kada se desi dogaaj (ili e se dogoditi). Real-time poziv se obavlja pomou standardnog jBilling API (obino koristi SOAP kao protokol). Postoje odreene metode u API-ju koje omoguuju obradu dogaaja procesom medijacije. Vano je napomenuti da sam proces medijacije nije svjestan kako se zapisi dostavljaju na njega. On ne zna da li zapisi dolaze iz datoteke koja je proitana od strane itaa, ili su doli kroz API u stvarnom vremenu. To je vano, zbog injenice da se ne mjenja konfiguracija medijacije, bez obzira na mehanizam isporuke CDR-a ili izvora CDR-a. Ovo omoguava dranje oba tipa medijacija na jednom mjestu.
Sl.3.15 Aktivna medijacija [8]
35
3.5 Opis testnog scenarija

U cilju detaljnog opisa konfiguracije medijacijskog procesa u jBilling-u, iskoristit emo jedan od tarifnih modela kompanije BH Telecom-a. Uzet emo paket Student Plus 1 uz cijenu mjesene naknade od 10 KM. Cjelokupan iznos mjesene naknade se prebacuje na pre-paid raun i na raspolaganju je korisniku za sve vrste saobraaja/usluga koje se plaaju kroz pre-paid raun. Ovaj paket ukljuuje: 1000 besplatnih minuta prema brojevima iz BH Mobile mree, uz naplatu uspostave poziva (0,06 KM); 250 MB mobilnog Internet saobraaja na flat principu; unutar BH Mobile mree i prema drugim mobilnim mreama u BiH po cijeni od 0,20 KM/min za pozive iznad ukljuenih 1000 minuta; prema fiksnim mreama unutar BiH po cijeni od samo 0,12 KM/min za pozive iznad ukljuenih 1000 minuta; cijena SMS-a unutar BiH iznosi 0,06 KM po poruci, a za pretplatnike ovog paketa samo 0,03 KM; cijena koritenja Interneta je 0.18 KM/MB.3
3.6 Realizacija testnog scenarija

Medijacijski proces omoguava jBilling-u da proita zapise o dogaajima iz vanjskog izvora, koji ih transformie u oblik pogodan za obraunavanje. Kroz ovo poglavlje opisat e se svi koraci pri konfiguraciji medijacije uz pridravanje vlastitog poslovnog plana. 3.6.1 Medijacijski proces
Medijacijski proces se moe podijeliti na tri razliite komponente: itata, medijacijski format i set pravila. Medijacijski itata je plug-in ija je svrha itanje podataka s vanjskog izvora. U jBiling-u postoje SeparatorFileReader za polja ograniena na tekstualnim fajlovima, FixedFileReader za zapise fiksne duine, JDBCReader za itanje iz baze podataka i MySQLReader koji prua jednostavnu konfiguraciju za MySQL baze podataka. Medijacijski format definira dolazee podatke, tako da se mogu parsirati i konvertovati u interni format. Konfiguracija plug-ina medijacijskog itatelja uzima format kao parametar. Definicija medijacijskog formata kontrolira koje informacije imamo na raspolaganju prilikom procesiranja pravila.
U radu smo poistovjetili Ameriki dolar s Konvertibilnim Markama KM, jer ve kreirana kompanija Trend po default-u koristi ovu valutu.
36
Posao dodavanja medijacijskih dogaaja u jBilling, kao naplatnih elemenata pripada setu medijacijskih pravila i drugih pravila baziranih na plug-in-ima. itata i definicija medijacijskog formata predstavljaju izvor podataka, dok set pravila predstavlja parser tih podataka. Medijacijski proces nije samo skup specifinih medijacijskih paketa pravila, on takoer aktivira item management i pravila cjenovnika. Na taj nain, omogueno je da se kompletna poslovna logika i pravila cjenovnika primjene na korisnike naloge. Medijacijski format prihvaa paket pravila i izvrava ih istovremeno. Iako izgleda kao asinhron pristup, realnost je drugaija, tj. pravila se uvijek izvravaju u predvidljivom slijedu. Ovo je mogue zbog injenice da item pravila ovise od identifikatora korisnikog naloga i ne izvravaju se dok ih medijacija ne doda u liniju naloga. Pravila cjenovnika se ne izvravaju sve dok se ne poalje zahtjev za njima (slika 3.16).
Sl.3.16 Veza medijacija-item pravila-cjenovnik [8]
3.6.2
Defincija medijacijskog formata
Svi itatai plug-in-i prihvataju medijacijski format definiran kao XML file koji opisuje dolazee podatke (dogaaje). Medijacijski XML format mora biti u skladu s fajlom mediation.dtd koji se nalazi u direkoriju /jbilling/resource/mediation/, dok njegov sastav moe biti korisniki definiran. Medijacijski format je opisan preko <format> taga, a sadri jednu ili vie <field> sekcija. Svaka <field> sekcija definira dio podataka koji e biti parsiran od dolazeih podataka. <field> elementi mogu sadravati sljedee child elemente: <name>#CDATA</name> - ime parsiranog elementa; <type>(string|integer|float|date)</type> - tip podataka sadranih u ovom polju; <startPosition>#CDATA</startPosition> - poetna pozicija u polju, koristi se za odabir podniza i dostupna je samo za formate s fiksnom duinom; <length>#CDATA</length> - broj karaktera ukljuenih u ovo polje poinjui od startPosition, dostupan samo za formate s fiksnom duinom; <durationFormat>#CDATA</durationFormat> - specificira format vremena koji se koristi za konvertovanje cjelobrojne vrijednosti u vremensku oznaku HHMMSS (npr. 013059 se konvertuje u 1 sat 30 minuta i 59 sekundi);
37
<isKey/> - oznaava polje kao dio jedinstvenog kljua koji identificira zapis koji se ita. Key polje se koristi kako bi se odredio nain procesiranja zapisa dogaaja. Ovo polje je obavezno i doputa jBilling-u filtriranje duplikata. Ako se vie polja oznai kao <isKey/> elementa, jBilling e grupirati sva ta polja u kompozitni Key.
Kako paket Student Plus 1 ukljuuje tri razliita tipa usluga, potrebno je formirati zaseban XML fajl za svaku od tih usluga. CallFormatCDR.xml opisuje format za obradu poziva, SMSFormatCDR.xml opisuje nain parsiranja SMS dogaaja, a InternetFormatCDR.xml nain parisanja Internet dogaaja. Ovi fajlovi dati su u prilogu. Izgled XML fajla CallFormat.xml je sljedei: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE format SYSTEM "mediation.dtd" > <format> <field> <name>event_id</name> <type>string</type> <isKey/> </field> <field> <name>event_date</name> <type>date</type> </field> <field> <name>username</name> <type>string</type> </field> <field> <name>calling_number</name> <type>string</type> </field> <field> <name>called_number</name> <type>string</type> </field> <field> <name>item_number</name> <type>string</type> </field> <field> <name>duration</name> <type>integer</type> 38
Upravljanje TK mreama </field> </format>
Kao Key elemenat definisali smo event_id. Za polje Duration se pretpostavlja da ima vrijednost u minutama. Zapisi dogaaja od vanjskog izvora su zapisani kao .csv fajlovi, bazirajui se na XML formatu zapisa. Npr. zapis kao: 01,20111129-121559,ErmaP,061/956-423,062/528-032,SP-3,120 e biti tretiran kao: event_id=01, event_date = 29.11.2011.god. 12h 15min 59s (tip ovog elementa je Date, koji je unutar jBilling-a definisan preko sljedea dva formata YYYYMMDD ili YYYYMMDD-HHmmss), username=ErmaP, calling_number=061/956-423, called_number=062/528-032, item_number=SP-3, duration=120 min. 3.6.3 ita plug-in
ita plug-in je djelimino razliit od drugih jBilling plug-in-a. Kao prvo, ne zanima ga ta predstavljaju zapisi koje procesira. Kao drugo, jBilling ne ulazi u samu konfiguraciju itaa kao to je sluaj s drugim plug-in-ima. On samo kroz konfiguraciju medijacije odreuje koji e se ita koristiti za procesiranje zapisa dogaaja. Ovo omoguava da imamo vie medijacijskih konfiguracija sa zasebnim itaima, to moe biti vrlo korisno ako postoji nekoliko izvora dogaaja. Za konfiguraciju medijacije potreban je ID plug-in itaa. Na ovaj nain, medijacijski proces zna koju klasu pozvati kod itanja zapisa. U jBilling-u veza izmeu konfiguracije medijacije i itaa je jedan na jedan i ako je potrebno definisati vie itaa onda je neophodno kreirati i vie konfiguracija medijacije. Kao ita, mi smo koristili SeparatorFileReader. Za odabir itaa potrebno je kliknuti na Configuration, zatim u lijevom dijelu prozora kliknuti na Plug-ins, u listi pronai Plug-in Mediation Reader com.sapienter.jbilling.server.mediation.task.SeparatorFileReader, kliknuti na njega i onda na button Add new za kreiranje novog itaa, pojavit e se prozor kao na sljedeoj slici.
39
Sl.3.17 Kreiranje ita plug-ina i njegovih parametara
Kao to je ve reeno, SeparatorFileReader ita tekstualne fajlove, gdje su polja odvojena stringom, po default-u se podrazumjeva zarezom (,). Polje Order odreuje prioritet itaa, tj. ako postoji vie itaa, a prvo e itati onaj ita s manjom Order vrijednou. Ovaj ita kao parametre koristi: format_file je jedino obavezan parametar, oznaava format zapisa dogaaja od vanjskog izvora i lokacija ovog fajla je po default-u u /jbilling/resource/mediation/; suffix odnosi se na csv fajlove koje e ita itati. Ako se eli dozvoliti itanje svih csv fajlova u default-nom direktoriju, onda se ovaj parametar postavlja na .csv; rename je boolean parametar, koji ako je je postavljen na true uzorkuje da ita promjeni ime fajla s zapisima o dogaajima s .csv na .done sufiks.
Ostali opcionalni parametri su: format_directory oznaava lokaciju fajla formata zapisa dogaaja; dateFormat definira format koji ita koristi za konvertovanje 'date' tipa u Java Date vrijednost. Prihvata formatiranje paterna koristei klasu JavaSimpleDataFormat. Default-ni format je yyyyMMdd-HHmmss; Separator oznaava karakter koji se koristi za razdvajanje polja, po default-u je zarez;
40
Batch_size odreuje broj zapisa koji se mogu itati u isto vrijeme za grupno procesiranje (default-na vrijednost je 100); buffer_size broj ili karakteri koje ita koristi za popunjavanje bafera svaki put kada pristupa fajlu (default-na vrijednost je 8192); removeQuote odnosi se na uklanjanje navodnika iz svakog polja. Ovo doputa da polja mogu imati zarez u svom sadraju; autoID je boolean paremater. Ako je postavljen na true, ita e dodjeliti svim zapisima vrijednost Key polja.
Bazirajui se na navedenim koracima, kreirali smo tri itaa za na poslovni plan koji su dati na sljedeoj slici. jBilling dodjeljuje ID svakom itau, koji e se pridruiti odgovarajuem procesu medijacije.
Sl.3.18 Kreirani itai plug-in-a
3.6.4
Konfiguracija medijacije
Konfiguracija medijacije govori procesu medijacije gdje su smjeteni zapisi dogaaja i kako da ih proita, pokazajui na plug-in koji zna kako obaviti ove zadatke. Potrebna je barem jedna konfiguracija medijacije da bi medijacijski proces uradio neto. Za upravljanje konfiguracijom medijacije potrebno je kliknuti na Configuration, potom u lijevom dijelu prozora na Mediation i u prozoru koji se pojavi upisati ime procesa medijacije i dodjeliti mu odgovarajui plug-in i kliknuti na dugme Save Changes, kao na slici 3.19.
41
Sl.3.19 Konfiguracija medijacije
ID se sistemski kreira. Kako bi procesirali pozive, Internet sadraj i SMS poruke, neophodno je kreirati tri konfiguracije. To podrazumjeva da su ta tri tipa dogaaja pohranjena u njihovim vlastitim fajlovima i formatima. Order broj pokazuje koja komponenta medijacije e se koristit prva. Plug-in ID pokazuje na itaa i ima istu vrijednost kao plug-ini koje smo kreirali. (Ovaj scenarij je mogu samo u Telco ili Telco Hosted verziji jBilling-a, koji nisu free dostupni na internetu. Iz tog razloga, u cilju realizacije naeg scenarija potrebno je kreirati tri jBilling aplikacije( tj. rapakovati skinuti jBilling zip fajl u tri razliite mape) i svakoj kreiranoj aplikaciji dodjeliti odgovarajuu konfiguraciju medijacije, drugim rijeima community verzija omoguava podrku za medijaciju samo za jedan tip usluge. U daljem radu mi emo opisivati nain na koji bi se na scenarij realizovao u Telco jBilling-u, dok e se oni dijelovi koji nisu podrani u community jBilling naglasiti.). Kada se doda konfiguracija medijacije, proces postaje iv. Medijacija se pokree na isti nain kao i ostatak serije procesa (billing, ageing, credit-control). Po default-u frekvencija pokretanja medijacijskog procesa je 720 minuta, no mi smo ovu frekvenciju podesili na 4 minuta. Podeavanje procesne frekvencije vri se editovanjem fajla jbilling.properties koji se nalazi u /jbilling/conf/ direktoriju. Dakle, vrijednost varijable process.frequency se postavlja na 4. Proces medijacije se pokree 4 minuta nakon to je sistem startovan i ponavlja se periodino svakih 4 minuta. Takoer, unutar ovog fajla podeava se proces pokretanja medijacije na true (tj. process.run_mediation=true, dok su ostali procesi postavljeni na false jer nisu relevantni za na zadatak).
42
Upravljanje TK mreama 3.6.5 Item management
Item-i predstavljaju katalog usluga i proizvoda koje nudi neka kompanija. To je mjesto gdje se usluge i proizvodi detaljno opisuju i gdje su navedene cijene. Item moe takoer biti promocija, kamata, provizija, porez ili bilo to drugo to faktura moe sadravati. Kreiranje item-a i itemkategorija je prvi zadatak koji se mora uraditi da bi izvrili set-up jBillinga. Za kreiranje nove kategorije produkta potrebno je kliknuti na Products, a potom na ikonu Add Category i dobije se izgled prozora kao na sljedeoj slici.
Sl.3.20 Kreiranje kategorije proizvoda/usluge
Name polje je obavezno. To je identifikacija koja se koristi za interno razlikovanje kategorija. Kao Type kategorije produkta moe se odabrati Items, Tax ili Penalty. Nakon kreiranja kategorije produkta, mogue je dodati nove proizvode u tu kategoriju. Klikom na odgovarajuu kategoriju, a potom u desnom donjem uglu na button Add Product otvorit e se prozor kao na sljedeoj slici.
43
Sl.3.21 Dodavanje novog proizvoda u odreenu kategoriju
Product ID se sistemski dodjeljuje. Product Code polje oznaava kod proizvoda. Ako su item-i jako vani za fakturu, moe se koristiti sljedei nain njihovog kodiranja. Ako elimo da se svi normalni item-i pojavljuju prvi, a potom svi popusti i provizije moemo iskoristiti oznaavanje item-a s prefiksima tako da se prefiks 'A' koristi za normalne item-e, 'B' za popuste i 'C' za poreze. Description je mjesto gdje se proizvod imenuje i kratko opisuje. Ime i opis eventualno mogu biti prikazani na raunu. Categories predstavlja selektovanje proizvoda s jednom od kreiranih kategorija. Excluded Categories predstavlja kategorije koje ne sadre ovaj produkt (ova opcija trenutno nije u funkciji u ovom release-u jBilling community). Line Precentage pokazuje dodatnu cjenu koja se dodaje na uslugu, izraunava kao postotak od ukupne cijene. Allow Manual Pricing odnosi se na dozvolu runog mjenjanja cijene usluge pri obraunavanju. Price oznaava cijenu usluge u United States Dollars jedinicama. Ako je ukljueno polje Precentage ovo polje mora biti prazno. Na sljedeoj slici je predstavljena lista proizvoda unutar kategorije Student Plus 1. ID svakog Item-a je vaan za pisanje pravila, to je objanjeno u nastavku. S obzirom da Student Plus 1 predstavlja poslovni plan, u Telco jBilling-u bi se kreirao Plan 'Student Plus 1' sa navedenim proizvodima, no u ovoj verziji ono to moemo uraditi jeste samo kreirati kategoriju proizvoda.
44
Sl.3.22 Lista usluga unutar Student Plus 1 kategorije
Plug-in konfiguriran za Trend kompaniju za Item Management je RulesItemManager2. Ovaj plug-in baziran na pravilima je ono to nam je potrebno, tako da nema potrebe za nekim modifikacijama. 3.6.6 Kreiranje novih korisnika
Korisnici su temelj svih informacija spremljenih i generisanih od strane jBilling-a. Oni kupuju proizvode i usluge, dakle, oni su primaoci rauna koje jBilling generie. Oni se loguju na jBilling da vide svoje raune, auriraju svoje kontakt informacije (adresu, broj telefona, itd.), mijenjaju svoje podatke o kreditnoj kartici, dostavi plaanja, itd. Podaci o korisnicima moraju biti uneeni u sistem, prije nego to ponete sa obavljanjem narudbe. Unos podataka o korisnicima je obino drugi korak u dobivanju jBilling set-up, odmah nakon to su uneseni item-i. Za svrhu implementacije naeg scenarija kreirat emo jednog korisnika, koji e biti pretplatnik paketa Student Plus 1, takoer koristit emo ve tri kreirana korisnika Penny Bright, Terry Wilson i Jenny Smith sa UserID 22, 12 i 2, respektivno. Za kreiranje korisnika potrebno je kliknuti na Customers pa na Add New. Nakon toga pojavit e se prozor kao na sljedeoj slici.
45
Sl.3.23 Kreiranje novog korisnika
Login Name/Password - ime i prezime za logovanje omoguava korisniku da dobije informaciju o svom obraunu. Ova informacija moe biti ukljuena na raunu koje se alje korisniku. E-mail - elektronski se adresira gdje e sve e-mail obavijesti za korisnika biti poslane. Ove e-mail adrese e biti dodjeljene korisnikovom primarnom kontaktu. Ovo polje je obavezno. Razlog zato je ovo polje tako vano u jBilling-u je zato to je sistem mnogo efikasniji kada korisnike moe lahko (i jeftino) kontaktirati, kako bi ih obavijestio o obraunskim dogaajima: novi obraun, podsjetnik obrauna, rezultat plaanja, itd. Currency - odabir eljene valute s kojom e ovaj korisnik da radi. Partner ID - ako je ovaj korisnik proglaen partnerom, potrebno je unijeti broj partnera ovdje. Parent ID - ako ovi korisnici pripadaju 'Parent Customer', unesite ID 'Parent Customer' ovdje. Ovo se odnosi na 'Sub-accounts'. Sub-accounts ukljuuje se jedino ako e ovaj korisnik imati podraune. Balance Type - oznaava tip korisnika pre-paid, post-paid, Credit Limit. Due Date odreuje vremenske trenutke slanja faktura jednom od selektovanih Invoice Delivery Method.
46
U desnom dijelu unose se kontaktne informacije za odreenog korisnika, koje mogu biti ukljuene u notifikacije. Lista korisnika sa njihovim ID-ovima, kao i osobine novog kreiranog korisnika dati su na sljedeim slikama.
Sl.3.24 Lista korisnika
Sl.3.25 Osobine novo-kreiranog korisnika
47
Sl.3.26 Dodavanje proizvoda paketa Student Plus 1 korisniku
Sl.3.27 Novo-kreirani korisnik i njegov raun

4
jBilling community ne podrava planove, te iz tog razloga nemogue je u ovoj verziji jBilling korisnika uiniti pretplatnikom paketa Student Plus 1. No, mi emo bez obzira na ovo napisati ItemManagement pravila kao da je to mogue, samo u cilju ilustracije kako to sve izgleda u onoj verziji jBilling-a koja podrava i planove, kao i istovremeno koritenje vie konfiguracija medijacije.
48
Bitno je primjetiti da je kod novog korisnika Erma Perenda, ukljuen flag Main Subscription. Znaenje ovog flaga je sljedee: za svaki dogaaj korisnik e dobiti po jedan raun, iako je ovo neefikasno u praksi, gdje se obino mjeseno kreira po jedan raun, odnosno svaki zapis dogaaja update-uje postojei raun. No, mi smo ovaj flag ukljuili iz razloga ilustracije kreiranja novih rauna. 3.6.7 Procesiranje s pravilima
U jednom trenutku medijacije, zapisi dogaaja su spremni za obradu. ita zapisa prua zapise dogaaja iz baze dogaaja, te se sada javlja potreba da se neto uradi sa ovim zapisima. Stoga, trebamo dati znaenja svim podacima koja dolaze kao polja svakog zapisa. Plug-in medijacijskog precesa se bazira na interfejsu IMediationProcess. Default-na implementacija ovog plug-ina je bazirana na pravilima. To znai da je stvarna logika onoga to plug-in radi proirena do poslovnih pravila upravljanih od strane Drools ureaja pravila. Medijacijski plug-in omoguava koritenje tri razliita tipa pravila: 1. 2. 3. Medijacijska pravila ine osnovnu interpretaciju sirovih podataka koji dolaze sa itaa. Item management pravila dijelovi sa planom, komponentom i pravilom. Pricing pravila pridruuju cijenu onim item-ima koji trebaju razliitu cijenu baziranu na nekim podacima prisutnim u CDR-u. Medijacijska pravila Kao ulaz, plug-in uzima zapis dogaaja (tip Record), te je sa ovog ulaza odgovoran za: Kreiranje jednog ili vie linija naloga sa item-ima i koliine onoga to korisnik koristi. Ovo je translacija sa zapisa dogaaja na stvarne item-e i koliine. Odreivanje jBilling korisnika. Dogaaj predstavlja akciju koja je uraena od strane korisnika. Drugim rijeima, koje naloge kupca treba aurirati? Odreivanje valute. Budui da je dogaaj obraen, jBilling treba da zna koja valuta se odnosi na korisnika. Odreivanje datuma dogaaja.
Kao to se moe vidjeti, odgovornosti ove komponente su osnova medijacijskog procesa. On preuzima zapise dogaaja bez ikakvog znaenja (samo povoljno pretvorenih u Java objekte pomou itaa) i na osnovu podataka iz zapisa, vri pretvaranje zapisa u oblik koji razumije sistem naplate. Plug-in nee aurirati nikakve naloge u informacijama o bilo kojem korisniku, ali e obezbjediti sve potrebne podatke za medijacijski proces, da to uini. Item management pravila Ova pravila su obino smjetena u posebnim paketima. Odnosno, grupisana su zajedno u BRMS-u ili u posebnoj datoteci. to omoguava koritenje ovog paketa kod item management plug-ina i sa medijacijskog plug-ina. Ova tehnika je vrlo korisna kada su potrebna ista pravila koja djeluju na medijacijski proces i ostale dijelove sistema, bez ponavljanja tih pravila u mnogim paketima. Pravila upravljanja item-ima djeluju na to kako se item-i odnose meusobno. Ona se mogu koristiti za 49
grupiranje item-a, zamjenu item-a sa drugim, te za druge akcije koje su potrebne za konfiguraciju planova i komponenti. Pricing pravila Ova pravila se obino nalaze u posebnom paketu pravila. Pozivaju se sa pricing plug-inima, kao i sa medijacijskim plug-in-ima. Sa ovim pravilima mogu se mijenjati cijene item-a. Ovo je vrlo vano kada default-na cijena ne vrijedi za zapis dogaaja koji se obrauje. Pravila emo pisati pomou Drools Guvnor GUI, pridravajui se njegovih pravila pisanja. Drools Guvnor e kompajlirati i uiniti dostupnim ova pravila jBilling-u, odnosno mogue je izvriti 'rules deployment'. Anatomija ovih pravila je jednostavno uslov s posljedicama tj. when #conditions then #actions Kljuna rije when oznaava uslove, a then akcije koje e se preduzeti u sluaju ispunjenja uslova. 3.6.7.1 Student Plus 1 plan i pravila Kako bi bolje razumjeli koja pravila je potrebno napisati, napravili smo dijagram toka koji je dat na sljedeoj slici. Na ovoj slici jasno se vidi koja pravila je potrebno napisati u okviru paketa Mediation, kao i paketa ItemManagement koji se nalaze u Knowledge Bases repozitoriju Drools Guvnor-a. Pricing pravila nije potrebno pisati jer ona e se primjeniti po default-u u skladu s cijenama odgovarajuih item-a. Potrebno je jedino napisati pravilo tipa Special Prices u okviru paketa ItemManagement, kada je u pitanju uspostava poziva prema mobilnim mreama u okviru 1000 besplatnih minuta.
50
Sl.3.28 Logika poslovnog plana
3.6.7.2 Koraci procesiranja zapisa dogaaja
Da bi se zapis dogaaja u potpunosti procesirao, moraju se proi neki koraci. Poevi od dodjele korisnika dogaajima, do auriranja korisnikog rauna. Neki koraci ukljuuju vie akcija:
51
Sl.3.29 Koraci za potpuno procesiranje zapisa dogaaja [8]
1. Start Proces zapoinje odreivanjem korisnika i datuma. Dodatna pravila za provjeru greaka u zapisu dogaajau pripadaju ovom koraku. 2. After User Korisnik je sada poznat. Valuta za ovaj dogaaj je postavljena. 3. Cuurent Order Trenutni nalog za korisnika i datum dogaaja su preuzeti. 4. Item Resolution Ovaj dogaaj je sada mapiran u jBilling item (proizvod). Opis dogaaja je takoer dodan u kasnijoj listi dogaaja u dijelu detalja rauna. 5. Pricing Ako dogaaj ne moe koristiti defalt-nu cijenu item-a, pravila koja mijenjaju ovu cijenu se aktiviraju u ovom koraku. 6. Item Management Planiranje bundles pravila. 7. Auriranje rauna Posljednji korak vodi brigu o auriranju korisnikog rauna, sa naplatama koje proizlaze iz dogaaja. MediationResult objekat jBilling prati rezultate za svaki zapis dogaaja kroz MediationResult objekat. MediatonResult objekat zna trenutni korak u kojem se nalazi zapis dogaaja i svaku informaciju koja se prikupila do sada. Na primjer, ako je zapis dogaaja u koraku 2, onda se moe pretpostaviti da je postavljen userId. Veina pravila teko da imaju interakciju sa ovim objektom. Ne trebaju se poznavati sva polja ovog objekta, ali je dobro upoznati se sa veinom od njih. U nastavku je dat jedan primjer ovog objekta za svaki zapis dogaaja koji treba da se procesira u memorijski sadraj:
52
Sl.3.30 Primjer MediationResult objekta [8]
Korak 1: Start Ovo je prvi korak. Rezultujui zapis dogaaja je uglavnom prazan, a cilj je da se postavi korisnik i datum. Ulazne varijable Rezultujui zapis dogaaja je popunjen samo sa podacima koji su poznati sistemu od samog poetka. Svako drugo polje je prazno: oni e biti popunjeni po pravilima. recordKey: jedinstveni identifikator zapisa dogaaja. On je postavljen od strane itaa plugina. configurationName: naziv konfiguracije medijacije. Ovo je korisno kada se javlja vie razliitih konfiguracija: SMS, glas, podaci, itd. Persist: boolean zastavica za indikaciju da li je zapis dogaaja stvarni zapis dogaaja koji treba da ostane ili ne. Ovo bi bilo neistinito u scenarijima gdje se poziva API metoda validatePurchase, koja koristi medijacijski modul za rjeavanje zapisa dogaaja, ali oni ne bi trebali mijenjati korisniki raun. Ovo se prevodi kao moe li korisnik ovo da kupi radije nego ovaj korisnik je kupio ovo. Za prvi sluaj vai da je persist=false, a za drugi da je persist=true. Izlazne varijable userId: ID korisnika kojem dogaaj pripada. eventDate: datum i vrijeme dogaanja ovog dogaaja. 53
Postavljanje userID: U Drools Guvnor GUI kliknuti na repozitorij Knowledge Bases, potom na Create New->New Rule i pojavit e se prozor kao na sljedeoj slici. Ime pravila postaviti na 'user setter', Inicijalna kategorija je 'configuration', tip pravila postaviti na DRL Rule (Technical rule - text editor) i paket Mediation.
Sl.3.31 Kreiranje pravila 'user setter'
U prozoru koji se otvori, napisati pravilo i kliknuti na Save Changes->Check In. Izgled napisanog pravila je kao na slici 3.21.
54
Sl.3.32 Anatomija pravila 'user setter'
Postavljanje eventDate: Na ve opisan nain kreirati novo pravilo 'date setter', iste kategorije i u istom paketu kao i pravilo 'user setter'. Anatomija ovog pravila je sljedea: dialect 'mvel' when $result : MediationResult(step == MediationResult.STEP_1_START, eventDate == null) $field : PricingField( name == "event_date", resultId == $result.id) then modify( $result ) { setEventDate( $field.getDateValue() ); } LOG.info("Day set to " + $result.getEventDate() + " record" + $result.getRecordKey()); Pravilo 'move step 1 to step 2': Nakon to je rijeeno postavljanje korisnikog ID i datuma dogaaja, moemo prei na drugi korak. Pravila koja opisuju prelaske s jednog koraka na drugi su ve definisana i nalaze se u Knowledge Bases/Mediation/Technical rule assets i ova pravila nije potrebno mijenjati za na testni scenarij. Anatomija pravila 'move step 1 to step 2' je sljedea: dialect 'mvel' when $result : MediationResult(step == MediationResult.STEP_1_START, 55
Upravljanje TK mreama userId != null, eventDate != null, currencyId == null)
# only one record for a given user at a time not( exists( MediationResult( $result.userId == userId, step > MediationResult.STEP_1_START) ) ) then modify( $result ) { setStep(MediationResult.STEP_2_AFTER_USER); } LOG.info("Transition from start to after user record" + $result.getRecordKey()); Korak 2: After User Kada znamo kome pripada zapis dogaaja i kada se isti desio, moemo da obavljamo bilo koji korak, koji zahtjeva zapis dogaaja. Po default-u, ovo je samo za postavljanje valute. Ulazne varijable: userId: ID korisnika kojem dogaaj pripada. eventDate: datum i vrijeme dogaanja ovog dogaaja. Izlazne varijable: currencyId: valuta na osnovu koje e se vriti naplata ovog dogaaj.
Pravilo za postavljanje valute, koje smo koristili u naem scenariju ima sljedei izgled: dialect 'mvel' when $result : MediationResult(step == MediationResult.STEP_2_AFTER_USER, currencyId == null) then modify( $result ) { setCurrencyId( getDefaultCurrency($result.getUserId()) ); } LOG.info("The currency was set to " + $result.getCurrencyId() + " record" + $result.getRecordKey()); Izgled pravila ' move step 2 to step 3' je sljedei: dialect 'mvel' when $result : MediationResult(step == MediationResult.STEP_2_AFTER_USER, currencyId != null, currentOrder == null)
56
then modify( $result ) { setStep(MediationResult.STEP_3_CURRENT_ORDER); } LOG.info("Transition from after user to current order record" + $result.getRecordKey()); Korak 3: Current Order Dohvaanje trenutnog naloga je obino korak koji se moe ignorisati. Ovaj korak se moe razmatrati kao unutarnji korak. Medijacijski proces sada treba da zna koji nalog da koristi prilikom dodavanja troka za dogaaj. Ulazne varijable: currencyId: valuta na osnovu koje e se vriti naplata ovog dogaaja. Izlazne varijable: currentOrder: nalog koji e jednom primiti trokove, dolazi od ovog dogaaja.
Kod za pravilo 'move step 3 to step 4' se nalazi u direktoriju knowlegde_bases/mediation i za potrebe naeg scenarija, nije ga potrebno mijenjati. Korak 4: Item resolution Item resolution je osnova medijacijskog procesa. Ovo je mjesto gdje se vri mapiranje CDR-ova u format poznat sistemu za naplatu. Dok ostali koraci u medijacijskom procesu zahtjevaju malo rada, ovaj korak je onaj gdje se koristi stvarna logika koju sistem treba da prati. Ulazne varijable: currentOrder: Nalog koji e jednom primiti trokove, dolazi od ovog dogaaja. Izlazne varijable: lines: popis treba da dobije nove linije naloga. Svaka nova linija naloga e imati item i quantity. Ovo je sr onoga to medijacijski proces treba da uradi: mapiranje dogaaja u item, koji je predstavljen kao linija naloga u jBilling-u. step: umjesto koritenja pravila prelaska, step je obino postavljen u then dijelu pravila na step 5. New pricing request Ovo nije varijabla postavljena u MediationResult objektu, ve zahtjev za novom cijenom koji moe zatrebati ubacivanjem objekta u memorijski sadraj. description: objanjenje trokova koji dolaze sa dogaaja (opcionalno).
MediationResult objekat sadri popis linija naloga koje se odnose na item-e koritene od korisnika. Ovo znai da treba kreirati instancu objekta OrderLineDTO() popunjenu sa informacijama o koritenju. Funkcija za dodavanje novih linija naloga je: function OrderLineDTO newLine(Integer itemId, BigDecimal quantity) { 57
Upravljanje TK mreama OrderLineDTO line = new OrderLineDTO(); Line.setItemId(itemId); line.setQuantity(quantity); line.setDefaults(); return line; }
Dogaaj se obino mapira u jedan item, ali i ne mora. To je razlog zato je varijabla lines zapisa dogaaja List. Primjer koritenja navedene funkcije u pravilu 'Resolve 1000 besplatnih minuta', koja koristi polje 'duration' iz CDR-a na proizvodu/itemu iji je ID 2200 je dat u nastavku. Takoer, slino ovom pravilu kreirana su i sljedea pravila: 'Resolve Pozivi prema mobilnim mrezama', 'Resolve Pozivi prema fiksnim mrezama', 'Resolve SMS', 'Resolve SMS za pretplatnike', 'Resolve Internet', 'Resolve Interent free 250 MB'. Sva ova pravila nalaze se u paketu Mediation, i pripadaju kategoriji Product i data su u prilogu. dialect 'java' when $result : MediationResult( step == MediationResult.STEP_4_RESOLVE_ITEM ) $quantity : PricingField( name == "duration", resultId == $result.id) PricingField( name == "item_number", value == "SP-1", resultId == $result.id) # ensure that we haven't added it yet not ( OrderLineDTO( itemId == 2200 ) from $result.lines ) then $result.getLines().add(newLine(2200, new BigDecimal($quantity.getIntValue()))); update( $result ); PricingResult request = priceRequest(2200, $result); insert( request ); LOG.info("Resolve 1000 besplatnih minuta i poslat zahtjev za naplatu" + $result.getRecordKey()); Vaan dio ovog pravila je da vrijednost Pricing polja 'quantity' se postavlja direktno na vrijednosti 'duration' polja CDR. Pravila pretpostavljaju da se ovo postavljanje vri za svaki CDR iji je itemID 2200. Pravilo prelaska sa koraka 4 na korak 5 ne zahtjeva posebno razmiljanje. Prvi faktor je da svi CDR-ovi ne trebaju pricing korak, jer se u nekim sluajevima primjenjuje defalt-na cijena. Drugi faktor je ako 58
elite da se pricing pravila koriste ne samo u procesu medijacije, nego i od strane drugih podruja sistema (kao to je poziv prema API-ju prilikom kreiranja naloga). Ovo znai da pricing pravila ne koriste MediationResult objekat u potpunosti. Ova pravila e se pokrenuti kada se detektuje PricingRequest i uveliko odredi nalog koristei propuste (drools atribut). Zadnje, ali ne i manje vano, ako postoji samo jedno pravila za mapiranje zapisa dogaaja u item ID, onda je jednostavno i lagano izvriti sljedei korak tamo. Meutim, ovo nije dobra opcija ako postoji vie pravila mapiranja. Korak 5: Pricing Ovo je opcionalni korak, koji je potreban kada defalt-na cijena item-a treba da se promijeni zavisno od podataka koji dolaze u CDR-u. Ovaj korak je poseban, jer je formiranje cijena obavljeno u drugim dijelovima jBilling-a, a ne samo kada se izvrava medijacija. Budui da je objekat MediationResult samo za medijaciju, pricing korak obino ne zavisi od tog objekta. Pricing se obavlja koritenjem PricingResult objekta. Zahtjev za cijenom se trai dodavanjem instance PricingResult objekta memorijskom sadraju, a onda se preuzima cijena sa objekta za promjenu cijene linije naloga, koja se doda u prethodnom koraku. Ulazne varijable: Nije primjenjivo: MediationResult nije ukljuen. Izlazne varijable: Nije primjenjivo: MediationResult nije ukljuen.
Pricing pravila se primjenuju sa viim prioritetom u odnosu na pravila koja pridruuju cijenu za to. Primjer dodjele nove cijene je: rule 'price assignment' when $result : MediationResult(step < MediationResult.STEP_6_ITEM_MANAGEMENT) $price : PricingResult( pricingFieldsResultId == $result.id, price != null ) $line : OrderLineDTO( itemId == $price.itemId) from $result.lines then $line.setPrice( $price.getPrice() ); update( $result ); end Pravilo prelaska sa koraka 5 na korak 6 je veoma jednostavno i uglavnom se oslanja na prioritet pravila: rule "from pricing to item" salience -10 # has to run after the pricing rules had a chance of # setting the price when $result : MediationResult(step == MediationResult.STEP_5_PRICING) 59
PricingResult(pricingFieldsResultId == $result.id ) # probably not needed then modify( $result ) { setStep(MediationResult.STEP_6_ITEM_MANAGEMENT); } end Korak 6: Item management Ovaj korak je slian prethodnom koraku po tome da pravila koja obavlja item management obino pripadaju razliitim paketima pravila, jer oni su takoer potrebni za akcije kao to su kreiranje naloga sa API-ja. Kako god, rezultujui objekat se modificira u ovom koraku. Kada zapone korak 6, napokon imamo definisan produkt, kvanitet toga to je kupljeno i cijenu. Dakle, sada je vrijeme za promjenu trenutnog naloga u skladu s tim. Nakon toga, trebat e standardna item management pravila koja vode rauna o planovima koji se trebaju izvriti. Ulazne varijable: lines: sa linijama naloga tano postavljenih: item ID, quantity, cijena. Izlazne varijable: oldLines: ovo bi trebalo da sadri linije trenutnih naloga, kao to su bile prije ikakvih promjena koje su dole proceciranjem dogaaja. CurrentOrder: trenutni nalog treba biti promijenjen, dodavanjem linije ili dodavanjem quantity postojeim linijama sa trokovima koji dolaze sa ovim CDR-om.
Kod za korak 6 postoji po default-u i nije ga potrebno mijenjati. Za razliku od pravila medijacije, item management pravilima rukovode poslovni korisnici. Ova pravila su apstraktna za dogaaje, ona su neki vid poslovnih uslova. Naprimjer, ako imamo neki poziv prema mobilnoj mrei, potrebno je provjeriti da li je korisnik pretplatnik paketa Student Plus 1 i ako jeste onda treba da se ovom korisniku dodjeli item ' 1000 besplatnih minuta' ako ih ve nije potroio. Anatomija pravila '1000 jos nepotrosenih minuta' koji ovo implementira je: rule: 1000 jos nepotrosenih minuta when $order : OrderDTO( ) $line : OrderLineDTO( itemId == 2202, $quantity : quantity ) from $order.lines SubscriptionResult( userId == $order.userId, itemId == 2200, subscribed == true ) $pricing : PricingResult(userId == $order.userId, itemId == 2200) then $order.getLines().remove($line); OrderLineBL.addItem($order, 2200, new Integer($quantity.intValue()), $pricing.getPrice()); 60
Upravljanje TK mreama update($order);
LOG.debug("Potroseno je od" + $quantity + " minuta od 1000"); U sluaju da imamo item '1000 besplatnih minuta', a korisnik je ve potroio te minute onda je potrebno na korisniki raun primjeniti cijenu itema 'Pozivi prema mobilnim mreama'. Nain na koji je to uraeno pomou BRMS-a je sljedei: rule: 1000 potrosenih minuta when $order : OrderDTO( ) $line : OrderLineDTO( quantity.intValue > 1000, itemId == 2200, $quantity : quantity) from $order.lines $pricing : PricingResult(userId == $order.userId, itemId == 2202) then OrderLineBL.addItem($order, 2202, new Integer($quantity.intValue() - 1000), $pricing.getPrice()); update($order); $line.setQuantity(1000); LOG.debug("1000 minuta je potroseno.");
Vodei se istom logikom, napisana su pravila '250 MB jos nepotroseno' i '250 MB potroseno'. rule: 250 MB jos nepotroseno when $order : OrderDTO( ) $line : OrderLineDTO( itemId == 2206, $quantity : quantity ) from $order.lines SubscriptionResult( userId == $order.userId, itemId == 2205, subscribed == true ) $pricing : PricingResult(userId == $order.userId, itemId == 2205) then $order.getLines().remove($line); OrderLineBL.addItem($order, 2205, new Integer($quantity.intValue()), $pricing.getPrice()); update($order); LOG.debug("Potroseno je " + $quantity + " MB od 250 MB.");
rule: 250 MB potroseno when 61
$order : OrderDTO( ) $line : OrderLineDTO( quantity.intValue > 250, itemId == 2205, $quantity : quantity) from $order.lines $pricing : PricingResult(userId == $order.userId, itemId == 2206) then OrderLineBL.addItem($order, 2206, new Integer($quantity.intValue() - 250), $pricing.getPrice()); update($order); $line.setQuantity(250); LOG.debug("250 MB je potroseno."); Ova pravila se kreiraju unutar paketa ItemManagement, kategorija Plans i tip DRL Rule (Technical rule-text editor). Takoer, unutar ovog paketa kreirano je i pravilo za naplatu uspostave veze kod itema '1000 besplatnih minuta'. Ovo pravilo pripada kategoriji Special Prices i njegova anatomija je sljedea: rule: Uspostava poziva when result : PricingResult( itemId == 2200, price == null ) then result.setPrice( "0.06" ); update( result ); Korak 7: Account Update Posljednji korak jeste auriranje korisnikog rauna. U ovom koraku se takoer vri usporedba naloga prije i poslije dogaaja, i ova informacija se uva kao dio historije naloga. Ovo je korak koji obino ne mora napraviti nikakve promjene standardnih jBilling pravila. Ovo pravilo pripada klasi unutarnjih pravila. Ulazne varijable: currentOrder: kompletirano sa svim novim trokovima. Izlazne varijable: done: sada postavljeno na true. diffLines: rezultat poreenja izmeu starog i novog naloga.
Kod za korak 7 postoji po default-u i nije ga potrebno mijenjati. Sada moemo rezimirati, kako se sve uklapa zajedno: ita plug-ina ita .csv fajlove,
62
Primjenjuje se medijacijski format, pri emu se svaki red pretvara u skup PricingField objekata, gdje svaki objekat predstavlja polje u skladu sa medijacijskim formatom. Skup PricingField objekata prolazi kroz RulesMediationTask, gdje je skup grupisan sa MediationResult objektom, koristei zajedniki ID. Rezultati medijacije
3.6.8
Nakon zavretka medijacijskog procesa, dostupni su rezultati o tome ta se desilo sa svakim CDRom, koji se procesirao. Postoji nekoliko ishoda: zapisi proizvode neke trokove za korisnike, ili moda sprjeavaju deavanje greaka. Zapise koji se javljaju s grekama e spremiti jBilling, tako da se moe postaviti automatizirani nain za njihovo reprocesiranje. Prvo, veoma je vano da se razumiju rezultati koje jBilling identificira. Ilustracija vanosti ovih rezultata data je kroz na scenarij. Procesiranjem sljedeeg Call.csv fajla: 1,20121130-161223,pbright,SP-3,062/456234,061/567-234,243 2,20121201-161223,pbright,SP-2,062/456234,061/567-234,243 3,20121202-161224,ErmaP,SP-3,062/456234,062/567-234,43 4,20121203-161223,pbright,SP-3,062/456234,062/567-234,243 5,20121203-181223,ErmaP,SP-3,062/456234,061/547-234,243 6,20121204-161223,ErmaP,SP-2,062/456234,061/557-234,243 7,20121205-171223,ErmaP,SP-3,062/456234,061/587-234,243 8,20121205-181223,ErmaP,SP-1,062/456234,062/567-234,243 9,20121205-191223,ErmaP,SP-1,062/456234,061/547-234,243 10,20121205-201223,ErmaP,SP-2,062/456234,061/557-234,243 11,20121205-211223,ErmaP,SP-3,062/456234,061/587-234,243 dobijene rezultate medijacije unutar jBilling GUI pokazuje sljedea slika:
Sl. 3.33 Rezultati medijacije dobijeni procesiranjem Call.csv fajla Ime procesa medijacije koji se pokree je Call Mediation, a njegov ID je 30. Rezultati medijacije su: 63
Broj proitanih (engl. Record Processed) dogaaja za pozive je 11 , Broj kreiranih rauna (engl. Orders Affected) je 11, Broj gotovih i naplaenih (engl. Done And Billable) dogaaja za poziv je 11. Ovo je tipini rezultat kojeg identificira jBilling: zapis dogaaja je uspjeno procesiran (svi koraci uspjeno izvedeni) i preveden je u naplatu za korisnika. Da bi se ovo izvrilo, done polje MediationResult objekta treba da bude postavljeno na vrijednosti true i lines polje treba da sadri neke linije. Broj gotovih i nenaplaenih (engl. Done And Not Billable) dogaaja za poziv je 0. Ovaj rezultat procesa medijacije kojeg identificira jBilling, daje broj uspjeno procesiranih dogaaja (done polje postavljeno na true), ali bez prisutnih linija. Tipian primjer ovoga je kada zapis dogaaja predstavlja dogaaj kojeg korisnik nee platiti, na primjer, poziv na koji se ne odgovori. Broj otkrivenih greaka (engl. Errors Detected) u CDR-ovima je 0. Ukoliko je proces medijacije zavren, a vrijednost done polja jednaka false, onda e jBilling smatrati da je upitanje CDR sa grekom. Uvijek bi trebalo imati pravila koja e razmatrati svaki zapis dogaaja i postavljati done polje na vrijednost true. Proces medijacije e pokuati da odredi razlog zato ovaj zapis dogaaja nije uspio, dodjeljujui mu kod. Nakon toga e se ovaj kod pohraniti sa cijelim zapisom dogaaja za ponovno procesiranje. Broj proglaenih greaka (engl. Errors Declared) je 0. Uvijek se tei tome da se posjeduju pravila koja e pokriti sve mogue situacije u kojima se moe nai zapis dogaaja. Ako postoji greka koja se moe detektovati, onda se moe pomou polja 'errors' u jBilling-u iz MediationResults odrediti kakva je greka u pitanju. Mogu se napraviti liste greaka, u kojima se one uvaju dok ne dou na red za reprocesiranje. To polje je niz stringova, tako da se moe dodati bilo koji broj greaka, koji e biti sauvan kada se greke spreme radi ponovnog procesiranja. Ne postoji granica u formatu ili broju greaka koje se mogu dodati. Samo te greke trebaju da imaju smisla. Greke koje rjeava jBilling koristei kod zapoinju sa JB, tako da greke koje mi unosimo trebaju da poinju sa neim drugim. jBilling e uzeti u obzir sve zapise dogaaja koji pripadaju kategoriji greke (otkrivena ili proglaena), oznaeni kao not processed. Ovo je vano da bi se sauvao zapis u kojem se javila greka, radi kasnijeg procesiranja, jer filter u jBilling-u se koristi da bi se izbjeglo procesiranje istog zapisa dva puta, pa bi se u sluaju ponovnog procesiranja zapisa, isti odbacio. Normalni tok rada se moe svesti na sljedee: pokretanje medijacijskog procesa, neki zapisi sadre greke, a neki ne, pregledaju se ovi zapisi sa grekama i ispravi se ono to je uzrokovalo problem, onda se proces medijacije pokrene ponovo samo za zapise u kojime se javila greka.
Kako je ve spomenuto za korisnika ErmaP oznaen je flag Main Subcription, kao i za korisnika pbright, pa prema tome treba da se generie jednak broj rauna kao i broj proitanih zapisa, to dokazuju sljedea slika. Na svaki raun primjenjena je taksa od 6%, tj. GST item kreirana od strane Trend kompanije.
64
Slika 3.34 Lista kreiranih rauna/order-a
Nakon zavretka procesa medijacije, ako se pogleda unutar direktorija jbilling/resources/mediation vidjet e se da je na Call.csv fajl dodana ekstenzija done tj. fajl se sada zove Call.csv.done. Takoer, pokretanjem SMS Mediation i Internet Mediation procesa s odgovarajuim SMS.csv i Internet.csv fajlovima dobit e se slini rezultati.
65
ZAKLJUAK
Upravljanje obraunom je backbone svakog telekom operatora. Ako operator nema jak sistem za upravljanje obraunom, nee biti u mogunosti da ponudi svoje usluge i proizvode sa atraktivnom cijenom i nee se moi izboriti na dananjem konkuretnom i dinaminom tritu. Medijacija igra veoma bitnu ulogu u sistemima za upravljanje obraunom, to je razlog zato joj mnogi proizvoai daju toliko panje, kako bi proizveli to efikasniji i sigurniji sistem za medijaciju operatorima, a samim tim i dobijanje konkurentske prednosti na tritu. S druge strane, mnogi vjeruju da e open-source rjeenja za medijaciju igrati sve vaniju ulogu u budunosti poslovnog softvera. Imajui izvorni kod, operator moe razviti dodatne funkcionalnosti da zadovolji svoje potrebe i ovim putem moe postii punu kontrolu sistema za naplatu. Proces medijacije ukljuuje izvravanje vie procesa koji nisu ba jednostavni. U ovom radu opisani su ti procesi, kao i nain na koji su oni implemenitrani unutar jednog od open-source rjeenja za medijaciju, jBilling. Na osnovu priloene analize procesa medijacije u ovom alatu, uoava se svrha i funkcija medijacije u cjelokupnom sistemu za obraun. Medijacijski ureaji su posrednike take izmeu korisnika s jedne strane i sistema za obraun s druge strane. Dakle, medijacijski ureaji su ureaji koji korisnikovo koritenje usluge mapiraju u prikladne zapise dogaaja, koje sistem za obraun koristi za izvrenje procesa naplate.
66
AKRONIMI
ASN.1 API CDR CRM ERP FTP GGSN IP ISP MSC MMSC MSS OMOF QoS TCP UDP UDR Abstract Syntax Notation One Application Programming Interface Call Detail Record Customer Relationship Management Enterprise Resource Planning File Transfer Protocol Gateway GPRS support node Internet Protocol Internet Service Provider Mobile Switching Center Multimedia Messaging Service Center Maximum Segment Size Order Management and Order Fulfillment Quality of Service Transmission Control Protocol User Datagram Protocol Usage Detail Record
67
LITERATURA
[1] Tomislav Grgi, Pregled sustava za tereenje telekomunikacijskih usluga u novoj generaciji mrea, Zavod za telekomunikacije, Fakultet elektrotehnike i raunarstva, Sveuilite u Zagrebu Web: http://www.tutorialspoint.com/telecom-billing/system-architecture.htm, pristup ostvaren 19.12.2012. god. Web: http://en.wikipedia.org/wiki/Billing_Mediation_Platform, pristup ostvaren 19.12.2012. god. Avi Ofrane, Harte, Lawrencem Introduction to Telecom Billing, Usage Events, CDR and Bill Cycles, 2003. Web: http://www.billingworld.com/articles/2004/06/mediation-systems-come-of-age.aspx#2 pristup ostvaren 19.12.2012. god. . Moini, G. Ivoevi, D. Turk, Razvoj sustava za nadzor i upravljanje,2004. Web: http://www.cio.com.au/article/324595/5_open_source_billing_systems_watch/, pristup ostvaren 19.12.2012. god. Web: http://www.jbilling.com/ , Telecom Guide, User Guide, pristup ostvaren 19.12.2012. god. Sohag Sarkar, Telecom Billing Solutions, Symbiosis Institute of Telecom Management, Pune. Web: http://www.jbilling.com/documentation/developers/database-model, pristup ostvaren 19.12.2012.god.
[2]
[3]
[4]
[5]
[6] [7]
[8] [9] [10]
68
Prilog
SMSFormatCDR.xml <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE format SYSTEM "mediation.dtd" > <format> <field> <name>event_id</name> <type>string</type> <isKey/> </field> <field> <name>event_date</name> <type>date</type> </field> <field> <name>username</name> <type>string</type> </field> <field> <name>item_number</name> <type>string</type> </field> <field> <name>quantity</name> <type>integer</type> </field> </format> InternetFormatCDR.xml <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE format SYSTEM "mediation.dtd" > <format> <field> <name>event_id</name> <type>string</type> <isKey/> 69
Upravljanje TK mreama </field> <field> <name>event_date</name> <type>date</type> </field> <field> <name>username</name> <type>string</type> </field> <field> <name>item_number</name> <type>string</type> </field> <field> <name>quantity</name> <type>integer</type> </field> </format> SMS.csv 22,20121130-161223,pbright,SP-4,3 23,20121202-141224,ErmaP,SP-5,5 24,20121203-101223,pbright,SP-4,6 25,20121203-121223,ErmaP,SP-4,7 26,20121204-151228,ErmaP,SP-5,2 27,20121201-161226,pbright,SP-4,2 Internet.csv 32,20121130-161223,pbright,SP-7,30 33,20121202-141224,ErmaP,SP-6,50 34,20121203-101223,pbright,SP-7,16 35,20121203-121223,ErmaP,SP-6,12.7 36,20121204-151228,ErmaP,SP-7,2.5 37,20121201-161226,pbright,SP-6,12
Sadraj paketa Mediation/Technical rule assests u Drool Guvnor Knowledge repozitoriju: Kategorija: Mediation/Product
Rule Resolve 1000 besplatnih minuta dialect 'java' when $result : MediationResult( step == MediationResult.STEP_4_RESOLVE_ITEM ) 70
$quantity : PricingField( name == "duration", resultId == $result.id) PricingField( name == "item_number", value == "SP-1", resultId == $result.id) # ensure that we haven't added it yet not ( OrderLineDTO( itemId == 2200 ) from $result.lines ) then $result.getLines().add(newLine(2200, new BigDecimal($quantity.getIntValue()))); update( $result ); PricingResult request = priceRequest(2200, $result); insert( request ); LOG.info("Resolve 1000 besplatnih minuta i poslat zahtjev za naplatu" + $result.getRecordKey()); Rule 'Resolve Internet free 250 MB' when $result : MediationResult( step == MediationResult.STEP_4_RESOLVE_ITEM ) $quantity : PricingField( name == "quantity", resultId == $result.id) PricingField( name == "item_number", value == "SP-6", resultId == $result.id) # ensure that we haven't added it yet not ( OrderLineDTO( itemId == 2205 ) from $result.lines ) then $result.getLines().add(newLine(2205, new BigDecimal($quantity.getIntValue()))); update( $result ); PricingResult request = priceRequest(2205, $result); insert( request ); LOG.info("Resolve Internet 250 MB flat rate i poslat zahtjev za naplatu" + $result.getRecordKey());
Rule Resolve Pozivi prema fiksnim mrezama when $result : MediationResult( step == MediationResult.STEP_4_RESOLVE_ITEM ) $quantity : PricingField( name == "duration", resultId == $result.id) PricingField( name == "item_number", value == "SP-2", resultId == $result.id) # ensure that we haven't added it yet 71
not ( OrderLineDTO( itemId == 2201 ) from $result.lines ) then $result.getLines().add(newLine(2201, new BigDecimal($quantity.getIntValue()))); update( $result ); PricingResult request = priceRequest(2201, $result); insert( request ); LOG.info("Resolve Pozivi $result.getRecordKey()); prema fiksnim mreama I poslat zahtjev za naplatu" +
Rule: Resolve Pozivi prema mobilnim mreama when $result : MediationResult( step == MediationResult.STEP_4_RESOLVE_ITEM ) $quantity : PricingField( name == "duration", resultId == $result.id) PricingField( name == "item_number", value == "SP-3", resultId == $result.id) # ensure that we haven't added it yet not ( OrderLineDTO( itemId == 2202 ) from $result.lines ) then $result.getLines().add(newLine(2202, new BigDecimal($quantity.getIntValue()))); update( $result ); PricingResult request = priceRequest(2202, $result); insert( request ); LOG.info("Resolve Pozivi prema mobilnim mreama I poslat zahtjev za naplatu" + $result.getRecordKey()); Rule:Resolve Internet when $result : MediationResult( step == MediationResult.STEP_4_RESOLVE_ITEM ) $quantity : PricingField( name == "quantity", resultId == $result.id) PricingField( name == "item_number", value == "SP-7", resultId == $result.id) # ensure that we haven't added it yet not ( OrderLineDTO( itemId == 2206 ) from $result.lines ) then 72
$result.getLines().add(newLine(2206, new BigDecimal($quantity.getIntValue()))); update( $result ); PricingResult request = priceRequest(2206, $result); insert( request ); LOG.info("Resolve Internet saobraaj I poslat zahtjev za naplatu" + $result.getRecordKey()); Rule: Reslove SMS
when $result : MediationResult( step == MediationResult.STEP_4_RESOLVE_ITEM ) $quantity : PricingField( name == "quantity", resultId == $result.id) PricingField( name == "item_number", value == "SP-4", resultId == $result.id) # ensure that we haven't added it yet not ( OrderLineDTO( itemId == 2203 ) from $result.lines ) then $result.getLines().add(newLine(2203, new BigDecimal($quantity.getIntValue()))); update( $result ); PricingResult request = priceRequest(2203, $result); insert( request ); LOG.info("Resolve SMS I poslat zahtjev za naplatu" + $result.getRecordKey());
Rule: Resolve SMS za pretplatnike when $result : MediationResult( step == MediationResult.STEP_4_RESOLVE_ITEM ) $quantity : PricingField( name == "quantity", resultId == $result.id) PricingField( name == "item_number", value == "SP-5", resultId == $result.id) # ensure that we haven't added it yet not ( OrderLineDTO( itemId == 2204 ) from $result.lines ) then $result.getLines().add(newLine(2204, new BigDecimal($quantity.getIntValue()))); update( $result ); 73
PricingResult request = priceRequest(2204, $result); insert( request ); LOG.info("Resolve SMS za pretplatnike I poslat zahtjev za naplatu" + $result.getRecordKey());
Sadraj paketa ItemManagement/Technical rule assests u Drool Guvnor Knowledge repozitoriju: Kategorija: Plans
Rule: 1000 jos ne potrosenih minuta when $order : OrderDTO( ) $line : OrderLineDTO( itemId == 2202, $quantity : quantity ) from $order.lines SubscriptionResult( userId == $order.userId, itemId == 2200, subscribed == true ) $pricing : PricingResult(userId == $order.userId, itemId == 2200) then $order.getLines().remove($line); OrderLineBL.addItem($order, 2200, new Integer($quantity.intValue()), $pricing.getPrice()); update($order); LOG.debug("Potroseno je od" + $quantity + " minuta od 1000");
Rule: 1000 minuta je potroseno when $order : OrderDTO( ) $line : OrderLineDTO( quantity.intValue > 1000, itemId == 2200, $quantity : quantity) from $order.lines $pricing : PricingResult(userId == $order.userId, itemId == 2202) then OrderLineBL.addItem($order, 2202, new Integer($quantity.intValue() - 1000), $pricing.getPrice()); update($order); $line.setQuantity(1000); LOG.debug("1000 minuta je potroseno.");
Rule:250 MB jo ne potroeno 74
when $order : OrderDTO( ) $line : OrderLineDTO( itemId == 2206, $quantity : quantity ) from $order.lines SubscriptionResult( userId == $order.userId, itemId == 2205, subscribed == true ) $pricing : PricingResult(userId == $order.userId, itemId == 2205) then $order.getLines().remove($line); OrderLineBL.addItem($order, 2205, new Integer($quantity.intValue()), $pricing.getPrice()); update($order); LOG.debug("Potroseno je " + $quantity + " MB od 250 MB."); Rule:250 MB je potroseno when $order : OrderDTO( ) $line : OrderLineDTO( quantity.intValue > 250, itemId == 2205, $quantity : quantity) from $order.lines $pricing : PricingResult(userId == $order.userId, itemId == 2206) then OrderLineBL.addItem($order, 2206, new Integer($quantity.intValue() - 250), $pricing.getPrice()); update($order); $line.setQuantity(250); LOG.debug("250 MB je potroseno.");
Rule: SMS za pretplatnike when $order : OrderDTO( ) $line : OrderLineDTO( itemId == 2203, $quantity : quantity ) from $order.lines SubscriptionResult( userId == $order.userId, itemId == 2204, subscribed == true ) $pricing : PricingResult(userId == $order.userId, itemId == 2205) then $order.getLines().remove($line); OrderLineBL.addItem($order, 2204, new Integer($quantity.intValue()), $pricing.getPrice()); update($order); 75
LOG.debug("Korisnik je pretplatnik); Kategorija: Special Prices
Rule: Uspostava poziva when result : PricingResult( itemId == 2200, price == null ) then result.setPrice( "0.06" ); update( result );
76

Ut M Proje KT Mediation

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ut M Proje KT Mediation

Uploaded by

Copyright:

Available Formats

UNIVERZITET U SARAJEVU ELEKTROTEHNIKI FAKULTET ODSJEK ZA TELEKOMUNIKACIJE

MEDIATION Medijacija u upravljanju obraunom

Projekt iz predmeta Upravljanje telekomunikacijskim mreama

Elbisa olak, Meliha Duli & Erma Perenda

MEDIATION - Medijacija u upravljanju obraunom

1.1.1 1.1.2 1.1.3 2.

2.5.1 2.5.2 2.6 2.7 3.

Aktivna i pasivna medijacija .................................................................................................. 18 Rjeenja za medijaciju ........................................................................................................... 18

3.2.1 3.2.2 3.2.3 3.2.4 3.2.5 3.2.6 3.3 3.4

3.4.1 3.4.2 3.5 3.6

Upravljanje TK mreama 3.6.2 3.6.3 3.6.4 3.6.5 3.6.6 3.6.7 3.6.8

MEDIATION - Medijacija u upravljanju obraunom

MEDIATION - Medijacija u upravljanju obraunom

MEDIATION - Medijacija u upravljanju obraunom

1.1 Arhitektura sistema za upravljanje obraunom

Sl.1.1 Arhitektura sistema za upravljanje obraunom [2]

Upravljanje TK mreama 1.1.1 Sistem za obraun

MEDIATION - Medijacija u upravljanju obraunom

MEDIATION - Medijacija u upravljanju obraunom

Sl.1.2 Billing Engine i njegove funkcije [2]

MEDIATION - Medijacija u upravljanju obraunom

Sl.1.3 Rating Engine i njegove funkcije [2]

MEDIATION - Medijacija u upravljanju obraunom

MEDIATION - Medijacija u upravljanju obraunom

MEDIATION - Medijacija u upravljanju obraunom

Sl.2.1 Proces medijacije [9]

2.1 Potreba za medijacijom

MEDIATION - Medijacija u upravljanju obraunom

2.2 Zahtjevi prema medijacijskom sistemu

2.3 Medijacijske karakteristike

MEDIATION - Medijacija u upravljanju obraunom

Sl.2.2 Generalizirana arhitektura medijacijskog sistema [9]

MEDIATION - Medijacija u upravljanju obraunom

2.4 Medijacijski ureaji

MEDIATION - Medijacija u upravljanju obraunom

Sl.2.3 Medijacijski sistem [4]

2.5 CDR standardni format

Upravljanje TK mreama 2.5.1 CDR format za glasovne usluge

MEDIATION - Medijacija u upravljanju obraunom

CDR format za podatkovne usluge

MEDIATION - Medijacija u upravljanju obraunom

MEDIATION - Medijacija u upravljanju obraunom

2.6 Aktivna i pasivna medijacija

2.7 Rjeenja za medijaciju

MEDIATION - Medijacija u upravljanju obraunom

MEDIATION - Medijacija u upravljanju obraunom

Tabela 2.2 Interconnect sistemi za naplatu i tarifiranje [2]

Tabela 2.3 Post-paid sistemi za naplatu i tarifiranje [2]

MEDIATION - Medijacija u upravljanju obraunom

MEDIATION - Medijacija u upravljanju obraunom

3.1 jBilling arhitektura

MEDIATION - Medijacija u upravljanju obraunom

3.2 Model baze podataka

Sl.3. 1 Model baze podataka u jBilling-u [10]

Primjer jBilling_table je dat u nastavku. Id 10 14 21 Ime 'base_user' 'item' 'purchase_order' itd.

MEDIATION - Medijacija u upravljanju obraunom

Sl.3.2 Korisnici u jBilling bazi podataka [10]

MEDIATION - Medijacija u upravljanju obraunom

Sl.3. 3 Kontaktne informacije kupca unutar baze podataka [10]

Upravljanje TK mreama 3.2.2 Item-i

MEDIATION - Medijacija u upravljanju obraunom

Sl.3. 4 Model Item-a u bazi podataka [10]

Sl.3. 5 Model item_type i item_type_map tabele [10]