Ut m Proje Kt Mediation

UNIVERZITET U SARAJEVU

ELEKTROTEHNIČKI FAKULTET

ODSJEK ZA TELEKOMUNIKACIJE

MEDIATION – Medijacija u upravljanju obračunom

Projekt iz predmeta Upravljanje telekomunikacijskim mrežama

Elbisa Čolak, Meliha Dulić & Erma Perenda

Sarajevo, 2012

Upravljanje TK mrežama MEDIATION - Medijacija u upravljanju obračunom

2

Sadržaj

UVOD ........................................................................................................................................... 4

1. Upravljanje obračunom ......................................................................................................... 5

1.1 Arhitektura sistema za upravljanje obračunom ...................................................................... 5

1.1.1 Sistem za obračun ........................................................................................................... 6

1.1.2 Sistem za naplatu............................................................................................................. 6

1.1.3 Sistem za tarifiranje ......................................................................................................... 9

2. Medijacija ........................................................................................................................... 10

2.1 Potreba za medijacijom ......................................................................................................... 11

2.2 Zahtjevi prema medijacijskom sistemu ................................................................................. 12

2.3 Medijacijske karakteristike .................................................................................................... 12

2.4 Medijacijski uređaji ............................................................................................................... 14

2.5 CDR standardni format .......................................................................................................... 15

2.5.1 CDR format za glasovne usluge ..................................................................................... 16

2.5.2 CDR format za podatkovne usluge ............................................................................... 16

2.6 Aktivna i pasivna medijacija .................................................................................................. 18

2.7 Rješenja za medijaciju ........................................................................................................... 18

3. Medijacija i jBilling .............................................................................................................. 22

3.1 jBilling arhitektura ................................................................................................................. 22

3.2 Model baze podataka ............................................................................................................ 23

3.2.1 Korisnici ......................................................................................................................... 24

3.2.2 Item-i ............................................................................................................................. 26

3.2.3 Purchase Order .............................................................................................................. 27

3.2.4 Računi ............................................................................................................................ 28

3.2.5 Plaćanja.......................................................................................................................... 29

3.2.6 Medijacija ...................................................................................................................... 31

3.3 Instalacija Community jBilling ............................................................................................... 32

3.4 Medijacija u Community jBilling-u ......................................................................................... 34

3.4.1 Pasivna medijacija ......................................................................................................... 34

3.4.2 Aktivna medijacija ......................................................................................................... 35

3.5 Opis testnog scenarija ........................................................................................................... 36

3.6 Realizacija testnog scenarija .................................................................................................. 36

3.6.1 Medijacijski proces ........................................................................................................ 36


3

3.6.2 Defincija medijacijskog formata ................................................................................... 37

3.6.3 Čitač plug-in .................................................................................................................. 39

3.6.4 Konfiguracija medijacije ................................................................................................ 41

3.6.5 Item management ......................................................................................................... 43

3.6.6 Kreiranje novih korisnika ............................................................................................... 45

3.6.7 Procesiranje s pravilima................................................................................................. 49

3.6.8 Rezultati medijacije ....................................................................................................... 63

ZAKLJUČAK ................................................................................................................................. 66

AKRONIMI .................................................................................................................................. 67

LITERATURA ............................................................................................................................... 68

Prilog ......................................................................................................................................... 69


4

UVOD

Razvoj društvenih i privrednih sistema u drugoj polovici prošloga stoljeća 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, budući da oni postaju sve kompleksniji. Postoji više pristupa ka

upravljačkom sistemu. Jedan od najpoznatijih je FCAPS model, koji opisuje pet nivoa upravljanja

mrežom: upravljanje greškama, upravljanje konfiguracijom, upravljanje obračunom, upravljanje

performansama i upravljanje sigurnošću. Sistemi za upravljanje obračunom dobijaju sve veću važnost

kod mrežnih operatora. U tradicionalnim telekomunikacijskim mrežama, sistemi za tarifiranje i

naplatu usko su vezani uz pojedine usluge, pri čemu svaka usluga ima specifična pravila tarifiranja i

format računa. Proces tarifiranja i naplate svake usluge je odvojen i nezavisan, a pretplatnici

pojedinih usluga definirani su u zasebnim sistemima, čime je ograničena ili otežana razmjena

informacija i fleksibilnost u poslovanju. Operatori se danas suočavaju s novim izazovima na tržištu,

kao što su uvođenje kompleksnih multimedijalnih usluga, segmentacija pretplatnika, te upravljanje

partnerima uz istovremenu potrebu za kontrolom troškova i osiguranjem prihoda. Za uspjeh

multimedijalnih usluga, ključno je kreirati nove tržišne pakete i poslovne modele koji će privući

pretplatnike, a također i partnere. Tržišni paketi usluga moraju biti cjenovno i ponudom atraktivni, a

istovremeno jednostavni i razumljivi krajnjem korisniku. Korisnik zahtjeva kontrolu troškova i

personalizirani sadržaj. Operatori trebaju učinkovit i nenametljiv način kojim mogu pridobiti

pretplatnikovu pažnju, stimulirati korištenje usluga i osigurati lojalnost. U takvom okruženju podjela

pretplatnika i usluga na različite sisteme tarifiranja i naplate više nije poželjna niti potrebna, kako s

tehnološkog, tako i s poslovnog aspekta. Od sistema za tarifiranje i naplatu zahtjeva se fleksibilnost,

uz fokus na smanjenje troškova pa tradicionalni, potpuno odvojeni vertikalni sistemi naplate nisu

isplativo rješenje. Ovaj projektni zadatak ima za cilj da predstavi važnost medijacije unutar sistema za

naplatu i tarifiranje.

Rad je podjeljen na tri dijela. U prvom dijelu opisana je arhitektura sistema za upravljanje

obračunom, 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. Također, data su

potencijalna rješenja za medijaciju bazirana i na komercijalnim proizvodima, kao i na open-source

rješenjima. Treći dio rada opisuje jedan od široko rasprostranjenog open-source rješenja za

medijaciju, jBilling. U ovom dijelu detaljno je opisan proces medijacije unutar ovog alata, uz naznaku

svih specifičnih koraka ovog procesa. U cilju ilustracije tog procesa, realiziran je jedan testni scenarij.


5

1. Upravljanje obračunom

Upravljanje obračunom sadrži skup funkcija koje omogućavaju mjerenje korištenja mreže (i

servisa), te kolekciju, tarifiranje i obračun podataka o korištenju mreže (servisa). Sistemi za tarifiranje

i sistemi za naplatu su ključni sastavni dijelovi svakog telekom operatora kod procesa upravljanja

obračunom. Sistemom tarifiranja (engl. Charging System) nazivamo svaki proces koji u sistemu

skuplja i procesira informacije o svim događajima važnim za tarifiranje. Sistem za obračun (engl.

Accounting System) brine se o raspodijeli troškova u slučaju da više pružatelja usluge učestvuje u

kreiranju i dostavi usluge, na primjer u slučaju roaming-a. Sistem za naplatu (engl. Billing System)

obavlja funkciju akumulacije svih troškova, te izdavanja računa za krajnjeg korisnika. Nadalje, kako bi

sistem tarifiranja mogao obavljati svoju zadaću, on mora koristiti funkciju određivanja tarife,

jedinične cijene pojedine usluge (engl. Tariffing), te funkciju računanja broja iskorištenih jedinica

(engl. Metering). [1]

1.1 Arhitektura sistema za upravljanje obračunom

Slika 1.1 ilustrira arhitekturu sistema za upravljanje obračunom. Logički je podjeljena na tri dijela:

sistem za obračun, sistem za naplatu i sistem za tarifiranje. Sistem za naplatu je daleko složeniji od

sistema za tarifiranje.

Sl.1.1 Arhitektura sistema za upravljanje obračunom [2]


6

1.1.1 Sistem za obračun

Sistem za obračun 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 korisničkog naloga. CRM je

sistem kojim prilagođavamo strategiju, organizaciju i kulturu poslovanja na način da svaki

kontakt s korisnikom vodi ka dugoročnom zadovoljstvu korisnika, a time i dugoročno

povezanoj dobiti kompanije. Pri tome se ne razmišlja na način "šta mi možemo ponuditi

korisniku?", nego na način "kako upoznati korisnika i identificirati njegove potrebe?".

Osnovna ideja CRM-a je, ne više orjentiranost kompanije prema uslugama, već povećana

briga za korisnika. Usluge moraju biti prilagođene osobnosti korisnika usluga. Ovo je danas

postalo moguće razvojem baza podataka, koje omogućavaju pohranu podataka o pojedinim

korisnicima, te softvera koji omogućava analizu i optimalno korištenje tih podataka. CRM

čuva relevantne informacije o korisniku i proizvodima i uslugama koje koristi. OMOF modul je

odgovoran za praćenje korisničkog naloga od njegovog nastanka pa do završetka.

CRM/OMOF modul može komunicirati s nižim slojevima na dva načina:

CRM/OMOF sistem kontaktira sistem za naplatu, koji zatim kontaktira Provisioning

sistem za pružanje usluge i Network inventory sistem za dodjelu telefonskih brojeva

ili IP adresa, a potom sistem za naplatu vraća povratnu informaciju CRM/OMOF

sistemu.

Druga mogućnost je da CRM/OMOF sistem direktno kontaktira Provisioning sistem

za pružanje 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

mreže za aktiviranje, deaktiviranje ili obustavljanje usluge. Nakon uspješno obavljenog

zadatka, ovaj sistem šalje odgovor natrag onom sistemu koji mu je poslao naredbu.

Network Inventory System (NIS) održava listu svih mrežnih 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 može direktno ili

posredno preko sistema za naplatu kontaktirati NIS za dobijanje određenog mrežnog

identifikatora i dodijeliti ga korisniku za vrijeme kreiranja korisničkog naloga. Ovaj sistem je,

također, odgovoran za održavanje životnog ciklusa mrežnog identifikatora, koji pri samom

kreiranju korisničkog naloga postaje dostupan, a potom prolazi kroz faze aktivacije,

obustavljanja, ukidanja ovisno o prirodi i ponašanju korisnika.

1.1.2 Sistem za naplatu

Sistem za naplatu je sastavljen od serije nezavisnih aplikacija koje se pokreću zajedno na jednom

hardveru. Sastoji se od sljedećih dijelova:


7

Billing Engine je mašina za naplatu koja za odgovarajući korisnički nalog sakuplja sljedeće

relevantne informacije na osnovu kojeg generira fakturu podataka (engl. invoice) koja se

koristi za kreiranje računa, 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 računa;

da li je korisnik unaprijed platio u određenom mjesecu;

postoji li popust za korisnika;

ukupni porezi i troškovi obrade računa;

da li je monitiranje prošlo u dobrobit korisnika ili ne;

Billing konfiguracijski parametar je potreban za pokretanje Billing Engine-a, na

primjer plaćanje do određenog datuma i sl.

Iznad navedeni podaci su samo indikativni i mogu varirati ovisno o vrsti sistema za naplatu, kao i od

operatora. Billing Engine mašina proizvodi sirove podatke koji imaju sve potrebne informacije za

generiranje konačnog obračuna i ovi sirovi podaci se mogu koristiti za generiranje konačne fakture

koja se šalje krajnjem korisniku.

Sl.1.2 Billing Engine i njegove funkcije [2]

Rating Engine prima događaje (jedna pojava upotrebe usluge/proizvoda) u obliku record

podataka koji se zovu Call Detail Records (CDR) ili Usage Detail Records (UDR), koji opisuju

korištenje proizvoda/usluge (sl. 1.3). CDR je niz podataka koji sadrži informacije o pozivu kao


8

što su datum i vrijeme poziva, trajanje poziva, pozvana strana, pozivajuća strana, koje se

koriste za rating događaja. Osnovne funkcije ove mašine su prihvatanje CDR-ova od sistema

za medijaciju, provjera validnosti CDR-a, u slučaju duplikata odbacivanje CDR-a i slanje ovog

duplog CDR-a u bazu podataka koji će biti kasnije verificiran, na osnovu izvorne adrese CDR-a

pretražuje bazu podataka da utvrdi da li postoji korisnički nalog, ako ne postoji događaj se

odbija, računanje cijene događaja na osnovu tarife koja je sadržana u planu za cijene

događaja, pohranjivanje ocjenjenog događaja u bazu podataka koja služi za naplatu ili se šalje

