K2, PowerApps and Flow: When and Why?

Since Microsoft released PowerApps and Flow in 2016 there have been a lot of questions about how these new tools compare with K2.

Do PowerApps and Flow do the same things as K2? Are PowerApps and Flow a competitor to K2. Can they be used together?

For businesses making the important decision on what process automation platform to use, these are relevant and critical questions. If you are an Office 365 customer you may already have PowerApps & Flow available, and you will need to evaluate these tools to see if they meet your needs.

At the first glance, PowerApps and Flow display a list of similarities when doing a feature comparison with K2. Both offer connectors to allow you to get data from your business systems, a forms designer and a workflow engine.

Both can also be classified as low code platforms.

However, there are a few key points of difference between PowerApps/Flow and K2 that you need to consider before embarking on your process automation journey.

While it will take thousands of words to describe all differences, this introductory article will focus on two of the most obvious differences.

Firstly, K2 has more a more advanced design experience in most areas of the stack, making it faster and easier to build more complex form and workflow scenarios to address the business problem at hand.

Secondly, and most importantly, K2 is a mature Business Process Management (BPM) platform, which means that it not only offers the tools to build more advanced process automation applications, but it also has tools to manage and analyse your applications. This is a very important consideration in evaluating automation platforms that can get overlooked.

Let’s explore these two points of differentiation in more detail.

Design and Build Experience

I am not going to dive into a detailed technical feature comparison between PowerApps/Flow and K2 for a couple of reasons.

One is that the landscape for both platforms is constantly evolving, with more features being added for both all the time, making a comparison done today redundant tomorrow.

The other is that when assessing the suitability of a toolset it is more important to look at the type/s of process automation application you are looking to build.

What do I mean by “type/s of business process applications”?

The following diagram provides a useful reference point for answering this question. The process-driven application landscape/framework below leverages some of the application portfolio management concepts in Gartner’s Pace-Layered IT Strategy as outlined [1]

According to Gartner:

  • Systems of record — Established packaged applications or legacy homegrown systems that support core transaction processing and manage the organisation’s critical master data. The rate of change is low because the processes are well-established and common to most organisations, and often are subject to regulatory requirements. Systems of record have the longest life cycle, at 10 or more years.
  • Systems of differentiation — Applications that enable unique company processes or industry-specific capabilities. They have a medium life cycle (one to three years) but need to be reconfigured frequently to accommodate changing business practices or customer requirements.
  • Systems of innovation — New applications that are built on an ad hoc basis to address new business requirements or opportunities. These are typically short life cycle projects (zero to 12 months) using departmental or outside resources and consumer-grade technologies.

In the context of K2:

  • “Systems of Record” applications, which includes large business systems like SAP & Oracle (ERPs) are pre-packaged vertical applications which cost a lot to purchase, implement, and extend. Implementation of systems in this layer tends to be strongly IT led and often involves the software platform vendor by necessity. K2 can quite often fill some gaps in this space, for example by providing an alternate user interface for your SAP system and integrating it with other systems. These systems typically have rigid and tight business processes built into the system (for good legal and compliance reasons). Still, within the System of Record context, some organisations also choose to use K2 as the enterprise workflow layer in large-scale line-of-business system type, custom development projects.
  • “Systems of Differentiation” applications meet reasonably complex business needs that require integrations into other business systems and flexible reporting. These applications are typically developed to automate a business process which will provide the business with some competitive advantage, whether it be cost reduction, better customer experience or better decision making. Valuable intellectual property that differentiates the organisation from its competitors often lives in this application layer in organisations. Implementation of applications in this layer tends to involve business, IT and external consulting assistance as necessary. K2 plays very well in this layer, allowing business applications with medium and high complexity level workflow logic, sophisticated forms and advanced data integration to be built quickly with little or no code.
  • “Systems of Innovation” applications are typically simple workflow and/or form applications that solve a specific business need across a team or department. These applications are usually developed by individuals within the team or department and are cost effective to implement using widely available toolsets. This is also referred to by many as “citizen developer” type activity in organisations. With specific reference to the use of technologies like PowerApps, Flow, IFTT, and Zapier, we also see a rising trend around the creation of Personal Productivity Applications in this layer in organisations.

 

As the diagram above illustrates, K2 can play a meaningful role in any of these application layers, but its main strength lies in the “Systems of Differentiation” layer. PowerApps and Flow are mainly used in the “Systems of Innovation” layer.

