ClaySys Technologies Introduction - White Paper - Feb 2011.pdf

www.claysys.com Page 1 of 35

ClaySys Technologies Pvt Ltd, Ground Floor, Athulya, InfoPark SEZ,

Kochi, Kerala, INDIA – 682030

ClaySys Introduction

White Paper




ClaySys Technologies Introduction – White Paper

1. Executive Summary ..................................................................... 3

2. Technology Architecture ............................................................. 4

3. Functional Architecture ............................................................... 4 3.1. User Interface ................................................................................................................. 5 3.2. Business Logic ................................................................................................................. 5 3.3. BPM (Business Process Management and Workflow) ............................................................. 6 3.4. Reporting and BI (Business Intelligence) ............................................................................. 7 3.5. Security (Authentication, Authorization & Auditing) .............................................................. 7

4. Product Overview ......................................................................... 8 4.1. ClaySys Central Administration .......................................................................................... 8

4.1.1. Multi-Tenant Architecture ............................................................................................ 8 4.1.2. Tenant Management Console ....................................................................................... 9 4.1.3. Forms Designer Module ............................................................................................. 10 4.1.4. Forms Designer – Datasource Configuration ................................................................. 13 4.1.1. Forms Designer – Rules Editor .................................................................................... 18

5. Business Logic Examples ......................................................... 22 5.1. Business Logic Examples - Summary ................................................................................. 22 5.1. ClaySys – End User Interface ........................................................................................... 24

5.1.1. Example 1 – Populate State Name .............................................................................. 25 5.1.2. Example 2 – Credit Card Check................................................................................... 26 5.1.3. Example 3 – Date Functions ....................................................................................... 29 5.1.4. Example 4 – String Functions ..................................................................................... 30 5.1.5. Example 5 – Numeric Functions .................................................................................. 33

6. Conclusion .................................................................................. 35




1. Executive Summary In today’s business environment, most business applications are too rigid and inflexible and are unable to

keep pace with the business functions that they support. The business applications that exist today force

people to execute their tasks and processes by working with different silos of information and application

functions. End Users have to align their physical processes and activities around how they can be supported

by the existing business applications.

One of the biggest challenges facing IT Decision Makers over the next few years is how to have their

Enterprise Software and Business Applications adapt to rapidly changing business processes and functions.

Forrester Research in their report "The New IT Imperative: Design For People, Build For Change" calls this

new generation of enterprise software capabilities, Dynamic Business Applications, with an emphasis on an

applications close alignment with business processes and work, whereby they are designed for people, and

an applications ability to adapt to business change, whereby they are built and architected to support changes

frequently and feasibly.

Forrester Research continues to say in this report “The Dynamic Business Applications Imperative“ that Most

business applications are too inflexible to keep pace with the businesses they support. Today's applications

force people to figure out how to map isolated pools of information and functions to their tasks and processes,

and they force IT pros to spend too much budget to keep up with evolving markets, policies, regulations, and

business models. IT's primary goal during the next five years should be to invent a new generation of

enterprise software that adapts to the business and its work and evolves with it.

The ClaySys Product Suite is a comprehensive Business Application Platform that enables IT and the

Business to very rapidly develop custom or integrated Business Applications through just Configuration, as

against Customization through custom code. The Business Requirements can now be very feasibly translated

into a working Business Application, and ongoing rapid changes required of the Business Application, both

from a Data Management and Business Logic perspective, are also addressed with the same ease and speed

taken to create the application.

From an architectural standpoint, ClaySys is a ‘Metadata’ driven application platform, where all the User

Interface design as well as the Business Logic and Data Management are ‘Metadata’ driven, requiring no

custom coding. So incorporating any changes to a applications functionality are simply changes made to the

‘Metadata’ which are immediately reflected within the application.

The ClaySys solution runs within a web browser and requires just the Microsoft Silverlight addin to be

installed within the browser, which enables support for RIA (Rich Internet Application) capabilities.

The ClaySys suite also supports built in capabilities for complex BPM and Workflow automation, as well as

Enterprise Security and Access control to ensure that any application created using the platform is of

Industrial Strength and Enterprise Scale.

The rest of this whitepaper presents the ClaySys Suites capabilities and core features, to support the

‘Dynamic Business Application’ capability envisioned by Forrester Research and others.

http://www.forrester.com/rb/Research/new_it_imperative_design_for_people%2C_build/q/id/43249/t/2?src=41397pdf

