harmony concepts and design guide v0.2

Harmony concepts and design Guide.doc

Harmony concepts and design guide

Harmony

Concepts & Design Reference guide version 0:22 / 9 sept 2014



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



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



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



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



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



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.



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);



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



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.



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 …



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



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



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”

http://liquidsequence.com/Decision-Table-samples.html

http://liquidsequence.com/Decision-Table-samples.html



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).



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)



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)



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



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)

https://www.liquidsequence.net/

https://www.lucidchart.com/publicSegments/view/5356387e-e354-4a47-8dda-67cb0a005377/image.png

https://www.lucidchart.com/publicSegments/view/53563476-a98c-4f44-9f07-64340a00dcad/image.png



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 1

st 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



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“!



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.



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



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:



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”



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



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…

http://en.wikipedia.org/wiki/Triplestore



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]



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



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



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)



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.



Tech talk


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

http://www.sencha.com/products/touch/



HARMONY mobile web parts


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).



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.



Some of the technical design concepts that are applied in Harmony


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



Authentication


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



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.



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

harmony concepts and design guide v0.2

Software