1 / 71

Implementing the OpenEdge Reference Architecture

Implementing the OpenEdge Reference Architecture. John Sadd Progress Fellow and OpenEdge Evangelist. Agenda. Introducing the OERA Implementation Business Entities and Data Access Objects Business Logic Issues Introducing the Service Interface Layer Managing ProDataSet instances

paulineg
Download Presentation

Implementing the OpenEdge Reference Architecture

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Implementing the OpenEdge Reference Architecture John Sadd Progress Fellow and OpenEdge Evangelist

  2. Agenda • Introducing the OERA Implementation • Business Entities and Data Access Objects • Business Logic Issues • Introducing the Service Interface Layer • Managing ProDataSet instances • Context Management • Conclusions

  3. Modern Application Architecture Separated presentationand integration layers Common business logic withadvanced models Data accessabstracted fromstorage OpenEdge Reference Architecture – a layered view Users Enterprise Services Presentation Layer Integration Layer Business Servicing Layer Data Access Layer Managed Data Stores Unmanaged Data Stores

  4. Objectives Implementing the OERA: What are the goals? • To provide an understanding of the OpenEdge Reference Architecture by describing a sample implementation • To help you understand best practices for using OpenEdge features • To motivate architects & lead developers to think about applying the OERA to their own projects

  5. Implementing the OERA: What are non-goals? • Not a new framework • Not intended to be comprehensive or to cover all application use cases • Not intended to be commercialized • Not intended to be used without changes, extensions, and understanding

  6. How Should You Use It? • Use it to learn OERA concepts more deeply • Use it to learn how best to use OpenEdge 4GL constructs and other features • Consider it as a potentially useful starting point for OpenEdge 10 application development

  7. Who Is It For? • Architects and Lead Developers with • A strong knowledge of Progress 4GL development • Familiarity with key OpenEdge 10 features • Access to the latest release • Plans • To re-implement an application, or application modules • For a new development project

  8. What are the current OERI white papers? 1. Introduction 2. Business Entities and Data Access Objects 3. The Service Interface Layer 4. Using Advanced ProDataSet Language Features 5. Using an Unmanaged Data Store 6. Building a .NET Interface to Business Entities

  9. What additional papers are planned? 7. Advanced Business Logic Issues 8. Context Management 9. Building a WebSpeed User Interface 10. Auditing 11…

  10. What is in the sample implementation code base? • Templates directory • Template procedures for BE’s, DAO’s etc. • Support directory • Supporting supers & other procedures • Samples directory • Code samples from the papers • These use sports2000 but there is nothing database-specific about any sample code

  11. Where do I find it? • The white papers and sample code are on the PSDN website at: • psdn.progress.com/library/product_info/ oera/index.ssp • There will be ongoing updates • Second phase of 10.0 papers by Exchange • Later material will describe best practices for using OE 10.1 and its OO4GL features

  12. Agenda • Introducing the OERA Implementation • Business Entities and Data Access Objects • Business Logic Issues • Introducing the Service Interface Layer • Managing ProDataSet instances • Context Management • Conclusions

  13. The Business Entity and Data Access Object in the OERA Users Enterprise Services Integration Layer Presentation Layer Business Entity Business Servicing Layer Data Access Object Data Access Layer Managed Data Stores Unmanaged Data Stores

  14. Business Entities and Data Access Objects • The Business Entity manages the logical, internal view of application data • The Data Access Object manages the physical data store • It also handles the mapping to the logic view of the data

  15. Business Entities • The Business Entity manages the logical, internal view of application data • Data for the user interface and other application layers • Business logic written against these logical definitions • Data best represented as ProDataSets and their temp-tables • The Business Entity is the core of the value of building applications in OpenEdge

  16. Data Access Objects • The Data Access Object manages the physical data store • It understands the schema or other description of the physical data • It translates between this and the application’s logical view of the data • All references to the physical data store should be confined to the Data Access Object

  17. Basic goals of these two object types • Keep the application logic unaware of and independent of the physical data storage • Keep the Business Entities independent of the UI and other layers • Define well-managed APIs to communicate between layers • Build business objects according to well-defined templates and standards • Provide for maximum flexibility and maintainability

  18. The ProDataSet as a building block Data-Source1 Database Field MapCustNum Name Contact Query…Q1 for Customer CustomerTT OrderTT Data-Source2 6 1 01/05/9336 1 01/19/9379 1 02/10/93 1 Lift Line Skiing 2 Urpon Frisbee 3 Hoops Croquet Field MapOrderNum CustNum OrderDate Query… Q2 for Order Order Event Logic Customer 1 53 01/01/93 2 81 01/04/93 3 66 01/04/93 Lift Line Skiing Urpon Frisbee Hoops Croquet Dataset:Before-fillBuffer:Before-fillBefore-row-fill Row-Add Row-Delete… ProDataSet Data-Relation1

  19. Constructing the objects – temp-table definitions • Define temp-tables for logical data definitions • Each temp-table in its own include file DEFINE TEMP-TABLE eOrder FIELD OrderNum… etOrder.i DEFINE TEMP-TABLE eOrderLine FIELD OrderNum… FIELD LineNum… etOrderLine.i

  20. Temp-table Definitions • These temp-tables are the internal view of the data • Benefits: • Separate physical schema from logical • Separate server database connection from business logic • Allow a body of related data to be passed as a parameter (typically as part of a ProDataSet) • Allow a transaction scope independent of the database

  21. Prefix table name with e For example eCustomer Prefix include files with et etCustomer.i Rename fields for consistency or comprehensibility Remove unwanted: Fields Indexes Add other joined DB fields Add calculated fields that might be required for ease of use Add BEFORE-TABLE to end of definition when tracking changes Don’t use LIKE syntax Temp-table LIKE database-table Field LIKE database-field Guidelines for temp-table definitions Use Temp-DB and Temp-DB Maintenance Tool

  22. Sample: etCustomer.i • TEMP-DB Maintenance Tool added in 10.0B Release can help maintain include files

  23. One Temp-Table include file for each temp-table Code – samples\etOrder.i, etOrderLine, etItem /* Include file etOrder.i -- temp-table for Order DataSet */ DEFINE TEMP-TABLE eOrder BEFORE-TABLE eOrderBefore FIELD Ordernum AS INTEGER LABEL "Order Num" FORMAT "zzzzzzzzz9" INITIAL "0" FIELD CustNum AS INTEGER LABEL "Cust Num" FORMAT ">>>>9" INITIAL "0" FIELD OrderDate AS DATE LABEL "Ordered" FORMAT "99/99/99" INITIAL "TODAY" FIELD ShipDate AS DATE LABEL "Shipped" FORMAT "99/99/9999" FIELD PromiseDate AS DATE LABEL "Promised" FORMAT "99/99/99“ … /* Include file etOrderline.i */ DEFINE TEMP-TABLE eOrderLine BEFORE-TABLE eOrderLineBefore FIELD Ordernum AS INTEGER LABEL "Order Num" FORMAT "zzzzzzzzz9" INITIAL "0" FIELD Linenum AS INTEGER LABEL "Line Num" FORMAT ">>9" INITIAL "0" FIELD Itemnum AS INTEGER LABEL "Item Num" FORMAT "zzzzzzzzz9" INITIAL "0" … /* Include file etItem.i */ DEFINE TEMP-TABLE eItem BEFORE-TABLE eItemBefore FIELD Itemnum AS INTEGER LABEL "Item Num" FORMAT "zzzzzzzzz9" INITIAL "0" FIELD ItemName AS CHARACTER LABEL "Item Name" FORMAT "x(25)" … BEFORE-TABLE tracks changes!

  24. Constructing the objects – Data-Source objects ApplicationDatabase • Build Data-Source object procedure • Each maps a temp-table to its physical data DEFINE DATA-SOURCE srcOrder FOR QUERY qOrder. ATTACH-DATA-SOURCE() sceOrder.p etOrder.i DEFINE DATA-SOURCE srcOrderLine FOR BUFFER OrderLine. ATTACH-DATA-SOURCE() sceOrderLine.p etOrderLine.i

  25. Constructing the objects – ProDataSet definitions • Define ProDataSets for sets of related data • Each is the basis for a Business Entity DEFINE DATASET dsOrder FOR eOrder, eOrderline… dsOrder.i etOrder.i etOrderLine.i

  26. Building the ProDataSet include file Code sample: dsOrder.i – from template dsDataSet.i • Temp-tables defined and included separately • WINDOW-NAME preprocessor for the AppBuilder /* dsOrder.i -- ProDataSet definition for dsOrder. */ /* This is the signal that the include file reference is in an AppBuilder window. Define WINDOW-NAME therefore for all AppBuilder procedures, since the AppBuilder includes the temp-table includes on its own. */ &IF DEFINED(WINDOW-NAME) = 0 &THEN {etOrder.i} {etOrderLine.i} {etItem.i} &ENDIF DEFINE DATASET dsOrder FOR eOrder,eOrderLine,eItem DATA-RELATION OrderLine FOR eOrder,eOrderLine RELATION-FIELDS (OrderNum,OrderNum) DATA-RELATION LineItem FOR eOrderLine,eItem RELATION-FIELDS (ItemNum,ItemNum) REPOSITION.

  27. Constructing the objects – Data Access Object • Build Data Access Object for the DataSet • Manages all the Data-Source objects daOrder.p sceOrder.p dsOrder.i sceOrderLine.p

  28. Building the Data Access Object • Built from the template daEntity.p • Naming convention of da + entity-name • Includes the ProDataSet definition file • Can also include FILL logic that is beyond a single temp-table

  29. All the Data Access components together sceOrder.p DEF DATA-SOURCE ATTACH-DATA-SOURCE RowFill handler sceOrderLine.p DEF DATA-SOURCE ATTACH-DATA-SOURCE sceItem.p DEF DATA-SOURCE ATTACH-DATA-SOURCE daSupport.p initDataSources: daOrder.p {dsOrder.i} {daEntity.i} SUPER Application Database SUPER daOrderValidate.p (optional) eOrderLineModifyBeginTrans: SUPER

  30. The Data Access Object as a compound object • Everything is a super procedure of the DAO • The related procedures are started according to naming conventions • Can be run just once in a session and left running • Its parts can be reassembled in different ways • Validation logic can be in the DAO or delegated to a separate procedure

  31. Constructing the objects – Business Entities • Build a Business Entity for each ProDataSet • Manages business logic on the logical data • Defines the API for access from other objects DEFINE DATASET dsOrder FOR eOrder, eOrderline… BusinessLogic: END PROCEDURE. dsOrder.i etOrder.i etOrderLine.i

  32. Building the Business Entity • Based on a template: beEntity.p • Naming convention: be + entity name • Standard behavior starts the DAO • Supporting super procedure • Optional separate validation procedure

  33. Business Entity components together dsOrder.i {etOrder.i} {etOrderLine.i} {etItem.i} DEFINE DATASET… beOrder.p {dsOrder.i} {beEntity.i} beSupport.p fetchCustom saveChanges beEntity.i RUN daOrder.p SUPER beOrderValidate.p (optional) eOrderLineModifyPreTrans: SUPER Data Access Object

  34. Agenda • Introducing the OERA Implementation • Business Entities and Data Access Objects • Business Logic Issues • Introducing the Service Interface Layer • Managing ProDataSet instances • Context Management • Conclusions

  35. Example of “magic” behavior: Callbacks set by daSupport.p Code – support\daSupport.p PROCEDURE initDataSources : /* …code snippet that shows dataset check there is also code to generically check all buffers for callbacks - Look for DataSet-level events first. */ IF LOOKUP(phDataSet:NAME + "BeforeFill", cEntries) NE 0 THEN phDataSet:SET-CALLBACK-PROCEDURE ("BEFORE-FILL", phDataSet:NAME + "BeforeFill", TARGET-PROCEDURE). IF LOOKUP(phDataSet:NAME + "AfterFill", cEntries) NE 0 THEN phDataSet:SET-CALLBACK-PROCEDURE ("AFTER-FILL", phDataSet:NAME + "AfterFill", TARGET-PROCEDURE). /* …*/

  36. Data Access Object logic Issues • Leave out logic that doesn’t need access to the physical data • That belongs in the Business Entity • Decidewhere the logic should go • Single-table logic in its Data-Source proc • Logic with a larger scope in the DAO • Static versus dynamic table references • Access to other DAOs through their APIs for complex requests • Interaction with database trigger procs

  37. Data Access Object FILL logic • Example of logic that references more than one table in the ProDataSet • This should go into the Data Access Object itself PROCEDURE eOrderLineAfterFill: DEFINE INPUT PARAMETER DATASET FOR dsOrder. DEFINE VARIABLE dTotal AS DECIMAL NO-UNDO. FOR EACH OrderLine WHERE OrderLine.OrderNum = eOrder.OrderNum: dTotal = dTotal + OrderLine.ExtendedPrice. END. eOrder.OrderTotal = dTotal. END PROCEDURE.

  38. Data-Source Object FILL logic • Example of dynamic table reference: • Dynamic reference allows reuse PROCEDURE eItemAfterRowFill: DEFINE INPUT PARAMETER DATASET-HANDLE phDataSet. …. hItemName = phDataSet:GET-BUFFER-HANDLE("eItem"):BUFFER-FIELD("ItemName"). DO iType = 1 TO NUM-ENTRIES(cItemTypes): cType = ENTRY(iType, cItemTypes). IF INDEX(hItemName:STRING-VALUE, cType) NE 0 THEN hItemName:BUFFER-VALUE = REPLACE(hItemName:BUFFER-VALUE, cType, cType). END. END PROCEDURE.

  39. Business Entity logic • Validation and other business logic • Logic references the internal logical view of the data • References to other entities through their published APIs • Logic requiring knowledge of the physical schema is deferred to DAOs

  40. Business Entity logic issues • How strictly do I adhere to logic separation? • Do I use an API call just for a CAN-FIND? • Do I defer that to a database trigger? • How do I adjust BE logic to allow for re-use of tables in other ProDataSets? • When do I use static versus dynamic table and ProDataSet references?

  41. Business Entity update semantics in the sample implementation • Generic saveChanges for one or multiple rows in any number of related tables • Callouts to validation hooks based on procedure names • Database transaction per row • Can be modified to provide: • Custom control logic for the whole update • Saving all changes as a single transaction • Extensions to error handling logic

  42. Agenda • Introducing the OERA Implementation • Business Entities and Data Access Objects • Business Logic Issues • Introducing the Service Interface Layer • Managing ProDataSet instances • Context Management • Conclusions

  43. SOA – Service Interaction Model Enterprise Services Broker/ Directory Service Find / Details Publish Service Requestor Service Provider Bind Invoke Bus Task Bus Task Bus Task

  44. Application Domain Services Service Proxy Service Interface Presentation Container Domain Fn() Service Container Order Mgmt Other Services Financials

  45. Container Managed – Support Services Session/Context Management Auditing Security Client Side Server Side Presentation Container Fn() Service Proxy Service Container Service Interface Order Mgmt …

  46. The Service Interface Layer in the OERA Users Enterprise Services Integration Layer Presentation Layer Service Interface Business Servicing Layer Data Access Layer Managed Data Stores Unmanaged Data Stores

  47. Role of the sample Service Interface Layer • Manages server-side entities • Keeps an in-memory catalog of running instances • Provides standard one-call access to server-side procedures • Provides a single simplified API from client to server

  48. The Service Interface Layer Client Server UI Procedure Business Entity Data-Access Object DATASET dsOrder DATASET dsOrder DATASET dsOrder RUN fetchOrder IN hdsOrder (. . . , OUTPUT DATASET dsOrder BY-REFERENCE) RUN FetchWhere IN hEntity (. . ., OUTPUT DATASET phFetchDataSet BY-REFERENCE) fetchWhere: FILL ATTACH Client Proxy Procedure Server Gateway Procedure

  49. Client-side SI proxy Client proxy procedure User interface procedure proSIproxy.p PROC fetchWhere: RUN proSIgateway.p ON hAppServer (INPUT “Order”, INPUT “fetchWhere”…) PROC saveChanges: … dsOrderWinAdv.w {dsOrder.i} {proSIproxyStart.i} … RUN fetchWhere IN ghProxySIproc (INPUT “Order”, INPUT ttContextDSOrder, OUTPUT DataSet dsOrder). (call to server-side gateway)

More Related