K2 provides two standard notification providers:
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:
You can use Notification Events > Custom Event Designer in K2 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 blackpearl 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
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:
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 blackpearl 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 blackpearl version 4.6.9, a number of configuration files have been 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 \K2 blackpearl\Host Server\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 blackpearl service) in the environment, and the necessary configuration file changes need to be applied to ALL the K2 application servers in the environment.
This step should be performed every time you make an update to the custom notification provider .dll
This step only needs to be done once on each K2 application server.
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.
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.
Video | Links | Learn | Support |
No videos found for this article K2 on YouTube
No Additional links found for this article
No self-learning content for this article Try some scenarios...
No relevant support links available for this article
|