Springboard Modules for K2 provides a framework with building blocks to assist with the rapid creation of applications using reusable components. Springboard Modules for K2 includes the following:

  • Dashboard and Process Tracking Interfaces
  • Workflow components and general reusable Views
  • Transactional and system SmartObjects
  • Task allocation and Purchase request processes

The two working business processes offered with Springboard Modules for K2 could be used “as-is”, or as a base for more customized solutions. Using the Task Allocation Process, you could validate the installation of a new K2 environment in a matter of minutes. This process tests some of the key areas used within K2 – K2 SmartForms and SmartObjects, workflow processes, email integration, the K2 worklist and K2 reporting capabilities.

See this “How To” document for more information.

Benefits of using Springboard Modules for K2:

  • Immediate return on investment
  • Instant capability to test a new K2 environment
  • Provides customers with a unified and best practise approach for building K2 SmartForms and workflow
  • Rapid acceleration of K2 SmartForm development for all K2 projects
  • Out of the box features, reporting and processes
  • Springboard Modules for K2 is designed to overcome the gap that exists between installing a new K2 environment and the “First Process Live”.
  • The developers of Springboard Modules for K2 have been using the K2 product stack since the early days of K2.net 2003 (and some even K2 2.4!).
  • When deciding on naming conventions and components to use, we relied on industry standards and also tried and proven K2 best practices.
  • Springboard Modules for K2 component and category structure is broken down into logical areas which could easily be differentiated and defined by simply relying on the name.
  • The reusable Views are designed in such a way that each acts as a “stand alone” entity with self-contained rules which allows it to be used on its own, or with other Views on a K2 SmartForm.
  • We have opted to use a custom SQL database to serve as the data store for internal Springboard Modules for K2 artifacts – this decision was made with future updates to Springboard for K2 in mind, and also to isolate the data associated with Springboard Modules for K2.
  • It is strongly recommended that users do not alter any of the components delivered with Springboard Modules for K2, as future updates will overwrite your changes, and it could also negatively affect other components delivered with Springboard Modules for K2.