http://www.forrester.com/rb/Research/dynamic_business_applications_imperative/q/id/41397/t/2




2. Technology Architecture The ClaySys Product Suite has been developed in Microsoft Visual Studio 2010, and runs on the Windows

Server stack. The ‘Metadata’ managed by the product to store all the configuration data for any application

created using the platform, is managed in MS SQL Server 2008.

While it supports MS SQL Server by default, ClaySys can still work with any ODBC compliant Database such

as Oracle or DB2, for managing the data of any Business Application created using the tool.

ClaySys can also work with other Datasources such as Web Services, SharePoint 2007 or SP2010, or any

XML end point, to manage all the data or elements of data to be integrated with any business application.

The End User Interface of the ClaySys Platform is rendered in MS Silverlight 4.0, and is a dynamically

rendered UI using XAML.

ClaySys manages its authentication by supporting Windows Authentication through Active Directory by

default, as well as through maintaining its own Membership Provider in SQL Server to support Non-Active

Directory environments. This ensures single sign-on in all Active Directory Environments. The Authorization is

managed by a comprehensive security module that enables controlling access to individual ClaySys

Applications, Modules, Forms, Fields and Data, for the Users and Groups that are provided access to any

ClaySys app or apps.

The ClaySys Application Server runs on Windows Server and requires the .NET Framework 3.5 and above.

The ClaySys Platforms supports Multi-Tenancy for all its functions, and every application configured using the

platform is identified by a unique Tenant-ID. This ensures that ClaySys can support multiple logically separate

and unique applications on the same ClaySys Server, and theoretically sharing the same ClaySys Database,

as every Database record is partitioned by the ClaySys Tenant-ID.

3. Functional Architecture The ClaySys Application Platform is a paradigm shift and a potentially game changing product, with its ability

to allow IT’s ‘technical staff’ to respond to legitimate business requests exponentially faster, and respond to

the inevitable pipeline of ‘Change Requests’ just as fast as well. It will allow their current pared down staff to

keep up with the rising tide of application requests, without ramping up resources or resorting to local or off-

shore vendors, and in most cases will eliminate costly RFPs.

If the applications are not mission critical, IT can also empower a savvy business user to maintain some parts

if not the entire application themselves, with IT just approving the change requests, and supporting the

Production Environment. This if achieved can be a significant win for both IT and the business.

The application building process using ClaySys requires a skill set similar to what would be required for

configuring Microsoft Excel, and so is not dependent on the application support team being programming




experts. We expect the IT Infrastructure team to be able to support the platform quite feasibly, just like they do

with Windows Server environments and platforms like Microsoft SharePoint.

The ClaySys Application Platform addresses the key functional areas of a Business Application such as the

User Interface, Business Logic, BPM (Workflow), Reporting (BI) and Security, all of which can be configured

as required to meet specific feature requirements for the business application to be developed.

The following sections will provide a better understanding of the core functionality supported by the product.

3.1. User Interface

Any business application has to present its User Interface or UI to its End Users, to allow them to participate

in updating data into the application and to access information maintained by the application. ClaySys

supports the ability to define and configure any type of typical Business Application UI, with all the standard UI

controls and navigation options one would expect to support within the required business application.

The ClaySys UI configuration capability supports the ability to,

-Configure the Application Navigation Menus, so you could setup all the menus and sub-menus to

allow an End-User to navigate through an application.

-Configure very simple to very complex Data Entry Forms, to build the applications User Interface.

-Configure simple to complex Data Presentation Forms and Reports, to enable retrieving and

displaying business data appropriately to End-Users as well.

-Support for Tabbed, Nested Sub-forms and other Composite Forms, so very complex UI structures

can be created, to support typical Business Application interfaces.

-Ability to edit style sheets for branding and UI Skinning requirements. This ensures that the

Application Designer has complete control over how the application being built can look and feel for

the End Users.

3.2. Business Logic

For any business application, between accepting data entry from an End User and presenting data back to an end User through the UI, there needs to be embedded business logic that can validate all data being entered, prior to accepting it, and do the same for all data to be presented in the UI as well. A summary of the Business Logic elements supported by ClaySys are categorized below,

-Ability to configure Complex Form and Field Validation Rules. -Maintaining Application State in a Configurable Manner, so session data is retained as the User navigates between multiple forms or modules.




