Arhitekture za podrku elektronikom poslovanju Logika arhitektura el

Arhitekture za podršku elektroničkom poslovanju

Logička arhitektura • el. Poslovanje prelazi granice u poduzeću, ali i izvan njega • sustav za podršku mora omogućiti složena rješenja, promjenjivost, skalabilnost i brzinu

5 slojeva • • • Kor. Sučelje Aplikacija Poslovna logika Pristup podacima Baza podataka

Tehnologije slojeva arhitekture (korisničko sučelje, aplikacija) Autori: Branko Đakulović Marina Ivančević Darko Jamnić Sveučilište u Zagrebu, Fakultet organizacije i informatike Varaždin, Elektroničko poslovanje 2006/07

Sadržaj • • • HTML – uvod, povijest, struktura i sintaksa DHTML – DOM, CSS, skriptni jezici WBS – web servisi ASP – objekti, primjer JSP – prednosti, primjer Sveučilište u Zagrebu, Fakultet organizacije i informatike Varaždin, Elektroničko poslovanje 2006/07

Uvod • Internet i pristupačnost novih softverskih tehnologija danas svima omogućava izradu vlastitog virtualnog prostora, međusobnu komunikaciju, ali i izradu vrlo zahtjevnih sadržaja. • opis jezika koji se koriste za oblikovanje korisničkog sučelja HTML-a i DHTML-a te njihova razlika • funkcioniranje i komunikacijski kanal web servisa • korištenje alata Microsoft ASP i JSP tehnologije Sveučilište u Zagrebu, Fakultet organizacije i informatike Varaždin, Elektroničko poslovanje 2006/07

HTML • HTML - Hyper Text Markup Lanuage • za opis informacija na stranici u strukturnom obliku, služi za prikazivanje strukture informacija • 1945. Vannevar Bush - Memex • 1965. Ted Nelson - hypertext i hypermedia • 1978. Andrew Lippman - Aspen Movie Map Sveučilište u Zagrebu, Fakultet organizacije i informatike Varaždin, Elektroničko poslovanje 2006/07

HTML • posebnost – definiranje linkova među dokumentima • koristi URL (Universal Resource Locators) kako bi adresirao druge dokumente • pravila jezika zasnivaju se na standardu SGML koji se koristio prije pojave HTML-a Sveučilište u Zagrebu, Fakultet organizacije i informatike Varaždin, Elektroničko poslovanje 2006/07

HTML – Struktura i sintaksa • sastoji se od elemenata • dva osnovna dijela: • head ili glava stranice - meta informacije o samoj stranici (informacije o podacima, jeziku, kodiranju sadržaja…) • body ili tijelo stranice - elemente koji se nalaze unutar <body></body> tagova, a koji se prikazuju u pregledniku Sveučilište u Zagrebu, Fakultet organizacije i informatike Varaždin, Elektroničko poslovanje 2006/07

• U HEAD elementu mogu se naći: <BASE> - bazna adresa HTML dokumenta <LINK> - povezanost s drugim dokumentima (CSS i sl. ) <TITLE> - naslov <META> - definira informacije korisne za server i poslužitelj (character set i sl) <STYLE> - definiranje stilova • U BODY elementu mogu se naći: <P> - paragraf <BR> - novi red <LI> - lista <TABLE> - tablica <IMG> - slika Sveučilište u Zagrebu, Fakultet organizacije i informatike Varaždin, Elektroničko poslovanje 2006/07

HTML – Struktura i sintaksa • tri dijela elementa: početni tag, sadržaj i završni tag • tag = specijalna tekstualna oznaka označen s < i > znakovima • elementi se ne mogu preklapati, ali se mogu gnijezditi • ako započnemo drugi element unutar prvog, moramo ga i završiti prije završnog tag-a prvog elementa Sveučilište u Zagrebu, Fakultet organizacije i informatike Varaždin, Elektroničko poslovanje 2006/07

HTML – Struktura i sintaksa • nakon što preglednik učita sadržaj stranice on će na temelju njega pristupiti izvršavanju renderiranja stranice • učitavanje vanjskih datoteka, učitavanje zamjenskih referenci ili postavki • za opis elemenata ne razlikuje velika i mala slova • element može sadržavati listu atributa čije se vrijednosti navode ovako: <element atribut=“vrijednost“ atribut 2=“vrijednost“>sadržaj </element> Sveučilište u Zagrebu, Fakultet organizacije i informatike Varaždin, Elektroničko poslovanje 2006/07

