Custom Notification Providers

This content applies to legacy components (such as K2 Studio and K2 for Visual Studio), legacy assemblies, legacy services or legacy functionality. If you have upgraded from K2 blackpearl 4.7 to K2 Five, these items may still be available in your environment. These legacy items may not be available in new installations of K2 Five. These legacy items may also not be available, supported, or behave as described, in future updates or versions of K2. Please see the legacy component support policy for more information about support for these components.

K2 provides two standard notification providers:

  • E-mail Notification Provider that can send SMTP email messages when an event is raised
  • K2 Process initiation provider that can start K2 workflows in response to some event

In certain scenarios, it may be necessary to create custom notification providers that will execute some code in response to an event in a SmartObject, Workflow, or when an event is raised by a custom Event Bus Server. The most common reasons why custom notification providers are implemented include:

  • Auditing requirements that will write audit entries whenever events are raised on the K2 platform
  • To allow the K2 platform to participate in an Enterprise Message Bus architecture, by raising messages to the Bus in response to events on the K2 platform
  • A scheduled task implementation, where the K2 scheduling capability will be used to execute a particular event at some predefined interval

You can use Notification Events > Custom Event Designer in the K2 legacy workspace to register events for your custom notification provider. The user interface uses Reflection to determine which actions are available in your Notification Provider and what the input properties for the actions are. You can then drag and drop contextual information from the event into your notification provider action.

If you want to raise custom events in the K2 environment so that you can register actions for those events with a notification provider (e.g. listen for a "SAP Record added" event), you will need to create a custom Event Bus Server as described in the topic How to add a 3rd-party event recorder to the K2 Server.
The difference is that a Notification Provider responds to events and performs an action, while an Event Bus Server raises custom events which a notification provider can then respond to.

Implementing a custom notification provider requires knowledge of the K2 platform’s Event Bus technology, the K2 platform, and the systems and technologies to which the custom notification provider will send notifications of events.

You must clearly understand that building a custom notification provider is typically an integration project, and as such, there may be considerations about network communication, authentication and authorization when the custom notification provider needs to interact with an external system or API.

You must take care that the code in a custom notification provider is optimized and stable, since the code will execute on the K2 server. Code that performs poorly or is unstable will affect the performance and stability of the K2 environment, so sufficient testing and code review of any custom notification provider is recommended before the assembly is published in production environments.

You can also refer to the K2 community site for samples of custom Notification Providers, such as http://community.k2.com/t5/K2-blackpearl/Custom-Event-Notification-for-OCS/ba-p/751

Implementation

You implement a custom notification provider by creating a standard .NET assembly and defining one or more public static methods. Each public static method represents a notification provider. It is not necessary to reference any SourceCode assemblies or namespaces, or implement specific interfaces.

A custom notification provider must perform the following operations:

  • Gather data related to an event that is raised within the K2 platform
  • Send notification of events to an underlying system or technology

Deployment and Registration

In order for the K2 platform to make use of a notification provider, it must be deployed to and registered with the platform. Notification providers are deployed by copying the notification provider assembly to the Host Server\Bin folder in the K2 Server’s installation folder. Notification providers are registered by adding a key to the SourceCode.EventBus.Assemblies.config configuration file that specifies that path to the assembly and a display name for the notification provider.

In K2 version 4.6.9, a number of configuration files were consolidated into a single configuration file to simplify the management of configuration settings. The SourceCode.EventBus.Assemblies.config file has been consolidated into the K2HostServer.exe.Config file, which is located in the "%PROGRAMFILES%\K2\HostServer\Bin" folder on the K2 Server. The connection strings previously stored in this file are now retrieved from the K2HostServer.exe.Config file.

Deploying and registering a custom Notification Provider is a 2-step process.

The custom notification provider assembly must be copied to ALL the K2 application servers (i.e. the servers that run the K2 service) in the environment, and the necessary configuration file changes need to be applied to ALL the K2 application servers in the environment.

Step 1: Deploy the dll to the K2 application servers

This step should be performed every time you make an update to the custom notification provider .dll

  1. Stop the K2 service.
  2. Copy the notification provider .dll file to the K2 host server's Bin directory. By default, this directory is located at "%PROGRAMFILES%\K2\HostServer\Bin" (you could copy the assembly to a different directory: the important part is to set the path to the assembly correctly when you edit the configuration file in Step 2. We recommend that you put the assembly in the Bin folder to keep things consistent.)
  3. Copy any dependencies that are not already on the K2 server to the host server Bin directory, or install the dependencies in the GAC.
  4. Start the K2 service.

Step 2: Register the notification provider with the K2 application servers

This step only needs to be done once on each K2 application server.

  1. Stop the K2 Service.
  2. Add your assembly to the <assemblies> section of the K2HostServer.exe.config configuration file. You need to provide the Display Name and full path to the assembly:
    <!--
    Make a backup of the K2HostServer.exe.config file. This file is by default located in "%PROGRAMFILES%\K2\HostServer\Bin" on the K2 application server.
    Add your assembly to the <assemblies> section of the K2HostServer.exe.config file. You need to provide the Display Name and full path to the assembly:
    -->
    <assemblies>
      <assembly displayname="[DisplayName]" fullname="[Full path to the assembly]" />
    </assemblies>

  3. Start the K2 service.

Debugging

You can debug custom notification providers through remote debugging and attaching to the K2 server process. If you are debugging a remote K2 server, you will need to enable remote debugging. See http://msdn.microsoft.com/en-us/library/vstudio/y7f5zaaa.aspx for more information. If you are running a multi-K2 server environment (for example, when using NLB) we recommend that you shut down all but once of the K2 servers so that only one K2 server will handle the notification provider event.

  1. Add breakpoints to your code
  2. Copy the assembly and .pdb file to the K2 host server as described in the Deploying and Registration section
  3. Start the K2 service and then use Visual Studio's Debug > Attach to process option to attach to the K2HostServer.exe process. You may need to check the options Show Processes from all users and Show Processes in all sessions before the K2HostServer.exe process will show up.
  4. Use K2 legacy workspace to create an event which uses your custom Notification provider.
  5. Raise the event by executing the SmartObject, starting the workflow or performing whatever event you used in step 4)
  6. K2 Studio should launch and you can step through and debug your code.

Attaching to the K2 host server process and hitting a breakpoint will suspend all execution on the K2 server, so use this approach carefully in any shared K2 environment. We do not recommend that you debug a production K2 server, unless downtime has been scheduled.