-Ability to set up a Hybrid of Form Validation and Server Side Business Rules, to perform complex Form validations against backend data sources. -ClaySys supports a comprehensive built in BRE (Business Rules Engine), which enables support for complex Business Logic capabilities within each of the configured Forms or Modules. -Managing a Business Applications Data in a RDBMS such as SQL Server, Oracle etc, against any Data Model or Schema maintained in the Database. - Managing a Business Applications Data through Data sources such as Web Services or SharePoint as well. -The ability to Embed Custom Coded Composite Controls and setup integrated business logic, to ensure that complex scenarios such as integrating with external technology components, e.g. a CTI (Computer Telephony Interface) as well as integration directly with other 3 rd Party Application API’s can be supported. This scenario supports writing custom code using the ClaySys SDK, and deploying such ‘Composite Controls’ into the ClaySys App Designer framework, from within which the custom controls can be embedded into forms etc.

3.3. BPM (Business Process Management and Workflow)

Most Business Applications planned or architected today, embed BPM capabilities within it. So it needs to support capabilities to route forms or documents to relevant Users based on any defined approval or review processes. Also support the ability to automatically escalate items or entities to End Users based on events in the database etc, or to simply notify End Users through Email or Mobile Text Messages on logical events occurring. Such features are comprehensively supported within the Business Application being developed, wherever found to be necessary. The core BPM capabilities supported by ClaySys are summarized below, -Support for configuring Individual Processes and their Process Steps by mapping Users and Groups to their Process Roles. -The ability to configure complex routing rules for a specific process, depending on the parameters maintained by specific Forms or Modules. -The ability to configure Escalation Rules for a process or within a process step, so End Users get notified by email or SMS when process events occur that require End User action on intervention. - The ability to Map and Route Forms or Documents to configured BPM Processes, based on the input parameters within the Forms or the Meta Data mapped to Documents and Files. - The ability to configure Email Notifications for any Process Events, such as when any item in a process requires a specific User or Groups intervention or inputs. - The ability to maintain an audit trail of all active processes, to ensure that process managers can monitor the process and intervene where necessary to make the process more efficient or to act on process exceptions etc.




3.4. Reporting and BI (Business Intelligence)

One of the key functions of any business application is to facilitate the reporting requirements based on all the data managed and maintained by the application. Most organizations require basic reporting capabilities off the OLTP data maintained by the application, while more complex BI capabilities are achieved through a Data Warehousing solution. The Reporting and BI capabilities supported by ClaySys are summarized below, -The ability to generate basic OLTP reports through End User configuration of SSRS (SQL Server Reporting Services) Reports, of the OLTP database. -The support for exporting specific subsets of the transactional data, into tools like MS Excel for analysis as required. - The ability to export the OLTP data maintained within a Business Application to a Data Warehouse feasibly. - The ability to report of any Data Source that the application is mapped to, such as Web Services, SharePoint and other XML Touchpoints to data.

3.5. Security (Authentication, Authorization & Auditing)

Once a business application has been setup in ClaySys and is ready for deployment, it is critical to be able to manage the security of the application. The security capabilities will need to address the authentication requirements as well as the authorization and auditing requirements for access control to the application. The Security and Access Control requirements addressed by ClaySys are summarized below, -Support for Authentication using Windows Active Directory for Single Sign-On and Windows Authentication support -Support Authentication using a Custom Membership Provider as well, where Active Directory may not be the preferred authentication channel. -Support comprehensive Access Control settings for the specific AD Users and Groups, to the ClaySys Application Modules, Forms, Fields and Data. -Support for Rules based Access Control to a ClaySys Applications Modules, Forms, Fields and Data. E.g. ‘John Smith’ can only access ‘Orders’ where ‘State’=New York -Maintaining an Audit trail of all Authentication and Authorization requests, to ensure comprehensive tracking and traceability, to support the most ‘Security Conscious’ application scenarios.




4. Product Overview

This section will attempt to provide an overview of the ClaySys product suite. We have presented appropriate screenshots to allow the reader to identify with how specific features and functions of the product work.

4.1. ClaySys Central Administration

This is the primary management and maintenance console for the product. All the core maintenance functions and navigation to core modules such as Security, Workflow etc are managed from this console. The screenshot below shows you how you can navigate to all the core modules from ‘Central Administration’. Being a Multi-Tenant application platform, within ClaySys you can create a logically partitioned application by simply creating a new ‘Tenant’. The system assigns a ‘Tenant-ID’ to each Tenant, after which all relevant Database records are partitioned by ‘Tenant-ID’ though most ‘Metadata’ and ‘Transactional’ Tables can be shared across multiple Tenants.