HTML – Struktura i sintaksa • atributi se razlikuju zavisno o elementu, a najčešći su id, style, class i lang koji su prisutni kod većine • elementi služe za strukturiranje sadržaja, a atributi elemenata služe za formatiranje njihovog prikaza ili formatiranje sadržaja Sveučilište u Zagrebu, Fakultet organizacije i informatike Varaždin, Elektroničko poslovanje 2006/07

DHTML • omogućuje promjene na strani HTML-a bez potrebe obraćanja serveru • ovo nije jedna od naprednijih verzija postojećeg HTML-a već je to oznaka da koristimo nekoliko osnovnih tehnologija • DHTML pruža odgovor na neki upit korisnika, i to na poslužitelju (serveru) prije nego se informacija počne prikazivati s pomoću preglednika Sveučilište u Zagrebu, Fakultet organizacije i informatike Varaždin, Elektroničko poslovanje 2006/07

DHTML • objekti uz pomoć kojih se postiže dinamičnost su: layer, timer i event • Layer se deklarira u HTML-u, moguće mu je definirati veličinu, poziciju i sadržaj • obuhvaća: CSS, HTML, DOM i skriptne jezike (Java. Script, VBScript) Sveučilište u Zagrebu, Fakultet organizacije i informatike Varaždin, Elektroničko poslovanje 2006/07

DHTML - DOM • DOM - Document Object Model ne predstavlja konkretan jezik već samo model po kojemu se u HTML-u stranica gradi od objekata • predstavlja poveznicu između HTML-a koji sadrži objekte i CSS-a i skriptnog jezika koji tim objektima upravljaju Sveučilište u Zagrebu, Fakultet organizacije i informatike Varaždin, Elektroničko poslovanje 2006/07

DHTML - CSS • Cascading Style Sheets – kontrolira izgled i položaj svih elementa na stranici • razdvaja se dizajn od sadržaja • Sintaksa CSS kôda je slijedeća: <style type="text/css"> ELEMENT { property 1: value 1; property: value 2 } </style> • STYLE tag stavlja se unutar HEAD dijela dokumenta Sveučilište u Zagrebu, Fakultet organizacije i informatike Varaždin, Elektroničko poslovanje 2006/07

DHTML – Skriptni jezici • posrednici između WWW servera, vanjskih baza podataka i izvora informacija • ne smatramo ih pravim programskim jezicima - ne generiraju izvršne aplikacije (exe, com i dr. ), već su uklopljeni u Web dokumente • Današnji najčešći skriptni jezici su: - CGI (Common Gateway Interface) - Java. Script - VBscript (Visual Basic Script) - ASP - idr. Sveučilište u Zagrebu, Fakultet organizacije i informatike Varaždin, Elektroničko poslovanje 2006/07

DHTML • možemo zaključiti – pomoću HTML-a stavljaju elementi na našu stranicu, – pomoću CSS-a određujemo njihov izgled (font, veličinu itd. ), – pomoću skriptnih jezika manipuliramo elementima, – Java. Script koristi DOM kao vezu sa tim elementima Sveučilište u Zagrebu, Fakultet organizacije i informatike Varaždin, Elektroničko poslovanje 2006/07

WEB SERVISI • aplikacije (komponente ili moduli) koje egzistiraju u distribuiranim okruženjima poput Interneta ili privatnih LAN-ova • temelje se na paradigmi zahtjev – odgovor, a razlikujemo sinkroni i asinkroni model • komunikacija se odvija korištenjem SOAP (Simple Object Access Protocol ) protokola Sveučilište u Zagrebu, Fakultet organizacije i informatike Varaždin, Elektroničko poslovanje 2006/07

SOAP • specifikacija protokola za korištenje funkcionalnosti web servisa • definira formate poruka za komunikaciju s web servisima i propisuje povezivanje na postojeće komunikacijske protokole • temeljni dio SOAP-a je poruka (SOAP omotnica, SOAP zaglavlje i obavezno SOAP tijelo) • tijelo prenosi glavni dio SOAP poruke (dio namijenjen primatelju) Sveučilište u Zagrebu, Fakultet organizacije i informatike Varaždin, Elektroničko poslovanje 2006/07

