Best Practices in ClaySys Appforms Configuration

Before going through this documentation, I am assuming that the user knows the basic ClaySys AppForms Configuration including rules and data sources.

A comprehensive configuration encompasses all the aspect of assembling the Forms, Controls, Rules and Data sources in the smart way. This will improve the performance and readability of the AppForm configuration.

This blog post will help you understand the best practises for ClaySys Appforms are not proposed to form an inflexible methods to follow, they are meant to serve as a guide for creating the application for a specific project.

The AppForm configuration can be divided as follows:

  • Deciding the goal
  • Finalizing the UI design
  • Data Source design (The back end data where you save and process data)
  • Deciding the number of form
  • Deciding the controls in the form
  • Structuring the rules
  • Calling the right rule at right time


Designing the form

In AppForms the form is presented to the end user as the HTML, so basically the form is rendered as HTML in the client browser.

If you are not replicating the UI design of another form, keep the number of controls minimal to improve the rendering.

It is very important to decide navigation and number of form even before you start designing, so once you decided the navigation then you can take decision on the number of form you are going to use.

Hidden control

This is a kind of tricky stuff because mostly these hidden controls are used to keep the temporary values. Most of the time the designer will set the visibility of the control as hidden permanently and that control is used as “HIDDEN CONTROL”.

As the project move in agile mode the designer will keep adding the hidden controls just to maintain the temporary value or to control the form logically. When a new designer continue to work on this kind of form, they will be really worried to touch those controls so he will add new controls to it, the end result of this method will be a junk form.

Also if you use a hidden control whenever a value is changed in that control, the AppForms will search for rule for that particular control, this can be avoided.

As mentioned earlier, since this form is rendering as HTML, it will take time to render. But according to the end user there may be only few visible controls and the end user is really worried on the performance in that form .

b1 So how can we avoid this? 

There are few methods we can use :

  • Managing through variable
  • Managing through Session variables
  • Reusing the controls
  • Keeping only minimal data

“ Even if you wanted to use the hidden controls for managing the form logic then it is better to group the controls using SubForm control, So you can show and hide the controls by just disabling the sub form rather than hiding each controls “

Managing through variables

This is the smartest way to keep the temporary value and traffic the rules. The normal variables can be created from the rules. You have to note that the variables can be accessed only from rules, it cannot be accessed neither from the designer nor from data source.

If it is essential to pass the variable value to the data source then use only one hidden control and pass the variable value to the control. You can use the same hidden control to pass value to the different data source.

Please see the example below:


There are two data sources to save to two different lists, and based on the date of birth they need to save Age to the first data source and based on the Gender they need to save Mr/Miss to the second data source. In this case you have to use the rule to populate the Age from Date of birth and Salutation from Gender. Once you populated you can assign the Age to lblTemp and invoke the save action. Once that is completed you can use the rule to generate the Salutation and assign that to lblTemp and use the same save to the second DB.

Managing through Session variables

Those who have a small glimpse to the programming world they must know the session variable. It can store any data and scope of the session variable is through out the Tenant in the ClaySys, and the life time is till the  browser gets closed.

Who need session variables?

Let’s take an example, If I want to maintain a common value called ‘company name’ through out the forms, I can either pass the value between the forms using the controls or use session variable.

Next, if the user want to load form_2 from form_1, but also he want to pass a value from form_1 to form_2, the user can use the session variable to keep that variable.

*Please note the session variables can be used in Data sources.

Reusing the controls

Reusing the control is just what it mean by the title. For example, based on different value you need to perform some operation in the rule. So let try the same by using only two controls, One for the command(txtCommand) and the another one for the value (lblValue). And when you create the rule add the txtCommand as the trigger .


Standard naming practice

In any domain, naming conversion have a great benefit to reduce the effort to read and understand the configuration. It provides a better understanding to the third person who is reading this configuration even after a long time.

The best recommended practices are :

The default name of a control name will be control type + number, leaving this as it is not a recommended process.
The recommenced naming standard is Control Type Short Name + Name +functionality

For example,
Text Box which managed with Name for the Employee info will be, txtEmpInfo.
ComboBox which load the state for Student info will be, cmbStateStudent.

The variable can be given with a prefix of Var
For Example,
The variable to keep the count will be varCount.

Also you have to note that whenever a variable name is created it should not conflict with the control name or the default rule function name.

The recommended process for the rule is, it should not conflict with the control name or the default rule function name. Whenever you are giving a sub rule it can be managed in a little more smart way, like

The Child name should be like Parent Rulename_1 and the second level child should be Parent Rule name_2 , like the example below:


Using the right control

While configuring it is advised to use the right control for the right purpose, for example it is not advised to use the Dynamic grid control for the purpose of Search control. The main purpose of dynamic grid is not just to display data but perform the data manipulation operations, also it has composite column feature and lot more, so when you use the dynamic grid instead of search it has to do lot of process before pulling the data to the view .