4.1.1. Multi-Tenant Architecture

The screenshot below shows a list of ‘Tenants’ created using ClaySys. Each Tenant can behave like an independent application, containing its own Modules and Forms and its own Custom Business Logic as well. Administrators can work with different Tenants from this module, and the ClaySys Security Module can restrict access for specific Administrators to only One or a Subset of Tenants that individual administrators need to have access to. Clicking on any Tenant will then take the Administrator to the Tenant Management Console, which is explained in the next section.




4.1.2. Tenant Management Console

The screenshot below shows the Tenant Management Console in ClaySys. All the Modules and Forms configured for a specific Tenant are listed here, and the Administrator can choose a specific Form or Module that they would like to work with, to either make changes or create new Modules and Forms etc. In the example below, we have right-clicked on the ‘New Contact’ Form, and from the Menu options presented, we have selected ‘Edit Form’.




4.1.3. Forms Designer Module

The screenshot below shows the ClaySys Forms Designer, which is a comprehensive Forms Design

Environment. You can simply ‘Drag and Drop’ fields and controls onto the Forms design surface to design

your own business application form. The example below shows a ‘Contact Form’.

Clicking on the ‘Standard’ menu item on the Toolbox presents a list of the typical Form Controls you would

need to add to a business application form.




The screenshot below shows how you could simply drag and drop a ‘TextBox’ onto the Form Surface, and it

shows up as an editable ‘Field’ on the form. You can then set all the attributes of this new field by editing the

field properties as shown next.

Below we have opened the ‘Properties’ panel in the Forms Designer, where you can set the new Text Fields

properties. Here we have set the font to ‘Comic Sans MS’ and the size to ‘14’ with color to #FFF42824 which

is Red etc. Note that all properties set are immediately reflected in the WYSIWYG Forms Designer.




Clicking on the ‘Preview’ button on the Forms Designer will present to the designer the ‘Preview’ of the Form

being designed, which is how the End Users would view the form just created or edited. You can see the ‘New

Contact Field’ displayed below, when previewing the form.

So far we have only shown you how you can drag and drop fields and controls onto the Forms Design surface. In the

screenshot below, we show you how you can set the ‘Datasource’ options to connect the Forms Fields to its Datasources

which can be RDBMS Table Columns, Web Service Nodes, SharePoint lists etc. You need to use the ‘Datasource’

control that you drag onto the Form to set these mappings of the Forms fields to their data sources. The ‘DSContacts’ is

the Datasource control that was dragged and dropped onto this ‘Contact’ form.




4.1.4. Forms Designer – Datasource Configuration

The screenshot below shows the Datasource options supported by ClaySys. So you could configure any

Form designed using the platform to a ‘SQL Server’ database, any external Web Service, Microsoft

SharePoint, any XML Touchpoint through a URL etc. In the example below, the form is configured to work

with a SQL Database, so we have selected ‘SQL’.

The next screenshot below shows the Datasource Wizard that is launched, which allows you to map the Form

fields to its datasource.

The first step in the Wizard lists the ‘Databases’ configured to work with this ClaySys Installation. So you need

to select one of the Databases as shown below, after which you can configure the Form to map to the Tables

and Columns of the selected SQL Database.




After selecting the Database above, the next step in the wizard as shown below prompts you to select the

‘Tables’ that you would like to work with. Note: If the Form is required to save to multiple Tables, then you

need to setup a separate Datasource control on the Form for each Table. The ClaySys Server Side library

then manages the Transaction Commit and Rollback scenarios behind the scenes.




After selecting the ‘Table’ you want to map to for this specific Datasource control, you can then setup

‘Commands’ to ‘Select’, ‘Insert’ and ‘Update’ data to the Table from the Field Values of the Form designed

using the Forms Designer module.

Below we have selected the ‘Edit’ option against the ‘Select’ command, which brings up the ‘Select’ command edit

screen below. Here you can map the Form Fields to their respective Table Columns as shown below. In the ‘Query

Criteria’ panel you just have to select the ‘Primary Key’ assigned to the Table as well.




Below is the ‘Edit’ option selected for the ‘Insert’ command, and you can see it is similar in terms of allowing

