OUGDK 23 KICKING THE ASP OUT OF DESIGNER 8 NYHEDER 22 TFR: TRACE FILE REPOSITORY 20

Transkript

1 ktober 2001 Nr 8, Årgang 2 ISSN Pris: kr. 125,00 ex moms #8 UGDK 23 DBA SIG Næste møde er endnu ikke fastlagt. Designer SIG Møde: 14. november 2001 kl. 13:30 Developer SIG Næste møde er endnu ikke fastlagt. Data warehouse SIG Næste møde er endnu ikke fastlagt. Web SIG Næste møde er endnu ikke fastlagt. NYHEDER 22 Rekordoverskud i 1. kvartal IBM-rekord på racle9i Det var i Portal får AltaVista portaler DB2 overhaler racle Larry sælger aktier for USD 706 mill racle lancerer penworld HP installerer racles Sales nline racle opkøber e-handelpatent Virtual Private Database E-Business Suite til mobile enheder racle9i Real Application Clusters Accelerator JDeveloper frigivet i EAP Ny warehouse benchmark rekord Boeing køber e-business racle implementerer stemmestyring NYSKABENDE TEKNIKKER TIL MERE EFFEKTIV PFYLDELSE AF DATALVGIVNINGENS BESTEMMELSE M LGNING AF ADGANG TIL PERSNFØLSMME INFRMATINER 4 Martin Jensen, racle Consulting, martin.jensen@oracle.com For første gang er det nu muligt, som en del af selve databasesystemet, at indbygge mekanismer til automatisk logning af access til forudbestemte informationer, uden at skulle ændre i de rapporter og skærmbilleder, der betjener brugerne af systemet. KICKING THE ASP UT F DESIGNER 8 David Schleis, Wisconsin State Laboratory of Hygiene/ccupational Health Lab. Reprinted by permission from the DTUG 2001 Conference Proceedings. Notice that this is an updated version of the paper that was published at DTUG. The racle Designer WebServer Generator (WSG) generates web-based applications designed to run on an racle Web Application Server. These applications are generated based on module and database design specifications recorded in the Repository, and allow u TFR: TRACE FILE REPSITRY 20 Torben Holm & Mogens Nørgaard, begge Miracle A/S Det er egentlig Cary Millsaps ide: Tracefiler (uanset om de er normale level 1 eller mere barske level 4, 8 og 12 typer) hører til i en database i et repository, som man ynder at kalde en samling tabeller nu om dage. Indryk en jobannonce i racleekspert DKK (excl moms) for 1/4 side Salg@racleEkspert.dk

2 Leder DESIGNER VS JDEVELPER Marc de liveira, ansvarshavende redaktør. Takket være Torkild Linde-Hansens indsats lykkedes det at fylde racle Danmarks auditorium til Designer SIG'ens møde den 19. september. Dagens program var endog meget interessant, idet lederen af Modeling Tools Product Management, Simon Day, gennemgik planerne for de næste fire versioner af Designer (Designer 6i release 4.1, Designer 6i release 5, Designer 9i og Designer 10i). Gruppens medlemmer sammensatte til lejligheden en liste af ændringsønsker til Designer, som blev præsenteret for Simon Day, og han lovede som svar at vende tilbage med racles holdning til de fremsatte ønsker inden gruppens næte møde den 14. november. På dette møde vil det så være muligt at vurdere racles egentlige vilje til fortsat at understøtte Designer som et anvendeligt produkt for "Full Lifecycle" applikationsudvikling. Både Simon Days indlæg og Designer SIG gruppens udvidelsesønsker kan hentes på Designer SIG'ens hjemmeside, som ligger på mens vi venter på at kommer op igen. Baggrunden for hele denne debat omkring Designer / JDeveloper blev skitseret i racleekspert nr 7, men Simon Day fik konkretiseret flere af diskussionens elementer. racles overordnede mål er at positionere JDeveloper og objektorienteret udvikling som fremtidens udviklingsmiljø i oposition til den "gamle" relationelle/strukturerede metode, som Designer understøtter. Dette signal kommer fra racles øverste top, og blev understreget af at JDevelopers product manager, Bill Dwight, blev gjort til Vice President for hele Development Tools divisionen. Andre tydelige signaler har været SCM gruppens distancering fra Designer. Tidligere blev arbejdet på Designers repository gjort til en vej til at få de andre værktøjer til at integrere med Designer - nu er signalet at alle værktøjer skal kunne bruge Designers repository (nu kaldet Software Configuration Manager - SCM) uden at have noget med Designer at gøre. gså den masive flytning af racle-medarbejdere fra Designer-gruppen til JDeveloper-gruppen, samt signalerne om, at der ikke er planer om at tilføje ny funktionalitet til Designer i fremtiden, taler sit tydelige sprog. Disse klare signaler giver nok de fleste et indtryk af, at racle er sikre i deres sag og helt klar over hvordan JDeveloper kan udvikle sig til at blive et programmeringsværktøj såvel som et modelleringsværktøj, som udover at understøtte Java, XML og den objektorienterede metode vil kunne bibringe dets brugere samme niveau af dokumentation, rapportering, overblik og understøttelse for projektarbejde som Designer i dag tilbyder sine brugere. Men dette skal man ikke være helt sikker på. Som det blev nævnt i racleekspert nr 7 blev en alvorlig manglende forståelse for hvilket produkt Designer er allerede afsløret inden dette års DTUG-konference, hvor Bill Dwight lovede DTUGs medlemmer at sætte sig ind i produktet inden konferencen, og hvor han under konferencen proklamerede, at hans arbejde med Designer havde gjort ham opmærksom på Designers evne til at lave abstrakte modeller og transformere disse til fysiske modeller. Som en erkendelse af dette, indviede han deltagerne på konferencen i sine planer om at udvide UML med tilsvarende elementer. På Designer SIG mødet den 19. september nævnte Simon Day, at Bill Dwight desuden havde opdaget, hvor anvendeligt det var, at man med Designer kunne lave alle tænkelige udtræk af sine applikationer, datamodeller og deres indbyrdes sammenhænge. Da målet med JDeveloper er, at UML-modeller og programkode skal være helt integrerede, og at metadata principielt uddrages af koden, vil der ikke eksistere de store mængder strukturerede metadata i JDevelopers repository, som vi kender det fra Designer. Bill Dwight og Simon Day kunne se, at der var et behov for dette, og løsningen blev, at XSql skulle kunne anvendes til at lave avancerede søgninger i XML-filerne, som ville blive JDevelopers hovedbestanddel. Generelt var cheferne helt op på Sohaib Abbasis (Senior Vice president for Tools divisionen) niveau blevet klar over, at Designer ikke blot kunne forlades, og Simon Day betroede os, at man nu var ved at flytte nogle af udviklerne tilbage til Designergruppen. Simon Day har selv arbejdet med Designer siden 1989, så det kan undre at Deres redaktørs spørgsmål om, hvordan de ville overføre meta-data om udviklingsprojekters forløb, modulkompleksitet, opgavefordeling, tidsplanlægning, fejlrapportering og -behandling til JDevelopers objektorienterede (og ikke-strukturerede) paradigme, fik ham til at stoppe tænktsomt op og erkende det som et væsentligt spørgsmål, som jeg endelig måtte huske dem på, at de fik implementeret i JDeveloper. Så mødet endte med at være givtigt for alle parter. Selv om det kunne se sådan ud i denne tekst, er det ikke mit mål at Designer holdes i live for enhver pris. Hvad der derimod er et vigtigt mål er at sikre, at uanset hvilken vej racle måtte vælge at gå med deres udviklingsværktøjer, så bør de ikke tvinge deres udviklere til at skulle bruge et ringere værktøj end hvad racle allerede tilbyder i dag. m der står Designer eller JDeveloper på CD'en er ligegyldigt. racle bør blot holde fast i at de, som det eneste softwarefirma, i dag har et produkt til ægte "Full Lifecycle" applikationsudvikling. plag: kopier Udgives af: pythia Information Kongensvej Frederiksberg Danmark Telefon: Fax: Info@racleEkspert.dk Web: Ansvarshavende redaktør: marc de liveira marc@racleekspert.dk Rettigheder: PYTHIA Information ejer alle rettigheder til indholdet af racleekspert. Kopiering af bladet i dele eller helhed må kun ske efter skriftligt samtykke fra PYTHIA Information. PYTHIA Information forbeholder sig rettigheder til at offentliggøre og genudgive de trykte artikler, tips mv, samt at tillade bladets læsere at anvende indholdet til såvel personlige som kommercielle formål. PYTHIA Information kan ikke drages til ansvar for eventuelle fejl og mangler i Indholdet af racleekspert. Artikler mv stilles tilrådighed uden garanti af nogen art. Pris: Enkeltnummer DKK 125,00 1 års abonnement dkk 600,00 Ved samtidig køb af minimum 5 kopier til samme adresse (enkeltnummer eller abonnement) gives 40% rabat på den samlede pris. Priserne er excl moms. Annoncer: Annoncer til racleekspert nr 9 skal være PYTHIA Information i hænde senest den 9. november Annoncepriser kan findes på: Password: bdlat

