(403) 770-3017

Kiashay Framework

The Kiashay Framework’s objective as a Windows software development tool is to allow for a significant reduction in development time and ongoing support costs, while improving the functionality and reliability of custom developed business system applications. It accomplishes this by addressing the majority of business application requirements such that the developer can simply inherit functionality and often just set parameter options to implement interactive forms, reporting, and batch processes. The Kiashay Framework “takes care” of most of the requirements that the software developer traditionally had to code for.  The overall method to implement this is fairly novel in itself, however in addition, the Framework includes some innovative functionality which previously has not been addressed or not implemented to the same level. Some of these items include:

Categorization: A common requirement in developing business applications is the need to organize data into groups or categories. For example, if a company handles numerous products they often wish to group the products into different categories. Traditionally, the solution for this is for the developer to create a Product Categories table (or multiple tables if more than one category type is desired) and relationally connect it to the Products table. As long as the categorization requirements are straightforward and structurally do not change, this solution is quite viable. If, however, there is a need to categorize items in multiple different ways, sometimes parallel (independent sets of categories), other times hierarchical (categories containing categories) or combinations of both (one within the other down to any level), the solution is far from trivial. If, on top of this, the exact categorization requirements are difficult to predefine or are subject to change, then traditionally the problem has been too unwieldy. With the Kiashay Framework the solution has been developed and is “built in” such that the developer defines the Products table as they conventionally would and simply sets that table to “utilize” categorization which implements full categorization capabilities for that data.

Security: For any application accessing a corporate database, controlled user access is almost always required. Windows Active Directory controls user access to Windows computers / networks. Windows databases like SQL Server & Oracle include, and recommend use of, integrated security where a user’s Windows Active Directory account flows through (is recognized by) the database rather than a separate database account being required. As Windows databases are easily accessible via various tools (Excel for example), it is not recommended that users are given the privilege to add or edit data specifically but rather  have the ability to implement a Role via an Application which then allows for the required privileges within that application. The Kiashay Framework utilizes Windows Active Directory integrated security and database Application Roles for its fundamental security. In addition to this, the Kiashay Framework adds on numerous finer level security options. By simply configuring Program security options and Data Table security options the software developer, utilizing the Kiashay Framework, can implement security at a Program Level, at a Category Level, at an individual Record Level, or any combination of these.  For example if we are granting privilege to modify Product records, security may be set at the Program level in that a user has (or does not have) privilege in the program to edit any Product records. Security could also be set at a Category level where Products are assigned to categories and users are granted privilege to specific categories of Products. Finally security may be granted at an individual record level where privilege may be granted to edit only a specific Product. The level of security implemented varies with each program as requirements dictate.

In establishing privileges available to a user, security is determined in the following order. If a user has been granted (or denied) privilege at a record level then that security is used. If a user has been granted (or denied) privilege at a category group level and no record level security has been defined (for that user) then the category level is used. Finally, if security has been granted at a program level and no lower level security has been set, then the program level is used. If no security has been defined for a user, the user would have no access to the data.

Security can be granted to an individual user or to a Security Group (group of users). As a user may be a member of multiple security groups and each group may have been granted differing privileges, the following procedure is used to determine security in this situation. If security has been granted (or denied) specifically to a user then that security is used. If security has not been set specifically to a user but has been granted to multiple groups that the user is a member of, the “sum” of the privileges is granted (i.e. if one group has Edit privilege and another group has Delete privilege and a user is a member of both groups that user would have both Edit and Delete privileges). If access is specifically set to Denied on any group the user is a member of, the user will be Denied access. This security by User or Security Group exists within each of the security levels defined in the previous paragraph (Program Level, Category Group Level, and Record Level).

Applications implementing Record Level security have a security toolbar button which launches the record Security Screen. This allows for the setting of security on a specific record. With this fine level of security and the interrelationships between them, it may not be obvious sometimes how security was determined. From this form users may view the Security Tree flowchart to see how their security was determined. Administrators can view the flowchart for any user.

Specific Security Privileges that can be granted are

  • Read – User can read (view) the data.

  • Edit – User can edit (change) the data.

  • Delete – User can delete the data.

  • Deny – All access to the data is denied even if it is granted somewhere else.

  • Record Lock – User can lock the record

  • Modify Security – User can modify security for other users

  • Change Record Status – User can change the record status (see Record Status section below)

  • View Preliminary – User can view records with a Preliminary record status

 Batch Processing: Natively in Windows the ability to do batch procedures scheduled to run routinely at any time of day is quite limited. Some third party tools are available to schedule/launch programs, but they do not incorporate logging within the batch process of what has been performed and the results; pausing, stopping and/or restarting jobs at individual steps; and an environment to handle typical business application batch processes requiring processing of large volumes of transactional data. Within the Kiashay Framework there is a full Batch Queue processing & control structure; the ability to monitor progress and completion of steps within a batch process; error notification and restart/recovery options; as well as a framework structure to develop the batch program. The batch processing “code” to be developed is done in the standard Visual Studio and Database Stored Procedure SQL code that developers are used to.

 Report Parameter / Filter Selection: A significant portion of business applications require numerous end user reports / data inquiries. When running a report Users want to be able to select portions of the data in various combinations. The ability to filter complicated data (from multiple tables) simply and retain various filters for future use is highly desired. Tools such as Crystal Reports or Microsoft Reporting Services are very good for developing reports. What they do not do very well is provide a powerful interface for the User to be able to select / filter information. Within the Kiashay Framework the developer first creates the report with the development tool like Crystal Reports and then defines within the Framework the Report Filter which establishes the Tables, Columns, optional & mandatory requirements, interrelationship between filter data, etc. When calling the report with the defined Report Filter the user is automatically presented with the Report Filter form. This form allows the user to select/check off the specific set of data they desire. Different data types available for selection are displayed in individual tabs. Each Tab Name identifies the data available on the tab.