you to map the Form Fields to their respective Columns in the SQL Table. The ‘Update’ command is sim ilar to

the ‘Select’ command shown earlier.

You can also see in the screenshot below, how you can set ‘Default’ Global Variables to a field as well.

Examples of Global Variables are the ‘System Date’, ‘Logged in User’ etc, which can be set to Table Fields

based on the session information of the User submitting the Form.




When defining the Datasource, you also need to specify the ‘Primary Key’ and in the example below, we have set the

‘Contactid’ field to have an ‘AutoIncrement’ option, and we have set it to be the Primary Key as well.

You can also combine fields to create your keys as shown below. We have shown you below, the options available when

setting up the Primary Key fields.




4.1.1. Forms Designer – Rules Editor

So far we have shown you how you can design and configure any type of Form using the ClaySys platform,

and how you could map Form fields to their respective Datasources.

In this section we will show you the key component that allows you to embed the required Business Logic into

your designed forms, and that is the ‘Rules Editor’.

The Rules Editor allows you to configure a built in comprehensive ‘Rules Engine’ to embed the required

business logic into any Form or Module created using ClaySys.

You can access the Rules Editor by just clicking on the ‘Rule’ button in the Forms Designer Panel, which will

bring up the Rule Editor panel as shown below.

For any ClaySys Form, you can configure ‘n’ number of Business Rules. You can then set up ‘n’ number of

‘Triggers’ to fire the specific Business Rules when appropriate or when certain Form or Application Events

occur.

The Rules Editor also supports ‘Intellisense’ comprehensively, and it will prompt you for the list of available

‘Functions’ and Form Fields that you would like to relate a Rule to. The following sections will highlight some

samples of Business Rules that have been configured to achieve certain Business Logic requirements.




The example below shows how the ‘DSContacts’ Datasource control that was configured in the Contact Form

as shown earlier in this document, can be triggered to load a specific ‘Contacts’ data into the Contact Form,

when a ‘ContactID’ is updated. So as seen below, the Trigger is the ContactID field, after which the

DSContacts Datasource is triggered to fetch the Contact Form fields form the Database and display them

within the Contact Form.




There are a host of ‘Functions’ supported by the Rules Engine as well, which is practically almost all the

‘Functions’ supported by Silverlight 4 which manages a subset of the .NET Framework within it, as part of the

Silverlight Browser addin.

The built in Intellisense support will list out all the Functions and options available to a Rule Author, based on

the characters typed in by the author. The example below shows all the options available when you type in ‘a’

into the Rules Editor field.

Note that you can create a hierarchy of ‘Nested’ rules, which are rules within rules, by right clicking on any

existing Rule node as shown below. For any Rule you can define ‘Decision’ logic as well as ‘Action’ logic to

achieve the business logic requirements of the Business Application Form or Module.




The examples below just show the Rule Editor options that show up when you type in the first few characters of the

alphabet. So like we did ‘a’ above, you can also see the options that show up if you type in ‘b’ and ‘c’ as well.

You can also see that if you type in a text string like ‘cont’ below, the Rules Editor intellisense will display all the filtered

options available based on the Character String you typed in.

When you select a Rule Option, the Rule Editor also prompts you on how to complete entering the Rule

appropriately. So the basic Syntax prompt as shown below, acts as a guideline for a User, to help them

configure specific rules.




5. Business Logic Examples Since the ability to configure complex Business Logic through just configuration as against writing custom

code is one of the most important capabilities of the ClaySys Product, we will present some comprehensive

examples in the sections below.

This built in capability to configure complex business logic is the key differentiator of the ClaySys Platform

when compared to any other Rapid Application Builder or Forms designer tools available in the marketplace

today.

5.1. Business Logic Examples - Summary

Below you will see a sample Tenant called ‘Northwind’, where we have configured Forms to work with the

sample SQL Server Northwind Database.

The examples we will cover are summarized for this one form below.

Example 1 – Populate State Name – Load a State Name when a User Enters a ‘State Code’. Here we will

need to use the State Code to query a Master Table to select the related State Name and display it in the

State Name field.

Example 2 – Credit Card Check – Here we show you how to setup a Form, where the scenario is that you

have a ‘Checkbox’ called ‘Is Card Holder’ and if this Checkbox is selected, then display the ‘Card Code’ and

