Best Practice for developing K2 Apps

This guide goes through some  best practices for developing K2 applications.


Below is a list of additional things that are needed for every K2 Smartform.

Form Name

Form name should be made of the following

[ProjectName].[Area].smf.[Name of form]

So for example a form name would look like DMO.TST.SMF.DemoForm


Form Description

The form description needs to be filled in with a basic description of what it does and also its story number and form number. The form number should be in this format < form number >. So for example <FM0001>.  This will make it easier for people to easily identify what the form does what it relates too.






For this project it’s recommended to use concurrently if you do not need to pass data between the actions or rely on the result of the previous action.


Below is a list of additional items needed for a view.

View Name

The name of the view is made up in the same way as a Smartform. The only difference is that instead of .smf.formname.  The instead of ‘.smf’ its one of the following

[ProjectName].[Area].vwi.[Name of view]


View Type


Item View VWI
List View VWL


View Description

The view description needs to be filled in with a basic description of what it does and also its story number.  This will make it easier for people to easily identify what the view does what it relates too.


View Properties

View input controls and labels are in the same column.


View Controls

The controls for the view also has naming conventions

Display Controls

Type Property Name Size Example
Content ctt cttMyControl
Label lbl 200px lblMyControl
Picture pic picMyControl

Input Controls

AutoComplete auo 200px auoMyControl
Calendar cal 100px calMyControl
Check Box chk 150px chkMyControl
Check Box list chl 150px chlMyControl
Choice che 200px cheMyControl
Data Label dbl 200px dblMyControl
Drop-Down list ddl 200px ddlMyControl
Hyperlink hyp 200px hypMyControl
List Display lst 200px lstMyControl
Lookup lku 200px lkuMyControl
Multi-Select msl 300px mslMyControl
Picker pkr 200px pkrMyControl
Radio Button rdo 150px rdoMyControl
Radio Button Group rdg 150px rdgMyControl
Radio Button list rdl 150px rdlMyControl
Rating rtg 150px rfgMyControl
Rich Text rxt 400px rxtMyControl
Slider sld 150px sldMyControl
Text Area tar 400px txtMyControl
Text Box txt 200px txtMyControl
Tree tre treMyControl

Action Controls

Button btn btnMyControl
Timer tmr tmrMyControl
Toolbar Button tbr tbrMyControl

Attachment Controls

File Attachment fat fatMyControl
Image Attachment iat iatMyControl

Layout Controls

Table tbl tblMyControl

The size is only a guide and common sense must still be used for controls apart from the label control.


Control Watermarks

Each control should have its own watermark, with the watermark relating the label the control belongs to and not just the default ‘Type a value’

The watermark must be all in lower case

The image below should help demonstrate this



When to use a drop down list or a picker control

Using drop down lists to select reference data and for most cases is an acceptable approach as everybody knows now to use a drop down list. But it does have a couple of drawbacks.

  1. Can take the form a long time to load if there is a huge amount of data to populate the drop down list
  2. When the user interacts with a dropdown list with huge amount of data, the drop down list becomes a nightmare to interact with.

So we do have an answer to this and that is to use to the picker control instead. This will allow for speedier loading times and also allows the user to search for the specific data in an easier fashion.

The rules for moving to a picker control is if the reference data is longer than 20 rows then use a picker control. You still setup the control in exactly the same way as you would a drop down list. The only differences you can choose which properties can be searched against.

Setting up a picker control

1.Drag  a picker control on to the view or change an existing control into a picker control




2.Give the control a  name with the correct naming conventions

3.Select ‘SmartObject’ under data and setup as normal if you would a drop down list

4.Select which properties you want to filter against


5. Click ‘Ok’


6. In the picker control properties unchecked ‘Allow Multiple’


Required fields