Sync and Asynchronous operations

Basically the sync and Async operation plays while the time of data Source related command like Execute command and FillData command.


Async / Sync

What is Synchronous operation ?

When the user choose the synchronous operation for the execution then it will block the next operation till the synchronous execution is complete, It is advised when you use the execute command as the last action.
OR if there is only one or two execution. Basically synchronous operation is advised to the basic forms.

What is Asynchronous operation ?

Asynchronous operation take the advantage of parallel processing, like the Async execution will not block the next operation.

Then how do I know that my Asynchronous execution is completed?

The user can use two methods to manage this, use the Execute completed and Fill Data completed trigger. Please refer the Execute Complete trigger and Fill Data complete trigger from the ClaySys AppForms documentation.
The second option is set the execution result to a control while configuring the data source and add that control as trigger to a rule, so when the execution is completed the result will set in to the control and the control will trigger its rule.

Rules optimization

Rules in the AppForms are the brain when the user wants to control the flow of his execution. So please note the better practice as below:

Enclose the non-control value with double quotes when you are using it,

For example
txtName.value=”anto.Rubin” (good practice)
lblName.Value=anto.Rubin (This will still work but not advised)

According to the architecture of rule engine, when you give a value the rule engine will check is that a control name/Variable/operation, only if that is not a control or variable it will rerun the name. But if we enclose double quotes then it will not check for the same and it will directly return as value .

Avoid giving the same control in multiple rules

It is advised to not give same control for different rules, but you can call the required rule using RunRule() function.

Avoid leaving the rule with syntax error

There is an option in the designer to check is there any syntax issue in the rules. If you leave as it is, the remaining rule will still work but that error part will be executed as rejected by the rules engine each time.

Avoid recursion

This is a big no no in the rules. This is like adding the control as trigger and setting value to the same control from the same rule. Also there are lot of recursions where the user use for the purpose of looping, and in that case the user must proof the looping logic with and entering condition. see the example below:

In the above example the varIcount will control the execution of the LoopRule.

Understanding Enterprise Application Architecture

In this post, I will highlight the typical portfolio of Enterprise Application requirements, and touch on an architecture that is better aligned towards leveraging the benefits of an off-the-shelf software application, while continuing to pursue the customization’s required to have the final solution align with the unique business processes and user experiences of each unique organisation.