‘Card Type’ fields in the Form, which are otherwise hidden. And on entering the Card Code, validate the entry

and populate the Card Type field with the result of the validation rule.

Example 3 – Date Functions – Here we show you a simple example of working with Dates in a Form, where

if you select a ‘DOB’ (Date of Birth) Field, then to calculate and populate the ‘Age’ field.




Example 4 – String Functions – Here we show you an example of how you can work with strings within a

form, by using the Rules Editor functions. We validate the Character string typed in by the User and split the

string into several parts which are then populated into separate fields.

Example 5 – Numeric Functions – Here we show you the ability to work with any type of Numeric Functions

within a form. The example shows you how to do simple ‘Addition’, ‘Average’ etc by calculating numbers

within a Form.




5.1. ClaySys – End User Interface

Each Tenant configured using the ClaySys Tool is published on the ClaySys Application Server (Which is a

Windows Server running IIS) as a separate Web Application. So each Tenant will have its own URL, and End

Users simply need to hit each Tenants Specific URL to access that specific Tenant.

If Windows Authentication is enabled with Active Directory, then the End User will be taken straight into the

Tenant Application through single sign-on, without needing to authenticate again.

The example below shows the Northwind Tenant for the ‘admin’ User who has accessed its URL.




5.1.1. Example 1 – Populate State Name

As explained earlier, if the End User types in a State Code as shown below, the Form retrieves the related

‘State Name’ from the database. So ‘NY’ will trigger the retrieval of ‘New York’ in the State Name field on the

right.

‘FL’ will trigger the retrieval of ‘Florida’ in the State Name field on the right etc.

Below is the corresponding Rule setup using the Rule Editor for the ‘StateCode’ field on the form. You can see how the

‘txtStateCode’ trigger fires the Rule to retrieve the State Name from the database using the ‘LoadStateCode’ datasource

control.




5.1.2. Example 2 – Credit Card Check

As explained earlier, the scenario is that you have a ‘Checkbox’ called ‘Is Card Holder’ and if this Checkbox is

selected, then display the ‘Card Code’ and ‘Card Type’ fields in the Form, which are otherwise hidden. And on

entering the Card Code, validate the entry and populate the Card Type field with the result of the validation

rule.

Below, only if the ‘Checkbox’ is selected will the Card Code and Card Type fields be displayed.

Next when the User types in SLV1234567890 into the Card Code Field, we are validating that this is a ‘Silver’

Card based on the first 3 characters typed in, and we are also setting the background colour of the Card Type

field to ‘Silver’ as part of the validation.

Similarly, if the User types in GLD1234567890 instead of SLV, we are validating the entry as being that of a

Gold Card and are displaying Gold in the Card Type field as well as setting the background colour of the field

to Gold as well.




Now let us examine how the business logic shown above was achieved. You can see below that in the

‘ShowCreditCardControls’ rule, we trigger the Rule based on the checkbox ‘iscardholder’ being selected.

Once the Rule is triggered, we then display the 2 fields by setting their Style.Visibility property to ‘true’ using

the Rules Editor.




The next Rule to be triggered is the ‘CardType’ Rule which is fired when the ‘cardCode’ field is populated. So

based on the Character String typed into the ‘cardCode’ field by the End User, once the User tabs out of that

field, the Rule fires and you can see below how the first three characters are being validated to decide

whether it is a Silver or a Gold card, and based on the result of that validation we also set the

Style.BackGroundColor property to ‘Silver’ or ‘Gold’ for the cardType field.




5.1.3. Example 3 – Date Functions

In this scenario, once the User selects a Date in the DOB field, which is using the Date Picker Form control.

We are calculating the ‘Age’ in the Age field next to it.

So you can see below that the Age is calculated as ‘38’ when the 15th October 1973 Date is selected.

The Rule Editor entries to achieve the logic described above is shown below. The ‘Ceil’ function is used to

calculate the ‘Age’ using the Formula shown below using Global Variables such as ‘SystemDate’ etc.




5.1.4. Example 4 – String Functions

To demonstrate string manipulation functions, the example below concatenates the three fields ‘Title’, ‘First

Name’ and ‘Last Name’ into one String, and displays it in the ‘Full Name’ field.

This logic above is achieved by appending all the three fields and populating the result into the Full Name field

as shown in the Rule below. This Rule is triggered when either of the ‘title’, ‘firstName’ or ‘lastName’ fields are

