340 likes | 452 Views
Delivering flexible applications using data-management patterns. Willem de Vries, Remia C.V. Simon Jasperse, Kiboko. Agenda. Remia, the company Remia and Plex Rolodex Remia Patterns Application Design Plex Observations ? time. Remia, The Company. 75+ years of food manufacturing
E N D
Delivering flexible applications using data-management patterns Willem de Vries, Remia C.V. Simon Jasperse, Kiboko
Agenda • Remia, the company • Remia and Plex • Rolodex • Remia Patterns • Application • Design • Plex • Observations • ? time
Remia, The Company • 75+ years of food manufacturing • 300+ employees • Flexibility as a strategic approach • IT-systems should support: • rapid change • diversified processes • IT-policy with strong development component
Remia and Plex • Long term AS/400 - iSeries experience • Using 2E since 1991 • Plex since 1999 for: • quality through standards enforcement • speed through reuse of functional patterns • Pattern development: • Framework-approach vs. • Explicit experience
Rolodex: the application • Centralised customer-info repository • Flexibility: structural perspective • different channels, different info • Flexibility: process perspective • short “time to change” • independent from IT department • Requirement: user perspective • easy and comprehensive
Rolodex: The Project • Base Layer • Separation of Logical and Physical • Introduction of “ Replace “ - entity • Separation of UI and DB models • First phase of application project • Redesign of Base Layer • Build of additional patterns in sync with Application Development
Rolodex: Categories of Patterns • Technical patterns: • Synchronisation / consolidation of data • History • Supporting patterns: • Polymorphism • Functional patterns: data-flexibility • User Managed Data • Query • XML
User Managed Data • User perspective • Definition of questions • Conditional application of question-groups • Developer perspective • Creation of answer-formats • Application within “owner-context” • Practice • Used within 4 different contexts
Comparison to _UserData • Goals are comparable • Difficult to adjust _UserData to Remia’s BasePattern • UI of _UserData too constrained • Limited run-time flexibility in _UserData • Didn’t like the licensing model…..
Query • User perspective • Conceptual vs. Table/Column view • Tree-wise presentation of compound queries • Developer perspective • Creation of answer-context • Creation of support for elementary concepts: Datatype + Operators • Technical: ODBC + AS/400 support
Comparison to Filter • Filter can be implemented fast • Drawbacks are: • attached to grid • based on single view • restricted operator-support for AS/400 implementation
XML • User perspective • Flexible presentations: layout • Selective presentation • Developer perspective • New schemata • Schema-extensions • Practice: • XML-based presentation combines with configurable data support
Patterns: User Managed Data • Application Demonstration • Enter relation data • Specify data for relation type
Rel_ RelType RelType _Char Owner_ Characteristic Characteristic _Data Owner_ Data Weekend (Yes/No) Max Pallet Weight (num) Patterns: User Managed Data • Design Relation Type Relation DataOwner Characteristic Delivery Conditions Product Sales Use in kg/week (num) Type of Product (list) Competitor (list) Data (format) ListData
Characteristics Characteristics Characteristic Owner_Characteristic Characteristic_Data OwnerData ListData Data Patterns: User Managed Data • Database Implementation
Characteristics.DataEntry Patterns: User Managed Data • Interface Implementation, Data Entry Data ¦ Value Characteristics Data Entry, Format
Patterns: User Query • Create and run query • Type A users in Java land, attending Edge 2002
Patterns: User Query • Query example • Type A users in Java land, attending EMEA • Type AANDJavaAND attending EMEA
Patterns: User Query • User Query Pattern • ERD • Combine queries (AND /OR) • UI to build combinations • Query by Platform • AS400 - file pointer • ODBC - SQL
Patterns: User Query • Polymorphism Pattern • Super - Subtype • Subtype • owned by supertype (query) • shared functionality (run query) • distinct functionality (query view / fields)
Proto Type Dispatch Runquery Sub Type 2 Sub Type 1 Dispatch Dispatch Runquery Runquery Patterns: Polymorphism Call RunQuery Dispatcher Super Type Dispatchers Runquery Common Functionality View1 View7
Stack SuperType Answer SubType Compound Query AND - OR Elementary Query SubType Query Composition Patterns: User Query • ERD Relation Query_ Owner Query
Answer ElementaryQuery Distribution RelationType Characteristic Connection CompoundQuery QueryComposition Stack Query Patterns: User Query • Implementation Call RunQuery
Patterns: XML/XSL • Application Demo
Patterns: XML/XSL • XML generation • DOM for xml generation • Scripting for DOM control • Conform with Plex conventions
Patterns: XML/XSL • XML Writer • Abstract functions • Write xml data from block/single fetch • XML generation options • Keys in node Attributes • Field Names for nodes • Impl Names for nodes
Patterns: XML/XSL • XML Writer Tree structure through object scoping • Function name => Node Name • Meta calls and parm mapping • Field names for field tags MijnAgenda.xml XML Generator function
Patterns: XML/XSL • XML Writer Implementation • Inherit from abstract functions • Replace View / Fetch functions
Patterns: XML/XSL • Display XML - XSL, ActiveX
Patterns: XML/XSL • Display XML - Runtime script generation to combine XML and XSL <html> <body> <script language=VBScript> set xml = CreateObject("Microsoft.XMLDOM") xml.async = false xml.load("klnkaart.xml") set xsl = CreateObject("Microsoft.XMLDOM") xsl.async = false xsl.load("Basis.xsl") document.write(xml.transformNode(xsl)) </script> </body> </html>
Patterns: XML/XSL Relatie.xml • XML for data exchange between platforms • Data transfer • 1 table = 1 file • Keys => Attributes
Patterns: XML/XSL • XML for data exchange • Process Data Communication Files DownloadInfo.xml
Observations • Flexibility and patterns • Balancing between developer and user • Weighing reusability and initial investment • Application Building • Poor impact analysis • Huge number of objects • Practical results • Fast implementation when needed • Small team delivers
Discussion Questions deVries@remia.nl simon@kiboko.nl www.kiboko.nl