K2 BlackPearl SP1 Released

Service Pack 1 Release

Service Pack 1 for K2 BlackPearl has been released and I am very excited about getting it. Over the past two months I have been working closely with a client do some pretty basic workflows in WSS 3.0 and client-based InfoPath forms. We knew would be early adopters with using BlackPearl. We knew that building the workflows in K2 2003 and then migrating them to BlackPearl would add additional work plus that migration path still is under development with K2. Knowing this, we jumped in with BlackPearl. We ran into several small problems which required me to open several tickets with K2. The problem was the amount of small problems with their workarounds equated to one large problem. K2's support worked hand-and-hand with us to identify the issues and as of right now almost all of the problems have been resolved!

Congratulations to the K2 team for getting this out the door. I expect great things for SP2 J

Service Pack 1 Issues Resolved for this Project

• K2 Visual Studio memory leak issues were resolved - Basically as the processes got larger and larger with more stuff and the longer you left studio open the slower and slower things got. It is not speedy for SP1, but it is a significant improvement and bearable. In the past it would take minutes to deploy a K2 process, open a process or even a wizard within a disconnected VPC.
  
• SmartObject Invalid Archive Type Error – Well I hope this issue will go away; they mention it in the SP1 release notes. Basically when using SmartObjects with the SmartBox I would get this error out of the blue. No code changes and no reasons; just because. We would find weird ways to resolve the problem like changing the parameter values on insert or changing the order in which properties were set on insert. K2 Labs had seen the problem and believe it has gone away (I suspect the refactored a bunch of code under the hood which just took care of the problem). I cannot verify this has been fixed as I do not have any of the process instances with the error sitting around anymore.
  
• Escalations – There were several issues associated with escalations that were resolved for me. InfoPath forms are now properly cleaned up when Redirecting, using GoTo and Expiring. Problem is that the file name for the InfoPath for is dynamically generated using the event serial number in the name. So, it is impossible to guess what the InfoPath file name is without going in and modifying K2 wizard code directly to use a custom file naming convention. Going down this path was un-realistic with the amount of InfoPath client events that I had. The filename was stored in the activity destination instance and it looks like they now loop over this in the activity succeeding event and delete all of the InfoPath file instances.
  
• Working Hours – Along with escalations, Working Hours were not working and now work in SP1. They have changed since the K2 2003 product. The great thing you can now configure them on the K2 workspace outside of the process definition. Now you do not have to redeploy your K2 process when the process hours change since it is configurable in the K2 Workspace. Plus they are now time zone based. You can share working hour configurations across processes. I still need to do some research this week on the proper configuration of them. Specifically what is the right mix of associating a working hour zone with a process and user group/role.
  
• Dynamic Roles - Roles were not working correctly with Redirect Escalations. The problem was that even if you change the users who are registered in a role, the redirect escalations would still go to the old users who were removed from the role. Then I found out the same behavior was occurring with setting a Role for a destination user. Roles are the replacement for Destination Queues in K2 2003. It is a best practices to ALWAYS use a Role and inside of process. Then you associate users or groups to the Role making make your processes configurable through the K2 workspace so again you do not have to redeploy your K2 process when there is a change. So the issue was that Roles were not being refreshed with the K2 processes, this has been fixed and all is well now.
  
• Environments – Simply stated, they were not working correctly. Basically Environment templates are a class like definition for the StringTable (a key-value pair config). You can create re-useable configurations that can be used across processes. Now I have had to go down a specific path with my current processes but I know they have done a lot of work with this. Hopefully it will be better. Plus I need to do some investigation if you can create project dedicated environments that are not shared. This was a big problem with the release prior to SP1.
  
• Reporting Services – Many of the out of the box reports were not available. All of the reports we had in K2 2003 are not there an all of the issues associated with navigating through the Reporting Services reports have been resolved.
  
• Process, Activity and Event Error Handlers are Back – In K2 2003 there was the ability to put in global exception blocks to log, send an email, etc on error. They were not present. They have been added to BlackPearl allowing us to send emails to an administrator when an error occurs anywhere in the K2 process (I would still like to see this as part of the notifications framework)…
  
• Special Characters in K2 Workspace – It was frustrating but you could not use underscores, dashes, etc. in when setting values in the workspace. So if you have a url you needed to put into a configuration you could not. You would have to go into the configuration database and manually fix the problem. Resolved…
  

Service Pack 1 Issues Still Open for this Project

• Notification Limitations – Notifications is a new piece that allows administrators and users to hook into all events that are being raised throughout the workflows. Problem is that you cannot get access to XML Fields and that they are not re-deployable. The second issue is more problematic because you may set up sophisticated emails in your development environment and you will have to manually recreate all of them in your production environment. Plus the notification registration screen is not business user friendly. It is exactly what a K2 Administrator, Developer or very strong IT Business Analyst can use. Knowing this, we do not plan to take advantage of this functionality until it gets farther along.
  
• Redeployment to Production Environment Limitations – This is still an open issue with redeploying from one environment to another. Specifically notifications, roles, and environments must be manually redeployed into the production environment. I am not sure yet if custom reports will fall into this issue yet as they are Reporting Service definitions, but there is not push button to move them either.
  
• InfoPath Client File Locking – This is not in their release notes but it is an open bug that is still in SP1. Basically if you are using client based InfoPath forms if the user does not press the Ok button quick enough (like 3 seconds) after the submit successful is shown within InfoPath the process will fail with a file locking issue between K2, SharePoint and the client desktop. A temporary solution is to change the Submit Options to not show the prompt in the advanced options. Problem is that if there is an error on submit the user will not be notified there is an error. Second, every time you deploy the K2 process K2 will publish the InfoPath form with the option to show the confirmation prompt. After deploying the process you will have to open the InfoPath form, make the changes, and publish it again.
• Sending Roles an Email (WORKAROUND) – In the release notes, in is mentioned that a known bug is that you cannot send a Role an email and you will get a compile error. My simple workaround is make the Role the destination user for the activity, in the destination rule resolve the users in the Role and then send the email to the destination user. Done.