entered. So even if you edit a value in any of the 3 fields, the concatenated string in the Full Name field gets

updated.




Another example of the String Manipulation capabilities are shown below,

Here we demonstrate how you can split a String into separate fields on a Form, by splitting specific characters

into each of the fields. We also validate that before splitting the String typed in, we should first check for it to

be exactly 10 Characters long.

So below when we enter 12 characters instead of 10, the Validation Rule is fired and it displays the validation

message stating that there are 12 characters typed in.

Now once we type in 10 Characters, as expected below, you can see the Characters are split up into the

three fields as defined by the Rule.




Now let us examine how the Rules Editor allows you to achieve the string manipulation demonstrated above.

You can see below how the ‘StringLength’ and ‘SubString’ functions are used to first validate the length of the

string and then split the string and populate sections of it into the 3 individual fields as required.

Note that for many business application scenarios, we can also maintain hidden fields in the form to store

temporary or session values, which allows us to maintain state and manage a stream of logic, even as the

User navigates between multiple forms.




5.1.5. Example 5 – Numeric Functions

The example below will demonstrate how numeric functions or calculations can also be handled using the

Rules Editor within any of the Forms designed using ClaySys.

Below, when we enter numeric values into the fields ‘Number 1, Number 2, Number 3, Number 4 and Number

5’ we calculate the sum of these values in the field ‘SUM’ and the Average of these values in the field

‘Average’.

Even if you edit the values of any of the 5 fields after setting it the first time, you will see that the re-calculation

is instantaneous, as the Rule is triggered when any of the Field values change. The Rule Editor view showing

how this was achieved will make this clearer.




So to achieve the Numeric Calculations shown above, what we did was setup this very basic Rule as shown

below. It sets the Value of the ‘txtTotal’ which is the SUM field to the summation of the 5 fields, and it sets the

‘txtAvg’ which is the Average field to the average values spread across the 5 fields as well.

Note that this Rule is triggered when any of the 5 fields are updated, so when that event occurs, the Rule

fires, and recalculates the SUM and Average as required.




6. Conclusion This White Paper attempts to introduce the reader to the capabilities of the ClaySys Product Suite. It does not

comprehensively address all the features, but should express the core capabilities of the ClaySys Product.

The Screenshots and Examples should enable the reader to identify with how you would use ClaySys to

create a Business Application very, very rapidly. In our internal testing, we have seen a 1 x 30 to 1 x 50 time

saving when trying to build an application with ClaySys as against the classic Custom Development

Approach. This varies depending on the complexity of the application functionality being attempted.

We have seen that ClaySys ends up building almost the Entire Business Application being envisioned, during

the Requirements Gathering Phase itself, as its simpler for a Business Analyst to layout the Application Forms

and UI while Interacting with the Business Users when brainstorming on the Application Requirements.

The built in BPM and Workflow capability allows you to also create complex Form Routing logic, to setup

approval processes for Form Submissions, Form Edits etc.

The full power of the ClaySys Platform can be demonstrated by actually applying it to building a Sample

Application itself. The biggest advantages of the ClaySys Approach towards Business Application

Development is the fact that the Application can be created very, very quickly, where we are talking days

instead of months and years.

Once a ClaySys Application is in Production, the additional benefits come to the fore, where the ease of

Application Maintenance is highlighted when ‘Change Requests’ are able to be addressed over a 24 hour

turnaround time at the latest. Most changes simply take minutes to a few hours, but in Enterprise Scale

scenarios, the changes would need to be published to QA and UAT Environments, before moving them to

Production, and therefore we’ve seen a 24 hour turnaround being practical for most changes.

Note that maintaining multiple Environments for a Business Application using ClaySys is supported

comprehensively, and is practically just multiple Databases being maintained in the back end to support each

Environment like Dev, QA, UAT, Training etc, and publishing Changes from One Environment to another is

Simply Moving that Application or Module or Forms Metadata from One Database to Another using the

ClaySys Publishing tools.

To prove the power and capabilities of the ClaySys Platform, we would invite any prospective Client to test the

Product on either a ‘Proof of Concept’ or ‘Pilot’ project, without needing to make any purchasing commitments

of the Product. We would support the prospective Client is configuring the entire POC or Pilot project with no

commitments expected whatsoever, as we are confident that once a prospective Client identifies with the

power of the ClaySys Platform, we usually end up converting them to a paying Client pretty quickly.