SOAP protokol Sveučilište u Zagrebu, Fakultet organizacije i informatike Varaždin, Elektroničko poslovanje 2006/07

WEB SERVISI • web 2. 0 - naglasak na korisnike i njihovu međusobnu interakciju • korisnici koji kreiraju i razmjenjuju sadržaje omogućavajući otkrivanje željenih informacija lakše nego klasičnim pretraživanjima • jedan od najpopularnijih web servisa svakako je You. Tube Sveučilište u Zagrebu, Fakultet organizacije i informatike Varaždin, Elektroničko poslovanje 2006/07

ASP – Active Server Pages • za izradu dinamičkih i interaktivnih Internet stranica • može interpretirati samo na Microsoftovom IIS serveru (Internet Information Services) • sličnost i razlika s HTML • važni objekti: response, request, application, session, server i error object Sveučilište u Zagrebu, Fakultet organizacije i informatike Varaždin, Elektroničko poslovanje 2006/07

ASP - primjer Sveučilište u Zagrebu, Fakultet organizacije i informatike Varaždin, Elektroničko poslovanje 2006/07

JSP – Java Server Pages • tehnologija koja dozvoljava miješanje običnog, statičkog HTML-a sa dinamičkim • JSP nam omogućava odvojeno kreiranje dva najvažnija dijela (HEAD i BODY) • server-side tehnologija veoma slična ASP-u • prednosti korištenja JSP-a je korištenje Jave te time nismo ograničeni na samo jednu platformu Sveučilište u Zagrebu, Fakultet organizacije i informatike Varaždin, Elektroničko poslovanje 2006/07

JSP – Primjer Sveučilište u Zagrebu, Fakultet organizacije i informatike Varaždin, Elektroničko poslovanje 2006/07

Zaključak • uspješna poduzeća nastoje orijentirati svoje poslovanje prema Internetu • interakcijom, te korištenjem navedenih tehnologija poduzeća nastoje ubrzati svoj rast, proširiti i pojednostavniti poslovanje te ujedno biti korak ispred svoje konkurencije • Internet poslovanje ima mnogih prednosti Sveučilište u Zagrebu, Fakultet organizacije i informatike Varaždin, Elektroničko poslovanje 2006/07

TEHNOLOGIJA SLOJA ARHITEKTURE -BAZA PODATAKA Autori: Ivan Lešić Danijel Matijević Sveučilište u Zagrebu, Fakultet organizacije i informatike Varaždin, Elektroničko poslovanje 2006/07

Sadržaj • • Uvod Troslojna arhitektura Sloj baze podataka Fat server Pohranjene procedure Trigeri Struktura portala HZZO Sveučilište u Zagrebu, Fakultet organizacije i informatike Varaždin, Elektroničko poslovanje 2006/07

Uvod • razdvajanje softvera na sistemski i aplikacijski softver • pojava baza podataka i sustava za njihovo upravljanje omogućila je daljnje rasterećenje i pojednostavljenje aplikativnih programa

Slika 1. Arhitekture korisničkih programa

Uvod • u skladu s klijent/server konceptom, razdvajanje aplikacije na dva dijela, dio koji se odnosi na upravljanje podacima označava se kao server, a dio koji se sastoji od korisničkog sučelja i poslovnih pravila označava se kao klijent • komunikacija između klijenta i servera razmjenom poruka

Troslojna arhitektura • na najnižem nivou aplikacije nalazi se sloj baze podataka • sustav za upravljanje bazom podataka • iznad sloja baze podataka nalazi se složeni prezentacijski sloj koji sadrži najveći dio logike aplikacije i prenosi podatke između preostala dva sloja. • na vrhu se nalazi klijentski sloj, obično Web čitač koji komunicira sa aplikacijom.

Troslojna arhitektura Slika 2. Troslojna arhitektura

Troslojna arhitektura • poslovna logika može, ali ne mora biti izdvojena kao logička ili fizička cjelina u sustavu • ukoliko je pridružena aplikaciji, sva poslovna logika će biti na klijentskoj strani • takav slučaj se naziva "debeli klijent/tanki server" (Fat client/Thin server)

Troslojna arhitektura • ako poslovnu logiku želimo pridružiti samoj bazi podataka, to je naravno moguće samo pomoću programskog jezika Transact SQL • upotreba pohranjenih procedura (stored procedures), funkcija, trigera, pravila (rules), podrazumijevanih vrijednosti (defaults), extended stored procedures i ostalih elemenata jezika koje vam stoje na raspolaganju