The naming convention guide made available by K2 (http://help.k2.com/k2ls-qrs023.aspx) was used as a starting point for the Springboard Modules for K2 naming convention. We aimed to follow a naming convention which makes it easy to understand what each component relates to and to align it with K2 and industry standards. Each the Springboard Modules for K2 artifacts is prefixed with K2ANZ to make it easy to identify items which belong to the framework. For more detail, please see the Bill of Materials.

For Springboard Modules for K2, we have opted to keep all Identity columns in the database as GUID. The reason for this is to allow us to port data into the database, should this be required with future upgrades of Springboard Modules for K2.

First, download the Springboard Modules for K2 ZIP-file. The ZIP-file contains a SQL server script and a K2 Package and Deployment file. Installing the K2 Database Before deploying the Springboard Modules for K2 package, you’ll need to create the SQL database. Open the SQL script contained with the ZIP-File using SQL Server Management studio. Before executing the database script, you will need to make two (possibly three) changes to the script:

  1. The database name is K2_ANZ_Framework. To change this, please change the DB name in the appropriate places
  2. The Transaction and Log files (MDF and LDF-files) are set to be created on here: C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\DATAThis location is not generally accepted (as most data files are usually stored on a D:\ or E:\ drive. Before running the script, please ensure that you choose the appropriate location for the files to be created.
  3. Springboard Modules for K2 requires that the K2 service account has a minimum of Execute, data reader and data writer permissions to the database. Please make the appropriate changes on the script: a. To set the K2 service account name b. Set the permissions to what you require.

Deploying the Springboard Modules for K2 package Using K2 Package and Deploy, simply deploy the package that is contained in the Springboard for K2 ZIP-file. For instructions on using K2 Package and Deployment, please click here. You will need to set some variable values during the Package and Deployment procedure – these variables are used to set up the service instance to the database you created prior to deploying the K2 package. On Different SQL Server This variable is used to determine if the Springboard Modules for K2 database is on the same SQL server instance as the K2 database. If the two databases are not on the same servers, please change this value to “true”. Springboard SQL DB name This is the name you have given to the Springboard Modules for K2 database. If you did not change the DB name, the default value set against the variable will be correct. SQL Database Server Name This value is the name of SQL server where the Springboard Modules for K2 database was created. Use Native SQL Execution If you changed the value of the “On Different SQL Server” value to “true”, please change this variable’s value to “false”. If the Springboard for K2 database and the K2 databases aren’t on the same server, then Native SQL Execution cannot be used. Post Deployment Steps Once the package was successfully deployed, please open the K2 workspace. You will need to set permissions to the two processes that were deployed and add users to the two roles deployed with the Springboard Modules for K2 package. Processes

  • K2ANZ.Framework\Processes\PurchaseRequest
  • K2ANZ.Framework\Processes\TaskAllocation

Please assign the appropriate start permissions to the processes. Please take note: It is recommended that, should you wish to use the Comments and Attachments components that ships with Springboard for K2, you will need to assign VIEW permissions to all users. If not, users that open the forms linked to Worklist items will be shown an exception on screen that they do not have permissions to view the comments or attachments. Roles You are required to add at least a single person (but you are also allowed a group) to the following two roles. If this is not done, the K2 server will log an exception to the event log periodically stating that it couldn’t resolve the role.

  • Purchase Request Approvers
  • Purchase Request Additional Approver

The Springboard Modules for K2 version 1.1 package contains items specific to K2 blackpearl 4.6.11. If you are seeing this error, it means that you are attempting to deploy the package to K2 blackpearl 4.6.10. Please download Springboard Modules for K2 version 1.0 and deploy the package again.

The main transactional SmartObjects behind Springboard Modules for K2 are:

  • K2ANZ.Framework.Transaction.Application.Instance
  • K2ANZ.Framework.Transaction.ActivityLog
  • K2ANZ.Framework.Transaction.BusinessAudit
  • K2ANZ.Framework.Transaction.ExceptionLog

K2ANZ.Framework.Transaction.Application.Instance The application instance is the primary SmartObject instance which will need to be created when an instance of any application registered with Springboard Modules for K2 is started. E.g. Purchase Request is listed as an Application with Springboard Modules for K2 and the Purchase Request application form can be opened from the Springboard Modules for K2 dashboard. When a new Purchase Request is created, the following will occur:

  1. A new record will be added to the Purchase Request SmartObject. This will return a Purchase Request ID.
  2. We then create a new Application Instance. To this Application instance, we provide the Application ID, the Purchase Request ID (to be saved in the Business Object Id column) and some other information. This will return an Application Instance ID.
  3. We now start the Purchase Request Process. To the process, we simply provide the Application Instance ID. The process will return a Process Instance ID.
  4. Lastly, we update the Application Instance with the Process Instance ID. As a result, the Application Instance has context to: a. The Application itself (details to the Purchase Request in general) b. The Purchase Request Id (all data saved for this specific Purchase Request) c. The K2 Process Instance ID

K2ANZ.Framework.Transaction.ActivityLog The activity log is used to track any activity the user wishes to track on a form. E.g. if you wish to log a user accessing to a form, or deleting records, you will save this information into the Activity Log SmartObject. Note that the activity log is not bound to an Application or Business Object Instance. K2ANZ.Framework.Transaction.BusinessAudit Business Audit Data is used to store specific data which you are required to audit linked to an Application Instance. E.g. when a user performs an action on a worklist item, you can store an audit of the action taken. K2ANZ.Framework.Transaction.ExceptionLog Any error that happens on Springboard Modules for K2 forms are logged to the Exception log. Custom exceptions could also be logged against this table. Exceptions are listed in two different lists – one will show “new” exceptions, and the other will list all acknowledged exceptions. The difference between the two is an acknowledged flag on the record.

There are 3 templates forms which are shipped with Springboard Modules for K2. These templates are called:

  • K2ANZ.Framework.Template
  • K2ANZ.Framework.Template.StartProcessPage
  • K2ANZ.Framework.Template.ActionWorkItemPage

“Template” is used for simple forms that have no integration to a K2 workflow process.

Template.StartProcessPage and Template.ActionWorkItemPage are for integrating Springboard Modules for K2 with a K2 workflow process; to start a new process instance and to act as a client event respectively. Before starting work on a new form, please select the template you wish to use, and select “Save As…” to create a NEW instance of the form. Pick an appropriate name and location to save the form to. Once done, start editing the new for you created based on the template. Note: Do not change anything on the template form. Only make changes to the new form you have just created. Edit the Rules behind the form. All three templates have some common components, such as “Form Initialize” and “Form in Error” rules. The StartProcessPage has some additional rules to create a new instance of your business object and the application instance, along with rules to start a workflow process. The ActionWorkItemPage has logic to load a Worklist Item, and also the functionality built in to action a worklist item.

When the Action Work Item Page loads, it passes the Serial Number of the Worklist Item to the K2ANZ.Framework.Workflow.TaskAction.Item View. When this View loads, it adds all available actions from the Worklist Item to a drop down list. There is a hidden button on this view to action the worklist item using the Serial Number. When the user chooses to action the item, the needed updates to the various SmartObjects (like the business object, data audit etc.) must be done. Then, execute the hidden button on the K2ANZ.Framework.Workflow.TaskAction.Item View to action the work list item.

  • Portal Site
  • Process Templates Reusable Forms
  • Process Reporting
  • Integration Components Solution Framework
  • Best Practices
  • K2 Development Methodology, Accelerated Solution Delivery
  • 44 SmartForms, 113 Views, 55 SmartObjects
  • 3 Processes: Simple Task Allocation Process and Purchase Request Process
  • In excess of 25 years’ experience involved
  • Saving you at least 4+ weeks of development time.

The package for Springboard Modules for K2 V1.2 was built using K2 blackpearl 4.6.11, where V1.0 was build using K2 blackpearl 4.6.10.Springboard Modules for K2 V1.1 used the original package created on K2 blackpearl 4.6.10 and then made changes to it to include updated components using K2 blackpearl 4.6.11. As such, the file retained older references required by K2 blackpearl 4.6.10. When the package for Springboard Modules for K2 V1.2 was build using K2 blackpearl 4.6.11, it meant that file size would be less due to significant enhancements made by K2.

Due to the architecture of Springboard Modules for K2, you won’t be able to use anonymous forms with any of the existing forms and applications, as they all require the current logged on user’s information. However, you can use certain elements of Springboard Modules for K2 with anonymous forms. E.g. This website uses anonymous forms and was built using Springboard Modules for K2. Please visit the K2 Help Portal for more information regarding Anonymous Forms, and everything to consider when using it.

Download this “How To” document. This document explores the architecture of Springboard Modules for K2, along with a step by step guide to create a new standalone application and creating an application that integrates with a K2 blackpearl workflow process.

Make sure the Swagger Descriptor URL is correct and active. Confirm that the API key is correct with the correct serialized header object.

By starting an incognito browser session we get a separate cookie session and then leverage that to log in as the differentdomain.com account which has K2 server rights. From there:

1) Go to K2 Management with someone who can access the Management Site

2) Drill down into Workflow Server>>>Server Rights

3) Add the other account to the Server Rights list and give it Admin, Export and Impersonate rights.

Navigate to Roles and add user as security admin and Deployment Roles.