A Functional Language for Specifying Business Reports Patrick Bahr - PowerPoint PPT Presentation

A Functional Language for Specifying Business Reports Patrick Bahr University of Copenhagen, Department of Computer Science paba@diku.dk 23rd Nordic Workshop on Programming Theory, M¨ alardalen University, V¨ aster˚ as, Sweden, October 26 - 28, 2011

Outline Enterprise Resource Planning Systems 1 Reports & Report Functions 2 Conclusions 3 2

Outline Enterprise Resource Planning Systems 1 Reports & Report Functions 2 Conclusions 3 3

What are Enterprise Resource Planning Systems? ERP systems integrate several software components that are essential for managing a business. ERP systems integrate Financial Management Supply Chain Management Manufacturing Resource Planning Human Resource Management Customer Relationship Management . . . 4

What do ERP Systems Look Like? 5

Issues of Many ERP Implementations Complexity processes are specified in general purpose language gap between specification and implementation large monolithic system Inflexibility code is duplicated in order to avoid unexpected side effects the use of general purpose languages makes customisation expensive the (relational) database determines the way data is stored and accessed 6

Outline Enterprise Resource Planning Systems 1 Reports & Report Functions 2 Conclusions 3 7

Entering POETS Process-oriented event-driven transaction systems compact core system • customisable via DSLs • simple data model query results Contract engine Report engine Report engine Running Report Report contracts definitions definitions updates events start contract add/delete report add/delete report Event register event modify report modify report log end contract query report query report 8

What is a Report? Event Log Report Report Function event 1 invoice 1 { invoices : [Invoice] event 2 invoices = [ Invoice { customer = { . . . } , customer = ii.customer@, event 3 orderLines = { . . . } orderLines = ii.orderLines } | tr : TransactionEvent ← events , event 4 } ii : IssueInvoice = tr.transaction] event 5 invoice 2 { event 6 customer = { . . . } , event 7 orderLines = { . . . } event 8 } event 9 invoice 3 { event 10 customer = { . . . } , orderLines = { . . . } } 9

The Report Language The central data types records: events are records lists: the event log is a list of events Nominal subtyping Event Transaction Entity Contract Report Issue Transfer Event Event Event Invoice Put Delete Payment Delivery Entity Entity 10

The Report Language – An Example Function Report Event Hierarchy Example Report reportNames : [ String ] Event reportNames = [ pr . name | cr : CreateReport ← events , Put Delete pr : PutReport = head [ ur | Report Report ur : ReportEvent ← events , ur . id ≡ cr . id ] Create Update ] Report Report 11

Nominal Subtyping with Benefits Nominal subtype relation < : User defined subtyping partial order on records Fixed subtyping relation on built-in types Record Constraints τ 1 . f : τ 2 E.g. field selector operator . f has type α. f : β ⇒ α → β E.g. record modifier operator { f 1 = , . . . , f n = } has type α. f 1 : α 1 , . . . , α. f n : α n ⇒ α → α 1 → . . . → α n → α 12

Record Field Constraints What do we gain? Field names can be used by different record types. Nominal subtyping feels like structural subtyping (unless you want to create a record). Example fullName : ( a . firstName : String , a . lastName : String ) ⇒ a → String fullName x = x . firstName + + " " + + x . lastName setFullName : ( a . firstName : String , a . lastName : String ) ⇒ String → a → a setFullName name x = let ( first , last ) = decompose name in x { firstName = first , lastName = last } 13

Making It Scale ain’t easy Report R obsolete event 1 event 2 report function r event n event n+1 old result + ∆ Report R ′ r ′ incrementalised variant of r 14

Automatic Incrementalisation of Report Functions Basic idea: unfolding folds fold f e ( x # xs ) = f x ( fold f e xs ) ���� � �� � new element old (intermediate) result Limitations This works well with single folds. For nested folds more powerful equations are needed. ◮ commutative operations ◮ multisets instead of lists 15

Outline Enterprise Resource Planning Systems 1 Reports & Report Functions 2 Conclusions 3 16

Conclusions The Last Slide What do we have? Simple yet powerful data model for ERP Purely functional language for extracting & aggregating complex information Highly customisable & flexible Incrementalisation of report functions What are we planning? More powerful incrementalisation transformations Possibly restricting the language further A better cost model 17