Selecting Tab Items:

  • The user can chose to display only data of a certain value by checking (clicking on the item). Multiple items, when selected, will show data of both values.

  • If a user does not select a specific item then all items will be selected.

  • When items have been selected on a tab the Tab Name will display the  icon.

  • When a tab contains selections in which the user is required to select at least one item the Tab Name will display the  icon.

  • Often selecting a certain group of data results in a reduced list of available subordinate data. When this occurs “(Reduced)” will appear in the Tab Name of the subordinate data tab.

Users can save a custom selection for later repeated use as a User Defined Filter. Previously saved Filters are listed in the User Filters drop down box. Saved Filters will show up as new Menu Items in the Application Center.

Data Dictionary: On business application screens there is the requirement to display and maintain record information. If we use a Product Maintenance screen example again, the Products database table has a number of columns defining the different elements of a Product. For each of these columns the business requirements will dictate if users can enter or change data in that column (field), if they must enter data in that column, the type and size of data allowed in the column, whether the data is normally searched for via that column, etc. The software developer when writing the application must write a fair amount of code to implement each of these requirements and have them integrate with each other and the application toolbars and menu items. The Kiashay Framework allows the developer to define the Record and Columns and on each column, assign the properties such as the type and size of information allowed, as well as if the column Is Required, Allows New, Allows Edit, is a Find Column, data should be spell checked, etc. Properties can also be assigned at the record level such as implementing Record Versioning, Record Status, Record Locking, Record Change History (see descriptions below), as well as allowing attachments & documents. Although the options are often desired, without the Kiashay Framework the developer must define additional tables, procedures and extensive code to implement similar functionality on a single table. Utilizing the Kiashay Framework the developer assigns the properties to the Record and Columns, links that column to Windows Form Controls (textboxes, list boxes, checklists, radio buttons, etc.) and the properties and underlying functionality are simply inherited into the application.

Record Versioning: File versioning has been available in numerous operating systems for years (other than Windows).  Within the Framework we have implemented the concept of Record Versioning which in concept is similar to file versioning. Record Versioning when selected on a Table implements the functionality that allows multiple versions of a record to be retained in the database. Each time a record is changed (or, if desired, each time a change of a certain significance happens) a new version of the record is created and the original remains unchanged. Functionality like this is useful in many situations, for example if a company makes some type of assembled equipment parts which contain other parts (a certain bolt is used to make bigger part). If the bolt part is changed slightly (there is a new version of it) it is nice to be able to treat the new bolt as a new version of the part rather than an entirely new part as often the new bolt will now be used wherever the old one was used, but historically we need to track where the old version of the bolt had been used.

Record Change History:  Often it is desired to be able to see all the changes that have happened to a record. Within the Framework the developer can turn on Record Change History on a Table which will cause a log item event to be created automatically each time a record is changed in a Table. The change that was done to the table and who did the change is recorded. The ability to view the Change History is automatically available from the application form.

Record Locking: Record Locking gives the User the ability to lock a specific record on a table. The developer first establishes if Record Locking is allowed on a particular table and when turned on, the User’s screen will then allow the user to lock or unlock any single record. Privileges to do this are further defined / granted via the Security Model described above.

Record Status: If Record Status functionality has been implemented for a particular application, data records can be in three different states Preliminary, Current, or Archived. Preliminary records are records that are in the system but are not yet available for general use / access. These would be used in situations where significant work must be done on set of data and the ability to work on it over time is desired. Users must have the View Preliminary security privilege in order to view or set a record as Preliminary. A record status of Current is for all of the active records in a table and is the “normal” state. A record status of Archived allows records to be no longer available for normal processing, etc. but still available for historical purposes.

Attachments/Document Management:  The ability to attach one or more files (Word, Excel, PDF, etc.) to any particular data record is often desired. For example on a Parts record you may wish to attach pictures, Manufacturer’s data sheets, etc. The Framework allows the developer to turn on allowing Attachments and/or Documents to any tables records and implements the interface to allow importing, exporting, viewing, checking out for changes etc. The difference between an Attachment and a Document is that an attachment only exists within the context of the record it is connected to (it is like another field on the record) while a Document exists independently, separate from a data record but can be linked/associated to one or many data records.

Word Processing: Although historically not even considered, there is a growing desire is to allow the ability to enter rich / formatted text data into traditional format neutral record/column information. By example again, a Customer Name or Product Name is normally simply a string of characters independent of any formatting.  For something like a Product Description or other larger textual information fields there may be a desire to bold or italicize part of the text, use different fonts, sizes, colours, etc. Essentially, formatting text similar to what you can do in a word processor with traditional business application record/column data is desired. This capability has been implemented within the Kiashay Framework allowing the developer to inherit and utilize the functionality within any application.

For more information or for a demo of the software please contact us at  Kiashay Framework Info