nekom eksternom sistemu za naplatu. Informacije korisnika određuje plan tarifiranja u cilju

izračunavanja cijene. Rating Engine koristi rating tabele i informacije o događaju iz CDR-a

(npr. udaljenost, vrijeme, mjesto poziva, trajanje ili veličina događaja, itd.) kako bi izračunao

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 izračunati u toku rating procesa ili billing procesa. Detaljnije

o ovim procesima vidjeti u [2].

Credit Control modul omogućava pružatelju usluge monitoring kredita pretplatnika i

monitoring poziva, te preuzimanje mjera protiv određenog pretplatnika ako je potrebno.

Payment Processing je obrada uplaćenog računa u sistemu za naplatu. Uplate koje načini

korisnik smještaju se u njegov korisnički račun (engl. account). Ako postoje bilo kakvi

nepodmireni dugovi onda račun koji se plaća ovisi o tipu računovodstvene metode. Postoje

dva tipa računovodstvenih metoda: Balance forward accounting (plaćanje prema starosti

računa) i Open item accounting (plaćanje određenog proizvoljnog računa).

Report Generation modul je bitan za pružanje korisnih informacija za upravljanje, finansije,

prodaju i performanse sistema. Izvještaji sadrže podatke koji unapređuju poslovni uspjeh,

monitoring ispravnosti poslovanja, identificiranje problema kako bi se primjenile

odgovarajuće korektivne akcije. Postoje dvije kategorije izvještaja: temeljni/gotovi izvještaji


9

(generiše ih sistem za naplatu) i custom izvještaji (nisu direktno dostupni iz sistema i

zahtjevaju konstruisanje odgovarajućih PL/SQL, PERL skripti).

1.1.3 Sistem za tarifiranje

Sistem za tarifiranje sastoji se sistema za medijaciju, mrežnih preklopnika, DWH baze, ERP

sistema i Payment gateway-a.

Mrežni preklopnici su odgovorni za pružanje 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. Mrežni preklopnici uključuju

MSC (engl. Mobile Switching Center), GGSN (engl. Gateway GPRS support node) i MMSC

(engl. Multimedia Messaging Service Center).

Skladište podataka DWH (engl. Data Ware House ) sistem je baza podataka koja sadrži

historijske nepromjenjive podatke, koji se prikupljaju i obrađuju radi podrške sistema za

naplatu. Podaci se izvlače iz raznovrsnih izvora, te se u skladu s definiranim modelom

podataka učitavaju u bazu podataka i integriraju s postojećim podacima. U logičkom smislu,

to je centralizirana baza podataka koja se periodički osvježava. Čuvaju se informacije vezane

za korištenje usluga, račune, plaćanja, popuste i prilagodbe itd. Sve ove informacije se koriste

za generiranje raznih vrsta izvještaja, koji se koriste za poslovnu inteligenciju i prognozu.

Enterprise Resource Planning (ERP) sistem je uobičajeni naziv za poslovni softver koji

integrira aktivnosti različitih odjela kao što su planiranje proizvodnje, nabavka dijelova,

upravljanje zalihama, distribucije proizvoda i praćenje narudžbi. On može objediniti

aplikacijske module za finansije, računovodstvo i upravljanje ljudskim resursima.

Payment Gateway ne mora nužno biti kompletan sistem, ali predstavlja neku vrstu

posrednika između sistema za naplatu i plaćanja putem različitih kanala kao što su banke,

kreditne kartice i dr. Svi kanali koji se koriste za plaćanje koriste Payment gateway. Obično

Payment gateway predstavlja neku vrstu API-a (engl. Application Programming Interface)

vanjskom svijetu, u cilju obavljanja plaćanja koje je direktno vezano za sistem za naplatu. API

se može koristiti od strane bilo kojeg vanjskog izvora kako bi se obavilo plaćanje.

Sistem za medijaciju prikuplja CDR-ove od različitih mrežnih elemenata u različitim

formatima i obrađuje ih i pretvara u jedinstveni format, kompatibilan onom koji se koristi kod

sistema za naplatu. Detaljnije o procesu medijacije dato je u drugom poglavlju.


10

2. Medijacija

Medijacija je proces koji je umetnut između mrežnih elemenata i downstream aplikacija. Ove

aplikacije mogu biti različitih vrsta i medijacijski proces sam može upravljati nekom od tih vrsta

podataka. Medijacija je lanac tri procesa: prikupljanje podataka, normalizacija i poslovna

transformacija i dostava podataka. [9]

1. Prikupljanje podataka uključuje prikupljanje korisnih informacija u formi CDR-a. CDR se

sakuplja od različitog seta mrežnih elemenata, rangiranih od PSTN switch-eva do MSC-

ova, korištenjem različitih 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 korištenjem seta poslovnih

pravila da odredi značajne podatke za transakciju i okolnosti u kojima se podaci koriste.

Na primjer, slanjem svih zapisa prema statistički baziranim poslovnim aplikacijama, ali

slanjem samo poziva koji traju više od minute prema sistemu za obračun. U scenariju

komunikacije podataka, proces transformacije uključuje apsorpciju informacija iz različitih

izvora podataka i konsolidaciju prikupljenih podataka u sažet zapis.

3. Dostava podataka je posljednji korak u procesu medijacije. Ovdje, CDR je dostavljen

downstream aplikaciji, koja može biti: sistem za naplatu, sistem za upravljanje prevarama

i poslovni inteligentni sistem. Ovaj korak uključuje sljedeće procese:

Kodiranje prikupljenog i transformisanog CDR-a u format, koji je prikladan za

odgovarajuću downstream aplikaciju;

Streaming transformisanog CDR-a za neposredno korištenje od strane

downstream aplikacije u push-mode operaciji;

Smještanje podataka u fajl, tako da ih downstream aplikacije mogu koristiti u

određeno vrijeme.


11

Sl.2.1 Proces medijacije [9]

2.1 Potreba za medijacijom

Medijacijski proces omogućava pružateljima usluga da iskoriste sve prednosti njihovih mrežnih

korisnih podataka, korištenih ne samo za streamline nekog sistema za naplatu, nego i za strateške

aplikacije, kao što su upravljanje prevarama, analize ponašanja korisnika i mrežno planiranje.

Fleksibilnost medijacijskog procesa omogućava operatoru da se nosi sa budućim aplikacijama koje će

biti dodane i pomaže im da bolje upravljaju njihovim porastom u kompleksnom okruženju, koje se

brzo mijenja. Medijacijski sistem je uveden s ciljem da pruži mrežnim operatorima put za brže

razvijanje novih aplikacija i servisa, dok štiti postojeće aplikacije od promjena. [9]

Danas u konkurencijskom okruženju, operatori moraju da pruže mnogo više usluga, baziranih na

novim tehnologijama. Medijacijski sistem omogućava ne samo neposredni obračun za nove

pokrenute usluge, nego i konvergenciju obračuna, odnosno pružanje samo jednog obračuna

prikupljanjem svih obračunskih informacija povezanih sa svim uslugama, koje je koristio korisnik

(pretplatnik). Fleksibilnost je veoma važna sposobnost za opstanak na konkurentnom tržištu i

omogućavanje ovih novih karakteristika, da se mogu nositi sa povećanim tehnološkim komplikacijama

i vladajućim pravilima, i sposobnost da uvedu prototip novih usluga, te da izmjere njihovo prihvaćanje

i interes od strane korisnika, prije nego što ulože velika sredstva za njihovu implementaciju.[9]

Davatelji usluga moraju preispitati sami sebe kako će neka od sljedećih pitanja utjecati na njihov

sistem za obračun:

prenosivost broja;

razdvojene mreže (engl. unbundled networks);

pristup cijenama (engl. charges) drugih ISP-ova;

performanse usluga u inteligentnim mrežama;

konvergencija više tipova usluga u jedan obračun.


12

Za adaptaciju i primjenu ovih promjena, fleksibilnost u njihovim medijacijskim sistemima je

ključna. Dakle, medijacijski sistem je ključan za savladavanje sljedećih izazova:

na vrijeme izbaciti nove usluge na tržište (engl. time-to-market for new services);

obračun za više tipova mrežnih usluga;

real-time medijacija je potrebna za detalje o pozivu i informacije za naplatu;

IP telefonski obračun;

veleprodajni i maloprodajni obračuni;

međuoperatorski ugovor je potreban;

prevencija sigurnosnih prevara.

Stoga, medijacijski sistem:

stavlja fokus na organizacijski end-to-end pogled na uslugu;

podržava nove dodane usluge;

popunjava praznine između IT (engl. Information technology) i mrežnih operacija;

smanjuje zavisnost sistema za naplatu od mrežnih elemenata;

može ubrzati uvođenje konvergentnih usluga;

ušteda pomoću podrške za više različitih medijacijskih platformi;

pruža OSS (engl. Operation Support System) fleksibilnost da omogući spajanje i akviziciju;

sposobnost integracije mreže - FMI, SS7.

2.2 Zahtjevi prema medijacijskom sistemu

Zahtjevi koji se postavljaju pred medijacijski sistem su:

sakupljanje podataka od interfejsa mrežnih elemenata različitih proizvođača;

podrška za uvođenje novih tehnologija;

podrška za izmjene novih tehnologija;

normalizacija, ujedinjenje i filtracija podataka preko različitih tipova uređaja i proizvođača;

dostavljanje podataka različitim sistemskim interfejsima mrežnih elemenata;

podrška za uvođenje novih sistema;

podrška promjenama novih sistema, za upoznavanje sa novim poslovnim zahtjevima.

2.3 Medijacijske karakteristike

Na sljedećoj slici data je generalizirana arhitektura medijacijskog sistema.


13

Sl.2.2 Generalizirana arhitektura medijacijskog sistema [9]

Sakupljanje (engl. Collection)

Medijacijski sistem mora sakupiti CDR-ove od različitih mrežnih elemenata, preklopnika različitih

proizvođača, internetskog rutera, Internetskih usluga (e-mail, autentifikacija, itd.). Podaci se

sakupljaju pomoću različitih protokola, traka ili diskova. Najčešće korišteni 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 korisnički-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 pogrešni CDR-ovi i usmjeriti na uređaj za korekciju.

Integracija, konsolidacija (engl. Consolidation)

Ova karakteristika je veoma važna i specijalna za Internetski obračun. Omogućava da se napravi

samo jedan CDR baziran na korisnički definiranim pravilima i omogućava prikupljanje svih obračunskih

informacija od drugih srodnih CDR-ova, koji mogu dolaziti iz različitih izvora.

Prezentacija (engl. Presentation)

Kao što je navedeno ranije, format sirovog CDR-a ne može se koristiti za obračunsku 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


14

izvedene iz ostalih postojećih informacija ili dohvaćene iz vanjskih izvora (npr. baze podataka). Kao

izlaz ovog procesa, dobije se obračunski zapis, koji može biti sakupljen u datoteci ili sačuvan odvojeno

za neposrednu distribuciju.

Distribucija/Raspodjela (engl. Distribution)

Obračunski zapisi se raspodjeljuju na obračunske aplikacije. Sredstva koja se obično koriste: FTP

preko TCP/IP, NFS montirani disk, TCP/IP, Ethernet na nivou linka.

Opće usluge (engl. General services)

Osim ovih tipičnih medijacijskih karakteristika, medijacijski sistem treba opće namjenske usluge:

planiranje: za početak ukupnog procesa ili samo dijela procesa;

reviziju logova;

praćenje – Monitoring;

korisnički interfejs: preferira se grafički interfejs, koji omogućava korisniku pristup svim

nivoima za konfiguraciju, praćenje, te reviziju funkcija;

izvještavanje: generiranje izvještaja za prihod od osiguranja;

notifikacije alarma u slučaju greške koja zahtjeva neposrednu akciju;

arhiviranje: pohranjivanje sirovih CDR-ova za kasnije reprocesiranje.

2.4 Medijacijski uređaji

Medijacijski uređaji primaju, procesiraju i reformatiraju informacijske događaje u

telekomunikacijskim mrežama u format pogodan za jedan ili više obračunskih sistema i za sisteme za

podršku korisnicima. Obrađene informacije se stalno ili povremeno šalju sistemu za naplatu. Switch

obično „zapisuje“ korisne informacije (npr. trajanje veze) u Binary Coded Decimal (BCD) formatu i ovi

zapisi su najčešće vlasništvo proizvođača switch-a. Zapisi mogu biti različitih dužina i nekoliko