3 Vågn n op! Så er det t nu du u skal se ata komme i gang... Deadline er den 9. nov. n 2001 Vi betaler 700 kr. pr. sides Hvis du d u skal vinde racleek cleekspert spert- prisen 2001!!!

4 DBATeknisk Artikel NYSKABENDE TEKNIKKER TIL MERE EFFEKTIV PFYLDELSE AF DATALVGIVNINGENS BESTEMMELSE M LGNING AF ADGANG TIL PERSNFØLSMME INFRMATINER Martin Jensen, racle Consulting, martin.jensen@oracle.com Kilde: Vejledning til bekendtgørelse nr. 528 af 15. juni 2000 om sikkerhedsforanstaltninger til beskyttelse af personoplysninger, som behandles for den offentlige forvaltning, URL: For første gang er det nu muligt, som en del af selve databasesystemet, at indbygge mekanismer til automatisk logning af access til forudbestemte informationer, uden at skulle ændre i de rapporter og skærmbilleder, der betjener brugerne af systemet. Nærværende notat redegør først i brede vendinger for hvorfor dette overhovedet har været et problem, og søger dernæst mere teknisk at skitsere hvorledes dette ville tage sig ud ved anvendelse af de nye teknikker. Sidst i notatet gives bud på alternative anvendelsesmuligheder af disse teknikker. Notatet henvender sig til alle med interesse for implementering af offentlige administrative systemer eller databasesystemer i bred forstand. Igennem mange år har vi i Danmark haft en lovgivning og en række bestemmelser, der har til hensigt at beskytte personer mod misbrug af personfølsomme informationer i offentlige registre. Til opfyldelse af disse bestemmelser er to tekniske virkemidler helt centrale: Adgangskontrol og Logning. Adgangskontrol som virkemiddel er for så vidt enkelt nok: Kun personer med arbejdsmæssige rettigheder til se personfølsomme data skal have adgang til de pågældende dele af det administrative system, herunder data. Logning som virkemiddel er derimod mindre enkelt. Generelt skal alle anvendelser af personoplysninger (incl. søgninger) logges. Citatet fra Datatilsynets bekendgørelse lyder således: 19. Der skal foretages maskinel registrering (logning) af alle anvendelser af personoplysninger. Registreringen skal mindst indeholde oplysning om tidspunkt, bruger, type af anvendelse og angivelse af den person, de anvendte oplysninger vedrørte, eller det anvendte søgekriterium. Loggen skal opbevares i 6 måneder, hvorefter den skal slettes. Myndigheder med et særligt behov kan opbevare loggen i op til 5 år. Bemærk at det snarere er selve forespørgslen, fremfor de fremfundne data man er interesseret i at logge. For med forespørgslen i hånden er det i en kritisk situation muligt fra en database-backup at reetablere databasen til det rigtige tidspunkt, hvorefter forespørgslen kan anvendes til at gen-fremfinde de relevante data. Endvidere fortæller selve forespørgslen ofte mere om brugerens hensigter end de fundne dataelementer. Der er med andre ord behov for i et komplekst administrativt system at kunne generere og vedligeholde en liste over hvem, der hvornår, og med hvilken forespørgsel eller operation foretager sig hvad på en række forud definerede dele af databasen. Leverandører af kommercielle databasesystemer har, af mange grunde, været stærkt tilbageholdende med at tilbyde at foretage denne type logning i selve databasesystemet. Derfor har udviklere af offentlige administrative systemer været henvist til at implementere disse mekanismer i selve applikationerne. Af vigtige grunde til at afstå fra at tilbyde logning i selve databasesystemet, har følgende argumenter været fremført: Faciliteten er vanskelig at implementere, da en række objekter i databasen kan være mere eller mindre afhængige af de dele, der ønskes omfattet af logningskravet. Hvis tabellen Employees eksempelvis er omfattet, vil views og synonymer på denne tabel også være omfattet. Det er vanskeligt fra selve databasen generelt at udlede informationer om hvem, der via hvilke applikationer fremfinder et objekt omfattet af et logningskrav. En ting er at vide hvilket databaseskema der anvendes, vanskeligere er det at finde identiteten af brugeren, der i øjeblikket betjener sig af systemet. Når logning implementeres er det vigtigt at balancere anvendelse af loggene med hvor meget disse log-filer fylder, samt naturligvis størrelsen af den administrative byrde. Det er sjældent man har plads til eller behov for samtlige forespørgsler i et område, så det er vigtigt at kunne sætte så fint-maskede regler op som muligt, hvilket ikke er enkelt. Logning af søgninger i databasesystemet var ikke opført i the orange book om USA s militære sikkerhedsforeskrifter, hvorfor databasesystemer med amerikansk oprindelse normalt ikke har dette forhold i fokus. Dengang større administrative systemer bestod af en database, skærmbilleder og rapporter, var dette en besværlig men dog mulig opgave at implementere. Udviklerne skulle fremfinde alle de steder i skærmbilleder og rapporter, hvor man kunne tænkes at søge direkte eller indirekte efter personfølsomme informationer. g her skulle man så huske at implementere passende operationer, der kunne logge centrale informationer, hvis en bruger søgte efter informationer omfattet af logningskrav. Der er i dag flere grunde til at denne implementeringsstrategi i praksis ikke længere er anvendelig. Her er nogle af de væsentligste: Standardprogrammel. I modsætning til tidligere er det i dag helt normalt at de samme informationer fremsøges af forskellige applikationer. Nogle i form af programmerede rapporter, andre i form af ad hoc værktøjer, der automatisk genererer de SQL-sætninger, der henter de ønskede informationer frem, og atter andre der måske tilbyder at vise dele af databasens indhold som HTML eller XML i en browser. Her er det vanskeligt, og måske umuligt at implementere de mekanismer der skal logge søgning af personfølsomme informationer. Hastighed. Når selve skærmbilledet eller rapporten 4 ktober 2001 racleekspert

5 typisk afvikles i en browser eller på en dedikeret applikations-server uden for database-serveren, vil lognings-hændelser implementeret i applikationen give flere kald til databasen over netværket og dermed give anledning til mere netværksog I/-belastning med dårligere svartider til følge. Robusthed. Med de mange forskellige adgangsveje til de bagvedliggende informationer, er det vanskeligt at garantere, at samtlige veje til de personfølsomme informationer er beskyttet af lognings-mekanismer. Vedligehold. I et komplekst administrativt system vil lognings-mekanismerne skulle implementeres i CBL, C, Java, samt i værts-sprog i specialiserede værktøjer. Dette gør det meget vanskeligt at sikre sig, at lognings-mekanismerne virker ens overalt, samt at en ændring i virkemåden slår igennem alle steder. Bl.a af ovennævnte grunde har branchen gennem et stykke tid været på udkig efter løsninger der kunne håndtere lognings-mekanismerne i selve databasesystemet. I racle har en af løsningsmodellerne været at bede databasesystemet om at logge samtlige SQL-sætninger, og så lade sophistikerede parsere trække alle relevante dele ud i log-filer eller tabeller. Dette virker naturligvis, men er tungt og pladskrævende at administrere. Det er i dette lys, man skal se en af racle9i databasens faciliteter: Fine Grained Auditing. Fine Grained Auditing Antag at vi i databasen har en tabel med personers løn og ansættelsesforhold i en tænkt virksomhed. Netop løn og ansættelsesforhold kan vel siges at være personfølsomt. create table employees ( employee_no Number primary key, employee_name Varchar2( 30 ), hire_date Date not null, manager_no Number, job_category Varchar2( 10 ) not null, salary Number( 10 )); The Setup Her ønsker man måske at definere en sikkerhedsauditerings-politik om, at alle hændelser, hvor der på den ene eller anden måde, trækkes rækker fra tabellen, hvor salary kolonnen indgår og hvor job_category har værdien salesman, skal logges. Den sikkerhedsansvarlige kunne så implementere denne sikkerheds-politik centralt, uden at ændre nogen applikation, ved at skrive følgende: declare begin dbms_fga.add_policy( object_schema => 'system', object_name => 'employees', policy_name => 'employees_salesman', audit_condition => 'job_category = ''salesman''', audit_column => 'salary'); end; Logging Følgende SQL-sætninger vil nu alle blive logget hvis de resulterende rækker passer med at kategorien er salesman. select count( * ) from employees where job_category='salesman' and salary>1000; select employee_no, salary from employees where upper( job_category ) = 'SALESMAN'; select salary from employees where job_category ' m/k'='salesman m/k'; select salary from employees where job_category between 'salesman' and 'salesmen'; select count( * ), sum( salary ) from employees where job_category = 'salesman'; select count( * ), sum(salary) from employees group by job_category; select salary, job_category from employees where employee_no = 7499; select e.salary, e.job_category from employees m, employees e where m.employee_no = e.manager_no; select salary from employees where employee_no in (select employee_no from employees where job_category = 'salesman' ); select 'hello' from dual where 1000 < ( select max( salary ) from employees where employee_no in ( select employee_no from employees where job_category = 'salesman' )); Følgende DML sætninger logges ikke De kan derimod auditeres med almindelige autonome triggere: update employees set salary = salary where job_category = 'salesman'; delete from employees where job_category = 'salesman'; Øvrige afhængige databaseobjekter Nu er det jo helt sædvanligt at applikationernes SQLsætninger slet ikke direkte nævner den foreliggende tabel, men derimod synonymer, der refererer til mere eller mindre komplicerede views på tabellerne. Her skal sikkerheds-politikkerne naturligvis ligeledes så igennem automatisk! Følgende select sætninger logges alle (hvis der returneres relevante rækker). create or replace view employees_v as select * from employees; select salary from employees_v where job_category = 'salesman'; create or replace view employees_v2 as select salary,job_category from employees_v; select * from employees_v2 where job_category = 'salesman'; create synonym employees_s for racleekspert ktober

