U ovom tekstu obraÄ‘ujemo jedan konkretan sluÄaj u, nazovimo ga, Telecomu X. Problematika koju ćemo elaborirati vrlo je Äesta, koliko god to mnogi baÅ¡ i ne žele priznati, a radi se o nepovezanosti ICT sustava unutar jedne tvrtke. Pod sustavima se misli na ERP ( Enterprise Resource Planning ), CRM ( Customer Relationship Management ) i na sustave za provisioning tj. kontrolu ureÄ‘aja kod korisnika preko nekakvog centralnog sustava za odreÄ‘enu uslugu. Kako se odvijao proces rjeÅ¡avanja problema u kojima je Biztalk odigrao kljuÄnu ulogu?
-
U Äemu je bila problematika „Telecoma X“ ?
Kako bi korisnici mogli gledati odreÄ‘ene kanale, potrebno je na sustavu za digitalnu televiziju to i omogućiti. Problematika je bila u tome Å¡to sustav nije bio u nikakvoj povezanosti s drugim sustavima pa se svaki put, prilikom aktiviranja neke nove usluge ( novog kanala ) za nekog korisnika, moralo preko web suÄelja pronaći tog odreÄ‘enog korisnika, odabrati mu uslugu koju želi i tek tada ju aktivirati. Dakle, u potpunosti neautomatiziran, manualan rad. Ista situacija je bila i kod usluga telefonije i interneta koje su opet imale svoj zaseban sustav, s posebnom bazom korisnika i usluga. Uz navedeno, bio je ukljuÄen joÅ¡ jedan vanjski sustav ( koji je Telecomu X partner u pružanju telefonskih usluga ), a koji u konaÄnici zbraja minute razgovora, prati pozive itd… Telecom X je Äesto imao problema, jer se Äesto nije znalo da li je neka usluga kod korisnika ukljuÄena. Naime, nije bilo nikakvih podataka u ERP-u niti u CRM-u koji bi to sa sigurnošću potvrdili. Sve je ovisilo o tome da li je informacija na papiru doÅ¡la iz jednog ureda u drugi; npr. iz ureda gdje se neki korisnik telefonski pretplatio na neke usluge i ureda gdje su se onda ti podaci unosili u neki od provisioning sustava.
Kad je doneÅ¡ena odluka o izradi novog sustava, osim ideje o automatskom provisioningu, iÅ¡lo se i na novi ERP sustav i novi CRM sustav. Odabrani su Microsoft Dynamics NAV i Microsoft Dynamics CRM. Tako je doÅ¡lo i do novog izazova – sinkronizacije podataka izmeÄ‘u dva sustava.
Da bi situacija bila zanimljivija ( Äitajmo: kompliciranija ) tu se naÅ¡ao joÅ¡ i self care sustav putem kojeg korisnici mogu sami sebi napraviti zahtjev za ukljuÄenjem neke opcije na nekoj usluzi. Ni to nije bilo povezano s ostalim sustavima…
Kad se sve zbroji dobijemo ERP, CRM, digitalnu televiziju, sustav za provisioning prema modemima za internet i telefon, provider za telefoniju i self care sustav. Kako to sve povezati? Kao rjeÅ¡enje definirao se BizTalk Server 2006 R2. ZaÅ¡to BizTalk, a ne nekakvo custom rjeÅ¡enje koje bi povezalo baze navedenih sustava? Zbog toga Å¡to su sustavi na razliÄitim platformama ( Windows, Unix, Linux ), a po nekim sustavima se u bazu ne smije niÅ¡ta dodavati mimo definiranog API-a ( NAV i CRM ). „Ne smije“ zapravo znaÄi nije preporuÄljivo, poÅ¡to se dosta logiÄkih stvari odvija u API-ima navedenih sustava kao npr. sigurnosne provjere ( autentikacije i autorizacije ), generiranje kljuÄeva, razni vezani procesi (workflowi) itd…
Nadalje, BizTalk Server omogućuje komunikaciju preko gotovo svih postojećih komunikacijskih protokola pa su tako za ovu priliku koriÅ¡teni protokoli HTTP, SOAP, FTP, file sharing i MSMQ, ovisno s kojim sustavom se komunicira. U ovom sluÄaju BizTalk je postavljen kao centar preko kojeg ide sva komunikacija izmeÄ‘u sustava, Å¡to znaÄi da sustavi pojedinaÄno niti ne moraju znati jedan za drugog.
-
Primjer
Kad se promijeni zapis u NAV-u koji predstavlja korisnika, NAV poÅ¡alje zapis u obliku XML-a u outbound message queue. BizTalk proces „sluÅ¡a“ taj queue i u trenutku kad poruka stigne prosljeÄ‘uje ju onim sustavima koji su na nju pretplaćeni. U ovom sluÄaju je to CRM. MeÄ‘utim, prije nego je prosljeÄ‘ena on je prvo mora prilagoditi formatu kojeg CRM „razumije“ tj. poruka se mora transformirati u drugi XML format koji predstavlja korisnika u CRM-u. BizTalk tada zove web servis na API suÄelju CRM-a i prosljeÄ‘uje mu XML. Situacija u drugom smjeru funkcionira sliÄno s razlikom da sad CRM postavlja izmjenjeni podatak u MSMQ ( ili postoji opcija na file share ), BizTalk ga skuplja , transformira i prosljeÄ‘uje u inbound message queue NAV-a.
-
Provisioning
Proces provisioninga se pokreće iz NAV-a. Nakon što se za nekog korisnika definiraju usluge koje će imati, u outbound message queue se postavlja XML koji sadrži sve potrebne podatke za provisioning prema svima uslugama. Tako je omogućen istovremeni provisioning prema svim sustavima.
Dakle, BizTalk skuplja XML, prema njegovom formatu detektira da je rijeÄ o formatu za provisioning , rastavlja ga na tri dijela ( ako ima sva tri dijela ) i Å¡alje svaki dio na obradu prema procesima za obradu svakog pojedinog dijela. XML dijelovi se obraÄ‘uju neovisno i Å¡alju sustavima za provisioning neovisno jedan od drugog. Svaki od krajnjih sustava nakon Å¡to obradi zahtjeve, vraća odgovor o uspjeÅ¡nosti , te se ti odgovori opet preko BizTalka vraćaju u inbound message queue. NAV zaprima sva tri odgovora i potvrÄ‘uje da je proces provisioninga za korisnika uspjeÅ¡no obavljen.
-
Self Care
Self care radi na naÄin da korisnik preko web-a može sam sebi ukljuÄiti neke opcije odreÄ‘ene usluge, zahtjev se postavlja u MSMQ, BizTalk ga skuplja, transformira, prosljeÄ‘uje u CRM, koji ga onda opet kao dio prije definiranog procesa prosljeÄ‘uje u NAV.
Ovim su zatvoreni svi poslovni procesi koji idu preko BizTalk Servera. Uz sve to BizTalk ima ukljuÄen i Business Activity Monitoring koji prati sve zahtjeve za provisioning koji prolaze kroz njega i iz kojeg se naknadno mogu generirati izvjeÅ¡taji o broju zahtjeva, usluga itd…
Na ovaj naÄin uspjeÅ¡no su konsolidirani svi ICT sustavi omogućivÅ¡i brže i lakÅ¡e odvijanje poslovnih procesa unutar Telecoma X, a koji se tiÄu onih najosjetljivijih segmenata: korisnika i usluga.
Vas Komentar