događaja mogu biti zapisani u istom sistemu za jedan poziv. Postoji najmanje 60 proizvođača switch-

eva i svaki od njih ima nekoliko modela switch-eva, koji mogu dovesti do različitih formata obračuna.

Slika 2.3 prikazuje medijacijski sistem koji preuzima CDR-ove sa nekoliko različitih switch-eva i

transformiše ih u standardne CDR-ove, koji se prosljeđuju obračunskim sistemima. Sa slike se vidi da

medijacijski uređaji imaju mogućnost primanja i dekodiranja određenih formata podataka od raznih

proizvođača switch-eva. Medijacijski uređaji konvertuju ove formate u standardni CDR format, kojeg

može koristiti sistem za naplatu.


15

Sl.2.3 Medijacijski sistem [4]

Preovladavajući ekonomski uvjeti na komunikacijskom tržištu osiguravaju da su svi pružatelji

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 sljedećih načela:

Brzi povratak ulaganja:

prekonfigurisana integracija – minimizacija cijene i vremena integracije sistema;

pojedinačna linija proizvodnje – svi korisnici na istoj verziji software-a, minimizacija

TCO-a;

brzi razvoj – minimizacija vremena od ugovora do povratne investicije.

Fleksibilnost:

postepena implementacija olakšava pomjeranje od nasljeđenog 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

uključuju glasovne i podaktovne usluge preko mobilne ili fiksne mreže, IP usluge (poput e-mail-a) i

isporuku sadržaja. Drugim riječima, usluge se mogu podijeliti na glasovne i podatkovne usluge. [9]


16

2.5.1 CDR format za glasovne usluge

Glas je osnovna usluga koju pruža 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 sadržavati:

jedinstveni sekvencni broj koji identificira CDR (engl. Unique Identifier Record);

pozivajući broj (engl. Call Originator);

pozvani broj (engl. Called Number);

vrijeme početka poziva (engl. Start Time);

vrijeme završetka poziva (engl. Stop Time).

Osim toga CDR može sadržavati informacije poput: identifikator telefonske centrale, rezultat poziva

(odbijen, uspostavljen), trunk ili ruta korištena za spajanje poziva, greške pri uspostavi poziva i dr.

Tačno snimanje svih zahtjevanih informacija u CDR/UDR zavisi od logike switch-a i specifične tabele

zapisa tog switch-a. Ako bilo koja od zahtjevanih informacija nije korektna, medijacijski sistem neće

prepoznati kompletan poziv i neće 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 pruža podaktovne usluge je GPRS (engl. General Packet Radio

Service). GPRS je paketska tehnologija, koja omogućava bežičnu komunikaciju, slanje i primanje

informacije pokretnom mrežom, koristeći velike brzine. Standardiziran je od strane ETSI (engl.

European Telecommunications Standards Institute) 2000. godine. Omogućava sljedeće usluge:

pristup intranetu, pristup internetu, e-mail i fax, tekstualne i slikovne poruke, chat, e-commerce i

online-banking, oglašavanje, GPS (engl. Global Positioning System), automatizacija doma i dr. Kao


17

proširenje GSM mreže, GPRS je dodao dva nova čvora: SGSN (engl. Serving GPRS Support Node), čija

je uloga u GPRS arhitekturi ekvivalentna ulozi MSC/VLR čvora u postojećoj GSM arhitekturi i GGSN

(engl. Gateway GPRS Support Node), koji je većinom pod ingerencijom rutera, koji podržava funkcije

klasičnog gateway-a, kao što su: objavljivanje pretplatničkih adresa, mapiranje adresa, povezivanje i

tuneliranje paketa, prikazivanje poruka, te brojanje paketa, omogućava šifriranje, mobility

management, naplaćivanje i skupljanje statističkih informacija (zapisi o stanju računa). Različiti

elementi GPRS mreže sakupljaju različite tarifne podatke [9]:

SGSN generira tarifne informacije za upotrebu radio mreže;

GGSN generira tarifne informacije za eksternu upotrebu podaktovne mreže;

oba ova čvora generiraju tarifne informacije o upotrebi resursa GPRS mreže.

GGSN CDR mora sadržavati:

vremenski trenutak početka skupljanja tarifnih informacija: aktivacija PDP (engl. Packet Data

Protocol) konteksta;

vremenski trenutak prestanka skupljanja tarifnih informacija: deaktivacija PDP konteksta;

količinu saobraćaja uplink/downlink-a;

ugovoreni QoS (engl. Quality of Service);

SGSN i GGSN adresu;

AP (engl. Access Point) adresu;

trajanje korištenja usluge.

SGSN generiše nekoliko tipova CDR-ova: S-CDR (SGSN-CDR), M-CDR (Mobility Management-CDR) i

SMS-CDR. SGSN CDR odnosi se na korištenje radio mreže i sadrži iste CDR atribute kao i GGSN CDR.

M-CDR odnosi se na aktivaciju upravljanja mobilnosti i sadrži:

vremenski trenutak početka skupljanja: GPRS aktivacija/dolazeći SGSN RA (engl. Routing

Area) update;

vremenski trenutak prestanka skupljanja: GPRS deaktivacija/odlazeći SGSN RA update;

promjenu lokacije.

SGSN šalje M-CDR Charging gateway1-u svaki put kada korisnik promjeni ćeliju, lokalno područje ili

pak routing područje. SMS-CDR odnosi se na upotrebu SMS usluge u GPRS-u i on može biti poslan

preko tradicionalne ili pak preko GPRS backbone mreže. Sadrži informacije kao što su: servisni IMSI,

servisni IMEI (engl. International Mobile Equipment Identity), servisni MSISDN i adresu SMS servisnog

centra. Jedan PDP kontekst može generirati nekoliko S-CDR-ova i G-CDR-ova. CDR-ovi se sistemu za

naplatu šalju u regularnim intervalima. CDR jednog PDP konteksta može biti poslan od više SGSN

čvorova, ako se korisnik kreće i mjenja routing područje ili u slučaju 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 prosljeđuje u medijaciju.


18

2.6 Aktivna i pasivna medijacija

Dosad opisan princip rada medijacijskih uređaja predstavlja pasivnu medijaciju. Aktivna

medijacija opisuje funkcionalnosti sistema za medijaciju koji ima mogućnost da komunicira sa

pretplatnikom. Drugim riječima, medijacijski sistem definira/generiše događaj, a ne mrežni elementi.

Mrežni elementi su sada zaduženi za skupljane događaja generiranih od sistema za medijaciju.

Aktivna medijacija uključuje mogućnost autentifikacije i upita korisnika preko handset-a i

inicijalizacije sesije preko koje sistem za medijaciju korisniku predstavlja čitav niz izbora. Aktivna

medijacijska platforma utvrđuje da li korisnik ima dovoljno kredita na svom računu za korištenje

drugih usluga i druge detalje. Stablina aktivna medijacija je razvijena od strane proizvođača koji još

uvijek rukuju s jednostavnijom pasivnom medijacijom. U februaru 2004. godine na tržištu se pojavio

prvi aktivni konvergentni medijacijski sistem Xaccit Technologies od strane kompanija Comptel,

Openet Telecom, Ace-Comm, Intec Telecom Systems, Narus i Amdocs, koje obećavaju smanjenje

troškova održavanja, u odnosu na korištenja više pasivnih medijacijskih sistema i pratećih baza

podataka [5].

2.7 Rješenja za medijaciju

Kako bi se objasnila postojeća rješenja za medijaciju, neophodno je prethodno navesti tipove

sistema za naplatu. [2] Najčešća podjela sistema za naplatu je na:

Pre-pay sistem za naplatu je mehanizam naplate kod kojeg korisnik plaća unaprijed, nakon

čega počinje da koristi uslugu. Obično, pre-paid korisnici ne primaju nikakve račune i oni se

tarifiraju u realnom vremenu od strane široko-dostupnih sistema za naplatu koji se nazivaju

inteligentna mreža 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 (obično mjesec dana) i na kraju pružatelj usluge izračunavaju agregirani obračun,

kojeg šalje korisniku koji su ga dužni platiti.

Interconnect sistem za naplatu najčešće se odnosi na partnerstvo različitih

operatora/davatelja usluga koji imaju zadatak da korisniku osiguraju uslugu, a prihode

međusobno dijele.

Roaming tarifiranje odnosi se na slučaj kada korisnik ide iz područja pokrivenosti svog

operatora u područje drugog operatora. U cilju obezbjeđivanja usluge svom korisniku i van

područja pokrivenosti, operator sklapa ugovor s drugim operatorom i dužan je platiti drugom

operatoru marginalne troškove.

Konvergentni sistem za naplatu predstavlja san svakog velikog operatora. Odnosi se na

integraciju tarifiranja svih usluga nekog korisnika u jedan račun. To znači stvaranje

jedinstvenog pogleda operatora na korisnika i na sve usluge pružene tom korisniku.

U posljednih nekoliko godina, sistemi za medijaciju postali su sofisticiraniji i obavljaju veći broj

složenih zadataka. Tvrdi se da će sistemi za medijaciju evoluirati do tačke gdje će moći obavljati tzv.


19

back office funkcije, tj. upravljanje SLA (engl. Service Level Agreement) ugovorom, obavještavanje

operatora da postoji nestašica propusnog opsega korisnicima, detektiranje i sprečavanje

zlonamjernih prevara. Kako svaki medijacijski sistem podržava bazu podataka u koje se upisuje

korisnikovo ime, također korisnikovo ime stavlja se i u IP bazu podataka, te bazu podataka za bežične

usluge i upravo te tri baze podataka su mjesta koja omogućavaju prevare. Pri odabiru medijacijske

platforme, operatori moraju uzeti u obzir svoj poslovni plan, stepen evolucije mreže i marketinšku

strategiju. S obzirom na povećanje korištenja multimedijalnih aplikacija i podaktovnih usluga,

operatori imaju zadatak da preispitaju svoj postojeći sistem za medijaciju kako bi ostvarili što

ekonomičnije strateške mogućnosti medijacije [5]. Iako konvergentni medijacijski sistemi vladaju

tržištem, iznenađujuće je što veliki broj velikih operatora još uvijek koriste orginalne medijacijske

sisteme, i kombiniraju jedan ili više od ovih sistema za omogućavanje sistema za naplatu za razne

sisteme bazirane na IP ili bežičnim š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 pružanje rješenja za medijaciju za pre-paid proizvode i usluge. Ovi sistemi

nisu dovoljno fleksibilni za obradu različitih funkcionalnosti post-paid korisnika, poput

složene hijerarhijske baze korisnika, CDR re-rating, fleksibilni izvještaji, roaming tarifiranje i

dr.

Post-paid sistemi za tarifiranje, poput Convergys Infinys ili Amdocs, su veoma dobri za post-

paid 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) možemo postići

konvergentni medijacijski sistem. Ericssonovo rješenje za konvergentno prikupljanje podataka

(medijaciju) zove se Ericsson Multi Mediation EMM. EMM se sastoji od dva modula, modula za

prikupljanje datoteka/događaja (engl. File/Event Module) i online modula. Modul za prikupljanje

datoteka/događaja prikuplja podatke o usluzi iz bilo koje višeuslužne i pristupne mreže, neovisno o

proizvođaču opreme, te procesira prikupljene podatke u nerealnom ili približno realnom vremenu, pa

obrađene podatke šalje u sistem naplate, sistem za otkrivanje prevara (engl. Fraud) ili neki drugi

sistem. Online modul omogućava dvosmjernu komunikaciju za razmjenu podataka o usluzi s mrežnim

elementima u realnom vremenu. Na taj način omogućeno je operatoru da naplati uslugu neposredno

nakon što je korištena. [6] U sljedećim tabelama dati se proizvođači sistema za naplatu, odnosno

medijacijskih sistema.

Sistem Web stranica

Ericsson IN http://www.ericsson.com

Nokia Siemens IN http://www.nokiasiemensnetworks.com

Orga Systems http://www.orga-systems.com

Tabela 2.1 Pre-paid sistemi za naplatu i tarifiranje [2]

http://www.ericsson.com/

http://www.nokiasiemensnetworks.com/

http://www.orga-systems.com/


20

Sistem Web stranica

Ascade www.ascade.com

i-conX http://www.iconxsolutions.com/

Convergys http://www.Convergys.com

Comptel http://www.comptel.fi/

Intec Systems http://www.intec-telecom-systems.com

Cerillion http://www.cerillion.com