Troslojna arhitektura • odluka o tome gdje će se smjestiti poslovnu logiku zavisi od velikog broja varijabli • nekada su one vrlo značajne, kao recimo usko grlo u mreži, koje uvjetuje da smanjite ukupan protok informacija i smjestite poslovnu logiku na samom serveru • nekada su sigurnosni zahtjevi ti koji određuju mjesto poslovnoj logici sustava

Troslojna arhitektura • višeslojna arhitektura nam pruža još nekoliko pogodnosti a jedna od njih je da možemo lakše raspodijeliti zadatke između ljudi sa kojima raspolažemo • na primjer, možemo imati ljude koji su specijalizirani samo za implementaciju korisničkog sučelja a ne znaju raditi sa bazama podataka

Sloj baze podataka • sloj baze podataka je osnova Web aplikacija koje rade s bazama podataka • u aplikaciji sa troslojnom arhitekturom, sloj baze podataka zadužen je za upravljanje podacima

Fat klijent • fat-klijent aplikacija je ona kod koje su svi pristupi podacima i poslovna logika uključeni u forme aplikacije • poslovna logika i pristup podacima postaju strogi i ne mogu se mijenjati brzo i jednostavno od strane programera

Slika 3. Fat-klijent aplikacija

Fat klijent • fat-klijent aplikacija obuhvaća cijelu poslovnu logiku i pristup podacima unutar individualnih formi aplikacije • svaki put kad je forma kreirana, poslovna logika i pristup podacima mora biti ponovno kodiran • uz to, ako se neke promjene moraju izvršiti na poslovnoj logici ili pristupu podacima, promjene se moraju izvršiti na svakoj formi unutar aplikacije

Fat server • fat-server arhitektura je napravljena kao moguće rješenje problema naslijeđenih od fat-klijent arhitekture • poslovna logika je uklonjena iz poslovnih sučelja a smještena unutar servera baze podataka

Fat server • koristeći T-SQL pohranjene procedure i trigere, cijela logika aplikacije je rješena na razini servera radije nego na razini korisnika, centralizirajući poslovnu logiku i čineći je lakše proširivom i jednostavnijom za održavanje • fat-server izaziva neke nove probleme

Fat server • server baze podataka postaje usko grlo aplikacije, budući da server obrađuje cijelu poslovnu logiku, a također se na njemu odvijaju procesi baze podataka • uz to, T-SQL nije programski jezik visoke razine i sadrži mnoga ograničenja za programera

Slika 4. Fat-server aplikacija

Fat server • fat-server aplikacija unutar skladišta podataka obuhvaća cijelu poslovnu logiku i validaciju podataka • to je većinom ostvareno pomoću T-SQL trigera i procedura. Pri centraliziranju poslovne logike ova arhitektura ne centralizira pristup podacima • server baze podataka postaje usko grlo cijele aplikacije, predstavljajući performanse

Client side/server side(CSSS) • CSSS arhitektura je kombinacija fat-klijent i fat-server arhitektura. Generalno, CSSS aplikacija je rezultat višegodišnjeg proširivanja i održavanja aplikacije • aplikacija početno nije bila izgrađena prikladnom arhitekturom, te je održavanje koda zahtijevalo da poslovna logika bude smještena u obadvije razine, serversku i klijentsku

Slika 4. CSSS arhitektura

Client side/server side(CSSS) • client-side / server-side arhitektura je najučestaliji pristup korišten kod aplikacija danas. To je kombinacija fat-klijent i fatserver arhitektura

Pohranjene procedure • predstavljaju procedure koje se smještaju u okviru baze podataka i dostupne su za pozivanje od strane klijenata. Najčešće se pišu u nekom od proširenja jezika SQL koje definira proizvođač konkretnog SUBP: • Oracle – PL/SQL • Microsoft SQL Server – Transact-SQL

Pohranjene procedure • prednost korištenja pohranjenih procedura je u poboljšanju performansi sustava • najčešće predstavlja složenu operaciju nad bazom podataka • nalazi se na serveru u obliku koji je unaprijed pripremljen za efikasno izvršavanje

Pohranjene procedure • predstavljaju skup prevedenih SQL funkcija (instrukcija), koje su smještene (pohranjene) u samu bazu podataka • uglavnom sadrže logičke skupove instrukcija, koji se često upotrebljavaju • sve procedure nalaze se na jednom mjestu, a ne na više mjesta u aplikacijama, pa je njihova izmjena i ažuriranje mnogo lakše.

