Harmony concepts and design guide v0.2

Harmony concepts and design Guide.doc Page 1
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”

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)

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

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…

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

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

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (13)

Ähnlich wie Harmony concepts and design guide v0.2

Ähnlich wie Harmony concepts and design guide v0.2 (20)

Mehr von 112Motion

Mehr von 112Motion (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Harmony concepts and design guide v0.2