6 employees_v2; select * from employees_s where job_category = 'salesman'; create global temporary table employees_t on commit preserve rows as select * from employees_s; Mindre fintmasket logning Det er naturligvis også muligt helt at undlade at angive audit_column i sikkerhedspolitikken så vil selects mod enhver kolonne logges. I sikkerheds-politikken skal man derimod angive audit_conditon, så en måde hvorpå man alligevel kan bede om logning uden en reel betingelse er ved at angive: audit_condition => '1 = 1'. Faktisk også selvom ingen rækker fremfindes! declare begin dbms_fga.add_policy ( object_schema => 'system', object_name => 'employees', policy_name => 'employees_all', audit_condition => '1 = 1' ); end; Her vil følgende sætning blive logget: select 'x' from employees where salary>3000; g mere komplekse betingelser kan angives. Følgende politik vil logge select-sætningen neden for idet præsidentens manager nummer er null: declare begin dbms_fga.add_policy ( object_schema => 'system', object_name => 'employees', policy_name => 'employees_salesman', audit_condition => 'job_category = ''salesman'' or manager_no is null'); end; select salary, job_category from employees where job_category = 'president'; Prisen Hvad koster det så rent tidsmæssigt - at anvende denne form for sikkerhedsaudit? I mit eksempel er der 13 rækker i employees tabellen, så hvis jeg beder om det kartesiske produkt af tabellen med sig selv 4 gange fåes 13 * 13 * 13 * 13 = rækker: set timing on select count( * ), sum( a.salary ) from employees a, employees b, employees c, employees d; Det er på min PC umuligt at måle tidsforskelle, der kunne vise om ovenstående select var hurtigere uden fine grained audit end med, hvilket antyder at denne facilitet i sig selv ikke kræver voldsomt kraftige systemer. Bemærk i øvrigt, at når ovenstående select logges kommer den 4 gange i audittabellen, da vi netop i hver af de joinede tabeller støder på en tilstand, der kræver logging! Selve prisen for at indsætte en række i fga_audit tablen (sys.fga_log$), der er den egentlige ekstra operation, og er langt billigere end alternativerne, hvor det er selve de brugerskrevne programmer, der skulle have foretaget noget tilsvarende. Extensibility Selve de loggede informationer er tilgængelige via det centrale view dba_fga_audit_trail, hvor følgende informationer tilbydes: session_id, timestamp, db_user, os_user, object_schema, object_name, policy_name, scn, sql_text og sql_bind. Hvis dette ikke er nok, tilbyder sikkerhedspolitikken, at man angiver en procedure (handler_module), der kaldes når en select-sætning skal logges. I denne procedure som man selv kan implementere kan man så eksempelvis sende beskeder, og logge yderligere informationer. create or replace procedure extra_fga_info ( schema Varchar2 default 'n/a', tab_name Varchar2 default 'n/a', policy Varchar2 default 'n/a' ) as begin -- Assuming table fga_extra already exists insert into system.fga_extra (user_name, terminal, time_when) select user,userenv( 'terminal' ),sysdate from dual; end extra_fga_info; declare begin dbms_fga.add_policy ( object_schema => 'system', object_name => 'employees', policy_name => 'employees_salesman', handler_schema => 'system', handler_module => 'extra_fga_info', audit_condition => '1 = 1', audit_column => 'salary'); end; Administration Ved at anvende det centrale view user_audit_policies, er det muligt at se hvilke politikker der pt. er gældende på systemet. Der er endvidere mulighed for på et senere tidspunkt at afvikle samme select-sætning på nogenlunde det udseende, database havde da den aktielle select første ganeg blev afviklet. Hertil anvendes SCN (System Change Number) nummeret for audittabellen. Hvis dette SCN nummer ikke går længere tilbage i tid end det der svarer til indholdet i racle kernens UND segmenter, kan følgende flashback-kald bringe en session tilbage til det relevante tidspunkt, hvorefter select sætningen kan afvikles: execute dbms_flashback.enable_at_system_change_number( scn ); Hvis forespørgslerne går længere tilbage i tid må logminor eller point-in-time restore af databassen anvendes. Andre anvendelsesområder Anvendelse af views, synonymer mv. Det er også muligt i en sikkerhedspolitik kun at angive et view-navn frem for tabel-navn på denne måde er det muligt hurtigt og effektivt at finde ud af om et givet view fortsat er i anvendelse i systemet samt 6 ktober 2001 racleekspert

7 hvorledes det anvendes og af hvem. Andre fortrolige informationer Det står administratoren frit for at definere auditeringspolitikker på andre dele af systemet f.eks. på en tabel over lookup værdier for at vide mere om hvem der forespørger på hvilken måde på database objeker, der måske bør restruktureres. Performanceforbedring Ud over anvendelse af teknikken til opfyldelse af logningsbestemmelserne i bekendtgørelsen, som allerede omtalt, kan den skitserede teknik finde værdifuld anvendelse til at finde performance-svage områder af applikationssystemet. Ved at slå logning til for et givet database område, vil man kunne se, hvor hyppigt der søges i denne del af databasen, af hvem, og med hvilke SQL-sætninger, samt med hvilke værdier. Miracle's kommende arrangementer: RM-EUG okt. Vi har en Dogmestand hvor vi med bl.a Cary Millsap, Jonathan Lewis og James Morle vil afholde Challenge. Spørg os om hvad som helst racle-relateret, og hvis vi ikke svarer indenfor 24 timer får du en T-shirt med en tekst, der gør dig til en helt. FIRST Friday Fredag 9. november Samme dag, som vi fejrer vores 1-års-dag afholdes First Friday kl Læs mere på vores webside: MiracleAS.dk Deltag gerne i den efterfølgende fest. Miracle s 1-års fødselsdag Alle er velkomne fredag 9. november. Tilmeld jer på vores webside: Miracleas.dk Velkomstdrink mv. fra 18-19, spisning mv , musik og orkester (Back2Blue) fra 22 midnat. Derefter natmad. Jonathan Lewis kommer til Danmark januar 2002 g afholder et superkursus Reserver datoerne nu. Detaljer følger snarest. Vores website er blevet fornyet lidt. Der er nu mulighed for at registrere sig (ingen password bare rolig), modtage nyhedsbrev, downloade vores egen-udviklede tools samt klikke på Undskyld-linket og få sig et godt grin over Cary s overvejelser omkring ordet Undskyld. Helsidesannoncer i racleekspert fra DKK (excl moms) Læs mere på: racleekspert ktober