Pohranjene procedure • razlikuju se dva tipa pohranjenih procedure: select procedure i izvršne procedure • select procedure se koriste u slučaju kad bismo zatrebali neki složeniji upit, a prilično ga je nemoguće izvesti i ovakav tip procedure vraća rezultate • izvršne procedure ne vraćaju rezultate i služe za složene operacije nad bazom podataka (npr. knjiženja)

Pohranjene procedure CREATE PROCEDURE Prva. Proc AS SELECT * FROM Radnik WHERE Plaća > 2500 GO EXECUTE Prva. Proc

• • • • • CREATE PROCEDURE PROC_UPISNI @l. Ulist_id int=NULL OUTPUT, @s. Matbr varchar(10)=NULL, @s. Sk_god varchar(7)=NULL, @l. Sem tinyint=NULL, @s. Obr_ime varchar(25)=NULL, AS DECLARE @l. Student. Id int, @l. Obr. Id int SELECT @l. Student. Id=Student_id FROM STUDENT WHERE Matbr=@s. Matbr IF @l. Student. Id IS NULL RETURN -6 SELECT @l. Obr. Id=obr_prog_id FROM OBR_PROG WHERE obr_prog_ime=@s. Obr_ime IF @l. Obr. Id IS NULL RETURN – 6 BEGIN TRAN INSERT UPISNI_LIST VALUES ( @l. Student. Id, @s. Sk_god, @l. Sem, @l. Obr_prog_id) IF @@Error<>0 BEGIN ROLLBACK TRAN

• • • RETURN END SELECT @l. Ulist_id=@@IDENTITY IF @l. Ulist_id IS NULL BEGIN ROLLBACK TRAN RETURN -6 END COMMIT TRAN

Trigeri • predstavljaju posebno klasu SQL procedura koja se izvršava automatski kod izvršavanja akcijskih upita (UPDATE, INSERT, DELETE) na pojedinim tablicama u bazi • uglavnom se koriste kao oblik proširenja provjere integriteta i suvislosti podataka prema logici procesa kojeg opisuje baza

Trigeri • uvijek vezani uz tablice, pri čemu jedna tablica može imati više trigera • moguće je definirati posebne trigere za svaki tip promjene koja se vrši u tablici (unos, promjena ili brisanje podataka), ili zajedničke trigere za različite promjene • izvršavaju se odmah nakon što završi instrukcija koja ih ''okida''

Trigeri • primjenom trigera zabranjuju se ili poništavaju (rollback) promjene kojima se krši integritet podataka • omogućavaju uvođenje strožih i složenijih ograničenja od onih koja se definiraju preko CHECK ograničenja. Za razliku od CHECK ograničenja koje djeluje samo na nivou definirane tablice, triger može pristupiti drugim tablicama, te provjeravati složenije uvjete integriteta • pomoću trigera moguće je ustanoviti razliku između stanja tablice prije promjena i nakon promjena i poduzeti odgovarajuće akcije u vezi tih promjena

Trigeri • nakon nastupanja promjena u određenoj tablici, interni mehanizam baze podataka stvara dvije privremene tablice naziva deleted i inserted • tablica deleted pohranjuje kopije svih redova na koje djeluju instrukcije DELETE ili UPDATE

Trigeri • tablica inserted pohranjuje kopije svih novounesenih redova u promatranu tablicu, tj. djelovanjem instrukcije INSERT novi redovi dodaju se istovremeno u tablicu u bazi i sistemsku privremenu tablicu inserted • operacije ažuriranja (UPDATE) tretiraju se kao slijed brisanja i unosa; podaci prije promjene prenose se u privremenu tablicu deleted, a novopromijenjeni podaci u inserted tablicu

Trigeri • prilikom formiranja trigera potrebno je definirati • ime(naziv) trigera • tablicu uz koju je triger vezan • akciju koja aktivira triger • niz SQL instrukcija koje se izvršavaju aktiviranjem trigera

Trigeri CREATE TRIGGER naziv_okidača ON ime_tablice FOR [DELETE] [, ] [INSERT] [, ] [UPDATE] AS sql_izrazi [1. . . n] | FOR [INSERT] [, ] [UPDATE] AS IF UPDATE (naziv_kolone) [AND | OR UPDATE (naziv_kolone)] sql_izrazi [. . . n]