MTS http://www.mtsint.com/

Telarix http://www.telarix.com/

Tabela 2.2 Interconnect sistemi za naplatu i tarifiranje [2]

Sistem za naplatu i tarifiranje Web adresa

Amdocs http://www.amdocs.com

Convergys http://www.Convergys.com

Cellution http://www.1cellution.com/

Comarch http://www.comarch.com

Comverse http://www.comverse.com

CSG Systems http://www.csgsystems.com

FTS http://www.fts-soft.com

HighDeal http://www.highdeal.com

Huawei http://www.huawei.com/

InfoDirections http://www.infodirections.com/

Kabira Technologies http://www.kabira.com/

LHS http://www.lhsgroup.com

Martin Dawes Systems http://www.martindawessystems.com

Oracle RBM http://www.oracle.com/index.html

Sitronics 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 rješenja za medijaciju.

Prednosti open-source rješenja su u tome da su web-bazirana, mogu se proširiti i integirati za

specifičnu namjenu. Najraširenija open-source rješenja za medijaciju su [7]:

http://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/

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


21

1. AgileBill - je pušten kao komercijalni proizvod 2004, a zatim kao open-source od strane

svog kreatora Tony Landis-a 2008. AgileBill je aplikacija za naplatu i obračunavanje

pogodna za poslovne modele tipa članstvo/pretplata, uključujući Web hosting kompanije,

ISP i VoIP pružatelje usluga. AgileBill ima dodatke za payment processing, Provisioning i

povezivanje s third-party aplikacijama i uslugama. To je, također, dovelo do AgileVoice,

AgileISP VoIP i ISP aplikacija za naplatu, respektivno.

2. Amberdms Billing System je sistem za naplatu koji također pruža niz korisnih funkcija

obračuna i poslovnog upravljanja. ABS ima aplikacije za fakturiranje, upravljanje

uslugama, HR i vrijeme čuvanja, a namijenjen je malim i srednjim poduzećima, kao i za

male ISP i IT kompanije. Third-party integracija može biti učinjena putem API-a i

komercijalna podrška je dostupna od novozelandskih kompanija Amberdms.

3. Freeside je softver za naplatu, ticketing i automatski Provisioning, prilagođen za online

tvrtke, uključujući i ISP, ITSPs, hosting i davatelje sadržaja. Funkcionalnosti sistema za

naplatu uključuje i real-time kontrolu kredita i e-potvrdnu obradu koristeći popularne

Payment Gateway-e, e-mail, fax, printano i online obračunavanje, kao i fleksibilan

cijenovni i rating plan.

4. CitrusDB je sistem za naplatu razvijen s PHP i MySQL-om, koji se također može koristiti za

praćenje informacija o korisnicima (CRM), uslugama, proizvodima, fakturama i kreditnim

karticama, i informacijama o podršci. Cilj projekta je pružiti open-source rješenje za CRM i

sisteme za naplatu, koje se može koristiti u mnogim različitim uslužnim 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 podržava

sisteme s više baza podataka. Projekt tvrdi da može skalirati "milion faktura", a može se

izvoditi na jednom serveru ili grupi specijaliziranih čvorova. Uključuju automatsku

generaciju faktura i Payment Processing. Detaljnije o jBilling-u dato je u trećem dijelu

rada.


22

3. Medijacija i jBilling

Enterprise jBilling Software je kanadska kompanija, locirana u gradu Vancouver, obalni grad

smješten u regiji Lower Mainlandu, u Britanskoj Kolumbiji. jBilling je standard za open-source softver

za sisteme za naplatu. Uz poslovne mogućnosti i robusnu arhitekturu, dobar je izbor za kompanije

svih veličina. jBilling podržava od vrlo jednostavnih do vrlo složenih zahtjeva sistema za naplatu.

jBilling dolazi u četiri izdanja, uključujući Community, koji je besplatan, kao i Enterprise i Telco

izdanja, koji imaju godišnje naknade za licenciranje, podršku i održavanje. Ova izdanja daju također i

izvorni kod, tako da je moguće zadržati potpunu kontrolu nad svojim rješenjem za sistem za naplatu.

Telco Hosted izdanje zahtjeva mjesečne pretplate, ili godišnju opciju koja nudi popust. Kao cloud-

based rješenje, Telco Hosted izdanje ne omogućava pristup izvornom kodu. Detalje o tome šta

pružaju navedene verzije može se pogledati na http://www.jbilling.com/features/compare-editions.

U cilju prilagodbe jBilling-a osobnim zahtjevima sistema za naplatu, jBilling se integriše s Business

Rules Management sistemom (BRMS). BRMS održava pravila koja se izvode u produkciji sistema, ali

također održava repozitorij s korisničkim interfejsom pogodan kompanijama za kreiranje novih

pravila, čitanje, ažuriranje i brisanje istih. Glavne prednosti BRMS-a su: smanjiti ili ukloniti oslanjanje

na IT odjele za promjene na živim sistemima (to znači da za promjenu poslovnog pravila, ne treba

promijeniti nikakav kod, to se sve čini kroz GUI ) i pojačana kontrola nad implementiranoj poslovnoj

logici, za saglasno i bolje poslovno upravljanje. [8]2

Za realizaciju našeg 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 uključuje real-time medijaciju i sveobuhvatno upravljanje

CDR-ovima u slučaju greški, zajedno s drugim poboljšanjima. No, ova verzija još uvijek ne pruža sve

funkcionalnosti sistema za upravljanje obračunom, poput podrške za više procesa medijacije,

poslovnih planova , specijalnih cijena i dr. Ova verzija još uvijek služi kao osnova istraživačima u ovom

polju.

3.1 jBilling arhitektura

jBilling arhitektura se sastoji od četiri odvojena dijela:

Klijent obavlja sve interakcije s korisnikom (korisnički 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-view-

controller za web bazirane aplikacije pisane u Javi, tako da korisnici pristupaju sistemu

koristeći web preglednik, koji se spaja na web server gdje su JSPs (engl. JavaServer Pages)

deploy-ane.

Server je nositelj poslovne logike i jedino on može da komunicira sa ostala tri

nivoa. On prima zahtjeve od klijenta, te odgovara na njih tako što vrši 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 razgraničenja na transakcijskim granicama, 2 Cjelokupan drugi dio rada je baziran na jBilling dokumentaciji preuzetoj s web stranice:

http://www.jbilling.com/

http://www.jbilling.com/features/compare-editions



23

integracija s Hibernate-om, JMS, itd. Sve što je potrebno je pokrenuti Java web server.

Moguće je pokrenuti ga na bilo kojem aplikacijskom serveru, kao jednostavnu Java aplikaciju.

Važno je napomenuti da je u početku, jBilling pokretao kao EJB (engl. Enterprise Java Beans)

aplikacija, koji se pokreće samo na JBoss. jBilling je danas Spring aplikacija, ali njen početak u

EJB svijetu je ostavio 'ožiljke' u kodu. Ključni framework za korištenje su Spring i Hibernate, a

standardno implemenitranje koristi Tomcat i ActiveMQ.

Baza podataka je RDBMS (engl. Relational Database Management System) engine koja drži

sve podatke. Zadužena 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 početku,

jBilling se pokretao na PostgreSQL, koji je prilično snažan i open-source. Vrlo lahko je

pokrenuti jBilling na bilo kojoj drugoj mašini, koja podržava ANSI SQL. Postoji nekoliko načina

pristupa bazi podataka: kroz Hibernate persisted klase, Hibernate HQL queries, Hibernate

criteria queries i preko JDBC poziva. Hibernate je preferirani način za pristup bazi podataka.

Business Rules Plug-ins važni su kod sistema za naplatu koji žele uvesti dodatna pravila plana

obračuna. Dizajnirani su kao Java interfejsi. jBilling samo zna o postojanju tih interfejsa, a ne

zna ništa o njihovim stvarnim implementacijama.

3.2 Model baze podataka

jBilling_table sadrži popis svih tabela unutar jBilling šeme. Ova lista tabela se koristi za formiranje

proizvoljnih asocijacija za bilo koju tabelu unutar sistema. Ovo je važno u nekim slučajevima poput

jedinstvene translacijske tabele, jer bi bilo veoma kompleksno imati ključ ograničenja za svaku

moguću tabelu mapiranja u sistemu [10].

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

Primjer jBilling_table je dat u nastavku.

Id Ime

10 'base_user'

14 'item'

21 'purchase_order'

itd.

Tablica 3.1 Primjer jBilling_table [10]


24

Parametar international_description table_id pokazuje na jbilling_table id. Ovo omogućava mapiranje

u ostale tabele unutar jBilling sistema. Ukoliko je vrijednost international_description parametra

table_id=14, označava se opis reda za item. Ako se posmatra foreign key constraint, parametar

table_id će se odnositi na tabelu kojoj se pridružuje, a parametar foreign_id će biti odgovarajući ID

pridružene tabele. Na primjer, vrijednosti international_description parametara table_id=14 i

foreign_id=100, označavaju opis reda za item sa ID vrijednošću 100. Parametar

international_description psudo_column je identifikator tekstualne vrijednosti. Svi opisi nisu označeni

kao „description“, u nekim tabelama se umjesto toga koriste „title“ ili „name“. Ovaj format tabela se

koristi u jBilling-u, tako da je lahko izvršiti identifikaciju pomoću parametara table_id i foreign_id.

3.2.1 Korisnici

Korisnici su smješteni u base_user tabeli. Korisnik može da bude partner ili kupac, u zavisnosti od

toga koju ulogu obavlja. Korisnik bez pridružene uloge kupca se smatra internim jBilling korisnikom,

kao što je administrator ili službenik.

Sl.3.2 Korisnici u jBilling bazi podataka [10]

Većina korisnika je opisana kontakt informacijama, koje su potrebne za naplatu. Međutim, ove

informacije nisu direktno povezane sa base_user. Tabela kontakata je struktuirana tako da kontaktne


25

informacije mogu biti povezane sa bilo kojim record-om u bilo kojoj tabeli, kroz sistem. Trenutno,

jBilling samo dozvoljava korištenje kontaktnih informacija kupaca.

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

Možemo uočiti da contact_map tabela sadrži slične 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 način.


26

3.2.2 Item-i

Svi item-i naloga unutar jBilling-a su smješteni unutar item tabele. Cijena ovih item-a je smještena

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 smješten u item_type i item_type_map tabelama. Item-i mogu

pripadati većem 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 račune kao linije (invoice_line ili order_line tabele) koristeći ID item-a

kao povratnu referencu. Kako se item-i mogu mijenjati tokom vremena, linije jBilling naloga i računa

uvijek imaju cijenu i opis. Podatke o item-ima jBilling koristi samo za postavljanje vrijednosti linija

item_price i item_id. Ovo znači da linija uvjek pokazuje šta se tačno naplaćuje, bez obzira na trenutne


27

promjene item-a (npr. promjene cijene, promjena opisa item-a, itd). Item-i ne sadrže „description“

polje. Svi tekstualni opis unutar jBilling-a dolaze iz tabele international_description. Opisi se sadrže od

više detalja u jbilling_table i Textual Description dijelu.

3.2.3 Purchase Order

Kupovni nalozi (engl. Purchase order) predstavljaju sve troškove za kupce, uključujući pretplate i

jednokratne kupovine. Kupovni nalozi se mogu kreirati ručno kroz korisnički interfejs ili kroz proces

medijacije nakon što se učitaju ulazni podaci u sistem.

Sl.3. 6 Model kupovni nalozi u jBilling bazi podataka[10]

Nalozi mogu imati nekoliko stanja, označenih u status_id koloni:

Id Status

16 Aktivan, ovaj nalog može generisati račune.

17 Završen, ovi troškovi naloga su uključeni u

obračun i neće se više koristiti.

18 Suspendiran, ovi nalozi neće genersati račune.

19 Suspendiran-Star, nalog je suspendiran od

strane procesa starenja (korisnik ima

nepodmirene troškove).

Tablica 3.2 Stanja naloga [10]


28

Svaki nalog sadrži skup linija naloga, gdje ove linije predstavljaju kvantitet item-a koji je kupljen na

osnovu utvrđene cijene. Cijena linije naloga moža biti drugačija od one u osnovnom item-u. jBilling

osnovni item koristi samo za inicijalizaciju linije naloga, promjene cijene, popuste i druge događaje

koji se javljaju nezavisno. Sami nalozi se ne plaćaju, oni jednostavno predstavljaju troškove nastalih

od strane kupca. Proces naplate periodično kreira račune (koji se plaćaju) na osnovu kupovnog

naloga korisnika. Ovo se može pratiti putem order_process tabele, koja povezuje naloge sa računima.

3.2.4 Računi

Kao što se item-i koriste za kreiranje linija naloga, tako se i nalozi koriste za kreiranje računa. Ne

postoji direktna veza između naloga i računa, kao i između order_line i invoice_line. Nalozi i računi

sadrže mnogo istih podataka (plaćen, obrisan, itd.) i ponavljajući nalozi mogu generisati više računa,

te onda jBilling kopira podatke iz naloga u račun, prilikom kreiranja.

Sl.3. 7 Model računa u jBilling bazi podataka [10]

Računi ne predstavljaju uvijek troškove za jedan period. Ako račun za prethodni period nije plaćen ili

je samo djelimično plaćen, preostali iznos je uključen u parametar carried_balance. U ovom slučaju,

prethodni račun je označen kao „carried“, a novi račun predstavlja trenutno troškove koje korisnika

treba da plati. Kao i nalozi, računi mogu imati nekoliko stanja, označenih u status_id koloni:

Id Status

26 Plaćen

27 Neplaćen

28 Neplaćen i označen kao „carried“

Tablica 3.3 Stanja računa [10]


29

Parametar balance predstavlja ukupan iznos za pojedini račun, uključujući i carried_balance. Kada se

plati račun, iznos je smanjen na iznos za plaćanje. Ukoliko je ukupan iznos jednak nuli, smatra se da je

račun plaćen. Uplate za račune se vrše kroz payment_invoice tabelu.

3.2.5 Plaćanja

Sl.3. 8 Modeli plaćanja u jBilling bazi podataka [10]

jBilling podržava više oblika plaćanja: kreditnom karticom, automatic clearing house (ACH) direct

bank transfers, i plaćanje čekom. U većini slučajeva, način plaćanja je unaprijed određen (ACH i

kreditnom karticom), i plaćanja se vrše pomoću odgovarajućeg procesora plaćanja. Najčešće se

plaćanje vrši pomoću kreditnih kartica ili ACH, a nakon što se izvrši uplata preuzima se izvještaj o

uplati. Ukoliko je povratni izvještaj uspješan, račun se smanjuje za iznos uplate.


30

Sl.3. 9 Model platnih naloga u jBilling bazi podataka [10]

U slučaju plaćanja čekom, stvari funkcionišu malo drugačije. Kod plaćanja čekom, prvo se kreira

record plaćanja, zatim se doda payment_info_check record, tako da izvor uplate može biti praćen. U

svim slučajevima, record plaćanja prikazuje tačno koliko je plaćeno, kada i od koga je plaćeno.

Općenito, isplate su napravljene na računu, međutim, to nije uvijek slučaj. Uplate se mogu vršiti za

cijeli račun, ostavljajući pozitivan iznos umjesto negativnog. U ovim slučajevima, jBilling će prvo

pokušati primijeniti plaćanje svih neplaćenih računa. Preostali iznos će se koristiti u sljedećem

računu, koji se generira. U tim slučajevima, mogu se vidjeti višestruki unosi u payment_invoice tabeli.

Kreditne kartice i ACH plaćanja će uvijek imati pridružen payment_authorization record. Autorizacija

sadrži sve detalje transakcije, uključujući kodove grešaka, poruke odgovora i ostale detalje vraćene

od strane procesora plaćanja.

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.


31

Sl.3. 10 Model kreditne kartice u jBilling bazi podataka [10]

Mnogi gateway-i plaćanja prevazilaze potrebu za pohranu broja kreditne kartice (čak i u šifriranom

obliku), tj. pružaju ID transakcije ili ID pohrane, koji se mogu koristiti za buduća plaćanja 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 (nešto 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 događaja 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]


32

Zapisi se mogu nalaziti u nekoliko stanja označenih parametrom status_id:

id status

29 Done and billable

30 Done and not billable (no line was added)

31 Error detected

32 Error declared

Tablica 3.4 Stanja zapisa [10]

Svaki mediation_record, koji je dodan kao jedna linija naloga, ima pridružen mediation_record_line

ulaz. Parametar mediation_record_line prikazuje koji item je dodan u liniju naloga i u kojoj količini.

Treba imati na umu da će order_lines istog item-a biti spojene zajedno u istu liniju. Ovo znači da će

više mediation_record_line unosa upućivati na istu order_line. Parametar mediation_record_line se

može posmatrati kao historijski zapis svih događaja 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, omogućiti izvršivost svih fajlova s ekstenzijom .sh i pokrenuti jBilling pomoću

naredbi:

chmod +x *.sh

./startup.sh

Nakon toga treba otvoriti browser i unijeti sljedeću adresu: http://localhost:8080/jbilling/ , pojavit

će se prozor kao na sljedećoj slici. Logovati se s LoginID='admin', password = '123qwe' i Company =

'Trend'.

http://sourceforge.net/projects/jbilling/files/latest/download

http://localhost:8080/jbilling/


33

Sl.3.12 jBilling web GUI

Verzija 3.0.2 jBilling community ima implementiran i Drools-Guvnor BRM unutar instalacije, tako da

nije ništa potrebno dodatno instalirati već samo u browser unijeti adresu:

http://localhost:8080/drools-guvnor/ i pojavit će se prozor kao na sljedećoj slici. Logovati se s

username='admin' i password = '123qwe'.

Sl.3.13 BRM GUI

http://localhost:8080/drools-guvnor/


34

3.4 Medijacija u Community jBilling-u

Kako je navedeno u prvom dijelu postoje dva tipa medijacije: post-paid medijacija (pasivna) i real-

time medijacija (aktivna.

3.4.1 Pasivna medijacija

Proces pasivne medijacije u jBilling-u predstavljena je na sljedećoj slici.

Sl.3.14 Pasivna medijacija [8]

1. Vanjski sistem pruža uslugu korisniku. To je obično telefonski switch za telefonske pozive, ali

to može biti i bilo koji drugi sistem, poput web servera za posluživanje sadržaja korisnicima

interneta.

2. Vanjski sistem spašava zapise događaja s detaljima pružene usluge korisniku u bazu

podataka. Baza je obično tekstualna datoteka, ali također može biti RDBM baza ili drugi tipovi

skladišta.

3. Interni jBilling raspoređivač započinje medijacijski proces. To se događa periodično, obično

jedanput dnevno. Proces medijacije će pronaći konfigurirane plug-in-ove, koji posjeduju

logiku o tome kako čitati događaje i što učiniti s njima. Ova komponenta je 'orchestrator', tj.

ne zna kako se izvršava 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 čitača plug-ina.

4. Čitatač plug-ina zna čitati događaje: njihov položaj, format, kako podijeliti zapis u smislena

polja podataka. Ipak, on je ograničen samo na čitanje. Čitatač ne zna značenje polja tih

podataka.

5. Grupa pročitanih zapisa vraća se medijacijskom procesu kao Java objekti.


35

6. Medijacijski proces šalje podatke o zapisu događaja procesoru plug-ina.

7. Procesor plug-in može odlučiti što će učiniti s zapisom. Standardna implementacija je plug-in

na bazi pravila. To znači da će se koristiti BRMS za obradu događaja. 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 plaća ovaj događaj.

8. Procesor vraća procesu medijacije podatke u obliku pogodnom za čitanje tj. identifikacija

predmet prodaje, vrijeme zbivanja događaja i korisnika koji učestvuje u događaju.

9. Proces medijacije sada može napraviti jednostavan zahtjev jBilling jezgri za stvaranje ili

ažuriranje naloga. Ovaj posljednji korak omogućava sistemu za naplatu da ažurira svoju bazu

podataka u skladu s aktivnošću koju je korisnik učinio 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 slučaju 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 jBilling-

u. Čitatači plug-ina imaju samo zadatak da pročitaju zapise od vanjskog sistema i da ih spreme. Ako

to nije potrebno, onda nisu potrebni čitatači plug-in-a. Vanjski sistem zove jBilling svaki put kada se

desi događaj (ili će se dogoditi). Real-time poziv se obavlja pomoću standardnog jBilling API (obično

koristi SOAP kao protokol). Postoje određene metode u API-ju koje omogućuju obradu događaja

procesom medijacije. Važno 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 pročitana od strane čitača, ili su

došli kroz API u stvarnom vremenu. To je važno, zbog činjenice da se ne mjenja konfiguracija

medijacije, bez obzira na mehanizam isporuke CDR-a ili izvora CDR-a. Ovo omogućava držanje oba

tipa medijacija na jednom mjestu.

Sl.3.15 Aktivna medijacija [8]


36

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 mjesečne

naknade od 10 KM. Cjelokupan iznos mjesečne naknade se prebacuje na pre-paid račun i na

raspolaganju je korisniku za sve vrste saobraćaja/usluga koje se plaćaju kroz pre-paid račun. Ovaj

paket uključuje:

1000 besplatnih minuta prema brojevima iz BH Mobile mreže, uz naplatu uspostave poziva

(0,06 KM);

250 MB mobilnog Internet saobraćaja na flat principu;

unutar BH Mobile mreže i prema drugim mobilnim mrežama u BiH po cijeni od 0,20 KM/min

za pozive iznad uključenih 1000 minuta;

prema fiksnim mrežama unutar BiH po cijeni od samo 0,12 KM/min za pozive iznad

uključenih 1000 minuta;

cijena SMS-a unutar BiH iznosi 0,06 KM po poruci, a za pretplatnike ovog paketa samo 0,03

KM;

cijena korištenja Interneta je 0.18 KM/MB.3

3.6 Realizacija testnog scenarija

Medijacijski proces omogućava jBilling-u da pročita zapise o događajima iz vanjskog izvora, koji ih

transformiše u oblik pogodan za obračunavanje. Kroz ovo poglavlje opisat će se svi koraci pri

konfiguraciji medijacije uz pridržavanje vlastitog poslovnog plana.

3.6.1 Medijacijski proces

Medijacijski proces se može podijeliti na tri različite 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 ograničena na tekstualnim fajlovima, FixedFileReader za zapise fiksne

dužine, JDBCReader za čitanje iz baze podataka i MySQLReader koji pruža jednostavnu konfiguraciju

za MySQL baze podataka.

Medijacijski format definira dolazeće 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.

3 U radu smo poistovjetili Američki dolar s Konvertibilnim Markama KM, jer već kreirana kompanija Trend po

default-u koristi ovu valutu.


37

Posao dodavanja medijacijskih događaja 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 specifičnih medijacijskih paketa pravila, on također aktivira item management

i pravila cjenovnika. Na taj način, omogućeno je da se kompletna poslovna logika i pravila cjenovnika

primjene na korisničke naloge. Medijacijski format prihvaća paket pravila i izvršava ih istovremeno.

Iako izgleda kao asinhron pristup, realnost je drugačija, tj. pravila se uvijek izvršavaju u predvidljivom

slijedu. Ovo je moguće zbog činjenice da item pravila ovise od identifikatora korisničkog naloga i ne

izvršavaju se dok ih medijacija ne doda u liniju naloga. Pravila cjenovnika se ne izvršavaju sve dok se

ne pošalje zahtjev za njima (slika 3.16).

Sl.3.16 Veza medijacija-item pravila-cjenovnik [8]

3.6.2 Defincija medijacijskog formata

Svi čitatači plug-in-i prihvataju medijacijski format definiran kao XML file koji opisuje dolazeće

podatke (događaje). Medijacijski XML format mora biti u skladu s fajlom mediation.dtd koji se nalazi

u direkoriju /jbilling/resource/mediation/, dok njegov sastav može biti korisnički definiran.

Medijacijski format je opisan preko <format> taga, a sadrži jednu ili više <field> sekcija. Svaka <field>

sekcija definira dio podataka koji će biti parsiran od dolazećih podataka. <field> elementi mogu

sadržavati sljedeće child elemente:

<name>#CDATA</name> - ime parsiranog elementa;

<type>(string|integer|float|date)</type> - tip podataka sadržanih u ovom polju;

<startPosition>#CDATA</startPosition> - početna pozicija u polju, koristi se za odabir

podniza i dostupna je samo za formate s fiksnom dužinom;

<length>#CDATA</length> - broj karaktera uključenih u ovo polje počinjući od startPosition,

dostupan samo za formate s fiksnom dužinom;

<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);


38

<isKey/> - označava polje kao dio jedinstvenog ključa koji identificira zapis koji se čita. Key

polje se koristi kako bi se odredio način procesiranja zapisa događaja. Ovo polje je obavezno i

dopušta jBilling-u filtriranje duplikata. Ako se više polja označi kao <isKey/> elementa, jBilling

će grupirati sva ta polja u kompozitni Key.

Kako paket Student Plus 1 uključuje tri različita tipa usluga, potrebno je formirati zaseban XML fajl za

svaku od tih usluga. CallFormatCDR.xml opisuje format za obradu poziva, SMSFormatCDR.xml opisuje

način parsiranja SMS događaja, a InternetFormatCDR.xml način parisanja Internet događaja. Ovi

fajlovi dati su u prilogu. Izgled XML fajla CallFormat.xml je sljedeći:

<?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>


39

</field>

</format>

Kao Key elemenat definisali smo event_id. Za polje Duration se pretpostavlja da ima vrijednost u

minutama.

Zapisi događaja od vanjskog izvora su zapisani kao .csv fajlovi, bazirajući 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 sljedeća 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 djelimično različit od drugih jBilling plug-in-a. Kao prvo, ne zanima ga šta

predstavljaju zapisi koje procesira. Kao drugo, jBilling ne ulazi u samu konfiguraciju čitača kao što je

slučaj s drugim plug-in-ima. On samo kroz konfiguraciju medijacije određuje koji će se čitač koristiti za

procesiranje zapisa događaja. Ovo omogućava da imamo više medijacijskih konfiguracija sa zasebnim

čitačima, što može biti vrlo korisno ako postoji nekoliko izvora događaja. Za konfiguraciju medijacije

potreban je ID plug-in čitača. Na ovaj način, medijacijski proces zna koju klasu pozvati kod čitanja

zapisa. U jBilling-u veza između konfiguracije medijacije i čitača je jedan na jedan i ako je potrebno

definisati više čitača onda je neophodno kreirati i više konfiguracija medijacije. Kao čitač, mi smo

koristili SeparatorFileReader. Za odabir čitača potrebno je kliknuti na Configuration, zatim u lijevom

dijelu prozora kliknuti na Plug-ins, u listi pronaći Plug-in Mediation Reader

com.sapienter.jbilling.server.mediation.task.SeparatorFileReader, kliknuti na njega i onda na

button Add new za kreiranje novog čitača, pojavit će se prozor kao na sljedećoj slici.


40

Sl.3.17 Kreiranje čitač plug-ina i njegovih parametara

Kao što je već rečeno, SeparatorFileReader čita tekstualne fajlove, gdje su polja odvojena stringom,

po default-u se podrazumjeva zarezom (,). Polje Order određuje prioritet čitača, tj. ako postoji više

čitača, a prvo će čitati onaj čitač s manjom Order vrijednošću. Ovaj čitač kao parametre koristi:

format_file je jedino obavezan parametar, označava format zapisa događaja 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 događajima s .csv na .done sufiks.

Ostali opcionalni parametri su:

format_directory označava lokaciju fajla formata zapisa događaja;

dateFormat definira format koji čitač koristi za konvertovanje 'date' tipa u Java Date

vrijednost. Prihvata formatiranje paterna koristeći klasu JavaSimpleDataFormat. Default-ni

format je yyyyMMdd-HHmmss;

Separator označava karakter koji se koristi za razdvajanje polja, po default-u je zarez;


41

Batch_size određuje 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 dopušta da polja mogu

imati zarez u svom sadržaju;

autoID je boolean paremater. Ako je postavljen na true, čitač će dodjeliti svim zapisima

vrijednost Key polja.

Bazirajući se na navedenim koracima, kreirali smo tri čitača za naš poslovni plan koji su dati na

sljedećoj slici. jBilling dodjeljuje ID svakom čitaču, koji će se pridružiti odgovarajućem procesu

medijacije.

Sl.3.18 Kreirani čitači plug-in-a

3.6.4 Konfiguracija medijacije

Konfiguracija medijacije govori procesu medijacije gdje su smješteni zapisi događaja i kako da ih

pročita, pokazajući na plug-in koji zna kako obaviti ove zadatke. Potrebna je barem jedna

konfiguracija medijacije da bi medijacijski proces uradio nešto. 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 odgovarajući plug-in i kliknuti na

dugme Save Changes, kao na slici 3.19.


42

Sl.3.19 Konfiguracija medijacije

ID se sistemski kreira. Kako bi procesirali pozive, Internet sadržaj i SMS poruke, neophodno je kreirati

tri konfiguracije. To podrazumjeva da su ta tri tipa događaja pohranjena u njihovim vlastitim

fajlovima i formatima. Order broj pokazuje koja komponenta medijacije će se koristit prva. Plug-in ID

pokazuje na čitača 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 našeg scenarija potrebno je kreirati tri jBilling aplikacije( tj. rapakovati skinuti jBilling zip

fajl u tri različite mape) i svakoj kreiranoj aplikaciji dodjeliti odgovarajuću konfiguraciju medijacije,

drugim riječima community verzija omogućava podršku za medijaciju samo za jedan tip usluge. U

daljem radu mi ćemo opisivati način na koji bi se naš scenarij realizovao u Telco jBilling-u, dok će se

oni dijelovi koji nisu podržani u community jBilling naglasiti.).