8 Designer Teknisk Artikel KICKING THE ASP UT F DESIGNER David Schleis, Wisconsin State Laboratory of Hygiene/ccupational Health Lab. Reprinted by permission from the DTUG 2001 Conference Proceedings. Notice that this is an updated version of the paper that was published at DTUG. Introduction The racle Designer WebServer Generator (WSG) generates web-based applications designed to run on an racle Web Application Server. These applications are generated based on module and database design specifications recorded in the Repository, and allow users to interact with an racle database over the internet. This is extremely useful if you are running an racle Web Application Server, but what if you are restricted to an existing web server? A web server that is very widely deployed because it comes with no additional (monetary) cost, but is included as part of the server operating system? The web server I am describing is Microsoft Internet Information Server, or IIS. Primarily because of its availability, IIS is a very popular web server, but I don t expect that Designer will ever cater to its users, of which I am one. But thanks to the remarkable extensibility of Designer, by using the same module and database design specifications as the WSG, the generation of Microsoft Active Server Pages (ASP) applications is possible. In the following pages I will give some background on the technologies used, and describe how to use the information stored in the Designer Repository to assist in the creation of N-tier ASP applications. Template ASP pages are generated as a foundation for the client tier. Visual Basic (VB) components are generated to provide the database interaction of the middle tier. And the data tier is supported with generated PL/SQL procedures that act as a translation layer between the VB component and the Designergenerated Table API. Given these building blocks, an ASP developer is able to design and deliver racle web-based applications without detailed knowledge of data access methodologies or PL/SQL. ASP 101 Active Server Pages, or ASP, runs in conjunction with Microsoft Internet Information Server (IIS) to provide an efficient and scalable web-based application platform. ASP applications can be created with serverside script using JavaScript or VBScript. Functionality beyond the capabilities of scripting is accomplished by calling ActiveX components resident on the server. When IIS gets a request for a page with a.asp extension, the server first compiles the scripted sections of the page and loads it into memory. The script then typically performs some operations that generate HTML that is written to the ASP page. The modified page is then returned to the client using a standard HTTP transaction. To the user on the client machine the page looks like a normal HTML page. An ASP application consists of five basic operations. 1. The ASP application is born the first time one of its pages is accessed after the web server is started, and it lives until the application or the web server is shut down. 2. The ASP server loads pages and creates server components to support the application. 3. An individual user creates a session by accessing one of pages of the application. This session exists until it is terminated by the loss of connection with the client or by scripted commands. 4. The application sends information to the client. 5. The client may need to send information back to the application. To accomplish these tasks there are five objects in the ASP object model to match these basic operations. These are the Application, Server, Session, Response and Request objects respectively. The Application bject bjects created within the scope of the Application object are available to all sessions of an ASP application. Since the purpose of the Application object is to provide a common data storage area, it has two methods, Lock and Unlock. Predictably these methods allow for exclusive access by a single session to the Application s shared data. The object also has an event that fires when the application is started and another that fires when it ends. These events are coded in the global.asa file. Global.asa is a file that must exist for each ASP application. This file is always found in the root directory of the project and is used to add application or session level events and components to the application. The Server bject The Createbject of the Server object is used to instantiate the server components that are used by the ASP application or by other components. Components can also be instantiated by using the <BJECT> tag in the global.asa file. ther methods of the Server bject include HTMLEncode and URLEncode. These methods apply HTML or URL encoding rules to a specified string to allow the string to be displayed on a web page. The Session bject A Session object is created for each client instance that accesses the ASP application. This object manages the components and data unique to each session. This information is tracked on the server by means of a SessionID property that uniquely identifies each session and provides a connection between the client and the data on the server. The Contents property holds variable information that can be used to maintain state unique to each client session. Like the Application bject, the Session bject also has nstart and nend events that are coded in the global.asa file. The Response bject The Response object sends information from the web server to the client. This object is responsible for maintaining the Cookies collection, which writes name-value information, including the SessionID value, to the client machine. Because this object is so heavily involved with client interaction it has a very rich object model, containing an additional nine properties and eight methods. f these additional methods 8 ktober 2001 racleekspert

9 the Write method is the most widely used. This method is used to write information to the HTTP output. This information typically consists of HTML tags interspersed with data values. The Write method is especially useful for creating much more readable code when the output is controlled by a looping or conditional statement that extends over several lines of code. This output can be buffered to prevent partial pages from being returned by using the Clear, End and Flush methods. The Redirect method transfers the browser to a designated URL that may belong to the current ASP application, or may be on an entirely different server. The Request bject The Request object is responsible for collecting the information sent back to the server by a web page. This information could be appended to the URL or posted from a form within the web page. Information appended to the URL of an ASP page is accessible through the QueryString collection of the Request object. This collection is an array consisting of namevalue pairs. Individual elements of the collection can themselves contain an array of values. Elements of the collection can be accessed using either positional notation or by name. Individual arrayed elements are accessed by using positional notation. The QuerySting collection can also be populated by using the GET posting of method of an HTML form. The Form collection contains a similar array of name-value pairs and is populated using the PST form posting method. The PST method is preferable to the GET method because there is a limit to the size of the string that can be appended to a URL. The Form elements are accessed in the same way as the QueryString elements discussed above. The Request object has three additional collections that can be quite useful. The Cookies collection retrieves the cookie information from the client. The ServerVariables collection contains information such as user name, password, browser type, remote connection information, and much more. Finally the ClientCertificate collection is used when running secure ASP applications. CM Components CM, or the Component bject Model, is a binary and network specification that defines a means of communication between compiled program objects. Components can be called by applications or by other components. All CM-based components can communicate regardless of the language that the component was originally written in. All that matters is that the component adheres to the specifications. Among these specifications are an ability to provide unique identifiers, immutable interfaces, a method to publish available interfaces and a method to track active references to an object to determine if it can be unloaded from memory. Fortunately the VB developer only need be concerned with keeping the interface consistant. The remainder of the requirements are handled by the compiler and the installer applications provided with VB. Although creating a CM component using C++ allows greater flexibility, the relative ease of using VB makes it an attractive choice when selecting a development tool. CM components can be written to provide functionality that is available through any other CM components and the Win32 API. ASP CM Components An ASP CM-based component, hereafter referred to as an ASP component, can have all of the functionality of a CM object, such as database access, file system access and printer access to name a few. Additionally, because they are designed to work within the IIS environment, these components have access to information stored within the ASP objects. This information includes field values submitted from an HTML form, the type of browser being used on the client, cookie values and much more. This information is, of course, available directly from the ASP page, so why go through the trouble of creating components when directly scripting ASP pages is simpler and seemingly more direct? ne reason is code re-use. Although useful sections of code can be cut and pasted between ASP scripts, if the code for this pasted functionality changes, this change needs to be repasted to all of the pages that contain the code. Alternately, all ASP applications can access a single physical component where any coding change can be applied with a single re-installation. The ability to simply reference an object s functionality makes code reuse simpler. Another reason is support. Because an ASP page is an ASCII text file, it can be easily modified by anyone with the appropriate permissions on the server. If your application is installed on a server beyond your control these modifications could introduce bugs. Placing vital bits of functionality within components helps to prevent this unwelcome modification. This brings up the point of security. By simply selecting View Source from the browser menu, the user on the client can see all the code on an ASP page. In many cases this is not a problem, but if the code is pure genius, and you don t want to give it away, or if the use of hard-coded user name/password is unavoidable, you do not want your code available so easily. Yet another reason is distribution. By using Distributed CM (DCM), the components themselves can reside virtually anywhere. While this could be achieved by distributing scripted pages to various machines, the maintenance and access issues are far more complex, and may require hard coding of page addresses. With CM-based functionality only the operating system needs to know where the components reside. Finally, ASP components allow for a wide range of functionality on the server that is difficult or even impossible to achieve with straight scripting, such as calls to the Win32 API or management of file input and output. UDA, LE DB and AD Universal Data Access (UDA) is a Microsoft initiative that is designed to provide high-performance access to all types of data on a variety of platforms, through a single data access model. Thus allowing access to the data in its native format without replication, transformation or conversion. Universal Data Access is an integral part of Windows Distributed Internet Applications architecture (Windows DNA). This means that UDA is integrated into current and future MS operating systems, tools and applications and is designed to work consistently across these major product lines. See Figure 1. At the heart of UDA lies LE DB. LE DB is an open specification for a set of CM interfaces that encapsulate data management services. LE DB was racleekspert ktober

10 designed to build on the success of pen Database Connectivity (DBC) and should be considered as an evolutionary step beyond DBC. Whereas DBC was designed to interact with relational data sources, LE DB is designed to access all data sources. The LE DB architecture consists of three major components: data providers, data consumers, and service components. All data providers expose their data in a tabular format through virtual tables, and can be broken down into two types, simple and complex. A simple provider is typically an in-house solution written in VB, C++ or Java, while a complex provider will generally be supplied by the company that created the application that owns the data. A complex provider typically provides functionality and efficiencies that could only be derived with proprietary knowledge of the system. Complex providers exist for many popular data formats, and simple providers can be created to expose virtually any data source. A data consumer is any object that accesses data from a data provider. Any consumer can access data from any provider when using the standard interfaces. Consumers are normally client/server applications, web applications and controls or other CM components. A service component is a stand-alone product that is plugged in only when needed to increase the overall efficiency of the data access code. These service components are logical objects that encapsulate a piece of DBMS functionality. Some available service components are the query processor, the cursor engine and the shaping service that allows for the creation of hierarchical recordsets. As might be expected, the majority of the existing complex data providers were developed by Microsoft. The very first LE DB data provider created was the Microsoft LE DB Provider for DBC Drivers. It allows the use of the LE DB object model through an DBC connection. Microsoft has also released providers for Jet (Access), SQL Server and racle along with others. Joining this list in March of 2000 was the racle Provider for LE DB (raledb). According to the documentation, it provides high-performance and efficient access of racle data by an LE DB consumer. The latest release of the provider (8.1.7) requires Windows 95, 98, 2000 or Windows NT 4.0, racle server or later and Net8 Client raledb supports input, output and input/input parameters for stored procedures and Figure 1. Universal Data Access Architecture functions and allows scalar and ref cursor return values. The provider recognizes the following racle datatypes: BFILE, BLB, CHAR, CLB, DATE, FLAT, LNG, LNG RAW, NCHAR, NCLB, NUM- BER, NUMBER (p, s), NVARCHAR2, RAW, RWID, VARCHAR. The ideals of Universal Data Access are brought to practical life through Microsoft ActiveX Data bjects (AD). AD provides a high-level API over an LE DB data provider. The advantage of AD (2.1) is an object model consisting of only 7 objects. The Connection object maintains information regarding the data source. The Command object manages the commands used to access the data. The Recordset object stores data in a row/column format and provides search and sort functionality. The Connection, Command and Recordset are considered high-level objects because they can be created and destroyed independent of other objects. This means that you can have a recordset with no active connection to the database, allowing for the loosely connected model required for internet transactions. The remaining objects, the Error, Property, Parameter and Field objects are components of the high level objects. The racle Designer Repository All of the information entered into Designer is stored in the tables of the Designer Repository. This data can be modified by use of the Designer API, but is accessible by querying the Repository Views. The Designer API documentation is an excellent resource for information about the structure and content of these views, and the Designer Repository View Model is available as an Application that can be imported into Designer. The file is RACLE_HME\Des2_71\Model\- Model_60.dmp. However the easiest way to obtain detailed information about any property in Designer is to select the property in the Repository bject Navigator and press the F5 key. To display the Property Details page for the Name property of an Entity, select Name on the Property Palette and then press F5 (see Figure 2). The Property Details page is then displayed (see Figure 3). This page provides all of the details neces- 10 ktober 2001 racleekspert