If a control is required, we can graphically represent this by adding a *. To do this do the following steps.

  1. Select the label of the  field/control you want to modify
  2. In the properties tab, find the ‘Text’ property
  3. At the end of the text, put in the following html ‘<b style=’color:red’>&nbsp;*</b>’
  4. Literal property is enabled
  5. In the ‘Tooltip’ put in the text of the label without the html ‘<b style=’color:red’>&nbsp;*</b>’.




Control Data Cache

Please make sure that data caching is not enabled on your data list controls like dropdown lists etc…


Label to Control spacing

As mentioned in the table at the beginning of ‘View Controls’ the labels must set to 200px with the ’Wrap Text’ property value set to ‘True’


Read Only Controls

Data that is read only will be data labels with ‘Read Only’ enabled and with a name that starts with ‘dblReadOnly’

So for example a ‘Lastname’ needs to be read only, it would be called ‘dblReadOnlyLastname’


View Rules

The pattern for RCT is that we have smart views and dummy forms. So to get this to work properly we have use unbound rules.


How to create a unbound rule

Unbound rule is something that is not bound to an event such as a button is clicked.

To create unbound rules do the following steps

  1. Click on Rules, ‘Add Rule’
  2. In the right hand panel and click on ‘Enter Rule Name’ as seen in the image below


3. Start the Rule name with the word ‘Unbound’ and the rest of the rule name should be what it does.

4. You can then add in conditions and actions as normal

Reducing the load with editable list views

Due to the amount of rules being called on an editable list, there is new approach that dramatically reduces those calls.

1.Create a list view, but don’t enable the editing options


2.On the view layout, drag a couple of ‘Toolbar buttons’ on the to the top of the view and name them ‘Add’ and ‘Edit’


3.Add a parameter for the primary key of the data the list view is bound to

4.Click on ‘Finish’

5.Create an item view based on the same SmartObject that was used for the list view.


6.On the item view add  a button and lets call ‘Save’

7.Add a parameter with same name and type that you used in the list view.


8. Add in any other additional parameters you will require such the rest of the best practice parameters.

9.Click on ‘Rules’ and click on ‘Add Rule’

Event When a view executes a method  initialize
Condition If the view parameter contains a value  (Primary key parameter)
Action Execute a view method Load
Input Parameter ID
Parameter Value View primary key parameter


10.Click on ‘Ok’

11.Create a unbound rule to check the validation of the view

12.Create an unbound rule to either save or update the data depending on if the parameter id is populated like in step 9.


13. Now create a rule for when the save button is clicked which will check for the view validation rule and then call the ‘Unbound Save Data‘ rule that you just created.


14. Now that we have built the rules to save and update and load the information we can now add it to the list view. Open the list view in ‘Edit’ mode and go to the rules

15. Create a unbound view called ‘Unbound PopUp View

Rule Name Unbound PopUp View
Action Open Subview (Select your item view you just created)
Configure Execute a view method Load
Source Parameter List View Primary Key parameter
Destination Parameter Item View primary key parameter



16. Now create rule for the ‘btnAdd’ that calls the unbound rule

Event Control on view raises an event
Action Transfer Data


Parameter Primary Key value
Parameter Value Empty (Tick the check box, but leave empty)
Action Execute another rule Unbound PopUp View


17. Do the same for the ‘btnEdit’ except without the ‘transfer data’ action


18.Create a rule that when you click on the list item it transfers the primary key from the list into the view parameter.



19.The last set of rules we need to do is add an action to close the sub view once the ‘Save’ button has been clicked. Click on the ‘btnSave is clicked’ rule and click on ‘Edit’

20. Click on the ‘Actions’ tab and search for ‘Close’ and select ‘Close Subview’ action. The edit rule should look like this.


21. Click on ‘Ok’ and ‘Finish’

22.You can now test the view to make sure it’s behaving correctly. When you click on ‘Add’ it should load up the item view empty and when you click on ‘Save’ it should insert a new record into the list. If you click on an item in the list and click on ‘edit’ it should load up the data for you to edit. When you click on ‘Save’ it should update any changes.