Kada se doda konfiguracija medijacije, proces postaje živ. Medijacija se pokreće na isti način 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. Podešavanje

procesne frekvencije vrši se editovanjem fajla jbilling.properties koji se nalazi u /jbilling/conf/

direktoriju. Dakle, vrijednost varijable process.frequency se postavlja na 4. Proces medijacije se

pokreće 4 minuta nakon što je sistem startovan i ponavlja se periodično svakih 4 minuta. Također,

unutar ovog fajla podešava se proces pokretanja medijacije na true (tj. process.run_mediation=true,

dok su ostali procesi postavljeni na false jer nisu relevantni za naš zadatak).


43

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 može također biti promocija,

kamata, provizija, porez ili bilo što drugo što faktura može sadržavati. Kreiranje item-a i item-

kategorija je prvi zadatak koji se mora uraditi da bi izvršili 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 sljedećoj 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 može se odabrati Items, Tax ili Penalty.

Nakon kreiranja kategorije produkta, moguće je dodati nove proizvode u tu kategoriju. Klikom na

odgovarajuću kategoriju, a potom u desnom donjem uglu na button Add Product otvorit će se prozor

kao na sljedećoj slici.


44

Sl.3.21 Dodavanje novog proizvoda u određenu kategoriju

Product ID se sistemski dodjeljuje.

Product Code polje označava kod proizvoda. Ako su item-i jako važni za fakturu, može se koristiti

sljedeći način njihovog kodiranja. Ako želimo da se svi normalni item-i pojavljuju prvi, a potom svi

popusti i provizije možemo iskoristiti označavanje 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 računu.

Categories predstavlja selektovanje proizvoda s jednom od kreiranih kategorija.

Excluded Categories predstavlja kategorije koje ne sadrže ovaj produkt (ova opcija trenutno nije u

funkciji u ovom release-u jBilling community).

Line Precentage pokazuje dodatnu cjenu koja se dodaje na uslugu, izračunava kao postotak od

ukupne cijene.

Allow Manual Pricing odnosi se na dozvolu ručnog mjenjanja cijene usluge pri obračunavanju.

Price označava cijenu usluge u United States Dollars jedinicama. Ako je uključeno polje Precentage

ovo polje mora biti prazno.

Na sljedećoj slici je predstavljena lista proizvoda unutar kategorije Student Plus 1. ID svakog Item-a je

važan za pisanje pravila, što je objašnjeno 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 možemo uraditi jeste samo kreirati kategoriju proizvoda.


45

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 računa koje jBilling generiše. Oni se loguju na jBilling da

vide svoje račune, ažuriraju svoje kontakt informacije (adresu, broj telefona, itd.), mijenjaju svoje

podatke o kreditnoj kartici, dostavi plaćanja, itd. Podaci o korisnicima moraju biti unešeni u sistem,

prije nego što počnete sa obavljanjem narudžbe. Unos podataka o korisnicima je obično drugi korak u

dobivanju jBilling set-up, odmah nakon što su uneseni item-i. Za svrhu implementacije našeg

scenarija kreirat ćemo jednog korisnika, koji će biti pretplatnik paketa Student Plus 1, također 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 sljedećoj slici.


46

Sl.3.23 Kreiranje novog korisnika

Login Name/Password - ime i prezime za logovanje omogućava korisniku da dobije informaciju o

svom obračunu. Ova informacija može biti uključena na računu 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 zašto je

ovo polje tako važno u jBilling-u je zato što je sistem mnogo efikasniji kada korisnike može lahko (i

jeftino) kontaktirati, kako bi ih obavijestio o obračunskim događajima: novi obračun, podsjetnik

obračuna, rezultat plaćanja, itd.

Currency - odabir željene valute s kojom će ovaj korisnik da radi.

Partner ID - ako je ovaj korisnik proglašen 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 – uključuje se jedino ako će ovaj korisnik imati podračune.

Balance Type - označava tip korisnika pre-paid, post-paid, Credit Limit.

Due Date – određuje vremenske trenutke slanja faktura jednom od selektovanih Invoice Delivery

Method.


47

U desnom dijelu unose se kontaktne informacije za određenog korisnika, koje mogu biti uključene u

notifikacije.

Lista korisnika sa njihovim ID-ovima, kao i osobine novog kreiranog korisnika dati su na sljedećim

slikama.

Sl.3.24 Lista korisnika

Sl.3.25 Osobine novo-kreiranog korisnika


48

Sl.3.26 Dodavanje proizvoda paketa Student Plus 1 korisniku4

Sl.3.27 Novo-kreirani korisnik i njegov račun

4 jBilling community ne podržava planove, te iz tog razloga nemoguće je u ovoj verziji jBilling korisnika učiniti

pretplatnikom paketa Student Plus 1. No, mi ćemo bez obzira na ovo napisati ItemManagement pravila kao da je to moguće, samo u cilju ilustracije kako to sve izgleda u onoj verziji jBilling-a koja podržava i planove, kao i istovremeno korištenje više konfiguracija medijacije.


49

Bitno je primjetiti da je kod novog korisnika Erma Perenda, uključen flag Main Subscription. Značenje

ovog flaga je sljedeće: za svaki događaj korisnik će dobiti po jedan račun, iako je ovo neefikasno u

praksi, gdje se obično mjesečno kreira po jedan račun, odnosno svaki zapis događaja update-uje

postojeći račun. No, mi smo ovaj flag uključili iz razloga ilustracije kreiranja novih računa.

3.6.7 Procesiranje s pravilima

U jednom trenutku medijacije, zapisi događaja su spremni za obradu. Čitač zapisa pruža zapise

događaja iz baze događaja, te se sada javlja potreba da se nešto uradi sa ovim zapisima. Stoga,

trebamo dati značenja 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 znači da je stvarna logika onoga što plug-in radi proširena do poslovnih

pravila upravljanih od strane Drools uređaja pravila.

Medijacijski plug-in omogućava korištenje tri različita tipa pravila:

1. Medijacijska pravila – čine osnovnu interpretaciju sirovih podataka koji dolaze sa čitača.

2. Item management pravila – dijelovi sa planom, komponentom i pravilom.

3. Pricing pravila – pridružuju cijenu onim item-ima koji trebaju različitu cijenu baziranu na

nekim podacima prisutnim u CDR-u.

Medijacijska pravila

Kao ulaz, plug-in uzima zapis događaja (tip Record), te je sa ovog ulaza odgovoran za:

Kreiranje jednog ili više linija naloga sa item-ima i količine onoga što korisnik koristi. Ovo je

translacija sa zapisa događaja na stvarne item-e i količine.

Određivanje jBilling korisnika. Događaj predstavlja akciju koja je urađena od strane korisnika.

Drugim riječima, koje naloge kupca treba ažurirati?

Određivanje valute. Budući da je događaj obrađen, jBilling treba da zna koja valuta se odnosi

na korisnika.

Određivanje datuma događaja.

Kao što se može vidjeti, odgovornosti ove komponente su osnova medijacijskog procesa. On

preuzima zapise događaja bez ikakvog značenja (samo povoljno pretvorenih u Java objekte pomoću

čitača) i na osnovu podataka iz zapisa, vrši pretvaranje zapisa u oblik koji razumije sistem naplate.