One reason for this difference is that the K2 platform allows you to more easily design the medium and high complexity workflows and forms that “Systems of Differentiation” demand than PowerApps/Flow. Flow is designed to solve “If This Then That” type workflow problems. For example: “if a new account is added to a CRM system, then send an email”. Flow also does simple data orchestration well, using its large number of connectors it can respond data being created or updated in one system and then create or update data in another.

Flow can be very useful for personal or team-based workflows, such as sending notifications or reminders. However, when requirements start getting more complex – things like rework patterns, parallel paths, sub-workflows, multiple user actions (beyond approve & decline) and task escalations – implementing these in Flow often becomes quite difficult, where K2 can handle these with ease.

PowerApps is a “mobile first” forms platform, primarily used to capture and display data for a single data object (e.g. a SharePoint List). When you want to start doing things like creating complex user interfaces for desktops and mobile (e.g. displaying/updating from multiple data sources on different tabs, offline forms and sharing forms with external users) PowerApps often hits limitations that may be difficult to overcome without significant workarounds or custom development.

K2 uses a simple declarative form rule to drive form behaviour, whereas PowerApps requires Excel-like formulas to be used. Another aspect to consider is the ability in K2 to create reusable objects. K2 Forms, Views, SmartObjects, and Workflows can all be re-used in K2 across multiple applications, reducing your build time and making updates quicker and easier.

A final, and very important, consideration with respect to the design experience, is the management of the application development lifecycle. In K2 you can build an entire application (Forms, Views, SmartObjects and Workflows) and package that up and deploy to a test or production environment in a few clicks.

This is a powerful feature that lets you totally segregate your development, test and production environments and have full control over the deployment process and application development lifecycle.

I am sure we all know by now that almost anything is possible with most development platforms given enough time and energy. In practice, choosing the appropriate tool for the job is often the difference between success or failure though.

Process Management

So, you have built a business-critical process-driven application, released it into the wild, and it starts getting used in anger. Soon, the business starts asking questions like “How many workflow processes are running right now?”, “What happens if someone is on leave and cannot approve an urgent request?”, “By who and when was a particular request approved?”.

This is when having the tools and features that a proper BPM platform come in very handy.  K2 offers a comprehensive set of functionalities to manage your processes, including:

  • Out of Office notifications
  • Task list for all workflows
  • Task escalations
  • Task redirections and sharing
  • Working Hours
  • Workflow permission management (who can start, administer and report on workflows)
  • Workflow error management
  • Workflow version management
  • Workflow instance management – starting & stopping workflow, go to specific workflow steps
  • Workflow Reporting – workflow analysis and insight
  • Centralised and secured management interface
  • Design Permissions – control who can build and deploy applications

Microsoft PowerApps and Flow working with K2

A final thought to consider when looking at K2 and PowerApps/Flow is that they can actually work together quite nicely when building an automation application, utilising the strengths of each platform.

Take the example of a CRM system and an onboarding process for new accounts. A user can add a new account directly into the CRM system, however for the account to become active, we need an onboarding process to occur that involves verification from different business departments and data from other systems.

This workflow might have a parallel approval pattern with rework steps and inputs required from other systems (e.g. the account is added to the Finance system and the new account ID is input back into the CRM system by the finance team.). To implement this application, we need to monitor the CRM system for new accounts, and when one is added we need to start a reasonably complex account onboarding workflow.

Now, we could try and do all this using K2, or similarly by only using Flow/PowerApps.

To trigger the K2 workflow for account onboarding from your CRM system will probably require some sort of custom development in that system – not something you really want to do, but possible.

On the other hand, trying to create a Flow and PowerApp that implements the account onboarding process will quickly become very difficult and complex. In addition, you don’t get the additional benefits of things like task lists, out of office task redirection and task escalations. As the kid on the Old El Paso advert says, “porque no los dos?” (Why not both).

We could also expose the new account form in CRM as a PowerApp, allowing users out on the road to use their mobile device to add new accounts on the run. We could then use Flow connectors to monitor our Salesforce or Dynamics system for new accounts – there are out of the box connectors for these systems that are relatively simple to set up in Flow.

We could then use an action in Flow to start a K2 workflow to start a more complex business process to onboard the new account (involving legal and finance teams, and other LOB systems).  A Flow connector for ease of integration with K2, is available [2].  K2 SmartForms can be used as the task forms, exposing data from not just the CRM systems but other business systems as well.