This section looks at what is needed in every workflow

Where to create the workflow?

The workflow is to be created in visual studio, so it can be checked into TFS

Workflow Name

The name like the views and Smartforms must represent what part of the project it relates to

[ProjectName].[Area].wf.[Name of workflow]

Workflow Description

Work flow description should be filled in, so people know what it does and what story it relates to

Workflow Data fields

Data fields should be kept to a minimum and be used to only hold reference data like a primary or foreign key. You can then use ‘reference option’ to get the rest of the data that you need.

The following check boxes also need to be unchecked

  • Hidden
  • On Demand
  • Keep Audit


Workflow Activities

Workflow activities should contain a name in what they do and the activity description should contain information such as whether there is a start rule or any escalations.

To describe what activity rules are being used you can use the following abbreviations

Activity Rule


Proceeding Rule PR
Start Rule SR
Escalation Rule ER
Destination Rule DR



Activities are colour coded to make it easier to identify what they are doing

Activity Type

Activity Colour

Start Green
Client Activity Blue
Server Activity Grey
IPC Activity Yellow
End Activity Red


Activity Events

Activity Events should say what they are doing and not be left with the default names

If a server event is used with some code then the event name should be prefixed with ‘CC’

Please note it is not ideal to put code directly into the workflow and you must consult with your K2 lead before doing so.


Line Rules

Lines Rules must have a label that is prefixed with LR and then what the rule is checking for. As seen in the image above.


Line Colours

The outcome lines should also be coloured to represent what they are doing and to also help visually navigate what the workflow is doing. This is especially helpful in larger workflows

Line Type


Approve (Positive Line) Green
Reject (Negative Line) Red
Rework line Blue
Normal line Default





This sections looks at what is needed in each SmartObject. If you have a number of stored procedures that interact with same table, then same SmartObject can be used with the additional methods and properties added.

Where to create a SmartObject

SmartObject should be created in visual studio and in the correct folder

SmartObject Name

The name of the SmartObject like the rest of the K2 artefacts should carry the same naming convention.

[ProjectName].[Area].smo.[Name of SmartObject]

SmartObject Description

The description of the SmartObject should describe what it does and what story it belongs to.

SmartObject Parameters

All required input properties should be parameters and be prefixed ‘p’

SmartObject Properties

  Naming Conventions

The property names must be named correctly with no ‘PropertyName(1)’ used

There should be no names with spacing between words or no _ . Camel case should be used

  Property Description

A description of the property used be filled in describing what the property does.

  Property Data types

The correct property type should be used and most of the time K2 will take care of this automatically. The only exception is for file types. You will need to manually change the property data type for the file property from ‘Memo’ to ‘File’


When creating a method the following needs to be checked.

Method Name

The name should represent what it does

Method Description

Should describe what the method does and what store procedure it is calling

Method Types

In some cases the correct method type is not selected. After the service object method is collected.


So you once the service object method has been selected and the properties created and bound to the service object. You need to edit the method and choose the correct method type.

An example of this sometimes a store procedure that returns a single row of data is sometimes returned as a list method. This is incorrect and would cause problems later on in the view design.

So in this case you would need to change the method type to ‘Read’ and then save.


Testing SmartObjects

After creating the SmartObject, it can be tested by using the SmartObject Service Tester which if its not on your task bar it can be found here ‘C:\Program Files (x86)\K2 blackpearl\Bin\SmartObject Service Tester.exe’



Using this application allows you then to test your SmartObject to see if it is working correctly.


How to test your SmartObject

To test your SmartObject do the following

  1. Open the tester tool
  2. Expand ‘SmartObject Explorer’
  3. Navigate to your SmartObject
  4. Right Click on the object and select ‘Execute SmartObject’


5.From here we can now test the methods of the SmartObject. Select a method from the dropdown list and fill out the parameters as required and then click on ‘Execute’

6.The returned data if there is any will be returned in the underneath the parameters.