Plug-in neće ažurirati nikakve naloge u informacijama o bilo kojem korisniku, ali će obezbjediti sve

potrebne podatke za medijacijski proces, da to učini.

Item management pravila

Ova pravila su obično smještena u posebnim paketima. Odnosno, grupisana su zajedno u BRMS-u

ili u posebnoj datoteci. Što omogućava korištenje 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 međusobno. Ona se mogu koristiti za


50

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 obično 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 važno

kada default-na cijena ne vrijedi za zapis događaja koji se obrađuje.

Pravila ćemo pisati pomoću Drools Guvnor GUI, pridržavajući se njegovih pravila pisanja. Drools

Guvnor će kompajlirati i učiniti dostupnim ova pravila jBilling-u, odnosno moguće je izvršiti 'rules

deployment'. Anatomija ovih pravila je jednostavno uslov s posljedicama tj.

when

#conditions

then

#actions

Ključna riječ when označava uslove, a then akcije koje će se preduzeti u slučaju 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 sljedećoj 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

odgovarajućih item-a. Potrebno je jedino napisati pravilo tipa Special Prices u okviru paketa

ItemManagement, kada je u pitanju uspostava poziva prema mobilnim mrežama u okviru 1000

besplatnih minuta.


51

Sl.3.28 Logika poslovnog plana

3.6.7.2 Koraci procesiranja zapisa događaja

Da bi se zapis događaja u potpunosti procesirao, moraju se proći neki koraci. Počevši od

dodjele korisnika događajima, do ažuriranja korisničkog računa. Neki koraci uključuju više akcija:


52

Sl.3.29 Koraci za potpuno procesiranje zapisa događaja [8]

1. Start – Proces započinje određivanjem korisnika i datuma. Dodatna pravila za provjeru

grešaka u zapisu događajau pripadaju ovom koraku.

2. After User – Korisnik je sada poznat. Valuta za ovaj događaj je postavljena.

3. Cuurent Order – Trenutni nalog za korisnika i datum događaja su preuzeti.

4. Item Resolution – Ovaj događaj je sada mapiran u jBilling item (proizvod). Opis događaja je

također dodan u kasnijoj listi događaja u dijelu detalja računa.

5. Pricing – Ako događaj ne može koristiti defalt-nu cijenu item-a, pravila koja mijenjaju ovu

cijenu se aktiviraju u ovom koraku.

6. Item Management – Planiranje bundles pravila.

7. Ažuriranje računa – Posljednji korak vodi brigu o ažuriranju korisničkog računa, sa naplatama

koje proizlaze iz događaja.

MediationResult objekat

jBilling prati rezultate za svaki zapis događaja kroz MediationResult objekat. MediatonResult objekat

zna trenutni korak u kojem se nalazi zapis događaja i svaku informaciju koja se prikupila do sada. Na

primjer, ako je zapis događaja u koraku 2, onda se može pretpostaviti da je postavljen userId. Većina

pravila teško da imaju interakciju sa ovim objektom. Ne trebaju se poznavati sva polja ovog objekta,

ali je dobro upoznati se sa većinom od njih.

U nastavku je dat jedan primjer ovog objekta za svaki zapis događaja koji treba da se procesira u

memorijski sadržaj:


53

Sl.3.30 Primjer MediationResult objekta [8]

Korak 1: Start

Ovo je prvi korak. Rezultujući zapis događaja je uglavnom prazan, a cilj je da se postavi korisnik i

datum.

Ulazne varijable

Rezultujući zapis događaja je popunjen samo sa podacima koji su poznati sistemu od samog

početka. Svako drugo polje je prazno: oni će biti popunjeni po pravilima.

recordKey: jedinstveni identifikator zapisa događaja. On je postavljen od strane čitača plug-

ina.

configurationName: naziv konfiguracije medijacije. Ovo je korisno kada se javlja više različitih

konfiguracija: SMS, glas, podaci, itd.

Persist: boolean zastavica za indikaciju da li je zapis događaja „stvarni“ zapis događaja koji

treba da ostane ili ne. Ovo bi bilo neistinito u scenarijima gdje se poziva API metoda

„validatePurchase“, koja koristi medijacijski modul za rješavanje zapisa događaja, ali oni ne bi

trebali mijenjati korisnički račun. Ovo se prevodi kao „može li korisnik ovo da kupi“ radije

nego „ovaj korisnik je kupio ovo“. Za prvi slučaj važi da je persist=false, a za drugi da je

persist=true.

Izlazne varijable

userId: ID korisnika kojem događaj pripada.

eventDate: datum i vrijeme događanja ovog događaja.


54

Postavljanje userID: U Drools Guvnor GUI kliknuti na repozitorij Knowledge Bases, potom na Create

New->New Rule i pojavit će se prozor kao na sljedećoj 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.


55

Sl.3.32 Anatomija pravila 'user setter'

Postavljanje eventDate: Na već opisan način kreirati novo pravilo 'date setter', iste kategorije i u

istom paketu kao i pravilo 'user setter'. Anatomija ovog pravila je sljedeća:

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 riješeno postavljanje korisničkog ID i datuma događaja, možemo preći 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 sljedeća:

dialect 'mvel'

when

$result : MediationResult(step == MediationResult.STEP_1_START,


56

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 događaja i kada se isti desio, možemo da obavljamo bilo koji korak,

koji zahtjeva zapis događaja. Po default-u, ovo je samo za postavljanje valute.

Ulazne varijable:

userId: ID korisnika kojem događaj pripada.

eventDate: datum i vrijeme događanja ovog događaja.

Izlazne varijable:

currencyId: valuta na osnovu koje će se vršiti naplata ovog događaj.

Pravilo za postavljanje valute, koje smo koristili u našem scenariju ima sljedeći 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 sljedeći:

dialect 'mvel'

when

$result : MediationResult(step == MediationResult.STEP_2_AFTER_USER, currencyId != null,

currentOrder == null)


57

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

Dohvaćanje trenutnog naloga je obično korak koji se može ignorisati. Ovaj korak se može razmatrati

kao „unutarnji“ korak. Medijacijski proces sada treba da zna koji nalog da koristi prilikom dodavanja

troška za događaj.

Ulazne varijable:

currencyId: valuta na osnovu koje će se vršiti naplata ovog događaja.

Izlazne varijable:

currentOrder: nalog koji će jednom primiti troškove, dolazi od ovog događaja.

Kod za pravilo 'move step 3 to step 4' se nalazi u direktoriju knowlegde_bases/mediation i za potrebe

našeg scenarija, nije ga potrebno mijenjati.

Korak 4: Item resolution

Item resolution je osnova medijacijskog procesa. Ovo je mjesto gdje se vrši 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 troškove, dolazi od ovog događaja.

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 događaja u item,

koji je predstavljen kao linija naloga u jBilling-u.

step: umjesto korištenja pravila prelaska, step je obično postavljen u „then“ dijelu pravila na

step 5.

New pricing request – Ovo nije varijabla postavljena u MediationResult objektu, već zahtjev

za novom cijenom koji može zatrebati ubacivanjem objekta u memorijski sadržaj.

description: objašnjenje troškova koji dolaze sa događaja (opcionalno).

MediationResult objekat sadrži popis linija naloga koje se odnose na item-e korištene od korisnika.

Ovo znači da treba kreirati instancu objekta OrderLineDTO() popunjenu sa informacijama o

korištenju. Funkcija za dodavanje novih linija naloga je:

function OrderLineDTO newLine(Integer itemId, BigDecimal quantity) {


58

OrderLineDTO line = new OrderLineDTO();

Line.setItemId(itemId);

line.setQuantity(quantity);

line.setDefaults();

return line;

}

Događaj se obično mapira u jedan item, ali i ne mora. To je razlog zašto je varijabla „lines“ zapisa

događaja List.

Primjer korištenja 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. Također, slično ovom pravilu

kreirana su i sljedeća 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());

Važan dio ovog pravila je da vrijednost Pricing polja 'quantity' se postavlja direktno na vrijednosti

'duration' polja CDR. Pravila pretpostavljaju da se ovo postavljanje vrši za svaki CDR čiji je itemID

2200.

Pravilo prelaska sa koraka 4 na korak 5 ne zahtjeva posebno razmišljanje. Prvi faktor je da svi CDR-ovi

ne trebaju pricing korak, jer se u nekim slučajevima primjenjuje defalt-na cijena. Drugi faktor je ako


59

želite da se pricing pravila koriste ne samo u procesu medijacije, nego i od strane drugih područja

sistema (kao što je poziv prema API-ju prilikom kreiranja naloga). Ovo znači da pricing pravila ne

koriste MediationResult objekat u potpunosti. Ova pravila će se pokrenuti kada se detektuje

PricingRequest i uveliko odredi nalog koristeći propuste (drools atribut). Zadnje, ali ne i manje važno,

ako postoji samo jedno pravila za mapiranje zapisa događaja u item ID, onda je jednostavno i lagano

izvršiti sljedeći korak tamo. Međutim, ovo nije dobra opcija ako postoji više 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 izvršava medijacija. Budući da je objekat MediationResult samo za medijaciju, pricing korak

obično ne zavisi od tog objekta.

Pricing se obavlja korištenjem PricingResult objekta. Zahtjev za cijenom se traži dodavanjem instance

PricingResult objekta memorijskom sadržaju, a onda se preuzima cijena sa objekta za promjenu

cijene linije naloga, koja se doda u prethodnom koraku.

Ulazne varijable:

Nije primjenjivo: MediationResult nije uključen.

Izlazne varijable:

Nije primjenjivo: MediationResult nije uključen.

Pricing pravila se primjenuju sa višim prioritetom u odnosu na pravila koja pridružuju 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)


60

PricingResult(pricingFieldsResultId == $result.id ) # probably not needed

then

modify( $result ) {

setStep(MediationResult.STEP_6_ITEM_MANAGEMENT);

}

end

Korak 6: Item management

Ovaj korak je sličan prethodnom koraku po tome da pravila koja obavlja item management obično

pripadaju različitim paketima pravila, jer oni su također potrebni za akcije kao što su kreiranje naloga

sa API-ja. Kako god, rezultujući objekat se modificira u ovom koraku. Kada započne 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 računa o planovima koji se trebaju izvršiti.

Ulazne varijable:

lines: sa linijama naloga tačno postavljenih: item ID, quantity, cijena.

Izlazne varijable:

oldLines: ovo bi trebalo da sadrži linije trenutnih naloga, kao što su bile prije ikakvih

promjena koje su došle proceciranjem događaja.

CurrentOrder: trenutni nalog treba biti promijenjen, dodavanjem linije ili dodavanjem

„quantity“ postojećim linijama sa troškovima 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 događaje, ona su neki vid poslovnih uslova.

Naprimjer, ako imamo neki poziv prema mobilnoj mreži, 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 potrošio. 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());


61

update($order);

LOG.debug("Potroseno je od" + $quantity + " minuta od 1000");

U slučaju da imamo item '1000 besplatnih minuta', a korisnik je već potrošio te minute onda je

potrebno na korisnički račun primjeniti cijenu itema 'Pozivi prema mobilnim mrežama'. Način na koji

je to urađeno pomoću BRMS-a je sljedeći:

‘rule: 1000 potrosenih minuta’

when


$line : OrderLineDTO( quantity.intValue > 1000, itemId == 2200, $quantity : quantity) from

$order.lines


then

OrderLineBL.addItem($order, 2202, new Integer($quantity.intValue() - 1000), $pricing.getPrice());

update($order);

$line.setQuantity(1000);

LOG.debug("1000 minuta je potroseno.");

Vodeći se istom logikom, napisana su pravila '250 MB jos nepotroseno' i '250 MB potroseno'.

‘rule: 250 MB jos nepotroseno’

when





then



update($order);

LOG.debug("Potroseno je " + $quantity + " MB od 250 MB.");

‘rule: 250 MB potroseno’

when


62



$order.lines


then


update($order);


LOG.debug("250 MB je potroseno.");

Ova pravila se kreiraju unutar paketa ItemManagement, kategorija Plans i tip DRL Rule (Technical

rule-text editor).

Također, 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 sljedeća:

‘rule: Uspostava poziva’

when

result : PricingResult( itemId == 2200, price == null )

then

result.setPrice( "0.06" );

update( result );

Korak 7: Account Update

Posljednji korak jeste ažuriranje korisničkog računa. U ovom koraku se također vrši usporedba naloga