11 Figure 2. Repository bject Navigator view of a Bound Item of a Module Component. sary to reference this particular property. Taking the plural of the Name property and prefixing it with CI_ yields the view name. Therefore the bject Name DATA_BUND_ITEM becomes the view name CI_ DATA_BUND_ITEMS. Figure 3. Example of a Property Details Page. In the example seen in Figure 3, the SQL statement: SELECT NAME FRM CI_DATA_BUND_ITEMS WHERE ID = would return ACCUNT_NUMBER. Selecting the Model and API buttons on the Property Details page provides a wealth of information about the view and how to access it through the Designer API. From this information it was determined that the views shown in Figure 4 are critical to generation of code based on module definitions. Putting it All Together So what do we get when we mix racle Designer, AD and ASP? ASP Kicker is a Visual Basic application that uses information stored in the Designer Repository to generate three distinct types of code. First are VB classes that are designed to be compiled as ASP components. Second is PL/SQL code that acts as a Module API between the ASP component and the Designer generated Table API. And finally, ASP pages that utilize the compiled components. The program itself uses AD and raledb to query the Designer Repository to find the information needed to generate the code. The ASP components utilize AD to allow applications to interact with data from a wide variety of sources, and raledb to maximize the efficiency of the interactions with racle. The classes encapsulate database interaction, allowing an application developer to write data manipulation code without detailed knowledge of AD, PL/SQL or racle. Kicking Some ASP After a standard connection dialog, the user is presented with an Application System Selection dialog box similar to that presented by Designer. The list of applications available to the connected user (Figure 5) is obtained with the following query. SELECT cia.id, Figure 4. Repository views required to generate code from module definitions. racleekspert ktober

12 cia.name, cia.application_system_owner, cia.version FRM ci_application_systems cia, sdw_access_rights sdw WHERE sdw.ar_usr_granted_to = USER AND sdw.ar_sel_allw = 'Y' AND sdw.ar_appid_for = cia.id RDER BY cia.name nce a valid Application is selected, the Repository is queried for valid modules within the selected application system. SELECT id, name, short_name, implementation_name FRM ci_general_modules WHERE application_system_owned_by = IDvalue AND candidate_flag = 'N' AND prevent_generation_flag = 'N' Where IDvalue is the ID of the selected Application System. Upon selection of an Application System, the main program window (Figure 6) is displayed listing the modules for the selected application system. After selecting a module, the type of code that is to be produced and its destination are selected using the tabbed control in the lower half of the program window. The user then simply clicks on Generate, and the code is written to the designated directory. For the module-based code, the program first examines the settings of the Insert, Update, Delete and Query flags for each module component table or view (simply referred to as tables from this point). Based on these Figure 5. Application System Selection dialog box. values, the settings for each column of the table are examined, and the appropriate code is produced. Inserts and updates are not allowed on server-generated columns or primary keys. The module component information for the selected module is derived with the following query. Finally, the column level data is extracted with the following query. SELECT ci_dbi.id DBI_ID, ci_dbi.name name, insert_flag, select_flag, update_flag, nullify_flag, ci_col.id col_id, ci_col.datatype, ci_col.auto_generated, ci_col.maximum_length, ci_col.racle_bject_type_reference table_id, ci_col.relatin_type, ci_col.base_clumn_reference FRM ci_data_bound_items ci_dbi, ci_columns ci_col WHERE ci_dbi.column_reference = ci_col.id AND ci_dbi.module_component_reference=idvalue RDER BY usage_sequence Where IDvalue is the ID of the current Module Component. The PL/SQL Code Several types of PL/SQL code are produced. First is the Module API package. This package contains procedures corresponding to the procedures of the Table API generated by Designer (ins, upd, slct and del). Which of these procedures are included in the Module API is determined by the module definitions. For example, if the module is designed to only do inserts, then only the code of the insert procedure is generated. The package is named CG$<module_short_- name>, and the procedures are named <table_name>_- <DML_type>. Both package specification and body files are produced along with a script file that runs both. Each of the procedures has as its parameters the columns defined in the module. The type of each parameter (in, out or in/out) is determined by the requirements of the Table API. Within the procedure the indi- SELECT id, name, module_component_type, datasource_type, insert_flag, select_flag, update_flag, delete_flag FRM ci_module_components WHERE general_module_reference = Idvalue Where IDvalue is the value of the ID of the selected Module. Figure 6. ASP Kicker program window. 12 ktober 2001 racleekspert

13 vidual parameters are combined to create the records that the Table API requires as parameters. After successful completion of the Table API procedure, the PL/SQL record is transformed back into the individual parameters if required. If the module contains a view, a View API package is also generated. The View API is the equivalent of the Designer-generated Table API. This allows the Module API to treat views and tables identically. What makes this possible is the use of updateable views. In addition to the DML procedures, the View API also contains a trigger procedure. This is a procedure called by the instead-of trigger of the updateable view. The trigger procedure uses the underlying Table API to perform the desired database manipulations. The generated code of the trigger procedure is commented out by default due to the complex nature of the updateable view. The View API package is named CG$<view_name>. Again, both specification and body files are created. An example of a complete Module API package can be downloaded from racleekspert.dk. PL/SQL CDE SAMPLE CREATE R REPLACE PACKAGE BDY DC$RD001 AS cgc$sales_order_row cg$sales_order.cg$row_type; cgc$sales_order_ind cg$sales_order.cg$ind_type; cgc$sales_order_pk cg$sales_order.cg$pk_type; cgc$item_row cg$item.cg$row_type; cgc$item_ind cg$item.cg$ind_type; cgc$item_pk cg$item.cg$pk_type; --======================================== -- ITEM INS --======================================== PRCEDURE item_ins ( p_actual_price IN UT item.actual_price%type, p_item_id IN UT item.item_id%type, p_order_id IN UT item.order_id%type, p_product_id IN UT item.product_id%type, p_quantity IN UT item.quantity%type, p_total IN UT item.total%type ) IS BEGIN cgc$item_ind.actual_price := TRUE; cgc$item_ind.item_id := FALSE; cgc$item_ind.order_id := FALSE; cgc$item_ind.product_id := TRUE; cgc$item_ind.quantity := TRUE; cgc$item_ind.total := TRUE; cg$item.ins (cgc$item_row,cgc$item_ind); p_actual_price:=cgc$item_row.actual_price; p_item_id := cgc$item_row.item_id ; p_order_id := cgc$item_row.order_id ; p_product_id := cgc$item_row.product_id ; p_quantity := cgc$item_row.quantity ; p_total := cgc$item_row.total ; EXCEPTIN WHEN cg$errors.cg$error THEN RAISE_APPLICATIN_ERRR (-20000,cg$errors.GETERRRS); END item_ins; The ASP Component Code The generated ASP component code consists of a minimum of two files. The ASP component project file, named AK_<module_short_name>.vbp, contains references to the required Microsoft components as well as each of the generated component files named <module_component>.cls. The component contains 3 basic types of methods. First are the database interaction methods that correspond to the Table API procedures. Second are the ASP component methods that assist the developer in manipulating the ASP component objects. Third are the methods that generate the HTML that is sent to the client. And forth are the numerous support methods. nly the first three methods types are available to the developer. The Database Interaction Methods The component classes may contain one or all of the DML methods; Insert, Update, Delete and Select based on the module definition. The connection information is stored in the session variables username, userpass and datasrc. Each of the DML methods allows the use of an existing AD Connection object. This is done for two reasons. First, establishing a connection is a fairly expensive operation. Using an existing Connection object allows multiple DML operations to take place using a single connection. A network round trip is still required for each operation, but the overhead of establishing a connection is avoided. The second reason for a shared connection is to provide transaction control. If several DML operations are required for a complete transaction, a shared connection object can provide this support. The DML methods are Insert, InsertRecordset(), Update(), Delete() and SelectRecord(). ther clearly named database interaction methods include Query(), openra(), closera(), begintxn(), committxn() and rollbacktxn(). A more detailed explanation of these and all of the other ASP component methods can be found in the examples of the generated ASP code. The ASP Component Methods As stated earlier, this group of methods assists the developer in manipulating the objects of the ASP component. The component creates a session variable named Session( <column_name> ) for each of the columns defined in the module. The setsessnfrom- RecSet(), setsessnfromform() and copysession- Vars() methods each manipulate these session variables. The ASP component stores metadata information for the columns defined in the module. This consists of the columns data type, maximum length, display width, prompt, hint text, and flags to indicate if the column is to be displayed and if null values are allowed. The metadata is available to the developer by passing the column name to the methods ado- DataType(), oradatatype(), maxlen(), displaywidth(), prompt(), hinttext(), displayflag(), allownull(). Another component object is the SessionSet. The SessionSet object is a scaled-down recordset and is stored as a session variable. This allows for the basic functionality of a recordset without the overhead. The Session- Set object has only three methods. The addto- SessionSet() and removefromsessionset() methods add and remove records from the SessionSet, while the sessionsettable() method allows the data of the SessionSet to be displayed as an HTML table. This brings us to the third type of method available to the developer, the HTML methods. The HTML Methods These methods are designed to assist the developer with commonly used HTML data display mechanisms. racleekspert ktober