This hybrid application approach is playing to the strengths of both platforms. Flow gives us the nice and easy way to monitor our line of business system by providing loads of connectors, PowerApps provides a mobile form for new account submission, and K2 gives us both an enterprise-grade workflow engine that can easily handle complex scenarios, and a user interface to allow task completion, as well as all of the other baked in platform, features such as task management and process reporting.

While Flow and PowerApps are constantly evolving and getting more and more features, the types of business problems they are focussed on solving are fundamentally different from the ones that K2 is aimed at. And while there is of course cross-over in the terms of functionality, you need to look at what type of business application you are building based on the application portfolio management approach chosen by your organisation. (i.e. is it a System of Innovation or Differentiation etc.?). Lastly, find a toolset that can deliver for not only your technical requirements but also provides features to let you manage your processes.

[1] Pace-Layered Application Strategy and IT organisational Design: How to Structure the Application Team for Success

[2] Microsoft Connector – K2 Workflow

Join the webinar on October 11th, 2018 at 3PM AEST to see a comprehensive overview of PowerApps and K2 and how when they work together to build an automation solution.

Register now

 

K2 Cloud and Azure Function Apps

If you are looking at K2 Cloud or already using it, you will most likely be aware that you cannot create or use custom service brokers in this version of K2 (you can still do this in K2 Five). So, what do you do if you need to execute some custom code in K2? Azure Functions could be your solution. 