prije i poslije događaja, i ova informacija se čuva kao dio historije naloga. Ovo je korak koji obično ne

mora napraviti nikakve promjene standardnih jBilling pravila. Ovo pravilo pripada klasi „unutarnjih“

pravila.

Ulazne varijable:

currentOrder: kompletirano sa svim novim troškovima.

Izlazne varijable:

done: sada postavljeno na „true“.

diffLines: rezultat poređenja između starog i novog naloga.

Kod za korak 7 postoji po default-u i nije ga potrebno mijenjati.

Sada možemo rezimirati, kako se sve uklapa zajedno:

Čitač plug-ina čita .csv fajlove,


63

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, koristeći zajednički ID.

3.6.8 Rezultati medijacije

Nakon završetka medijacijskog procesa, dostupni su rezultati o tome šta se desilo sa svakim CDR-

om, koji se procesirao. Postoji nekoliko ishoda: zapisi proizvode neke troškove za korisnike, ili možda

sprječavaju dešavanje grešaka. Zapise koji se javljaju s greškama će spremiti jBilling, tako da se može

postaviti automatizirani način za njihovo reprocesiranje. Prvo, veoma je važno da se razumiju

rezultati koje jBilling identificira. Ilustracija važnosti ovih rezultata data je kroz naš scenarij.

Procesiranjem sljedećeg 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 sljedeća slika:

Sl. 3.33 Rezultati medijacije dobijeni procesiranjem Call.csv fajla

Ime procesa medijacije koji se pokreće je Call Mediation, a njegov ID je 30. Rezultati medijacije su:


64

Broj pročitanih (engl. Record Processed) događaja za pozive je 11 ,

Broj kreiranih računa (engl. Orders Affected) je 11,

Broj gotovih i naplaćenih (engl. Done And Billable) događaja za poziv je 11. Ovo je tipični

rezultat kojeg identificira jBilling: zapis događaja je uspješno procesiran (svi koraci uspješno

izvedeni) i preveden je u naplatu za korisnika. Da bi se ovo izvršilo, „done“ polje

MediationResult objekta treba da bude postavljeno na vrijednosti „true“ i „lines“ polje treba

da sadrži neke linije.

Broj gotovih i nenaplaćenih (engl. Done And Not Billable) događaja za poziv je 0. Ovaj

rezultat procesa medijacije kojeg identificira jBilling, daje broj uspješno procesiranih

događaja („done“ polje postavljeno na „true“), ali bez prisutnih linija. Tipičan primjer ovoga je

kada zapis događaja predstavlja događaj kojeg korisnik neće platiti, na primjer, poziv na koji

se ne odgovori.

Broj otkrivenih grešaka (engl. Errors Detected) u CDR-ovima je 0. Ukoliko je proces

medijacije završen, a vrijednost „done“ polja jednaka „false“, onda će jBilling smatrati da je

upitanje CDR sa greškom. Uvijek bi trebalo imati pravila koja će razmatrati svaki zapis

događaja i postavljati „done“ polje na vrijednost „true“. Proces medijacije će pokušati da

odredi razlog zašto ovaj zapis događaja nije uspio, dodjeljujući mu kod. Nakon toga će se ovaj

kod pohraniti sa cijelim zapisom događaja za ponovno procesiranje.

Broj proglašenih grešaka (engl. Errors Declared) je 0. Uvijek se teži tome da se posjeduju

pravila koja će pokriti sve moguće situacije u kojima se može naći zapis događaja. Ako postoji

greška koja se može detektovati, onda se može pomoću polja 'errors' u jBilling-u iz

MediationResults odrediti kakva je greška u pitanju. Mogu se napraviti liste grešaka, u kojima

se one čuvaju dok ne dođu na red za reprocesiranje. To polje je niz stringova, tako da se

može dodati bilo koji broj grešaka, koji će biti sačuvan kada se greške spreme radi ponovnog

procesiranja. Ne postoji granica u formatu ili broju grešaka koje se mogu dodati. Samo te

greške trebaju da imaju smisla. Greške koje rješava jBilling koristeći kod započinju sa „JB“,

tako da greške koje mi unosimo trebaju da počinju sa nečim drugim. jBilling će uzeti u obzir

sve zapise događaja koji pripadaju kategoriji greške (otkrivena ili proglašena), označeni kao

not processed. Ovo je važno da bi se sačuvao zapis u kojem se javila greška, radi kasnijeg

procesiranja, jer filter u jBilling-u se koristi da bi se izbjeglo procesiranje istog zapisa dva

puta, pa bi se u slučaju ponovnog procesiranja zapisa, isti odbacio. Normalni tok rada se

može svesti na sljedeće: pokretanje medijacijskog procesa, neki zapisi sadrže greške, a neki

ne, pregledaju se ovi zapisi sa greškama i ispravi se ono što je uzrokovalo problem, onda se

proces medijacije pokrene ponovo samo za zapise u kojime se javila greška.

Kako je već spomenuto za korisnika ErmaP označen je flag Main Subcription, kao i za korisnika

pbright, pa prema tome treba da se generiše jednak broj računa kao i broj pročitanih zapisa, što

dokazuju sljedeća slika. Na svaki račun primjenjena je taksa od 6%, tj. GST item kreirana od strane

Trend kompanije.


65

Slika 3.34 Lista kreiranih računa/order-a

Nakon završetka 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. Također,

pokretanjem SMS Mediation i Internet Mediation procesa s odgovarajućim SMS.csv i Internet.csv

fajlovima dobit će se slični rezultati.


66

ZAKLJUČAK

Upravljanje obračunom je backbone svakog telekom operatora. Ako operator nema jak

sistem za upravljanje obračunom, neće biti u mogućnosti da ponudi svoje usluge i proizvode sa

atraktivnom cijenom i neće se moći izboriti na današnjem konkuretnom i dinamičnom tržištu.

Medijacija igra veoma bitnu ulogu u sistemima za upravljanje obračunom, što je razlog zašto joj

mnogi proizvođači daju toliko pažnje, kako bi proizveli što efikasniji i sigurniji sistem za medijaciju

operatorima, a samim tim i dobijanje konkurentske prednosti na tržištu. S druge strane, mnogi

vjeruju da će open-source rješenja za medijaciju igrati sve važniju ulogu u budućnosti poslovnog

softvera. Imajući izvorni kod, operator može razviti dodatne funkcionalnosti da zadovolji svoje

potrebe i ovim putem može postići punu kontrolu sistema za naplatu.

Proces medijacije uključuje izvršavanje više procesa koji nisu baš jednostavni. U ovom radu

opisani su ti procesi, kao i način na koji su oni implemenitrani unutar jednog od open-source rješenja

za medijaciju, jBilling. Na osnovu priložene analize procesa medijacije u ovom alatu, uočava se svrha i

funkcija medijacije u cjelokupnom sistemu za obračun. Medijacijski uređaji su posredničke tačke

između korisnika s jedne strane i sistema za obračun s druge strane. Dakle, medijacijski uređaji su

uređaji koji korisnikovo korištenje usluge mapiraju u prikladne zapise događaja, koje sistem za

obračun koristi za izvršenje procesa naplate.


67

AKRONIMI

ASN.1 Abstract Syntax Notation One

API Application Programming Interface

CDR Call Detail Record

CRM Customer Relationship Management

ERP Enterprise Resource Planning

FTP File Transfer Protocol

GGSN Gateway GPRS support node

IP Internet Protocol

ISP Internet Service Provider

MSC Mobile Switching Center

MMSC Multimedia Messaging Service Center

MSS Maximum Segment Size

OMOF Order Management and Order Fulfillment

QoS Quality of Service

TCP Transmission Control Protocol

UDP User Datagram Protocol

UDR Usage Detail Record


68

LITERATURA

[1] Tomislav Grgić, Pregled sustava za terećenje telekomunikacijskih usluga u novoj generaciji mreža,

Zavod za telekomunikacije, Fakultet elektrotehnike i računarstva, Sveučilište u Zagrebu

[2] Web: http://www.tutorialspoint.com/telecom-billing/system-architecture.htm, pristup ostvaren

19.12.2012. god.

[3] Web: http://en.wikipedia.org/wiki/Billing_Mediation_Platform, pristup ostvaren 19.12.2012.

god.

[4] Avi Ofrane, Harte, Lawrencem Introduction to Telecom Billing, Usage Events, CDR and Bill Cycles,

2003.

[5]

Web: http://www.billingworld.com/articles/2004/06/mediation-systems-come-of-age.aspx#2

pristup ostvaren 19.12.2012. god.

[6] Ž. Močinić, G. Ivošević, D. Turk, Razvoj sustava za nadzor i upravljanje,2004.

[7] Web: http://www.cio.com.au/article/324595/5_open_source_billing_systems_watch/, pristup

ostvaren 19.12.2012. god.

[8] Web: http://www.jbilling.com/ , Telecom Guide, User Guide, pristup ostvaren 19.12.2012. god.

[9] Sohag Sarkar, Telecom Billing Solutions, Symbiosis Institute of Telecom Management, Pune.

[10] Web: http://www.jbilling.com/documentation/developers/database-model, pristup ostvaren 19.12.2012.god.

http://www.tutorialspoint.com/telecom-billing/system-architecture.htm

http://en.wikipedia.org/wiki/Billing_Mediation_Platform

http://www.billingworld.com/articles/2004/06/mediation-systems-come-of-age.aspx#2

http://www.cio.com.au/article/324595/5_open_source_billing_systems_watch/


http://www.jbilling.com/documentation/developers/database-model


69

Prilog

SMSFormatCDR.xml



<format>

<field>


<type>string</type>

<isKey/>

</field>

<field>


<type>date</type>

</field>

<field>


<type>string</type>

</field>

<field>


<type>string</type>

</field>

<field>

<name>quantity</name>


</field>

</format>

InternetFormatCDR.xml



<format>

<field>


<type>string</type>

<isKey/>


70

</field>

<field>


<type>date</type>

</field>

<field>


<type>string</type>

</field>

<field>


<type>string</type>

</field>

<field>

<name>quantity</name>


</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

Sadržaj paketa Mediation/Technical rule assests u Drool Guvnor Knowledge repozitoriju:

Kategorija: Mediation/Product

Rule ‘Resolve 1000 besplatnih minuta’

dialect 'java'

when



71





then


update( $result );


insert( request );

LOG.info("Resolve 1000 besplatnih minuta i poslat zahtjev za naplatu" + $result.getRecordKey());

Rule 'Resolve Internet free 250 MB'

when


$quantity : PricingField( name == "quantity", resultId == $result.id)




then


update( $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






72


then


update( $result );


insert( request );

LOG.info("Resolve Pozivi prema fiksnim mrežama I poslat zahtjev za naplatu" +

$result.getRecordKey());

Rule: ‘Resolve Pozivi prema mobilnim mrežama’

when






then


update( $result );


insert( request );

LOG.info("Resolve Pozivi prema mobilnim mrežama I poslat zahtjev za naplatu" +

$result.getRecordKey());

Rule:’Resolve Internet ’

when






then


73


update( $result );


insert( request );

LOG.info("Resolve Internet saobraćaj I poslat zahtjev za naplatu" + $result.getRecordKey());

Rule: ‘Reslove SMS’

when






then


update( $result );


insert( request );

LOG.info("Resolve SMS I poslat zahtjev za naplatu" + $result.getRecordKey());

Rule: ‘Resolve SMS za pretplatnike’

when






then


update( $result );


74


insert( request );

LOG.info("Resolve SMS za pretplatnike I poslat zahtjev za naplatu" + $result.getRecordKey());

Sadržaj paketa ItemManagement/Technical rule assests u Drool Guvnor Knowledge repozitoriju:

Kategorija: Plans

Rule: ‘1000 jos ne potrosenih minuta’

when





then



update($order);

LOG.debug("Potroseno je od" + $quantity + " minuta od 1000");

Rule: ‘1000 minuta je potroseno’

when



$order.lines


then


update($order);


LOG.debug("1000 minuta je potroseno.");

Rule:’250 MB još ne potrošeno’


75

when





then



update($order);

LOG.debug("Potroseno je " + $quantity + " MB od 250 MB.");

Rule:’250 MB je potroseno’

when



$order.lines


then


update($order);


LOG.debug("250 MB je potroseno.");

Rule: ‘SMS za pretplatnike’

when





then



update($order);


76

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 );

Documents

Ut m Proje Kt Mediation