14 Public Function Insert(ptional useformdata As Boolean = True, ptional externalcnn As Variant = Nothing) As String Dim cmdle As New ADDB.Command Static cmdparam(6) As ADDB.Parameter Dim uselocalcnn As Boolean n Error GoTo ErrHandler uselocalcnn = externalcnn Is Nothing loadmetadata If useformdata Then setsessnfromform End If ' create ASP objects createasp ("object") createasp ("session") With objsession Set cmdparam(0) = cmdle.createparameter("actual_price", 131, adparaminpututput, 8, oradata("actual_price",.contents("item_actual_price"))) cmdle.parameters.append cmdparam(0) Note the oradata method converts the data from a string to the actual oracle data type Set cmdparam(1) = cmdle.createparameter("item_id", 131, adparaminpututput, 4, oradata("item_id", "")) cmdle.parameters.append cmdparam(1) Set cmdparam(2) = cmdle.createparameter("rder_id", 131, adparaminpututput, 4, oradata("rder_id", "")) cmdle.parameters.append cmdparam(2) Set cmdparam(3) = cmdle.createparameter("prduct_id", 131, adparaminpututput, 6, oradata("prduct_id",.contents("item_product_id"))) cmdle.parameters.append cmdparam(3) Set cmdparam(4) = cmdle.createparameter("quantity", 131, adparaminpututput, 8, oradata("quantity",.contents("item_quantity"))) cmdle.parameters.append cmdparam(4) Set cmdparam(5) = cmdle.createparameter("ttal", 131, adparaminpututput, 8, oradata("ttal",.contents("item_total"))) cmdle.parameters.append cmdparam(5) End With ' objsession ' if an external connection was not provided, create a connection object If uselocalcnn Then openra begintxn Else Set lcnn = externalcnn End If With cmdle.commandtype = adcmdstoredproc.commandtext = "DC$RD001.item_ins()".ActiveConnection = lcnn.execute End With initsessionvars objsession.contents("item_actual_price") = CStr(cmdParam(0).Value & "") objsession.contents("item_item_id") = CStr(cmdParam(1).Value & "") objsession.contents("item_order_id") = CStr(cmdParam(2).Value & "") objsession.contents("item_product_id") = CStr(cmdParam(3).Value & "") objsession.contents("item_quantity") = CStr(cmdParam(4).Value & "") objsession.contents("item_total") = CStr(cmdParam(5).Value & "") ErrHandler: If Err.Number <> 0 Then Insert = classerror("rd001.insert") If uselocalcnn And Not lcnn Is Nothing Then rollbacktxn End If Else Insert = "K" If uselocalcnn Then committxn End If End If Set cmdle = Nothing If uselocalcnn Then closera End If End Function Figure 7. ASP Component Code Example 14 ktober 2001 racleekspert

15 These methods rely on the metadata to determine if the data is to be displayed, and if so, the size of the text box and what to label the data item. The htmltable() method formats the results of a query as an HTML table. This method allows for the specification of several optional parameters that enhance the table s functionality. If a key column is specified, an additional column of radio buttons is added to the table to allow the user to select one row of the table. The value of the key column in the selected row can be accessed with the command Request.Form("TblSelect"). Specifying hrefcol and hrefdest cause the specified column to be formatted as an anchor tag that redirects the browser to the specified destination with the value of the of the selected row appended to the URL as a QueryString. The table can be stored as a session level variable to allow the table to be re-displayed without connecting to the database. The htmlselectlist() method formats the results of a query as an HTML select list. The method allows the developer to specify which columns to use as the display and the value elements of the list. Since select lists are often based on lookup tables, the method allows the select list to stored as an application-level variable. This means that the only the first person to use the application will actually have to connect to the database to populate the select list. For all subsequent references, the list is cached in the application tier. The showform() method generates the HTML to create a form using the prompt and display width metadata values. The developer can specify if required fields are to be indicated with a red asterisk by setting the starrequired parameter to true. The form can be used for input by default, or can be populated with the current session values for display or editing. Like the output of the other HTML methods, the form can be cached as an application or session-level variable. An example of a complete ASP Component file can be downloaded from Ekspert.dk. See the ASP Component Code Sample on figure 7. The ASP Code The generated ASP code is a- gain based on the table, view and module definitions recorded within racle Designer. A global.asa file that contains a reference to the Microsoft ActiveX Data bjects Library and initializes the database connection parameters is generated each time ASP code is generated. An ASP page with the name <module_short_name>.asp is created for each Module. Within this page an HTML form is defined that contains all of the Module component tables. The way in which these tables are displayed is determined by several factors. nly columns with the Display property set to Yes are shown on the page. If the table is designated for insert, update or delete, the table is displayed in a labeled text box format. Buttons for the associated functions for each of the DML operations are also created. If the table is designated as query only, it is displayed either as an HTML table or as an HTML select list if the LV Title property is not null. The resulting ASP page is not very useful without additional modification, however it provides a basic template for the developer to start with. To assist the developer in turning this basic page into a full-scale application, a file called <module_name>.txt is generated. This file describes all of the available variables and methods of the module allowing commands and variables to be copied and pasted into the working document. The following code examples were generated from the Module shown in Figure 8. Examples of all of the generated ASP files can be downloaded from ASP CMPNENT HELPER FILE ASP CM bject: RD001.V_RDER_ITEMS Session Select List name = Session("V_RDER_ITEMS_LIST") Application Select List name = Application("V_RDER_ITEMS_LIST") Session Form name = Session("V_RDER_ITEMS_FRM") Application Form name = Application("V_RDER_ITEMS_FRM") Session HTML Table name = Session("V_RDER_ITEMS_TABLE") SessionSet name = Session("V_RDER_ITEMS_RS") Set Session("V_RDER_ITEMS") = "" Figure 8. Repository bject Navigator view of the Module used for the example code. to clear the Session variables Session("v_order_items_actual_price") Response.Form("v_order_items_actual_price") Session("v_order_items_description") Response.Form("v_order_items_description") Session("v_order_items_item_id") Response.Form("v_order_items_item_id") Session("v_order_items_order_id") racleekspert ktober

