BlackBelt K2 and other random tips

Sending emails to Destination user

File this one under miscellaneous tips, it might come in handy for someone somewhere.

The symptoms

• You want to send an email to the destination user using a standard email event wizard, but the check box for send to destination user remains grayed out and you don't understand why.
• You use the API in the code behind a server event, client event or in a destination rule or anything and try the following fairly innocent looking code:
• Console.WriteLine(K2.ActivityInstanceDestination.User.Email.ToString()); or anything similar to do with the ActivityInstanceDestination.User
• and the above line of code gives you an "object reference not set..." type error.

The Cause

The reason why you are seeing the above mentioned symptoms is because by default the new destination rule advanced settings are set such that no destination instances are created (Planned per slot (No destinations) in the advanced wizard). This means that the K2.ActivityInstanceDestination object does not exist and therefore the error you are getting. This is also why the send to destination user is grayed out in the email event template.

The Solution

So what to do? Plain and simple do the following:

• run the destination rule wizard for the particular activity
• click on the first (welcome) screen at the bottom of the wizard to go back to the start.
• check "Run this wizard in Advanced mode" and click next.
• On the next page you will see that "Plan per slot" is highlighted. Click on "All at once" which will create standard destinations as in 2003 (do how ever take into account the effect of this if you have a large number of destination users, activity data fields or xml fields, etc, but that is out of scope of this article...)
• click finish.
• You can now go back to your email event template and "send to destination user" will be enabled, and your K2.ActivityInstanceDestination API calls will/should work.

Logging Framework - Log to a SQL Table

I'm sure many of you have heard about the K2 [blackpearl] Logging framework by now or have seen Matt's post on how to create a custom logging event.

So today we're going to look at one of the options in the logging framework to log directly to a DB table. This has the advantage that you can quite easily filter and report on the results, and can make it much easier to reach the results in a distributed or secured environment. What I mean by this is that text log files dropped into a folder on your production box is not always easily accessible by anybody other than your administrator. So what if the developers need to troubleshoot an issue or you want to monitor for a certain logging event, then text files are just not good enough. But with your results dropped in a DB table it is easy to create some front-end view over that table to present the results in a browser or some other tool, and still maintain DB security etc. Some options (and we'll probably go into more detail on these in follow up posts) are to create an ASP.net page with a data grid that points to the DB table. You could even use the Dynamic SQL Service Object and expose this table as a Smart Object, if you had a good reason to do that.

So lets enable logging:

1. Browse to you hostserver/bin folder (usually located at C:\Program Files\K2 blackpearl\Host Server\Bin\HostServerLogging.config) and open the file.
2. The first area that you will be interested in today is the <Extention name="ArchiveExtension"...> section. This contains the two properties that will define the connection to the DB where you want to log to, and also the database name. Note that by default it uses the HostServer database, so it gets connection string to that from the K2HostServer.config file located in the same folder as above. 
3. If you want to use a different database than the HostServer DB then you will also have to place this connection string in the K2HostServer.config file, but the catch is that all the connection strings in this file are encrypted. So unless you speak fluent triple DES or whatever, you will have a hard time writing your own connection string in there. So here's the trick:
• Backup your K2HostServer.config file and then comment out the current <ConnectionStrings> section, so that there are no <ConnectionStings/> sections available.
• Now copy the <ConnectionStrings> placeholder part that is commented out at the beginning of the file and replace the values of the SQL server with the correct value for where your real host server is located.
• Add one additional line of the <add name="CustomLogDB" connectionString="... bla bla"/> in between the <ConnetionStrings><ConnetionStrings/> section pointing to your custom DB so it looks roughly like this:
• <connectionStrings>
        <add name="HostserverDB" connectionString="Data Source=mySQLServer;Initial Catalog=HostServer;Integrated Security=SSPI" providerName="System.Data.SqlClient" />
        <add name="CustomLogDB" connectionString="Data Source=mySQLServer;Initial Catalog=CustomLogDB;Integrated Security=SSPI" providerName="System.Data.SqlClient" />
  </connectionStrings>
• When the K2 HostServer is started up it will automatically encrypt these config settings for us and store them securely, so we don't have to worry about doing any encryption ourselves.
4. Note that IF you do use a different DB than the HostServer DB, then you will need a table called LogArchive with exactly the same fields as this table in HostServer. BUT, fear not because if your DB does not have such a table when the logging framework starts logging it will automagically create this table for you. But do not create an empty table called LogArchive in your DB and assume that the fields inside the table will be created for you. It will only check if that table exists and create it for you if it does not.
5. The next area that is of importance is the <LogLocationSettings/> where you will find the ArchiveExtension setting. To enable logging you have to change the Active key to "True" (note that it's case sensitive), and you can select what LogLevel you want to receive in your logging DB. The options are "All", "Debug", "Info", "Warning", "Ignore" and "Error".
6. For any changes in the config files to take effect you have to restart the HostServer service (no, not the whole machine), so go into Services and stop and start the "K2 [blackpearl] Server" service.

Once the service started running again you should be able to go check in the LogArchive table and see the messages being logged there. Lekker man! From there it's up to your imagination on how you can display this in some nice and user friendly UI to authorized users. Remember that there are other logging options also, including the MSMQ option which could also be quite handy, so we'll investigate that in another post.

Intro post

Hi there underground!

 Before we get this blog going I guess it would be good to start with a short intro post. As the name of the blog suggest I'll try to introduce you to some advanced K2 concepts (handing a knockout blow to that custom event template), but at the same time I will also try to share any random tips that I do come about. Hopefully this will be useful to someone out there, and probably good for me to help remind myself some of the things I come across over time.

My name is Gerhard and I've been working with/for K2 since the early betas of K2.net 2003 way back in yonder year of 2003 and over the years I have consulted in various capacities on K2 projects on 5 continents all over the world in all kinds of industries from major global projects to small little intra-department processes. My favorite feature of K2 is the fact that you can expand on the platform by going into code for almost anything, allowing you to customize a process to whatever your coding skills can let you. I also love the fact that we are always playing with cutting edge tools and working on the tip of the technology wave most of the time. This obviously has some frustrations attached to it as glitches are sorted out with new tech, but that is part of the game, if you don’t want to get hurt then go knit a jersey or something.

Ok that's enough intro stuff for now. Next time I'll write something techy for you I promise. Some posts I have in mind is to talk about exception handling in K2 BlackPearl, SOA architecture thinga majings, and maybe I'll tell you how a K2 process can achieve world peace (but that's only for extremely advanced users so remember to practice your Kata)....