Azure Functions enable you to run code-on-demand without having to provision your own infrastructure. Functions can be written in a variety of languages (e.g. C#, JavaScript, Python) and can respond to a variety of events (e.g. HTTP Trigger, Service Bus Queue Trigger). As a K2 Cloud customer, you have an Office 365 subscription, which means you will also have an Azure subscription so you can get started with Azure Functions without any setup (See An introduction to Azure Functions for more details, including information on pricing) 

So how can you incorporate Azure Functions into your K2 solution? 

K2 and REST 

K2 now has a REST Service broker that allows you to integrate K2 with REST-based web services. A good explanation of what REST (REpresentational State Transfer) web services are can be found here. 

The REST broker is the key to working with Azure Functions. The K2 REST service works by reading a service “descriptor” file, called a swagger or OpenAPI file. A swagger file describes the methods and properties that a web service exposes, allowing K2 to create matching SmartObjects. I will provide options below on how to create the swagger file for our function. 

Azure Function Example 

Let’s look at a simple function example. Say as part of a solution you need to convert a number to character/s. So, for example, 1 becomes “A”, “2” becomes “B”, “26” becomes “Z”, “27” becomes “AA” and so on. You could try and do this with functions and expressions in a K2 form or workflow, but it would get quite complex. Or, you could write some code that does this, deploy it as an Azure Function and call it from K2 as a SmartObject. 

Here is some code that does what we need. It looks for a query parameter named “Number” and then uses a while loop and the modulo function to convert the number to characters.  

using System.Net; 

 

public static async Task<HttpResponseMessage> Run(HttpRequestMessage req, TraceWriter log) 

{ 

 log.Info("C# HTTP trigger function processed a request."); 

 

 // parse query parameter 

 string strNumber = req.GetQueryNameValuePairs() 

 .FirstOrDefault(q => string.Compare(q.Key, "Number", true) == 0) 

 .Value; 

 

 int dividend = int.Parse(strNumber); 

 string columnName = String.Empty; 

 int modulo; 

 

 while (dividend > 0) 

 { 

 modulo = (dividend - 1) % 26; 

 columnName = Convert.ToChar(65 + modulo).ToString() + columnName; 

 dividend = (int)((dividend - modulo) / 26); 

 } 

 

 return req.CreateResponse(HttpStatusCode.OK,columnName); 

}  

So how do we use this code in an Azure Function?

The first thing to do is open your Azure Portal and click the “Create a resource” button and choose “Compute” and the “Function App” 

Add the Function “App name” and set the other details. The Function App is a container for a number of functions – you can add more functions to your Function App later. You may need to create a Resource Group (see Manage Azure resources through portal for more info) if you do not have one you can use. 

Once you hit “Create” Azure will provision you with your function app and you will see the following  

 

Select “Go to resource” and start to edit your function app. 

We are going to choose to use the “Webhook + API” and “CSharp” option. We are using the webhook as this will let us trigger the function by an HTTP call. You can use any programming language you are comfortable with. 

A default function is created for you. Replace this function with the code above. You can then test this function by clicking the “Run” button. Add a number into the “Number” Query Parameter, click the “Run” button at the bottom right and view the result in the Output pane. Note that the log file also shows some entries indicating if the execution was successful, and outputs our “Log.Info” line from the code. 

Ok great, our function works, now how do we consume it in K2? 

Create Swagger File 

There are two choices for creating the swagger file. You can create a template in Azure and then manually update it, or create one from scratch from a tool like REST United (see Resources for Working with the REST Service Broker). 

I will not go into detail on how to create the swagger file, but have include a definition for the GetCharOfNumber function at the end of this post. 

(For a more detailed walkthrough of these steps see Create an OpenAPI definition for a function) 

To get a swagger template for your function app, expand your function and select the Integrate option, and make sure the “Get” HTTP method is selected. Set your “Authorization level” to anonymous for this exercise, and click “Save”. 

Now click on your Function App and select the “API definition” menu item. 

Click “Generate API definition template”, and the swagger template is generated for you 

You can now copy the template out into another editor or edit it directly in the azure portal.  

Once you have created your swagger file, you can choose to host it back in the Azure portal, or in any other location accessible by your K2 Cloud instance. 

If you want to host it back in Azure, you can overwrite the template with your swagger and Save. The API Definition URL can then be used when creating your REST service instance.

Create REST Service Instance 

Open K2 Management and create a new REST Service instance. Add in the swagger location into the Descriptor location and use the Service Account as the Authentication Mode. All other settings can be left as default. Click the option to generate the SmartObjects (or leave unticked and create later) and then Ok to create the service instance. 

Once the SmartObject is created, it’s time to test it. Find it under the Categories in the Management site and execute the “GetCharOfNumber” method.  

{ 

"swagger": "2.0", 

"info": { 

"title": "Azurewebsites", 

"description": "API for <yourfunctionappname>.azurewebsites.net", 

"version": "0.0.0" 

}, 

"host": "<yourfunctionappname>.azurewebsites.net", 

"schemes": ["https"], 

"paths": { 

"/api/GetCharOfNumber": { 

"get": { 

"tags": ["Web"], 

"description": "Get char of number", 

"operationId": "GetCharOfNumber", 

"produces": ["application/json"], 

"parameters": [{ 

"name": "Number", 

"in": "query", 

"description": "Number", 

"required": false, 

"type": "string", 

"x-example": "445" 

}], 

"responses": { 

"200": { 

"description": "OK", 

"schema": { 

"type": "string" 

}, 

"examples": { 

"application/xml": "<string xmlns=\"http://schemas.microsoft.com/2003/10/Serialization/\">QC</string>" 

} 

} 

}, 

"security": [] 

} 

} 

}, 

"securityDefinitions": { 

 

}, 

"security": [], 

"tags": [{ 

"name": "Web", 

"description": "Operations about Web" 

}] 

}

K2 Cloud Update 5

 

This webinar will provide an in-depth overview of the capabilities of the new K2 Five and K2 Cloud.

During this session we will focus on:

• K2 Smartbox enhancements;
• SharePoint dynamic URL’s;
• K2 Cloud external users; and
• K2 multiple authentications.

Showcase: K2 and Adobe Sign

 

 

eSignatures are becoming more and more popular with businesses as they try to create a competitive advantage and complete business transactions faster.

With eSignature technology like Adobe Sign, you can obtain signatures from your staff and customers within minutes instead of days, and signatures can be obtained on any device. eSignature technology is a perfect fit for a Business Process Management platform like K2, allowing you to automate the collection of signatures as part of your business processes such as sales orders, employee onboarding, and contract creation.

While there is no Adobe Sign feature available for K2 (yet…) we can still integrate with K2 using the Adobe Sign REST API. This article will describe the steps required to integrate K2 with Adobe Sign, including:

  1. Create the Adobe Sign Developer Account and configuring OAuth
  2. Create the swagger file against the Adobe Sign REST API Reference
  3. Create an OAuth resource and resource type in K2
  4. Create the Adobe Sign Service Instance and generate SmartObjects
  5. Using Adobe Sign in your K2 applications

Adobe Sign Developer Account

To get started with Adobe Sign create a developer account. Once your account is created and verified, the first thing you will need to do is create an API application for your Adobe Sign account. Select API Applications under the API menu to create a new application.

Give your application a useful name and display name, and select the Customer option for Domain.

Once created, select your application and click the Configure Oauth for Application link. On this page, you will need to copy your Client Secret and Client ID for later use. You will also need to enter a Redirect URI and select the required scopes.

Your redirect URL will be in the form:

https://<k2 server name>/identity/token/oauth/2

Be careful as this URL is case sensitive. You can add multiple URIs by comma separating them.

Adobe Sign and REST/Swagger

To use the Adobe Sign REST API in K2 you will need to create a swagger file. Swagger files are used to describe the service, and K2 uses these files to create the service objects when you create a REST service instance.

There are many ways to create a swagger file (for example you can do it manually using an online editor like swagger.io). The example below uses REST United, an online tool that uses wizards to generate REST API Libraries.  REST United offer a free account that can be used to generate swagger files.

Before you start, it is important to find the Base URI for your location. You will need the Base URI to ensure you enter the correct path in REST United.

Open the API Reference and find the base_uirs operation. Click the button to create an OAuth resource token and click the Try it Out button. You will need the api_access_point from the response.

Open REST United and select REST API -> New REST API Wizard

Enter an endpoint URL (see the API reference), ensuring you select the correct method (e.g. GET) and use the base URI you obtained above. The wizard will work out the Base URL. Enter a useful Method Name. Don’t enter a response body yet, and leave “Authentication” as none. We will look at authentication later, but for now, we can ignore it as K2 will take care of this for us.

On the next page of the wizard, you can add any more parameters.

If you added a path parameter in the Request Path this will automatically be created for you. Check the API reference for the parameters you need. Ignore the “Access-Token” header parameter – K2 will create this for you automatically when we use the OAuth authorisation type for the service instance.

Click Next to get to the Response Page. Here you can paste in the example response. Get the example response from the Adobe Sign API reference by clicking on Model Schema.

Paste the example in and click the button “Guess Response Type using Example Response”

 

REST United will create Models for you based on the sample.

**TIP** Use the same name for your Model as the Model Name in the API Reference. This way your SmartObjects will be named the same, making life easier when trying to work out what SmartObject methods to call.

Be careful at this step as the response type may not match the Model you just created

You will need to come back later to select this, as it will not be immediately available (don’t ask me why!)

Click Next to get to the Test page. You won’t be able to test as you do not have an OAuth token.

Click Next again to get to the Release SDK page. Here you can click On Endpoint to add more endpoints, or select Test and Export to generate the swagger.

The 2 REST operations that you will need to send an agreement are:

Type Operation Description
POST /agreements Creates an agreement. Sends it out for signatures, and returns the agreementID in the response to the client
POST /transientDocuments Uploads a document and obtains the document’s ID.

To generate the swagger simply select the Swagger option and click Export to download the file.

You will need to host the file somewhere the K2 server can access (such as the K2 server file system, or for Cloud on an Azure file storage).

When you create your REST service instance enter the address for the Swagger file in the Descriptor Location.

 

Adobe Sign and OAuth

The Adobe Sign REST API requires an OAuth Access Token to authorize each REST operation (more details can found here). OAuth is “an open protocol to allow secure authorization in a simple and standard method from web, mobile and desktop applications” 1. The details of how OAuth works are beyond the scope of this post, however, what is important to know here is that K2 has a mechanism to allow you to use OAuth so your users can seamlessly authenticate with your providers that use OAuth. You may have noticed that we did not need to add in the “Access-Token” header parameter in our swagger file. That is because when we use to create service instance with OAuth as the authentication mode K2 takes care of obtaining and adding this parameter to all smartobject method calls.

The following steps outline how to set this up for Adobe Sign.

The first step is to create a Resource Type and Resource in K2 Management.

Under the Authentication Node in Management select OAuth->Resource Types.

Add a new Resource Type called “Adobe Sign”

Then add the following resource parameters:

Then click on the Resources node and click New under Resources and add a new Resource.

Take care with the region part of the URL (e.g. au1) as this might be different for your region. You can get you full path by calling the base_uris method (see https://secure.echosign.com/public/docs/restapi/v5)

Then add in the parameter setting, using the client id, client secret and redirect URI you got from the Connect application. For the scope you need to enter the scopes required as space-separated values, e.g. user_login:self agreement_send:account user_read:account agreement_read:account agreement_write:account widget_read:account widget_write:account

Name Authorization Value Token Value Refresh Value
client_id <your client id> <your client id> <your client id>
scope <scopes required>
redirect_uri <your redirect uri> <your redirect uri> <your redirect uri>
grant_type authorization_code refresh_token
client_secret <your client secret> <your client secret> <your client secret>
response_type code

Once this is done you can now use this Oauth resource when creating your service instance.

 

When you create the service instance you will get a message that you need to redirect for authentication.

You will be directed to the Adobe Sign login page. Once you have logged in you will be asked to accept the scopes you asked for, and then the authorization token will be created and returned to K2.

K2 securely stores these for you-you can find them under Authentication -> OAuth -> Tokens in Management if you need to delete them for any reason.

The good news is that K2 also takes care of refreshing the token for you if it expires (the token has an expiry of one hour) so you don’t need to keep re-authenticating.

When creating the service instance you can tick the option to create the SmartObjects. If you don’t select this option you can either click the button to Generate SmartObjects on the Service Instance list or create them manually.

Using Adobe Sign in your K2 Application

Once you have completed all the above steps and created your SmartObjects, you are ready to use Adobe Sign in your K2 applications

Adobe Sign uses the concept of an Agreement to manage document signing. An agreement contains one or more documents and one or more recipients.

The basic process for sending a document for signing with Adobe Sign is as follows:

  1. Upload a document/s
  2. Add the recipient/s
  3. Create an Agreement

You can create “groups” (called Recipient Sets) of recipients, with multiple recipients in each group. You can then indicate if you want all recipients in a group to sign, in which case they will be asked to sign in order, or just one.

Let’s look at the basic steps to create a form like the following that will allow a document to be sent to multiple signers.

Notes:

  • you could also do some or all of these steps in a workflow if needed.
  • Your smartobject names and methods may differ from those below. If you followed the naming of your models using the API names then the smartobject names should match.

The first we will do is to upload a document.

You should have a “TransientDocumentId” SmartObject with an UploadDocument method (otherwise find your SmartObject that has this method). This method accepts a File_Name and File (document).

The output from this method will be a “TransientDocumentId” text property. You will need to store this somewhere for later use.

Next, you will need to add the recipients. This step involves serializing each recipient to a typed array and then adding these recipients to a Recipient Set. Note that the following steps will result in a single “Recipient Set” containing all recipients, with only one required to sign. If you need all recipients to sign you will need to create a “Recipient Set” for each recipient.

If you are using a list for recipient emails, loop through the list and add each recipient to a typed array (using a data field to store the updated value).

Finally, create a Typed array of RecipientSetMembersInfo and store in a data label.

The next step is to create the FileInfos object that stores the documents. Call the Serialize Add Item To Array method of the FileInfos SmartObject passing in the document id obtained earlier, and store the output in another data field.

The next step is to create the DocumentCreationInfo using the Serialize method on the DocumentCreationInfo SmartObject. Check the API Reference for valid values for Signature Flow and Signature Type. Store the output in a data label.

Next, you need to create the AgreementCreationInfo using the Serialize Method of the AgreementCreationInfo SmartObject. Pass in the DocumentCreationInfo created in the previous step, and store the output in a data label.

Note that some of these SmartObject methods could be chained together to reduce the number of methods called and make the process simpler. I have chosen to do each step individually to make it easier to describe each step.

Finally, create the Agreement. This will send the document for singing. Using the AgreementCreateResponse SmartObject call the CreateAgreement Method, passing in the AgreementCreateInfo created in the previous step. You can store the output from this method if necessary.

Technical Deep Dive: Elevate your K2 Cloud experience using Microsoft Azure

 

 

Transitioning to K2 Cloud calls for a different approach in Business Application Development on the K2 Platform.

During this video, John will be showcasing how to leverage Microsoft Azure and modern industry standards to fill the technology gap and better enable Business Application Delivery.

During this video the content will focus on:

• Javascript Custom Controls for K2 forms
• K2 form styling using CSS
• Third party integrations for K2 Five and K2 Cloud

Showcase: Google ReCAPTCHA & K2

 

 

Have you ever been to a website, and before you can submit or view information, you have had to verify that you are not a robot?

While this might be a bit annoying (of course you are not a robot!) there is a very good reason for doing this – to stop automated software, or “bots” from abusing the website. There is any number of “bad actors” out there who would like to exploit weaknesses in your site.

To try and sort the humans from the bots, CAPTCHA was invented as a way of testing who you were: man or a machine. CAPTCHA is an acronym that stands for Completely Automated Public Turing Test to Tell Computers and Humans Apart.

In the bad old days CAPTCHAs were usually images of squiggly text or numbers that you had to read and type into a text box, like the image below. They were not very friendly or pretty.

In 2009 Google acquired one of the CAPTCHA systems called reCaptcha. In the words of Google:

reCAPTCHA is a free service that protects your website from spam and abuse. reCAPTCHA uses an advanced risk analysis engine and adaptive CAPTCHAs to keep automated software from engaging in abusive activities on your site. It does this while letting your valid users pass through with ease.

reCaptcha is more user-friendly, asking users to verify you are not a robot by showing the user squares of images, and asking the user to select ones that meet a criterion, such as those having a street sign in them. You first tick the “I’m not a robot” box and then complete the test.

So, if you have a public facing website that allows users to view or submit information, you will probably be interested in stopping bots from running amok by using something like reCaptcha. What if your publicly facing form is using K2. Not to worry, you can quite easily add reCaptcha to your K2 forms.

The first thing you will need is a google account. If you don’t have one, visit Google and create one.

Then visit the reCaptcha site and click on the Get reCaptcha button and enter your Google login details.

Once you have logged in you will need to register your site. Give it a label and select the reCaptcha V2 option. You will need to enter the domain name for your K2 site (e.g. denallix.com) 

Once you have done this you will be shown the information needed to add reCaptcha to your site.

To add reCaptcha to your K2 form follow these steps:

  1. Create a new view (e.g. named “Google.Recaptcha.Verify.Item”)
  2. Add a data label to the view named “Recaptcha Script Data Label”
  3. Add an expression to your data label and add the following script to the expression, taking care to replace the highlighted value with your site key obtained above

<script type=”text/javascript”>var recaptchaCallback = function(response) {$(‘span[name=”Result Data Label”]’).SFCLabel(“option”, “text”, response);};</script><script src=’https://www.google.com/recaptcha/api.js’ ></script> <div class=”g-recaptcha” data-sitekey=”<your site key>” data-callback=”recaptchaCallback”></div>

  1. Make sure you mark your data label as a literal
  2. Add another data label called “Result Data Label”

At this point you can run your view, and you should be able to verify you are not a robot. When you are verified your Result Data Label should have a long string in it:

Great! You have verified you are not a robot, however, this is only half the story. Even though Google has returned a response (that long string), you have not fully verified. This is because you need to send that response off to Google now and get back a final confirmation.  To do this you will need to call Googles https://www.google.com/recaptcha/api/siteverify URL. The best and easiest way to do this is via a K2 REST service.

To create a reCaptcha REST service instance you will need a swagger file. A swagger file describes the service and is used by K2 for it to create the Service Instance and related Service Objects. The quickest and easiest way to create this is by using a service like REST United.

There is only one endpoint needed –  the following images describe the steps to create it in Rest UNITED.

Once you have the swagger file (you can export this from RESTUnited, go to Test & Export, select Swagger and then Export) place it on a location (i.e. file share or website) accessible by K2.

You can now create a new REST Service Instance and add this location to the “Descriptor Location” setting for your service instance.

Once your Google reCaptcha service is created, you can generate the SmartObject you need to perform the verification. The Service Object you need will be called “ValidationResponse” if you followed the steps above for creating the swagger file in RESTUnited. You can ask K2 to create the SmartObject for you by using the “Generate SmartObjects” button on the Service Instances page in Management.

This SmartObject will have a single “Verify” method that you need to call. This method takes two parameters: secret and response. The secret parameter maps to the “secret key” that was generated for you by Google when you registered your site. The response parameter is the long string that was returned to your “Result Data Label”

Instead of having to add the “secret” parameter in every time you call this “Verify” SmartObject method, you can add it in as a specific value in the SmartObject method definition. Edit the SmartObject method and choose to bind “secret” to a specific value, and paste your secret key in (don’t worry if K2 reports the value as “undefined” as per the image below, it will retain the value).

Now when you call this method on your form you do not need to pass the secret key in.

So now you can complete the final piece of the puzzle, and send Google your response and secret and get verification that the user is not a robot!

  1. Add a new data label to your view called “Recaptcha Valid Data Label”. Optionally you can add another data label to hold any error codes returned by the verify call (e.g. add an “Error Codes Data Label”)
  2. Add a new unbound rule to your view called “Verify Recaptcha Response” and add an action to call a SmartObject method
  3. Select your “Validation Response” SmartObject created above and the “Verify” method.
  4. Configure the action and map the “Result Data Label” to the “response” input parameter, and the “Success” property to the “Recaptcha Valid Data Label” in the output mappings.

  1. You can now finish this view and add it to a form. On your form you can now call the “Verify reCaptcha Response” rule in response to an event on your form, such as a button click. You will first want to check that the “Result Data Label” has a value, so that you can tell if the user has tried the reCaptcha verification. Once you have called the rule to verify the response you can check the value in “Recaptcha Valid Data Label” to see if is true (passed) or false (failed), and then act accordingly.

You now have a re-usable view and pattern for implementing Google reCaptcha on any of your K2 forms!

On Demand: K2 Cloud + K2 Five Overview

 

Late last year we launched the K2 Five and K2 Cloud platform.

The rate of updates to the K2 Cloud has been impressive with new enhancements and features added every 3 to 6 weeks. ​​​​​​​ In order to help keep up-to-date with the new enhancements, we would like to start a bi-monthly webinar to overview these new capabilities and enhancements.

This video will provide an in-depth overview of the capabilities of the new K2 Five and K2 Cloud.

During this video we will focus on:

Highlight the key feature changes and updates from K2 4.7 Demo the new simple K2 drag and drop designer Differences between the on-premises and cloud versions of K2 How to integrate both of these into Power BI using the new OData providers.

SmartStarters and Application Wizard for K2 Cloud

The latest update of K2 Cloud includes a couple of new features that make creating new K2 apps as simple as few mouse clicks! Empower your business users by allowing them to create their own apps by taking advantage of these great new features.

K2 SmartStarters are ready-to-use applications for common use cases like IT Service Requests, Job Postings, and Task Management. SmartStarters are fully built solutions that you can deploy and have up and running in minutes. These solutions are fully customisable, so you can run them as is, or update to suit your needs.

The K2 Application Wizard allows you to quickly create K2 applications via a wizard that will generate the application for you. You can build customised applications like a Marketing Collateral Approval process or a Customer Satisfaction Survey in just 4 simple steps.   The Application Wizard is the perfect solution for the business user who just wants to create a solution without having to know how to build SmartObjects, views, forms, and workflows.

Both the SmartStarters and Application Wizard are available from the new Apps page in the K2 Workspace. Let’s have a look at each option in more depth.

 

SmartStarters

At the time of posting there are 26 different SmartStarters available for install, including for common business processes like IT Service Request, Training Request, and Travel Approval (see Creating Applications with SmartStarters for a full list and detailed instructions on deploying).

Use the “Install” button on the “All Apps” page to select a SmartStarter application

A list of available SmartStarters will be displayed.

Click the “Details” button to view the SmartStarter application. Here you can see what the application form and workflow looks like

Click the “Install” button to start the install process. A popup will appear showing you the app download and install progress. Allow a minute or 2 for the application package to be downloaded and installed. After the application has finished installing, you will be given options to configure the application.

Each SmartStarter comes with its own landing and administration pages.  The administration page will allow you to modify any lookup data or user groups used by the application forms and workflow.

Once your SmartStarter is installed and configured it is ready to go!

From the landing page, you can submit a new form and start the workflow process. But what if the form fields are not exactly what you want, or the workflow does not match your own businesses process? The great thing is that these apps are fully customisable. Simply find the app in the designer (Under Apps->K2->SmartStarters) and you can edit the SmartObjects, Views, Forms, and Workflow to suit your requirements.

 

Application Wizard

You can use the Application Wizard to generate a new application from a pre-defined template or select the option to create your own custom app. The application templates currently available are categorised under the application types Submit for Approval, Send a Survey and Create and Edit Lists (see Creating Applications with Application Wizards).

To create a new application using the Application Wizard we open the Apps workspace and click on the “New” button in the “All Apps” or “My Apps” page.  This starts the Application Wizard to step us through the application creation process.

Give your app a name and select to create an app from an existing template, or build a fully custom application. To use a template, select the Application Type to see a list of available templates.

To see more info about the template click the “More Details…” link.

Once you have selected a template you can make any changes you need to it, such as adding new a question to a survey. Once you have done this you can click “Preview and Finalise” to start the app creation or click “Next (Additional Options)” to configure any application-specific options.

Once you click “Preview and Finalize” a workflow will start to get administrator approval and create the application. Once this is complete you will get an email advising your app is ready to go! As with the SmartStarters you can also modify your app after it has been created by finding the related artifacts in the K2 Designer (Apps->K2).

Written by Andrew Blinco, Technical Evangelist – K2