16 Response.Form("v_order_items_order_id") Session("v_order_items_product_id") Response.Form("v_order_items_product_id") Session("v_order_items_quantity") Response.Form("v_order_items_quantity") Session("v_order_items_total") Response.Form("v_order_items_total") Available Methods of each ASP bject htmltable([strwhere], [includeheaders], [borderwidth], [keycol], [hrefcol], [hrefdest], [saveassesn]) Produces the HTML to display a table of data produced by a query using an optional where clause. mitting the where clause causes the entire table to be returned. The table can be saved as a session variable, otherwise it is sent directly to the Response bject. Returns "K" on success, otherwise an error message. strwhere: ptional String = "". Where clause of the query (without the "where"). includeheaders: ptional Boolean = True. Include headers in the HTML table. borderwidth: ptional Integer = 1. Border width of the HTML table. keycol: ptional String = "". Specifying a field name causes a column of radio buttons labeled "Select" and a form name of "tblselect" to be prepended to the table data. hrefcol: ptional String = "". Specifying a field name causes the field data to become a hyperlink to the hrefdest with the contents of the field appended to the URL as a QueryString. hrefdest: ptional String = "". Destination URL for the hrefcol. saveassesn: ptional Boolean = False. Save the HTML text as a session variable named <table_name>_table htmlselectlist(listname, [strwhere], [keycol], [displayfield], [selectedkey], [listsize], [multiselect], [saveasappl], [saveassesn]) Produces the HTML to display a select list of data produced by a query using an optional where clause. mitting the where clause causes the entire table to be returned. The table can be saved as an application or session variable, otherwise it is sent directly to the Response bject. Returns "K" on success, otherwise an error message. listname: Required String. Name of the HTML select list. strwhere: ptional String = "". Where clause of the query (without the "where"). keycol: ptional Integer = 0. Index of the field to be used as the value of the select list entry. displayfield: ptional Integer = 1. Index of the field to be used for display of the select list entry. selectedkey: ptional String = "". Specifying a key value causes that entry to be selected. listsize: ptional Integer = 1. The number of displayed rows of the select list. multiselect: ptional Boolean = False. Allow multiple selections. saveasappl: ptional Boolean = False. Save the HTML text as a application variable named <table_name>_list_a. saveassesn: ptional Boolean = False. Save the HTML text as a session variable named <table_name>_list_s. showform([fillit], [starrequired], [saveassesn], [saveasappl]) Produces the HTML to display a prompt/text box form of the fields in the module. The form can be saved as an application or session variable. It is always sent directly to the Response bject. fillit: ptional Boolean = False. Fill the form with the current session values. starrequired: ptional Boolean = False. Indicate required fields with a red asterisk by the text box. saveasappl: ptional Boolean = False. Save the HTML text as a application variable named <table_name>_frm_a. saveassesn: ptional Boolean = False. Save the HTML text as a session variable named <table_name>_frm_s. setsessnfromrecset(therecset) Sets the session variables to the values of the supplied recordset object. therecset: Required ADDB.Recordset setsessnfromform() Sets the session variables to the values in the form. copysessionvars(fromtable As String) Sets the session variables of the calling object to the values of like-named columns of the provided object. This is used to copy data from a view module to a table module. fromtable: Required String. This is a table or view name that has values to be copied. addtosessionset([useformdata]) This function adds a record to the SessionSet using data from the form or from the session variables. Note: The SessionSet is an ASP Kicker bject used to store a temporary table. Its designed use is to store the child records for a parent/child insert such as RDER/RDER_ITEMS. useformdata: ptional Boolean = True. Use values from the form. therwise use session variables. removefromsessionset(keycol As, keyval As String) This function removes an record from the SessionSet based on an indicated value of an indicated key column. See addtosessionset. keycol: Required String. The name of the column to be used as the removal key. keyval: Required String. The value of the column to be removed. sessionsettable(ptional includeheaders As Boolean = True, ptional borderwidth As Integer = 1, ptional keycol As String = "") This function displays the contents of the sessionset in an HTML table. See addtosessionset. Returns "K" on success, otherwise an error message. includeheaders: ptional Boolean = True. Include headers in the HTML table. borderwidth: ptional Integer = 1. Border width of the HTML table. keycol: ptional String = "". Specifying a field name causes a column of radio buttons labeled "Select" and a form name of "tblselect" to be prepended to the table data. Query([strWhere], [externalcnn], [setsessionvars], [xmldest]) Returns an ADDC Recordset bject based on the provided where clause. Can be used to fill session variables. 16 ktober 2001 racleekspert

17 strwhere: ptional String = "". Where clause of the query (without the "where"). externalcnn: ADDB.Connection = Nothing. Existing database connection. Used for extended transactions. setsessionvars: Boolean = False. Set the session variables to the first record of the returned Recordset. xmldest: String = "". If provided the Recordset is saved as an XML file to the indicated location. Insert([useFormData], [externalcnn]) Inserts record into database. Returns "K" on success, otherwise an error message. useformdata: ptional Boolean = True. Used values from the form, otherwise use session variables. externalcnn: ADDB.Connection = Nothing. Existing database connection. Used for extended transactions. InsertRecordSet([useFormData],[externalCnn]) Inserts a series of records (stored in a sessionset) into the database. Returns "K" on success, otherwise an error message. useformdata: ptional Boolean = True. Used values from the form, otherwise use session variables. externalcnn: ADDB.Connection = Nothing. Existing database connection. Used for extended transactions. Delete([useFormData], [externalcnn]) Deletes a record from the database. Returns "K" on success, otherwise an error message. useformdata: ptional Boolean = True. Used values from the form, otherwise use session variables. externalcnn: ADDB.Connection = Nothing. Existing database connection. Used for extended transactions. Update([useFormData], [externalcnn]) Updates a record in the database. Returns "K" on success, otherwise an error message. Begins a transaction. committxn() Commits a transaction to the database. rollbacktxn() Rolls back a transaction. ASP SAMPLE CDE <%@ Language=VBScript %> <% Response.Buffer=true %> <HTML> <HEAD> <META NAME="GENERATR" Content="ASP Kicker 1.0"/> <TITLE> VBCA rder Entry </TITLE> </HEAD> <BDY> <H2>VBCA rder Entry</H2> <FRM method="pst" action="ak_rd001.asp"> <% dim aksales_rder set aksales_rder = Server.Createbject("AK_RD001.SALES_RDER") aksales_rder.showform True Response.Write ("<p><input type=""submit"" name=""submit"" value=""insert""></p>") Response.Write ("<p><input type=""submit"" name=""submit"" value=""select""></p>") dim akitem set akitem = Server.Createbject("AK_RD001.ITEM") akitem.showform True Response.Write ("<p><input type=""submit"" name=""submit"" value=""insert""></p>") Response.Write ("<p><input type=""submit"" name=""submit"" value=""select""></p>") dim akv_rder_items set akv_rder_items = Server.Createbject("AK_RD001.V_RDER_ITEMS") akv_rder_items.htmlselectlist Response.Write ("<p><input type=""submit"" name=""submit"" value=""insert""></p>") Response.Write ("<p><input type=""submit"" name=""submit"" value=""select""></p>") %> </FRM> </BDY> </HTML> useformdata: ptional Boolean = True. Used values from the form, otherwise use session variables. externalcnn: ADDB.Connection = Nothing. Existing database connection. Used for extended transactions. SelectRecord([useFormData], [externalcnn]) Sets the appropriate session variables from values in the database. Returns "K" on success, otherwise an error message. useformdata: ptional Boolean = True. Used values from the form, otherwise use session variables. externalcnn: ADDB.Connection = Nothing. Existing database connection. Used for extended transactions. Note: to use the following database operations the object must be created as a session variable. openra() pens a connection to an racle database based on the values of Session("userName"), Session("userPass") and Session("dataSrc") Returns an ADDB.Connection closera() Closes the database connection. begintxn() Figure 9. Generated ASP as Viewed in a Browser. racleekspert ktober

18 The preceding ASP code would be displayed in a browser as seen in Figure 9. bviously the generated page is not of much use without modification. A simple demonstration ASP application built using the ASP Kicker components can be downloaded from Downloadable Code The code available for download at Ekspert.dk consists of all of the components necessary to build a simple ASP application based on the racle Data Browser demonstration tables included with racle This assumes that racle or greater is installed on a MS Windows platform along with the racle LE DB provider that can be downloaded from the racle Technology Network (technet.oracle.com/index.html). In addition to the pieces used to create the application is an annotated series of HTML pages that show how the demonstration project works in a browser. Using this demonstration walkthrough, the ASP code can be compared to the HTML that is sent to the browser. Additional comments about the downloadable code can be found in the downloadable file readme.txt. Conclusions racle Designer is a powerful tool that has the capability to produce racle WebServer applications right out of the box. This in itself is notable, but Designer s most powerful feature is its extensibility. By using the wealth of design and documentation information stored in the Designer Repository, the ability to generate web-based applications for other internet server software, such as Microsoft IIS, is possible. Active Server Pages applications can be relatively simple to program with a basic knowledge of HTML and either JavaScript or VBScript. However, more advanced applications that require database interaction may become overwhelming due to the added complexities of data access mechanisms and SQL. By using CM objects as a database interface, all of the data access code can be encapsulated and exposed by means of simple methods such as Select, Insert, Update and Delete, allowing the developer to concentrate on other aspects of the program. Another advantage of using CM objects is that it allows the application to load into memory only those selected bits of functionality that are required for the current operation to conserve server resources and provide scalibility. Although the ASP pages generated by ASP Kicker at this time are not necessaitly the desired end product, the methods provided by the ASP components allow users with a basic knowledge of ASP programming to build complex web-based applications to work against an racle database. References Developing ASP Components, Shelley Powers, Reilly, 1999 Visual Basic Developers Guide to ASP and IIS, A, Russell Jones, Sybex, 1999 The Generation of Visual Basic Class Modules from the racle Designer Repository, David Schleis; IUG-A Conference Proceedings, M A I L 30 I Løsning for Kryds&Tværs fra racleekspert nr 7 Vinder: ingen (der var desværre ingen korrekte besvarelser) D A D 20 7 I D 21 N 16 C A 34 1 T G D B M B M I D E V E L P E T 1 A N S E 35 N U L L J D L G T H P C C R F T G N F R 40 V 9 H A L 25 T R A P 43 F A L S E 12 T 1 31 T W R I C K P 46 N I C N A K G E T I N F L 37 R T I L L I 18 ktober 2001 racleekspert

