Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Harmony concepts and design Guide.doc Page 1 
Harmony concepts and design guide 
Harmony 
Concepts & Design 
Reference gui...
Harmony concepts and design Guide.doc Page 2 
Harmony concepts and design guide 
Version Management # Date Author Descript...
Harmony concepts and design Guide.doc Page 3 
Harmony concepts and design guide 
Table of Contents 
Version Management ......
Harmony concepts and design Guide.doc Page 4 
Harmony concepts and design guide 
Implementing Relation Kernel – Fraud dete...
Harmony concepts and design Guide.doc Page 5 
Harmony concepts and design guide 
Table of figures 
Figure 1 Typical flowch...
Harmony concepts and design Guide.doc Page 6 
Harmony concepts and design guide 
Figure 46 Expression to calculate distanc...
Harmony concepts and design Guide.doc Page 7 
Harmony concepts and design guide 
Introduction 
The purpose of this “concep...
Harmony concepts and design Guide.doc Page 8 
Harmony concepts and design guide 
Terms 
Name 
Description Event An Event d...
Harmony concepts and design Guide.doc Page 9 
Harmony concepts and design guide 
 Order date;  Customer name 
Pair Type ...
Harmony concepts and design Guide.doc Page 10 
Harmony concepts and design guide 
Introduction 
This concepts and design g...
Harmony concepts and design Guide.doc Page 11 
Harmony concepts and design guide 
Creating applications: using a flowchart...
Harmony concepts and design Guide.doc Page 12 
Harmony concepts and design guide 
Harmony provides many more functions sin...
Harmony concepts and design Guide.doc Page 13 
Harmony concepts and design guide 
Reference data (database / table) 
Refer...
Harmony concepts and design Guide.doc Page 14 
Harmony concepts and design guide 
Introducing decision tables 
There are m...
Harmony concepts and design Guide.doc Page 15 
Harmony concepts and design guide 
A “multi dimensional” decision table (MD...
Harmony concepts and design Guide.doc Page 16 
Harmony concepts and design guide 
Overview of Harmony “configuration” opti...
Harmony concepts and design Guide.doc Page 17 
Harmony concepts and design guide 
The HARMONY UI (user interface) - web-pa...
Harmony concepts and design Guide.doc Page 18 
Harmony concepts and design guide 
The sample case– tourism on-line booking...
Harmony concepts and design Guide.doc Page 19 
Harmony concepts and design guide 
Creating the business application/system...
Harmony concepts and design Guide.doc Page 20 
Harmony concepts and design guide 
Creating dialogs (workflow steps) 
Figur...
Harmony concepts and design Guide.doc Page 21 
Harmony concepts and design guide 
Figure 18 Generated user interface [dial...
Harmony concepts and design Guide.doc Page 22 
Harmony concepts and design guide 
Tip: condition workflow steps through va...
Harmony concepts and design Guide.doc Page 23 
Harmony concepts and design guide 
Figure 25 Previewing the email – note Du...
Harmony concepts and design Guide.doc Page 24 
Harmony concepts and design guide 
Adding complexity – “Stay details’ dialo...
Harmony concepts and design Guide.doc Page 25 
Harmony concepts and design guide 
Figure 32 executing "Stay details" – ava...
Harmony concepts and design Guide.doc Page 26 
Harmony concepts and design guide 
a. prompt for friends.email – to be used...
Harmony concepts and design Guide.doc Page 27 
Harmony concepts and design guide 
Modeling data: the relationship kernel 
...
Harmony concepts and design Guide.doc Page 28 
Harmony concepts and design guide 
Implementing Relation Kernel – Fraud det...
Harmony concepts and design Guide.doc Page 29 
Harmony concepts and design guide 
We won’t describe the steps to create th...
Harmony concepts and design Guide.doc Page 30 
Harmony concepts and design guide 
The 2nd step involves retrieving the loc...
Harmony concepts and design Guide.doc Page 31 
Harmony concepts and design guide 
67. We set the transaction window to 3 m...
Harmony concepts and design Guide.doc Page 32 
Harmony concepts and design guide
Harmony concepts and design Guide.doc Page 33 
Harmony concepts and design guide 
Harmony UI customization 
(Editor’s note...
Harmony concepts and design Guide.doc Page 34 
Harmony concepts and design guide 
Tech talk 
(Editor’s note: this section ...
Harmony concepts and design Guide.doc Page 35 
Harmony concepts and design guide 
HARMONY mobile web parts 
(Editor’s note...
Harmony concepts and design Guide.doc Page 36 
Harmony concepts and design guide 
HARMONY provides an out-of-the-box Mule ...
Harmony concepts and design Guide.doc Page 37 
Harmony concepts and design guide 
Some of the technical design concepts th...
Harmony concepts and design Guide.doc Page 38 
Harmony concepts and design guide 
Authentication 
(Editor’s note: this sec...
Harmony concepts and design Guide.doc Page 39 
Harmony concepts and design guide 
Quality assurance standards 
All of HARM...
Harmony concepts and design Guide.doc Page 40 
Harmony concepts and design guide 
Positioning Harmony in the Gartner Magic...
Upcoming SlideShare
Loading in …5
×

Harmony concepts and design guide v0.2

1,234 views

Published on

An introduction to / get started with Harmony. This concepts and design guidelines & best practices gets users started creating systems (applications) and provides instructions how to create complex enterprise systems.

Published in: Software
  • Be the first to comment

  • Be the first to like this

Harmony concepts and design guide v0.2

  1. 1. Harmony concepts and design Guide.doc Page 1 Harmony concepts and design guide Harmony Concepts & Design Reference guide version 0:22 / 9 sept 2014
  2. 2. Harmony concepts and design Guide.doc Page 2 Harmony concepts and design guide Version Management # Date Author Description 0.1 27 April 2014 Kasev, Laan (vd) 1st draft – based on Harmony Orchestration Guide 0.11 29 April Kasev reviewed 0:12 30 April Laan (vd) midications 0:21 16 July Laan (vd) Added release 3.0 / Fraud / Relation Kernel expressions. Not reviewed! 0:22 9 Sept Laan (vd) Added the resulting REF_Transaction file output Related information Title # Date Author Description Harmony Users Guide 3.0 2 Feb 2014 Kasev,Laan history and decision support, workflow, UI proto v0.1, rules, business events. Limited testcases. Published/distributions # Channel Date By Remarks 0.2 gDOCS 16 July Nanno Google DOCS for AltosCloud project, SlideShare for interested persons Excluded Testimony / data driven development
  3. 3. Harmony concepts and design Guide.doc Page 3 Harmony concepts and design guide Table of Contents Version Management ......................................................................................................................... 2 Related information ............................................................................................................................ 2 Table of figures ................................................................................................................................... 5 Introduction ............................................................................................................................................ 7 About Harmony ................................................................................................................................... 7 Typical Harmony users .................................................................................................................... 7 Harmony, what it does .................................................................................................................... 7 Harmony product development strategy ........................................................................................... 7 Terms ...................................................................................................................................................... 8 Introduction .......................................................................................................................................... 10 Creating applications: using a flowchart to explain Harmony .............................................................. 11 A “typical” flowcharted (process, decision, database, groups [users]) ............................................ 11 The ‘typical’ flowchart in Harmony terms ........................................................................................ 11 Flowchart symbols “mapped” to Harmony concepts ....................................................................... 11 Dialogs (process steps) .................................................................................................................. 12 Rules (decision) ............................................................................................................................. 12 Templates (email) ......................................................................................................................... 12 Authorization (groups and users) ................................................................................................. 12 Reference data (database / table) ................................................................................................ 13 Introducing decision tables ................................................................................................................... 14 Capture complex logic: Decision Tables (DTs) .................................................................................. 14 DMN – Decision Modeling Notation – the OMG standard ........................................................... 14 The “standard” decision table ...................................................................................................... 14 A “multi dimensional” decision table (MDT) … ............................................................................. 15 Rules and logic in “rules” (versus in Decision Tables) ................................................................... 15 Overview of Harmony “configuration” options .................................................................................... 16 The HARMONY UI (user interface) - web-parts .................................................................................... 17 The sample case– tourism on-line booking .......................................................................................... 18 Creating the business application/system: book an accommodation .................................................. 19 Creating dialogs (workflow steps) ..................................................................................................... 20 Adding the “Stay details’ dialog to the workflow ......................................................................... 20 Creating the sequence, aka process flow / workflow using rules................................................. 21 Defining presentation logic ........................................................................................................... 22 Configuring email (and provide access to Customer profile) ....................................................... 22 Adding complexity – “Stay details’ dialog ......................................................................................... 24 Creating the REF_Availability and a unique ID ( key) – to retrieve price & quantity ................... 24 Sensor processing ......................................................................................................................... 25 Accessing multiple records, the “is” operation. Loyalty (friend’s) discount sample ....................... 25 Modeling data: the relationship kernel ................................................................................................ 27
  4. 4. Harmony concepts and design Guide.doc Page 4 Harmony concepts and design guide Implementing Relation Kernel – Fraud detection ............................................................................. 28 Logic (rules) to process the ATM withdrawal & card swipe ......................................................... 29 Creating relationships ................................................................................................................... 31 Harmony UI customization ................................................................................................................... 33 The PHP library .............................................................................................................................. 33 Tech talk ................................................................................................................................................ 34 About orchestration and choreography ........................................................................................... 34 HARMONY mobile web parts ............................................................................................................ 35 Features ............................................................................................................................................ 35 Integration scenarios ........................................................................................................................ 35 Modernizing the AS400 – integration thru web services and ESB ................................................ 35 Some of the technical design concepts that are applied in Harmony .................................................. 37 Complex Event Processing (CEP) ....................................................................................................... 37 The OpenAjax UI event bus ............................................................................................................... 37 Rule (logic) based, decision tables – the RETE algorithm ................................................................. 37 Authentication ...................................................................................................................................... 38 Quality assurance standards ................................................................................................................. 39 Positioning Harmony in the Gartner Magic Quadrant .......................................................................... 40
  5. 5. Harmony concepts and design Guide.doc Page 5 Harmony concepts and design guide Table of figures Figure 1 Typical flowchart processes, decisions, data and groups (swim lanes) .................................. 11 Figure 2 High-level overview of mapping "flowchart symbols" to Harmony ....................................... 11 Figure 3 Dialog definition ...................................................................................................................... 12 Figure 4 Process flow defined with Harmony ....................................................................................... 12 Figure 5 Templates definitions for eMail and Calendar ........................................................................ 12 Figure 6 Groups (swim lanes) ................................................................................................................ 12 Figure 7 User authorization .................................................................................................................. 12 Figure 8 Sample of a table .................................................................................................................... 13 Figure 9 Standard decision table “determine treatment level – payment overdue” ........................... 14 Figure 10 multi-dimensional decision table .......................................................................................... 15 Figure 11 Overview Harmony.sheets (spreadsheets) ........................................................................... 16 Figure 12 Harmony UI - standard web parts ......................................................................................... 17 Figure 13 Harmony web parts overview (User Interface)..................................................................... 17 Figure 14 The flowchart of the tourism booking process .................................................................... 19 Figure 15 Mapping "flowchart symbols" to Harmony .......................................................................... 19 Figure 16 creating the search destination dialog (User Interface) ....................................................... 20 Figure 17 Creating the REF_Parc table (database) .............................................................................. 20 Figure 18 Generated user interface [dialog] “Stay details” .................................................................. 21 Figure 19 Dialog configuration for Stay details ..................................................................................... 21 Figure 20 Rules controlling the workflow ............................................................................................. 21 Figure 21 Presentation logic - dialog items hidden .............................................................................. 22 Figure 22 Presentation logic - the dialog items are visible .................................................................. 22 Figure 23 Presentation logic - hiding dialog items (dialog.sheet) ......................................................... 22 Figure 24 same - showing dialog items (rules.sheet)............................................................................ 22 Figure 25 Previewing the email – note Dutch UI implementation ....................................................... 23 Figure 26 Configure sending email & access to profile ......................................................................... 23 Figure 27 Customer profile accessible to user ...................................................................................... 23 Figure 28 Email template "mailing list” – the template contains access to the “customer profile” .... 23 Figure 29email as delivered in InBox .................................................................................................... 23 Figure 30 Layout of the REF_Availability table ..................................................................................... 24 Figure 31 expression to create the key for accessing the Availability file ............................................ 24 Figure 32 executing "Stay details" – availability.ID retrieves price ...................................................... 25 Figure 33 Checking a file using a different key ... The "is" function ..................................................... 26 Figure 34 Traditional data model .......................................................................................................... 27 Figure 35 “Schema less” design: the Harmony datamodel .................................................................. 27 Figure 36 Defining relationships - the RK model .................................................................................. 27 Figure 37 the actual data (RK Store) ..................................................................................................... 27 Figure 38 Bank object model (graphical representation) ..................................................................... 28 Figure 39 Bank object model (Harmony implementation) ................................................................... 28 Figure 40 ATM withdrawal dialog ......................................................................................................... 28 Figure 41 ATM master file - with geo coordinates ............................................................................... 28 Figure 42 ATM Transaction [file] ........................................................................................................... 28 Figure 43 ATM withdrawal logic: writing data to the Transaction file ................................................. 29 Figure 44 How the data is stored in the transaction file (a Google spreadsheet) ................................ 29 Figure 45 44 ATM withdrawal: computing GEO location & transaction time of last withdrawal ........ 30
  6. 6. Harmony concepts and design Guide.doc Page 6 Harmony concepts and design guide Figure 46 Expression to calculate distance and elapsed time for ATM withdrawals ........................... 30 Figure 47 Decision Table providing Fraud Description outcome related to ATM locations ................. 30 Figure 48 Calculating average transaction amount within a set time frame........................................ 31 Figure 49 Creating relationships ... linking transactions to ATM and debit card .................................. 31 Figure 50 RK_Store contains the relationships for each transaction .................................................... 31 Figure 51 Harmony UI architecture / presentation tier ........................................................................ 33 Figure 52 Mobile web parts .................................................................................................................. 35 Figure 53 CEP context ........................................................................................................................... 37 Figure 54 webpage "template" for OpenAjax ....................................................................................... 37 Figure 55 The more data becomes "known" the more predictive info becomes available ................. 37 Figure 56 Implemented authentication mechanisms ........................................................................... 38
  7. 7. Harmony concepts and design Guide.doc Page 7 Harmony concepts and design guide Introduction The purpose of this “concepts and design guide” is to familiarize (future) users with new ways of building (designing, “building” and maintaining) the next generation of cloud IT systems About Harmony Harmony is productivity platform for building web-based & mobile web applications – a so called Platform-as-a-Service (PaaS) solution. Harmony is a Do It Yourself IT solution addressing the following audiences: Typical Harmony users 1. Domain (subject matter) experts – business professionals with in-depth industry knowledge of business rules and detailed processes. Within this category we identify a. business analysts– using Harmony to validate process maps/designs by feeding data into the process b. expert users (employees) – instead of documenting their knowledge in textual documents – they use Harmony formatted spreadsheets to documenting. This ‘configuration-style-documentation’ approach turns business rules / decision logic – and workflows – into a ready to execute format (i.e. an application). 2. Spreadsheet power users – persons with a solid understanding of the power of spreadsheets that want to develop (part of) their own business applications 3. IT professionals looking to develop easy-to-maintain high performance, secure cloud applications. Involved is a wide spectrum of IT experts … who identify themselves with a. unfamiliarity with the risks involved with “the cloud” b. developers realizing that they have to moving away from traditional programming languages such as COBOL, RPG, Java, PHP etc c. developers who like to take advantage of modern IT concepts such as business rule driven development Harmony, what it does Harmony provides a spreadsheet framework to configure business applications, instead of coding applications – freeing users from worrying about functional semantic issues (are the specifications correctly defined, are they developed correctly?) and technical issues – such as performance, security and scalability. Harmony also provides guidance on [a] reference architecture, application integration and data driven development. Harmony product development strategy Harmony adapts to modern open standards and using technologies and concepts that have been, and are still being, developed by industry leaders such as Google. The Harmony development path is agile, evolutionary, delivering new functions as when these are needed. The development sequence is practice driven - new features being implemented as standard patterns emerge – matching requirements as defined by customers as well as trends defined by industry leaders.
  8. 8. Harmony concepts and design Guide.doc Page 8 Harmony concepts and design guide Terms Name Description Event An Event describes, in accordance with DIN 69900, an occurred defined condition that causes a sequence of activities. Therefore the event is a passive component and may have no function in contrast to the decision- making authority. Events can trigger functions. Functions are triggered by events. Events describe an occurring condition Business event (BE) A business event is an “event” (process) to which an organizational unit [OU], will have to respond to. Is triggered by an actor, threshold or time. Can be inbound or outbound. {rule} The BE must be executable in one step, one time zone. Examples: customer places an order, customer files a complaint, airplane scheduled to leave terminal @time, purchasing order submitted when minimum stock quantity is exceeded. Business process A number of (business) events which are processed in a predefined sequence. In theory “predefined” is optional. Business rule Logic to control explicit operations such as workflow, presentation logic, merging data with (email, calendar, to spreadsheets) and much more. Each rule has two parts: left-hand side (LHS) and right-hand side (RHS). The LHS are the pre-condition(s) that must be met in order for the rule to fire and execute its RHS. This is if-then logic. One rule RHS can then be the pre-condition for another rule's LHS, which causes rules to "chain". This is a very powerful method of breaking down complex logic in re-usable execution parts. Workflow A number of (business) events (the “what”) which are processed in a predefined sequence at a given time (“when”) by a person or system (“who”). Simply put: Who does What When Dialog A dialog is the user-interface representation of a business event; Case ID Each business process contains a set of events that are linked together. The unifying key is the case ID User & group Users are the persons, defined by their email address, that can access the application. Groups are a collection of users that have a common “authority” to execute business events. Users can be members of (at least) one or more user groups; Work queue Queues contain outstanding work items [OWI]. There are two types of work queues: user and group queues. User queue belongs to a user and he/she is the only one having access to it. Group queue is accessible by each user that is a member of the group Work item Outstanding work items [OWI are put in work queues. These are dialogs that must be processed by the users of the application; Concept A class of objects, for example order, car, contract and so on; Attribute Describes a property of a concept, for example (order) value, (car) production_date, (contract) issue_date ….; Concept/Attribute Pair Each business event is made-up of a set of concept/attribute pairs, for example the “new order” [event] has the following structure:  Order amount (order =concept, amount =attribute);
  9. 9. Harmony concepts and design Guide.doc Page 9 Harmony concepts and design guide  Order date;  Customer name Pair Type Each concept/attribute pair has a type, for example the order date type is date (or dateTime). A drop-down is represented by the multiple-choice type and so on Dialog Item Same as a concept/attribute pair, but part of a dialog Orchestration Orchestration defines the sequence of steps within a process, including conditions and exceptions Choreography Provides a different approach that is gaining acceptance in scenarios that have complex processes with many interacting parts, and event-based and agent-based systems. In a choreography approach, rules are created that determine the behavior of each individual participant in the process. The overall behavior of the process emerges based on the interaction of the individual pieces, each autonomously following their own rules. If you’re familiar with the work going on with Complex Event Processing (CEP), you will see the similarity in the problem space of CEP and a choreography approach, i.e. how can you manage the interaction of multiple, independent events (or participants) to yield an overall, predictable business result
  10. 10. Harmony concepts and design Guide.doc Page 10 Harmony concepts and design guide Introduction This concepts and design guide provides future users of Harmony an overview on how to get started, design principles and how to implement complex logic using expressions. Harmony applications can be created in two ways: (1) Create a flowchart, using LucidChart, and generate the Harmony application (2) Use a blank Harmony workbook, with pre-defined sheets and create an application from scratch The preferred approach depends on Harmony experience and complexity of the system that needs to be developed. We recommend having a high level diagram, which improves oversight for the system to be developed. We’ll start the 1st introduction to Harmony by using a flowchart diagram for illustration purposes.
  11. 11. Harmony concepts and design Guide.doc Page 11 Harmony concepts and design guide Creating applications: using a flowchart to explain Harmony Most people understand flowcharts – so demonstrating Harmony’s modeling concept can best be illustrated using the “traditional” flowchart graphical model, as is illustrated in a sample below: Figure 1 Typical flowchart processes, decisions, data and groups (swim lanes) A “typical” flowcharted (process, decision, database, groups [users]) From the above we distill that most flowcharts contain: 1. multiple processes1; with a. input(s) b. output(s) 2. decision(s) 3. files / database(s) / table(s) 4. users / groups (re-presented by swim lanes) The ‘typical’ flowchart in Harmony terms Harmony uses pre-formatted spreadsheets which lead to the generation of powerful2 business applications. The whole configuration is stored in a Google Spreadsheet that provides a familiar "Excel"-like user-interface with collaboration as its primary goal. Flowchart symbols “mapped” to Harmony concepts Flowchart/BPMN symbol Harmony re-presentation Process Dialog (represents an “event”) Database/table REF_ sheets; each sheet contains one table Decision (diamond) Rules: decisions are business logic Swim lane (BPMN) Groups (represented as “Queues” on user interface) Email Email template – controlled by one/more rules Dataflow / arrow n.a. (this is automatic in Harmony) Figure 2 High-level overview of mapping "flowchart symbols" to Harmony 1 an one-step process is not a business process 2 Powerful as in fast (immediate response), scalable (supporting thousands of users), secure and more …
  12. 12. Harmony concepts and design Guide.doc Page 12 Harmony concepts and design guide Harmony provides many more functions since it’s capable of creating complex business applications; more on this [creating applications] in the next chapter. Dialogs (process steps) Flowcharts use process symbol, Harmony uses Dialogs. Figure 3 Dialog definition Rules (decision) Rules control the business process (workflow) – and are simple to define, while still offering all the possibilities to define complex rules. The sample below is the Harmony implementation for a flowchart decision (the diamond symbol). The industry guideline for defining complex decisions (like a sequence of diamonds in a flowchart) is implementing decision tables – this is described in the next chapter. Figure 4 Process flow defined with Harmony Templates (email) Templates merge data with email and Google Calendar. Template generation is controlled by rules as well. Figure 5 Templates definitions for eMail and Calendar Authorization (groups and users) Multiple levels of authorization exist: group and user level permissions, business events authorization and case access. The standard authorization is assigning users to groups – groups are assigned in rules. Figure 6 Groups (swim lanes) Figure 7 User authorization
  13. 13. Harmony concepts and design Guide.doc Page 13 Harmony concepts and design guide Reference data (database / table) Reference data is defined in the workbook as a “REF_ sheet”; it provides a viable, easy option of defining new data. Harmony, internally, stores data in a proper database (PostgreSQL or DB2 for i). Figure 8 Sample of a table
  14. 14. Harmony concepts and design Guide.doc Page 14 Harmony concepts and design guide Introducing decision tables There are many aspects to consider when comparing modern with traditional applications – such as workflows, integrated case management, verb-syntax data relations (versus graphical data modeling) and but not least: decision tables. In this paragraph we elaborate on the power of decision tables: 1. Modeling complex logic in flowcharts (or BPMN models) is cumbersome, hard to define – even harder to validate. Some systems involve many operations/decisions to produce one or more outcomes. Even simple decision tables can be cumbersome to model/present in flowcharts or BPMN; consider the sample below (see Figure 9 below “determine treatment level – payment overdue”). It gets even more complex when a new value range (like platinum [customer profile]) is to be added. 2. Traditional application development requires storing decision table data in database tables and the logic to access this either in stored procedures or (complex) code. Capture complex logic: Decision Tables (DTs) One of the most outstanding Harmony capabilities is defining business logic using decision tables (DTs). A Decision Table is a pre-defined abstract format that is technology-independent; it has been used since the existence of spreadsheets, particularly by business analysts – long before there was technology capable to implement it. At this time of writing Harmony is the only available solution supporting the implementation of DTs without writing one single line of code, with no compromise on performance or scalability. Any MS- Excel or Google spreadsheet with the correct structure can be copied & pasted into a Harmony configuration. To effectively ensure that the DT produces outcomes it is obviously necessary to have matching input parameters in the Harmony configuration. A good option for testing is creating a dialog with matching input parameters – after which the application is ready. Check the Decision pages on our website. DMN – Decision Modeling Notation – the OMG standard The purpose of DMN is to provide the constructs that are needed to model decisions, so that organizational decision-making can be depicted in diagrams, accurately defined by business analysts, and be automated. The “standard” decision table A decision table uses conditions to set a certain value [to an attribute]. Both input & output (outcome) are c/a pairs. In the sample below the input parameters are customer profile [cell A2] and percentage overdue [cell B1]. The output is treatment level [cell A1]. Example: A customer profile “silver” and percentage overdue of “3” returns a treatment level of “medium” Figure 9 Standard decision table “determine treatment level – payment overdue”
  15. 15. Harmony concepts and design Guide.doc Page 15 Harmony concepts and design guide A “multi dimensional” decision table (MDT) … A MDT is a DT that provides one or more outcomes for a multitude of input parameters (in this case columns A till D). Figure 10 multi-dimensional decision table Other than with a standartd DT, the output (outcome) is a c/a pair where the concept is defined by the MDT sheet name. using the sample above, if the MDT name is PaymentPolicies the outcomes would be PaymentPolicies.policy, PaymentPolicies.SaleAllowed, etc…. Rules and logic in “rules” (versus in Decision Tables) Decision rules can also be defined without using DTs – some examples 1. (if payment overdue > 90 [days] AND total savings is between €1,000 and €3,000 set customer risk level to “medium” [the output] 2. Raise a purchase order [the output] if stock level < threshold stock (minimum stock level). Sample 1 will most likely fit better in a DT – since multiple parameter values are involved, describing these in rules requires entries for each output. Sample 2’s implementation seems to be a plausible one – give the fact that this is single dimension rule … applicable to all entries in the same catalog/product file using the artifact (article).
  16. 16. Harmony concepts and design Guide.doc Page 16 Harmony concepts and design guide Overview of Harmony “configuration” options Little is needed to define a business process / workflow – in Harmony terms “configuring. Below is the list of spreadsheets features. The complete list of Harmony features … the structure, contents of the workbook Harmony function [spreadsheet] name Remarks Rules / business logic Rules Dialogs / user interface Dialogs Files / tables REF_@name Each table is separate sheet Decision Table (DT) DT_@name concept attribute names are in/output Multi dimensional Decision Table MDT_@name Groups Groups Users Users Menu (process) authorization Event_Authorization Matrix of dialogs and groups Templates Templates For email / calendar / .doc Initial values & overrides FactDefinitions Application Configuration Config show rule ID, colors, instance .. Supported “in-config” Support List of operations, item types Language settings (decision support) Language_@id Translations … per language a sheet (@id=nl, en, fr) Logging settings AuditLog Specifies what is logged Special functions (Building blocks) Multi line order entry CustomItem_OrderMatrix Generates order entry Relationship kernel definitions RK_Model “data model” contains relationship definitions Relationship kernel store RK_Store Contains the relationships between real objects Figure 11 Overview Harmony.sheets (spreadsheets)
  17. 17. Harmony concepts and design Guide.doc Page 17 Harmony concepts and design guide The HARMONY UI (user interface) - web-parts The Harmony UI is made-up of web-parts, where each web-part provides one distinct function and runs independent from the other [parts]. Figure 12 Harmony UI - standard web parts Harmony Web parts Outstanding work displays the work to be done by groups or individual users Business events displays all tasks (sometimes called “menu items”) which can be started by a user – such is, dependent upon authorization [settings] Dialogs ” performs the actual processing (it’s the representation of the event, or dialog) and performs complete input validation such as valid e-mail, telephone numbers and other data formats History provides a view over what has been done, when by whom. The details of the history contain the data that has been entered or referenced Decision Support Shows what will happen next – it displays what will be done once the “dialog” is submitted Case data displays all data which is part of the case. Harmony displays the data value and the rule (or expression) that created the data. When the case data contains order value = 10,000 then the link to the expression is order quantity * product price Harmony menu bar Search Search for case data Reference objects For authorized users … shows a list of all the reference files Your Groups Displays to which groups the user belongs Figure 13 Harmony web parts overview (User Interface)
  18. 18. Harmony concepts and design Guide.doc Page 18 Harmony concepts and design guide The sample case– tourism on-line booking We’ll be using an example known to most of us – supporting the online booking of an accommodation (cottage/bungalow) in a park. We’ll be using an extract of the ‘Tourism book an accommodation’ process - which is actually an existing Harmony solution. Background - some of the characteristics of the sample case 1. The provider has parks in a number of European countries 2. Bungalow types vary per park (as well as list price) for example …. An “EDEN” type bungalow might not exist in certain parks 3. On pricing: a. Pricing levels3 are country dependent – each country applies a mark-up b. Discounting the booking price are: i. early booking (the earlier the booking is made – the more %), ii. loyalty (frequent/returning customer), iii. “specials” – such as 55+ and family discount. 4. People staying at a park might be required to provide additional identification (ID) –such imposed by EU regulations (the “Schengen4” treaty) … a. UK travelers to France qualify for providing an ID b. Dutch travelers to France do not 5. Child details are required – depending on the age of the child 6. The Product Availability Catalog is maintained in the cloud; the [booking] transactions with the legacy reservation system are implemented using an ESB. The “user’s [UI] behavior” The “standard process steps” involve search, decide to proceed based on search results – enter [stay] details, check for loyalty, prompt for booker details and the actual [booking] confirmation. 3 consider this: pricing could be different at accommodation level “EDEN” list price €100/night in an UK park - €120/night in France 4 http://en.wikipedia.org/wiki/Schengen_Agreement
  19. 19. Harmony concepts and design Guide.doc Page 19 Harmony concepts and design guide Creating the business application/system: book an accommodation Applications are made up of “parts” such as workflow, user interface dialogs, presentation logic, (database) tables, expressions and groups and users (for accessing the app). This can get quite complex – so let’s start with a typical business application with medium complexity … our demo sample - an extract from the ‘Tourism book an accommodation’ process. Note that this system is accessible on our portal https://www.liquidsequence.net/ - use the Tourism instance. The tourism “book an accommodation” involves search for a park and a preference, after which the user decides to proceed by creating a quote; the stay details (select an accommodation) is the next step. When the user declines he/she is routed to the mailing list and email is sent. Figure 14 The flowchart of the tourism booking process To ‘configure’ this sample involves two workflows, three (database) tables, some decision logic and email processing. It also contains presentation logic. Flowchart symbol How to implement in Harmony Process Create 3 dialogs (each represents a “Harmony event”) Database/table Create REF_ sheets: REF_Parc, REF_Preference & REF_... Decision (diamond) 2 Rules – a “Yes” rule and a “No” rule (this is business logic) Email [create a] Email template & a rule to sent the email Dataflow / arrow n.a. (the items (name, list_price,location) should match columns on th REF_) Sample flowchart The Harmony translation Figure 15 Mapping "flowchart symbols" to Harmony Tip: concentrate on one, the primary, workflow when designing/configuring … usually this is the flow that has the “yes [positive] decision outcomes. Complete this flow before starting on secondary flows! Tip 2: The pre-condition for the Stay details step is that the user has indicated that he/she is interested in a quote… in order to create flexible systems use conditions based on a value (versus if step 1 exists start step 2) The 1st step requires implementing / creating dialogs .. which are the equivalent of processes (workflow steps)
  20. 20. Harmony concepts and design Guide.doc Page 20 Harmony concepts and design guide Creating dialogs (workflow steps) Figure 16 Creating the search destination dialog (User Interface) Dialogs contain items, also known as fields or c/a pairs, are created by specifying the items (column B). For each item (column C) specify the type (text, number, location etc). From the flowchart we know that Parc and Preference data are stored in [database] tables – thus it is necessary to create REF_ sheets …. In the ‘search destination’ dialog we find items linking to the Parc table, these are name, list_price, location and description. Data is automatically mapped – provided the dialog items match the Table attributes. The table data for REF_Parc: Figure 17 Creating the REF_Parc table (database) Repeat this process to create the other tables (note that these steps are not documented; do this yourself, which is fairly easy to do using the above sample). Rule: the 1st column [name] is the key and Harmony requires the key to be unique. Adding the “Stay details’ dialog to the workflow Next, the “Stay details’ dialog has to be created; this workflow step is divided into two paragraphs – for now we’ll focus on the dialog presentation i.e. the configuring the dialog. Then we’ll define the workflow Further on in this reference guide we’ll add “complex” logic
  21. 21. Harmony concepts and design Guide.doc Page 21 Harmony concepts and design guide Figure 18 Generated user interface [dialog] “Stay details” Figure 19 Dialog configuration for Stay details Accommodation name and description are stored in a table – a REF_Accommodation has to be created Based on this input (accommodation, date and stay length) and with the prior selected parc, a key will have to be composed to retrieve price and available quantity. Creating the sequence, aka process flow / workflow using rules (use the sheet in Figure 20 Rules controlling the workflow below) Rules are defined using a 1. condition, in a format which is called LHS: Left Hand Side using columns C & D 2. an operation [column E], often matching a value [F] 3. the action, what needs to be executed [G and H] 4. the group, or queue, that can execute the action [J] Next we have to ensure the Stay details [dialog #2] is displayed after the Search destination [dialog #1]. The answer to the “create quotation” decision controls this … In the rules.sheet this is defined as follows: Figure 20 Rules controlling the workflow Rid (Rule ID) 5 actually executes two steps …. On row 5 it defines that outstanding dialogs are “withdrawn” – essentially stopping the ability to execute open work items. Note that the “Queue” identifies which group can access the step … in this case the “internet user” is to ’group’ that has access to the dialog. Tip: condition workflow steps through variables (see the sample above); instead of using when [dialog] “A” exists then do [dialog] “B“!
  22. 22. Harmony concepts and design Guide.doc Page 22 Harmony concepts and design guide Tip: condition workflow steps through variables (see the sample above); instead of using when [dialog] “A” exists then do [dialog] “B“! Defining presentation logic Presentation logic controls the User Interface (UI) interaction, in terms of rules definition, this is similar to the workflow pattern; presentation logic is used to condition which items (fields, c/a pairs) are to be displayed. The Mailing list [dialog] contains presentation logic. Figure 21 Presentation logic - dialog items hidden Figure 22 Presentation logic - the dialog items are visible This dialog, by default, shows 2 [dialog] items, because the value for “would you ….” = no Note the c/a pair “opt in” triggers initially hidden items to be displayed (see Figure 24 ) Change the “opt in” value to yes and Harmony inserts three items after the “opt in” and the <submit> button. Implement this by hiding the items (column H) Figure 23 Presentation logic - hiding dialog items (dialog.sheet) Add logic to show the items when the opt in = yes Figure 24 same - showing dialog items (rules.sheet) Configuring email (and provide access to Customer profile) When the user decides to register for the mailing process and email will be sent for confirmation. Below is the preview, the rules for sending the email and providing access to his/hers customer profile.
  23. 23. Harmony concepts and design Guide.doc Page 23 Harmony concepts and design guide Figure 25 Previewing the email – note Dutch UI implementation Figure 26 Configure sending email & access to profile Figure 27 Customer profile accessible to user The email template is defined in the template.sheet Figure 28 Email template "mailing list” – the template contains access to the “customer profile” Figure 29email as delivered in InBox
  24. 24. Harmony concepts and design Guide.doc Page 24 Harmony concepts and design guide Adding complexity – “Stay details’ dialog The “Stay details’ dialog has already been created (see Figure 18 ); next we’ll add the logic to retrieve price. Using accommodation type, arrival date and stay length a price will be displayed. In tourism pricing mechanisms are very variable – being influenced by country of residence (of the booker), date/holidays, availability and popularity. We’ll implement a European standard (XFT) for the availability file. Creating the REF_Availability and a unique ID ( key) – to retrieve price & quantity The REF_Availability contains price and available quantity, its key is made up of  Parc ID (Column B),  accommodation ID (C),  date (H)  stay length (D) This results in the file layout below. Figure 30 Layout of the REF_Availability table The availability ID key (Column A) needs to be created in order to access the file. For this we’ll use an expression. This is all we have to do. Harmony will automatically retrieve the record (the price and quantity) once all the data in the expression exists. Figure 31 expression to create the key for accessing the Availability file Expression #90 creates a key by using: 1. the Parc.key; A Parc name was selected by the user in the first dialog (see Figure 16); associated with the Parc name is the Parc ID (see Figure 17) 2. Availability.idkey is the outcome of a decision table (which maps Accommodation.name and Parc.key) 3. the arrival date, with date format (input by user) 4. the stay length (input by user) Now let’s check how this works out in practice … When we execute the workflow the result is:
  25. 25. Harmony concepts and design Guide.doc Page 25 Harmony concepts and design guide Figure 32 executing "Stay details" – availability.ID retrieves price The key is generated when the Eden VIP, 02-05-2014 and 3 values are know (the Parc.key has been retrieved in the 1st dialog) Sensor processing You’ll notice from the “Decision Support” web part that many results are displayed; due to the fact that expressions were “fired” or “activated” once the price and date became available: 1. the early booking % was set to 0 because the arrival date (02-05-2014) was entered 2. this in turn prompted the early booking discount [amount] to become available 3. which then led to calculated the booking price All the above is the result of sensors or implicit processing by Harmony … no logic needs to be created to execute operations; instead when sufficient data to execute an event becomes available (even a calculation is an event), the event will “fire” (be “executed”). Accessing multiple records, the “is” operation. Loyalty (friend’s) discount sample Loyalty programs give discounts for returning customers – as this is with the sample case. But how to apply a discount when the business policy sees friends as returning customers? Some business logic: 1. When making a booking the bookers personal data is stored in the REF_Customer, with customer.email as unique key, and a booking count [field] containing the total of all stays. 2. When the booking count is less than 3 [stays] …. ask “do you have a friend who is a frequent visitor (i.e. more or equal than 3)”. If the answer is “yes”
  26. 26. Harmony concepts and design Guide.doc Page 26 Harmony concepts and design guide a. prompt for friends.email – to be used to check the customer file … Figure 33 Checking a file using a different key ... The "is" function
  27. 27. Harmony concepts and design Guide.doc Page 27 Harmony concepts and design guide Modeling data: the relationship kernel Instead of graphically modeling data, Harmony uses easy to understand data relationships, thus fulfilling our requirement of “schema less” design & creation of business applications – see sample below … Figure 34 Traditional data model Figure 35 “Schema less” design: the Harmony datamodel With release 3.0 Harmony provides full Relationship Kernel (RK) functions • RK builds on top of reference objects; • It allows to store/retrieve relationships between reference objects; Remember a reference object in Harmony always has a unique identifier; it’s the first column in any REF_ sheet Figure 36 Defining relationships - the RK model The reverse relation is for readability purposes only Figure 37 the actual data (RK Store) Each value is a reference object key, such as person.id, address.id and so on In the screenshot you see that John and Mary have signed the same contract EN456, which is for a product ENOF1189 RK is a TripleStore implementation, triples are composed of subject-predicate-object, like “Mary is married to John” (see http://en.wikipedia.org/wiki/Triplestore) . A note for IT experts … to simplify, only physically observable entities are modeled – OO developers have historically been hampered when “inventing” abstractions, because all the information had to go into a relational database with tables and foreign keys…
  28. 28. Harmony concepts and design Guide.doc Page 28 Harmony concepts and design guide Implementing Relation Kernel – Fraud detection We’ll be using a bank’s fraud detection process to demonstrate how to implement complex logic; we’ll demonstrate this with two computations a. Geo location - time between ATM withdrawals considering the distance between ATMs b. Transaction amount > 80% of the average in the last 3 minutes for a Card Swipe [transaction] Figure 38 Bank object model (graphical representation) Figure 39 Bank object model (Harmony implementation) The model is implemented in the RK_Model sheet which defines the relationships What’s needed to create this system? 1. Create a dialog, emulating the cash withdrawal from an ATM, in an operational environment this data will come from the bank’s transaction processing platform. 2. Create a dialog emulating the card swipe (for matter of readbility we use two different dialogs) 3. Create files: a. “master data” for ATM, Debit card, Bank, b. Transactional data for Person and Transactions c. Create the relationship model i. Link transactions to card owner (by creating the relationship) 4. A decision table 5. Expressions Figure 40 ATM withdrawal dialog Figure 41 ATM master file - with geo coordinates Figure 42 ATM Transaction [file]
  29. 29. Harmony concepts and design Guide.doc Page 29 Harmony concepts and design guide We won’t describe the steps to create the files for debit card, bank and person. When defining these, ensure all have the Id [attribute] in the 1st column of the REF_sheet Logic (rules) to process the ATM withdrawal & card swipe A number of actions need to defined [rules]; the logic explanation is split into 3 separate parts, increasing readability. The 1st step involves writing [ATM withdrawal) data to transaction file (see the REF_Transaction in Figure 42 defining this file) We’ll describe the processing by sheet row number 57. The transaction ID is set to an unique number using an expression 58. The cardholder’s name is retrieved from the master file REF_debitcard a. { } indicate that this is a RK expression b. The [issued_to] is defined as the relationship (see Figure 38 and Figure 39Figure 38); thus this statement reads as “give me the person name of the debit card which is issued to person” 59. The amount is set to the withdrawal amount (which is defined on the dialog) 60. The card number equals the debitcard id 61. The issues is again a RK expression (see #58 above) The statement reads as as “give me the bank name of the debit card which is issued by the bank” 62. We “timestamp” the transaction (current date contains YYYY-MM-DD HH:MM:SS) Figure 43 ATM withdrawal logic: writing data to the Transaction file The result of writing to the transaction file (REF_Transaction) Figure 44 How the data is stored in the transaction file (a Google spreadsheet) Next we have two objectives ….. I. to calculate the time between ATM withdrawals considering the distance between ATMs II. to calculate the transaction amount > 80% of the average in the last 3 minutes
  30. 30. Harmony concepts and design Guide.doc Page 30 Harmony concepts and design guide The 2nd step involves retrieving the location and time of the last transaction. With this information available compare this to location and time of the current transaction. Retrieve the id of the last transaction and use this to retrieve the time of this transaction 63. “set the last transaction c/a pair to the last transaction id for the last used time [stamp]” The max(timestamp) means that it will retrieve the most recent transaction made with the debit card - it's the one with the largest (latest) timestamp. It's a filter function 64. “set the time of the last transaction c/a pair to the to the last used time [stamp]” Figure 45 44 ATM withdrawal: computing GEO location & transaction time of last withdrawal The same is done for the latitude and longitude 65. Retrieve latitude of the last transaction using the transaction id [value] in row 63 66. Retrieve longitude of the last transaction Once these rules execute (fire) … the expressions in rows 6 and 7 will provide the outcomes (in column B). A special expression is used [distance] to calculate the distance between the ATMs. Figure 46 Expression to calculate distance and elapsed time for ATM withdrawals Once these expression outcomes (see rows 6 and 7, column B in the sample above) are known the outcome from the decision table will be known (see below cell A1). Figure 47 Decision Table providing Fraud Description outcome related to ATM locations All this is achieved automatically; no logic is required to make this happen. Harmony is 100% sensor driven, it suffices to have matching c/a pairs for rules and expressions to “fire” (execute). The 3rd and last part involves determining if the last withdrawal amount > 80% of the average in the last 3 minutes The same is done for the latitude and longitude
  31. 31. Harmony concepts and design Guide.doc Page 31 Harmony concepts and design guide 67. We set the transaction window to 3 minutes 68. The average transaction amount is calculated using the avg expression using all transactions a. from the current transaction timestamp and the “window” time frame of 3 minutes Figure 48 Calculating average transaction amount within a set time frame Creating relationships We also need to link the transactions to the ATM and the debit card. Figure 49 Creating relationships ... linking transactions to ATM and debit card The result is shown in Figure 50 Figure 50 RK_Store contains the relationships for each transaction Note that we actually implemented the scenario using two events (dialogs), in accordance with what was needed to create such a system, and with each event having a unique associated rule set (defined by the Rid (column A)
  32. 32. Harmony concepts and design Guide.doc Page 32 Harmony concepts and design guide
  33. 33. Harmony concepts and design Guide.doc Page 33 Harmony concepts and design guide Harmony UI customization (Editor’s note: this section will be revised sometime Q3 2014) In one of the previous sections (see Figure 12) the Harmony UI has been explained. In many cases there is a need to customize this UI. Since Harmony is an architected solution – as can been seen in the following diagram – UI manipulation is relatively simple. Figure 51 Harmony UI architecture / presentation tier Properly architected UIs allow the structure to be coded in HTML and/or CSS. I It is important to know that Harmony exposes a web services interface via an API and allows developers to build a custom UI. Custom UI usually is needed when: a) the look and feel required is not what Harmony provides out-of-the-box; b) functionality from Harmony must be integrated in another application – think of website forms (we call it custom "webparts", some call it "portlets" and so on). Usually both a) and b) are valid. Consider there’s a graphical designer working on the web design - the look and feel. A web developer would be working on the web site, customizing (styling) input fields – such as the text box for the "Message body" on a contact form. The PHP library Usually, when integrating with other applications, is that only the API and documentation is provided; web developers are left on your own, deciding how to integrate... Some applications provide a library suited for programming language of web developer’s choice (like Java library for Google Docs, or PHP, Java and .NET for Salesforce.com). Harmony provides such a library for PHP. With respect to the validations, these must be styled – such in the case of validation errors at the top of the form and also display a "*" next to each wrong item. This also depends on the custom graphical look and feel of the web site (graphical designer). Harmony ensures that CSS classes are presented - which can then be used to style in any shape or form. The PHP library generates, for the validations, a "required" CSS class that tells web developers that an item is mandatory. The only thing web developers need to do is develop the CSS file according to the web site design and style the validation errors accordingly. Bottom line is, Harmony won't include the form validations in the PHP library, because we will take out the possibility for developers to style with a CSS. This is presentation logic and look and feel issue. The PHP library is meant to address the integration issue with the API instead, leaving the styling (with CSS) to the web developers.
  34. 34. Harmony concepts and design Guide.doc Page 34 Harmony concepts and design guide Tech talk (Editor’s note: this section will be revised sometime Q3 2014) Harmony is a solution using industry solutions by design like: 1. OpenAjax - an open AJAX standard (for a browser) based event messaging bus; 2. Twitter's Bootstrap - An HTML(5) Mobile Application (http://getbootstrap.com/ / for developing responsive, mobile first projects on the web. 3. Developed in Erlang (Ericsson Language), a functional programming language used to build massively scalable soft real-time systems with requirements on high availability and scalability and Java (de-facto standard for industry scale enterprise applications). HARMONY runs on industry standard Wintel/Unix/Linux operating systems and hardware. It offers seamless support of all major database servers and is certified to be deployed in the cloud on Amazon Web Services (AWS), Google Compute Engine, Linode and many other cloud computing platforms. This whitepaper uses the concept of event driven applications, using an (UI) orchestration suite that ‘consumes’ web services. For this we use the "Harmony Orchestration Suite"; a rules driven UI and application flow suite incorporating smart web-parts5, business rules, decision support and application integration. About orchestration and choreography Unlike many other tools, Harmony does not distinguish between orchestration and choreography, it is all event based and a sequence of events can be workflowed and workflows can be run as dialogs given certain conditions. 5 HTML5 [web]PARTS
  35. 35. Harmony concepts and design Guide.doc Page 35 Harmony concepts and design guide HARMONY mobile web parts (Editor’s note: this section will be revised sometime Q3 2014) Every application built with HARMONY automatically becomes a web-enabled mobile application. Web- parts are automatically generated for iOS (iPhone), Android and BlackBerry. If the product stock level falls below the minimum stock level the supplier automatically receives a notification. The same web-part that runs in the application is “raised” on the mobile asking the supplier to confirm delivery of this purchase order. All rules and logic, including workflow, are applicable to the mobile phone app. Mobile web parts are generated “out-of-the-box”. HARMONY, when deployed in the cloud, offers full online capabilities for mobile phones. The mobile web parts thus offers seamless network support, whether users are online with their PC or online with their mobile phone, the application is always online. Web parts, both standard and user generated, are converted into mobile web parts. All the functionality and all supporting data, which is available as standard web parts in a standard [PC based] browser, is available for mobile phones, thus the workflow is extended to any [geo] location. Figure 52 Mobile web parts Features HARMONY main function is to facilitate application development; it generates standard UI web-parts, it integrates and it provides a plug-in model to integrate with external web-parts. Thus a new application can be developed in a number of days, not weeks. The external web-parts can link to AS400, .NET or JAVA programs. Basically anything that has been developed in HTML(5)+ CSS can be integrated. This mix and match application development concept offers great advantages for organizations migrating or converting old applications to a new, modern, IT environment. Integration scenarios A wholesale organization uses an AS400 for sales order processing and purchasing. These applications were developed in 1994 and the purchasing department has the requirement to improve interaction with suppliers and transport companies. Given the state of new technologies, a cloud based system is developed using HARMONY and contains AS400 web-parts, such as an order overview [web-part]. Modernizing the AS400 – integration thru web services and ESB The complete functionality of HARMONY is exposed as web services. HARMONY also integrates seamlessly with an enterprise service bus (ESB) via JMS (IBM WebSphere, Mule or AMQP (RabbitMQ).
  36. 36. Harmony concepts and design Guide.doc Page 36 Harmony concepts and design guide HARMONY provides an out-of-the-box Mule 3.2 ESB connector for iSeries, so any AS400 application can be exposed as a web service via the ESB. An order is created using the RPG sales order program, which puts a message on an AS400 data queue. The ESB connector picks up the order from the data queue and publishes it to the ESB. The ESB then notifies HARMONY that a new sales order was created. The purchasing process is started by checking minimum stock level.
  37. 37. Harmony concepts and design Guide.doc Page 37 Harmony concepts and design guide Some of the technical design concepts that are applied in Harmony (Editor’s note: this section will be revised sometime Q3 2014) Harmony is “not-just-another-product or framework; instead it is the result of many years of pioneering workflows and business process areas and developing IT solutions using these concepts. Starting in the early 90’s, when there were static workflows and IT environments were “closed” till 2010 when technologies (“open source”) and platforms (“cloud”) became reality. Google is setting the standard for extremely scalable technologies. Complex Event Processing (CEP) Figure 53 CEP context The concept of business event modeling dates back to late 80’s, early 90’s – providing a solution for processing modeling with a clear focus on solving business issues. Harmony is based on complex event processing where every (possible) action is a trigger, which will lead to events to be fired. As such the workflow of an applications can be seen as a collection of events that are triggered by an action. The OpenAjax UI event bus Harmony uses PageBus, an OpenAjax event bus implementation. PageBus is an event bus implemented in JavaScript that enables web-parts and other Ajax components in a Web page to broadcast and listen for messages published on topic names (it's a messaging bus in the browser). Figure 54 webpage "template" for OpenAjax Rule (logic) based, decision tables – the RETE algorithm Harmony’s goal is to establish a solid rule based platform without the complexity that comes with many technologies and/or products. The rule engine is based on the RETE algorithm - decision tables and decision support are based on it. A modular approach is implemented, where each rule is a separate unit. This makes adding, editing or removing rules easy. Thus providing great flexibility to a generated & workflow based application. Rule uniformity is applied; the same format is used for representing all of the logic/knowledge in the system: Figure 55 The more data becomes "known" the more predictive info becomes available
  38. 38. Harmony concepts and design Guide.doc Page 38 Harmony concepts and design guide Authentication (Editor’s note: this section will be revised sometime Q3 2014) It is based on the OpenID standard which is also implemented by Google, Yahoo and AOL. . Harmony supports Facebook, LinkedIn and Twitter authentication protocols as well, so users of those applications can login seamlessly. Figure 56 Implemented authentication mechanisms
  39. 39. Harmony concepts and design Guide.doc Page 39 Harmony concepts and design guide Quality assurance standards All of HARMONY’s functionality is tested with Selenium IDE. This guarantees the complete test coverage of its features. The performance and scalability is tested with OpenSTA. All test cases are Google spreadsheet driven. Every (major) release is tested on Linux, Windows and iOS and the following browsers: Google Chrome, Mozilla Firefox, MS IE and Safari for Mac and iOS.
  40. 40. Harmony concepts and design Guide.doc Page 40 Harmony concepts and design guide Positioning Harmony in the Gartner Magic Quadrant Business processes on the right side of Figure 1 undergo frequent or unexpected (ad hoc) change. Efficiency, cost reductions and transparency, although important goals, are surpassed by the overarching goal business agility, which results in build-to-change solutions. In these situations, the process and IT solutions change may be prompted by internal and external business triggers, or perhaps the to-be process is not yet perfectly clear. The best way to address this is through “evolutionary” implementation. Change the processes as more insights are gained. Harmony’s foundation is adaptive case management – which is a must have for agile processes. Business professionals, with some help of IT specialists, can collaborate in a highly agile and iterative fashion to approximate the optimal process. Figure 57 Gartner magic quadrant BPM tooling showing Harmony’s position

×