Trigeri

Trigeri CREATE TRIGGER TG_DEL_ULIST ON UPISNI_LIST FOR DELETE AS DECLARE @i. Sem smallint, @l. Student. Id int SELECT @i. Sem= SEM, @l. Student. Id=STUDENT_ID FROM DELETED IF EXISTS (SELECT ULIST_ID FROM UPISNI_LIST WHERE SEM=@i. Sem+1 AND STUDENT_ID=@l. Student. Id ) BEGIN ROLLBACK TRAN RAISERROR ('Ne možete izbrisati %d semestar, jer već postoji slijedeći', 16, -1, @i. Sem) RETURN END

Struktura portala HZZO • da bi portal HZZO-a zadovoljio uvjete funkcionalnosti i zahtjeve sigurnosti, komunikacije i upravljanja sadržajem, platforma na kojoj se gradi takav sustav također mora zadovoljavati neke tehnološke uvjete • ti uvjeti odnose se na: • arhitekturu • izvršnu okolinu (točnije, J 2 EE) te • integracijske komponente

Struktura portala HZZO • arhitektura koja je najpogodnija za ovakvo rješenje je višeslojna arhitektura sustava, tj. arhitektura koja se sastoji od tri sloja: • Web server, koji oblikuje i distribuira sadržaj i podržava prvi sloj funkcija sigurnosti (prihvaćanje zahtjeva za autentikacijom korisnika i sl. );

Struktura portala HZZO • application server / Portal server, koji priprema sadržaj, prosljeđuje zahtjeve za podacima i sadržajem unutarnjim aplikacijskim sustavima HZZO-a (tj. aplikacijama u klasičnom smislu), ostvaruje personalizaciju sadržaja … • baze podataka i aplikacije unutar HZZO-a, koje čine glavne izvore podataka i velikog dijela poslovne logike

Struktura portala HZZO • međusobna komunikacija ovih komponenata ostvaruje se putem integracijskog sloja, koji osigurava održavanje poslovnog i komunikacijskog integriteta unutar sustava portala, kao i prema vanjskim komponentama. Istovremeno, integracijski sloj podržava i međusobnu komunikaciju komponenata prilikom izgradnje i/ili izvršavanja Web servisa, servleta, portleta i poruka • ti zahtjevi čine glavne razloge za odabir J 2 EE infrastrukture

Struktura portala HZZO Slika 5: Troslojna arhitektura sustava

Nedostaci slojevitog pristupa • složenost - dodatni napori u svim razvojnim fazama. Teži dizajn. • potreban je disciplinirani razvoj - za sada RAD alati još nemaju povjerenje u ovom području • tim mora biti usklađen po znanju • teško testiranje po slojevima

Prednosti slojevitog pristupa • razdvajanje aplikacijske odgovornosti - fizički i logički – lakše razumijevanje sustava – lakša optimizacija • podrška složenim aplikacija bez fragmentacije procesa – postoji poseban sloj poslovne logike

Prednosti slojevitog pristupa • dijeljenje zajedničkih servisa – srednji sloj (sa poslovnom logikom) može pristupati različitim bazama podataka i posluživati velik broj klijenata • olakšana migracija – jednostavna promjena baza podataka, veza na legacy • Skalabilnost • Dostupnost 24 * 7

Zajednički servisi • Zajednički dostup servisima – personalizacija – naplata – prijava korisnika – profiliranje korisnika – agregacija narudžbi – pretraživanje

Tehnološka arhitektura • Komponentni pristup – enkapsulacija i suradnja programskih entiteta • CORBA • EJB – komponentni objektni model za Javu • COM, DCOM, COM+

Baza podataka • slojevita arhitektura nas odvaja od proizvođača baze podataka • nitko ne koristi ANSI SQL • koristiti pohranjene procedure (fat database server), ali one nisu skalabilne!!!

Tipične arhitekture el. poslovanja • Brochureware - prva pojava organizacije na Internet-u

Ponuda i pretraživanje • Stranice se kreiraju pomoću CGI na korisnikov zahtjev, scheduler prebacuje podatke iz baze u kopiju koju čita CGI program

