It used to be somewhat confusing with two mobile apps (K2 Workspace and K2 Mobile) for two platforms (iOS and Android), but recently updated K2 Mobile Applications help landing page makes things clear right off the bat making it easy for you to navigate to the right information:
I guess I’m a bit late for writing posts of the “looking back at 2018” and “new year resolutions for 2019” type as through the relevant time period I was busy migrating my blog from premium shared hosting provider to cloud hosting. The reason for the move was former provider inflexibility with payment options (I was OK with high price tag but was not OK with their desire of receiving it all upfront). Migration process involved some silly mistakes and forced WordPress internals learning, but I finally managed to resolve all issues and get my blog up and running (now with HTTPS 🙂 ).
I also keep writing blog posts for StarWind Blog, and recent one was about SharePoint 2019 installation. But something which may qualify for bigger of my NY resolutions for 2019 is a new blog about K2 which I’m going to do completely in Spanish. I don’t plan to put huge amount of content there very fast and probably will be also translating some of my old K2 related posts into Spanish. You can already bookmark new site address – k2bpm.es and stay tuned for new posts which will arrive as soon as I write them 🙂
Recently I bumped into a problem which was super obvious in retrospective, yet took me some time to untangle it. K2 environment was upgraded from 4.6.11 to 4.7 and K2 installation path was changed in the process (drive letter). After upgrade was completed without warnings or errors, we did some more testing and found that one of the forms which was using Oracle Service Instance based SmartObject started to throw an error similar to this one:
Essentially it was very clear from the error message that Oracle Service instance keep looking for related assembly in old installation location (wrong drive letter). We switched to SmartObjects Services Tool only to see that there we are unable to edit or create new service instance of this service type. At this point I looked at old cases mentioning similar error message and surprisingly large amount of them was proposing workarounds and things not quite related with the root cause. We spend some time addressing missing prerequisite for this service type – 64-bit Oracle Data Access Components (ODAC) version 220.127.116.11 or higher, which mentioned as such in 4.7 user guide (_) and checking some related settings and so on.
But I next paid attention to the fact that environment had 2 service type for Oracle one of them was working, while another one does not. I next dropped assembly mentioned in error message in old installation location and restarted K2 service – it then fixed first Oracle service instance, but broken another one – it started to say that assembly SourceCode.SmartObjects.Services.Oracle.dll has been already loaded from another location, and this brought my focus back to the real problem – somehow one of the Oracle service types was not updated by K2 Setup Manager to use new installation path. Probably it was somehow “custom” and somehow was skipped by installer because of that. Anyhow my next step was finding where this path is defined. As soon as I confirmed that I cannot see/edit Service Type definition XML from SmartObjects Services Tool I switched to K2 database to check it there.
Necessary word of warning: Backup your K2 database before attempting any direct manipulations in it, and make sure you understand what you are doing before starting doing that 🙂
Service type definitions live in the follow [SmartBroker].[ServiceType] table, so I located “problematic” service type to check on its XML which is stored in ServiceTypeXML column. Here is the sample query to quickly search for service instance definition based on its Display Name:
Than will return you XML column value, on which you can click to view it as a formatted XML, here is an example of how it looks like:
As you can easily service type definition contains assembly path parameter in its XML. So now it is only a question of updating it with correct value. Here is sample script to do that:
That will iron out problem with misbehaving service type. I don’t think that it can be very frequent problem as normally installer updates all the assembly paths definition with new path. But, especially if you have some custom service type, you may want to scan your service types definitions for any vestiges of old installation path. Here is a sample script which will display all Service Instances definitions which contain old drive letter reference (my example uses “D:\%” as a search criteria):
I hope that this blog post may help someone who may bump into similar error in K2 and if not, then maybe you can make use of SQL script samples which use filtering based on values within XML columns.
P.S. Note that all scripts mentioned above are for K2 4.7. In K2 Five (5.x) structure of the [SmartBroker].[ServiceType] table has been changed – it no longer has XML column named [ServiceTypeXML] and assembly path is stored in dedicated text column [AssemblyLocation] instead.
Somehow I kept forgetting this thing frequently enough to expend some effort to write this 🙂
At times when you troubleshooting something in K2 you need to identify process having only process instance ID and frequently knowledge of the solutions and workflow is a missing part (developer is away on vacations or , in the worst case scenario, nobody even knows if there was a developer in the first place 🙂 ). As a sample scenario, you can think of troubleshooting failed process escalation or process instance which stuck in Running state.
Let’s look at this in more details. For failed escalation you will definitely have error in K2 host server log and entry in K2 Server.Async table – that will give you ProcInstID value, and your next steps are: A) Find out which process this instance belongs to and B) Status of this instance. Finding (B), at least if your process is in error state is easy as it supposed to be listed in Error Profiles View where you can retry error and also see Process Instance ID and process name.
But in case your instance not listed in Error Profiles View, or let’s say you going step by step before jumping into Error Profiles, then you still have 2 options to get Process Name process instance ID:
(1) Using Workflow Reporting SmartObjects. You can use Process Instance SmartObject (Workflow Reports > Workflow General > Process Instance) to get list of Process Instances – you just feed ProcInstID to it to get back ProcessSetID:
Process Set ID in turn can be feed to Process Overview SmartObject (Workflow Reports > Workflow General > Process Overview) which will give you Process Name:
(2) Querying K2 database (in case you already in SSMS and too lazy to switch over too K2 Server/Tester Tool 🙂 ). Here is a SQL query you need to run:
Today 17.10.2018 K2 5.2 went into GA stage meaning news about release were sent to all clients and partners and starting from now we can download this new and shiny version from K2 portal. So it is a perfect time to do a little review. Without further ado let me start with this.
You can download 5.2 installer from K2 portal. And providing you have test VM with current version of K2, update manager will get you to new version withing 30 minutes or so. Once installer completes extraction of files you presented with splash screen:
Splash screen provides you with essential information (.NET 4.6.1 requirement, where to run an so on) and allows you to kick off installation process (conservative people like me can still locate Setup.exe and run it from Installation folder).
In case of existing installation detected K2 Update manager detects that and gets you upgraded just in few steps:
In case you run with multiple security labels you will immediately notice improved label selection UI which is no longer looks like something from the past and fully aligned with modern K2 UI design:
Additionally you will notice increased number of available OAuth resource types:
My favorite under the hood improvement, which is really huge thing, is completely rebuilt identity cache and sync architecture which was brought into on-prem product from its cloud version (if I employ Microsoft-speak “battle-tested in the cloud” and so on). At this stage all the internal infrastructure of new Sync Engine is already here in 5.2 RTM, yet it is disabled – stay tuned for official news for when this feature will go live for all customers. At initial stage K2 will work with selected customers to assist them to enable and transition to the new Sync Engine. But like I said, you already can see that underlying infrastructure for New Sync engine is already here in 5.2 release. In case you familiar with back end/underlying tables you can tell that number of Identity tables has increased:
And Identity.Identity table has been expanded too:
Long story short with all these changes and new sync engine enabled your Identity cache sync speed will be greatly improved and, for example, even your URM Get Users SmO call against Azure AD label can be served from cache without doing query to AAD.
There is more improvements and new features and I will try to cover them in greater details a bit later.