A Typical Company,

  • Buys (Raw Materials or Products to Trade)
  • Makes (Saleable products and/or manages inventory
  • Sells (Sells Finished Products and/or Consulting Services)
  • Hires and Pays Employees

To support these core functions, the typical company invests in a Business Application like an ERP system from SAP, or products as basic as QuickBooks, which allows them to automate the core regulatory and compliance functions around:

  • Buying – Accounts Payables or AP, to manage purchasing and paying vendors
  • Manufacturing – Costing, Production Planning, Warehouse Management (MRP)
  • Selling – Accounts Receivables or AR, to capture and process orders, and track collections
  • Hires and Pays Employees – Automating payroll, salary disbursement and expense reimbursement

While almost every company has the same needs in relation to the core software modules from a regulatory or compliance standpoint, the challenges arise in extending the collaborative features touching each of the core functions, to align with the unique way in which the processes have been defined within the organization. Every organization needs to have the software application work a certain way, to meet the practical process requirements and user experiences required, to ensure the application can be used effectively by its employees.

As an example, we will look closer at the Purchase Management function which is illustrative of why the need for customization of off- the- shelf Accounting packages arises.  The basics of issuing a PO and tracking the payments to the vendor are handled routinely by the likes of QuickBooks or SAP.  They do an excellent job of handling the regulatory and compliance requirements around tracking of payments, as well as the calculation and disbursement of taxes.

The challenge for every organization is in the collaborative side of the Purchase Management function, which usually is unique to the operational processes defined within each organization. These unique processes create the need to ‘customize’ the off the shelf software products, and are the cause of most of the pain related to maintaining and using these software packages.

In this Purchase Order example, once a PO is finalized, it is simply an entry into the Accounts Payable Ledger, for a purchase of goods and/or services made with a vendor. The areas where organizations get into unique scenarios around the purchase process are highlighted below,

  • Purchase Requisition Workflow – Companies want to have a requisition process, where the requirement for any product/service is requested by an Employee or Department, after which it is reviewed and approved by different stakeholders, prior to a Purchase Order being created.
  • Cost Allocation – While the accounting entry is a Purchase Order entry resulting in an Accounts Payable record, each PO may need to be mapped to the accounting Cost Center, to decide which department or from which approved budget code, the specific PO needs to be applied. So approving a Requisition may require to see how it impacts the budgets allocated for a specific cost center or project, prior to having a PO issued.
  • Vendor Quote Management – Some companies may want to receive multiple Vendor Quotes, before finalizing a Purchase Order with a specific vendor. In such scenarios, the requisition that is approved, results in submission of the requisition or an RFQ to multiple vendors, against which the vendors submit quotes. The quotes are evaluated internally, after which a decision is made on which vendor to issue the PO to.
  • Purchase Consolidation – In some scenarios, requisitions may arise from different departments for the same product. E.g. New Laptop computers, where different departments want to procure new laptops. In such scenarios, the purchase department may want to consolidate the different requisitions into a single requisition that is then sent to the vendors for quotes. Since an increase in purchase quantities qualify for vendor discounts, such consolidation allows the company to save on purchase costs.

The more efficiently a company handles their processes, the more competitive they become.   Enterprise Applications were not created for agility, they were created to enforce a pure vanilla, ‘best practices’ way of doing things, which is why unique ways in which the Purchasing Process may need to be setup as highlighted above, are required to be achieved. The question then is whether such custom requirements should be achieved by ‘Customizing’ the ERP system itself, or whether there are any other more practical and efficient options.

While customizing the ERP is the default thought process within most organizations, i have highlighted below, some of the challenges and issues that arise out of customizing these monolithic programs:

  • Implementation Lead Time – While an off-the-shelf product can be installed and setup relatively quickly, it is the customization requirements that delay the implementation to take months if not years for completion.
  • Additional Costs – There is significant cost incurred in executing customization’s, as proprietary skills on a specific product are required, and the hourly technical consulting rates can be exorbitant.
  • Significant Cost to upgrade – If no customization’s are implemented, most ERP vendors support upgrading their products to the latest version very easily, with the upgrade supported with tooling provided by the ERP vendors themselves. But when you have customization’s implemented, then upgrades can get quite complex, with the need to first migrate the customization’s, and then re-test the migration with all historic data migrated, which is time consuming, expensive and complex.
  • Product Support – For many migration projects, by the time the migration is ready to go into production, the vendor has released at least one, if not several additional upgrades to the product version. So the newly migrated version itself is outdated when it goes live. If the client chooses to avoid a migration, as they can manage with the functionality of the existing legacy version, they are eventually forced to migrate when the Product Vendor retires support for the version that they are on.

So is there an alternative to meeting Enterprise Application customization requirements?

The following steps offer a way to realize the off the shelf benefits from commercial ERP or Accounting products, as well as an approach towards tailoring  the processes around them to meet the specific business requirements of each organization:

Step 1 – Avoid Customizing the ERP system like SAP, Oracle or QuickBooks.

Step 2 – Ensure the API (Application Programming Interface) Module license is procured with the prepackaged off-the-shelf application licensing, which ensures support to integrate with the ERP functionality and data.

Step 3 – Deploy a ‘No-code’ Application Development platform, to be the platform on which customization’s would be conducted.

Step 4 – Create all customization’s for the collaborative processes in a ‘No-code’ application layer, while integrating with the core ERP system through the API, or through read-only access to the ERP’s data layer for direct data access.

There are many ‘No-code’ platforms in the marketplace today, that support such a capability, and the ClaySys AppForms platform is one of the leading products in this space. By following the approach above, the core ERP can always be upgraded, as no customization’s are done on it, and so upgrades can be conducted easily using the tooling provided by the ERP Vendor.

Since all customization’s are done in the No-code Application Development platform, it is easy to achieve the customization’s required, in a fraction of the time, as the traditional software development life cycle is circumvented by the no code configuration paradigm that is significantly more productive.  Conservatively speaking, there is an 8x to 10x productivity gain, in comparison to hiring expensive specialists to hard code the customization’s within the ERP itself. Since the no-code platform integrates with the ERP using the API module, the customization’s are not limited, and full read/write access to the core ERP functionality can be managed through the API.

Since the API layer does not change significantly during the version upgrades of the ERP, carrying forward the customization’s done using the no-code layer to support the newer ERP Versions are possible and quite feasible, and significantly faster and less expensive than the migration of customization’s done within the ERP itself.

The no-code platform itself is futureproof, which means every update to the no-code platform can be done by carrying forward all functionality created with any earlier version of the no-code platform, so there is no upgrade related pain point in this layer.

Security is also enhanced, in that customizations on the no-code platform do not require each form to be inoculated against the 60+ known vulnerabilities compromising web forms. The no- code forms are presented to the users via a rendering engine or application browser, which becomes the one place to keep the web form security up to date with blocks against all the known vulnerabilities, which are then inherited by every form created with the platform. The same principle is used by the browser vendors, as they constantly update their offerings as new vulnerabilities are identified, but all HTML or HTML5 websites still render just fine.

The concept of letting the monolithic systems of record like ERP do what they are good at doing, and using an agile no code platform to handle the customization’s required over and above what the ERP system offers, in a fraction of the time and cost, makes perfect sense. The business will get the customization’s much faster, and IT will avoid the need for time consuming, and expensive upgrades.

The ClaySys AppForms platform was envisioned, designed and developed to address exactly the kind of scenarios that i have highlighted in this post.