Naručivanje • Pravi e-commerce počinje kada korisnik može sam naručivati preko Web-a i upravljati sustavom naručivanja • Oko sustava za naručivanje radi se ovojnica koja izlaže zahtjevanu funkcionalnost korisniku (korištenjem Java RMI). • CGI se odbacuje i koriste se Java servleti zbog poboljšanja perormansi

Naručivanje • Servleti mogu direktno surađivati sa prodajnim sustavom korištenjem • Aplikacijski server dozvoljava paralelni pristup objektnoj ovojnici za više korisnika

Naručivanje

Transakcijski sustav • Suradnja između različitih resursa sustava • Srce sustava je aplikacijski server

Organizacijska arhitektura • Korisnički orijentirani sustavi postaju korisnički upravljani • Gubi se razdjelnica između prodaje i neprodaje jer kupac svime upravlja • Međutim, dohvat je obostran • Poslovni sustav se okreće kupcu i uvlači ga u vlastitu organizaciju

Organizacijska arhitektura • Kupci su bolje informirani i imaju veću pregovaračku snagu • Web site nije više mjesto oglašavanja već mjesto dijaloga s kupcima • Podrška kupcu i nakon prodaje

Povezivanje • Narudžbu kupca proslijediti u sve dijelove organizacije (proizvodnju, nabavu, čak i dobavljačima…) • Smanjiti time to market • Trenutna mogućnost generiranja izvještaja na svim razinama poduzeća

Tko je odgovoran? • Tko je odgovoran za uspjeh e-commerce projekta? • Što povezuje e-commerce projekt – prodaju i odnose s kupcima – IT odjel – upravu –… • Projektom upravlja poslovni sustav

Pokretači e-commerce projekata • • dostići konkurenciju napraviti poznat i korišten prodajni kanal sniziti troškove poslovanja uključiti partnere u vlastito poslovanje

Kako započeti • Vlastita ideja • Imitacija – Kako su naši tradicionalni konkurenti pristupili elektroničkom poslovanju? – Tko su naši netradicionlani konkurenti na Webu? – Tko radi posao koji nije sličan našem, ali ga izuzetno cijenimo? – Da li nas netko imitira? Jesu li poboljšali poslovanje?

Što je prodajni kanal? • U medijskoj terminologiji – poznato ime za nositelja zabave ili informacije prema publici (sport, muzika, …) • Visoka specijalizacija • U svijetu elektroničkog poslovanja – bilo koji stalni put prema grupi kupaca – put za proizvode i informacije poduzeća

Prodajni kanal • u središtu interesa suvremenih poduzeća koja se kane baviti el. poslovanjem • stvoriti zajednicu potrošača (interesnu grupu) • stvoriti portal određene niše • vertkalni portali (vortals)

Kako razviti kanal • Koju populaciju ciljamo? • Što želimo od te populacije? (da nauče o nama, da nam daju informaciju o sebi, da se raspituju o našim proizvodima, da kupe preko našeg site-a, da kupe od nekog drugog preko našeg site-a) • Tko upravlja kanalom elektroničkog poslovanja u organizaciji?

Kanal • Da li planiramo razviti kanal el. poslovanja paralelno s drugim kanalima? • Da li imamo poslovne procese za generiranje, odobravanje, i povlačenje sadržaja? • Koji marketinški pristup ćemo odabrati da promoviramo kanal?

Uključenje partnera • • • uvid u podatke (cijene, datumi, količine, …) dozvoliti partnerima uvid u vlastiti sustav extranet podaci moraju biti točni i sinkronizirani Fed. Ex dozvoljava korisnicima da unesu broj pošiljke i provjere njezin status

Uključenje partnera • uvid u cijene • rezervacija isporuke • unos vremenskog rasporeda naručivanja, isporuke • telefonski imenik • rezervacija soba • financijsko stanje • uvid u radni kalendar poduzeća

Uklanjanje posrednika • proizvođači mogu izravno prodavati kupcima • posrednici moraju dodavati vrijednost proizvodu

ABC • Agora - mjesto sastanka zainteresiranih strana (1 prema 1) Match. com • Broker - klasični posrednik • Club - zajedničko mjesto pregovaranja i uparivanja

Transformatori • rafiniraju podatke i nude ih kao novu uslugu (Andersen Consulting) • analitika burzovnih kretanja • krediti