19 Spred det glade budskab! Referer abonnenter og få signerede og numererede raclerne (se nederst på siden) tryk af raclerne Fax eller send kuponen til: Pythia Information Kongensvej Frederiksberg Fax: ABNNEMENT Eller bestil via vores hjemmeside: Eller nedenstående oplysninger til: Ja tak, jeg ønsker: salg@racleekspert.dk stk racleekspert nr 1 - DKK 125,00 pr stk...dkk stk racleekspert nr 2 - DKK 125,00 pr stk...dkk stk racleekspert nr 3 - DKK 125,00 pr stk...dkk stk racleekspert nr 4 - DKK 125,00 pr stk...dkk stk racleekspert nr 5 - DKK 125,00 pr stk...dkk stk racleekspert nr 6 - DKK 125,00 pr stk...dkk stk racleekspert nr 7 - DKK 125,00 pr stk...dkk stk racleekspert nr 8 - DKK 125,00 pr stk...dkk stk racleekspert nr 9 - DKK 125,00 pr stk...dkk stk stk racleekspert nr DKK 600,00 pr stk...dkk 1 års abonnement (6 numre) - DKK 600,00 pr stk...dkk Jeg vil gerne begynde abonnementet med racleekspert nr: - 40% ved samtidig køb af minimum 5 ens blade eller abonnementer...dkk - 45% ved samtidig køb af minimum 10 ens blade eller abonnementer...dkk - 50% ved samtidig køb af minimum 20 ens blade eller abonnementer...dkk - 60% ved samtidig køb af minimum 50 ens blade eller abonnementer...dkk Bemærk: Når abonnementerne købes med mængderabat bliver alle blade sendt i én samlet forsendelse. Det er altså ikke muligt at få bladene sendt til individuelle modtagere. Pris i alt Firma:...DKK Priserne er excl moms. Navn: Adresse: Postnr/By: Land: Ved hver tegning af minimum 1 års abonnement på racleekspert sender vi et stk signeret kvalitetskopi af raclerne til den læser, som har refereret den nye abonnent til os. Kopien er trykt på kraftigt papir. Den er nummereret og signeret med rød tush. Refereret af: Adresse: Postnr/By: Som referencegave ønskes en signeret kopi af raclerne fra racleekspert: En racleekspert-læser er en person med eget abonnement eller en person ansat i et firma, som har tegnet abonnement på racleekspert. Man kan ikke referere et abonnement til sig selv. Nr 1 Det er fordi de ikke kan li fremmednøgler... [ ] Nr 2 Det er jo også vores Designer mand... [ ] Nr 3 Har du prøvet at skifte din Where-clause ud med en Santa clause?... [ ] Nr 4 Pro*C... [ ] Nr 5 No more table space...[ ] Nr 6 Komme i Forms...[ ] Nr 7 Rodeo...[ ] Nr 8 Joins...[ ] racleekspert ktober

20 DBA Præsentation TFR: TRACE FILE REPSITRY Torben Holm & Mogens Nørgaard, begge Miracle A/S Indledning Det er egentlig Cary Millsaps ide: Tracefiler (uanset om de er normale level 1 eller mere barske level 4, 8 og 12 typer) hører til i en database i et repository, som man ynder at kalde en samling tabeller nu om dage. Når først tracefilerne er splittet op i deres atomare bestanddele, og loadet ind i tabeller, kan man jo spørge på kryds og tværs med SQL i stedet for at ræse rundt i kæmpefiler med vi eller det der er værre (hvad det så skulle være). Man kan spørge på tværs af sessioner, brugere, nedlukninger, ja endog databaser. Man kan selv bestemme hvordan outputtet skal formatteres (skal det ligne tkprof? Skal det være inkl. al den dejlige ekstra information fra level 4, 8 og 12? Hypertext? Browser? Jeg har personligt ingen kvalifikationer, og da slet ikke til at skrive sådan en tingest. Men det har Torben Holm, og det ser efterhånden ganske fornuftigt ud. Torben selv har som gammel, bitter udvikler fået sig én på opleveren ved at skrive TFR pludselig var han nødt til at forstå hvad tracefiler kan bruges til og hvilken rigdom af information de indeholder J. Selve produktet TFR har vi besluttet os til at forære væk, inkl. sourcekoden. Det er nok penge værd for nogle mennesker, men så skal vi til gengæld til at markedsføre og sælge det, opdatere det, teste det mod alle mulige versioner og platforme, og hvad ved jeg og så i øvrigt læne os tilbage og vente på, at nogen laver noget tilsvarende freeware. I stedet lægger vi det ud som helt åben PL/SQL source og håber at I vil bidrage med kommentarer og kodeforbedringer til alles fælles bedste. Det skulle for eksempel være en smal sag at lave sit helt eget output-format når nu alle data ligger i sølle tabeller med 2-3 nøgler. Det allerførste krav jeg stillede til Torben var, at han skulle være i stand til at loade den største og værste level 12-mother ind i TFR, slette tracefilen fysisk fra disken, og derpå udfra repositoriet generere en fil, der lignede den 100%, ikke 99%. Det gjorde han som det første. Det er ret forbløffende at se på. Vi blev af nogle kreative mennesker hos Dannet gjort opmærksom på, at dette med at have tracefiler i en databaser pludselig gør det meget nemmere at håndtere problematikken med deling af tracefiler, dvs. det gamle problem med at udviklerne gerne vil have adgang til deres tracefiler, men DBA en tøver pga. sikkerhedsovervejelser. Nu er alle jeres bekymringer flyttet ned i databasen :-). Jeg vil nu give ordet til Torben. Han har fortjent det. Hent TFR på Hvis du oven i købet registrerer dig først via 'Registrér' i venstre side bliver vi glade og sender dig information om opdateringer og nyheder - men det er selvfølgelig helt frivilligt. Før load - etablering af repository Hvis man ønsker at benytte TFR bør man have racles Apache listener (den følger med basen fra version så vidt jeg husker) eller lign. f.eks. Webdb listener, så man kan se outputtet i en browser. Man kan godt nok se en del via SQL*Plus men en browser gør det nemmere. Etableringen af selve TFR er nemt: Der findes et Install script der ruller de 15 tabeller og 4 packages, som repositoriet består af, ind. Man skal blot sikre sig at den bruger, der skal eje TFR, samt de tablespaces der skal bruges til data og indexer, er oprettet. Man skal desuden have SYS s password, da der skal grantes select til et par V$-tabeller. Måden der læses ind i TFR gør at man skal have sat en init.ora parameter - UTL_FILE_DIR der gør at man kan læse fra filsystemet. Ønsker man ikke det, er jeg sikker på at TFR relativt nemt kan ændres således, at der benyttes SQL*loader i stedet. Load af tracefiler Når TFR er etableret kan man begynde at loade tracefiler. Måden denne load virker på er i grunden meget simpel. Der findes et tfrload.cmd/tfrload.sh script der, som det første, udfører en dir/ls over i en fil. Når dette er gjort startes SQL*Plus og pakken m10046.importfile med tilhørende parametre. Import programmet læser nu tekstfilen og leder efter tracefil navne i denne, kalder derpå (rekursivt) sig selv og begynder at loade den første tracefil og derefter den næste og så fremdeles. Et problem er, hvis nogle af trace-filerne stadig er i brug og man derfor har et ukomplet billede af informationerne i denne/de trace-filer. Mener man, at man ikke har alt med kan man så køre igen. Importprogrammet holder informationer om den nye import op mod det der findes i TFR i forvejen. Hvis en fil findes i TFR og den i øvrigt har samme størrelse som den der bliver læst ind, antages det at filen ikke er ændret og den springes over. Er der derimod differencer, bliver de gamle informationer fjernet og filen loades på ny. Er det en fil på mange MB tager dette selvfølgelig tid, men alternativt skulle man på en eller anden måde - fortsætte fra hvor man var kommet til - på dette tidspunkt var det andet nemmere! Når man mener at en tracefil ikke mere er aktiv kan man så fjerne denne efter den er loadet. Efter load: Håndtering af tracefilerne og output fra dem! Når tracefilerne er loadet kan man så principielt begynde at søge rundt i TFR, men man kan også begynde ved at bruge browser-interfacet eller SQL*Plus (dette er pt. ikke fuldt implementeret), men hvis vi tager browser-vejen virker den sådan ca. på denne måde: 20 ktober 2001 racleekspert