Žarišne aplikacije (B 2 C) • područja elektroničkog poslovanja na kojima se očekuje najveći učinak • prodaja proizvoda u kojima možemo pomoći kupcu kod odluke o kupnji (Amazon. com, www. drugstore. com) • osloboditi kupca neatraktivnih ponavljajućih kupnji (www. peapod. com)

Žarišne aplikacije (B 2 C) • aukcije - omogućuju običnom građaninu da sam sudjeluje u kreiranju tržišta • padajući i rastući principi aukcija • stvaraju se interesne zajednice • savjetodavne aplikacije (Merrill Lynch - istraživanje burza) • www. askjeeves. com • www. mediconsult. com

Žarišne aplikacije (B 2 B) • Procurement - nabava resursa koji se ne koriste izravno u proizvodnji - najbrže rastuće područje el. poslovanja • www. ariba. com, www. oracle. com • automatizirano odobravanje kod nabave (Business @ Speed of Thought)

Žarišne aplikacije (B 2 B) • • • Burze usko fokusirana vertikalna integracija www. metalsite. com, www. Paper. Exchange. com www. fastparts. com kad se jednom ostvari dominacija u jednoj vertikali, burza se širi na drugu (srodnu)

Žarišne aplikacije (B 2 B) • Klasične burze NYSE, NASDAQ ozbiljno su ugrožene • One posluju na principu neznanja kupaca o cijeni dionice koja se prodaje posredstvo broker-a • Strahovito su skupe • Elektroničke burze www. bsx. com

Žarišne aplikacije (B 2 B) • • Industrije će se grupirati oko takvih burzi Stvara se zajednica industrija (vertikala) Puno slobodnije formiranje cijena Nema opstanka za više burzi u istoj vertikali!!! • Zbog globalne prisutnosti Interneta jedna burza zauzima vertikalu (osim u posebnim slučajevima gdje lokacija igra ulogu npr. električna energija)

Veza ERP i E-business • U određenom trenutku potrebno je povezati ERP sustav koji objedinjuje unutarnje poslovne procese poduzeća i E-business koji predstavlja vezu poslovnog sustava sa svijetom

Razvojni ciklus el. poslovanja • Bez uspostavljenog sustava el. poslovanja • Optimalizacija kanala – prodaja putem Web-a – Internet marketing – usluge putem Internet-a

Razvojni ciklus el. poslovanja (2) • Povezivanje opskrbnog lanca – povezivanje kupaca i dobavljača s poslovnim procesima vlastitog sustava – zajedničko planiranje, predviđanje i dizajn sustava – niska cijena Internet-a rezultira u outsourcing-u usluga kojima se prenose informacije – e. CRM e-Customer Relationship Management – personalizirane Web stranice – portali

Razvojni ciklus el. poslovanja (3) • Transformacija – korištenje Interneta kao strateškog oružja poduzeća – rasterećivanja poduzeća od svega što mu nije primarna djelatnost – snažno povezivanje sa partnerima u alijanse

Razvojni ciklus el. poslovanja (4) • Konvergencija – snažno umrežavanje partnera kako bi se zajednički okrenuli ka kupcu u ponudi određene robe ili usluge

ERP razvojni ciklus • Bez ERP sustava – nema legacy sustava – poduzeće može krenuti prema el. poslovanju pravocrtnom putanjom • Nepovezani sustavi – neučinkovita razmjena podataka – visoki troškovi održavanja i razvoja programskih sustava

ERP razvojni ciklus (2) • ERP parcijalno u funkciji – postavljeni pojedini moduli (financije, ljudski resursi, proizvodnja) – sustav je još uvijek nepovezan i radi suboptimalno • ERP potpuno u funkciji u pojedinim poslovnim jedinicama – još nema zajedničke baze kupaca, roba, usluga, itd. – sustav nije cjelina

ERP razvojni ciklus (3) • Potpuno povezan ERP – sve poslovne jedinice i svi moduli ERP sustava potpuno su povezani – ono što je kupac unio preko Internet-a odmah ulazi u proizvodnju i naručivanje

ERP i el. poslovanje

Žarište ERP sustava

El. poslovanje i ERP

Kako ih objediniti? • ERP i el. poslovanje trebaju postati komplementarne tehnologije • ERP treba napraviti Web tehnologijama • prodajne i nabavne sustave treba potpuno okrenuti k Web-u kako bi se u poduzeće uvukao kupac

Povezivanje lanca Prošireno poduzeće Govoriti isti jezik i koristiti istu gramatiku